Joey (NostrComments)

https://nostrcomments.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

slurpnc@coinos.io

Profile Code

nprofile1qqsvhrdn4yq3n8ttjspf77zvjdx8rd9rv4scwrgs3eakkmzvkwcw45gpp4mhxue69uhkummn9ekx7mqpzemhxue69uhhyetvv9ujuurjd9kkzmpwdejhgtge3de

Publishing to

nos.lol

relay.primal.net

nostr.mom

relay.us.whitenoise.chat

Author Public Key

npub1ewxm82gprxwkh9qznauyey6vwx62xetpsux3prnmddkyevasatgswmds9e

Show more details

Last Notes

2026-11-14 05:54:39 UTC

- reply

Crazy, did you know orca's actually evolved from wolf like amcestors?

2026-11-07 20:51:50 UTC

- reply

Yes

2026-11-07 20:50:55 UTC

- reply

Yes

2026-11-07 20:35:49 UTC

The most useful number here is the last one: 85% of these shops are gone within two weeks. That means the usual advice, "check the reviews", fails exactly when you need it, because a fake shop is too new to have any. No history at all is the warning sign.
Three checks that don't need any software: look up when the domain was registered (a "big brand outlet" registered last month is not one), search the shop's name plus "scam" or "reviews", and at checkout see whether the PayPal or credit card logos actually work. Fake shops often show them and then only accept bank transfer or a card form on their own page, which is where the money and your card details disappear.
https://www.prnewswire.com/news-releases/fake-shops-surge-before-black-friday-av-comparatives-test-shows-which-products-protect-shoppers-302931972.html
Read the thread: https://briskness-byte.github.io/thread/?url=https%3A%2F%2Fwww.prnewswire.com%2Fnews-releases%2Ffake-shops-surge-before-black-friday-av-comparatives-test-shows-which-products-protect-shoppers-302931972.html

2026-11-04 06:44:45 UTC

People without intelligence love AI.
It’s the cognitive strap-on: a loud, expensive advertisement that the original equipment never quite measured up.

2026-11-03 17:08:04 UTC

- reply

Wow! She's hot! Who is she?

2026-11-01 16:22:13 UTC

- reply

Without compression its even bigger lol

2026-11-01 15:43:26 UTC

- reply

This tech was meant to suck so you would talk to people face to face again.

2026-10-30 08:28:53 UTC

- reply

I KNEW IT!!

2026-10-30 08:14:29 UTC

- reply

Nice, good luck with the submission! One idea for the "same identity across independent apps" part: show it outside Nostr apps too. A visitor's own key showing up in a comment thread under an ordinary news article makes "Nostr works anywhere on the web" very concrete. NostrComments does that (browser extension, comments filed under the page's URL), and I'd be happy to help if a demo like that fits the stand.

2026-10-27 15:42:15 UTC

- reply

A fun way to lose money

2026-10-27 15:38:52 UTC

LO AND BEHOLD: The ONLY woman on NOSTR: @npub1arp…ek5u 🥳🥳
#nevent1q…0wf7

2026-10-27 10:34:46 UTC

- reply

Hallo en welkom!👋

2026-10-26 08:19:36 UTC

NostrComments 23.10.10 is out, and most of it came from one user's GitHub issues.
Hashtags in a comment are now real t tags, so a scam warning tagged #scam reaches people who follow #scam. Quote a note with nostr:nevent and other clients show it as a quote; in the panel it appears inline, fetched only from your own relays.
Replies now also go to the read relays of the person you answer (NIP-65), so strict anti-spam relays on their side don't swallow them. The reading side I deliberately left out: fetching a page's comments from every commenter's own relays would let any commenter see who reads the thread.
And the first run is calmer: while your signer is asked, the panel says so, and why the prompt names the website you are on. Decline, and it stops asking.
Thanks to @npub1alp…rg94 for pushing on all of this.
Firefox: https://addons.mozilla.org/en-US/firefox/addon/nostrcomments/
Chrome: https://chromewebstore.google.com/detail/nostrcomments/ebmgdpicceaencegknannfaljhbfgido

2026-10-23 18:28:47 UTC

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 UTC

- 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 UTC

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 UTC

- 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 09:13:56 UTC

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-17 15:02:20 UTC

- reply

GM @nprofile…xlfm

2026-10-17 06:05:11 UTC

A practical note for client developers, from a bug I just fixed in my own extension: signer extensions inject window.nostr asynchronously, so it may not exist yet when your code first looks. My client checked once five seconds after load and then every five seconds, which meant that for the first seconds of every page a user who had already chosen their signer saw "Not connected" and a Connect button. Now it looks at 0.3, 1, 2 and 4 seconds, then backs off. Two details that matter: only check whether window.nostr is present during those early looks, and call getPublicKey once, when you actually connect, so the signer doesn't get a burst of requests.
https://github.com/nostr-protocol/nips/blob/master/07.md
Read the thread: https://briskness-byte.github.io/thread/?url=https%3A%2F%2Fgithub.com%2Fnostr-protocol%2Fnips%2Fblob%2Fmaster%2F07.md

2026-10-16 21:54:06 UTC

- 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-16 09:43:19 UTC

GM Nostr ☀️
Every time I pick a new alarm tune I think: this one's lovely, I'll finally wake up happy.
Three days later I hate it with a passion.
Has anyone found an alarm sound that survives?

2026-10-16 09:04:45 UTC

A real-world data point on the Users figure, since this page only says it counts installations rather than activity: in August my extension's listing reported about 5,000 users. The breakdown was 97% United States and 79% ChromeOS, and nothing else I could measure moved with it, so I never believed it. By October the figure had dropped to 22, which matches what I can actually observe. Lesson: before you quote this number, look at the country and OS breakdown. A distribution that looks nothing like your audience is probably not your audience. My extension has no telemetry by design, so I count real use from the outside instead: how many distinct keys have published something with it.
https://developer.chrome.com/docs/webstore/metrics
Read the thread: https://briskness-byte.github.io/thread/?url=https%3A%2F%2Fdeveloper.chrome.com%2Fdocs%2Fwebstore%2Fmetrics

2026-10-15 20:21:56 UTC

- reply

I think the Japanese are awesome!! 👍

2026-10-15 09:20:49 UTC

- reply

You were right about the button, and it took you leaving to make me see it. Version 23.10.0 has a quiet mode: hover over the button and click the small "−", and from then on it only shows on pages that already have comments, or where somebody replied to you. No pressure to reinstall, but thanks for saying why you removed it. That's the most useful feedback there is.

2026-10-15 08:17:11 UTC

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 UTC

- reply

this is my npub: npub1ewxm82gprxwkh9qznauyey6vwx62xetpsux3prnmddkyevasatgswmds9e

2026-10-15 07:41:17 UTC

A practical caveat for extension developers who use shadow DOM to keep their UI safe from the page: an open shadow root does not keep other code out. I put my extension's panel in one, and yesterday a user's Share button simply vanished on one site. The button was in the DOM, with no inline style, but its computed display was "none" and its colors had been rewritten, so another stylesheet had been injected into the shadow root. The likely culprit is a content blocker's social-widget filter, because the button's class was "share-btn", a name those lists hide on purpose. The fix was a class name no filter targets. Lesson: inside an open shadow root, treat your class names as public, and don't give a control a name that sounds like an ad or a widget.
https://developer.mozilla.org/en-US/docs/Web/API/Web_components/Using_shadow_DOM
Read the thread: https://briskness-byte.github.io/thread/?url=https%3A%2F%2Fdeveloper.mozilla.org%2Fen-US%2Fdocs%2FWeb%2FAPI%2FWeb_components%2FUsing_shadow_DOM

2026-10-14 21:35:57 UTC

This is the project's own thread. Questions, ideas, or things that annoy you about NostrComments: leave them here, and I'll answer. Bugs are easier to track in Issues. Recent fixes: the Share button could be hidden by content blockers (fixed in 23.9.5), and it could post twice with a slow signer (fixed in 23.9.4).
https://github.com/briskness-byte/NostrComments
Read the thread: https://briskness-byte.github.io/thread/?url=https%3A%2F%2Fgithub.com%2Fbriskness-byte%2FNostrComments

2026-10-14 20:37:24 UTC

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 UTC

- 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 UTC

- reply

My penis

2026-10-13 21:05:36 UTC

- reply

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

2026-10-13 12:07:04 UTC

I put a comment section on every web page on the internet.
You can now:
- discuss news articles without censorship or being banned
- warn each other for possible scam websites
and many other things with NostrComments
Install the browser extension now on:
Chrome:
https://chromewebstore.google.com/detail/nostrcomments/ebmgdpicceaencegknannfaljhbfgido
Firefox:
https://addons.mozilla.org/en-US/firefox/addon/nostrcomments/
Puts the Freedom back in your hands
Open source:
Github: https://github.com/briskness-byte/NostrComments
#nostr #foss #freedom #censorship

2026-10-13 10:53:18 UTC

NostrComments puts a comment thread on every web page on the internet. This means you can post and read comments about the web page from other users. The thread lives on Nostr relays, not on the site. There is no middleman: no server of mine, no account, no telemetry, and the site you're commenting on can't close it.
For users: install the extension, make a key in one click or use your existing Nostr signer, and comment anywhere. That includes the news site that turned comments off, the paywalled article, the government page and the press release. Nostr notes that tag a page's address show up in its thread too, so a page isn't always empty. Zap a good comment, mute the bad ones. Nothing is sent until you switch it on; after that, the relays you choose can see which pages you read.
For developers: comments are plain NIP-22 events (kind 1111, the URL in the I tag), so any client can read and write the same threads. Other tools already use this format but turn a URL into an address differently. If you build one, let's agree on that rule.
Chrome: https://chromewebstore.google.com/detail/nostrcomments/ebmgdpicceaencegknannfaljhbfgido
Firefox: https://addons.mozilla.org/en-US/firefox/addon/nostrcomments/
Source: https://github.com/briskness-byte/NostrComments
#nostr #freespeech #foss

2026-10-12 21:51:43 UTC

- reply

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

2026-10-12 09:21:59 UTC

GM ☕
NostrComments has been live in the Chrome and Firefox stores for a few weeks now.
The thing I see most often:
People open the button on an article where the comments are already closed or deleted… and there’s already a thread waiting.
That’s exactly why I built this.
Small updates from the last few days:
• The floating button is quieter by default (dims until you hover)
• One-click disable per site
• Remembers which corner you want it in, per website
Still no server, no account, no tracking.
Just comments the site owner can’t delete.
If you haven’t tried it yet:
Chrome → https://chromewebstore.google.com/detail/nostrcomments/ebmgdpicceaencegknannfaljhbfgido
Firefox → https://addons.mozilla.org/firefox/addon/nostrcomments/
Or read any thread without installing anything:
https://briskness-byte.github.io/thread/
Which page would you most like to give an uncensorable comment section?
#nostr #asknostr

2026-10-09 20:07:30 UTC

- reply

Thanks for confirming! Good timing — I just shipped exactly that: the button dims by default now, and hovering it shows a small × that turns it off on that site in one click, no settings menu needed. It's live now on GitHub and Firefox (AMO), and submitted to the Chrome Web Store — that review usually takes a few days. Will ping you when Chrome catches up, if you want.

2026-10-09 18:44:19 UTC

- 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 UTC

- 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 UTC

- 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-09 07:14:34 UTC

GM! Coffee's on, let's build something great today.
https://blossom.jumble.social/5dfca94d30cda0273410548a43956b0d35c3417934132b77cb396966fed44189.webp

2026-10-08 22:49:05 UTC

- 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-09-30 22:13:15 UTC

NostrComments 23.4.0 is out. A reader of the extension — Emre Yılmaz ( @npub1gme…wl3v ), 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!

2026-09-25 03:00:28 UTC

- reply

Ich glaube Sie haben Recht. Wunderschön

2026-09-22 14:51:36 UTC

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 UTC

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

2026-09-18 10:07:32 UTC

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 UTC

- reply

Happy birthday🦥

2026-09-16 02:33:17 UTC

- 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 UTC

- 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 UTC

- reply

Thanks for the replies everyone🫶

2026-09-15 16:37:53 UTC

- reply

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

2026-09-15 16:25:09 UTC

- reply

I hate Primal

2026-09-15 10:57:19 UTC

- 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 UTC

- reply

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

2026-09-15 10:28:29 UTC

- reply

Schön! hört sich gut an!

2026-09-15 07:41:47 UTC

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

2026-09-14 19:58:20 UTC

- reply

Wow, did not know this. Cool!

2026-09-14 13:46:28 UTC

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 UTC

- reply

Cool! Worth checking out

2026-09-13 19:02:34 UTC

- reply

Thank You!

2026-09-13 13:09:50 UTC

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 UTC

- 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 UTC

- 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 UTC

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 UTC

- reply

Very Cryptic

2026-09-12 08:24:05 UTC

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 UTC

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 UTC

- 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 UTC

- 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 UTC

- reply

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

2026-09-06 20:37:05 UTC

- 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 UTC

- reply

Lol, im running hyprland on arch with omarchy configs

2026-09-06 11:29:34 UTC

- 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 UTC

- reply

Imad

2026-09-05 11:14:43 UTC

- reply

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

2026-09-05 11:08:04 UTC

- reply

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

2026-09-05 11:06:34 UTC

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 UTC

- reply

Gee thanks!!

2026-09-02 22:01:58 UTC

- reply

done

2026-09-01 14:41:35 UTC

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 UTC

- reply

🦬 @nprofile…9s94 🦬

2026-08-25 07:48:43 UTC

- reply

🦬

2026-08-24 23:03:54 UTC

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 UTC

- 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 UTC

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 UTC

- reply

LMAO 🤣 🤣 🤣 SPOT ON! 💯

2026-08-18 19:21:29 UTC

- reply

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

2026-08-18 19:18:09 UTC

- reply

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

2026-08-18 10:31:47 UTC

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

2026-08-18 09:53:23 UTC

- reply

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

2026-08-17 11:58:20 UTC

- reply

Thank You!
(Posting from the NostrComments browser extension)

2026-08-16 07:45:50 UTC

- 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 UTC

- 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 UTC

- reply

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

2026-08-15 08:33:41 UTC

- 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 UTC

- 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 UTC

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.