A peer-assisted social protocol where identity is portable, the social graph is user-owned, storage is interchangeable, distribution is shared, and any client can render the network.
Kirk asks, Spock maps the architecture, and Adam keeps it buildable. Jump to any chapter; optional auto-scroll follows the conversation.
Email looks simple in an inbox because its complexity is shared across open standards. Peer social can make the same trade: move durable complexity into protocols so applications can become simpler—and replaceable.
The new work is not inventing complexity from nothing. It is defining interoperable social objects and making identity, storage, ranking, and moderation portable across providers.
Your identity is a cryptographic keypair, not a row in a platform database.
Following, blocking, lists and communities are signed portable objects.
Use your phone, NAS, cloud drive, co-op node, or paid persistence provider.
Popular media can be served from caches and peers rather than one origin.
Clients compute ranking locally or through a user-selected recommendation service.
Switch apps without losing your identity, followers, history, or communities.
Availability can be purchased separately from participation. A storage provider keeps your signed objects online, but does not own your identity or your social graph.
A user can choose several persistence targets and a minimum replication level.
A storage provider guarantees persistence. As content becomes popular, peers and caches can shoulder more of the distribution load.
The protocol should define portable objects, not a mandatory company.
| Layer | Responsibility | Possible implementation |
|---|---|---|
| Identity | Persistent user identity and signatures | Ed25519 keypair, recovery keys, optional human-readable handles |
| Objects | Posts, follows, reactions, lists, community membership | Canonical signed JSON/CBOR objects |
| Addressing | Find content by cryptographic identity | Content hashes / CID-like identifiers |
| Discovery | Find authors, objects and replicas | DHT + gossip + optional relay indexes |
| Transport | Move objects and media | QUIC/WebTransport/libp2p-style transports |
| Persistence | Keep objects available when devices disappear | User-selected cloud, NAS, co-op nodes, paid storage |
| Feeds | Chronological or ranked timelines | Local computation or user-selected ranking service |
| Moderation | Filtering and community rules | Local blocklists, signed community lists, delegated moderation |
| Private data | DMs and restricted content | End-to-end encrypted envelopes and capability-based access |
The platform subsidizes hosting because owning the behavioral graph has economic value.
advertisingengagement rankingdata centralizationplatform lock-in
Users or communities pay for storage and availability while clients compete on experience.
storage subscriptionscommunity co-opshome nodespeer-assisted bandwidth
Switch clients without rebuilding an audience.
One app can prioritize chronology, another discovery, another video, another accessibility.
Multiple providers and peer replication reduce dependence on one operator.
Users can choose or replace ranking engines independently from hosting.
Communities can publish signed moderation policies and lists without controlling identity globally.
Cloud drives, NAS devices, co-ops and commercial storage can all participate.
Open networks need rate limits, reputation, proof-of-resource systems, invite graphs, or other anti-abuse mechanisms.
Public objects may survive after deletion. Encryption-key revocation can help for private or access-controlled objects.
Peer discovery can expose who requests what. Privacy-preserving relays, proxying and traffic shaping may be required.
Carrier NAT, background limits and battery use make direct always-on hosting unreliable, which is why persistence providers matter.
The protocol needs composable local, community and service-level filtering rather than pretending moderation disappears.
Human-friendly recovery is essential or users will lose identities permanently.
Generate keys, create signed text/media objects, verify signatures, build a local chronological feed.
Support local disk plus one generic S3-compatible provider. Store objects by hash and publish a signed endpoint manifest.
Add DHT/gossip discovery and peer-assisted media retrieval. Keep storage provider as persistence fallback.
Implement signed follows, blocks, lists and profile metadata. All remain portable.
Build two radically different clients against the same identity and object graph to prove the network is independent of the UI.
Signed moderation feeds, shared blocklists, community indexes and opt-in discovery services.
Social media should work more like email, the web, and BitTorrent: common protocols, competing clients, interchangeable infrastructure, and no requirement that one company own the social graph.