Thank You!

How did you add the Monero target? I fetched your kind 0 across six relays and the newest one has no XMR field — did a client rewrite it, or does it live somewhere else?

Also on the project page, where the video is self-hosted — no YouTube embed, no third-party requests, the same claim the extension makes about itself: https://briskness-byte.github.io/ #nostr #privacy

NostrComments has a proper demo now — 66 seconds, no sales pitch: https://www.youtube.com/watch?v=bywF8yWZa3o A comment thread on any page, attached to the page's address and stored on relays instead of on the site. The clip shows it on a Nature article with no comment section, the same thread appearing in a second browser under a different key, and then a paywalled paper, a corporate announcement, an EU page and a post on X. Also out: 23.2.2, where the toolbar button opens and closes the panel. That matters because a page can delete the floating button — the toolbar is outside its reach. Firefox: https://addons.mozilla.org/firefox/addon/nostrcomments/ Chrome: https://chromewebstore.google.com/detail/nostrcomments/ebmgdpicceaencegknannfaljhbfgido

Very Cryptic

Attest is a Nostr signer for Firefox: it holds your key and asks before anything is signed. What's new in recent releases: • Protect your key with a passphrase, not just a 4–6 digit PIN. A short PIN stops someone using your browser; it does not stop someone who copies your Firefox profile, and the extension now says so plainly instead of implying otherwise. • Permissions are tied to a site's full address, https or http. A site you allowed over https is no longer also allowed over plain http. • Each site keeps one decision per kind of permission, so refusing something briefly no longer wipes a permission you granted permanently. • The options page shows what is actually there: no empty key field for a key that is encrypted, and adding another key happens where you'd look for it. Open source, reproducible build, and the release refuses to ship if the tests fail or if the code that handles your keys doesn't type-check. https://addons.mozilla.org/firefox/addon/attest/ https://github.com/briskness-byte/attest

NostrComments 23.2.0 is out 🧵 It now works on sites that used to show an empty panel. Some sites (x.com is the best-known) use a strict Content-Security-Policy that blocks connections to anywhere they haven't listed, and Firefox applied that rule to the extension too, so no relay could be reached. The extension now opens its relay connections from its own background, where the site has no say. Also new: • a switch to leave the "client" tag off your comments • on Firefox, the welcome screen now suggests Attest instead of nos2x-fox, which has a public flaw that lets a website read the PIN protecting your key. Attest is my fork with that fixed. What it is: a comment thread on any URL, stored on relays instead of on the site, so the site owner can't delete it. Comments are NIP-22 (kind 1111), so other clients can read them. Firefox: https://addons.mozilla.org/firefox/addon/nostrcomments/ Chrome/Brave/Edge: https://chromewebstore.google.com/detail/nostrcomments/ebmgdpicceaencegknannfaljhbfgido Source: https://github.com/briskness-byte/NostrComments No server, no account, no tracking. Feedback welcome, here or in the thread on any page. #nostr #privacy

A browser extension can be talked to by two very different things: its own pages, and a content script sitting in somebody's web page. Telling them apart is the whole security boundary, and the obvious way to do it is wrong. `sender.tab` looks like the answer. It is not. An options page opened with tabs.create() has a tab like any web page does, so checking for one makes the extension refuse its own UI — and it fails silently, because the message goes out, comes back refused, and nothing on screen says why. A button that does nothing. `sender.url` against runtime.getURL('') is the one that holds. A content script always reports the address of the page it was injected into, never a moz-extension:// one, and content scripts do not run on extension pages. Cost me a release before I found it.

I hand-rolled secp256k1 and BIP-340 Schnorr for a browser extension, and I would like someone who does this properly to read it. Why hand-rolled: the extension ships with no build step and no dependencies, so the file you install is the file in the repository, comparable line for line. A library would have cost that. Whether the trade was worth it is part of what I am asking. What I have already done. It passes all nineteen official BIP-340 test vectors, including the ten that must be rejected — public key off the curve, sig[0:32] not an x coordinate, s equal to the curve order, sG - eP at infinity. I mutation-tested that suite too: removing the even-y check on R is caught by exactly one assertion in the entire project, vector #6, and by nothing else. What I already know is weak. The scalar multiplication is a plain double-and-add branching on secret bits, so it runs in variable time. I do not think it is reachable from a hostile page — a content script's signing cannot be triggered or observed from the page — but I would rather say it than have it pointed out. And BigInt is not constant time in any JS engine, so this is not something I can fully fix in this language. What testing cannot tell me: whether the field arithmetic is right. Vectors prove the implementation behaves on inputs somebody thought to write down. They say nothing about the modular inverse. It is forty lines. I am not asking anyone for a free audit — just for eyes. I would rather find out now than after somebody depends on it. https://github.com/briskness-byte/NostrComments/blob/v23.1.0/NostrComments-Chrome/content.js#L56-L95

I was about to post a measurement. I re-ran it first, which I do, and it fell apart in my hands. The claim: across six news domains, the notes on Nostr that link to news articles are essentially one account. 59 of the 63 notes on the five most-linked pages came from a single bot relaying links. Four distinct authors in total. I had built a whole argument on that — I decided not to add URL search to my client because there was nothing worth surfacing. Redone sixteen days later: 3,050 distinct article pages, 17 distinct authors on the five most-linked, largest single author 16%. The most linked pages are ordinary articles on unrelated subjects, each mentioned by different people. Both runs used the same three search relays that answer a NIP-50 filter at all, of seven tried. The difference between them is one function call. The corpus was there the whole time. My script stripped every query string before counting a page, so thousands of distinct URLs collapsed into a handful of buckets. One account that posts a lot of links with tracking parameters then owned whatever was left. The bot was not the corpus. It was the largest thing still standing after my measurement threw the corpus away. The part I find hardest to be relaxed about: my own client already has a URL normaliser that gets this right. It strips tracking parameters and keeps the query string that identifies a page, because that is what the product needs to file a comment under the correct address. The measurement did not use it. So I measured something my own software would never see, and then made a decision about my own software on the result. The decision happens to survive — I still would not build that search, for reasons about relay reliability and about not sending the page you are reading to an index you did not choose. But it survived by luck, not by reasoning, and those are not the same thing. If you measure your own product: measure with the code your product runs. Anything else and you are describing a system nobody uses.