extend on-new-remote-conversation by the subconv ID#2997
Conversation
There was a problem hiding this comment.
Not a fan of encoding things with such ambiguity. It's a bit unintuitive that this maps to a sub-conversation if this value is present. Could we change this into a sum type instead?
There was a problem hiding this comment.
It is a sum type (Maybe). I'm not sure where the ambiguity is. We are using the same representation for events.
There was a problem hiding this comment.
The way we handled a need for a change like this before is to use the ConvOrSubConvId type instead of ConvId, and that type can carry either of the conv ID or the full subconv ID (maybe modulo the domain). This would be a change that affects the federation API beyond MLS, so I'd recommend a separate PR to develop just to change these types/API and then rebase the PR to mls on top of it.
There was a problem hiding this comment.
I'm still not sure what we are looking to achieve. What is the problem with the current representation?
There was a problem hiding this comment.
There's nothing wrong. It will get the job done. It's just not consistent with how it was done before, but maybe we shouldn't worry about it.
Another note: the way I did such a change before is to split the request type into two: one for Proteus (which doesn't feature subconversations) and one for MLS. It could be done here too.
There was a problem hiding this comment.
It would be the first commit in develop and the second in mls. This would require SubConversationStore in develop which doesn't exist there yet.
There was a problem hiding this comment.
It would be the first commit in
developand the second inmls. This would requireSubConversationStoreindevelopwhich doesn't exist there yet.
Unfortunately, the links lead to nowhere now (I suppose due to a rebase). The split of the message sending types that I was referring to was in PR #2925. There I didn't need the SubConversationStore effect, but your mileage might vary.
a41c4cd to
7ba795d
Compare
7ba795d to
e581d6d
Compare
e581d6d to
e62b2a4
Compare
e62b2a4 to
ba0b055
Compare
ba0b055 to
1f257a5
Compare
1f257a5 to
ddf3406
Compare
a1c7fc1 to
4701626
Compare
| pure (scMLSData sconv) | ||
|
|
||
| -- notify all backends that the subconversation has a new ID | ||
| let remotes = Set.fromList (map (void . rmId) (convRemoteMembers cnv)) |
There was a problem hiding this comment.
nit-pick: in other places we've used bucketRemote instead of Set.fromList
| -- TODO: only do this for new subconversations (i.e. Epoch 1) | ||
| -- call `on-new-remote-conversation` on all the remote backends involved in | ||
| -- the main conversation |
Co-authored-by: Stefan Matting <smatting@users.noreply.github.com>
When a subconversation is created, all backends involved in the main conversation need to be notified, so that they create a group ID → subconversation mapping. Otherwise, commits coming from clients on those backends cannot be routed.
Similarly, when a user from a new backend B joins a conversation containing non-empty subconversations, it needs to be informed of those subconversations, so that (external) commits for those subconversations coming from clients in B can be routed.
https://wearezeta.atlassian.net/browse/FS-1451
TODO
on-new-remote-conversationandon-new-remote-subconversationon-new-remote-subconversationwhen a new subconversation is createdon-new-remote-subconversationfor all existing subconversations when a new backend gets involvedon-new-remote-subconversationwhen a subconversation is resetexecuteProposalActioninto one function for conversations and one for subconversationsChecklist
changelog.d