No canonical surfaces — Jinn's plurality posture

[oaksprout]

Companion to launch-gating Discussion #222 and the PRINCIPLES.md re-establishment.

The posture, stated bluntly

Jinn has no canonical client, no canonical website, no canonical chat, no canonical Twitter, no canonical broadcast account, and no canonical operator UI. The DAO controls the protocol contracts; everything else is plural and forkable.

This is not a marketing posture. It is a load-bearing structural commitment that follows directly from PRINCIPLES.md — specifically Neutral (the network does not structurally benefit any individual or entity above any other), Governance-Minimal (every controlled surface is governance surface), and Permissionless (the path from outsider to participant has no privileged shortcuts).

What this means concretely

• Clients: the daemon implementation in this repo is a client. Anyone can write another. Forks are welcome and expected.
• Frontends / explorers / operator UIs: same. Multiple implementations expected. The reference frontend ships with a one-command deploy recipe (One-command deploy recipe for the reference frontend #259) so mirrors are cheap; mirrors get listed in a community-maintained README registry ("Known instances" list in README #260).
• Communications: no official Jinn chat room. The "Jinn Working Group" Telegram is being wound down because it was seeded through Olas-adjacent channels and framed as canonical. In its place: a list of community-run rooms in the README. Multiple rooms expected; new ones welcomed via PR.
• Twitter / X / social: no "voice of Jinn" account. Individual contributors post under their own identities. A community-run broadcast bot (Publish open-source Jinn broadcast bot #258) publishes mechanically-verifiable network state (releases, on-chain events, accepted PRs); the code is open source and anyone can run their own instance.
• Web domain: jinn.network is sunsetted. Not transferred to anyone, not squatted defensively, not renewed. After expiry, scam-squatting risk is accepted as the price of the posture. Contributor entities run their own websites under their own domains, listed plurally in the README.
• Name pointer: no canonical ENS, no canonical DNS. Anyone proposing a canonical pointer is proposing a chokepoint.

What stays canonical

Only what must be canonical to coordinate around:

• The on-chain protocol contracts (token, DAO, distributor)
• PRINCIPLES.md, SPEC.md, GLOSSARY.md
• The protocol's self-statements about its own loop and roles

Narrative artifacts (THESIS.md, BRAND.md, GROWTH.md) belong to whichever contributor entity is articulating them — they are not canonical, and other contributor entities can articulate their own.

The cost we accept

This posture makes coordination slower. There is no Schelling-point hub where everyone congregates, no single voice to amplify announcements, no canonical brand to defend. The alternative — owning canonical surfaces — is incompatible with becoming the most legitimate decentralised agentic AI network. We are choosing legitimacy over coordination convenience.

How to participate in this posture

• Run your own client. Fork ours, or write your own.
• Run your own frontend. The one-command deploy recipe (One-command deploy recipe for the reference frontend #259) makes mirroring cheap.
• Start your own community room. Add it to the README list via PR.
• Run your own broadcast bot instance.
• Articulate your own thesis / brand if you disagree with ours.

If you see a surface that has quietly become canonical that shouldn't be, open a Discussion. The point of this thread is to keep us honest.

Related threads

• Discussion Launch gating criteria — what makes a Jinn launch good enough to ship? #222 — launch gating + principles
• Discussion Adopt Apache-2.0 as the repository licence (+ open-source scaffolding) #276 — Apache-2.0 + open-source scaffolding
• Issue Audit on-chain structure for governance minimisation #223 — DAO governance-surface audit
• Issues Publish open-source Jinn broadcast bot #258, One-command deploy recipe for the reference frontend #259, "Known instances" list in README #260 — broadcast bot, deploy recipe, known-instances list