Hosted oncibercultura-25-26.hyper.mediavia theHypermedia Protocol

Why Not ActivityPub?ActivityPub brought federation to the mainstream, but its server-centric design doesn't address content integrity, permanent links, or author-level signatures- gaps that our protocol aims to fill.

    ActivityPub has done something remarkable: it brought federation to the mainstream. Millions of people now use Mastodon and other fediverse apps, and many have experienced for the first time what it feels like to choose your own server. That matters.

    But as we work on the Hypermedia Protocol, people sometimes ask why we didn't just build on ActivityPub. The honest answer is that ActivityPub solves a different problem than the one we're focused on.

    What ActivityPub does well

      ActivityPub makes it easy for servers to talk to each other. It uses familiar web technologies—HTTP, JSON—so developers can build compatible software without learning new concepts. It has a real ecosystem and real users. These are genuine achievements.

    Where it falls short for us

      Our work centers on a few principles that ActivityPub doesn't address:

      Content integrity. In ActivityPub, content lives on servers and can be changed at any time. There's no built-in way to verify that what you're reading is what the author actually wrote. You trust the server.

      Permanent links. When an ActivityPub server shuts down, all the links to content on that server break. The content may exist somewhere as a backup, but the addresses stop working. Links are tied to servers, not to content.

      Author signatures. ActivityPub uses signatures to verify that messages came from a particular server, but it doesn't sign the content itself. This means you're trusting the server operator, not the author directly.

      These are design choices that led to an easy-to-adopt standard. ActivityPub was built to federate social interactions across servers, and it does that. But if you care about content that stays verifiable and linkable even when servers come and go, you need different foundations.

    A different approach

      Protocols like HMproto take a different path. Content is signed by authors, not servers. Links point to content itself, not to fragile URLs. Anyone can verify that a HM document is authentic, and links work as long as anyone, anywhere, still has a copy.

      This approach has tradeoffs too. It's harder to build, harder to explain, and the tooling is less mature. We're still figuring out many of the details.

    No wrong answers

      We don't think ActivityPub is bad. It brought decentralization to people who had never thought about it before. That's valuable.

      But we think there's room for protocols built on different assumptions: protocols where your content truly belongs to you, where links don't rot, and where trust grows from cryptography rather than server operators.

      That's what we're building toward.