swarm-consensus

An implementation of Swarm Consensus

Links

You can read more about Swarm Consensus in this document.

TODOs

We need to support broadcasting scenarios above the basic one, which is to send Data from Origin to all Gnomes present in the Swarm during Broadcast start. Some additional scenarios are:

• Provide a way for a Gnome to Synchronize Swarm state, so that he is aware of active broadcasts and multicasts (direct to Neighbor or multiple Neighbors)
• Allow a Gnome to subscribe to an existing broadcast (direct to Neighbor)
• Allow a Gnome to unsubscribe from broadcast (direct to Neighbor)
• Allow a Gnome to take-over a broadcast once inactivity period has passed
• Allow a Gnome to end a Broadcast once inactivity period has passed
• Allow a Gnome to send a message uplink to Broadcast origin in order to notify subscribers (can be used for a service broadcast that provides information about other Gnomes open for joining defined Swarms without changing Swarm's state) (direct to Neighbor and recursive up to origin)
• In order to implement load balancing we also need a way for source Gnomes to notify their subscribers that they should switch given broadcast to a different source. Upon such notification receiving Gnome should respond with Unsubscribe message. (direct to Neighbor)

Once Swarm state sync is in place we can think of following: Introduction of Capabilities, together with Groups and Actions. Caps should be used for verifying that requesting Gnome is allowed to perform requested Action. Capabilities, Groups and Actions should be defined by application and Actions should be able to extend or shrink existing sets of any and all of those, making the system dynamic. Groups should also be used to define target recipients of Multicasts, but that requires implementation of encrypted casting and is lower priority. Maybe we should have a separate CastingGroup and Group for Capabilities.