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.
Hosting should be a replaceable service to a user-owned social layer: persistence, replication, recovery, and reach without custody of identity, relationships, or the right to migrate.
Posts, media, follows, blocks, lists, community memberships, and signed endpoint records need complete, documented export.
A user should be able to maintain independent replicas and verify that each copy resolves to the same signed objects.
Loss of a phone, client, or provider should trigger key and content recovery—not loss of identity or relationships.
Changing persistence providers must not require a new account, a rebuilt audience, or new canonical content identifiers.
Storage, traffic, discovery, and moderation metadata require explicit limits; encryption at rest does not hide access patterns by itself.
Revocation, retention, deletion requests, billing exit, and endpoint updates need testable behavior rather than a promise of portability.
Architectural reference, not an announced integration: Holo’s hosting model illustrates how dedicated nodes can add availability, DHT replication, relay, and web access to a peer application. Peer Social could use that division of labor, but would still need its own interoperability, export, metadata, recovery, and deletion rules.
Primary references: Holo hosting services, Holochain DHT and replication, and Holochain deletion constraints.
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.
Surveillance becomes socially operative when people know that activity can be linked to identity, scored, and returned as a consequential decision. A peer protocol does not escape that problem merely by distributing storage. It must keep any observer from quietly becoming the tower.
Support purpose-bound keys and unlinkable contexts instead of requiring one permanent public identifier for every relationship.
Local or selected recommendation should disclose inputs, allow reset and export, and never become a hidden eligibility score.
Replication, discovery, traffic, moderation, and payment metadata need minimization—not only encryption of stored content.
A user must be able to replace a host, feed, moderation service, or client without losing identity, relationships, or appeal rights.
Some shared visibility is necessary for trust and abuse response.
Make scope, retention, actor, reason, result, and undo paths legible to the person affected.
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.