A few releases of NostrComments since last time: the floating button dims unless you hover it, can be dragged to a corner instead of only picked from a menu, and can now be turned off entirely in settings. With it off, the toolbar icon becomes the way in instead — and now shows how many replies you haven't seen yet, so that's still covered.

https://briskness-byte.github.io/
github.com/briskness-byte/NostrComments

GM! Coffee's on, let's build something great today.

If your browser extension uses sender.tab to tell web pages apart from its own pages, check this. I got it wrong in a signer and it cost me a release.

The background script refused privileged messages, like setting a PIN, whenever sender.tab was set. The reasoning: content scripts run in tabs, so a message with a tab came from a web page.

But the extension's own options page has a tab too, as soon as it is opened in one. So the extension blocked itself. PIN setup didn't throw an error or show a warning. It just did nothing.

The check that means what you intended is the sender's URL, not whether a tab exists: compare sender.url against browser.runtime.getURL(''). Your own pages pass, and anything a content script relays from a web page does not.

The second half of the same fix: the content-script bridge now forwards only an explicit list of message types. Before, some handlers were out of a page's reach only by accident, and an accident is not a boundary.

NostrComments 23.4.0 is out. A reader of the extension — Emre Yılmaz ( @Emre Yilmaz ), blog.emre.xyz — wrote up a discovery convention for pages that are also native Nostr content: a <link rel="alternate" href="nostr:naddr…"> tag, so a client can find the entity a page already is. Sent it in as a proper draft, trust considerations included.

Built the read half of it — a page naming its own Nostr entity now has that thread merged into the panel, alongside the URL-scoped one. Thank you for taking the time to write it up properly Emre!