The state of decentralized messaging in Polkadot/Substrate

1

Context & Preface

Hello everyone,

I’d like to open the floor to discussing, gathering feedback on, and overall hammering out a core part of the web3 application stack:

Decentralized Messaging.

Specifically, I would like to discuss the following points:

  • The state of decentralized / web3 messaging.
  • What is currently being done.
  • My current approach / implementations of decentralized communication.
  • Interoperability, security, & scaling.
  • Crossroads with identity and desybiling issues.

The purpose of this thread is to get feedback for and discuss not just my personal project, but this topic as a whole. There is only so much I can tinker around with - which is why I need some brutally honest, constructive criticism in the hopes of making insurmountable amounts of progress around this topic this year!

Personal Project History & Current Status

I am no stranger to this topic. In fact, my first exposure into Substrate and Polkadot was through a Web3 Foundation Grant regarding a proof-of-concept Substrate-based messenger. It was called Uke, a p2p messenger that uses just Substrate to manage conversations and send messages between users. If you would like to view more technical details, I recommend reading that proposal, as I’d like to keep this post as concise as possible.

1180×1226 146 KB

Initial mockups for uke.

It’s still live in this PoC stage for anyone to test as of the writing of this post over at: app.uke.chat.

This proof of concept allowed for a few key points to be demonstrated:

  • It was possible to have a backend for a traditional webapp based completely on Substrate, and nothing else.

  • A very crude form of “local authentication” was demonstrated here - with the identity being linked directly to the user’s account. This has obvious security issues, and should not be used in any sort of production setting, but for a PoC it works fine.

  • A dead simple identity system - leaves a lot to be desired, but allowed for users to have crucial public metadata available.

This sort of application is not far off to a real, scalable implementation. With some topology changes, as well as progression in other areas such as identity and de-sybling tactics, it becomes very possible to use in a real world application.

Initial Goals & Expectations

I had some initial goals and exceptions for Uke as a project, summarized below:

  • Obviously, no backend or intermediary servers. Everything is purely based off of Substrate, or other p2p layers.

  • In our designs, the use of DLT/blockchain is not shown - this is intentional, as it allows users to merely experience a secure messaging experience without the cumbersome interface. The end goal is to have this be as non-intrusive from a UI/UX perspective as possible.

  • It’s well known that popular messaging apps like Whatsapp have had a few major security incidents. Trusting “end-to-end” encryption, without actually seeing how that takes place has also proven harmful!

  • In the future, as the protocol becomes more defined, the goal is to develop a suite of SDKs and docs centering around secure and confidential messaging for any use case - with a Substrate-based chain being the core of the solution.

  • The primary goal for Uke is to allow for the development of a messaging protocol that does not require trust to use. All processes, from sign up, to identification, to the act of sending a message should be very transparent in how it works, whilst preserving the privacy of the user.

  • Privacy - each message sent is completely, and purely, peer to peer - no one else could access the message.

  • Fault Tolerance / Reliability - By using DLT, we remove the need for a central server, meaning as long as an amount of nodes are kept online, users can still talk to one another. This is especially useful in emergency scenarios.

  • Anonymity - since each user is essentially just a cryptographic key paired with an id, user’s can easily stay anonymous on and off chain if they so wish to choose.

Problems With Current Implementation

The current implementation works - but it does a few things which after learning more, give me a certain ick:

  • All messages are sent as transactions. While for a blockchain application this may seem obvious, presents some next-to-obvious scaling and usability issues:

    • A high volume of messages may result in network slowdown at some point, i.e disrupting the block authoring process or introducing a significant amount of latency on the UX side when it comes to message delivery.

    • Each transaction being a signed extrinsic implies a private key having to be available for the duration of a conversation. From a UX point of view, this is unideal.

  • Message storage, arguably, should not occur on-chain. The chain should only be responsible for handling access control, identity, and for facilitating conversation logic. Message transmission, delivery, and storage should occur in an off-chain process.

  • There are no mechanisms to ‘de-sybil’ users, and currently, the network is spammable as a result of this. There are several ways to mitigate this, but I’ll leave that for discussion :wink:

  • Identity is still mostly undefined. What should identity look like in this context?

  • No real form of authentication - everything is dependent on a single private key, which could prove quite harmful.

I’d like to pose this question to the reader:

What should decentralized messaging look like? How could we create a common communication protocol that could thrive in a trustless enviroment? Is it something like uke, or is it completely different?

As I garner more research on this topic, I will update it as needed. I already have some interesting prospects that should solve a good chunk of the problems outlined above, so stay tuned!

6 Likes
2

Interesting post - lots of good stuff.

There are a couple of initiatives underway that I’m aware of including @olanod’s matrix/substrate work which was recently funded by the Kusama treasury and Sumi Network’s wallet to wallet messaging.

2 Likes
3

@rich

Sumi looks really interesting. I just saw a demo the other day where access to who you could message was based off of which tokens you owned, effectively making a sybil or spam attack worthless (to my understanding). I think staking/locking tokens as part of being a part of a communication network could be a good solution (for now) as far as de-sybling users goes.

Could you link the Matrix/Substrate work? I’d be keen to read more!

4

Sorry thought i’d added link - here’s the virto team led by @olanod

2 Likes
5

Previous work like Whisper or waku, its continuation by Status, should be helpful here.

I worked on Whisper in 2016/17 and there are a number of issues to juggle:

  • Creating large anonymity sets without overwhelming the system with traffic, including effective cover traffic
  • de-correlation of hops within the network without a predetermined route is difficult - with a known route you can employ onion-style encryption where the message sent along each hop is different.
  • Rewarding message propagation while distinguishing useful traffic from non-useful traffic meant to game the rewards system.

Using the blockchain as a reliable broadcast system has its weaknesses as well as strengths. The overwhelming weaknesses are that it doesn’t scale well to billions of messages per day (WhatsApp scale) and that latency is poor.

The scope of Whisper was initially even larger than just human-to-human messaging. It was meant to be used in an automated fashion as an initial communication/commitment layer for decentralized applications. This goal is still worth pursuing, IMO.

4 Likes
6

you could use GM chain to integrate against. this way you have less trouble with spamming the relay chain; and a lot of innovation-friendly people on GM chain would be happy to test it out.

2 Likes
7

Nice project and thread. We also have been looking into this as our app already has centralised messaging which is not ideal, but it does serve a purpose.

We were considering encryption as a means to privacy without necessarily using your own private key for encryption. Instead you can use ephemeral (throwaway) private keys rather than your own to send messages, as long as you include the associated public key and nonce with it so it can be decrypted by the recipient. You would only need your private key for decrypting messages sent to you using that same method.

Where this falls over however is that (last time I looked) there are no good cryptographic privacy solutions for group chats. Perhaps you are aware of some solutions to this?

1 Like
8

Waku is publishing some interesting innovations, namely:

In 2022 I started a Rust implementation to learn more about the protocol.
I got the core RFCs working but I’m not actively developing it anymore, so it’s quite limited. But it was a fun learning experience!

Anyone looking for a production-ready Rusty Waku should look into the Rust bindings from the official Golang implementation instead.

Mixnets are also bleeding edge tech on this context, with a broader application scope than only human-to-human messaging.

NYM is probably the most mature implementation of a Loopix/Sphinx-based Mixnet out there. I did some experimentations with it recently and it looks quite exciting!

NYM has a blockchain built on Cosmos (called NYX) that allows for incentivization of their Mixnode infrastructure.

Parity is also working on a Rust Mixnet implementation, with a limited scope of:

  1. Anonymous delivery of blockchain transactions from end-users to validators.
  2. SASSAFRAS consensus protocol. Network level anonymity is required for submitting tickets.
3 Likes
9

As a follow up to my previous message, I have this idea on the back of my head that I’d love to see coming true some day:

A common goods parachain that uses DOT to incentivize a decentralized messaging protocol (e.g.: Waku or Mixnet).

1 Like
10

As a general update to some weekend rabbit-holing / research,

as @bernardoaraujor just expressed - mixnets are something I think has great merit for this particular application. Not only for human communication, but as a general method for creating generic, yet context-specific ways for consensus, or even XCM-related network traffic. An example of this would be to provide a different mix strategy for different types of traffic within a node, whether it’s pallet specific (something used for messaging) or network level.

I think a common problem isn’t really how to do messaging, the following (rather glaring!) issues immediately stand out to me:

  • Even before using something like Waku or Whisper to be the transport layer for a common-goods communication chain, there is no reliable way (to my knowledge) to combine one of these protocols with Substrate in a homogeneous way.

  • There has to be a way to de-sybil users without the need for a high barrier of entry, both from an adoption/UX standpoint as well as price. The most obvious and naive solution right now is to ensure they can reserve or lock some balance before taking action within the chain.

In regards to the first point, I’ve been doing a lot of research around how a session-based, trustless authentication scheme with Substrate might look like. Essentially, Substrate could be used as the gateway to other external processes without being directly involved. This would solve a couple problems:

  • External services, whether they be off-chain workers or something completely external, could be authenticated via a set of rules before a user can access it.

  • Users can authenticate in a more natural “web2 manner”, but using cryptographic and Substrate-backed primitives.

  • Only crucial points of interest would actually be included in the state of chain - i.e, when a user accessed a service, and the state of that user upon accessing that service.

I would love to see some thoughts on this, as I think it’s important to delegate any heavy lifting (especially in an application like this) to something external rather than burden consensus with it. Once we have this building block, then we could potentially look into creating context-driven mixnets for anything we want :wink:

11

I’ll add more context and history here about our Substrate meets Matrix initiative, a.k.a. Summa since the proposal doesn’t describe it very deeply. The integration might not be in the ways you’d expect as the reasons that lead me to use Matrix were not so much about the messaging but more related to the need of solving UX issues of live products and being a lazy dev who doesn’t want to work on things that others are solving already.

I first started to look into Matrix when working on decentralizing an on&off ramps system for a startup with an existing product in Latam with a high censorship risk from the government. I had recently “acquired” this new fancy tool Substrate and like many people with a new tool you just want to use everywhere, so we proceeded to implement the whole protocol on-chain, but then when it came to integrate it in the existing product and deal with real users expectations I realized how far this stuff was from actually working in a real life scenario.
Signing and submitting transactions for every user interaction is not what you want to do, say I need to upload the photo of an invoice to convince you to release an escrow but then I need to do it several times because I made a mistake or the photo was blurry, going through the global consensus system of the blockchain every time becomes heavy, expensive, clumsy, etc. This kind of interactions didn’t really need consensus(I’d say most things don’t really need it), so I trashed the design and as I was familiar with Matrix I proceeded to create the protocol in a more generalized way on top of the encrypted rooms leaving the blockchain only for the escrow.

Matrix rooms are an interesting companion to a global consensus system, based on the previous premise, if we want to leave the blockchain for only the “important stuff” where do you put the rest? With Matrix you get a decentralized event storage partitioned by rooms that are Directed Acyclic Graphs that are replicated across every server participating in a “conversation” with a guarantee of eventual consistency of the data, messages don’t have to be chat messages, they can be anything and there’s also a room and per user state you can update, a nice and quite generic system to build all sorts of decentralized applications with a lot of batteries included that scales well :heart: e.g. my handicraft shop doesn’t have to spam everyone in the network with the color update preferences of a customer, those updates might not need to even leave mine and my customer’s homeserver.
One extra sauce we are adding is to pack the homeserver together with a WASM runtime where we can launch several light nodes or run other bits of custom logic so users can have a single easy to deploy binary that becomes their personal decentralized cloud. Having the ability to upload WASM blobs to rooms that change some state is like having mini blockchains, the room specific state transition functions are like an evolution of chat bots that could be validated by a blockchain and become a “L2-like” solution… eventually.

As I mentioned initially, UX was the main reason to look into the Matrix/Substrate love story, the main offenders IMO are wallets and how to deal with private keys in a transparent way, something I think the Matrix ecosystem has been solving quite well for a while, you can register/login with traditional means(e.g. just a fingerprint touch to register your WebAuthN device in an OpenIDConnect server integrated with your homeserver), the MatrixID is a simple handle that can be shared around easily, you can have multiple devices each with their own private keys, you get a secure secret storage out of the box and the ability to send secrets directly to another device and so on. There are several ways to leverage those features, for example our MVP uses the secure secret storage or the ability to share secrets to directly between devices to share the secret that becomes(with some extra steps) your blockchain account(later we’ll likely use multi-party signatures) resulting in users not faced with any “blockchainy quirk”, user discovery is built-in, open a room with a user you find by their MXID and automatically exchange your blockchain address in the encrypted chat(no need to link identity in the blockchain) and those are just a few examples.

Summa in the proposal might refer to the homeserver implementation but it is actually not a concrete thing, it’s more this idea to bring the ecosystems closer together. We have more ideas on how to create more integration points that could benefit the Polkadot ecosystem through the use of specialized pallets, sharing cryptographic primitives or lower level components like the networking stack but those will have to come later. In the meantime I encourage people have a deeper look at Matrix, it’s a nice decentralized protocol with a great community, it might not be at the level of decentralization or use of bleeding edge tech that many people in the blockchain space crave but it evolves fast(e.g. P2P, portable identities, Rust usage, etc.) and its moving in a direction very align with Web3’s ideals.
BTW check Wei’s discussion about funding the Matrix.org foundation as we already rely heavily on the protocol for our communications :slight_smile:

1 Like
12

Thank you @olanod for this insight - I had a good read through the proposal, and this response really tied it all together.

I think this is gold. A big problem, as you mentioned, is somehow combining the functionalities of external services / protocols with blockchain in a seamless way. In other words, blockchain becomes the governing body, while services flourish and use this governing body as needed for users accessing the service.

This approach kind of reminds me of PVFs with how parachains and relaychains agree on how to change state. Very excited to see this progress!

13

I work on the parachain Frequency (frequency.xyz) and a protocol on it: DSNP (dsnp.org).

Most blockchain based systems quickly have issues of metadata privacy due to the nature of the public blockchain. It isn’t implemented yet, but the DSNP whitepaper has a blockchain-based, metadata-private messaging system that was somewhat inspired by Whisper (mentioned above).

I’m not sure when it will be live on Frequency, as the focus is on getting Graph connections live first, but here’s the tldr of how it works.

  • Sender is never private, the recipient always is
  • The message is targeted not to the recipient, but to a deterministically derived Dead Drop Id using the shared secret of a key exchange between the sender and receiver (and a different one when the roles are reversed).
  • Given that the receiver knows that the sender is trying to send a message (thus why graph is important first), the recipient derives the Dead Drop Id and then looks for messages labeled with that Dead Drop Id.
  • For additional privacy a nonce can be applied so that no two messages are ever set to the same address (although that increases the work of the recipient)

Frequency uses a delegation/rollup system to support the volume of messages that would be sent on a messaging system at scale as well as a renewable economic system so users or their delegates do not need to continuously pay out for messages.

Anyway interested to see the others working in this space as well!

3 Likes
14

I’m afraid this grew long, but messaging winds up pretty orthogonal to blockchain concerns. I’ll address sassafras first thoug.

Sasssafras needs only a single hop proxy for submitting tickets, not a mixnet. In fact, mixnets would be worse in sassafras, unless you use the mixnet very carefully.

We do need some messaging platform to remove the memepool from sassafras parachains, which saves some CPU, and permits many fancy AMMs MPCs, etc. We could kinda ignore the messaging side here, and focus upon the straight mixnet, but really I’d say simplify by adopting Tor, preferably via Arti. We’d ideally obtain tresury support for Arti and a support contract from Tor during integration.

I’d expect sassafras benefits more from Tor than mixnets anyways, meaning users can negotiate live with the anonymous collator before it makes its block, which enables fancier MPC, AMMs, etc.

We envisioned doing mixnet work from the Web 3 Foundation early on, which resulted in hires, like Fatemeh and myself. We then used those mixnet hires doing polkadot itself, mostly because scalable blockchains are brand new theoretically, which makes them relatively fun design wise, while mixnets were worked over for decades, so mostly they consist of less fun real problem.

Afaik, there are two serious mixnet code bases right now, Nym (Rust) and Katzenpost (Go). Internally, the initial mixnet attempt by some folks at Parity Labs looked kinda atrotious, like no SURBs etc, but later David Emmit at Parity Labs improved this code dramatically. I’ve donno how the Nym vs Parity Labs code bases compare right now, but…

In Nym, there are several really wrong headed ideas, like streaming over a mixnet, probably dictated by VCs, and which Katzenpost always critisizes. You should not pull a “not invented here” by discounting Nym’s code, and adopting the Parity Labs code, because Nym had really good devs polishing it for ages. You should read Nym’s code if interested in mixnets.

Katzenpost had their own ugly “not invented here” moment early, by building overly complex lower level networking. At the same time, libp2p is full of dumb privacy footguns, so maybe best avoided entirely. I’d read the Arti code before doing anything myself.

I’ve an old unfinished tech report at lake/Xolotl/papers at master · burdges/lake · GitHub which answers many high level questions about mixnet packet formats, but many footguns were not discussed there, like the sphinx packet padding bugs everyone hits.

Axolotl or post-quantum flavors remains kind for one-on-one end-to-end encrypted messagingm, but even one-on-one messaging benefits form group messaign these days, which adds massive complexity, and sucks for mixnets

Messaging Layer Security (MLS) has occupied most serious end-to-end encrypted messaging people for half a decade, meaning it addresses far more niche group messaging concerns than anything else. At this point, one must understand what the MLS team did before one even considers designing an end-to-end encrypted messaging protocol, so ideally hire one of them.

We’ve one problem here however: MLS was designed for centralized messangers like Signal, WhatsApp, Wire, etc. I think Matrix partially adapted MLS to federation, but only after considerable effort. We’ve much design work to integrate some flavor of MLS with mixnets.

Alongside MLS, we should handle badly out-of-order message delivery, which likely breaks many things, certianly in MLS, but also in the underlying messaging data model.

As a start on the data model side, we should look into messaging data that’re CRDTs or similar, not necessarily to dictate one answer, but merely to have one good answer. Automerge exists, but the focus upon JSON looks miss-guided.

Interestingly, Pijul is a powerful CRDT that’d handle almost anything, but with power comes complexity. Afaik pijul never fixed this major vulnerability. It’s easy to fix if you abandon shallow clones, but maybe not great for messaging. I’d expect more work on shallow clones in general there.

Identity feels mostly unrealted to messaging, since mixnets do not necessarily need to de-sybil users.

Identity sounds more pressing politically, since the whole world wants fake-private attribute-based schemes, or moronic totally non-private self-soverign identites, or worse. See Digital Identity and Digital Euro (CCCCamp) and Please Identify Yourself (37c3) by Thomas Lohninger & Udbhav Tiwari. In fact, we know almost exactly what makes sense here:

You register a public key into a zk merkle tree on a blockchain, which you deduplicate using zk proofs of government identity documents. After this, you never touch attributes etc but merely prove uniquness using ring VRFs based upon zk continuations that read the on-chain zk merkle tree. We’re going to build this, but we researchers are slow so feel free to help out.

1 Like