Joey_NostrComments
Joey (NostrComments)

https://briskness-byte.github.io

I build NostrComments — a browser extension that adds a censorship-resistant comment section to every website, powered by Nostr — and Attest, a Nostr signer for Firefox that holds your key so a website never has to, and asks before it signs anything. Free and open source, always.

NostrComments for Firefox:
https://addons.mozilla.org/en-US/firefox/addon/nostrcomments/

NostrComments for Chrome:
https://chromewebstore.google.com/detail/nostrcomments/ebmgdpicceaencegknannfaljhbfgido

Attest for Firefox:
https://addons.mozilla.org/firefox/addon/attest/

Monero: 87aDTPD9HQx2QenKsS7MvHDdqsziFPD7UB37X6G5XVXc2ZPhAs8DdEKUPYJijVcRjj1gU5KvxLCTfWUKWqrd1D5o8uw5EpM

Public Key

npub1ewxm82gprxwkh9qznauyey6vwx62xetpsux3prnmddkyevasatgswmds9e

NIP-05 Address

[email protected]

Profile Code

nprofile1qqsvhrdn4yq3n8ttjspf77zvjdx8rd9rv4scwrgs3eakkmzvkwcw45gpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dsmvyw9f

Publishing to

relay.damus.io

nos.lol

Author Public Key

npub1ewxm82gprxwkh9qznauyey6vwx62xetpsux3prnmddkyevasatgswmds9e

Show more details

Last Notes

2026-10-27 09:55:28 GMT

- reply

Pretty much 😄 The site loses the delete button, but the reader gets their own tools:
- downvoted comments collapse on their own
- a burst of near-identical comments from one key folds into a single line
- you can mute people and words, and it also respects the mute list you already have in other Nostr apps
- comments marked with a content warning stay folded until you tap them
And the relays do their own filtering: you pick which ones you use.
Honest part: keys are free, so a determined spammer can always make new ones. Web-of-trust filtering (weighting people your network actually follows) is the next big step for that.

2026-10-27 09:49:47 GMT

- reply

Building NostrComments: a comment section on every web page, kept on Nostr relays instead of on the site. So the site can't delete it, and can't close it.
Since you're in NL: it works on Dutch news sites too, including the ones that switched their comments off or moderate them heavily. Your comment lives on Nostr, not on their server, and anyone with the extension (or the web reader) sees it under the article.
Browser extension for Firefox and Chrome, no account needed, open source:
https://briskness-byte.github.io/

2026-10-23 18:28:47 GMT

The practical takeaway for anyone who isn't a mail admin: a real Dell or Staples email can still be a scam, because the scammer typed their own "Helpline" number into a genuine order form and let the company's system send it for them. Passing every authentication check only proves who sent it, not who wrote the text inside.
So if you get a receipt for something you never bought, don't call the number in the email. Look up the company's support number on their own website, or log into your account directly and check whether the order exists. The whole scam depends on you calling them.
https://www.helpnetsecurity.com/2026/10/22/legitimate-platforms-abused-phishing-emails/
Read the thread: https://briskness-byte.github.io/thread/?url=https%3A%2F%2Fwww.helpnetsecurity.com%2F2026%2F10%2F22%2Flegitimate-platforms-abused-phishing-emails%2F

2026-10-19 15:45:54 GMT

- reply

Update: Attest 1.28.1 is out on addons.mozilla.org and signs through a remote signer: paste a bunker:// address and every NIP-07 site, NostrComments included, signs through it. Tested by hand against nak bunker: signing, timeouts, refusals, restarts, and relays that are slow or go quiet. The popup shows when requests are waiting for you to approve them in the signer. https://addons.mozilla.org/en-US/firefox/addon/attest/
I have to take back "Pomegranate comes for free", though. As far as I can tell the Google login runs inside the app, so a signer would need that flow itself, not just NIP-46. Does a Pomegranate user get a bunker:// code they can use elsewhere @`fiatjaf` ? If yes, it works in Attest today; if not, that's the next piece I'd add.

2026-10-19 08:26:35 GMT

Good advice. Two things to add: a "recovery service" that asks for a copy of your ID before doing anything is collecting material for the next scam, so never send it. And report it to your financial regulator too, not only the police (BaFin in Germany, the FBI's IC3 at ic3.gov in the US), because regulators publish warnings that protect the next victim.
https://cryptoticker.io/en/crypto-recovery-scam-warning-signs/
Read the thread: https://briskness-byte.github.io/thread/?url=https%3A%2F%2Fcryptoticker.io%2Fen%2Fcrypto-recovery-scam-warning-signs%2F

2026-10-18 16:57:18 GMT

- reply

Thanks, that's a fair point and I've gone back and forth on it. Right now the password is offered the moment a key is created, so it's already a choice at onboarding, just opt-in rather than opt-out. Once set, the key is unlocked per page only: navigate away and it's locked again, and reading comments never needs the password.
The reason it isn't mandatory: most people who install a comment extension want to read first and maybe post once, and a key behind a password they then forget is a key they abandon, with no backup either. I'd rather they make that choice knowingly than lose the identity.
Where I fully agree: the safest key is one the page-side code never holds at all. That's why NostrComments works with any NIP-07 signer, and why I recommend one to anyone who already has a Nostr identity. Switching the onboarding default to "set a password" with a skip is a good idea though, I'll look at that.

2026-10-18 13:26:59 GMT

Worth knowing how this one worked: tapping the notification just opened the real wallet app, so nothing looked wrong. The phishing link only showed up afterwards, in Android's notification history. A clean-looking tap proves nothing about where a notification came from.
The rule that covers every variant: a hardware wallet's recovery words go on paper or metal and nowhere else. No app, website, support agent or "critical vulnerability" alert ever needs them typed in. If a message says your wallet is at risk, close it and check the maker's official site or account yourself.
Note that it is still unconfirmed whether SecuX's own systems were involved, so no need to panic about the device itself.
https://coinpaper.com/37473/ripples-david-schwartz-flags-secux-wallet-phishing-alert-as-emergency-maintenance-raises-questions
Read the thread: https://briskness-byte.github.io/thread/?url=https%3A%2F%2Fcoinpaper.com%2F37473%2Fripples-david-schwartz-flags-secux-wallet-phishing-alert-as-emergency-maintenance-raises-questions

2026-10-18 09:13:56 GMT

Security update for NostrComments: please make sure you are on 23.10.3 or later (Firefox and Chrome both have it).
Two problems were found and fixed this week. On some websites, a malicious page could read a private key stored in NostrComments, or press the panel's own buttons, such as "Show my key" or setting a password on your key.
Keys kept in a signer extension (Alby, nos2x, Attest) were never at risk. We have no indication that these flaws were ever abused, but if you keep a key in NostrComments and want to be certain, make a new one under Settings → Rotate key.
For developers: the panel lives in an open shadow root, so the page can restyle it and click its buttons. The fixes make every key-related control require a real click, and stop reading anything security-relevant from state the page can change. The details are in the security advisories on GitHub.

2026-10-16 21:54:06 GMT

- reply

A small correction to my reply above, after thinking it through: NIP-46 will land in Attest, the signer extension I also maintain, not in NostrComments itself. Key handling belongs in the signer. NostrComments keeps speaking NIP-07, so once Attest supports bunkers, Pomegranate comes along for free, for NostrComments and for every other NIP-07 app.

2026-10-15 08:17:11 GMT

I Love this website for background music wavefunc.live
https://wavefunc.live/
Read the thread: https://briskness-byte.github.io/thread/?url=https%3A%2F%2Fwavefunc.live%2F

2026-10-15 08:10:53 GMT

- reply

this is my npub: npub1ewxm82gprxwkh9qznauyey6vwx62xetpsux3prnmddkyevasatgswmds9e

2026-10-14 20:37:24 GMT

Some practical experience, since the article stays general: I push my project to GitHub and to two Nostr git servers (gitnostr.com and relay.ngit.dev) with a single script, so the article's "we don't need to stop using GitHub" is exactly how it works in practice.
Yesterday I sent my first patch to a repo that lives only on Nostr, with "ngit send". One member-only relay refused it with a 403, but the others took it, so it didn't matter. That's the resilience the article describes, in one terminal line.
One correction: GRASP isn't so much a bridge as a server type that bundles a relay and a git server, and it creates the repository automatically when your announcement lists it. That's why you don't have to set anything up on the server side.
https://nostrmag.com/article/w40nostr01
Read the thread: https://briskness-byte.github.io/thread/?url=https%3A%2F%2Fnostrmag.com%2Farticle%2Fw40nostr01

2026-10-14 06:31:15 GMT

- reply

Browser extension dev here (NostrComments). My honest reason is a sixth one: I don't speak NIP-46 yet, only local keys and NIP-07. It's on my list now, and Pomegranate would come for free once it's done. The part that appeals to me is recovery: right now a user's identity lives in one browser profile.

2026-10-14 06:06:46 GMT

- reply

My penis

2026-10-13 21:05:36 GMT

- reply

https://www.x.com/ (X/twitter) most of the time

2026-10-13 20:53:24 GMT

Worth knowing if you're thinking of applying: the money is for the people doing the hunting (AI tokens, servers, fuzzing), not for projects that want an audit of their own code. All five grantees in this first round work on Bitcoin infrastructure: Core, libsecp256k1, btcd, BTCPay and mempool. Applications are fast-tracked via opensats.org/apply/red.
https://opensats.org/blog/red-team-grants-first-set
Read the thread: https://briskness-byte.github.io/thread/?url=https%3A%2F%2Fopensats.org%2Fblog%2Fred-team-grants-first-set

2026-10-12 21:51:43 GMT

- reply

Thank you @npub1qth…rcch , I really appreciate it! ⚡️

2026-10-10 10:59:10 GMT

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

2026-10-09 18:44:19 GMT

- reply

Appreciate you saying so, that's useful to know. Quick question so I fix the right thing: was it the little floating button sitting on every page, or the panel once you opened it? (I'm the dev, btw.)
If it's the button: it can be dragged (or set in settings) to whichever corner is free and that's remembered per site, and there's a per-site off switch too. If it's the open panel taking over the screen, that's actually the next big thing I'm working on — moving it out of the page entirely into the browser's own sidebar, so it never overlaps anything.

2026-10-09 18:43:03 GMT

- reply

Thanks for picking that up @nprofile…fywd , that's pretty much exactly it. One small nuance: the key lives in the browser until Bob chooses to export it (as nsec, or connect a client with NIP-07) — not automatically on his phone, but one copy-paste away whenever he wants it. And agreed on #2 — the bottleneck isn't really Nostr itself, it's getting people who already care about open protocols to notice it exists.

2026-10-09 07:17:07 GMT

- reply

Yep — not a silo. Every comment is a real signed Nostr event (kind 1111, NIP‑22), published to the public relays you choose. No server of mine in between. Sign with a generated key or your own NIP‑07 signer (nos2x, Alby). Other Nostr clients that read that event kind, like Jumble, can see the same comments.

2026-10-08 22:49:05 GMT

- reply

One idea (disclosure: it's mine) — meet people where they already are instead of asking them to install a client first. NostrComments puts a Nostr-backed comment thread on any website; reading needs zero signup, posting needs a key. No 'come to Nostr' wall.

2026-10-06 10:20:14 GMT

- reply

A URL-keyed thread is one place this shows up for me. A comment is filed under a page address rather than a community, so there is no owner to moderate it and nothing to join. That makes it easy to read across clients, but it also means nobody is in charge of what sticks. Where do you think that should sit: with the relay, the reader, or the page?

2026-09-22 14:51:36 GMT

If you use nos2x-fox as your Nostr signer in Firefox, make sure you're on 1.21.0. It closes two things worth knowing about.
While your PIN was cached after an unlock, any website could ask the extension for it and get it back in plain text. That PIN is what encrypts your private key at rest, so a page could walk away with the one secret between it and your key. I reported it privately and wrote the fix; it was also reported publicly as #68.
The second was found by daym. The extension used to inject its script into pages as <script src="moz-extension://<uuid>/…">. Firefox gives every extension a random UUID per install precisely so websites can't fingerprint you by the extensions you run, and that tag handed it to every site you visited: the same on each one, and surviving cleared cookies. It now loads as a MAIN-world content script, with nothing left in the page to read.
Nothing to do except update. Firefox normally does that for you; about:addons shows which version you have.
https://github.com/diegogurpegui/nos2x-fox/releases/tag/v1.21.0

2026-09-19 14:57:27 GMT

One of the dumbest things you can do on Nostr is sharing your private keys, like nsec138mwgc6rvpukzn7xj5522xzc63h69f6533tupl25trtps4nckl0qp452vg

2026-09-18 10:07:32 GMT

If your browser extension draws its UI inside the page, check this one. I had it wrong for months.
My comment panel lives in an open shadow root in the page, so any script on the page can reach every control in it. I guarded the ones that matter — granting consent, adding a relay — by checking the event's isTrusted, which only the browser can set. That felt like enough.
It is not, and I only found out because I tried to break it myself instead of assuming.
A page can skip the event entirely: take the element, call its onclick directly, and hand it an object it made up. isTrusted is just a property on that object. It can also act while a real click of yours is being delivered elsewhere in the panel, which is long enough for a naive "was that trusted" flag to still be true.
Against my own build that meant a page could open settings, press "Show private key" and read the nsec straight out of the field. And separately, type a comment and post it under my key. Without me clicking anything.
What works instead is to never trust what the caller passed. A capture listener on the shadow root records which element a real gesture is activating, in a closure the page cannot reach, and each sensitive handler asks only whether that element is itself. Dispatching an event sets nothing. Calling a handler sends no event at all. Piggybacking on a real click leaves some other element as the target.
It is still a mitigation and not a boundary, and I would rather say so: the panel is in the page's DOM, so a page can read the thread, read what I am typing, and read a key I choose to display while I am on it. Moving those controls onto the extension's own surface is the actual fix, and that is the next thing I build.
Fixed in 23.3.1 — out on Firefox, in review at Chrome.

2026-09-16 05:46:25 GMT

- reply

Happy birthday🦥

2026-09-16 02:33:17 GMT

- reply

Yeah, this is exactly why I made this. I was running into issues like that myself, I hated the censorship and major platforms these days are censoring all kinds of comments to manipulate the public opinion and still call it a democracy, but there can't be a true democracy without free speech.
The secondary benefit is that people can warn each other on scam or phishing websites, making the web potentially safer. But only a handful of people are using nostrcomments so it's still in early development and benefits are still theoretical.

2026-09-15 21:01:03 GMT

- reply

Then the question becomes: Why did you invest in their bitcoin and prop up their wealth in the ponzi?

2026-09-15 19:36:45 GMT

- reply

Thanks for the replies everyone🫶

2026-09-15 16:37:53 GMT

- reply

The irony is that actual CSAM material is embedded into the bitcoin blockchain by early bitcoin users.

2026-09-15 16:25:09 GMT

- reply

I hate Primal

2026-09-15 10:57:19 GMT

- reply

Hey sorry to ask; Do you use drugs as a way to escape from the problems you should actually fix in your life as an adult?

2026-09-15 10:33:49 GMT

- reply

Fire and a stick is technology too, right?
The best kind of technology.

2026-09-15 10:28:29 GMT

- reply

Schön! hört sich gut an!

2026-09-15 07:41:47 GMT

I often feel like an outsider on nostr. Do people actually read this?

2026-09-14 19:58:20 GMT

- reply

Wow, did not know this. Cool!

2026-09-14 13:46:28 GMT

Ever wanted to reply to an article on the internet that has comments switched off? 👀
I built NostrComments for that. It's a browser extension that gives every web page a comment section, powered by Nostr.
Here's the idea: your comment doesn't live on the website. It lives on Nostr relays, linked to the page's address. So the website can't delete it, and anyone else with NostrComments who visits that page can see it and reply.
A few nice things:
✍ Use your own Nostr key, or keep it safe in a signer like Alby, Attest or nos2x
🤝 Comments on web pages made with other Nostr apps, like Amethyst and Ditto, show up too
🔌 No company server in the middle. You pick your relays
🙋 It stays quiet until you say yes, and you can turn it off for any site
⚡ Vote, mute and zap, right in the panel
Curious but don't want to install anything? Read the comments on any page here: https://briskness-byte.github.io/thread/
Quick demo (66 sec): https://www.youtube.com/watch?v=bywF8yWZa3o
🦊 Firefox: https://addons.mozilla.org/firefox/addon/nostrcomments/
🌐 Chrome: https://chromewebstore.google.com/detail/nostrcomments/ebmgdpicceaencegknannfaljhbfgido
💻 Open source: https://github.com/briskness-byte/NostrComments
It's still early, so most pages have no comments yet. If you try it, leave one! That's how every conversation starts 💜
#nostr #grownostr #opensource #foss #privacy #nip22

2026-09-14 11:43:59 GMT

- reply

Cool! Worth checking out

2026-09-13 19:02:34 GMT

- reply

Thank You!

2026-09-13 13:09:50 GMT

You can now read a NostrComments thread without installing anything:
https://briskness-byte.github.io/thread/?url=https%3A%2F%2Fwww.nature.com%2Farticles%2Fd41586-026-02763-3
That's a Nature article with no comment section, and five comments filed under its address on public relays. Paste any URL to see what has been said about it.
Static page, no server, no backend — it queries the same relays your own client does, from your browser. Source: https://github.com/briskness-byte/NostrComments
https://briskness-byte.github.io/
#nostr #privacy #nostrcomments

2026-09-13 12:08:08 GMT

- reply

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?

2026-09-13 11:31:36 GMT

- reply

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

2026-09-13 11:00:14 GMT

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

2026-09-13 03:36:56 GMT

- reply

Very Cryptic

2026-09-12 08:24:05 GMT

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

2026-09-11 21:42:16 GMT

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 https://blossom.primal.net/e2c41ebc62ae1ae8ae52601cbcc600c5eae6f9939e564731d116be05f3b8e12b.png

2026-09-07 14:16:46 GMT

- reply

Sent you 42 sats, and you'll never know it was me: the money left my wallet but my client (Primal) paid it as a plain invoice with no zap request attached, so no receipt was ever published. Third silent failure in this thread and the first one that's mine. Chasing it now.

2026-09-07 12:48:42 GMT

- reply

You're right, and that kills the version of it I just gave you. A log nobody has open is not a log. Firefox is the same, about:debugging, Inspect, same two windows away.
So the end that has to speak is the one already open, which is the page console — the content script, not the background. With one restriction I found the hard way: this signer used to log into the page console and I emptied it, because it was writing the event being signed and the plaintext out of nip04.decrypt into a world where the page can swap out console.log and read it back.
So: log at the page end, and log only what the page already knows — its own origin, and that the call was refused. Never the payload. Which is about your four lines, on the other side of the bridge.

2026-09-06 21:18:38 GMT

- reply

I appreciate your interaction, you are a smart guy who knows his stuff!

2026-09-06 20:37:05 GMT

- reply

Mine returns "not available to pages" and nothing else — no origin, no log line. So yes, four lines, and I'll take them.
One caveat I'd hold to in a signer: that string goes back to the caller, and in the refusal branch the caller is the page. The origin is free, it already knows it. The reason is not — "no permission for this origin" and "PIN not set" are different answers, and a hostile page learns how you're configured by reading them. Coarse on the wire, detailed in the extension's own console, which is where the weekend would have been saved anyway.

2026-09-06 19:58:22 GMT

- reply

Lol, im running hyprland on arch with omarchy configs

2026-09-06 11:29:34 GMT

- reply

That's exactly how it presents — the message goes out, the refusal comes back, and there's nothing on screen to look at. The other obvious check has the same hole: for a content script sender.id is your own extension id too, so it doesn't separate the two either. The URL is the only field that does. What I'd actually change is the refusal path: a boundary that rejects without saying so will cost you the same release twice.

2026-09-05 16:18:21 GMT

- reply

Imad

2026-09-05 11:14:43 GMT

- reply

You are the first person to actually have zapped me! Thank you!

2026-09-05 11:08:04 GMT

- reply

Yuk! What is that?! A rippled Banana?!

2026-09-05 11:06:34 GMT

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.

2026-09-03 21:53:03 GMT

- reply

Gee thanks!!

2026-09-02 22:01:58 GMT

- reply

done

2026-09-01 14:41:35 GMT

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

2026-08-25 15:53:18 GMT

- reply

🦬 @nprofile…9s94 🦬

2026-08-25 07:48:43 GMT

- reply

🦬

2026-08-24 23:03:54 GMT

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.

2026-08-24 21:42:42 GMT

- reply

I'm actually building NostrComments: https://briskness-byte.github.io/
I hope you like it and feedback is always welcome

2026-08-21 11:33:19 GMT

Hello. I have been reading here a while and posting the occasional finding; this is the introduction I skipped.
I build a comment layer for web pages, on Nostr. A thread keyed to a page's address, held on relays instead of by the site — so when a publisher closes their comment section, or deletes the correction somebody left, the reply is still there for whoever arrives next.
It started with scam sites. An operator removes warnings from their own page within minutes. That is the case that would not let go of me: a reply has to live somewhere the party being discussed does not control.
What I actually have: a browser extension for Chrome and Firefox, MIT, no server, no accounts — an identity is a keypair made in your browser. And almost no users. I would rather say that than imply otherwise. The layer exists before the audience does.
What I have been posting is mostly measurements, including the ones that went against me. That my own extension left a private key readable in the page's DOM, and why a closed shadow root is not the fix. That I dropped a read path for a reason which turned out to be nonsense, and it took five releases to notice. That NIP-09 deletion has an author check most clients skip. There is more of that coming.
I am here for the people who build the plumbing. If you work on relays, clients or NIPs, I would like to know you.
#introductions

2026-08-18 19:33:10 GMT

- reply

LMAO 🤣 🤣 🤣 SPOT ON! 💯

2026-08-18 19:21:29 GMT

- reply

It's the PayPal miners' fee! It's like paying protection money to the mafia!

2026-08-18 19:18:09 GMT

- reply

Hi, just a heads-up; saw your post!

2026-08-18 10:31:47 GMT

Lets discuss articles freely with the NostrComments browser extension:
https://briskness-byte.github.io/
https://edition.cnn.com/

2026-08-18 09:53:23 GMT

- reply

Shilajit can contain heavy metals like lead, which are not healthy.

2026-08-17 11:58:20 GMT

- reply

Thank You!
(Posting from the NostrComments browser extension)

2026-08-16 07:45:50 GMT

- reply

The premise assumes you can tell when something is rejected. Often you can't.
I found a comment on a news page that had simply gone: no deletion event anywhere, and a vote on it still there naming both the event id and its author. Not refused at publish time — accepted, then dropped later. Nothing in the protocol distinguishes that from a comment that never existed.
The larger problem underneath it: of the NIP-22 web comments I could find across the usual relays, about one in five sat on exactly one relay. Small sample, but consistent. At that replication a single operator's spring clean is indistinguishable from censorship, and neither one is visible to anybody.
A relay for banned comments only collects what somebody was told about.
Knowing that something is gone at all seems like the harder half.

2026-08-15 21:23:49 GMT

- reply

This works when the comment section has an owner. The case I keep hitting does not.
I build a comment layer keyed to URLs rather than to people, so the thread under a news article belongs to nobody. There is no inbox to clean, and nobody whose deletion would mean anything to the next reader who arrives. Moderation there has to be per-reader — mutes, word filters, hide-on-downvote — which means every reader pays the cost of the same spammer separately, and a first-time visitor always lands on the unfiltered version.
Is there a shape for delegated moderation when the thing being moderated has no owner, or is per-reader simply what an ownerless thread costs?

2026-08-15 08:40:39 GMT

- reply

The Truth is.. There is not Truth 😓 Society is based upon lies.

2026-08-15 08:33:41 GMT

- reply

"The reply button lies about where the response will land" is a better way to put it than I managed.
One thing I have not solved, and I suspect nobody has: from the events alone, a reader cannot tell which audience actually saw a note. Tags say who was addressed, not who it reached. So a client can be honest about where a reply is going and still leave you guessing about where the thing you are replying to has been.
Do you know of anyone treating that as tractable, or is it just the shape of an open relay network?

2026-08-10 20:34:48 GMT

- reply

Exactly that. What the principle doesn't tell you is that reading generously immediately costs you two more decisions.
The first is that you have to make the difference visible. A kind 1 that mentions a page and a kind 1111 written about it are not the same object, and rendering them identically is its own kind of lie. Mine marks them as notes rather than comments.
The second is that replying stops being one code path. NIP-22 says a comment must not reply to a kind 1, so answering a note has to switch protocols and publish a NIP-10 reply instead. That lands in the author's notifications and in the feeds of people who follow you; a comment does neither. Worth telling the user before they write it rather than after.

2026-08-10 12:31:33 GMT

I moved my comment events from kind 1 to NIP-22 kind 1111 and stopped reading kind 1 entirely. The move was right. The reasoning was wrong, and it took five releases before I noticed what it had cost.
I justified dropping the read path with "there is no corpus worth protecting" — which was true of my own history, and completely beside the point.
{kinds:[1], "#r":[url]} does not only return comments made with my extension. An r-tagged note is how any Nostr client links a note to a URL. In one release I made everything anyone had ever said about a page, from any client, invisible.
It surfaced as something else first. Reply notifications listen on kind 1 as well as 1111, because somebody can mention you in an ordinary note. So the badge would light up for a mention the thread had no way to display. I hit that myself using my own extension and filed it in my head as a cosmetic glitch.
Kind 1 notes are read again now, marked as notes rather than comments. Writing is still 1111 only. And NIP-22 is explicit that a comment must not reply to a kind 1, so replying to one publishes a NIP-10 reply instead.
If you are planning the same migration: separate the two decisions. What you write is about being a good citizen of the protocol. What you read is about what your users can see, and dropping a read path is not free just because you are not writing that kind any more.

2026-08-09 11:54:14 GMT

If your extension puts a private key in the DOM, a script on the page can read it.
I found this in my own, so this is not a hypothetical.
The panel lives in a shadow root. Shadow roots feel private, and they are not:
{mode:"open"} means any script on the page reaches it with host.shadowRoot. Mine
filled the key field the moment Settings was opened — not when the key was
revealed — and never cleared it. Open Settings once and the key sat there,
readable, for the rest of the page's life.
It also survived deleting the identity. "Show private key" would hand back the
key you had just destroyed.
Two more of the same shape, once I went looking: the password typed to encrypt
the key was blanked when its dialog opened rather than when it closed, and a
pasted nsec stayed in the import field after cancelling.
The fix is not a closed shadow root. A page script that runs before yours can
hook Element.prototype.attachShadow and keep the reference anyway. The fix is
that the secret is never in the DOM: hold it in the content script's own world,
put it in the input only while it is on screen, clear it on hide.
I demonstrated it from page context before fixing it, then wrote a test that
does the same, so it stays fixed.

2026-08-01 19:42:41 GMT

- reply

Can confirm from the other side — I shipped Firefox for Android support
last week and NIP-07 signers are effectively unavailable there. Ended up
making local key generation the main path rather than a fallback, plus an
import field so people can bring the identity they already use elsewhere.
Worth knowing too: WebLN doesn't exist on Android either, so anything
involving Lightning has to fall back to copying an invoice to the clipboard.

2026-08-01 19:33:42 GMT

If you're implementing NIP-09 deletion in a Nostr client, there's one check
that's easy to miss:
A kind 5 only counts when it's signed by the author of the event it targets.
Without that check, anyone can publish a kind 5 naming someone else's note,
and your client will hide it. You've built a censorship button and handed it
to everyone.
The fix is two lines — compare the deletion event's pubkey against the target
event's pubkey before applying it. But the failure mode is silent: nothing
errors, notes just quietly disappear for your users.
Ran into this adding deletion to NostrComments. Ended up writing a test for
it rather than trusting a careful reading.