chore: bump de-mls and adapt group_v2 to the new API#153
Conversation
jazzz
left a comment
jazzz
left a comment
There was a problem hiding this comment.
Overall loving this direction. Smaller, cleaner, and easier to use.
| fn make_consensus() -> DefaultConsensusPlugin { | ||
| DefaultConsensusPlugin::new(EthereumConsensusSigner::new(PrivateKeySigner::random())) |
There was a problem hiding this comment.
[?] In the future should the consensus signer match the MLS Signer? Or is it best to keep it separate?
There was a problem hiding this comment.
Any signer that implement this trait: https://github.com/vacp2p/hashgraph-like-consensus/blob/48da54131328bb66a8f08dd3bf69c2727161f5d4/src/signing.rs#L46
| fn make_consensus() -> DefaultConsensusPlugin { | ||
| DefaultConsensusPlugin::new(EthereumConsensusSigner::new(PrivateKeySigner::random())) |
There was a problem hiding this comment.
[?] It is safe to assume in the future that any implementor of ConsensusSignatureScheme would suffice here? Or is there a strict dependence on secp256K1 or the ethAddress format?
There was a problem hiding this comment.
No strict dependency anymore. At least I tried implementing general trait based on this idea, so if you find any contradictions let me know
2 participants
Updates group_v2 to the latest de-mls.
de-mls reshaped its construction surface: key packages are now raw bytes plus an explicit member id (it no longer digs the id out of the package itself), the steward-list bounds moved into ConversationConfig, and create/join/add_member and the other driving methods regrouped their parameters.
Behaviour is unchanged; this is keeping up with the dependency.