๐ŸŒ united.social

Design

What united.social is, and why it is built this way.

The claim

Identity does not require government cooperation. Membership does not require biometrics. Governance does not require a platform that captures and compromises your community from the outside.

Real democratic traditions โ€” town halls, juries, caucuses, polling stations โ€” have always tied participation to showing up. united.social is continuous with that tradition. It is not continuous with the surveillance-state identity model that has replaced it: no state ID, no biometric hash, no centralized gatekeeper that can be captured, subpoenaed, or deplatformed.

The platform is content- and bias-neutral. Communities define their own membership, verify their own members, and decide what their votes mean. Consumers of the platform โ€” specific communities, consumer apps โ€” layer their own framing on top. The platform does not.

Identity model

Layer 1 โ€” cryptographic continuity

Identity starts as a signed key and a record of past actions. AT Protocol DIDs give this for free: a portable, signed identifier you control. No platform owns it. No state issues it. You take it with you.

This layer tells us nothing about whether the human behind the DID is real or unique โ€” only that the same pseudonymous identity that did X and Y is doing this now. Foundation, not verification.

Layer 2 โ€” proximity attestation

A signed record where one member attests another's identity at a place and time. Stored as a community.attestation.proximity record in AT Protocol โ€” in the attestor's own repo, signed by their own key.

The UX target: one tap, both phones say done. NFC handshake; both apps prompt "vouch for [name] as member of [community]?"; both tap yes. Looks like exchanging contacts. Means cryptographic mutual attestation.

Why this matters: physically meeting cannot be parallelized by a bot farm. For the foreseeable future, in-person attestation defeats AI-scale sybil attacks.

Layer 3 โ€” notary attestation

A small number of designated community members hold the notary role. They specialize in the verification ritual. Their attestations are weighted higher than peer-level proximity attestations. Their reputation is the collateral.

Notary is itself a community-defined role โ€” a credential signed by the community's governing authority. A notary caught attesting fakes loses the role; their prior attestations get flagged for re-verification. This is why vouching mills are harder: mill operators have skin in the game.

Real precedents: notary public, Quaker recording clerk, Justice of the Peace, tribal elder, PGP certificate authority, W3C Verifiable Credentials issuer.

Layered rules โ€” each community sets its own bar

book club, low stakes: 1 peer attestation, 24h waiting period

union local: 1 notary OR 3 peer attestations + 7d waiting period

HOA, address-bound: 1 notary AND postal-address verification

constitutional vote: notarized + 90d membership + 3 prior decisions participated

The recursive loop (worth being honest about)

Who becomes a notary is itself a governance decision the community makes through the system whose identity layer the notaries are anchoring. The polity decides who can verify membership in the polity. This is a circular dependency by design.

Every actual democratic system has this loop. Voter rolls are maintained by people whose authority comes from voter rolls. The honest move is to provide good primitives for managing the loop โ€” notary appointment, revocation, plurality requirements, term limits โ€” rather than pretend to break it with appeals to outside authority. State ID, biometrics, and blockchain "trustlessness" all import their own gatekeepers. We don't.

Founders self-attest at v0. Every constitution has a constitutive moment. Subsequent rounds are governed by the rules the founders bootstrapped. That is the system working.

Voting as a primitive

Voting on united.social is list-ranking: a member upvotes items on a list. One vote per DID per item, toggleable. The platform records that a member voted. It does not record why. It does not encode what voting means.

The insight that shaped this design came from a reader: a ranked list of billionaires, no instructions, no editorial guidance on how to vote โ€” people decide for themselves. The list is the question. The order is the answer. The platform stays out of it.

This is structurally different from Reddit (voting is one signal among many; editorial moderation is heavy), polls (single question, fixed options, treated as opinion data), and petitions (directional, goal-bound). It is closer to: publish a list, let the public rank it, the platform doesn't grade it.

Communities and list-creators define interpretation. A "guilty" list is a consumer concern, not a platform concern. The same primitive handles conviction lists, proposal ranking, resource allocation, bylaws prioritization, and anything else communities invent.

Time-depth and authority

Time-of-presence is a real signal. A 30-year HOA member can verify other long-time residents in ways a 30-day member cannot. In settler-colonial contexts, the people who occupied land longest had legitimate authority โ€” including the authority to define who belongs โ€” that was erased by force. Restoring that authority is a serious political project.

But "longest occupier wins" as a universal platform rule breaks badly. Most populated land has had multiple waves of occupation; every side claims time-depth and every claim has receipts. The same logic powers blood-and-soil nationalism. People moved against their will โ€” refugees, the climate-displaced, descendants of the enslaved โ€” have low time-depth in their current location through no fault of their own. A rule that disenfranchises them is morally indefensible.

united.social distinguishes four interpretations and takes a position on each:

embraced

1. Indigenous sovereignty primacy

Indigenous polities take precedence in settler-colonial contexts. When indigenous nations use united.social, they bring their own membership protocols, attested by their own elders and councils, recognized by the platform as authoritative for their own polities. The platform does not validate them. It does not pretend to. They are governing themselves through it.

embraced

2. Notary weight scales with tenure

A notary who has held their role for years carries more weight than a newly issued credential. This rewards continuity without requiring it. Communities can override the default; the default is to honor it.

embraced

3. Time-depth thresholds as a per-community rule

Each community can require N years of residency for full voting rights. Standard civic-republican structure. Available as a primitive; not imposed as a default.

refused

4. Universal "longest occupier wins"

The platform does not privilege priority of arrival on land in resolving any membership question. It records claims. It does not adjudicate sovereignty disputes. That is not a bug โ€” it is a refusal to import a problem the platform cannot solve.

Cross-community attestation chains weight prior polities higher when chains traverse indigenous rosters on the relevant land. This is a settable rule per consuming community. The recommended default is to honor it.

Explicit non-goals

  • โ€”Global personhood verification. united.social verifies that a DID is a real member of a specific community by that community's own bar โ€” not that a DID corresponds to a unique real human in the world. Membership-as-identity, not personhood-as-identity.
  • โ€”Adversarial sybil resistance against state-level attackers. A state actor can stake out meetups and attempt to compromise notaries. The system tolerates this risk and partially mitigates it. It does not pretend to defeat it.
  • โ€”Editorial neutrality as cover for harm. The "no editorial framing" claim does not extend to allowing target lists. Some baseline content policy is required and enforced. The platform stays neutral on what lists mean; it does not stay neutral on whether lists are designed to cause harm.

Stack

  • identity substrate: AT Protocol DIDs + signed records
  • app data: Cloudflare D1 (SQLite at edge)
  • cache + session: Cloudflare KV
  • frontend: TanStack Start (SSR) + React 19 + Tailwind v4
  • deploy: Cloudflare Workers via Wrangler