# p2p Messenger & Toolbox - Whitepaper

## Background
Since 2010, the Instant Messenger (IM) platform WhatsApp has shown exponential growth in active users, from 10 million monthly active users in 2010, to 2.7 billion in 2023, it is clear that IMs have become a default app for the vast majority of mobile users. In recent years we have observed user bases grow on platforms like Telegram and Signal, mainly based on users’ privacy concerns using applications like Messenger and WhatsApp. Active users engage with their contacts directly, or within public and private groups, where the user profiles and messages are recovered from a centralised server (presenting privacy concerns).
Over the past 5+ years we have witnessed a growth in users paying for subscriptions to follow content creators, who produce regular content for their communities. Users will also pay additionally for extra engagement within the live chats, where messages are made more prominent and they may receive a shout out. Depending on the platform users may place on a leaderboard, based on their level of interaction within the community and money donated to the creator channel.

Platforms, for example Twitch, that host these communities will take anywhere from 20% - 30%+ in fees, on any funds that are sent from users. Also, users who engage with the creators that they follow, do not receive anything tangible or meaningful that represents the creators that they follow and actively contribute. They may fall on a leaderboard or receive channel emblem/points, that may grant certain rewards within the website they are using. But they do not receive anything that can be transferred out of the ecosystem, in the way of a digital collectible or badge that portrays the communities they follow and engage with. Users retain no real ownership of anything that illustrates the money or time spent engaging with the creators they follow.
**Platforms like Twitch are in essence a messenger where each user (including the creators) has a profile where they save their media content. The other key features are video streaming, where fans can chat over live streams, pay subs and raise their social profiles, within the communities.

We also have a landscape where businesses/organisations host a variety of loyalty schemes on different mobile applications. While digital cards for these schemes can often be stored and used through central apps like Google wallet, in order to have a full UX where you can viewpoint totals etc, you need to have the relevant mobile application downloaded on the device. This has created an ecosystem where devices have become flooded with numerous applications, with multiple logins and accounts. Also, loyalty points that are collected are nontransferable outside of the user redeeming them at the retailers for their reward. Again, users have no real ownership outside of the ecosystem they are engaged with and as an example they are unable to swap, with other users.

In short there is no real standard for current subscriptions or loyalty schemes that we connect with.

A p2p Instant Messenger and toolbox can look to provide the solution to the issues outlined above. As it stands there is not a p2p messenger that has currently managed to capture considerable market share. While the technology to sustain p2p messaging is relatively nascent, it has reached a stage where it is becoming more infallible to be harnessed within a fully p2p sphere.

# The Idea

The idea is to create a fully decentralised IM messenger that will harness p2p technology on a level that is not currently offered by incumbent applications, in relation to the way messages are sent as well as stored. The solution would be underpinned by a private key, that would allow p2p messaging, including p2p storage for message archives, user profiles, and media content tied to digital assets.
The idea is to create a p2p messenger, where the user account would be underpinned by a private key, allowing for digital asset storage. A key feature to be launched with the IM would be video streaming with a chat thread window for creators and their communities. Either public or private groups can be created or joined, with direct messages, voice call or video calls being standard features for the IM.
To support the IM, the platform would host a toolbox that would allow for users to create their profiles and digital content like badges, points or collectibles. The content itself is represented by a multimedia file, that the user can upload or select from stock content, both via the toolbox (to include creation/design in the future). Through users’ engagement with the chat groups/communities they follow, there is the ability to receive digital content that will be saved to the private key being used.
This content allows for gamification, where if a certain number is collected, they could evolve into a more premium collectible, granting access to things like exclusive groups and more enhanced badge etc. As the ecosystem grows, the digital content could be used to mint skins for gaming (as just one example). Subscribers will be able to exhibit their advocacy, for a community that they follow, making subs paid translatable into something outside of just being a digital image within a group.
The other key area to be supported by the toolbox is the hosting of loyalty schemes. The user group represented as businesses and organisations, will create a profile which would underpin their loyalty programmes, where users could scan a QR code and receive the relevant points to their account on the p2p IM.
There is an opportunity for organisations to reduce costs in relation to their mobile applications, due to the infrastructure needed to support their loyalty programmes, engagement campaigns or ticket storage apps etc being provided by the platform. i.e. a mobile browser UI.
Toolbox helps Create a standard for user profiles and amplify the benefits of underpinning certain digital content e.g. loyalty points, badges and community collectibles, as a standard that would be ultimately NFTs.
What the toolbox provides is a hub for users to create digital content that will have various uses, across multiple industries (both online and offline). In the short term,
The application will be under control of a DAO, ensuring that along with the technology the organisation itself will be decentralised. What this ensures is that the ecosystem operates with a not-for-profit ethos and under control of the users of the platform. Governance like development decisions and proposed protocol fees will be created and voted on by the token holders, allowing for a unique proposition for users to be owners of the app they use and empowered to engage with governance proposals.
The app will be free to use, with user profiles (which initially would have a size cap) being stored on the decentralised storage network Swarm. These storage costs would be paid for by charging a small protocol based fee, when certain transactions are made and used to buy BZZ needed to host user data.
The aim is to build a large user base, where digital marketplace protocols can be bolted on that will disrupt digital marketplaces like travel, stays and food delivery. Protocol based fees can be charged to further develop the ecosystem as well as cover costs, that will be considerably lower than the current intermediary fees charged. The platform looks to charge a fee in the long run, that would be <1%, which opens up the opportunity for a community voted fee to be levied e.g. 2% on all transactions in a given region, that could be then spent on a community voted charitable cause, where the service takes place.

Building out marketplace protocols and paying for development costs and ecosystem costs
In the short term, the main purpose of the content will to represent a digital reward, following the user’s engagement within a public or private chat group. This will be something that the user can keep forever and could even evolve following a certain number collected or level of participation.

# Peers - User Groups & Profiles

All users who download the app will create a profile upon registering, which ultimately makes them a peer in the network. The peers can be broken down into 3 distinct groups:

- Standard Users
- Content Creators
- Businesses/Organisations

The notion being that they will each have a profile, represented by a 'sub ENS', but the content displayed for each would represent different demands in relation to the profile UI/UX and on the amount of data stored. It is important to make this distinction because as an example, content creators and organisations would produce and store more content than a standard user.

Standard users would predominantly store their messages (text files) or the multimedia files for their profiles and digital content. Content creators and businesses/organisations would mostly have profiles where they would have a larger digital footprint of multimedia files. For content creators this would predominantly be their catalogue of streams and for organisations it would be more in the form of different UIs, i.e. a copy of content from their mobile app or website.
In the long run the platform seeks to help user groups like organisations increase their engagement with advocates, by rewarding loyalty with access to private chat groups and exclusive digital media E.g. locker room/backstage content, collectibles etc.

Profiles will need to be hosted for free, with the cost for storage paid for by a small fee levied on transactions made during chats or streams*.

# Private Keys

All users will have a private key. However, this is still an alien thing for the majority of people, but a feature that is being rolled out and pushed by top tech (see article). From this perspective, it’s a great time to roll out a free-to-use, decentralised app, with web3 capabilities, while there is a reduced barrier and rollout (conditioning) when it comes to security (private keys and safe storage).

In the short term, the user’s private key will be offered as a seed phrase, passkey or QR code. The QR option will contain a warning about the security of having a key in QR format but will not be heavily pushed due to accounts not having any financial burden. However, if a user starts to store collectibles on their account, then warnings could be sent if the user has opted to store as a QR. (see Account Abstraction*)

## Users Names/Public Addresses. (ENS Sub Domains)

The user profiles will not be linked to a mobile number, but rather a sub-ENS. The user will input an ENS of their choosing and this will act as their username/point of contact. The address would be represented as the following NTL.appname.eth/gno*

User selected ENS IDs as a point of contact, provides a unique opportunity and UX compared with the status quo; mobile numbers or email addresses. A sub-ENS ID is their public address, however, it will not allow open access for other peers to contact unless both parties have requested to connect. (This preference can be changed if the user chooses an open profile). The ENS/public address will also be represented as a QR for peers to scan.

## p2p Messages
For some users the attraction of encrypted messages not being saved on a server, but to the device only would be the main draw for using a p2p messenger. However, there is also a large user base that would want to save messages, in a similar way to that on WhatsApp with archiving. Naturally, WhatsApp stores data in a centralised manner, but this data could also be stored on Swarm, with encryption, creating a fully decentralised p2p messenger.
The main principles of the p2p messenger will be built on privacy whereby default messages will only be saved locally on the device. However, there will be the option if users want to archive their messages to save on Swarm.
In order to create the funnel for messages to be stored on Swarm we need to harness a protocol that supports p2p messaging. In this, there are a few options available:

### Swarm’s PSS
PSS provides a solution to p2p messaging; however, it may not be the best solution in terms of instant messages (IMs) due to latency. The node needs to mine single owner chunks into specific neighbourhoods (trojan chunks) which will induce latency, creating an issue for IMs being delivered instantly. For this reason, we will explore other options below that could better serve demands.
PSS could be used when users load archive messages, both personal (DMs) and those with public and private groups. The latency when loading this kind of data, is more acceptable due to the nature of loading content.

### Waku Protocol
Waku is in fact a tried and tested in the sense that Status is already utilising their protocol for p2p messaging and companies like Coinbase are currently trialling wallet to wallet messaging, using Waku. This makes it an appealing medium for enabling a fully decentralised IM, once fused with Swarm.

### Status Fork
Taking advantage of the code being open source and that Waku is used, the app could be a fork of the Status app, but a more trimmed-down version in relation to UI/UX. The fork would also need to have the ability to 'talk' to Swarm, in relation to messages and account associated media. The other key difference compared to Status will be the user’s ability to select a sub ENS of their choosing, without needing to stake tokens.
Currently, Swarm is not compatible with Status, so any integration needs to be explored.

### Flutter Open-Source Apps
Numerous open-source applications could be bootstrapped, which would provide the infrastructure to support IMs, which ultimately would be archived on Swarm.
To create a p2p IM, Waku would need to be built onto the backend of any Flutter open-source apps**

## Storage and Costs

All data will be stored on a decentralised network and not a central server or IPFS (which still presents centralisation issues). The network used will be Swarm and as the ecosystem builds out the storage costs will be covered by a small fee applied to certain transactions made within the p2p IM. This will provide a free to use ecosystem for users, however data limits would be applied, where users would need to purchase more storage space if their channel is not contributing to the cost of storage.
We look to champion users becoming ‘greener’ with how and what we store digitally and feel strongly that there will be an evitable swing in attitudes, with regards to how much data and what is actually being saved.
Users need to be able to save data on Swarm securely, where only they will be allowed access. Ultimately, access would be granted to the associated private key, however this is not currently possible due to the user needing to run their own gateway for exclusive access (see Gateways). Until mobile gateways have been developed on Swarm, users will need to use the platforms gateway to upload data. Alongside this, updates are needed to the network, so the privacy of user data is still upheld, despite the upload being via an 3rd party gateway (see Pre-Signed Chunks/Sponsored Chunks).

## Video Streaming & Chat Feature

A feature to launch in the early stages will be video streaming with a chat facility. This would allow content creators to stream their content in the same manner as current UIs/UXs (e.g. Twitch), but with the unique UX around the digital content available and ownership.
A UI where the live stream has a chat window below, would need to be developed as well as profiles where creators can archive their streams, all ensuring that the fundamental UX currently on offer is not interrupted.
Etherna, provides solid foundations that could be built off for archiving creator content and access to their profiles.

Users will be able to donate to the channel, by utilizing the accounts that underpin their profiles and a small fee will be taken from the transaction.

(EDUCATING USERS ON PRIVATE KEY SAFETY WILL PLAY A HEAVY ROLE IF USERS START LOADING FUNDS TO THEIR ACCOUNTS. ACCOUNT ABSTRACTION WILL BE KEY TO THIS)

## Account Abstraction

The app will very much look to pioneer AA, recognising that storing private keys isn’t a user-friendly process. With a core team specialist, we will provide a more enhanced UX when it comes to recovering accounts, following private key loss.

We will be able to implement and spearhead account features like:

- Multi sig/Social recovery - e.g. Friends/family authorising new keys.
- Hardware signers - biometric data like fingerprint or face ID.
- Multifactor Authentication - e.g. email or SMS

The app will look to champion elements like social recovery, where users could select some of their close contacts to be eligible to authorise new keys etc. Also, exploring hardware signers like fingerprint or face ID, to further reduce the issues with private key storage.

Ultimately with an onboard specialist we will be able to help champion AA, to ensure users losing access to their accounts a near impossible event. AA will be key to ensuring that registering and saving keys is as seamless as possible, which will be critical to us driving real adoption.

# Digital Collectibles

In the early stages, digital collectibles will be a key component to user adoption. They provide an opportunity for brands/creators etc to connect and engage with their customers/fans etc, by providing them with something representative of their interest and also interactive/dynamic. The account/wallet also provides the foundations that could form a loyalty scheme where users can collect and cash in/transfer; when they have a certain number or even have the collectibles evolve into a more premium/visually appealing digital asset.

Instead of storing the media content for the collectibles on IPFS*, the content can be stored on the Swarm network. This provides a much more decentralised solution where data is not pinned to a host but stored on a decentralised network.

From a creator/brand/business perspective, the main purpose for users to claim their collectibles is so they have a channel to send messages, leading to further engagement with their community. This could be in the form of direct messages or via public/closed groups. Naturally, the collectible itself is a form of advertisement for the creator and advocate.

The free to use toolbox would be provided so creators can design and mint digital collectibles for their communities. ERC 2981 - royalty payments (clip/small fee) would be invoked on future sales (when rolled out in the future) would be levied on the NFT, which would be earmarked for development and ecosystem costs.
Fundamentally, the digital content created will consist of two components; on the backend is code that is saved to the account in the form as a NFT or FT. The frontend is basically media content that will be saved to Swarm and accessed by the accounts private key. The media files should be built on existing standards (Jpeg, mp4 etc), to ensure the user does not experience system lock in with regards to the visual representations of their tokens.
## Gamification of the app and ecosystem
The app seeks to grow its user base by creating a platform that encourages usage through the gamification of the interactions that users have with other peers or content on the network. The ecosystem being created would allow the interaction of communities and brand advocates to be in a more enhanced way, allowing for higher levels of engagement and advocacy. We will explore some examples, that have already proved popular when it comes to return rate and enjoyment.
### Decentralised Tinder – Enhanced Graffiti Wall

Providing the features, allowing for access to a free to use Tinder could a present an opportunity to develop the already established Graffiti wall on Swarm. A geographic consensus layer would need to be created along with some other primitives relating to privacy. But a decentralised dating feature that harnesses already established tech of Graffiti wall, would provide an enticing option for certain user groups.
Graffiti wall in itself could prove popular with user groups who are not necessarily concerned with privacy and want to post a public profile.
### Collecting Content – Collectibles/Loyalty Points/Badges
The notion of collecting has long been a past time and a societal trend that has stayed strong in terms of engagement. In recent times we have saw a growth in users collecting digital versions of Baseball (as an example) cards, where the asset is locked as an NFT. Loyalty programmes are also a staple in our everyday lives, where we collect points that are redeemable for discounts and offers.
The toolbox allows for the creation of loyalty campaigns and their associated points/stamps alongside digital collectibles, in the form of badges or emblems. While loyalty points could be redeemed in the same manner as they are today, customers collecting badges or emblems could see them evolve into a more premium collectible that gives exclusive access to content and more visually appealing (e.g. Gold emblems)

### Gaming skins/content evolving from online engagement with communities
Gaming presents a huge industry to tap into, from streaming to users playing games themselves. As digital collectibles become more interoperable with computer games, there is an opportunity for the app to be a hub for users to save their content for gaming. Coupled with this, the content collected from communities could be used to form and mint skins and game content, that can be uploaded to interoperable games to be flaunted while playing. The p2pIM account allows for the user to store and evolve their digital game assets, for later uploading to the relevant gaming environment. (e.g. special skin or weapon)

# Campaigns for adoption and Growth

Here is a list of campaigns that are currently in the early stages of conversations, and are just a few examples of the types of markets and industries that would be engaged and supporters of building this type of decentralised network:

### Example 1
Partnerships with Premiership football clubs – Football fans who attend football games, traditionally will purchase a programme and maybe a scarf with the teams playing. What the app provides is the ability for the football club to create a profile, and then connect with fans. The connection could start by a user simply adding them or by match day supporters scanning a QR code/NFC, receiving a free digital emblem of the game, thereby opening up a connection.
The emblems of the games could be interactive where if a supporter attends and collects a certain number, they could receive a special club badge (e.g. gold or platinum). This could become something that fans strive to collect and are proud to display in digital photo frames or on mobile devices. The interactive element could also be explored where fans vote for their favourite goal or 15 second moment, which could be attached to the emblem of the game.

Each football club would naturally have their own profile, that would have a private area for qualified fans (based on their collectibles held) are granted exclusive access to behind the scenes content.

### Example 2

Festivals including Glastonbury are held yearly and attract circa 200k people. Fans attend from around the world and for many, it is an event they attend more than a few times. Currently, there isn’t really much for fans to collect to document attendance at the festival or at any of the performances, other than their tickets.
What could be created for attendees, is a digital badge that serves as a memento of their experience. Returning guests could collect and when they have a certain number, exclusive access to a special area (toilets, bar etc) of the festival could be granted as well as competitions for backstage access. Favourite moments/songs could also be voted for by fans and attached to the collectible, to make a more dynamic experience with the digital.

Glastonbury festival have digitised their ticketing where users need to download their app in order to retrieve tickets. These could very easily be hosted within the user’s wallet/vault, reducing costs for the festival hosting the facility on their mobile app.
### Example 3
Notting Hill Carnival hosting their app on the platform. Due to the nature of the event, mobile signal is very poor, meaning the p2p nature of the app will be best suited in that environment due to the required data already being saved locally on the phone; once the user has loaded it once.
The event

# The Vision – Peers & Protocols

Despite the app launching with a heavy focus on NFTs, it is certainly not the main long term focus of the platform. They will be used and harnessed to grow the user base and aid adoption when it comes to registering an account. The long term aim is to build a pool of users, who can then be connected by different protocols that disrupt the various online marketplaces.

As the user base grows, it creates a pool of users that can be connected directly p2p via protocols, allowing for txns of a financial nature without intermediary fees. The account allows users to connect with other peers, via protocols that are not geared up toward profit or storing/selling user data (unless user opt-in for data sharing at later stages). Protocol fees charged would be to cover ecosystem/dev costs and will be a fraction of what is currently charged by incumbent markets. (Such as booking.com, uber etc etc)

A private key also makes it possible for users to set up things like validator nodes, in a decentralised manner for various blockchains. As the platform grows a key ethos would be that users contribute in some way to the sustainability of the ecosystem. Whether, through protocol fees or by the user hosting their own node, private keys enable peers to help sustain the ecosystems they may interact with and receive a return on their stake. This can take on many forms, depending on the node and devices.

For organisations that have their own mobile applications, there is an opportunity for them to reduce their costs for developing and hosting their app, by replicating their app UI/UX on their user profile. This helps reduce app clutter on user phones and reduce costs for the hosting party.

# DAO

We are creating a DAO, where the ecosystem is owned and governed by the users and token holders. With the DAO operating as a not for profit, the scope is there for an agreed fee that could be levied on transactions, which could be paid towards community voted charitable cause. What would be shareholder profits (based on existing digital marketplaces) could be diverted to more humanitarian and environmental causes in the local area where the transaction was made.
The DAO would ultimately oversee any such campaign and governance decisions around platform/protocol development.
Once the app has launched a manifesto/mandate/charter* will be released, setting out the pledges and rules of engagement for the newly formed DAO. It will coincide with the expected token sale or incentive based claim (referrals etc), after which decision making will be passed over to the token holders. Proposals would be raised on Snapshot by any token holder and put to the community, where the circulating token supply would vote for their preference.
Control of any community fund would also be managed by the DAO, with proposals for charitable causes being submitted for a vote in the same way that development proposals are submitted.
Nearer the time a full breakdown on the of the role of the DAO and the community will be mapped out, making its commitments clear and how exactly governance will be managed effectively.
The end game is to create a DAO that oversees and develops a fairer and overall simpler internet in relation to it in essence being a mix of just peers and fair protocols (put above?)… maybe even laying the physical foundations for a new internet network ;-)

## Protocol Based Fees – Development & Locally Based Charitable Funds
Once the DAO is established the protocol based fees will be agreed by the community. The fee charged that will cover platform costs will be a reducing figure based on the stage of the ecosystem and when fully established would expect an average fee charged to cover costs to be <1% (hopefully <0.5%). Naturally, the % can be adjusted as per relevant proposals voted, relating to accruing more funds for development.
To give something back to the communities where the service takes place, an agreed cause and % fee could be proposed and voted on by the community. There are a few models that could be implemented regarding how and where the funds are spent, but eventually when there is a lot of value being transacted through the protocols, the customer of the service could eventually decide themselves which project they would like their fee to be sent to.

## Tokenomics

The app would initially launch with no mention of a token. It would not be needed by users to interact with the platform and have no utility within v1.

For users, their first real mention of a 'token' would be in relation to the referral scheme where user referrals are rewarded with badges. These badges could be claimed in the future, based on a banding for the user’s total number. Also, having options to work in a similar way to Discord nitro prizes, dependent on partners.

The main purpose of the token will be for governance of the ecosystem, but as the platform grows so will the utility of the token.

### Gov token

The token is an integral part to the platform operating as a DAO. Users will be able to vote on key things relating to platform and ecosystem development and operation.

### Staking Token - Validator Nodes*

Staking token for setting up nodes; working in a similar way to rocketpool token. Basically, making setting a node (GNO, Bee etc) easier - token staked and the node is created in the back end, based on stake/function. The idea is that the UI/UX is simplified so that a user can set up a node more easily. e.g. staking tokens and saving a few things.

In the same way as Rocketpool the platform would offer the opportunity for peers to pool funds if they do not have enough to setup a full node.

### Staking Token - Reduced Platform/Loan Fees
Staking the token could enable a discount on fees and in the long term a discount on loan fees, based on expected revenue (on chain).
Revenue on loan fees could represent a real opportunity to accrue a lot more funds for community voted charitable causes, as well as taking the earning potential of the DAO to a new level.

### Staking token - Share of Fees, Lottery other benefits

As legislation catches up to crypto, revenue sharing will be explored, if it can be without upsetting bodies like SEC.

There are numerous other things that can be explored with the token, also included with staking. Such as extra storage, more features etc.

### Financing

The token will also be used to raise funds to launch and develop the application. Being cautious with funds and token holdings will be at the forefront in relation to reporting spend and centralised concentration of holdings. The main aim is to use financing to create, launch and sustain the ecosystem for a certain period. Then use a token sale to develop further, where after this stage various protocols, with a small, agreed built in fee, will provide the funding needed to maintain and develop the ecosystem. Ultimately, in the long run, the community pays for itself.

## Incentive/referral campaign
To encourage users to register a private key and sub-ENS, various campaigns will be launched to help support. This would include a referral campaign where users can receive rewards for encouraging others to register. Various other incentives could be built in where the user is rewarded for completing certain tasks e.g. uploading a profile pic or bio.
The incentive will be in the form of the native token, but initially would be displayed as points earned, which once minted would be made available for claiming (subject to vesting period).

## Creator Stake
As the p2p environment builds out and becomes more popular, creators will be required to make a small stake of funds, that would act as a deterrent to bad actors. Initially this stake will be in the form of a fiat value and a set number of tokens in the background that would not see its value fluctuate. Upon launching the token, the number of tokens attested to the fiat amount to stake, will be a dynamic figure based on the market price. If the token price was to drop considerably then the creator would be expected to top up their stake above a certain threshold.
It is important to note that when the stake does become a requirement, the fiat value will be low enough to not deter users but make it expensive for bad actors – circa $20.
Harnessing projects like Kleros, an ecosystem could be created, where bad actors lose their stake, and the reporting party receives the staked amount as a reward/bounty. A code of conduct for the ecosystem will be formulated, spelling out what would be considered malicious and unsuitable for the indexed catalogue that would be hosted on Swarm by the DAO – anything outside of this would relinquish the associated stamp and BZZ that was funded by the DAO.

## Toolbox
Upload a media file (image or short video file); and in the long term release a toolbox that contains photoshop style features, for user to create new or fashion their existing media. The focus being less about still images, but more dynamic when it comes to aesthetics. The creator can then mint and send their digital.

## Gateways & Nodes
For content to be uploaded to Swarm it needs to channel through a gateway, which ideally would be hosted by the user. However, due to the nature of the product being a mobile application, mobile gateways need to be developed that would allow users to create their own gateway for uploading content. Until this becomes reality the DAO would need to host its own gateway so content can be uploaded. While this presents a centralisation issue, it is a necessary step on the road to growing the user base and creating a fully decentralised application organically.
The Swarms network is managed and maintained by nodes (called Bee Nodes) that can be setup by anyone in the community, using relatively basic hardware and setup. As the demands on the network grow, the number of node operators needs to also to ensure costs and reliability storing data is managed effectively.
The aim is to build up a pool of users that could be easily migrated to being able to host their own mobile gateways, for uploading their content. When mobile nodes across web3 have become more established, users could be offered the opportunity to create a Bee Node and ultimately incentivised for doing so. This could also be implemented as a mandatory feature, where all users would become a mobile GNO & Bee Nodes upon registering, thus helping to maintain the network, when they are using it.
Prior to mobile nodes being developed and becoming widely used, other solutions can be explored to help sustain the storage network. These would include plug and play NUC devices, that would make setting up a node at home easy, providing the operator a return on their stake and work. The hardware required to setup a node could easily be built into home electrical devices like routers or even TVs. This could allow for anybody to have a node running at home, with reduced barriers to hosting and the associated incentives for setting up and maintaining.

## Pre-Signed Chunks/Sponsored Chunks
An important primitive that needs to be in place is to do with the principle that currently users cannot retain ownership or have privacy over their data if they upload via a 3rd party gateway, i.e. the DAO’s. To enable this pre signed chunks/sponsored chunks need to be implemented, which would allow for user data to be only accessible by their private key, regardless of the gateway used.

## Stamps & BZZ
Users need to be able to delete content if they choose and be confident that any data is deleted from the network. Ideally stamps would be drained of their BZZ, thus erasing the affixed data and not wasting BZZ hosting unwanted data. This becomes imperative when the platform has reached mass adoption due to the amount of DAO funded BZZ being drained on deleted content.
## Digital funds & Onboarding Fiat
With user profiles being underpinned by a private key, it permits the use of digital tokens like stable coins to be saved to accounts. A payment facility is fundamental to supporting users paying for premium content and will have a protocol based fees levied on these txns, earmarked for the DAO fund.
To help the onboarding of fiat options like Gnosis Pay and
## Proposed Roadmap/Plan

## Public/Private Chat Groups -

Status hosts a feature where users can participate and communicate in public groups. Users are able to search for group names and interact with communities. Threads, which is hosted on Swarm, could be an integration where public chats could be featured on the app.

A collaboration with Graffiti Wall could present an opportunity for users to post a picture with their ENS ID on a public page. This could start to form the basis of a public directory of users who want to be sociable and not as concerned with privacy e.g. creators.**check, if possible, with graffiti wall i.e. mobile

Private threads/chats are not yet available so would need to be developed before private chats/threads could be hosted on Swarm.**

## GPT Search Feature

Chat GPT type feature to be used as a search engine for users