nostr: add Double Ratchet sessions and invites (NIP-117/118) - #1441
Closed
mmalmi wants to merge 6 commits into
Closed
nostr: add Double Ratchet sessions and invites (NIP-117/118)#1441mmalmi wants to merge 6 commits into
mmalmi wants to merge 6 commits into
Conversation
added 2 commits
August 10, 2026 14:14
Implement persistable Double Ratchet sessions and invite bootstrapping without session-manager storage or routing policy. Follow the deployed reference protocol where the draft pseudocode was internally inconsistent. Refs nostr-protocol/nips#1813
Explain that private invite URLs retain sensitive shared capability material while public invite events expose it, and distinguish acceptor-side invites from owned invites.
mmalmi
changed the title
added 3 commits
August 10, 2026 15:23
Add concise Rustdoc workflows for session routing, durable send state, invite acceptance, and first-message behavior. Remove the experimental label while retaining the proposal link.
Explain the protection provided when a main Nostr key is compromised and document direct session initialization through an authenticated key-exchange channel.
Separate session and crypto logic, invite and wire handling, tests, and interoperability fixtures without changing the public API or behavior.
mmalmi
marked this pull request as ready for review
August 10, 2026 17:40
Bind invitee identities to their advertised session keys with a mandatory Schnorr proof, and reject proofless responses.\n\nBound encrypted inputs before allocation, strictly parse unsigned rumors, validate ratchet headers and raw NIP-44 versions, compare authentication tags in fixed time, and document identity and persistence requirements.\n\nAdd adversarial, atomicity, no_std, and TypeScript interoperability coverage.
Member
Member
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
If your main Nostr private key is compromised, all past NIP-17 messages you received and future ones sent to you are exposed. Double Ratchet fixes this for established conversations by using separate session keys that change after every message, so the main key alone cannot decrypt the session’s past or future messages.
This PR adds NIP-117 and NIP-118:
Sessionencrypts unsigned Nostr events as signed kind-1060 events, rotates keys per message, serializes its ratchet state, and handles delayed or out-of-order delivery.Invitecreates matching sessions through private links/QR codes or signed public invites and kind-1059 responses. Each response proves possession of its advertised session key.Developers can use these APIs for one-to-one chat or encrypted transport of messages, replies, reactions, and file metadata through existing relay clients.
Inviteis optional. If both sides exchange the ephemeral public keys and shared secret through another authenticated channel, they can construct matchingSessionvalues directly.Persist the updated session after every successful send or receive. Serialized sessions and private invite URLs contain secret material; public invites can be answered by anyone.
The features are disabled by default, support
no_std + alloc, and include interoperability, out-of-order delivery, persistence, tampering, identity-forgery, and failure-atomicity tests.Checklist
CHANGELOG.md