mirror of
https://github.com/vacp2p/de-mls.git
synced 2026-01-08 21:17:56 -05:00
4ea1136012
* chore: implement consensus mechanism - Updated `Cargo.lock` - Refactored `Cargo.toml` - Enhanced `action_handlers.rs` to introduce a ban request feature, allowing users to send ban requests through Waku. - Implemented a new consensus module to manage proposal and voting processes, including state transitions for steward epochs. - Updated error handling in `error.rs` to accommodate new consensus-related errors. - Refactored `group.rs` and `user_actor.rs` to integrate the new consensus logic and improve state management. - Added tests for the consensus mechanism to ensure reliability and correctness of the voting process. * chore: update dependencies and refactor code for clarity * refactor: update voting mechanism and clean up user actor logic - Changed the return type of `complete_voting_for_steward` to return a vector of messages instead of a boolean. - Removed unused request types and their implementations related to proposal handling. - Updated the `handle_steward_flow_per_epoch` function to reflect changes in the voting process and improved logging. - Refactored tests to align with the new voting mechanism and ensure proper message handling. - Enhanced consensus logic to better handle vote counting and state transitions. * feat: implement real voting for all users - Improved logging messages for clarity during WebSocket message handling. - Added new serverless functions and shims for better integration with the frontend. - Introduced new manifest files for server configuration and routing. - Implemented initial setup for handling user votes and proposals in the consensus mechanism. - Updated error handling to accommodate new user vote actions and related messages. * consensus: update test * Enhance steward state management and consensus mechanism - Added detailed documentation in README for steward state management, including state definitions, transitions, and flow scenarios. - Updated `WakuNode` connection logic to include a timeout for peer connections. - Refactored message handling in `action_handlers.rs` to utilize new `AppMessage` structures for improved clarity. - Enhanced error handling in `error.rs` to cover new scenarios related to consensus and state transitions. - Updated tests to reflect changes in the consensus mechanism and steward flow, ensuring robustness and reliability. - Improved state machine logic to handle edge cases and guarantee proper state transitions during steward epochs. * Refactor - Updated `WakuMessageToSend` constructor to accept a slice for `app_id`, improving memory efficiency. - Enhanced error handling in `Group` struct to provide more descriptive error messages for invalid states. - Added detailed documentation for new methods in `Group` and `User` structs, clarifying their functionality and usage. - Refactored state machine logic to ensure proper transitions during steward epochs and voting processes. - Improved test coverage for group state management and message processing, ensuring robustness in various scenarios. * Update README for improved clarity and formatting * fix: fix lint issues and updates test flow * test: update user test
de-mls
Decentralized MLS PoC using a smart contract for group coordination
Note: The frontend implementation is based on chatr, a real-time chat application built with Rust and SvelteKit
Run Test Waku Node
This node is used to easially connect different instances of the app between each other.
docker run -p 8645:8645 -p 60000:60000 wakuorg/nwaku:v0.33.1 --cluster-id=15 --rest --relay --rln-relay=false --pubsub-topic=/waku/2/rs/15/1
Run User Instance
Create a .env file in the .env folder for each client containing the following variables:
NAME=client1
BACKEND_PORT=3000
FRONTEND_PORT=4000
NODE_PORT=60000
PEER_ADDRESSES=[/ip4/x.x.x.x/tcp/60000/p2p/xxxx...xxxx]
Run docker compose up for the user instance
docker-compose --env-file ./.env/client1.env up --build
For each client, run the following command to start the frontend on the local host with the port specified in the .env file
Run from the frontend directory
PUBLIC_API_URL=http://0.0.0.0:3000 PUBLIC_WEBSOCKET_URL=ws://localhost:3000 npm run dev
Run from the root directory
RUST_BACKTRACE=full RUST_LOG=info NODE_PORT=60001 PEER_ADDRESSES=/ip4/x.x.x.x/tcp/60000/p2p/xxxx...xxxx,/ip4/y.y.y.y/tcp/60000/p2p/yyyy...yyyy cargo run -- --nocapture
Steward State Management
The system implements a robust state machine for managing steward epochs with the following states:
States
- Working: Normal operation where all users can send any message type freely
- Waiting: Steward epoch active, only steward can send BATCH_PROPOSALS_MESSAGE
- Voting: Consensus voting phase with only voting-related messages:
- Everyone: VOTE, USER_VOTE
- Steward only: VOTING_PROPOSAL, PROPOSAL
- All other messages blocked during voting
State Transitions
Working --start_steward_epoch()--> Waiting (if proposals exist)
Working --start_steward_epoch()--> Working (if no proposals - no state change)
Waiting --start_voting()---------> Voting
Waiting --no_proposals_found()---> Working (edge case: proposals disappear)
Voting --complete_voting(YES)----> Waiting --apply_proposals()--> Working
Voting --complete_voting(NO)-----> Working
Steward Flow Scenarios
- No Proposals: Steward stays in Working state throughout epoch
- Successful Vote:
- Steward: Working → Waiting → Voting → Waiting → Working
- Non-Steward: Working → Waiting → Voting → Working
- Failed Vote:
- Steward: Working → Waiting → Voting → Working
- Non-Steward: Working → Waiting → Voting → Working
- Edge Case: Working → Waiting → Working (if proposals disappear during voting)
Guarantees
- Steward always returns to Working state after epoch completion
- No infinite loops or stuck states
- All edge cases properly handled
- Robust error handling with detailed logging
Example of ban user
In chat message block run ban command, note that user wallet address should be in the format without 0x
/ban f39555ce6ab55579cfffb922665825e726880af6