Original CTZN design document
Technical architecture
Our goal is to establish trust in authority when it must be given. Our tools for gaining that trust is distributed & contingent authority ("Authority model") and constrained powers of authority ("Constitutional networks").
Authority model
CTZN's authority model has two primitives:
- DNS ownership - provides the ability to map domains and DNS-IDs to pubkeys.
- Pubkey ownership - provides the ability to modify a given database.
These primitives are used to create PX spaces. Consider the following example:
Element
Impact
example.com
maps to the example
database's pubkey
Establishes the example.com community's database.
example
declares the usage of ctzn.network
schemas
Establishes the example.com community's core application.
example
declares 3 user records -- alice@example.com
, bob@example.com
, and carla@example.com
-- and their database pubkeys.
Establishes the example.com community's membership.
alice
, bob
, and carla
databases declare profile and post records.
Establishes the content of the example.com network.
example
database declares a secondary index of the latest posts.
Establishes the timeline of the example.com community activity.
We can infer a few things from this example:
- There is a hierarchy of identity, from DNS -> server database -> user databases
- User databases maintain their own profile/post records and can be accessed independently of the
example.com
community. - The
example.com
database maintains community information only, including secondary indexes which represent a current "view" of the activity. - As records are linked by their pubkey-URL, there is no hard binding to the example server.
Because of this separation of authority, the members of example.com
maintain the freedom to migrate their content away from the example community without any disruption to the network. This migration would be similar to "forking" a codebase -- the content would remain but the community authority would be modified.
This interplay between community authority and individual authority is a repeatable PX pattern. By maintaining individual rights to migrate away from a community, the community maintainers' authority is contingent on the members' satisfaction with their leadership.
Constitutional networks
A future goal for the Hypercore Protocol is a toolset for "smart contracts" - code which has externally-auditable execution. Once CTZN's data-mesh supports smart contracts, it will integrate the contracts in the PX patterns to create community "constitutions."
Using constitutions, communities can define a strict ruleset by which community-members can exercise authority. These constitutions will establish rules for:
- Identity registries
- Content and user moderation
- Discovery and content-ranking
And so on.
Smart-contract constitutions create both transparency and constraints. Moderators will not be able to modify the community datasets without following the contract rules, and every action will be placed in an auditable log.
Constitutions will provide members of large-scale communities an assurance over how their community will be governed. Rather than trusting the moderators to follow a declared process, the community can legislate the constitution to establish how moderators will govern.