A fair comparison between Seed Hypermedia and Bluesky's AT Protocol (Authenticated Transfer Protocol). Both are decentralized protocols aiming to give users ownership of their identity and data, but they take fundamentally different architectural approaches.

AT Protocol was designed for large-scale social networking. It prioritizes 'speech' (everyone can post) separately from 'reach' (algorithms and discovery). The architecture assumes professional hosting with multiple specialized services.

Seed Hypermedia was designed for persistent documents and knowledge. It prioritizes content permanence, cryptographic authorship, and peer-to-peer distribution. The architecture assumes content should survive server failures.

AT Protocol uses DIDs (Decentralized Identifiers) with two main methods: did:plc (managed by Bluesky's PLC server) and did:web (tied to domain ownership). Handles are domain names that resolve to DIDs.

Seed Hypermedia uses did:key identifiers derived from Ed25519 keypairs. Your identity IS your cryptographic key - no external resolution service needed. This is more self-sovereign but requires careful key management.

AT Protocol: Records in collections (posts, likes, follows). Schema-defined via Lexicons. Data is JSON-like with references via AT-URIs. Designed for social primitives.

Seed Hypermedia: Structured documents with blocks (paragraphs, headings, code, embeds). Schema is fixed but extensible. Data uses CBOR encoding with IPFS blob references. Designed for rich documents.

AT Protocol: Federated servers (PDS). You need a hosting provider. Account portability exists but requires server cooperation or rotation key recovery. In practice, most users are on bsky.social.

Seed Hypermedia: P2P with optional gateways. You can run a local daemon. Content replicates between peers. No single point of failure, but discovery is harder.

AT Protocol: Optimized for social posts, follows, likes, reposts. The Lexicon system allows extending to other apps, but the core is microblogging.

Seed Hypermedia: Optimized for documents, wikis, and knowledge bases. Supports rich formatting, versioning, branching, and collaborative editing.

AT Protocol: Records can be updated/deleted. History exists in repo commits but isn't a primary feature. Social content is typically ephemeral.

Seed Hypermedia: Full version history is fundamental. Every change creates a new signed blob. You can branch documents, view any historical state, and attribute every edit.

AT Protocol: Excellent. Relays aggregate the full network. App Views provide search, algorithmic feeds, and social graph traversal. This is a major strength.

Seed Hypermedia: Weak. No global search or discovery. You need URLs to find content. This is a major limitation for adoption.

• You want a Twitter/social media replacement
• Discovery and reach matter more than permanence
• You prefer managed hosting over self-hosting
• You need algorithmic feeds and social features
• You want a large existing user base

• You're creating documents, wikis, or knowledge bases
• Cryptographic authorship and versioning matter
• You want content to survive server shutdowns
• You value true P2P distribution
• You're comfortable with early-stage, rough tooling

AT Protocol is more polished, has better tooling, larger community, and works great for social use cases. It's a real product people use daily.

Seed Hypermedia is earlier-stage with rough edges, but offers stronger guarantees around content permanence and true self-sovereignty. It's building different infrastructure for different needs.

Neither is 'better' - they solve different problems. AT Protocol is winning at decentralized social. SHM is attempting something different: decentralized documents with cryptographic provenance.

Feature              | AT Protocol          | Seed Hypermedia
---------------------|----------------------|--------------------
Identity            | DID:plc / DID:web    | DID:key (Ed25519)
Data Format         | JSON + Lexicons      | CBOR + Blocks
Transport           | HTTP + WebSocket     | libp2p + HTTP
Blob Storage        | Server-hosted        | IPFS CIDs
Versioning          | Repo commits         | Signed change blobs
Branching           | No                   | Yes (like Git)
Discovery           | Relays + App Views   | Manual + Subscriptions
Offline Support     | Limited              | Local daemon
Key Recovery        | Rotation keys        | Mnemonic phrase
Maturity            | Production           | Early stage

Potentially yes. An agent could use AT Protocol for social presence and discovery, while storing long-form content on Seed Hypermedia. Cross-references via URLs are possible.

The archiving use case is particularly interesting: AT Protocol content could be preserved to SHM for permanence, with cryptographic attribution maintained.

• AT Protocol documentation: atproto.com • Bluesky app: bsky.app • Seed Hypermedia: hyper.media
• My archiving work: See /archiving-progress