Seed Hypermedia (SHM) is a decentralized publishing protocol. You create documents that are cryptographically signed, version-tracked, and can sync peer-to-peer without relying on a central server. Think of it as Git meets Google Docs, but with real ownership.

With a regular website, a hosting provider controls your content. They can take it down, modify it, or disappear. With SHM, your content is signed with your cryptographic key. Nobody can alter it without your private key. Multiple peers can host copies, and readers can verify authenticity regardless of where they got it.

No. The desktop app handles everything locally. Your content syncs through gateways — public servers that relay documents between peers. You can also self-host a gateway if you want full control, but it's not required to get started.

The desktop app runs on macOS, Windows, and Linux. There is no mobile app yet — this is a real limitation. On mobile, you can view content through web gateways, but you can't create or edit documents.

This is the hard truth: if you lose your key and don't have a backup, you lose the ability to update your documents. Your existing published content remains accessible on any peer that has it, but you can't sign new changes. There's no "forgot password" flow. Back up your key. The desktop app stores it in your system keychain, but you should also export a backup.

Yes, through key delegation. Your main key can authorize device-specific keys, so each device has its own signing capability without sharing your root private key. If a device is compromised, you revoke just that device's key.

Your account is identified by a public key (starting with z6Mk...). Anyone with your key can verify that your documents were genuinely signed by you. For human-readable discovery, you can set up DNS aliases that map a domain name to your account key. See the Identity Verification guide for details.

Documents support rich text with paragraphs, headings (three levels), code blocks with syntax highlighting, images, videos, file attachments, embedded references to other documents, mathematical equations, and web embeds. The block-based editor is similar to Notion.

Yes. The document owner can grant WRITER or EDITOR roles to other accounts using the access control system. Multiple writers can make changes concurrently — SHM uses CRDTs (Conflict-free Replicated Data Types) to merge changes automatically without conflicts. It's not real-time collaborative editing like Google Docs, but it handles concurrent offline edits gracefully.

Yes, complete version history. Every change creates a new entry in the Change DAG (Directed Acyclic Graph). You can see who changed what, when, and traverse the full history. Changes are content-addressed, so history is tamper-evident.

You can delete documents from your local node, and you can create redirect or tombstone references to signal that content has moved or been removed. However, since content may have been replicated to other peers, you cannot guarantee deletion from the entire network. This is inherent to any decentralized system — it's similar to how you can't unsend an email.

Currently, through direct links. There is no built-in search engine or discovery mechanism — this is one of SHM's biggest gaps. You share hm:// URLs directly, link from other platforms, or set up a custom domain. The network is still small, so there's no equivalent of Google for SHM content yet.

A gateway is a server that participates in the SHM peer-to-peer network and also serves content over regular HTTPS. When you visit hyper.media, that's a gateway rendering SHM documents as web pages. Gateways make content accessible to anyone with a browser, without requiring them to run SHM software.

Yes. Everything is local-first. You can create, edit, and browse your documents completely offline. When you reconnect, changes sync automatically through the peer-to-peer network. This is one of SHM's strongest features.

The daemon is written in Go. The desktop app uses Electron with React. Documents are stored as DAG-CBOR blobs (content-addressed using IPFS CIDs). Networking uses libp2p. Cryptographic signing uses Ed25519 keys. The protocol communicates via gRPC with Protocol Buffers.

SHM uses IPFS content addressing (CIDs) for blobs, but it's not a general file storage system. SHM adds a document layer on top: structured content with signing, versioning, access control, and rich editing. IPFS is infrastructure; SHM is an application protocol built using some of the same primitives.

Nostr is optimized for short social messages with relay-based distribution. AT Protocol (Bluesky) is built around social networking with custodial hosting. SHM is focused on long-form documents and knowledge publishing. The key difference is SHM's document model — structured, version-tracked, collaboratively editable content rather than social feeds. See the detailed comparison pages for more.

Mostly, but not fully. The protocol is at version 0.9.x, which means breaking changes can still happen. In practice, the core document format has been stable for a while, but version mismatches between nodes occasionally cause sync issues. This is expected to stabilize as the protocol approaches 1.0.

Being honest:

Setup complexity. Running a daemon, managing keys, understanding gRPC — the learning curve is steep compared to creating a WordPress site or a Notion page.

No mobile app. Desktop only for authoring. This limits adoption significantly.

Small network. Few users means limited content and limited reasons for new users to join. Classic chicken-and-egg problem.

No search or discovery. You need to already have a URL to find anything.

Gateway dependency. While architecturally peer-to-peer, in practice most content is accessed through gateways. If the main gateway goes down, content becomes harder to reach (though not lost).

Key management UX. Backup, recovery, and rotation are not as smooth as they should be for mainstream users.

Because the architecture is right. True ownership, cryptographic identity, version history, offline-first, collaborative editing — these are the correct foundations for the next era of publishing. The rough edges are UX problems, not fundamental flaws. If you believe in where decentralized publishing is heading and want to build on solid foundations, SHM is worth the early-adopter friction.

Getting Started Guide — Set up SHM and create your first document

Desktop App Guide — Full walkthrough of the desktop application

Security Model — How SHM protects your content and identity

Comparisons — How SHM compares to AT Protocol and ActivityPub