-
Notifications
You must be signed in to change notification settings - Fork 23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature request: Constant-size hash for welcome message proto #812
Comments
Not sending the ratchet tree as part of the Welcome is definitely the way to go. I think having the ratchet tree in the Welcome really only works for small groups and allows for a simpler architecture. But as you see here, the trees, and therefore the Welcome messages get big pretty quickly. The general design for the flow with Welcome messages without the ratchet tree extension is as follows
The open question is how the invitee gets the ratchet tree. This is not defined in MLS and up to the implementation to define. There are different design that I can see
If you consider the tree sensitive information, or don't have another way to protect the API endpoint to download the ratchet tree, encrypting it with a key that is derived from the Note that the RFC mandates that "the client MUST download the tree before processing the Welcome". This is not entirely possible in practice though, because the client has to retrieve some information about the group in order to download the ratchet tree. This should be read as: process only the necessary parts of the Welcome before downloading the ratchet tree. Looking at the OpenMLS API I actually think we need to expose an new API to make any option work where the information about the ratchet tree is inside the Welcome message. Right now, OpenMLS is strict on this "MUST" and there's no way to get information from the Welcome message without a ratchet tree. I'll think about potential solutions for this. |
I opened openmls/openmls#1586 with an API. Let me know if you think that would work for you here. |
Thanks for the super fast response! Plan to dive into this head first tomorrow after finishing up the benchmarks |
Is your feature request related to a problem?
With the current
send_welcomes
function and associated proto, we quickly reach the gRPC limit which limits the amount of members we can invite at once without chunking first. Even with chunking, very large groups would hit this limit too.Increasing the gRPC limit is only a temporary solution, and not great anyway since sending large amounts of data over the wire isn't a great thing (this is in the range of 50-100MB a message).
Making this constant size would be a win for performance and scalability of groups.
Describe the solution to the problem
@richardhuaaa had great suggestions for a fix, namely Rich pointed out that these messages are so large because a full copy of the ratchet tree is included in each welcome message. For 800 members this comes out to
436092
bytes.Rich suggested to store the ratchet tree somewhere else, and only include the hash in the welcome. That would make the welcome message size constant and we would not have to worry about hitting the gRPC limits until much larger group sizes, at which point batching would come into play again.
joiner_secret
@franziskuskiefer would love your input on this!
Describe the uses cases for the feature
Additional details
Here's one of the original error messages:
The text was updated successfully, but these errors were encountered: