NIP-78: Arbitrary custom app data
Not every app setting deserves a public standard
Nostr culture rightly values interoperability, but some app data is simply app data. A drawing app, game, dashboard or client may need to store preferences or private state that no other app needs to understand.
NIP-78 gives those apps a place to put state on user-chosen relays. The user can bring their own relay as a database, and the app can keep data tied to the user's Nostr key without asking the whole ecosystem to agree on a schema.
That is useful precisely because it is modest. NIP-78 is not a replacement for standard NIPs. It is the escape hatch for custom app storage.
Kind 30078 and kind 78 for app-owned data
Kind 30078 is an addressable event with a d tag that names the app and context. The content and tags can be anything the app chooses. This is useful when the app wants one replaceable state object per key.
Kind 78 is a normal event for cases where an app needs multiple records of the same type. Apps needs to use a unique tag, even a d tag, to group records together.
The source is direct about intent: this is for custom applications that do not care about interoperability. If a data model becomes useful across apps, it probably deserves a real NIP instead.
A 2023 app-data escape hatch later got a normal-event sibling
fiatjaf added NIP-78 app-specific data in February 2023. The file later adopted addressable-event terminology. In May 2026, fiatjaf added the normal application-specific kind 78 through PR #2292.
That 2026 addition matters because not all app state is one replaceable object. Some apps need many records, logs or grouped entries.
The NIP has stayed short because the whole point is to avoid specifying the app's private schema.
Use it for app state, not shared protocol data
A client implementing NIP-78 needs to namespace its d tags carefully, avoid overwriting unknown records and encrypt private data when appropriate. The app needs to also offer export or migration paths because custom data can become stranded if the app disappears.
Good use cases include user settings, app-specific drafts, local UI layouts, non-interoperable game state or dynamic parameters. Bad use cases are things other clients need to understand, such as common wallet records, public media metadata or community models.
A user-facing page needs to be clear: NIP-78 is useful because not everything belongs in the shared protocol vocabulary.
Custom storage can become invisible lock-in
If an app stores important data in a private schema and never documents it, the user owns the events but cannot meaningfully use them elsewhere. That is better than a closed database, but still a kind of lock-in.
Private app data may also be sensitive. If the app uses public content casually, relays will see it. Encryption choices still matter.
Read NIP-78 in the wild
NIP-78 gives apps a place for application-specific data. Used well, it can make settings and state portable instead of locked inside local storage.
Used carelessly, it becomes a public junk drawer of preferences, draft state and workflow clues. The product needs to say what is stored, where, whether it is encrypted and how to remove it.
What changes when you actually use it
For you, NIP-78: Application-specific data is felt when a specialized experience still remains portable. Games, forums, handlers, static sites and local transports become useful only when another client can understand the same object. The source terms draft, d, content, tags are the difference between an open feature and a private app convention.
What changes for builders and operators
For builders, NIP-78: Application-specific data needs cross-client proof. Create an object in one product, open it in another, then test what survives without special server knowledge. That is where an app-specific idea becomes a real Nostr surface.
What the official file makes concrete
The official file is organized around Nostr event, Some use cases. Inspect draft, d, content, tags because these are the pieces most likely to surface as product behavior.
NIP-78: Application-specific data earns trust when a second client can understand the same object without a private handshake.
Where it breaks
The failure mode in NIP-78: Application-specific data is private interoperability. The event exists on Nostr, but only the original app knows how to use it. Test a second interface and a second relay before calling the feature portable.
Where this appears outside the markdown
In the ecosystem, NIP-78: Application-specific data is where Nostr stops being only a feed and becomes a surface for specialized products: forums, games, static sites, handlers, local transport or application state. The standard matters only when another client can open the same object without calling the first app for private instructions.
The nearby-standard trap
The nearby-standard trap in NIP-78: Application-specific data is mistaking novelty for interoperability. A clever app-specific event is not a standard until another client can use it. Read NIP-01 and the adjacent source links to see whether the feature has a path out of its first product.
Language that keeps the feature honest
Good product copy for NIP-78: Application-specific data names portability. It tells you whether another client can open the object, whether a relay or app-specific convention is required, and what might fail when you leave the original product.
What this page does not promise
NIP-78: Application-specific data does not make a niche feature portable just because it uses Nostr events. Portability begins when another client can parse the object, recover the context and show a useful experience without a private API. Read NIP-01 and the adjacent source links and look for second-client evidence before treating the format as settled.
Read it as a field test
Start NIP-78: Application-specific data with interoperability. If draft, d, content, tags cannot travel into another useful interface, the feature is still mostly an app convention. Read NIP-01 and the adjacent source links and look for public examples before assuming a specialized NIP has become a stable product surface.
Where the standard earns trust
The source links give you places to test the interpretation in public: PR #2292, remoteStorage, NIP-33 Addressable Events. Use those links to move from the spec to live libraries, mirrors, pull requests, guides or products.
Official NIP-78 source is the anchor for exact wording, and NIP-78 commit history shows how that wording moved over time. The strongest secondary clues here are PR #2292, remoteStorage, NIP-33 Addressable Events. 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-78: Application-specific data: first the human promise, then draft, d, content, tags, then the implementation record, then the real-world failure case. That order keeps NIP-78 useful without turning it into marketing copy or protocol trivia.
Three questions to carry forward
- Can a second app open the object and make it useful, or does the first product still carry the real meaning?
- Which part is standardized in
draft,d,content,tags, and which part remains a convention, server policy or UI choice? - What happens when the app, relay, local transport or handler that created the object is gone?
What to verify before you rely on it
- Find
draft,d,content,tagsin 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-78 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-78: Application-specific data in that order: Official NIP-78 source for the current wording; NIP-78 commit history for the change record; PR #2292, remoteStorage, NIP-33 Addressable Events 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.
