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:

1. DNS ownership - provides the ability to map domains and DNS-IDs to pubkeys.
2. 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.