The shared network
proposed
ONEON
A proposed network for shared records, designed to cooperate across independent implementations.
Why ONEON exists
The organs need ways to coordinate, verify shared records and carry agreements between communities. ONEON is one proposed implementation of that infrastructure. Its architecture remains open, with interoperability and local continuity as design requirements.
Let the needs shape the network
Shared intelligence, identity proofs and contribution records introduce different requirements. Establish which records need shared agreement and which information should remain private or local. Architecture should follow those needs, including how a disputed record can be reviewed and corrected without concealing its history.
Keep local life moving
Communities need to know which services can continue during a disconnection, which actions must wait and how pending records are reconciled. The design must make those limits visible. A connection failure should not silently turn an unconfirmed action into an accepted shared record.
Cooperation that survives a provider change
Open interfaces, portable records and a tested migration process should let communities change implementations while keeping their agreements usable. Recovery and dispute procedures need accountable people alongside technical verification. These capabilities remain to be demonstrated.
Where it stands
- Now
- A proposed network role; architecture and implementation are not yet settled.
- Next
- Test shared records across independent implementations, including provider switching, disconnection, recovery and a contested record.
Its place in the living system
SOS Systems defines governance. Otto provides intelligence. Umahn, Manifest, KOINK FUN and Panik supply requirements the network must be able to support.
Help shape ONEON
Help turn an organ’s needs into clear infrastructure requirements and ways to test them.
Introduce yourself →