NIP-48: Bridged events
Bridged content needs a receipt
A bridge can make the social web feel larger. It can also make provenance murky. If an ActivityPub post, AT Protocol post, RSS item or web object appears as a Nostr event, people and clients need to know that the event originated somewhere else.
NIP-48 solves that with one tag: ["proxy", id, protocol]. The tag points back to the source object and names the source protocol. It can be attached to any event kind, and it tells clients that the event did not originate natively on Nostr.
That small cue matters for duplicate handling, source attribution and trust. Without it, a client may show bridged content as if a Nostr key authored it directly. With it, the client can show a link to the original, reconcile duplicates and treat the bridge identity with more care.
The proxy tag and four protocol namespaces
The tag has three fields: proxy, the source object id and the protocol name. The ID must be universally unique regardless of protocol, but the actual format depends on the protocol. For ActivityPub and web, it is a URL. For AT Protocol, it is an AT URI. For RSS, the example uses a feed URL with a GUID fragment.
The current protocol list is intentionally short: activitypub, atproto, rss and web. The list can grow. The important constraint is that a client needs to be able to understand where the object came from and how to link or de-duplicate it.
NIP-48's see-also section points to FEP-fffd Proxy Objects and the Mostr bridge. That situates the NIP in a wider bridge conversation rather than only inside Nostr.
A compact NIP from bridge pressure
NIP-48 entered the visible history in August 2023 through Alex Gleason's proxy tag work. Later changes removed author names and, in May 2026, fiatjaf made a small sanity fix. The file has stayed short because the job is short.
Short does not mean unimportant. Bridging is one of the places where decentralized networks either become readable together or collapse into duplicated, unattributed mirrors. NIP-48 gives bridges a simple responsibility: leave a source receipt on the event.
The useful way to read it is as metadata discipline. NIP-48 does not tell bridges how to authenticate every foreign object, solve moderation across networks or reconcile all identity models. It gives clients a starting point for provenance.
A bridge needs to make origin visible, not invisible
A bridge implementing NIP-48 needs to add the proxy tag every time it turns a foreign object into a Nostr event. A client implementing it needs to show origin affordances: source protocol, link to original, duplicate hint or bridge badge. The goal is not to shame bridged content. The goal is to keep the social graph honest.
Rust-nostr advertises support for NIP-48. The most visible bridge context is Mostr, which bridges Fediverse and Nostr worlds. The ActivityPub side has FEP-fffd Proxy Objects, which speaks to a similar need from the other direction: a proxy object needs to identify the thing it represents.
The product rule is simple: do not let a bridged post look more native than it is. If the source object is reachable, link it. If the source protocol is unknown, say so. If a native Nostr event and a bridged event represent the same outside post, let the client reduce duplication.
Bridges can launder context
The risk of bridged content is context loss. A post can move from one moderation system, identity model and audience into another. A proxy tag does not solve consent or moderation, but it gives the client a way to preserve origin.
There is also spoofing risk. A malicious event can claim a proxy source. Clients still need to evaluate bridge identity, relay trust and source reachability. NIP-48 is a tag, not a verification authority.
Read NIP-48 in the wild
NIP-48 marks bridged events. It helps you see when something came from another network or protocol instead of being born as a native Nostr event.
That honesty matters. Bridges can expand reach, but they can also blur authorship, consent, formatting and moderation context. A bridged event needs visible origin, not just a familiar Nostr-shaped shell.
What changes when you actually use it
For you, NIP-48: Bridged Events is felt as protocol memory. Archived or experimental NIPs explain why older events exist and why some designs lost momentum. That history helps you interpret software you still encounter, but it also warns you not to build current product promises on old wording alone.
What changes for builders and operators
For builders, NIP-48: Bridged Events demands caution. Keep old formats readable, but label their status and migration path. Compatibility is useful; silently reviving an abandoned design is not.
What the official file makes concrete
The official file is organized around Supported protocols, Examples, See also. Inspect draft, <id> because these are the pieces most likely to surface as product behavior.
NIP-48: Bridged Events is useful as history only when the page also marks its current status and risk.
Where it breaks
The failure mode in NIP-48: Bridged Events is stale legitimacy. An old NIP may still explain history, but current products need current status, current alternatives and a reason to keep supporting the old behavior.
Where this appears outside the markdown
In the ecosystem, NIP-48: Bridged Events is part of the memory layer. Old NIPs explain older events, libraries and client behavior that still show up in the wild. The page therefore needs to preserve context while marking status clearly, so compatibility does not become accidental endorsement.
The nearby-standard trap
The nearby-standard trap in NIP-48: Bridged Events is ignoring status. Older NIPs may still explain real data, but current implementation needs current alternatives and warnings. Read NIP-01 and the adjacent source links before using old behavior as a new foundation.
Language that keeps the feature honest
Good product copy for NIP-48: Bridged Events names the status. It tells you whether the NIP is active, archived, experimental, replaced or useful mainly for old events. That protects people from building trust on stale context.
What this page does not promise
NIP-48: Bridged Events does not deserve current-product trust just because it appears in the NIP archive. Archived, draft or experimental material can explain old events and design history, but new products need current alternatives, migration notes and explicit status language. Compatibility is valuable; silent resurrection is not.
Read it as a field test
Start NIP-48: Bridged Events with status. Old, archived and experimental NIPs are still useful when they explain history, but they need a migration path and current context. The article earns its place when it helps you understand old data without encouraging stale implementation choices.
Where the standard earns trust
The source links give you places to test the interpretation in public: nips.nostr.com NIP-48, FEP-fffd Proxy Objects, Mostr bridge, rust-nostr supported NIPs. Use those links to move from the spec to live libraries, mirrors, pull requests, guides or products.
Official NIP-48 source is the anchor for exact wording, and NIP-48 commit history shows how that wording moved over time. The strongest secondary clues here are nips.nostr.com NIP-48, FEP-fffd Proxy Objects, Mostr bridge. Treat this evidence chain as part of the article, not as footnotes. A NIP page becomes useful when you can move from claim to source to working behavior without guessing.
Keep the chain visible for NIP-48: Bridged Events: first the human promise, then draft, <id>, then the implementation record, then the real-world failure case. That order keeps NIP-48 useful without turning it into marketing copy or protocol trivia.
Three questions to carry forward
- Is this current guidance, legacy compatibility or a historical design that explains old events?
- Which modern NIP replaced, absorbed or narrowed the original idea?
- Does the page label risk clearly enough that old compatibility does not become new product advice?
What to verify before you rely on it
- Find
draft,<id>in the official file and check where the UI exposes the same concept. - Read NIP-01 and the adjacent source links as context before treating NIP-48 as a complete product story.
- Open at least one implementation, mirror, pull request or library source from the source links before trusting that the idea is mature.
- Test the unhappy path: missing relays, stale metadata, invalid signatures, blocked events, expired state, revoked permissions or unavailable media.
- Write the user-facing copy in plain language. If a standard changes authority, privacy, money, moderation or recovery, say that before the click.
Direct sources
Use these sources for NIP-48: Bridged Events in that order: Official NIP-48 source for the current wording; NIP-48 commit history for the change record; nips.nostr.com NIP-48, FEP-fffd Proxy Objects, Mostr bridge for public context. The article gives you the consequence in plain language, but the source trail is where exact fields, status notes, unresolved debates and implementation proof stay checkable.
