Implementation of server_remove proposal
#280
Conversation
emarteca
changed the title
server_remove proposal
| self_remove_proposal = [] | ||
| server_remove_proposal = [] |
There was a problem hiding this comment.
Should there be just a GSMA feature?
There was a problem hiding this comment.
Yes, that is a good idea.
| pub async fn propose_server_remove( | ||
| &mut self, | ||
| index: u32, | ||
| authenticated_data: Vec<u8>, | ||
| ) -> Result<MlsMessage, MlsError> { | ||
| let proposal = self.server_remove_proposal(index)?; | ||
| self.proposal_message(proposal, authenticated_data).await | ||
| } | ||
|
|
||
| #[cfg(feature = "server_remove_proposal")] | ||
| #[cfg_attr(feature = "ffi", safer_ffi_gen::safer_ffi_gen_ignore)] | ||
| fn server_remove_proposal(&self, index: u32) -> Result<Proposal, MlsError> { | ||
| let leaf_index = LeafIndex(index); | ||
|
|
||
| // Verify that this leaf is actually in the tree | ||
| self.current_epoch_tree().get_leaf_node(leaf_index)?; | ||
|
|
||
| Ok(Proposal::ServerRemove(ServerRemoveProposal { | ||
| to_remove: leaf_index, | ||
| })) |
There was a problem hiding this comment.
If it's a server remove, why does the client code need to be able to generate it?
There was a problem hiding this comment.
So the logic flow is a bit odd; but in this model the server is not generating the proposal. Rather, the server signals to the client that the client should remove a member, and then the client has to create the proposal. It's more of a "server said to remove" remove proposal
| fn filter_out_server_remove_if_remove_same_leaf( | ||
| strategy: FilterStrategy, | ||
| mut proposals: ProposalBundle, | ||
| ) -> Result<ProposalBundle, MlsError> { |
There was a problem hiding this comment.
That shouldn't happen, no? Server cannot have a leaf or be a committer?
|
Thanks for the comments, and (like on my other PR), so sorry for the delay in response! To answer your questions:
I'll followup with code changes soon, thanks again! |
Implementation of the server_remove proposal, corresponding to section 7.11.9 of the GSMA RCS spec.
This proposal represents removal prompted by the server. A group member must still both propose and commit it (since the server is not a group member), but it signals that the removal was requested by the server.
The server_remove is a proposal that has the following properties:
It effectively has all of the same properties and behaves identically to the existing
Removeproposal, except that multiple of them can be committed externally.