nostrability

Nostr will have a shot at winning because of seamless interoperation between any combination of social media clients, and other stuff.

What is nostrability

The practical documentation of how various nostr apps and relays play together.

Two or more nostr apps and/or relays must be involved to invoke a nostrability report.
Negative interoperability documents the friction between two or more nostr apps interacting.
Positive interoperability advocates that certain apps adopt certain NIPs/implementation approaches, so that apps appear compatible.

Interactive tracker

Explore the full interoperability matrix at nostrability.github.io/nostrability — an interactive dashboard with app-vs-NIP compatibility grids, search, filters, and status indicators.

In meme form (negative interoperability)

memelord credit to corndalorian

How nostrability works

Manual testing and crowdsourcing

Nostrability assesses the degree of friction of interoperability between nostr's many moving parts. We provide a simple crowdsourcing template for documenting poor or lack of interoperability between nostr apps A and B, nostr app C and nostr relay D, and so on.

Devs are welcome to, and may find using nostrability useful as a platform to request comment from other devs on unvalidated concepts.

Positive interoperability trackers

We maintain 85+ tracker issues that monitor NIP adoption across nostr apps. Each tracker documents which apps support a given NIP and how well they interoperate. Examples:

• DMs (NIP-17) — Zaps (NIP-57) — Long-form (NIP-23)
• Relay list metadata (NIP-65) — NWC (NIP-47) — Lists (NIP-51)
• Reactions (NIP-25) — Highlights (NIP-84) — AI/MCP on Nostr

Browse all: positive-interop label

Event kind label taxonomy

Issues are systematically tagged with 78 kind-XXXX labels (color-coded by event type) and 35+ nip-XX labels, making it possible to find all interoperability issues related to a specific event kind or NIP at a glance.

| Color | Event type | Example | |-------|-----------|---------| | Orange | Regular kinds (0-9999) | kind-1, kind-7, kind-9735 | | Green | Replaceable kinds (10000-19999) | kind-10002, kind-10019 | | Teal | Parameterized replaceable (30000+) | kind-30023, kind-30311 |

Automated testing — schemata

Schemata is a set of language-agnostic JSON schemas for validating nostr events against their NIP and kind definitions. App devs can integrate relevant schemas into their dev/build/CI pipeline.

Schemas can also be used to pull events of specified kinds from relays and perform bulk "in the wild" validation. Events that do not conform are documented (example finding, and associated dev response & fix).

Automated testing — Sherlock

Sherlock is a passive schema validator that continuously scans relays, validates events against schemata JSON Schemas, and attributes violations to apps via NIP-89 client tags. It runs 3x/day via CI and publishes findings as:

• Interactive dashboard — by kind, by app, and error pattern views
• Machine-readable JSON — git-tracked for trend analysis
• Nostr notes — daily reports published by the nostrability bot

Non-objective

Nostrability does not aim to get all apps to implement all NIPs.

How to contribute

• Report broken interop: Open an issue describing which apps/relays are involved and what breaks
• Update a tracker: Comment on an existing positive-interop tracker with evidence of app support
• Add schemas: Contribute to nostrability/schemata with validation schemas for new or existing NIPs

Motivation & reference

• Nostr by fiatjaf: https://fiatjaf.com/nostr.html
• How nostr wins by Pablo F: https://youtu.be/qTixqS-W1yo
• Nostr — FOSDEM 2025, Wouter Constant
• Nostr's broken interoperability — Pablo F: https://youtu.be/v0H13dPceJ0
• Nostrability overview (~13 min): https://youtu.be/I3Qld_HXQuM — slides

Contact

npub1zafcms4xya5ap9zr7xxr0jlrtrattwlesytn2s42030lzu0dwlzqpd26k5