MeshSky
Run a Feeder

MeshSky Docs

Governance

How the MeshSky protocol evolves — RFCs, the foundation, and rough consensus.

MeshSky is a protocol, not a product. There is no admin button, no master switch, no vendor lock-in. This page explains how the protocol evolves over time and who decides what.

The MeshSky Foundation

The MeshSky Foundation is a non-profit steward of the protocol. It:

  • Hosts the canonical specification.
  • Maintains reference implementations (MIT-licensed).
  • Convenes the RFC process.
  • Holds the trademark and primary domain.
  • Operates a small set of public-good infrastructure (root directory, bootstrap AirBridges, audit signing key) — none of which are required to participate in the mesh.

The Foundation explicitly does not:

  • Run the network. The mesh runs itself.
  • Approve who may join. There is no permission to grant.
  • Have the technical ability to censor traffic, mint identities, or override signed observations.

The RFC process

Protocol changes are governed by MeshSky RFCs (Requests for Comment), modeled loosely on the IETF and Rust RFC processes:

  1. Pre-RFC discussion on the public forum or chat.
  2. Draft opened as a pull request to github.com/meshsky/rfcs.
  3. Public comment period of at least 2 weeks for substantive changes.
  4. Final comment period of 1 week signaling intent to merge.
  5. Disposition by the relevant working group (Protocol, Security, Operations).
  6. Reference implementation must land before the RFC is considered “stable”.

Major-version protocol bumps additionally require a rough-consensus signal from operators of at least two-thirds of weighted reputation in the network, collected via signed RFC_VOTE messages.

Working groups

Three standing working groups carry technical responsibility:

GroupScope
Protocol WGWire format, message types, version negotiation.
Security WGThreat model, cryptography, disclosure, audits.
Operations WGDirectory, bootstrap relays, public API SLOs.

Each WG has a public chair, public minutes, and rotates membership annually.

Reputation & rewards

Feeder reputation today translates into priority routing and higher API rate limits. Future RFCs may introduce protocol-level rewards (e.g. cooperative cost-sharing for AirBridge bandwidth). Any such change must:

  • Be specified in an RFC with a complete economic-impact analysis.
  • Be opt-in for existing operators.
  • Preserve the property that the protocol works without rewards — the mesh must never depend on incentives to function.

Forking

The protocol is permissively licensed and the spec is in the public domain. Anyone may fork. We expect that the strongest argument against any fork is the network effect of the existing mesh — but if the Foundation ever strays from the principles above, forking is the intended remedy.

Contact