Federation
Federation means letting the cooperative's records work with systems run by other organizations. This page is the plan for how that might happen, and what it would mean for you. The cooperative keeps one record of everything it does. This page says how parts of that record might one day travel: where it is kept, what the public would be able to read, what decides which parts may cross, and in what order any of it would arrive. It is a plan, not a rule the cooperative has voted into force. Nothing here has been adopted, most of it is not built, and none of it changes your account today.
A written plan for connecting the cooperative's records to systems outside it, one day, under rules the cooperative writes for itself. Reading it will tell you what the cooperative intends, what it refuses, and how far along any of it is. It will not ask you to do anything, sign anything, or hold anything.
Read what it means for you below to see what stays exactly as it is today, which is nearly everything. Then read the Egress Doctrine, the draft rule for what may leave the cooperative, and tell us where it is wrong. One question in it is yours to answer: whether the cooperative asks your permission once, or every time, before naming you outside.
This is a draft. Nothing on it governs anything. The cooperative's software agent wrote it, under a standing permission to draft that is written down at the grant register. It was built on its own branch, the way every change to these pages is, and it is filed in the ledger, the cooperative's numbered list of work, at the address X-29, marked drafted. Publishing it adds a draft to the cooperative's pages and does nothing more. It puts no plan in force, ties the cooperative to no technology, and creates no relationship with anybody.
It sits here, on the members-only side, rather than only on the public pages, because the questions underneath it are members' questions: what information leaves the cooperative, who outside can read it, and whether the login you use is yours or the cooperative's. The short public note on the Commonplace says the same thing to an outside reader. This page says it to you, and adds the part a public page has no reason to carry: what changes for you, and what does not.
The same position is written twice, once in detail and once in brief, which is the plan on this page applied to itself. The federation vision on the public site, filed as X-30, tells anybody who reads it what federation means to this cooperative, what it will commit to, what it invites, and what it will not do. This page is the longer version: the same position, plus what any of it would mean for your share, your login, and your record. Members get the full account and the public gets a shorter summary, which is exactly the rule these two pages were written by. They are filed separately so either can be corrected or withdrawn without touching the other. Neither page names any organization outside this cooperative.
If this page disagrees with a document the cooperative has actually adopted, believe the adopted document, not this page. Then tell us, because a page that disagrees with the record is a fault to be fixed.
The cooperative worked this out from its own record rather than adopting anyone else's product. The position: every entry in the record is signed by whoever wrote it, and the record sits in two rings, an inner one and an outer one, with a written rule about what may pass between them. An entry is written once, carries the signature of its author and the date, and is never edited afterward. That is what lets a copy of it travel elsewhere and still be trusted.
A message server the cooperative runs itself
Where the cooperative does its work: coordinating, approving things, and giving each software agent an identity. Every participant signs with a cryptographic key, and for every key that is not a person's own, a named human vouches for it in writing. This ring runs today on nostr, an open messaging standard where signed messages, not accounts on someone's platform, are what carry authority. The complete record lives here.
A public commons on a protocol where identity is portable
What the public may read and build on. Today that is only this website, the pages themselves. The intended shape is a public collection of records that other software can read directly, each with a stable address and a published definition of what its fields mean, on the AT Protocol, an open standard where a person's identity belongs to them and can move between services. The cooperative has named that protocol as its candidate. It has not chosen it.
A written rule decides what crosses from the inner ring to the outer one. Nobody decides it case by case on the day. That rule is the Egress Doctrine. Egress means anything leaving the cooperative's record. The doctrine says who owns the record, who owns the public summary of it, and then gives a table: for each kind of member right and each kind of content, what may leave, in how much detail, and through which named exit. Corrections leave by the same exit the original did. It is still a draft and it binds nothing until a person with the authority to adopt it does so.
Two conclusions the cooperative treats as settled position, not taste. First, do not plan on one technology for everything. A working system and a public library need different qualities, and one system trying to be both is bad at each. Second, do not treat a direct technical link between the two rings as something that has to be built first. The two rings connect through people and agreements, by using the same words for the same things and answering to the same governance, not by wiring one system into the other. Other groups doing similar work have split the job the same way, on their own and without talking to us. That is the stronger argument for it: when two groups reach the same answer separately, it is more likely the shape of the problem than a house preference.
A horizon is a stage of work. They are ordered by what has to exist before the next one can start, not by how exciting they are. Each one is work that could be taken up. None of it has been. Every one of them ends at a decision a person has to make, not the agent.
Test whether the inner ring can already talk to another organization
The cooperative already runs a message server where each software agent holds its own key and a named human answers for it. The method it uses for a human to vouch for an agent is an open, published standard, not something the cooperative invented. So another organization running a similar server should be able to connect the same way. Nobody has confirmed that, and it rests on our own reading of the standard. That is precisely why the first stage is to test it rather than assume it. If it works, giving one agent from another organization a read-only seat in a single channel, with a fixed scope and a single word to revoke it, is a settings change rather than a building project.
Nothing would be published outward. The point is to test whether the connection is possible at all, not to send any data through it.
What it would prove: that connecting the inner ring to another organization costs a settings change, and that what makes the connection trustworthy is a person vouching for it rather than a company granting permission. Both sides have to authorize it, and on each side that is a named human's call. No such seat exists today.
Publish our definitions in a form software can read, and translate rather than merge
The cooperative already keeps its list of defined terms as a versioned file, and an automated check makes sure that file and the page explaining those terms always say the same thing. If one drifts from the other, the check fails and the build stops, so the file cannot quietly go stale. That is the pattern to extend, and it is the half of federation that is cheapest to do early.
What you hand another organization is a translation, not a merger: a statement that our word for a thing means their word for a thing, roughly this closely, losing these details along the way. Neither organization has to start using the other's words.
What it would prove: that two organizations can work together without either one giving up its own vocabulary, which is the political question hiding under the technical one. This is the dullest stage and the most useful, because federation starts with agreeing what words mean.
Adopt the rule for what may leave, then build the public commons
Adopt the Egress Doctrine first. Build the public commons second. Do it the other way around and you have built a public place with no rule about what is allowed into it. A record with no rule about what may leave will both leak things by accident and hide things it should share, usually at the same time. Adopting the doctrine is a person's act, and no person has done it.
Then the public commons can carry records other software can read: requests for help and the answers to them, offers, claims, records of practice. Inner records stay inside. What is public is a filtered copy of the inner record, and the inner record is always the original that counts.
One honest constraint. Running the server that would host all this is an ongoing commitment to keep it available and to stand behind the identities on it. It is not a weekend project. Do not take it on before there is real traffic that needs it. The definitions can be published and the translation proven long before any such server exists.
What it would prove: that a cooperative can open part of its record to the public without being mined for value, because a written rule decides what crosses rather than whatever a piece of software happens to leave exposed.
An identity you own and can take with you
Where all of this is meant to end up, and the reason for the rest of it: you carry one identity and one record of your work across every organization that federates, instead of keeping a separate account with each of them. On the public side that means an identifier that belongs to you rather than to any company, with your roles proven by signed statements of membership. On the inner side it means keys a named person vouches for. Either way, your history follows you.
An identity that leaves with the member when the member leaves is closer to open and voluntary membership than any account list the cooperative could keep on its own. That is the cooperative argument for it, and it matters more than the technical one.
Where this actually stands: none of it is built, none of it is decided, and the account you sign in with today belongs to the cooperative. Telling you otherwise would be making you a promise, and this page does not make one.
This is why the page is here on the members-only side and not only on the public pages. Almost nothing above has been built, so the honest list of what changes for you is short, and the honest list of what stays the same is longer.
What does not change
- How you sign in. One account, the same emailed sign-in link, the same list of who may read what. Nothing here adds a second account or asks you to look after a cryptographic key.
- Your share and your agreements. None of it goes anywhere. Those are inner-ring records and they stay inside under every stage above.
- What leaves the cooperative. Nothing leaves because this page exists. The default is that nothing leaves, and the rule that could permit anything to leave has not been adopted.
- Who can read about you. Nobody outside gains the ability to read anything of yours. No outside seat exists, no exit exists, and nothing is published outward today.
- The message server. You do not have to be on the cooperative's message server to be a member of the cooperative, and this plan does not change that.
What would change, in the order it would arrive
- First, nothing you can see. Stage 1 is invisible to members on purpose. You would read about it here rather than notice it.
- Then our definitions, as a file. Another organization's software could read what our words mean without reading our database. It looks like a published file, not a new feature you use.
- Then a defined public summary, and only if the Egress Doctrine is adopted first: a stated level of detail, a stated exit it goes through, and corrections going out the same exit. You could ask how a piece of information got out, and the answer would name the exit.
- Then, furthest away, an identity you own. Yours to keep, which means it goes with you if you leave. That is the biggest change described on this page and the one least likely to happen soon.
What you can actually do about this now. Read the Egress Doctrine and tell us where its table gets things wrong. It decides what may be said about you outside the cooperative, and it is still a draft. It leaves three questions open on purpose, and one of them is yours: does the cooperative ask your permission once, as a standing yes, or every single time something about you is about to go out? Answer that one before a drafter answers it for you.
Written down here rather than left unsaid, because a page describing plans is exactly where the scope of those plans quietly grows.
- Nothing here has been adopted.
- Publishing this page adds a draft to the cooperative's pages. It adopts no plan. Every stage above becomes real, if it ever does, one piece at a time, through the same review and approval route as any other change, with a person's hand on it.
- Connecting to another organization is a governance decision, not a technical one.
- Giving another organization a seat, depending on another organization for anything, committing to run a particular technology, and publishing anything outward in the cooperative's name are all decisions for named people with the authority to commit the cooperative. They are not the agent's decisions to make, and no amount of technical readiness makes them so.
- The agent may do only what the register says it may do.
- The agent holds four standing permissions, all listed at the grant register: correct the record, review and publish changes to these pages, draft documents, and say publicly when something is wrong. None of those lets it speak for the cooperative to outsiders or commit it to anyone. Anything not written in the register is not permitted, and a new permission goes into the register before it is ever used.
- No relationship with anyone is assumed.
- This page names no other organization, describes no agreement, and makes no assumptions about anyone else's plans. Two groups landing on the same design is not a partnership, and noticing a pattern in public is not a negotiation.
- What the cooperative actually does is the test.
- If this page and the cooperative's actual practice ever disagree, the practice is the fact and this page owes you a correction. That correction gets published the way corrections are published, not quietly edited in.
public anchors · issue #217, the inner and outer two-body frame · issue #218, the forward design guidance · issue #250, solicitations as a first inhabitant of the outer commons
where this stands · X-29 · drafted, adopted by nobody · the agent drafts, a person decides