---
# System prepended metadata

title: Decentralised p2p messenger Revised v1

---

# The Idea - Decentralised p2p messenger - Overview

The idea is to create a p2p messenger, that would also have a wallet/account allowing users to store digital collectibles. While this is nothing, new, the aim is to fuse and ‘slim’ down current offerings, removing any barriers like staking tokens and crypto wallets. The platform would be built on the principles of being fully decentralised and with the long-term aim of building a network of peers. Moreover, in the long run the platform will be owned and governed by the peers that use it. Governance will be mananged by a token, with the aim of being available for claimants and a sale/funding round, within 2-3 years of the app launch. WeChat.

Toolboxes will be provided for creators to design and mint their own digital collectibles, that their communities can claim and where relevant collect. These digital assets could be in the form of badges, emblems, images, loyalty stamps or even tickets. 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.

A user would create a 'profile' in a similar way to Whatsapp which would be stored locally, as well as on Swarm. The foundations for this will be in the form of a private key and from a user perspective, its main utility will be for account recovery. As users become more exposed to private keys and also developments with Account Abstraction, the method of sign up and recovery should present less of a barrier for users. The platform would very much look to pioneer the UX, in relation to AA, being best placed to port users, with methods like finger print or facial recognition. 

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.

A user’s public address would be represented as a user-defined ENS input and would be selected upon signup. It gives the user an opportunity to select a unique username that despite being a public address, by default will not be open to 'connections'. While this can be changed if the user chooses, the app will be built on the principles of privacy, where user accounts are effectively locked down, unless a QR code is scanned or a user request is accepted via their user name being typed/requested too. (can NFC be used??).

The app looks to replicate the UX of Whatsapp, Signal, Status etc, but with the key difference being that it is the first interactive p2p messenger. As things stand there is not a platform that is offering the fusion of p2p messaging, a free-to-use toolbox, a simplified collectibles wallet with decentralised storage all operating under a DAO. 
 

## 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 wallet/vault 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.

A 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

## P2P Messaging 

For the p2p messaging app Waku protocol will be integrated with Swarm protocol. Status*, a p2p messenger, which uses waku will ultimately be forked, as it provides a sound base to work off. The fork would be trimmed down to a more basic application, with no emphasis on crypto storage (in the early stages). The app would consist of the following functions:

- Inbox - direct messages from connected peers*
- Chat - Public/private groups*.
- Vault (wallet) - Where the users digital collectibles are stored.
- Profile - An optional feature for users where they can upload a profile picture and share a 'thought' or picture.

The main principles of the p2p messenger will be built on privacy. Where by default messages will only be saved locally the device. However, there will be the option if users want to archive their messages(text), to store on Swarm. (**future development)

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

The app itself 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 user name/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.  

To stop people from gaming the system and hoarding user names, the app will implement a periodic pop-up notification. When the user clicks out of the pop-up, a message will be sent to a platform address with the user ENS, confirming an active account. After an agreed time period, inactive sub-ENS IDs will be revoked. If a user has interacted at an event or with a creator and is holding a collectible on their account, then ENS will not be revoked, regardless of inactivity. 

## The Technology

The application will fuse together Swarm & Waku, with more integrations between the two as the ecosystem evolves. As Swarm develops, user 'owned' profiles will be rolled out, where users could store messages, profile pictures, etc, that only the owner (user private key) can access.

With v1 the only data that will be stored on Swarm would be the user’s digital collectibles. The majority of NFTs are stored using IPFS, so there is a great opportunity to host this data on Swarm. Also, a profile picture saved publicly on Swarm (with the ENS), could also be an interesting campaign for users that are happy to be included in a decentralised directory of peers - this could be more relevant for brands, creators etc. (at this stage)

### Status Fork

The app will be a fork of the Status app, but a more trimmed-down version in relation to UI/UX. The fork will also need to have an ability to 'talk' to Swarm, in relation to NFT storage and potentially profile pictures. 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.

Ideally, this link would be written in Rust, but Python would be sufficient. The functions would need to ensure that users’ metadata/images from their NFTs are stored on Swarm, and subsequently displayed when a user selects. 

Currently Status is not compatible with Swarm, so this needs to be expanded. 


### Public/Private Chat Groups - Threads, Grafitti Wall

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.**

## 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. 

### Example 2

Glastonbury is a festival held yearly that attracts 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 users wallet/vault, reducing costs for the festival hosting the facility on their mobile app.  



### Private Keys

All users will have a private key. However, this is still an alien thing for the majority of users, 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.

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. 

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. i.e. mobile hosted nodes (online when using the application), dappnode forked device with a router for in the users home. *more details below in Nodes     

## 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).

### 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 fee built in to, will provide the funding needed to maintain and develop the ecosystem. Ultimately, in the long run, the community pays for itself.
#### Angel Round
These funds will be used to create a POC, then refine and develop the mobile app on the back of the Status fork. The aim would be to have a POC within 2-3 months and the mobile app and toolbox being developed in a 6 month period. The toolbox would initially start in a more basic and maybe more of a closed box to check certain elements work correctly. 
Initial funds being sought after would be $2,000,0000, which would represent a 3 year runway for the team. Token equity being offered for this investment would be circa 10% of total supply. The token price will also be circa 30% lower than the subsequent rounds. 
#### Seed & Community Round
This round would look to launch after a 2 year period and before funds run out EOY 3. It gives an opportunity for the platform to grow its community of advocates. Between the seed, community and launchpads circa 15% of the total supply will be available. 
It would be at this stage where work on the protocols that will underpin the ecosystem, will really begin. Depending on the community and demographic of users a focused approach regarding this, could prove successful when selecting markets to disrupt.


## Toolbox
Upload an media file (image or short video file); toolbox 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. 

## Nodes & Gateways


***