An Open Communication Layer For Polkadot

Currently, communication in the Polkadot ecosystem is not only largely stuck in Web2, but it is siloed and segregated. Governance discussions take place off-chain, projects have to rely on Discord and Telegram to interact with their communities, and suboptimal solutions are implemented for connecting these Web2 accounts to users’ Web3 accounts. Furthermore, by forcing communities to live off-chain, user engagement with dapps is lowered.

At Subsocial, we spent three months researching the needs of the ecosystem, and began implementing the foundation for Polkadot’s Open Communication Layer. We realized that, although Web3 communities, and their communications, should be moved on-chain, there was too much friction with actually using a blockchain for this.

To address this problem, we created Grill.chat as a proof of concept for OpenComm, showing how easy it is for users to start communicating on-chain. The onboarding process is even faster than Web2 apps that we are used to, as you don’t even have to create an account; you just send your first message and an account is automatically generated for you.

Grill.chat takes advantage of our Energy and Off-Chain Signer systems to allow users to communicate on-chain without needing to acquire tokens, install a wallet, or constantly sign transactions. Effectively, it is a user experience on par with what we know in Web2.

These features are not specific to our Grill.chat application; they form the basis for the OpenComm layer. Already, we have other projects working to integrate OpenComm based social features into their applications, and more interested teams lined up:

  • Astar
  • Kodadot
  • Moonsama
  • Zeitgest
  • Polkassembly
  • RMRK
  • Ternoa
  • Imbue

But what exactly does Open Communication mean? Perhaps the best example to look at is Polkadot’s governance discussions. The two main platforms are Polkassembly and Subsquare, however, you cannot find governance discussions from Subsquare on Polkassembly, because Subsquare is a closed platform. When dealing with the governance process of a blockchain, it just doesn’t make sense to have closed discussions.

With OpenComm, all governance discussions will take place on-chain, and the content and messages will be freely accessible by anyone. This means we could have ten different governance platforms, all connected to the OpenComm social layer, allowing anyone to access the full breadth of Polkadot’s governance discussions, despite their UI/UX preference.

This can be expanded to any project in the ecosystem, and does not apply to just governance discussions. NFT fans could discuss a specific NFT on Singular or Kodadot, accessing a single unified chat from different applications. Sports betters could anonymously discuss Zeitgeist prediction markets on-chain, directly from the PM webpage.

Perhaps you open a particular trading pair on a DEX, and see someone say that specific token is a good buy. Because the chat is on-chain, you can quickly check the account of the poster to view their trading history and see if they know what they are talking about.

I’ll avoid going into too much more detail here, as we have a proposal that will be going live soon, with all of the details on OpenComm, including a problem statement, why Polkadot needs OpenComm, and more. We will be posting a slightly modified version on-chain for discussion in the coming days.

If you have any feedback please let us know, and if you are interested in adding social features to your dapp, please get in contact with us.

5 Likes

I think the app is really slick, and indeed the onboarding is as frictionless as I have seen for anything in Web2 or Web3.

My question is more technical: how does it scale?

You mention in the proposal and above that the messages are stored “on-chain”.

It seems you have launched a new chain for this (xSocial), and are using “Web3 Bucket Storage tech” (is there more docs on this?).

But ultimately, if the chat is being stored somewhere, then it costs someone, somewhere money to host those messages.

What currently prevents sybil attacks against this platform?

Otherwise, love the initiative.

3 Likes

I fear that all you might achieve is fragment the discussions even more by creating a 15th platform of discussion competing with the other existing 14 platforms.

The only way to give an official status to a platform of discussion, and thus make it supersede the others, is for the discussions to happen on chain.

2 Likes

I agree that storing conversations on-chain is the main prerequisite to making them available to the community to contribute and benefit from, unlike the siloed web2 comments.

However, it’s not merely about imposing a standard, but rather expediency for the participating projects. Dapps that add Grill actually improve their user engagement (hey, I can discuss a bet), retention (what did they think about my idea), and overall UX (wow, social trading).

The network effect of a truly open communication layer would only come after initial adoption, but can be really powerful when kept web3 native. For example, on-chain objects can be tagged, embedded, and linked in discussions to provide further context and actions with them.

If the ecosystem owns the initiative, both projects and users win by capitalizing on the on-chain architecture and extending interconnected discussions throughout.

I really like it, perhaps I am biased because a messaging app is the first thing I built on Substrate. It had very similar goals to Grill, and I am happy to see this problem being tackled! The UX is super nice as well, a nice change to see in the web3 space.

That being said, while developing Uke, there were many questions around:

  • Scalability - how does one scale a messaging service to the point of something like Whatsapp (around 2b active users) without sacrificing scalability? This means block space must be utilized in a manner that matters. I could go deeper into the technical implications of how this may go, but I digress for now.

    • As a sub-point, spam prevention could also be a concern. Would the architecture (or more importantly, the underlying chain impl) suffer from a performance standpoint if someone attempted to fill the network with ‘useless’ messages?
  • Storage - where is data going? Who gets to view this data? Does the user have control over this data, and where it is stored? Who is paying for this storage?

  • Security - is encryption implemented? From a privacy standpoint, what is being done?

an account is automatically generated for you.

As @shawntabrizi mentioned, this could open the door for sybil attacks. Especially in the age of AI and GPT language models, how easy would it be for me to create a script to generate accounts that talk in favor of a particular proposal? Is there any deposit involved in?

Again, I love the effort, and all the best!

I am unsure of the specifics of how grill chat will solve the governance fragmentation issue that is present in the ecosystem but as a retail user of Polkadot, i can whole-heartedly get behind any team/platform that aims to aggregate and solve this problem.

It is incredibly difficult in current state to see all of the ecosystem projects governance forums in one place and i think this leads to lack of clarity as well as encourages lack of participation from communities wishing to see their projects work together to tackle problems.

I have used grill chat and it is a cool product with a very easy to use design and if this could be safely used to replace or aggregate the other governance platforms then it 100% should.

Cohesion is something that only polkadot truly offers and i am a proponent of any team working to increase cohesion throughout the ecosystem.

1 Like

> It seems you have launched a new chain for this (xSocial), and are using “Web3 Bucket Storage tech” (is there more docs on this?).

Yes, we have launched xSocial as an experimental network for testing the concept. In the future, we plan to migrate to Subsocial Polkadot Parachain. However, there are a few additional things we need to implement before for real-time interaction.

Regarding Web3 Bucket Storage, it is a product developed by Crust. You can find the documentation here

> But ultimately, if the chat is being stored somewhere, then it costs someone, somewhere money to host those messages.

Currently, we are sponsoring all users. When we migrate to Subsocial, we hope that projects will sponsor communication for their chats. Additionally, we will be developing offchain posting with backup to the blockchain, which will be included in the next milestones.

Furthermore, we envision that each user will be able to register their own Web3Bucket and store all their data in their own IPFS Bucket.

> What currently prevents sybil attacks against this platform?

Dapps implementing this can set their own requirements, for example, only sponsoring tx from accounts that have met the existential deposit requirement for DOT, or that have a certain NFT, etc.

1 Like

Here are some paragraphs addressing the concerns brought up, which will be included along with the proposal once we go on-chain.

Scaling: Any potential scaling problems caused by OpenComm pale in comparison to the scale required to support the social networks of the future, which we believe that Subsocial will be able to support, through a combination of off-chain rollups, layer 2s, and the eventual possibility of turning Subsocial into a relay-chain supporting 100 chains focused on processing Web3 social transactions.

xSocial: OpenComm currently runs on xSocial, an experimental network that we launched for testing the concept (similar to launching a parachain on Kusama). In the future we will be migrating it to our Polkadot parachain, but we need to implement a few things before that in order to better facilitate real-time interactions.

Storage: Message contents are stored on IPFS, and the CID is pinned on-chain. We are using Crust Network for pinning content to IPFS, by putting it all inside of a pre-paid Web3 Bucket. We think that in the future, if desired, any and every user will be able to register their own Web3 Bucket to store their data and retain full ownership of it.

Fees: Subsocial transaction fees are currently sponsored by us, and when we migrate to Subsocial’s parachain, we hope projects that have OpenComm implementations will sponsor communications for their chats. Fees are miniscule, and can be further decreased by on-chain governance via the energy coefficient. Currently, 1 SUB converted into 1 energy enables 250 transactions. We will be developing off-chain posting with batch backups to the blockchain, which will be included in future milestones, to further reduce fees.

Sybil Resistance: OpenComm implementations can set filters for which transactions they want to sponsor. Requirements could include meeting the existential deposit requirement for DOT, having a certain NFT, or having voted in a certain number of on-chain referenda. These measures can also work to prevent spam, in addition to the client-side moderation tools that make up part of this proposal.

Encryption: As it currently stands, OpenComm is entirely open and transparent. This means that all messages are openly visible. If you wish to be recognized as the author of a message, you may post it from an account with an existing identity, otherwise, you can post anonymously. In summary, access to viewing messages is open, but access to writing messages may be closed, depending on the application being used.

Standards: Someone suggested that this proposal will simply create another standard, but we think that is an apples to oranges comparison. OpenComm is not a standard, but an open, on-chain platform that is usable by anyone and anything. Rather than destroy the existing standards, OpenComm will allow them to interact. Also, we can easily build bridges for popular messaging apps like Telegram and Discord to further prevent fragmentation.

2 Likes

Yung Beef was on AAG on May 15 to discuss this proposal.
Watch the clip (5:30) :point_down:

2 Likes

Dumb question but if fees are miniscule, what is the revenue/business model for sustaining the development of the project now and into the future whilst ensuring incentives remain aligned with the protocol and users?

Miniscule fees times a trillion results in a lot of fees, plus we will start inflation at some point which will support the treasury (among other things).

1 Like

Our referenda is now live on-chain: https://kusama.polkassembly.io/referenda/198

You can also consider other Parachains to help with some sybil resistance. That would be proof of personhood. This could help with creating some, ensuring that those individuals are not the same person with multiple accounts.

@brenzi Maybe this is an interesting discussion for your project and bring some personhood up in here.

Again, you can also introduce some identity solutions. That brings me to the idea of using KILT Protocol to enhance the user’s profile.

This is only my two cents.

Yes, sybil-resilience is exactly what Encointer is aiming to provide for our ecosystem. However, for the case of Polkadot governance, we need to be aware that most voters have no Encointer community in their vicinity, currently. And Encointer communities can only grow organically and with dedication of many groups of people that live close by.

But we do have new ideas how Encointer could help with medium-security sybil-defense on a global level:

tl;dr:
People with (highly secure) reputation in an Encointer community can vouch for people they know or meet, phyisically or virtually (including a Turing test). Like this, people all over the globe can be easilly verified (with medium-security only). In a way, this combines the ideas of Encointer and BrightID

Such a (weaker) sybil-resilience is still stronger than linking token balances to posts, because it is super easy and quick to spilt your funds to 100 accounts and fake sentiment, but not that easy to get vouched 100 times by real humans.

Where I can get list of those people? I would love to spread Encointer experiment in SubWork area.

@yangwao DMed you to talk

1 Like