The muppet disco

sketch · a future milestone

Deliberately deferred

The disco’s design, plan and implementation come after the MVP. It raises questions of ownership and narrative control: who lists what, who decides what’s official, who holds a name. Those deserve their own discussion rather than steering the core protocol. These notes record the shape so far.

Discovery, not hosting

Hosting a session costs server resources, and XTXP doesn’t aim to host everyone’s. The ideal is federated and self-organising: people and organisations run their own muppets, and nobody has to ask a central service for permission.

So xtxp.link/{host}/{path}@{ref} isn’t served by xtxp.link. xtxp.link is a muppet disco: it helps a client find the actual muppets hosting the sessions behind an address, and hands it on to them.

• Anyone can run a disco. xtxp.link is one among many. Others can run their own, and XTXP couldn’t stop them and wouldn’t want to.
• A disco never hosts sessions. It lists them and points to the muppets that host them.
• A disco is a starting point for creating sessions. It can open a new session on an instance of your choosing, including a muppet on your own machine (localhost) tied to your key. The new session lives there, not at the disco.

Queries are signed

A client asks a disco for sessions with a query signed by its key. The signature tells the disco what that key may see, so it can answer with only the sessions visible to that key, under their grants.

That keeps lightweight sessions private by default. A personal session, such as one user’s scratch state, need never be advertised at all and may never leave that user’s own muppet.

Domain owners and the bouncer

For an ordinary website, the @origin session is the site as its owner publishes it. A domain owner can claim it by public key, with a DNS TXT record asserting ownership. Once claimed, the owner decides, at the disco:

• which forked sessions of their pages are listed
• which kinds of edits are permitted where
• what they officially relay

This control is called the bouncer. Everyone stays free to fork and host sessions of any page, as the web already lets anyone quote or link to it. The domain owner still controls the official @origin, and neither the protocol nor the disco becomes the police.

Names are contestable

With many hosts and many discos, a session name such as @alt, @punk or @notes on a popular page becomes something people can contest. That needs either a registrar for names, or a way for discos to advertise federation with each other so a name resolves the same way across them.

Federation

The rules for how the xtxp.link disco federates are still to be defined. Mastodon’s choices on how to use ActivityPub are the closest model: independent instances, each with its own policies, that choose whom to federate with.

ActivityPub itself might even carry disco federation. That’s a side quest, deliberately not defined here.

Still open

• Federation rules for the xtxp.link disco, and whether ActivityPub carries them.
• A registrar for session names, or a federation mechanism that makes names resolve consistently.
• The TXT record format for claiming a domain’s @origin by key.
• The signed query format, and what a disco learns about a user from it.
• How muppets advertise sessions to a disco, and how listings expire.

Prior art: Mastodon and ActivityPub for federation, and domain verification by DNS record for claiming @origin.