🤿 Nostr Connect Technical Deep Dive
Nostr Connect can be used to create a seamless flow where users do their work in the browser, while signing using their devices safely and securely. This articles describes the UX and specific message flows for how a circuit is created and how Bob can login to update and publish his work from multiple devices.
📱 Logging In
msg 1. The webapp uses its private key to post a message to the relay that is awaiting for a party to establish a session. It also make a QR code or nostrconnect:// link available on the site to scan. The nostrconnect string is static, and so the QR code is as well.
The URI string has a format like the uri below.
| 1 | const pubkey = "pubkey-representing-the-browser" |
| 1 | const relay = "wss://which-relay-the-parties-will-use-to-bounce-events.com" |
| 1 | const applicationName = "Content Authoring Application Name" |
| 1 2 | const uri = `nostrconnect://${pubkey}?relay=${encodeURIComponent(relay)}&
metadata=${encodeURIComponent(JSON.stringify({"name": applicationName}))}` |
msg 2. Bob scans the the QR code and is asked whether to approve sending a Login proof to the WebApp in Bob’s Browser.
msg 3. After signing, Bob broadcasts the message to the relay that was provided in the QR code. He does not broadcast this to other relays.
msg 4. Just as the Bob’s Browser opened a subscription to Bob in step 1, Bob opens a websocket subscription to receive updates from the WebApp.
msg 5. The WebApp was already subscribed from step 1 and now receives the Login proof and allows the user into the application.
The events described above all ephempheral, meaning they are not saved on the relay longer than a few minutes. They are also encrypted, but they do leak metadata about who is logging into which applications via which relays. A closed relay could be used for more privacy.
🖥️ Using the Application
At this point, Bob is logged into the application on his browser. He may start to author some content, post some events (tweets), creating bitcoin spending policies, or propose spends.
Let’s say that he authors a long paper using markdown on his computer. He is not quite finished, but he wants to save it as a draft.
In the application, he can perform a Save action. This would encrypt the document locally and send it to the relay which will forward it over the subscription to Bob’s Phone. The device would ask Bob if he approves saving that event to his private own DM Notes to Self (msgs 10-11).
When Bob approves, the signed event is returned the Bob’s Browser via the Relay, where the WebApp then sends it to the relay as a NIP-04 encrypted message (msgs 12-14).
Do we need a LOG-OFF event to inform the Browser to end the subscription? (and also erase any local data)
💻 Later that Day (or Year)
Later that day, Bob begins working on his laptop and wants to finalize his paper and publish it to Nostr.
Bob goes to the URL of the application on his laptop browser and scans the QR to Login (msg 20). The same login sequence that occurred at the beginning occurs again to create a session.
Once logged in, Bob sees his content within his Notes to Self and continues to edit and proofread. When he is complete, it clicks ‘Post’ to submit the content as a normal Nostr event (msg 22).
That click in the Browser constructs an Event and encapsulates it in wrapper event to send to Bob’s Phone over the relay. Bob reviews the hash of the event in the browser and on the device to know it is the same one, and then approves (msg 23).
The approval is sent back to Bob’s Browser where it is broadcast to a relay as the public post. It is only at this point that the content is accessible unencrypted by any audience or component outside of Bob’s local systems (msg 24).
✨ Summary
Establishing secure, flexible, and real time communications between the browser and application and device makes many great use cases available for Nostr.
₿ Postscript: Bitcoin Signatures in Nostr Connect (??)
I am an admitted and unashamed stalker of open source developers. I noticed that yesterday, the author of the Nostr Connect protocol and the reference implementation Nostrum starred and forked a Javascript library for signing and decoding Bitcoin transactions.
Coinstr is very interested in using this protocol to sign more than Nostr events, especially Bitcoin. We will keep a close eye on what transpires.
Follow Max on Nostr to report any errors and for more articles and information about innovation around Nostr, Bitcoin and Lightning.
https://snort.social/p/npub1ws2t95pdtpna4ps62rrz75mm6ujsudjv70yj2jk4wsqjhedlw22qsqwew9