Blogpost: de-mls with Waku #159
Conversation
…anations of the MLS protocol, its decentralized adaptation, and Waku's pub-sub architecture. Included insights on key management, user roles, and the actor-based system design for message processing.
… structure by enhancing explanations of the MLS protocol, Waku's pub-sub architecture, and key management processes. Added sections on message distribution, user roles, and future work, while correcting terminology and formatting for better readability.
seemenkina
force-pushed
the
acz-de-mls
branch
from
1552ce8 to
230e4d9
Compare
…with Waku documentation. Added new sections on actor communication and cryptographic key management, along with a new image for better illustration of the architecture.
…treamlined actor responsibilities, and removed outdated code snippets. Focused on Waku integration and user/group actor functionalities for improved understanding.
rlog/2024-12-23-de-mls.mdx
Outdated
| One straightforward approach to SGM is a pairwise group chat, where each pair of group members establishes a unique encryption key using Diffie-Hellman. While this method ensures security, it falls short in terms of practicality: | ||
|
|
||
| - **High storage requirements**: Each participant must store encryption keys for every other participant. | ||
| - **Inefficient encryption**: Each message must be encrypted separately for every participant, leading to significant computational overhead. |
There was a problem hiding this comment.
And data, as each separately encrypted must then be sent over the wire, whatever this wire might be. Or stored in DB.
rlog/2024-12-23-de-mls.mdx
Outdated
|
|
||
| The Message Layer Security (MLS) protocol offers scalable and secure group messaging protocol by organizing participants into a cryptographic tree structure, enabling efficient operations like adding or removing members with logarithmic time complexity relative to the group size. MLS provides strong security guarantees, including FS and PCS. | ||
|
|
||
| MLS assumes that we have the two services are provided: |
There was a problem hiding this comment.
MLS assumes that two services are provided (grammar)
rlog/2024-12-23-de-mls.mdx
Outdated
|
|
||
| ### Waku | ||
|
|
||
| Waku is a peer-to-peer communication network designed to facilitate private, secure, and censorship-resistant communication by eliminating centralized intermediaries. Built on the Gossipsub protocol, Waku operates as a messaging layer where users join groups by subscribing to specific pub-sub topics. These topics define the scope and nature of the messages exchanged, allowing for adaptable communication patterns. The Waku network is composed of multiple interconnected Waku nodes. |
There was a problem hiding this comment.
Content topics, not pub sub topics.
Not sure "groups" here is the right name. "Channels" may be more appropriate.
There was a problem hiding this comment.
Id present Waku by saying routing layer is broadcast and content topics can be used to tag and filter messages.
There was a problem hiding this comment.
thanks, I'll fix misprinting and update Waku representation
rlog/2024-12-23-de-mls.mdx
Outdated
|
|
||
| de-MLS provides two different user management configurations, both utilizing the Waku protocol for DS: | ||
|
|
||
| 1. **Single Admin Over a Single Waku Node**: |
There was a problem hiding this comment.
Does the number of waku node matter?
There was a problem hiding this comment.
hm, you're right, I think it doesn't matter
rlog/2024-12-23-de-mls.mdx
Outdated
|
|
||
| ### Distribution of the Messages | ||
|
|
||
| Since the Waku is based on gossipsub protocol and accordingly from the network point of view joining a group for a user will look like subscribing to the necessary topics. |
There was a problem hiding this comment.
This is conflating concepts I think. Maybe best to ignore the gossipsub part and focus on content topics concept.
rlog/2024-12-23-de-mls.mdx
Outdated
| We have pub-sub topics that send messages in the network. We also have content topics, which determine the groups and what messages are sent. | ||
|
|
||
| There are three types of topics: | ||
| - `app_msg`: The owner of the topic where messages encrypted with the group key are sent, thanks to encryption, even if someone not from the group subscribes to the topic, they will not be able to read the correspondence itself. |
There was a problem hiding this comment.
Not sure I understand the concept of "owner of topic"
There was a problem hiding this comment.
I didn't phrase it correctly, thanks for seeing that, I'll correct it now
|
|
||
| We have pub-sub topics that send messages in the network. We also have content topics, which determine the groups and what messages are sent. | ||
|
|
||
| There are three types of topics: |
There was a problem hiding this comment.
I am guessing you propose to use 3 content topics per group?
We usually recommend using a single content topic, and optimize later.
But you can still define 3 message types for clarity purposes.
There was a problem hiding this comment.
yeah, I user group-id as application name and 3 types of different content topics to filter messages. My idea was that it would reduce unnecessary processing from the user's point of view and he could ignore messages from irrelevant topics (like welcome after he joined the group), but we can of course discuss a more authentic implementation later on
I also already have different message type inside topics
There was a problem hiding this comment.
Indeed. The rule of thumb here is to have the number of content topics match the filter use cases. Afaics all users in a group would always be subscribed to receive both app and commit messages and only temporarily to welcome? If so, ideally we'll have two content topics - one "all group" content topic for app and commit messages and a second for the welcome messages.
Having three types of topics specified here is perfectly fine, though. The above is an implementation detail that can be fine tuned.
There was a problem hiding this comment.
Update: in fact, it seems like multiple groups could perhaps share the same welcome content topic and then a single content topic for each group's app/commit messages. (Such implementation details may be out of scope for your post.)
There was a problem hiding this comment.
Update: in fact, it seems like multiple groups could perhaps share the same welcome content topic and then a single content topic for each group's app/commit messages. (Such implementation details may be out of scope for your post.)
I think it's only possible if there's only one admin for the groups
but yes, I think we can discuss this in detail later and how technically it will be organised in the end.
rlog/2024-12-23-de-mls.mdx
Outdated
| - `commit_msg`: All messages related to changes in the group state - adding users, deleting users, key rotation - are sent here. By design only administrators can send messages about the deletion and addition of users, key update is still under development. At this stage proposal and commit messages are not differentiated and all are considered commit messages | ||
| - `welcome`: A special topic for joining the group. With it, we solve the problem of how users can join a group without the server side. This topic is also used for providing the key packages by the users. | ||
|
|
||
| This architecture does not require a direct 1-to-1 channel with the admin for join requests. However, it does allow for the possibility that the admin can personally request a key package and manually add a member to the group. |
There was a problem hiding this comment.
Instead of "1-to-1 channel" which makes assumptions, i'd say that "join requests dont need an out of band secure channel, and are handled within the de-MLS DS layer"
|
|
||
| #### Communication between actors: WebSocket <-> Application <-> Waku | ||
|
|
||
| ** Websocket actor ** |
There was a problem hiding this comment.
Does the transport matter? Isnt it just the "app actor"?
There was a problem hiding this comment.
Do you mean web socket part?
There was a problem hiding this comment.
yes, I find the "websocket" part confusing
… Waku protocol, and group communication topics
|
|
||
| We have pub-sub topics that send messages in the network. We also have content topics, which determine the groups and what messages are sent. | ||
|
|
||
| There are three types of topics: |
There was a problem hiding this comment.
Indeed. The rule of thumb here is to have the number of content topics match the filter use cases. Afaics all users in a group would always be subscribed to receive both app and commit messages and only temporarily to welcome? If so, ideally we'll have two content topics - one "all group" content topic for app and commit messages and a second for the welcome messages.
Having three types of topics specified here is perfectly fine, though. The above is an implementation detail that can be fine tuned.
|
|
||
| - `Ethereum key` is used to authenticate the user via their private key, with the user's ID essentially functioning as their wallet address. Alternatively, this step can be replaced by any Web3 service that supports authorization. Therefore, all users in the group can be assured about the authenticity of the other users. | ||
| - `OpenMLS keys` is utilized for the reference implementation of de-MLS based on OpenMLS, which provides all necessary APIs to work with MLS such as creating and storing key packages. The ultimate goal is to leverage Ethereum accounts to manage all necessary keys for groups. However, since OpenMLS currently lacks support for Ethereum curve operations, these keys are temporarily linked through specification within the identity wallet rather than direct allocation. | ||
| - `Admin keys` is a constantly rotating key used in the welcome topic to securely receive key packages from users. |
There was a problem hiding this comment.
Might be worth describing how this key is distributed. Is the current admin public key simply broadcast periodically on the welcome topic?
There was a problem hiding this comment.
agree, I'll add more details
in a nutshell, it's a public key and a signature under it, and every epoch I generate a new one.
| 1. **On-chain consensus mechanisms**: Outsourcing consensus to a smart contract solution for transparent and immutable agreement. | ||
| 2. **Off-chain consensus mechanisms**: Utilizing off-chain consensus protocol to design efficient, decentralized protocols. | ||
|
|
||
| ### Waku Integration |
There was a problem hiding this comment.
In some sense de-MLS is a new "application" over Waku. That is, it defines new payloads that are encapsulated in Waku messages - for Welcome messages, commits, group messages, key packages, etc. It would be interesting to see a "wire protocol" at some point that explains how all of this is encoded into Waku payloads (or just a reference to a spec where the payloads are defined).
There was a problem hiding this comment.
Thank you so much, it really will be interesting to add
I little got lost while I was trying to figure out what to describe by code in general and missed this part
| The architecture is built on an actor-based model, enabling a focus on the processing of messages rather than the specifics of how messages are transmitted between different entities. | ||
| We will give a brief overview of the architecture and the main actors. Let's start with the actors which are provide all network communication: the `waku actor` and the `websocket actor`. | ||
|
|
||
| #### Communication between actors: WebSocket <-> Application <-> Waku |
There was a problem hiding this comment.
I have to admit that I'm a bit confused by this section and diagram :). It seems quite complex, but from a de-MLS perspective just describes an abstracted Waku actor responsible for subscribing/publishing to the necessary content topics and interfacing with the de-MLS application?
There was a problem hiding this comment.
I'm increasingly feeling like this section doesn't make sense for blogpost :)
Maybe only what you suggested above about description of how payload is formed and different types of messages for different topics will be enough as integration details
And this one looks like documentation for code
|
|
||
| We have pub-sub topics that send messages in the network. We also have content topics, which determine the groups and what messages are sent. | ||
|
|
||
| There are three types of topics: |
There was a problem hiding this comment.
Update: in fact, it seems like multiple groups could perhaps share the same welcome content topic and then a single content topic for each group's app/commit messages. (Such implementation details may be out of scope for your post.)
Co-authored-by: Hanno Cornelius <[email protected]>
No description provided.