NIP-77: Negentropy Syncing
Syncing by dumping IDs wastes the network
Relays and clients often need to know what events differ between two sets. The naive approach is expensive: send every event or every event ID and compare. NIP-77 brings Negentropy into Nostr as a bandwidth-saving reconciliation protocol.
If both sides share most of a set, Negentropy can identify differences with much less data. That matters for relay migration, client cache repair, reaction counts, archival sync and relay-to-relay replication.
The NIP does not transfer the actual events. It lets the two sides learn which IDs one has and the other needs. After that, ordinary Nostr EVENT and REQ messages can move the data.
NEG messages around a hex-encoded binary protocol
Negentropy is binary, so NIP-77 hex-encodes messages. The initiator sends NEG-OPEN with a subscription id, filter and initial message. The relay replies with NEG-MSG. The two sides continue exchanging messages until the client closes with NEG-CLOSE or an error appears as NEG-ERR.
The filter follows NIP-01. The subscription id is separate from ordinary REQ subscriptions. Error prefixes follow the ordinary machine-readable pattern used elsewhere in Nostr.
The appendix includes the Negentropy Protocol V1 description, including records sorted by timestamp and ID.
A Nostr wrapper around hoytech's Negentropy work
fiatjaf added the visible NIP-77 Negentropy syncing work in May 2025. Later changes were mostly typo and relay-tag cleanup. The NIP points directly to hoytech's Negentropy repository and Range-Based Set Reconciliation background.
That source relationship matters. NIP-77 is not inventing the reconciliation algorithm in the NIP file. It is making the existing protocol usable over Nostr websocket messages.
The standard is relay-facing enough that people may not see it in a UI, but they will feel it when sync becomes faster and cheaper.
A sync engine needs to separate reconciliation from transfer
A client implementing NIP-77 needs to build a local event set for a filter, open a negentropy session, learn missing and extra IDs, then use normal Nostr messages to upload or download events. Mixing reconciliation and event transfer makes the flow harder to reason about.
Relays need limits. A broad old filter can be expensive to reconcile, so the NIP allows blocked-style errors for requests that would require too many records or too old a range.
The payoff is practical: less bandwidth for mostly-overlapping sets and cleaner cache repair.
Sync can become a relay-cost trap
Set reconciliation is efficient when scoped well. It can still be expensive for huge filters, old archives or hostile clients. Relays need limits and clear errors.
Clients need to also avoid assuming a successful reconciliation means every event is valid or wanted. Normal signature, kind, policy and spam checks still apply.
Read NIP-77 in the wild
NIP-77 is about efficient sync through Negentropy. You rarely see it directly, but you feel it when relays, clients and archives catch up without repeatedly transferring the same data.
Sync bugs become social bugs. Missing replies, incomplete histories and slow catch-up make users distrust the network. This NIP belongs to infrastructure quality.
What changes when you actually use it
For you, NIP-77: Negentropy Syncing is felt when a relay accepts, rejects, indexes, hides, charges for or returns events. Relays are not passive pipes. They make policy and infrastructure choices that shape what a client can show. The source terms draft, relay, NEG-CLOSE, EVENT, REQ, initialMessage matter because they are the narrow places where a product can distinguish a relay decision from a network failure.
What changes for builders and operators
For builders and operators, NIP-77: Negentropy Syncing is observability. Log what the relay accepted, rejected, counted, authenticated or refused. Then show enough of that to users so they can repair configuration instead of assuming Nostr is empty or broken.
What the official file makes concrete
The official file is organized around High-Level Protocol Description, Nostr Messages, Initial message (client to relay):, Error message (relay to client):, Subsequent messages (bidirectional):, Close message (client to relay):, Appendix: Negentropy Protocol V1, Preparation. Inspect draft, relay, NEG-CLOSE, EVENT, REQ, initialMessage, blocked, closed because these are the pieces most likely to surface as product behavior. Read it beside NIP-01 before treating it as isolated.
NIP-77: Negentropy Syncing belongs to infrastructure, not scenery. Acceptance, indexing, authentication, retention, payment and filtering all shape what you actually see.
Where it breaks
The failure mode in NIP-77: Negentropy Syncing is blaming the network for one server's policy. A relay may reject an event for payment, spam, size, auth, retention or software reasons. If the client collapses those cases into one empty state, the user loses the ability to act.
Where this appears outside the markdown
In the ecosystem, NIP-77: Negentropy Syncing lives where users rarely look and operators spend real money: websocket services, relay policies, indexes, rate limits, authentication, monitoring and retention. A good hub page has to make that infrastructure readable because relay behavior decides whether Nostr feels alive, empty, expensive or hostile.
The nearby-standard trap
The nearby-standard trap in NIP-77: Negentropy Syncing is treating all relay standards as one reliability story. Discovery, authentication, information documents, search, counts, monitoring and management each expose a different slice of relay behavior. Read NIP-01 before calling a relay 'good' or 'broken'.
Language that keeps the feature honest
Good product copy for NIP-77: Negentropy Syncing names the relay decision. It says whether access, payment, indexing, search, storage, rate limit, auth or policy shaped the result. That language gives you something to fix instead of making the network feel mystical.
What this page does not promise
NIP-77: Negentropy Syncing does not make every relay equal. A relay can be public, paid, local, archival, search-oriented, authenticated, heavily moderated or almost disposable. The standard gives clients and operators a way to communicate one part of that behavior. It does not replace uptime checks, policy reading, payment terms, retention expectations or the practical question of whether your own events can be found later.
Read it as a field test
Start NIP-77: Negentropy Syncing with the server behavior you can observe: accept, reject, count, search, authenticate, limit, store, delete or report. Then connect it to draft, relay, NEG-CLOSE, EVENT, REQ, initialMessage. A relay NIP becomes readable when it explains what a relay can honestly promise and what still depends on policy, money and operations.
Where the standard earns trust
The source links give you places to test the interpretation in public: hoytech/negentropy, Range-Based Set Reconciliation, NIP-01 Basic Protocol. Use those links to move from the spec to live libraries, mirrors, pull requests, guides or products.
Official NIP-77 source is the anchor for exact wording, and NIP-77 commit history shows how that wording moved over time. The strongest secondary clues here are hoytech/negentropy, Range-Based Set Reconciliation, NIP-01 Basic Protocol. 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-77: Negentropy Syncing: first the human promise, then draft, relay, NEG-CLOSE, EVENT, REQ, initialMessage, then the implementation record, then the real-world failure case. That order keeps NIP-77 useful without turning it into marketing copy or protocol trivia.
Three questions to carry forward
- What exact relay behavior is being described: discovery, auth, search, count, information, payment, moderation or management?
- Can you see whether a failure came from policy, payment, indexing, rate limit, auth or downtime?
- Does the relay expose enough public information for you to decide whether it belongs in your own relay set?
What to verify before you rely on it
- Find
draft,relay,NEG-CLOSE,EVENT,REQin the official file and check where the UI exposes the same concept. - Read NIP-01 as context before treating NIP-77 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-77: Negentropy Syncing in that order: Official NIP-77 source for the current wording; NIP-77 commit history for the change record; hoytech/negentropy, Range-Based Set Reconciliation, NIP-01 Basic Protocol 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.
