Do this in the right order (almost nobody does)

I wrote this 10 years ago. It's only become more true, and getting this wrong is what Bluesky got wrong:

1. Design a data abstraction that solves a class of problems.

2. Design a good wire protocol for that abstraction.

3. Better yet, design 2 protocols: one server-to-server and one client-to-server. The server to server protocol must be based on immutable append.

4. Implement a simple as possible server. Do not try too hard to make it performant, just very easy to install and very easy to understand. This is the protocol reference implementation. Reading this should should be reading the spec, and vice versa.

5. Implement an open source client library, that completely covers the entire data model and the entire wire protocol.

6. Implement another open source client library, in a very different programming language. If this is difficult, you let your knowledge of your favorite language overconstrain the wire protocol. Go back to step 2 and fix it.

7. Implement a command line client on one of those libraries. Again, it must completely cover the entire data model.

8. Implement an ok GUI app. NOT HTML/JS based. NOT Electron.

9. Implement a very high performance highly scalable server. If you are tempted to change the wire protocol to do this, you have screwed up.

10. Now, and only now, you can implement some easy to use GUI apps. At this point, and at this point only, do you bring in any "designers", "UX" people, or anyone who uses Photoshop as working tool.

Of course, for the past 15 ^H^H 25 years, everyone has been doing this backwards, with disastrous results.

Absolute exclusions until step 9 (non-negotiable)

1. Venture capitalists and anyone representing VC incentives

Why excluded

• Demand a narrative before a substrate exists.
• Optimize for scale, optics, and defensibility, not correctness.
• Force premature commitments about governance, safety, and outcomes.

Failure mode introduced

• Product goals hard-coded into protocol semantics.
• Centralization justified as “responsibility.”
• Architecture warped to satisfy pitch decks.

2. Trust & Safety, Policy, Integrity, or “Responsible X” teams

Why excluded

• Operate via discretion, escalation, and exception handling.
• Think in actors and intent, not invariants and state transitions.
• Require ambiguity to function (context sensitivity).

Failure mode introduced

• Undefined semantics (“case-by-case enforcement”).
• Hidden authority channels.
• Protocol surfaces that require human judgment to complete.

Protocols must eliminate discretion, not depend on it.

3. Social theorists, ethicists, “what this should do for the world” thinkers

Why excluded

• Start from normative conclusions instead of mechanical constraints.
• Produce unfalsifiable requirements (“healthy discourse,” “civic good”).
• Confuse social goals with system capabilities.

Failure mode introduced

• Moral abstractions embedded as data types.
• Un-testable success criteria.
• Endless reinterpretation of protocol meaning over time.

A protocol answers “what can exist,” not “what should happen.”

4. UX designers, product designers, and user-journey specialists

Why excluded

• Optimize for felt experience over semantic clarity.
• Push stateful shortcuts, caching hacks, and implicit behavior.
• Encode UI assumptions into core models.

Failure mode introduced

• Protocol coupled to one interaction model.
• Hidden state that cannot be represented cleanly in APIs.
• Clients that cannot be reimplemented independently.

UX belongs after the substrate stops moving.

5. Brand, communications, PR, and “community narrative” staff

Why excluded

• Treat ambiguity as an asset.
• Pressure engineers to keep semantics flexible for messaging.
• Optimize for press safety, not system truth.

Failure mode introduced

• Vague language in specs.
• “Soft” guarantees that cannot be enforced.
• Resistance to breaking changes even when required for correctness.

Protocols must be allowed to be boring and blunt.

6. Legal teams (except for narrow threat modeling)

Why excluded

• Incentivized to minimize liability, not complexity.
• Push for kill-switches, override powers, and vague authority.
• Prefer interpretability over determinism.

Failure mode introduced

• Emergency powers baked into the core.
• Non-enumerable authority.
• Protocols that assume compliance rather than enforce constraints.

Legal review comes after invariants exist.

Conditional exclusions (allowed only as silent reviewers)

7. Senior management / executives

Allowed only if they:

• Do not set requirements.
• Do not demand timelines.
• Do not request “alignment” with vision statements.

Failure mode if active

• Premature convergence.
• Fear of breaking compatibility.
• Incentive to “just ship something.”

8. Growth, analytics, or monetization specialists

Why limited

• Treat the system as an instrument panel.
• Push for hooks, metrics, and identifiers too early.

Failure mode introduced

• Surveillance baked into the substrate.
• Irreversible data exhaust.
• Clients forced to leak information.

Who must be in the room before step 9

For contrast, the allowed set:

• Protocol designers who think in invariants and adversarial models.
• Engineers who have implemented multiple independent clients.
• People who have run federated systems that survived hostile forks.
• Language implementers who care about determinism and edge cases.
• Operators who demand replay, auditability, and backfill.

If someone cannot explain:

• what the system forbids,
• what cannot be represented,
• and how two hostile implementations still interoperate,

they should not be shaping the protocol.

The hard rule (the one orgs break)

Anyone whose job depends on ambiguity, discretion, narrative control, or moral authority must not shape the substrate.

Those functions sit above the protocol, not inside it.