federation-across-networks

Nostr and the Protocol Bridges

Part 3 of Federation Across Networks. Part 1 covered Bridgy Fed and AT Protocol. Part 2 covered Threads' entry into the Fediverse. This series sits inside the broader Exploring the Fediverse umbrella.

Federated Mind

— 12 min read
Share
Three protocol logos — ActivityPub, AT Protocol (Bluesky), and Nostr — arranged over a dark network graph visualization.
Three independently designed bets on the open social web.

The last post in this series ended with a provocation: Nostr ignores the Fediverse by design, not by accident. That's true at the protocol level: Nostr's core spec is deliberately self-contained, making no provision for ActivityPub or cross-protocol federation. What emerged in the ecosystem around that protocol is a different story.

Nostr ("Notes and Other Stuff Transmitted by Relays") doesn't have instances. It doesn't federate. There are no servers exchanging messages, no instance admins negotiating trust, no canonical directory of nodes. There are only key pairs, signed events, and relays. The relays don't need to know each other exist.

Jack Dorsey funded Bluesky's AT Protocol, then resigned from its board in 2024, saying Bluesky was "literally repeating the mistakes of Twitter" on moderation. He's since directed significant funding toward open-source social protocols, including a reported $10 million to a nonprofit collective building tools on Nostr and ActivityPub. In a conversation with rabble on Revolution.Social, he said Twitter "never should have been a traditional tech company." It "should have been designed as a protocol, like email, or podcasting. That was the pure expression of it from day one." Nostr is, by Dorsey's own logic, closer to what Twitter should have been: a protocol, not a platform.

💡
Editor's note: BTW, Revolution.Social and rabble are doing some of the most interesting long-form conversations on decentralized social and open protocols. Worth noting: rabble is also building diVine, a Vine-style 6-second looping video app built on Nostr. The post that started this publication used Vine's shutdown as the canonical example of why you can't own an audience on someone else's platform.

Smart clients, dumb relays

Nostr's departure from ActivityPub and AT Protocol starts with identity: public-key cryptography instead of server accounts.

Every user on Nostr is a public/private key pair. Every action (post, follow, reaction, profile update, deletion request) is a signed JSON "event": a small packet with fields like kind, content, pubkey, created_at, and sig. The client creates the event, signs it with the user's private key, and broadcasts it over WebSocket connections to one or more relays. Relays store it and serve it to clients that ask. That's the whole protocol.

The protocol's simplicity becomes clearest at the wire level. It exposes exactly three operations to a client: publish an event, open a filtered subscription, or close one. A Nostr client sends these as three message types to a relay: EVENT(publish an event), REQ (open a subscription with filters), and CLOSE (end a subscription). The relay sends back events that match open subscriptions, an EOSE marker when it's finished replaying stored events, OK to acknowledge or reject writes, and NOTICE for human-readable status messages. Everything that makes Nostr feel like a social app (feeds, threads, search, profiles, follows, Lightning tips) is built on top of those seven message types. (Newer extensions add AUTH and COUNT to this surface, but these seven are the foundation; more on the extension system shortly.)

The relay's job ends at storage and filtering. Relays don't route to each other. A relay can accept or reject any event for any reason (content filter, paid subscription, invite-only list) but it has no power over your identity, because your identity isn't hosted there. Your key pair exists independently of every relay you've ever written to.

Nostr client-relay architecture: a key pair signs events that a client app broadcasts over WebSocket connections to multiple relays.
Every identity is a key pair. Every action is a signed event.

 

The contrast with ActivityPub is direct. On Mastodon, your account is your instance: @you@mastodon.social lives at mastodon.social, and if that instance shuts down without warning or bans you, your identity goes with it. AT Protocol improved on this by separating your identity (a DID, or decentralized identifier, anchored in a portable data repo) from the host that serves it. Nostr takes the same principle further: the key is the identity. No host, no DID resolution, no intermediate. You are the key.

In practice, your Nostr posts and follows exist on whichever relays you've chosen to write to (typically three to ten for redundancy). Use the same key pair in Damus on iOS, Amethyst on Android, and Primal on web, and you're accessing the same identity across all of them. Lose access to a relay; write to another. The relay failing doesn't cost you your account, as long as you still control your keys and can write to other relays.

Everything is a kind

At the protocol level there's only one object type (the event), and a kind number tells clients what it represents.

kind: 0 is a profile update: name, bio, picture URL. kind: 1 is a short note. kind: 3 is a contact list (your follows). kind: 30023is a long-form article. kind: 9735 is a Zap receipt: the Lightning payment confirmation.

The distinction between replaceable and regular events matters for how relays store them. Profile updates and contact lists are replaceable: for each (pubkey, kind) pair, relays keep only the most recent event. This keeps storage manageable and means "current profile" and "current follows" are always a single-event lookup. Notes and Zap receipts are regular events: every one is kept. Long-form articles are addressable events, keyed by (kind, pubkey, d-tag) (as defined in NIP-23), useful for versioning a document by slug.

Tags (e, p, a) express relationships between events and between users. An e tag on a note points to another event, forming a thread. A p tag points to a pubkey: a mention. Clients turn these tag graphs into the conversation and timeline UI that users actually see. The protocol has no concept of "thread" or "mention"; those are interpretations that clients build from tag relationships on plain events.

NIPs: how the protocol extends itself

Nostr's core is intentionally minimal. The extension mechanism that keeps it from being merely minimal is the NIP system: Nostr Implementation Possibilities, numbered proposals that specify new event kinds and behaviors. Any developer can propose a NIP; clients and relays choose which ones to implement.

NIPs have stretched the protocol well beyond simple microblogging:

  • NIP-01: the base protocol (signed events, basic query filters)
  • NIP-05: DNS-based identity verification. Instead of sharing a raw public key (npub1abc…), users can verify a human-readable alias like federatedmind@federatedmind.com by placing a JSON file at federatedmind.com/.well-known/nostr.json. The alias is convenience; the underlying identity is still the key.
  • NIP-23: long-form content (kind: 30023). Full articles with titles, summaries, and markdown bodies, stored as a distinct event kind.
  • NIP-57: Zaps. Lightning Network payments attached directly to events and profiles (kind: 9734 zap request, kind: 9735 zap receipt).

Zaps and the Bitcoin substrate

Every major open social protocol handles creator monetization differently. ActivityPub leaves it to third-party services (Ko-fi, Patreon, Liberapay, and similar). AT Protocol is in largely the same position today (most Bluesky users link out to external services from their profiles), though Bluesky has announced plans for a native subscription and monetization layer. Nostr grew up inside Bitcoin and Lightning circles, and NIP-57 zaps integrated Lightning payments deeply into the ecosystem early on.

A Zap is a micropayment over the Bitcoin Lightning Network, attached to a Nostr event through NIP-57. The sender specifies an amount in satoshis (the smallest unit of Bitcoin), their client generates a Lightning invoice via the recipient's Lightning address, the payment settles on Lightning, and a Zap receipt (a kind 9735 signed Nostr event) gets published to relays as a public record of the transaction. The whole flow can happen in one tap inside a client like Damus or Amethyst, without leaving the app.

The creator economics differ markedly from most other tipping systems. There's no platform intermediary taking a cut: the payment goes directly from Lightning wallet to Lightning wallet. There's no minimum payout threshold, no waiting period, no fiat conversion required unless you want it. A reader in Buenos Aires can send a few satoshis to a writer in Amsterdam and both sides see the confirmation in seconds.

Nostr originated in Bitcoin and Lightning circles and remains heavily used there, which explains why the protocol's cultural center of gravity differs from the Fediverse. These are generalizations, but directionally accurate ones: Mastodon communities tend to treat content moderation, instance governance, and federation policy as first-order concerns. Nostr communities tend to prioritize censorship resistance, self-custody, and monetary sovereignty. Both communities care about open infrastructure. They've built different cultures on top of that shared premise.

Note: Bitcoin and Lightning payments aren't my usual territory. I've tried to characterize them accurately, but if something here is technically wrong, I'd genuinely welcome a correction.

The relay layer

Not all relays are equal, and the choices you make about which relays to write to and read from shape your Nostr experience more than almost any other factor.

Free public relays (wss://relay.damus.io, wss://nos.lol, wss://relay.nostr.band) lower the barrier to entry but attract spam. relay.nostr.band runs full-text search and trending data, making it useful for discovery. wss://purplepag.es focuses on profile metadata (kind:0) and relay lists, making it fast for client-side profile lookups. Premium relays like wss://nostr.wine and similar paid relays charge a small fee (typically payable in Lightning) in exchange for spam control and higher reliability. Some power users run a private relay as a personal archive, writing all their events there and pulling from it on any device.

Relay-set asymmetry follows directly from this architecture. If Alice writes to relay sets A and B, Bob writes to B and C, and Mary reads only from C, then Mary can see Bob's posts but not Alice's, even if Alice and Mary both call themselves Nostr users. There's no global state. A "global" timeline in any Nostr client is just "all public events visible from this client's current relay set." Two users on different relay sets inhabit genuinely different networks, with no equivalent of the ActivityPub server-to-server federation that eventually syncs Mastodon instances together.

Relay-set asymmetry: your Nostr network is defined by which relays you read from.

 

The relay layer's governing tension: the architecture that makes permanent account-level censorship by any single operator nearly impossible also makes content discovery depend entirely on client-level curation and relay selection. No single relay or operator can delete your identity. That doesn't guarantee anyone will see what you publish.

Bridges at the protocol edge

ActivityPub, AT Protocol, and Nostr don't share a common language: each was designed independently to solve different problems. (Part 1 of this series showed how AT Protocol first began bridging that gap with the Fediverse.) A small ecosystem of bridges has emerged on Nostr's end anyway, built by independent developers working at the edges of each protocol's spec, not because the protocols invited them, but because enough people decided the gap was worth closing.

Mostr.pub was built by Alex Gleason, the same developer behind Soapbox, the open-source frontend that Truth Social used to strip federation out of Mastodon. (our post on Fediverse governance covers that episode in detail) Gleason left Truth Social as its Head of Engineering and went directly into Nostr. The bridge he built there, Mostr, acts as an ActivityPub server and Nostr client that publishes to a Nostr relay at wss://relay.mostr.pub, which the same team operates. From the Fediverse side, Nostr accounts appear as pseudo-users at mostr.pub/users/<pubkey>, followable from any ActivityPub client. From the Nostr side, ActivityPub accounts are reachable via bridge identifiers like alex_at_gleasonator.com@mostr.pub. The bridge translates in both directions: Nostr events become ActivityPub Createactivities; ActivityPub posts become Nostr events. A Mastodon user can follow a Nostr account and see its posts without leaving their client.

Ditto takes a different architectural approach. Rather than translating between two running systems, Ditto is a server that natively implements both Nostr relay protocol and ActivityPub, exposing a Mastodon-compatible API and a Nostr relay interface as two views on the same underlying data store. A NIP-05 identity on a Ditto instance is also a valid user@domain ActivityPub actor. The "no-fed" bounty that fiatjaf (one of Nostr's original architects) posted describes the same goal: an ActivityPub server that doubles as a Nostr relay, where AP accounts have deterministic Nostr keys and Nostr users are discoverable through AP identity resolution. Ditto is the closest working implementation of that vision. (Federated Mind is on Nostr via Ditto: follow at ditto.pub.)

The Bluesky connection runs through a third bridge. Mostr added support for following Bluesky accounts via a combination of itself and Bridgy Fed: a Bluesky user opts in by following the Bridgy Fed Bluesky account, their handle gets exposed as a bridge identifier (mkfain.bsky.social_at_bsky.brid.gy@mostr.pub), and Nostr clients can follow it. Posts propagate through both bridges. Propagation can be noticeably delayed, and the Mostr team is explicit that both services remain experimental.

What the bridges can't fix

Every one of these bridges is opt-in, third-party, and defederatable. Fediverse instance admins can (and some do) block bridge traffic: when Mostr.pub starts syndicating Nostr content into an ActivityPub timeline, admins who weren't expecting that traffic have the tools to cut it off. The governance mismatch runs deeper than infrastructure: ActivityPub's moderation model assumes instance admins take responsibility for their communities. Nostr's model distributes responsibility across relay operators and individual clients. When you bridge between them, you're not only bridging content: you're colliding two different theories of who's accountable for what. A Mastodon user who sees a Nostr post via Mostr.pub has no report-to-admin workflow that maps cleanly onto Nostr's architecture.

This isn't an argument against the bridges. It's the reason they work as opt-in experiments rather than default infrastructure. The admins and users who participate have chosen to accept that mismatch.

Three protocols, one open web

ActivityPub bet on federated communities with instance-level governance. AT Protocol bet on portable, signed data repos and a programmable algorithm layer any app can build on. Nostr bet on the smallest possible substrate: signed JSON events, WebSockets, cryptographic keys, and Lightning payments deeply integrated via NIP-57.

The bridge ecosystem rests on a single proposition: these three independently designed bets can interoperate. Mostr.pub, Ditto, Bridgy Fed, and the assorted local bridges being written by individual developers are building the translation layer that nobody officially planned. Each bridge is imperfect, opt-in, and occasionally blocked. Together they're sketching the outline of something that wasn't designed: a potential de facto unified open social layer that connects protocols because enough people decided it should exist.

Whether that sketch hardens into stable infrastructure depends on two things: how much weight each community puts on cross-protocol reachability, and whether the cultural gap between Bitcoin-centric Nostr and governance-centric Fediverse turns out to be a feature or friction. The protocols don't require the communities to agree. The bridges do.

What's next: Federation Across Networks Part 4 looks at the long tail of ActivityPub — Misskey, Pleroma, Akkoma, Friendica, and GoToSocial — and what their divergence from Mastodon reveals about the Fediverse's actual shape.

Sources and further reading

Protocol overview

The NIP system and event kinds

Relay ecosystem

Zaps and Lightning

Bridges: Mostr, Ditto, Bridgy Fed

Alex Gleason: Soapbox → Truth Social → Nostr

Jack Dorsey, Revolution.Social, and Nostr

Read more