Nostr vs ActivityPub
Nostr and ActivityPub both push back against platform lock-in, but they place identity, servers, delivery and moderation in different parts of the system.
Why the comparison matters
Nostr and ActivityPub are often placed in the same mental bucket because both resist centralized social platforms. That bucket is too broad. ActivityPub is a W3C standard for federated social networking built around actors, inboxes, outboxes, activities and server-to-server delivery. Nostr is a public-key event protocol built around clients, relays and signed events.
The comparison matters because new users ask the practical question: why not just use Mastodon or another ActivityPub service? The answer is not that one is morally pure and the other is obsolete. They solve different parts of the open social problem with different tradeoffs.
ActivityPub in one page
ActivityPub gives actors inboxes and outboxes. A user's server can deliver activities to other servers. Mastodon made this model familiar: an account has a home instance, the instance federates with other instances, and moderation often happens at the instance level. The server is a social home, an identity host, a policy boundary and a federation participant.
That architecture has strengths. It can feel understandable to users because an instance is a place. It can support community moderation. It can reuse web standards. It can give administrators tools to block, limit or curate federation. For many communities, that server-shaped social home is a feature.
Nostr in one page
Nostr starts elsewhere. The identity is a key pair. Events are signed. Relays carry and store events. Clients query relays and render the results. A relay can have policy, but it is not the identity host. A client can have moderation, but it is not the whole network. The user can publish to multiple relays.
That gives Nostr a different feel. It is less like joining a town and more like carrying a passport that many rooms can read. The rooms may still have rules. Some may refuse entry. Some may be badly run. But the identity is not created by the room.
Identity differences
In ActivityPub, a user identity is commonly tied to a server domain, such as user@instance. That is human-readable and socially intuitive. It also means the server is central to the account's presence. Moving can be possible, but the instance relationship remains a core part of the model.
In Nostr, the public key is the identity. A NIP-05 identifier can add a domain-backed human name, but the key remains the anchor. That makes identity more portable across clients and relays, but it puts more burden on key safety and user education.
Server differences
ActivityPub servers federate with each other. Delivery between servers is part of the model. Nostr relays generally do not need to talk to each other. Clients connect to relays. Users and clients decide where to read and write. This makes the relay model simpler in one sense and harder in another.
The simplicity is that relays can be dumb transport and storage pieces. The difficulty is discovery. If clients do not know where to look, events feel missing. Nostr pushes more responsibility to clients, relay lists and discovery heuristics.
Moderation differences
ActivityPub moderation often centers on instances. Administrators can block users, domains or servers. Communities can define norms through their home instance. This is legible, but it can also create instance politics and federation fractures.
Nostr moderation is more distributed. Relays can reject events. Clients can filter. Users can mute. Labelers and web-of-trust systems can add signals. No single moderation layer is the whole system. That can be powerful for pluralism and confusing for people who expect one place to handle every abuse problem.
Migration and portability
ActivityPub has account migration tools in some software, but the server remains part of identity. Nostr's public-key model makes client switching more native. The same key can appear in many apps. Follow lists and profile metadata can be signed events. Relay choices still affect visibility, but the identity is not inside one client.
The trade is harsh key management. ActivityPub users can often rely on server account recovery. Nostr users have to understand private keys and signers. Portability moves power to the user and also moves responsibility there.
Which one fits which job
ActivityPub fits communities that want recognizable homes, server-level governance, federation and mature social software. Nostr fits cases where portable identity, client competition, payment experiments, censorship resistance and signed event data matter more than server-centered community identity.
The open social web is large enough for both. The useful comparison is not a fan fight. It is a map: ActivityPub makes the server home important; Nostr makes the key important. Once you see that, many product and culture differences become easier to understand.
The biggest user-experience difference
The biggest user-experience difference is the home base. In ActivityPub, the instance is a visible home. The user often joins a server, follows people across federated servers and inherits some of the server's culture, policy and reliability. In Nostr, the home base is the key. Relays and clients may feel like rooms, tools or roads, but they are not the root identity.
That makes ActivityPub easier for many people to understand at first. It also makes the instance a major social and political actor. Nostr is harder to explain at first because the home base is abstract. Once understood, that abstraction gives more room to switch clients and publish through multiple relays.
Neither model removes governance. ActivityPub locates much governance in server administration and federation relationships. Nostr distributes governance across relays, clients, labels, lists, web-of-trust systems and user choice.
Where ActivityPub is stronger
ActivityPub is stronger when a community wants a recognizable server home, mature federation software and administrator-led policy. Mastodon and other ActivityPub projects have years of operational practice around instances, moderation, federation blocks and community norms. That matters.
A server home can create belonging. It can make onboarding easier. It can give users a place to ask for help. It can let communities define rules in a visible way. For many non-technical users, an instance is more comprehensible than a relay set and key pair.
This is why ActivityPub remains important in any serious open social map. Nostr does not erase the value of server-based communities. It offers a different approach for cases where key-centered portability and client-relay simplicity matter more.
Where Nostr is stronger
Nostr is stronger when the identity needs to survive app choice and server choice with minimal ceremony. The public key is the anchor. Relays can be replaced or multiplied. Clients can compete. Signed events can be verified outside the relay that served them.
Nostr is also stronger for experiments that want a small protocol surface: zaps, wallet connections, relay-specific tools, lightweight publishing, signed badges, event-driven apps and simple clients. A builder can implement the basic model without becoming a full social server operator.
The price is that more product work moves to the edges. Discovery, moderation, storage, search and onboarding need careful client and relay design. Nostr's strength is not that it solves these issues automatically; it makes it possible for many actors to solve them differently.
How to choose the comparison frame
Do not compare Nostr and ActivityPub only by asking which is more decentralized. Ask where identity lives. Ask who stores data. Ask how delivery works. Ask where moderation happens. Ask how a user moves. Ask what a builder has to run. Ask what breaks when a server disappears.
For ActivityPub, watch the instance. For Nostr, watch the key and relays. For ActivityPub, migration often means moving server identity. For Nostr, migration often means changing clients or relays while keeping the key. For ActivityPub, federation is server-to-server. For Nostr, clients query relays.
That frame turns a vague debate into product understanding. It also keeps the reader from treating either protocol as a religion.
What happens when the home server fails
In ActivityPub, the home server is central to the account. If an instance shuts down or becomes hostile, migration can be possible, but the server relationship matters deeply. The user has a home, and that home has administrators, policies, uptime, federation relationships and local norms.
In Nostr, the public key is the root identity. A relay can disappear without deleting the key. A client can change without changing the key. That is a different failure mode. It protects identity from one server collapse, but it makes relay reachability and backup strategy more visible to the user.
The comparison is therefore not "server bad, key good." It is a choice between different centers of gravity. ActivityPub gives communities a recognizable home. Nostr gives individuals and builders a more portable cryptographic anchor.
The moderation trade
ActivityPub moderation often begins with the instance. Administrators can suspend accounts, block other servers, enforce local norms and make policy visible. This can create strong community protection when the instance is well run. It can also create political friction when servers disagree or users feel trapped by local decisions.
Nostr moderation is more layered. Relays can reject events. Clients can mute, filter, label or rank. Users can carry lists. Communities can gather around specific relays or groups. This avoids one universal policy, but it can make enforcement less predictable for ordinary users.
A reader choosing between these models has to ask what kind of governance they want. Do they want a server community with administrators? Do they want client and relay choice? Do they want strong default moderation or maximum portability? Serious answers depend on context.
Developer cost and operational shape
For builders, ActivityPub often means thinking like a federated server operator. The software speaks to other servers, handles accounts, stores posts, manages moderation and participates in a federation. That can be powerful, but the operational shape is heavier than a small client or relay experiment.
Nostr lowers the primitive entry point. A builder can write a client that connects to existing relays, a relay with a specific policy, a signer, a bot, a wallet integration or a small event tool. The hard part moves from federation operation to product quality, discovery, spam resistance and key safety.
This is why Nostr has so many experiments. The base is easy to touch. The challenge is turning experiments into durable tools that respect users.
The social meaning of instances and keys
An ActivityPub instance can feel like a town. It has a name, rules, administrators and neighbors. People can identify with it. That social shape is valuable. It gives users a place to belong and gives moderators a visible mandate.
A Nostr key feels more like a passport. It can enter many clients and relays, but it does not automatically provide a home community. Communities have to be built through follows, relays, groups, lists, events, clients and culture. That can feel freer or lonelier depending on the person.
The Basics page keeps this distinction visible because it explains why people disagree honestly. They are not only debating technical plumbing. They are debating what kind of social home the web needs.
Identity before delivery
The clearest way to compare Nostr and ActivityPub is to separate identity from delivery. ActivityPub begins with actors and inboxes/outboxes on servers. The server is a major part of the account context. Nostr begins with a public key and signed events. Relays help move and store those events, but they are not the root account.
That difference affects everything else. In ActivityPub, the instance name often becomes part of social identity. In Nostr, the npub or verified domain relationship becomes more important. In ActivityPub, server-to-server delivery is a core social path. In Nostr, clients query relays and verify signatures.
A reader who understands this will stop asking which protocol is simply more open. They will ask which identity model fits the job. Communities may prefer server homes. Individuals and app builders may prefer key-centered portability.
What Mastodon made visible
Mastodon made federation visible to many people for the first time. Users learned that a social network could have many servers, local rules, federation blocks, administrators and community norms. That was a major cultural achievement even for people who later found the model difficult.
Nostr inherits some of the same platform skepticism, but it takes a different route. It does not ask the user to pick an instance as the account home. It asks the ecosystem to work around public keys, relays and clients. That gives more portability at the identity layer and less built-in community shape at the account layer.
This is why comparisons need respect. ActivityPub solved real problems for real communities. Nostr solves a different set of problems and creates a different set of difficulties. A serious reader can learn from both.
Where bridges get complicated
Bridges between protocols sound attractive because people want one social world. The hard part is that identity, moderation, delivery and content semantics do not line up perfectly. An ActivityPub actor is not the same thing as a Nostr public key. A server block is not the same thing as a relay policy. A boost is not always the same thing as a repost event.
A bridge has to translate choices, not only formats. It has to decide how to represent replies, deletes, edits, profile metadata, media, blocks, mentions and abuse reports. It also has to decide whose policy applies when communities disagree. Those choices are social, not merely technical.
That does not make bridges bad. It makes them translation layers. Readers should treat them as products with policies and tradeoffs, not as neutral pipes between identical worlds.
Why the instance still matters
The instance model remains powerful because people like homes. A good instance can give new users support, culture, rules, shared expectations and a clear place to appeal when something goes wrong. It can make open social feel less lonely.
Nostr has to recreate some of that through clients, communities, relays, groups, lists and people. A key is portable, but a key alone does not welcome anyone. The social layer has to be built deliberately. That is why Nostr community design matters as much as protocol design.
The comparison leaves the reader with a useful question: do I need a home first, or do I need a portable identity first? Many social tools will answer that question differently.
What ActivityPub teaches Nostr
ActivityPub teaches Nostr that governance cannot be hand-waved away. Communities need rules, abuse handling, appeal paths, moderation tools and clear expectations. If Nostr products pretend that key portability alone solves social conflict, ordinary users will not trust the network.
It also teaches the value of visible community context. A user joining an instance can often read the local culture before posting. Nostr clients and relays need equally clear signals: what kind of space is this, what does it filter, what does it store, who operates it and how do users leave?
Nostr can keep its key-centered architecture while learning from the operational maturity of federated communities. That is not a compromise of principle. It is a sign that the ecosystem is growing up.
What a user migrates
Migration means different things in the two systems. In ActivityPub, migration often means moving from one server identity to another server identity, carrying followers where the software and policies allow it. The instance remains part of the story. In Nostr, migration often means changing clients, relays or publishing habits while keeping the same key.
That makes Nostr migration feel lighter in some cases and harsher in others. Changing clients can be easy. Recovering from a compromised key can be very hard. Changing relays can preserve identity, but old events may not be available everywhere. The key is powerful, but it is not a magic undo button.
A reader comparing protocols should ask what they are trying to escape. A bad app? A bad server? A lost password? A hostile administrator? A broken relay? Each model handles those failures differently.
What ActivityPub users may find strange
ActivityPub users may find Nostr strange because there is no obvious home instance at the center. The key is portable, but the social room is assembled from clients, relays, follows and community habits. That can feel open and disorienting at the same time.
They may also find Nostr moderation less legible. Instead of one instance policy, there may be client filters, relay policies, mute lists, labelers and social trust tools. This gives more choice but requires better interfaces. Without those interfaces, choice feels like fragmentation.
The bridge for ActivityPub readers is to treat the Nostr key as the home base and relays as places the client visits for data. Once that clicks, the model becomes less alien.
What Nostr users can learn from instances
Nostr users can learn from instances that social software needs welcome, support and boundaries. A protocol can be open and still need rooms with expectations. A relay or group that explains its policy clearly can feel more humane than a supposedly open space where nobody knows what is happening.
The instance world also shows that moderation labor is real labor. Administrators handle spam, harassment, conflict, appeals, blocks and culture. Nostr cannot wish that work away. It can distribute it, make it plural and give users more exit options, but someone still has to do the work.
This lesson matters because Nostr culture can sometimes confuse absence of a central authority with absence of governance. The healthier view is that governance moves to many layers and needs better tools at each one.
