yourspace
pricingdocslog inhome
blog

Federation arrives — sub-collectives on a shared substrate

Federation has been on the wishlist since v1.0. Customers asked for it as four separate things at four different times: an art-collective wanted shared identity, an OSS organization wanted project-grouped sites, a school district wanted classroom-scoped hosting, and a conference series wanted year-stacked sites. v1.2 ships the shape that covers all four without adding distinct mechanisms for each.

What federation means here

A collective claims a sub-domain on the platform — your-collective.yo.urspace.net — and onboards member sites under it. Members get per-member scoped tokens; the collective gets a rollup view across every site.

The unit of identity on this platform is the site, not the post or the person. Compared to ActivityPub-style federation: this is hosting-shaped, not social-graph-shaped. A collective is a hosting tenant with shared billing + access; not a Mastodon instance.

The shape that landed:

# alice's site, deploying under the writers collective
name: short-stories
collective: writers-club

build:
  dist: ./dist

Alice's site lands at short-stories.writers-club.yo.urspace.net. The Writers' Club's collective dashboard shows it alongside bob's and charlie's sites; billing rolls up to one collective invoice; per-member chargeback exports as CSV.

The four use-case shapes that drove the design

OSS organizations

A maintainer collective with one site per project. The yourspace team's own cli.yourspace.yo.urspace.net, docs.yourspace.yo.urspace.net, and blog.yourspace.yo.urspace.net use the same shape; we eat our own dogfood. Per-project access control is what lets a docs-only contributor have write access to docs without seeing the CLI's deploy keys.

School + district sites

A district claims its sub-domain; each school + classroom gets a member site under it. Read-only roles for students; per-classroom edge functions with the district's content policy. The federation-aware audit log carries the trail compliance teams need.

Art + community collectives

A zine collective, a writing group, a gallery cooperative. Each member ships their own site under a shared identity; the collective's home page links the membership. The first cohort includes the Brooklyn Poets Coop, the Glasgow Print Group, and the Lagos Chapbook Assembly — three collectives with three different content policies, all running on the same substrate.

Conference sites

A conference series with one site per year: 2025.tech-conf.yo.urspace.net, 2026.tech-conf.yo.urspace.net, 2027.tech-conf.yo.urspace.net. Older years stay live as archives; the current year defaults to the apex. The conference team rotates without losing institutional memory; archives stay indexed.

Onboarding loop

Four steps from "we want to start a collective" to "Alice's site is live":

  1. Claim the sub-domain. From a Team-tier dashboard. Name uniqueness enforced platform-wide; reservations expire after 30 days unless a member site is bound.
  2. Invite collaborators. Email or GitHub username. Per-member scoped tokens; roles (owner / member / read-only).
  3. Bind member sites. The member's yourspace.yml adds collective: <name>; yourspace deploy lands at <site>.<collective>.yo.urspace.net.
  4. Track + bill from the rollup. Bandwidth, edge invocations, per-member breakdowns. CSV chargeback export for collectives with internal billing.

The constraints that shaped the calls

Why 25 member sites at the Team tier

The number is empirical. The first cohort of preview teams ran between 4 and 31 member sites; the median was 7. 25 covers ~85% of the cohort comfortably; the 15% that need more upgrade to Enterprise where the seat count is unbounded and SCIM provisioning kicks in.

Why custom domains verify against the collective

A member site at short-stories.writers-club.yo.urspace.net can also bind shortstories.example.com — but the verification posture sits with the collective, not the individual member. Two reasons: (1) the collective is the platform-side accountable party, and (2) members joining and leaving doesn't require re-verification each time.

The edge case: a member leaving the collective takes their custom domain with them only if the collective owner releases it. Same posture as a team employee leaving — the company keeps the account; the employee starts a new one.

Why federation-aware audit log lives at the collective

Compliance-required for the school-district shape; useful for every other shape. Logs scope to the collective; the platform operator never sees them. Members can't suppress the log on their own actions; the collective owner can export, can't redact.

What didn't make it into v1.2

  • Cross-collective sharing. Two collectives wanting to share a member is "deferred until enough collectives ask." Workaround: the member belongs to two collectives separately, with a site in each.
  • Per-collective custom CSS / theming. The collective landing page at <name>.yo.urspace.net is currently template-shaped. Customer-themable lands when the templating story does.
  • Federated analytics. Member sites' analytics roll up to the collective dashboard, but cross-collective comparisons are not surfaced. Out of scope until a customer asks.

Try it

/federation is the public landing. /signup?plan=team opens the Team-tier path that includes federation onboarding.

For collectives migrating from ad-hoc shared-token shapes — the migration tool at yourspace federation migrate walks an existing Team account through claiming a sub-domain, splitting shared tokens into per-member scoped tokens, and binding sites under the collective without breaking active deploys.