Current risks (Section 10.2) cover protocol ossification and network effect failure but do not address gradual centralization of successful implementations: a popular daemon fork adds proprietary extensions, a dominant relay becomes a de facto hub, a well-funded client captures users and extracts rent.
History: email → Gmail dominance, XMPP → Google Talk embrace-extend-extinguish, IRC → Discord/Slack.
Proposal: add enshittification as explicit risk (probability: high, impact: critical) with designed-in mitigations:
Planned centralization/decentralization toggle: protocol allows implementations to centralize in specific pre-designed ways that can be dropped without breaking the network
No undocumented proprietary extensions: extensions MUST be namespaced and documented, undocumented ones are a spec violation
Interoperability test suite: reference tests any implementation must pass, preventing subtle lock-in incompatibilities
Existing mitigations: plugin architecture, spec-first approach, multiple competing implementations
Discussion origin: ASCII moth — "enshittification should be included in the threat model at the early design stage."
Current risks (Section 10.2) cover protocol ossification and network effect failure but do not address gradual centralization of successful implementations: a popular daemon fork adds proprietary extensions, a dominant relay becomes a de facto hub, a well-funded client captures users and extracts rent.
History: email → Gmail dominance, XMPP → Google Talk embrace-extend-extinguish, IRC → Discord/Slack.
Proposal: add enshittification as explicit risk (probability: high, impact: critical) with designed-in mitigations:
Planned centralization/decentralization toggle: protocol allows implementations to centralize in specific pre-designed ways that can be dropped without breaking the network
No undocumented proprietary extensions: extensions MUST be namespaced and documented, undocumented ones are a spec violation
Interoperability test suite: reference tests any implementation must pass, preventing subtle lock-in incompatibilities
Existing mitigations: plugin architecture, spec-first approach, multiple competing implementations
Discussion origin: ASCII moth — "enshittification should be included in the threat model at the early design stage."