You are here. See how this question connects to other ideas.
Select a node to open its page · Expand to read within the map
One question
Who controls coordination?
Separate shared rules, coordination services and ultimate authority.
Imagine several people booking one meeting room. They need a consistent booking result to avoid double-booking. That requirement does not decide who owns the records, who can change the rules, or whether the team must always use one provider.
Design those decisions separately. A team might appoint a booking administrator or use a system operated by several parties. Needing agreement does not establish that a particular implementation is indispensable.
State what is necessary, and for what
Section 2.2 of RFC 9518 discusses useful centralization, including globally coordinated naming. It does not make every concentration of control justified.
For our booking example, a concrete design review might look like this:
| Decision | Possible justification | Remaining question |
|---|---|---|
| One service resolves booking conflicts | A small team wants simple operations | How is service restored after failure? |
| An administrator can cancel bookings | Mistakes and emergencies need handling | Are reasons recorded, and who can review them? |
| Tools share a booking format | Records can survive a change of tool | Does the replacement interpret time zones and recurring bookings correctly? |
This reviews the example; it is not a certification checklist for all Internet systems. Concentrating a particular task can be useful. The authority granted should still fit that task.
Relationship to ArcBlock
ArcBlock's 2019 article on five factors for successful dApps starts from user value rather than adding complexity for decentralization's sake. That historical position helps frame questions. It cannot replace examining the actual permissions and dependencies of an ArcBlock product.
Continue with switching services to turn a promise of choice into a verifiable migration.
Sources and further reading
- Mark Nottingham · RFC 9518, Section 2.2: an Independent Submission, Informational RFC representing the author's views.
- ArcBlock · Five factors for successful dApps (2019, Chinese): historical reasoning; verify current product behavior separately.
Check your understanding
When is centralized coordination reasonable?
Identify the conflict it solves, then examine its authority, failure impact and replacement.
Referenced here
Terms
- AFS UI
AFS-UI builds interfaces over the addressable resources of AFS. People use a rendered interface; agents can inspect and operate its exposed structure through paths. AUP describes the interface and its interactions, while a UI device such as Web Device renders it.