Federation concensus - #2683
Open
KoalaSat wants to merge 6 commits into
Open
Conversation
Contributor
|
I like the idea. How is the algorithm that weights the coordinator by seniority? |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What does this PR do?
The Problem
Today, adding or removing a coordinator from the RoboSats federation requires publishing a new version of every client app. Users have to update before they see the change, and coordinators have to wait for a release cycle to join or leave. This creates unnecessary friction for a system that is supposed to be decentralised and permissionless.
The Change
After this release, coordinators control their own membership by publishing who they recognise as part of the federation. When enough coordinators agree on a change — a new member joining, or an existing one leaving — every connected client picks it up automatically in the background, without any app update.
How It Feels to Users
The app continues to work exactly as before on launch — it starts from its own built-in list immediately. Once connected, it quietly consults the coordinators it is already talking to and applies a voting process to determine the agreed-upon list. If the coordinators agree with the client, nothing changes. If they have collectively moved on, the client updates its active list on the fly. Coordinators that were removed are disconnected cleanly; new ones become available right away.
Trust and Safety
No single coordinator can impose a change unilaterally. Votes are weighted by seniority — coordinators that have been in the federation longer carry more influence than newcomers. A coordinator with at least one year of service is guaranteed a meaningful vote weight, and the oldest coordinators carry the most. A strict majority of total weight must agree before any client adopts a new list. When no majority is reached the client keeps its current list unchanged, so indecision always favours the status quo. This makes it prohibitively expensive to flood the federation with fresh coordinators in order to push through an unwanted change. New coordinators not included in client's default federation will never have a vote.
Scope
This affects all platforms. The one exception is the self-hosted node app, where new coordinators still require a release to become reachable — but coordinator removals take effect automatically there too.
Checklist before merging
pip install pre-commit, thenpre-commit install. Pre-commit installs git hooks that automatically check the codebase. If pre-commit fails when you commit your changes, please fix the problems it points out.