volpe/posts/drafts/identity-protocol-design.md at 93837aaf2072cc39208c1de1d3b7f0003352db0b

jan-leila/volpe

Fork 0

Leyla Becker a590918036 feat: continued to talk about identity protocol design

2026-02-21 17:18:50 -06:00

48 KiB

Raw Blame History

Glossary

DHT - Distributed Hash Table: A decentralized key-value store distributed across multiple nodes
I2P - Invisible Internet Project: An anonymous network layer that uses garlic routing
IP - Internet Protocol: The principal communications protocol for relaying packets across network boundaries
IPFS - InterPlanetary File System: A distributed system for storing and accessing files
LoRa - Long Range: A low-power wide-area network radio protocol
NAT - Network Address Translation: A method of remapping IP addresses between networks
P2P - Peer to Peer: A distributed network architecture where participants share resources directly
PoW - Proof of Work: A cryptographic puzzle that requires computational effort to solve
SSU2 - Secure Semireliable UDP: I2P's transport protocol for UDP-based communication
STUN - Session Traversal Utilities for NAT: A protocol for discovering public IP addresses
TTL - Time to Live: The duration a record remains valid before expiring

Motivation

The Captured Internet

Every time I want to interact with the modern internet in a way that respects my independence to make choices for my own hardware and how I want to interact with people I feel like I am always trying to fight for control. Almost every part of how the modern internet is structured designed specific to extract profit and enforce state and capitalist control. This structure while terrible for the users and building community is not terribly surprising given the context that modern computing was built under.

TODO: talk about how ownership and commodification of connection is the issue.

To be able to have control over your digital life you need to have some way of telling people "this is who I am and this is how you find me". Traditionally for users this has been phone numbers, and usernames. Within the realm of hosting a service for others to access it is IP addresses, and Domain names. All of these things have some form of artificial sacristy applied to them and in most cases some layer of ownership and property added to them.

TODO: talk about ownership of hardware from data connections to the compute is an issue.

TODO: talk about the need to connect though existing protocols

TODO: summarize what we need out of a protocol

How State and Capital Prevent Autonomous Community

These structures are not neutral infrastructure - they constitute a hegemonic order¹ that actively prevents communities from organizing outside market and state control:

Commodification of connection means those without money cannot participate as equals - the market decides who speaks
Artificial scarcity turns names and addresses into speculative assets, creating property where none need exist
Rent extraction at every layer drains resources from communities into corporate hands
State jurisdiction means any community can be disconnected by pressuring registrars, hosting providers, or payment processors - your organizing exists only as long as it doesn't threaten power
Legal enforcement backs every terms of service, every takedown, every seizure - the violence of the state underwrites the apparent neutrality of the platform
Surveillance infrastructure is built into the architecture by design and by mandate - ISPs log traffic under legal compulsion, CAs can issue fraudulent certificates under state pressure, DNS queries reveal your interests to anyone with access to the logs
Corporate ownership means communities exist at the pleasure of shareholders, but those shareholders operate within a legal framework that the state constructs and defends

The internet could enable horizontal organizing across geographic boundaries, constructing new collective identities outside the nation-state framework. Instead, it has been structured to ensure that every connection passes through toll booths controlled by capital and monitored by states. These are not two separate problems - the state creates the conditions for capital accumulation, and capital funds the state apparatus. They are a single machine for the domination of those who would organize differently.

Communities cannot build durable infrastructure when the ground beneath them is rented from corporations and policed by states. Both landlord and cop serve the same order.

Constructing Alternatives: Bookmarked Names and Community-Based Discovery

The hegemonic order of the captured internet presents itself as the only possible way to organize digital communication. But hegemony is never total - it must be actively constructed and maintained, which means it can be contested and alternatives can be built. The protocol described here is one such counter-hegemonic project: infrastructure that enables communities to organize outside the state-capital apparatus.

Instead of market allocation and state enforcement, identity and naming can emerge from the communities that actually use them - a union of egoists,² individuals freely associating based on their own interests rather than submission to abstract authority:

Local Community Names Within a local community (a neighborhood, a cooperative, an affinity group), participants maintain bookmarks - human-readable names mapped to cryptographic identities. These names are not property defined and defended by state law. They are not commodities traded on markets. They are gifts of recognition within a community - they exist because a community chooses to acknowledge someone, not because an authority granted permission or a payment was processed. Your neighbor might be "sarah" in your local community's namespace, and that name carries meaning because your relationship gives it meaning, not because ICANN says so.

Affinity Group Namespaces Communities of interest can maintain shared directories without permission from any authority - state or corporate. A mutual aid network, a worker cooperative, a tenant union, an organizing collective, a reading group can establish their own naming conventions and share bookmark lists among members. These communities define themselves through their own practices, constructing collective identities through shared infrastructure rather than having identities imposed by citizenship, legal status, or consumer profiles. Names propagate through trust and relationship, not through markets, hierarchies, or the violence that backs them.

Federated Discovery When connecting across communities, introductions happen through solidarity networks. If you want to reach someone outside your immediate network, a mutual contact can provide the introduction - sharing the cryptographic identity and vouching for the connection. This is how human relationships actually work: we meet people through other people, through communities of trust and shared struggle, not through global registries controlled by corporations and monitored by states. The protocol makes explicit what the captured internet obscures: connection is a social practice, not a service to be purchased.

No Global Namespace Required This approach rejects the premise that everything must be globally unique, universally legible, and available for commodification. The state needs global namespaces to monitor and control. Capital needs them to enclose and extract. Communities need neither. Names are contextual - meaningful within the communities that create them. The cryptographic identity provides uniqueness without requiring scarcity, hierarchy, or permission; human-readable names are maintained by the people who use them, serving their purposes rather than the purposes of authorities.

Infrastructure as Commons, Not Property The goal is infrastructure that belongs to the communities using it - not rented from corporations, not licensed by states, not subject to the whims of investors or the dictates of law. When communities control their own naming and discovery, they can build durable connections that survive the next round of platform enshittification, the next state crackdown, the next private equity acquisition, the next change in terms of service. This is infrastructure that answers to the people who use it, not to shareholders or bureaucrats.

Against Constructed Authority The existing internet presents ICANN, the CA system, IP allocation hierarchies, terms of service, and property rights as natural and necessary - fixed points that cannot be questioned. But these are constructed authorities: abstractions that demand obedience while serving interests other than your own. The protocol described here refuses that obedience. It routes around the demand that you submit to authorities you never chose. It enables communities to build their own infrastructure on their own terms.

This shifts power from institutions that profit from allocation to communities that create meaning through their relationships. Connection becomes a practice of mutual recognition rather than a commodity transaction or a privilege granted by the state. The question is not whether existing authorities will permit this - they will not. The question is whether communities will build it anyway.

Goals

The goals of this protocol flow directly from the political analysis above. Each goal addresses a specific way the captured internet fails communities, and each represents a requirement for infrastructure that serves autonomous organizing rather than state-capital control.

Security

Why this matters: The surveillance infrastructure of the captured internet makes organizing visible to states and corporations. Communications can be intercepted, metadata analyzed, and participants identified. Communities organizing outside sanctioned channels face repression - legal, economic, or violent. Security is not a feature; it is a precondition for autonomous existence.

Encrypted by default - Communication should be unreadable to anyone except intended recipients. The ability to downgrade encryption should exist for applications that genuinely need it, but the default must be strong encryption. States and corporations should not be able to read community communications.
Private by default - Metadata (who talks to whom, when, how often) should be protected as strongly as content. The captured internet leaks metadata constantly; this protocol should not.
Support for forward and backward secrecy - Compromise of current keys should not compromise past communications (forward secrecy), and the protocol should recover security after a compromise through key ratcheting (backward secrecy / post-compromise security). Something like the Signal protocol's double ratchet³ should be possible.
Secure group communication - Communities are not pairs of individuals. Group chats, shared channels, and collective spaces must be as secure as one-to-one communication.

Networking

Why this matters: The captured internet assumes always-on high-bandwidth connections through ISP infrastructure. This excludes communities without reliable internet access, communities in areas where ISPs are hostile or surveilled, and communities that cannot afford commercial connectivity. Infrastructure for autonomous community must work across material conditions that capitalism creates.

Low bandwidth operation - The protocol should function on connections as limited as LoRa radio links. High bandwidth should improve performance but not be required for basic operation.
Hardware diversity - From mains-powered servers on fiber to solar-powered microcontrollers on radio mesh networks, the protocol should span the full range of hardware that communities actually have access to.
Cluster bridging - Isolated communities (a neighborhood mesh network, a rural radio cluster) should be able to bridge to other clusters through whatever links are available, even if those links are slow or intermittent.

Identity Management

Why this matters: On the captured internet, identity is rented from authorities - domain registrars, platform accounts, certificate authorities. Identity can be revoked, seized, or denied. Communities need identities they control, that cannot be taken away by state or corporate action.

Self-generated identifiers - Identities should be created by users through their own effort, not allocated by authorities.
Findability without registries - Users should be discoverable by those who need to find them, without depending on centralized directories that can be controlled or surveilled.
Identity continuity - Identities should persist across key rotations, device changes, and network disruptions. Your identity should not depend on any single point of failure.

Information Coordination

Why this matters: The captured internet requires always-on presence or dependence on corporate servers. If you're not online, you miss messages unless a company stores them for you - and reads them, analyzes them, monetizes them. Communities need asynchronous communication that doesn't require renting server space from capital.

Offline-capable messaging - Messages should be deliverable even when the recipient is offline, without requiring corporate infrastructure to store them.
Community-hosted persistence - Communities should be able to host data for their members using their own resources, not rented cloud services.
Deletion that works - Users should be able to delete information they've published, with reasonable assurance that deletion propagates. This is never perfect (you cannot force deletion from every copy), but it should be a protocol-level concept, not a corporate policy that serves their interests.

Why this matters: On the captured internet, data is enclosed as property - owned by platforms, monetized, sold, used for surveillance. Information sharing is mediated by corporations who extract value at every step. Communities need commons-based information sharing that doesn't recreate capitalist property relations.

No proprietary ownership - Data shared on the network should not be owned by any party in a way that enables extraction or enclosure.
Reciprocity without markets - There should be some mechanism to prevent pure extraction (leeching) while preserving privacy and not creating a token economy that reproduces capitalist exchange. This remains an open design problem.
Collective benefit - The protocol should enable communities to build shared resources (libraries, archives, knowledge bases) that serve collective interests rather than private accumulation.

Accessibility

Why this matters: The captured internet creates barriers - financial barriers (paying for domains, hosting, bandwidth), technical barriers (expertise required to self-host), resource barriers (hardware, electricity). A protocol that only technically-sophisticated people with resources can use reproduces existing inequalities. Infrastructure for autonomous community must be accessible across the material conditions communities actually face.

Low resource requirements - Basic participation should not require expensive hardware or high bandwidth connections.
Transferable effort - Where resource-intensive operations are necessary (like proof of work), it should be possible to perform them on borrowed or shared hardware and transfer the results.
Usable by communities - The protocol should be implementable in applications that non-technical users can actually use. Theoretical security that requires command-line expertise is not accessible.

Resilience

Why this matters: The captured internet is fragile in specific ways - dependent on DNS, on certificate authorities, on payment processors, on hosting providers. States and capital can attack communities by pressuring any of these chokepoints. Infrastructure for autonomous community must survive these attacks.

No single points of failure - The protocol should not depend on any single server, service, or authority that can be pressured or shut down.
Graceful degradation - When parts of the network are attacked or fail, remaining parts should continue functioning.
Censorship resistance - It should be difficult for states or corporations to prevent specific content or communities from using the network.
Jurisdictional independence - The protocol should not depend on legal protections from any particular state, since states serve capital and will act against communities that threaten the order.

Autonomy

Why this matters: Even decentralized protocols can create new dependencies - on core developers, on dominant implementations, on funding sources. Communities should be able to fork, modify, and operate the protocol independently.

No governance capture - The protocol should not have governance structures that can be captured by state or capital.
Implementation independence - Multiple implementations should be possible, so communities are not dependent on any single development team.
No embedded economics - The protocol should not require tokens, cryptocurrencies, or other mechanisms that could be financialized or captured by speculators.

Implementation

Identity

Identities are based on a hash of an asymmetric public key.

Identity Creation:

New identities require proof of work to prevent flooding the network with arbitrary identities
The PoW is a nonce value that, when hashed together with the identity's public key, produces a result with low entropy (e.g., many leading zeros)
Since the public key is already public knowledge, anyone can perform PoW computation on behalf of a low-power device without needing access to private keys
A helper device grinds through nonce values until finding one that satisfies: hash(public_key || nonce) < difficulty_threshold
The helper transmits only the nonce (public information) to the low-power device - no secrets cross the network
This enables mutual aid in identity creation: community members with more computational resources can help those with less, without any security compromise
Identity establishment is expected to happen off-network through secure channels (no in-band key exchange)

Key Rotation:

Old key signs a succession record pointing to new key hash
Succession records have a user-configurable TTL (time-to-live)
After TTL expires, the succession record is no longer needed
Anyone with the old key can verify the transition to the new key

Routing

Connections between nodes use packet-switched routing similar to I2P's garlic routing:⁴

Each message is routed through 6 intermediate nodes (hops) in each direction
A complete round trip passes through 12 routers total
Each hop only knows the previous and next node, not the full path
Provides anonymity by preventing any single node from knowing both sender and recipient

sequenceDiagram
    participant A as Node A
    participant H1 as Hop 1
    participant H2 as Hop 2
    participant H3 as ...
    participant H6 as Hop 6
    participant B as Node B
    
    Note over A,B: Outbound: 6 hops
    A->>H1: Encrypted packet
    H1->>H2: Re-encrypted
    H2->>H3: Re-encrypted
    H3->>H6: (3 more hops)
    H6->>B: Delivered
    
    Note over B,A: Return: 6 different hops
    B->>H6: Response
    H6->>A: (through 6 return hops)

NAT Traversal

Uses I2P-style SSU2 transport for NAT traversal:

Other nodes in the network provide STUN-like address discovery (no dedicated STUN servers)
Introducers to help establish connections through NAT

Address Discovery via Network Nodes:

sequenceDiagram
    participant Node as Node (behind NAT)
    participant Peer as Network Peer
    participant DHT as DHT/Rendezvous
    
    Node->>Peer: What is my public address?
    Peer-->>Node: Your public IP:port is X.X.X.X:YYYY
    Node->>DHT: Publish contact info (signed with identity key)

NAT Traversal with Introducers:

sequenceDiagram
    participant A as Node A (behind NAT)
    participant I as Introducer
    participant B as Node B (behind NAT)
    
    Note over A,I: A has established connection to Introducer
    B->>I: I want to connect to A
    I->>A: B wants to connect (here's B's address)
    A->>B: Direct connection attempt (NAT hole punch)
    B->>A: Direct connection attempt (NAT hole punch)
    Note over A,B: Direct P2P connection established

Rendezvous Points

Two types of rendezvous with different PoW thresholds:

Active rendezvous (self-hosted): Lower PoW threshold - the identity hosts their own contact information
Inactive rendezvous (hosted by others): Higher PoW threshold - other nodes host contact information on behalf of an identity

This allows low-powered devices to have their PoW nonce computed by more capable devices - since the nonce only requires the public key (which is already public), helpers can compute it without any access to the device's private keys.

Identities sign information that stores how to contact them in a distributed hash table. Published information needs to be hostable at a variety of rendezvous points - similar to how IPFS content routing works.⁵

Active Rendezvous (Self-Hosted):

sequenceDiagram
    participant A as Node A
    participant DHT as DHT
    participant B as Node B
    
    Note over A: Signs contact info with private key
    A->>DHT: 1. Publish signed contact record
    B->>DHT: 2. Lookup identity A
    DHT-->>B: 3. Return signed record
    B->>A: 4. Direct connection

Inactive Rendezvous (Hosted by Others):

sequenceDiagram
    participant HP as High-Power Device
    participant LP as LoRa Node
    participant R as Rendezvous Hosts
    participant B as Node B
    
    Note over HP: Compute PoW nonce for LP's public key
    HP->>LP: 1. Transfer nonce (public info only)
    LP->>R: 2. Publish contact info to multiple hosts
    B->>R: 3. Query any rendezvous host
    R-->>B: 4. Return contact info

Records and Tombstones

Records:

Published information has a time-to-live (TTL) that is user-configurable
Records can be marked as destroyable
Destroyable records include one-time keys for each party authorized to tombstone them

Tombstones:

Tombstones are used to mark records as no longer needed
Each authorized party has a one-time key embedded in the original record
Tombstones replace the records they are tombstoning
Tombstones inherit the same expiration time as the original record would have had
Sent to rendezvous points hosting the content to signal they no longer need to keep the record

File Distribution

Identities can sign packets of information for file distribution.

Evaluation: Does the Protocol Serve the Motivation?

The technical design must be evaluated against the political goals. A protocol that claims to enable autonomous community while reproducing the logics of state and capital would be worse than useless - it would be recuperation, channeling resistance back into structures that serve power. Here we assess how the implementation choices relate to the motivation.

Evaluation Against Goals

Security Goals

Encrypted by default The protocol assumes encryption at every layer. Garlic routing encrypts packets at each hop, and end-to-end encryption between identities is built into the design. This goal is met.

Private by default The routing model protects metadata - no single node knows both sender and recipient. The 6-hop design makes traffic analysis difficult. This goal is substantially met, though timing analysis and other advanced attacks may still be possible.

Forward secrecy ? The protocol can support ratcheting key exchange like Signal, but the implementation details are not specified. This goal is achievable but not yet designed.

Secure group communication ? Group communication is mentioned as a goal but the implementation is not detailed. This remains to be designed.

Networking Goals

Low bandwidth operation The protocol explicitly targets LoRa and other constrained networks. The design accounts for limited bandwidth from the start.

Hardware diversity The distinction between active and inactive rendezvous, and the ability to have PoW nonces computed by high-power devices and transferred to low-power devices (using only public keys), directly addresses hardware diversity.

Cluster bridging The design accommodates isolated clusters bridged by slow links. This is a core architectural assumption.

Identity Management Goals

Self-generated identifiers Identities are created through proof of work, not allocated by authorities. This goal is met.

Findability without registries The DHT-based rendezvous system allows discovery without centralized directories. This goal is met.

Identity continuity Key rotation through signed succession records maintains identity across key changes. This goal is met.

Information Coordination Goals

Offline-capable messaging The inactive rendezvous system allows messages to be stored by community members while the recipient is offline. This goal is met.

Community-hosted persistence Rendezvous hosts are community members, not corporations. This goal is met.

Deletion that works ~ Tombstones provide a deletion mechanism, but deletion cannot be enforced - nodes can retain data. This goal is partially met.

No proprietary ownership The protocol does not create property relations in data. This goal is met by design.

Reciprocity without markets ? This remains an open problem. No mechanism for preventing leeching without creating token economics is specified.

Collective benefit ? The protocol enables shared resources but doesn't specifically design for them. Further work needed.

Accessibility Goals

Low resource requirements ~ The protocol targets low-power devices, but proof of work creates resource barriers. The ability to compute PoW nonces on external devices using only public keys helps but doesn't fully solve the problem.

Transferable effort PoW nonces can be computed on powerful hardware using only the public key and transferred to constrained devices - no secrets cross the network. This goal is met.

Usable by communities ? This depends entirely on implementation. The protocol can be made usable, but nothing in the design guarantees it. Application design is a separate concern.

Resilience Goals

No single points of failure The DHT-based architecture, distributed rendezvous, and peer-based NAT traversal avoid single points of failure. This goal is met.

Graceful degradation The design assumes partial connectivity and intermittent links. Parts of the network can fail without global failure.

Censorship resistance ~ The protocol resists censorship through anonymity and distribution, but traffic can still be blocked at the network level. The protocol layer is resistant; the transport layer is not.

Jurisdictional independence Nothing in the protocol depends on legal protections from any state. This goal is met.

Autonomy Goals

No governance capture ? The protocol as designed has no governance structure, which prevents capture. But protocol evolution, bug fixes, and standards decisions will require some coordination. How to do this without creating capturable structures is not specified.

Implementation independence The protocol can be implemented independently. Multiple implementations are possible. This goal is achievable.

No embedded economics No tokens, cryptocurrencies, or financial mechanisms are required. This goal is met.

Summary of Evaluation

Goal Category	Met	Partial	Undesigned
Security	2	0	2
Networking	3	0	0
Identity	3	0	0
Information Coordination	2	1	0
Information Sharing	1	0	2
Accessibility	1	1	1
Resilience	3	1	0
Autonomy	2	0	1

The protocol is strongest on networking, identity management, and resilience - the core infrastructure concerns. It is weakest on information sharing reciprocity, some security details, and accessibility. These gaps represent areas for further design work.

Tensions and Contradictions

Proof of Work as Barrier PoW prevents flooding but also creates barriers. Computational effort is not equally available - it requires hardware, electricity, and time. The ability to compute PoW nonces on external devices using only public keys partially addresses this, but the fundamental logic of PoW is that participation costs resources. This may exclude the most marginalized, those without access to computation. Is this acceptable as a tradeoff against spam, or does it reproduce capitalist logic of ability-to-pay determining access?

Anonymity vs. Accountability Strong anonymity protects against state surveillance and corporate tracking, but it also enables abuse without accountability. Communities need ways to address harm caused by members. The protocol provides anonymity to the network but communities must develop their own practices for handling conflict - the technical layer cannot solve social problems. This is appropriate (technical solutions to social problems usually serve power), but it means the protocol alone is insufficient for healthy community.

Scale and the Return of Hierarchy DHTs and routing networks can develop emergent hierarchies as they scale. Nodes with more resources become more central. Rendezvous hosts that serve many identities gain power. The protocol may begin as a union of egoists but evolve toward recreating the hierarchies it opposes. This requires ongoing vigilance and possibly protocol-level mechanisms to prevent concentration that haven't been designed yet.

The Hardware Layer Remains Captured The protocol runs on internet infrastructure that remains under state-capital control. ISPs can block traffic, even if they can't read it. Hardware is manufactured by corporations and may contain backdoors. The physical layer is not addressed by this protocol. Community mesh networks, LoRa infrastructure, and other physical-layer projects must complement protocol-layer work.

Bootstrapping Problem How do you find the network without using the captured internet? Initial connection to peers requires some discovery mechanism. If that mechanism uses DNS, you're back to ICANN. If it uses hardcoded IPs, you depend on whoever controls those addresses. QR codes exchanged in person, pre-loaded peer lists, and other out-of-band mechanisms can help, but the bootstrap problem is not fully solved.

What Success Would Look Like

The protocol succeeds if communities can use it to:

Communicate without state surveillance
Organize without corporate platforms that can deplatform them
Build durable infrastructure that survives legal pressure on any single participant
Maintain autonomy from the state-capital apparatus that controls the captured internet

The protocol fails if:

Only those with significant resources can participate effectively
Emergent hierarchies recreate the power structures it opposes
State or capital find ways to surveil or control traffic despite the design
Communities cannot address internal harm because anonymity prevents accountability

The Political Work Remains

No protocol can substitute for political organizing. Technology that enables autonomous community is necessary but not sufficient. Communities must still build trust, resolve conflicts, develop shared practices, and maintain solidarity. The protocol provides infrastructure; the work of constructing counter-hegemonic collective identities happens through human practice, not through code.

The question posed at the end of the motivation section - whether communities will build this anyway, regardless of permission - applies not just to the protocol but to everything that follows from it. Technical infrastructure is one small part of the larger project of building power outside state and capital. If the protocol serves that project, it has value. If it becomes an end in itself, or a distraction from material organizing, it has failed regardless of its technical elegance.

Proposed Design Extensions

The evaluation above identifies several goals that are undesigned or only partially met. Here are potential design choices to address these gaps.

Forward and Backward Secrecy

Design choice: Double ratchet key exchange

Implement a double ratchet protocol similar to Signal's X3DH + Double Ratchet:

Initial key exchange uses ephemeral keys published to rendezvous points
Each message advances the ratchet, providing both forward and backward secrecy
Pre-keys can be published to DHT for asynchronous initial contact

The challenge is that Signal assumes a central server for pre-key distribution. In a decentralized system:

Pre-keys are published as signed records to the DHT
Multiple pre-keys can be published to handle simultaneous contact attempts
Pre-key exhaustion requires periodic refresh, which maps well to TTL-based records

Secure Group Communication

Design choice: Sender keys with membership proofs

For group communication, consider a hybrid approach:

Group has a shared identity (group key)
Members hold membership credentials signed by the group key
Sender keys allow efficient encryption (encrypt once for the group, not once per member)
Membership changes trigger key rotation

Challenges:

Group key management requires consensus or a coordinator - potential hierarchy
Large groups may need tree-based key structures (like MLS)
Anonymity within the group may conflict with accountability

Alternative: Onion-routed group messages

Instead of shared keys, route all group messages through the same anonymizing path:

Group defines a shared rendezvous point
Messages are posted to the rendezvous and distributed to members
No shared key means compromise of one member doesn't compromise group history
More bandwidth-intensive but simpler key management

Reciprocity Without Markets

Design choice: Contribution tracking without currency

The goal is to prevent pure leeching while avoiding token economics. Possible approaches:

Local reputation:

Nodes track contribution history with peers they directly interact with
Reputation is not global or transferable - it exists only in bilateral relationships
Nodes can prefer to serve peers who have served them
No currency, no speculation, no accumulation beyond direct relationships

Bandwidth budgets:

Nodes allocate bandwidth to serving others based on how much they've received
New nodes start with a small budget that grows as they contribute
No tokens - just local accounting of give/take ratios
Doesn't create markets because budgets aren't transferable

Community vouching:

Communities vouch for their members
Nodes serve requests that come with community vouches
Leeching becomes a community-level problem, handled through community practices
Preserves privacy (individual behavior not tracked, only community membership)

Reducing PoW Barriers

Design choice: Vouching-based identity creation

Instead of requiring PoW for all identities, allow alternative paths:

Community-vouched identities:

Established identities can vouch for new identities
Vouching consumes some resource (limited vouches per time period)
Creates social cost to spam rather than computational cost
New members join through existing community relationships

Time-locked identities:

Instead of PoW, identities can be created by committing to a future timestamp
Identity becomes valid after waiting period (e.g., 24 hours)
Spam prevention through time rather than computation
Low-resource nodes can wait instead of compute

Graduated capabilities:

New identities start with limited capabilities (can receive, limited sending)
Capabilities expand over time with network participation
Spam is self-limiting because new identities can't flood
No PoW required, just time and participation

Preventing Emergent Hierarchy

Design choice: Resource limits and rotation

DHTs and routing networks naturally concentrate load on well-connected nodes. To resist this:

Mandatory load shedding:

Nodes that serve above a threshold must redirect traffic to less-loaded nodes
Prevents any node from becoming too central
Redistributes load toward network edges

Rendezvous rotation:

Identities should use multiple rendezvous points and rotate between them
Prevents any rendezvous host from accumulating control over many identities
Built into the protocol rather than optional

Connection diversity requirements:

Nodes should maintain connections to diverse parts of the network
Routing should prefer paths through less-central nodes when available
Slight efficiency cost for significant hierarchy resistance

Bootstrap Without Captured Infrastructure

Design choice: Multiple bootstrap mechanisms

No single bootstrap method will work for all communities. The protocol should support:

QR code exchange:

In-person exchange of peer addresses via QR codes
No network dependency for initial bootstrap
Natural fit for local community organizing

Pre-loaded peer lists:

Distributions of the software include peer lists
Lists are signed by communities, not central authorities
Communities can distribute their own peer lists through their own channels

Sneakernet bootstrap:

USB drives, SD cards with bootstrap information
Works in network-hostile environments
Appropriate for high-security contexts

Existing network piggybacking:

Bootstrap information hidden in other protocols (steganography in images, encoded in DNS TXT records, etc.)
Useful when other methods are blocked
More complex but provides fallback

Local broadcast discovery:

mDNS⁶ or similar for finding peers on local network
Works for mesh networks and LANs
Doesn't depend on internet infrastructure

Governance Without Capture

Design choice: Rough consensus and running code

Protocol evolution needs coordination without creating capturable structures:

No formal governance:

Anyone can propose protocol changes
Changes are adopted if implementations adopt them
No voting, no foundation, no core team with special authority
Forks are expected and acceptable

Compatibility layers:

Protocol should be designed for graceful evolution
Version negotiation allows different implementations to interoperate
No forced upgrades controlled by any party

Multiple implementations:

Encourage multiple independent implementations from the start
No reference implementation with special status
Interoperability testing between implementations

Transport Layer Censorship Resistance

Design choice: Pluggable transports

The protocol layer resists censorship, but the transport layer can be blocked. Address this through:

Traffic obfuscation:

Protocol traffic should be indistinguishable from other traffic
Pluggable transports allow adaptation to blocking techniques
Community-developed transports for specific censorship environments

Multi-transport support:

Nodes should support multiple transport mechanisms
Fallback through different transports when one is blocked
LoRa, mesh networks, and other non-internet transports as alternatives

Domain fronting equivalents:

Where possible, use techniques that make blocking costly
Route through infrastructure the censor is unwilling to block
Constantly evolving to match censorship evolution

Open Questions

These design proposals address some gaps but leave others open:

Anti-leeching mechanism that preserves privacy - the approaches above are sketches, not complete designs. How do we prevent free-riding without creating token economies or surveillance?
Group communication at scale - tree-based key management introduces complexity and potential hierarchy. Is there a simpler approach for large groups?
Vouching systems and Sybil attacks - if vouching replaces PoW, how do we prevent vouching abuse?
Time-locked identities and spam - is time delay sufficient to prevent spam, or will attackers just pre-generate identities?
Bootstrap security - how do we verify bootstrap information without creating trust hierarchies?
Protocol evolution - rough consensus works for small communities of developers, but what happens when the protocol is widely deployed?
Accessibility and complexity - many of these design choices add complexity. How do we keep the protocol implementable and usable?

References

Political and Theoretical Influences

The political analysis in this document draws on several traditions of thought:

Critique of the State-Capital Relation

Marx's analysis of the state as serving class interests and creating the conditions for capital accumulation⁷
The understanding of law and property as constructed systems serving particular interests rather than neutral frameworks

Hegemony and Counter-Hegemony

Gramsci's concept of hegemony - dominant orders that present themselves as natural and inevitable while requiring active construction and maintenance
The possibility of counter-hegemonic projects that contest dominant orders and build alternatives

Construction of Collective Identity

Laclau and Mouffe's post-Marxist analysis of how collective political identities are constructed through practice rather than given by objective conditions⁸
The importance of building shared infrastructure as a practice that constitutes community

Critique of Abstract Authority

Stirner's critique of "spooks"⁹ - abstract concepts (state, property, law, morality) that demand obedience while serving interests other than your own
The concept of a "union of egoists" - free association based on mutual interest rather than submission to authority
The emphasis on refusing obedience to constructed authorities you never chose

Technical Protocol References

Anonymity and Routing

I2P (Invisible Internet Project) - garlic routing, SSU2 transport, distributed network architecture
Tor - onion routing concepts, though this protocol differs in significant ways

Key Exchange and Encryption

Signal Protocol - X3DH key exchange,¹⁰ Double Ratchet algorithm providing forward and backward secrecy
MLS (Messaging Layer Security)¹¹ - tree-based key management for large groups

Distributed Systems

IPFS (InterPlanetary File System) - content-addressed storage, distributed hash tables, content routing
BitTorrent - distributed file sharing, DHT-based peer discovery
Kademlia¹² - DHT algorithm used by many P2P systems

NAT Traversal

STUN (Session Traversal Utilities for NAT) - address discovery techniques
ICE (Interactive Connectivity Establishment) - connection establishment through NATs
I2P's introducer system - NAT traversal without centralized STUN servers

Low-Power and Mesh Networking

LoRa/LoRaWAN¹³ - long-range, low-power radio communication
Meshtastic - LoRa mesh networking
CJDNS - encrypted mesh networking

Censorship Resistance

Tor pluggable transports¹⁴ - traffic obfuscation techniques
Domain fronting - though largely blocked now, the concept of routing through infrastructure censors are unwilling to block
Steganography - hiding data in innocuous-seeming content

Identity and Naming

Petnames¹⁵ - contextual naming systems where names are meaningful within relationships rather than globally unique
Web of Trust - decentralized trust without certificate authorities
DIDs (Decentralized Identifiers) - self-sovereign identity standards, though this protocol takes a different approach

48 KiB Raw Blame History Unescape Escape