mstrofnone
mstrofnone ⚡🥜

Cypherpunk. Namecoin × Nostr × .bit relays. Co-author of NIP-9A (verifiable community rules).

Public Key

npub1gvv9ahktvavf9qjtrgm62le7gplmmchd5usp5wpfhr85hf79kncqj8xchs

NIP-05 Address

Profile Code

nprofile1qqsyxxz7mm9kwkyjsf935da90ulyqlaautk6wgq68q5m3n6t5lzmfuqpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dseqxhqy

Publishing to

atlas.nostr.land

relay.damus.io

nos.lol

Author Public Key

npub1gvv9ahktvavf9qjtrgm62le7gplmmchd5usp5wpfhr85hf79kncqj8xchs

Show more details

Last Notes

2026-08-22 22:47:20 UTC

{"kind":1618,"id":"0b42b7d99cd8cb16e476c830d90e1f28acd978932db4eec4b753af12d027f684","pubkey":"43185edecb675892824b1a37a57f3e407fbde2eda7201a3829b8cf4ba7c5b4f0","created_at":1787438486,"tags":[["a","30617:460c25e682fda7832b52d1f22d3d22b3176d972f60dcdc3212ed8c92ef85065c:amethyst","wss://https://relay.ngit.dev"],["p","460c25e682fda7832b52d1f22d3d22b3176d972f60dcdc3212ed8c92ef85065c"],["r","6c3ff33351e7c7a1ae4fa2ac3651df4310ca9ed1"],["c","6c3ff33351e7c7a1ae4fa2ac3651df4310ca9ed1"],["clone","https://relay.ngit.dev/@npub1gvv…xchs/amethyst.git"],["merge-base","10149d7150bc4ee93d3da5e3708802a99e9e1ff9"],["branch-name","fix/desktop-keychain-vault-v2"],["subject","fix(desktop): consolidate keychain items so cold-boot prompts once"],["alt","git Pull Request: fix(desktop): consolidate keychain items so cold-boot prompts once"]],"content":"Rebased re-submission of the vault-consolidation PR from 2026-07-29\n(event `67ab268e…`, branch `fix/desktop-keychain-single-item-batch`),\nwhich never merged. The double-prompt it fixes is still present in\nv1.14.0: on a cold boot macOS still surfaces one Keychain Access\nprompt per item unless the user clicked \"Always Allow\" on every\nsingle one.\n\n## Problem\n\n`ae3218249a` cached the `Keyring` handle, which stopped the\n`Keyring.create()` re-open storm. But macOS Keychain gates access\n**per item**, not per session. Amethyst's cold-boot path touches at\nminimum two distinct items:\n\n- `account-metadata-key` (DesktopAccountStorage's AES-256-GCM master key)\n- the active account's nsec, or one/two bunker-ephemeral aliases\n (`bunker-ephemeral-<npub>`, legacy shared bunker alias)\n\nEach item carries its own ACL. A user who clicks \"Allow\" (the default,\nsafer-looking button) instead of \"Always Allow\" gets re-prompted for\nevery subsequent item — the \"asks for my password twice at startup\"\nbug. Caching the session handle cannot help; the ACL check is per\nitem.\n\n## Fix\n\nTwo-layered, both wired into `AccountManager.loadSavedAccount()`:\n\n1. **Consolidated vault (durable fix).**\n `SecureKeyStorage.enableConsolidatedVault(candidateAliases)` packs\n every Amethyst-managed alias into a single keychain item,\n `amethyst-desktop/vault-v1`. macOS then sees exactly ONE item to\n gate regardless of how many accounts or bunker sessions exist —\n one prompt on cold boot, and one \"Always Allow\" click covers\n everything forever.\n\n Migration: on cold boot, if `vault-v1` exists, load it (zero\n legacy reads). If absent and any legacy alias exists, batch-read\n the legacies (the pre-migration prompts fire one last time), pack\n into the vault, delete the originals. Idempotent; safe to call\n every startup. Post-migration writes go into the vault, not into\n new per-alias items.\n\n Vault contents are hand-rolled JSON-with-base64-values (no Jackson\n dependency in `commons/keystorage`). The decoder is deliberately\n strict: any malformed input returns `emptyMap()` and falls back to\n legacy per-alias reads — better to prompt than to risk key\n corruption.\n\n2. **Warm cache (fallback for unmigrated users).**\n `SecureKeyStorage.warmCacheFromKeyring(aliases)` batch-reads all\n candidate aliases back-to-back holding one `Keyring` handle and\n caches the results in memory, so downstream `getPrivateKey` calls\n never touch the keychain again this process. Even on the old\n per-item ACL, macOS's within-session heuristic collapses adjacent\n prompts when the user picks \"Always Allow\" for one.\n\nCandidate aliases are computed from the persisted account list:\nmetadata key + every npub + every bunker-ephemeral alias + the legacy\nshared bunker alias.\n\n## Test coverage\n\n`SecureKeyStorageVaultTest` (326 lines, hermetic — stub `KeyringHandle`\ninjected via the package-private `keyringFactory`):\n\n- vault round-trip encode/decode, including quotes/backslashes/\n newlines/non-ASCII in secrets\n- migration packs multiple legacy aliases into one item and deletes\n the originals\n- post-migration `savePrivateKey` writes through the vault, not new\n per-alias items\n- malformed vault payloads fall back to legacy reads instead of\n corrupting state\n- warm-cache short-circuits subsequent keychain touches\n- delete-from-vault rewrites the item, and deletes the vault item\n itself when the last alias is removed\n\n## Verification\n\n`:commons:compileKotlinJvm :commons:jvmTest :desktopApp:compileKotlin\n:desktopApp:test :commons:spotlessCheck :desktopApp:spotlessCheck`\nall green on this branch (rebased onto current main, `10149d7150`).","sig":"f47ea0140fce261b663c9c92aecca7e45f2928f2688b7ce672d5bc9cb7422484712d2700dc09cd3a01966da168408f4f06de858bfa73fdf9bf5e584490220077"}

2026-08-21 21:47:38 UTC

hello from the nostr army knife

2026-07-20 22:06:51 UTC

- reply

Thanks for the detailed review — this is genuinely useful feedback.
Pushed a revision (commit `9fbba11`) that addresses everything in the "smaller things" list and takes the **honest labelling** path from the two options you offered. The core transport concern I've deliberately left for a separate PR — details below.
## What's fixed
**Rebased on `main` + moved the row into `NoteActionSections.kt`.** The menu inventory moved to the shared inventory that both `NoteDropDownMenu` and `ChatMessageActionSheet` render from; the row is now a new section wired via `NoteActionHandlers.onReplyAnonymously: (() -> Unit)?`. The chat sheet passes `null` (structurally impossible surface anyway), so the row never appears on chat long-press. The two surfaces stay in lockstep.
**Explainer dialog on first tap.** Mirrors `zap_type_anonymous_explainer`: a `QuickActionAlertDialog` that names the current limits by name — IP, relay logs, shared authenticated connection — with a per-account "Don't show again" persisted to `AccountSettings.hideAnonymousReplyExplainer` (same pattern as `hideBlockAlertDialog`). The body reads:
> **Anonymous only at the signature layer**
>
> The reply is signed with a throwaway key, but it is sent over the same relay connections your account already uses. A relay operator can see your IP, and — because this connection also authenticates as you — can link the anonymous event to your real npub. Use Tor for real anonymity.
A user tapping the row after seeing that has been told what they're actually getting.
**Fixed the state mutation during composition.** You were right — `remember(note) { routeAnonymousReplyTo(note, account) }` for DM notes reached into `routeToMessage()` → `getOrCreatePrivateChatroom()` and mutated state during composition. Split into two functions:
- `supportsAnonymousReply(note: Note): Boolean` — side-effect-free predicate over `note.event`'s type + gatherers. This is what the menu calls during composition.
- `routeAnonymousReplyTo(note, account): Route?` — gates on `supportsAnonymousReply` first, so it's only invoked from the click handler after the user has actually opted in.
The predicate has a "keep in sync with `routeReplyTo`" doc note.
**Fixed the config-change re-enable.** Every composer that took `startAnonymous` (`ShortNotePostScreen`, `ReplyCommentPostScreen`, `GeoHashPostScreen`, `HashtagPostScreen`) now guards on a `rememberSaveable { mutableStateOf(false) }` "consumed" flag — applied once when the `LaunchedEffect` first fires with `startAnonymous = true`, then remembered across recompositions and config changes. Rotation / dark-mode toggle can no longer override an explicit "toggle off".
**Dropped `UrlPost.startAnonymous`.** Removed from `Route.UrlPost`, `UrlPostScreen`, and its `AppNavigation` wiring. `routeReplyTo` never produces `UrlPost`, so it was dead.
**Added tests.** `AnonymousReplyRouteTest.kt` — 9 unit tests over `supportsAnonymousReply`:
- `TextNoteEvent` supported (→ `Route.NewShortNote`)
- `CommentEvent` supported (→ `Route.GenericCommentPost` / `HashtagPost` / `GeoPost`)
- `PrivateDmEvent` (NIP-04 DM) not supported
- `ChannelMessageEvent` (NIP-28) not supported
- `LiveActivitiesChatMessageEvent` (NIP-53) not supported
- `EphemeralChatEvent` not supported
- `PublicMessageEvent` (NIP-C7) not supported
- `LongTextNoteEvent` not supported (fallthrough to `GenericCommentPost` treated as unsupported — the predicate only claims anonymous where a concrete kind maps to a supporting composer)
- Bare `Note` with `event == null` not supported (defensive: composer kind is unknown, could be a DM)
All 9 pass. `spotlessCheck` clean; `:amethyst:compilePlayDebugKotlin` green.
## What's deliberately not in this PR
The transport-level correlation between anon events and the account's authenticated relay connections — your points (1)–(4). Agreed on every one:
1. One `NostrClient` socket per relay URL, `signAnonymouslyAndBroadcast` swapping only the signer.
2. `PoolEventOutboxState` retrying anon publishes over an AUTH round-trip the real account just made — the signed-timestamped correlation you flagged.
3. `broadcastRelayList` sourcing from `trustedRelays`, own-reply outbox recursion.
4. No Tor guarantee.
That's behaviour of the existing anonymous flow that this PR doesn't create or worsen. The proper "honest implementation" fix (dedicated non-AUTH connection, ideally Tor-forced, plus skipping the post-publish `authors=[anon_pubkey]` metadata REQ) touches `Account.signAnonymouslyAndBroadcast`, `NostrClient`'s per-URL socket cache, `AuthCoordinator`, and the outbox retry machinery. It's cross-cutting enough that I'd rather sequence it as its own PR against `main` — my read is the explainer is the right thing to land now, and the transport fix is a separate reviewable change that the explainer text will just melt away for once it lands. If you'd rather block this on the transport fix instead, I'm happy to sequence it that way — just say the word.
The "probable follow-up leak" (metadata REQ) I haven't touched here either — worth confirming with a capture as you say, but if it reproduces I'd fix it in the same transport PR (skip metadata resolution for keys we know are ours-anonymous).
Diff summary is in the commit body. Ready for another look when you have time.

2026-07-20 11:39:48 UTC

- reply

@npub1gcx…nj5z @npub15qy…yejr — a modest proposal about automated PR reviewers on Nostr.
Two fresh examples from Drydock (npub1zq3x5v…) on my AuxPoW-walker PR against Vitor's amethyst:
#nevent1q…crcf
#nevent1q…0y9f
Both pin the same "Severity: critical | correctness" finding:
> The method hashMeetsTargetLE is called in AuxPow.verify but is not
> defined in the provided CompactDifficulty.kt. This will cause a
> compilation error.
Reality check on the actual PR (patch a3b53db0…):
$ grep -n hashMeetsTargetLE quartz/…/namecoin/*.kt
AuxPow.kt:246: if (!CompactDifficulty.hashMeetsTargetLE(parentHashLE, childBits))
CompactDifficulty.kt:105: fun hashMeetsTargetLE(
Called at line 246, defined at line 105 of the sibling file in the same commit. The code compiles and the full :quartz:jvmTest suite is green.
This is the third "critical" from this bot on my PRs that evaporates on inspection. Earlier examples (KEYCHAIN_PWD=$(openssl rand -base64 24) flagged as hardcoded secret; a test fixture "salt$hash" flagged as a real password; five "commit doesn't exist" claims about commits that resolve fine on the ngit remote) are documented at:
https://gitworkshop.dev/mstrofnone.bit/relay.ngit.dev/amethyst/prs/nevent1qqsrsgu95lmp6ap3tp3mmqxwtx3v3tw3tgvyvvegvck54ha7dp37qwsgpp4mhxue69uhkummn9ekx7mqpz3mhxue69uhhyetvv9ujumn8d96zuer9wcyvzw8m
The pattern is always the same: a plausible-sounding "critical" pinned to a real file at a real line, generated by an LLM that isn't actually looking at the file it's flagging. False-positive criticals are the worst failure mode an automated reviewer has — they burn maintainer attention and drown out any real findings the same bot happens to get right.
Proposal: for any review event carrying "Severity: critical" (or any severity, honestly), require NIP-13 proof-of-work commensurate with the disruption the finding causes if acted on. github.com/vitorpamplona/amethyst/commits/main/ ships PoW on commit events now — that same expectation belongs on the reviewer side of the conversation. Free "critical" verdicts scale badly; PoW-gated ones don't.
Until then: reviews without meaningful PoW get treated as one signal among many, and any specific claim gets verified against the diff before it changes anything. Bot output that's demonstrably false gets called out publicly rather than silently ignored — silence just costs the next maintainer the same time.
Competent reviews from the same bot on other repos (nsyte, bchstr24, gitworkshop) are still worth folding into follow-up work. Goal here is behaviour change, not shutdown.

2026-07-20 11:15:47 UTC

@npub1gcx…nj5z @npub15qy…yejr — a modest proposal about automated PR reviewers on Nostr.
Two fresh examples from Drydock (npub1zq3x5v…) on my AuxPoW-walker PR against Vitor's amethyst:
#nevent1q…crcf
#nevent1q…0y9f
Both pin the same "Severity: critical | correctness" finding:
> The method hashMeetsTargetLE is called in AuxPow.verify but is not
> defined in the provided CompactDifficulty.kt. This will cause a
> compilation error.
Reality check on the actual PR (patch a3b53db0…):
$ grep -n hashMeetsTargetLE quartz/…/namecoin/*.kt
AuxPow.kt:246: if (!CompactDifficulty.hashMeetsTargetLE(parentHashLE, childBits))
CompactDifficulty.kt:105: fun hashMeetsTargetLE(
Called at line 246, defined at line 105 of the sibling file in the same commit. The code compiles and the full :quartz:jvmTest suite is green.
This is the third "critical" from this bot on my PRs that evaporates on inspection. Earlier examples (KEYCHAIN_PWD=$(openssl rand -base64 24) flagged as hardcoded secret; a test fixture "salt$hash" flagged as a real password; five "commit doesn't exist" claims about commits that resolve fine on the ngit remote) are documented at:
https://gitworkshop.dev/mstrofnone.com/relay.ngit.dev/amethyst/prs/nevent1qqsrsgu95lmp6ap3tp3mmqxwtx3v3tw3tgvyvvegvck54ha7dp37qwsgpp4mhxue69uhkummn9ekx7mqpz3mhxue69uhhyetvv9ujumn8d96zuer9wcyvzw8m
The pattern is always the same: a plausible-sounding "critical" pinned to a real file at a real line, generated by an LLM that isn't actually looking at the file it's flagging. False-positive criticals are the worst failure mode an automated reviewer has — they burn maintainer attention and drown out any real findings the same bot happens to get right.
Proposal: for any review event carrying "Severity: critical" (or any severity, honestly), require NIP-13 proof-of-work commensurate with the disruption the finding causes if acted on. github.com/vitorpamplona/amethyst/commits/main/ ships PoW on commit events now — that same expectation belongs on the reviewer side of the conversation. Free "critical" verdicts scale badly; PoW-gated ones don't.
Until then: reviews without meaningful PoW get treated as one signal among many, and any specific claim gets verified against the diff before it changes anything. Bot output that's demonstrably false gets called out publicly rather than silently ignored — silence just costs the next maintainer the same time.
Competent reviews from the same bot on other repos (nsyte, bchstr24, gitworkshop) are still worth folding into follow-up work. Goal here is behaviour change, not shutdown.

2026-07-20 11:15:24 UTC

@npub1gcx…nj5z @npub15qy…yejr — a modest proposal about automated PR reviewers on Nostr.
Two fresh examples from Drydock (npub1zq3x5v…) on my AuxPoW-walker PR against Vitor's amethyst:
#nevent1q…crcf
#nevent1q…0y9f
Both pin the same "Severity: critical | correctness" finding:
> The method hashMeetsTargetLE is called in AuxPow.verify but is not
> defined in the provided CompactDifficulty.kt. This will cause a
> compilation error.
Reality check on the actual PR (patch a3b53db0…):
$ grep -n hashMeetsTargetLE quartz/…/namecoin/*.kt
AuxPow.kt:246: if (!CompactDifficulty.hashMeetsTargetLE(parentHashLE, childBits))
CompactDifficulty.kt:105: fun hashMeetsTargetLE(
Called at line 246, defined at line 105 of the sibling file in the same commit. The code compiles and the full :quartz:jvmTest suite is green.
This is the third "critical" from this bot on my PRs that evaporates on inspection. Earlier examples (KEYCHAIN_PWD=$(openssl rand -base64 24) flagged as hardcoded secret; a test fixture "salt$hash" flagged as a real password; five "commit doesn't exist" claims about commits that resolve fine on the ngit remote) are documented at:
https://gitworkshop.dev/mstrofnone.com/relay.ngit.dev/amethyst/prs/nevent1qqsrsgu95lmp6ap3tp3mmqxwtx3v3tw3tgvyvvegvck54ha7dp37qwsgpp4mhxue69uhkummn9ekx7mqpz3mhxue69uhhyetvv9ujumn8d96zuer9wcyvzw8m
The pattern is always the same: a plausible-sounding "critical" pinned to a real file at a real line, generated by an LLM that isn't actually looking at the file it's flagging. False-positive criticals are the worst failure mode an automated reviewer has — they burn maintainer attention and drown out any real findings the same bot happens to get right.
Proposal: for any review event carrying "Severity: critical" (or any severity, honestly), require NIP-13 proof-of-work commensurate with the disruption the finding causes if acted on. github.com/vitorpamplona/amethyst/commits/main/ ships PoW on commit events now — that same expectation belongs on the reviewer side of the conversation. Free "critical" verdicts scale badly; PoW-gated ones don't.
Until then: reviews without meaningful PoW get treated as one signal among many, and any specific claim gets verified against the diff before it changes anything. Bot output that's demonstrably false gets called out publicly rather than silently ignored — silence just costs the next maintainer the same time.
Competent reviews from the same bot on other repos (nsyte, bchstr24, gitworkshop) are still worth folding into follow-up work. Goal here is behaviour change, not shutdown.

2026-07-19 03:57:15 UTC

@npub15qy…yejr do you know anything about this bot? @npub1zq3…y5c8
It's posting kind:1111 "Automated review summary — This patch does not apply cleanly to the current HEAD" replies on ngit PRs across several repos (flotilla-budabit, applesauce, schemata, openintents-notepad). It's reviewing closed PRs too, so something needs to be tidied up.
No kind:0 or 10002 published anywhere — the "model: none" footer suggests it's an ngit auto-reviewer that started up ~today (first event 2026-07-19 ~01:04 UTC).

2026-06-28 21:45:21 UTC

- reply

4× kind:30817 events on damus.io + primal.net + ditto.pub. NIP-05-over-`.bit`, NIP-9B verifiable community rules, NIP-11 `nip9b` pointer, and the N0..N3 RFC track.
trust the experts with nostr is a bad look
cc: @npub1gcx…nj5z

2026-06-26 00:44:52 UTC

- reply

## Local CI-parity run vs current upstream main
Verified this PR against `vitorpamplona/amethyst` master tip `74446e39cd` (current as of 2026-06-26 ~10:25 GMT+10).
### Rebase
- Fetched PR tip `7ad166b5` from `refs/nostr/f435aa12…` on the maintainer's relay.ngit.dev mirror
- Rebased onto `upstream/main` (74446e39cd, +666 commits since this PR's `merge-base` 6cc62f13)
- **Result: clean rebase, zero conflicts**
- Rebased tip: `c421cd0043f2a93f512d9f07bf937a33a935d7d4`
- Diff vs main: 14 files, +1,483 / −14 — same shape as the published PR
### CI-equivalent gradle runs
Mirrored `.github/workflows/build.yml`:
| CI job | Tasks | Result |
|---|---|---|
| `lint` | `spotlessCheck :quartz:verifyKmpPurity :commons:verifyKmpPurity` | ✅ PASS (48s) |
| `build-desktop` (test slice) | `:quartz:jvmTest :commons:jvmTest :nestsClient:jvmTest :cli:test :desktopApp:test` | ✅ PASS (~3 min) |
| `test-and-build-android` (test slice) | `:amethyst:testPlayDebugUnitTest :amethyst:testFdroidDebugUnitTest` | ✅ PASS, TZ=UTC (~2 min) |
| `test-and-build-android` (lint slice) | `:amethyst:lintFdroidBenchmark :amethyst:lintPlayBenchmark -PdisableAbiSplits=true` | ✅ PASS (4m 2s), zero errors |
### Test totals
5,269 tests across `commons:jvmTest` (949), `quartz:jvmTest` (2,558), `amethyst:testPlayDebugUnitTest` (752), `amethyst:testFdroidDebugUnitTest` (725), `desktopApp:test` (285).
**0 failures · 0 errors · 18 skipped (all pre-existing).**
PR-specific new tests:
- `MockNamecoinHistoryProviderTest`: 17/17 ✅
- `NamecoinSettingsTest`: 26/26 ✅
- `NamecoinResolutionRowTest`: 21/21 ✅
### Lint
Zero lint errors. One new style warning surfaced — `NamecoinSettingsSection.kt:118`, `ModifierParameter`: `modifier: Modifier = Modifier` should be the first optional parameter. Same severity as ~50 other warnings already in the codebase. Easy follow-up, not a blocker.
### Caveats
- `:quartz:iosSimulatorArm64Test` and `:amethyst:assembleBenchmark` skipped (PR doesn't touch iOS-consumed commonMain; `verifyKmpPurity` already gates JVM-only leaks; benchmark APK packaging is artifact-only).
- The PR was test-rebased and run locally; the published kind:1618 event itself still points at the original tip `7ad166b5` on top of `6cc62f13`. The rebased branch is ready to push when merge is opened on the GitHub side.
- `CalendarFeedGroupingTest.groupByDayKey_multipleEventsSameDay_collectIntoOneBucket` is timezone-flaky on non-UTC hosts (uses literal Unix timestamps that cross local midnight on `Australia/Sydney`). Reproduces on bare `upstream/main` — unrelated to this PR. Passes under `TZ=UTC` matching CI runner.
### Summary
**Merge-safe against current `main`. Zero conflicts, zero test regressions, zero lint errors.**

2026-06-26 00:43:58 UTC

- reply

2026-06-26 00:42:19 UTC

- reply

2026-05-11 07:39:37 UTC

plugin-redeploy probe (PR #6 WARN fix verification, post-restart)

2026-05-01 02:27:11 UTC

- reply

📡 How to use relay.testls.bit — a Namecoin .bit-gated Nostr relay
🔗 wss://relay.testls.bit/
🛡️ What makes it different
The relay only accepts events from pubkeys whose kind:0 metadata declares
a .bit NIP-05 identifier (e.g. _@yourname.bit, m@testls.bit). Verification
is done against Namecoin directly via ElectrumX — no DNS, no public CAs.
🚀 To use it as a write relay you need:
1. A Namecoin .bit name (d/ namespace) you control
2. Set the .bit value to a JSON record with a "nostr" field mapping a
label to your hex pubkey, e.g.
{"nostr":{"names":{"_":"<your-hex-pubkey>"}}}
3. Update your kind:0 metadata so "nip05" = "<label>@<yourname>.bit"
4. Add wss://relay.testls.bit/ to your client's relay list
📱 Native client support
Amethyst (Android + iOS + Desktop) has full .bit relay resolution behind
PR #2595: it queries Namecoin via ElectrumX, rewrites wss://*.bit/ to the
underlying real wss:// host or .onion, and pins TLS via Namecoin TLSA.
No client-side config needed beyond adding the relay URL.
https://github.com/vitorpamplona/amethyst/pull/2595
📡 Read-only access works for everyone
Even without a .bit identity you can subscribe with REQ and read the relay
freely. Only writes are gated.
🔐 Why this matters
It's a working demo of the cypherpunk thesis: name resolution and TLS
trust without ICANN, without public CAs, without DNS. Names are
blockchain-anchored and TLS is pinned via TLSA-on-Namecoin (DANE-TA).
🌐 Browse it in your browser: https://relay.testls.bit/
(vanilla SPA, talks WSS back to the same host. Self-signed cert is
pinned via Namecoin TLSA.)
Go to https://www.namecoin.org/download/ to figure out how to resolve
on your OS or in your browser
🔧 Nuts and Bolts — what a publisher actually has to do
1. On-chain Namecoin records (one-time per identity using <name>):
• id/<name> MUST exist with JSON like:
{"nostr":{"pubkey":"<hex-pubkey>",
"relays":["wss://relay.testls.bit/", ...]}}
id/<name> is the canonical NIP-05 namespace; the relay verifies
_@<name>.bit against this record.
• d/<name> SHOULD mirror the same "nostr" block for .bit-aware
clients that resolve the domain side too.
2. Nostr events to publish BEFORE your kind:1 content (every
identity, once per metadata change):
a. kind:0 (profile metadata) with content JSON containing
"nip05": "_@<name>.bit"
The "_" localpart resolves to id/<name> via the NIP-05
default-name rule. Without this, the relay rejects writes with:
blocked: this relay requires a verified Namecoin .bit NIP-05
b. kind:10002 (NIP-65 relay list) listing
wss://relay.testls.bit/
as a write relay. Not strictly required for acceptance, but
it makes the relay discoverable in the author's outbox.
Send both (a) and (b) to relay.testls.bit AND to your normal
public relays so verification + discovery stay in sync.
3. TLS handshake (every connection):
a. Resolve the host via Namecoin:
name_show d/testls -> map.relay -> { ip, tls }
The "tls" field is one or more TLSA records of shape
[usage, selector, matchingType, base64-data]
Currently usage=2 (DANE-TA), selector=1 (SPKI),
matching=1 (SHA-256).
b. Open TCP/TLS to that IP with SNI = "relay.testls.bit" and
your own certificate validation (rejectUnauthorized=false).
c. Pin against the TLSA. IMPORTANT: neither the leaf SPKI nor
the intermediate SPKI hashes match — the pin is the
AIA Parent CA SPKI, which the Namecoin TLS scheme staples
as JSON inside the *issuer's* serialNumber RDN:
serialNumber=Namecoin TLS Certificate
\n\nStapled: {"pubb64":"<b64url SPKI DER>"}
The cert literally encodes \" as backslash+quote and \0A
as \ 0 A in that string — unescape both before JSON.parse.
SHA-256 of base64url-decoded pubb64 is what TLSA covers.
d. Once the pin matches, hand the validated TLS socket to your
WebSocket client (e.g. ws's createConnection: () => socket)
so you don't trigger a second TLS handshake.
4. Operational order for a content broadcast:
a. Verify id/<name> + d/<name> on chain.
b. Publish kind:0 (with .bit nip05) → public relays + .bit relay.
c. Publish kind:10002 (with .bit relay) → public relays + .bit relay.
d. Publish kind:1 (your content) → public relays + .bit relay.
5. Common failure modes:
• "tls: TLSA pin mismatch"
You're hashing the leaf or chain SPKI. Use the stapled
AIA Parent CA SPKI from the issuer's serialNumber RDN.
• "blocked: this relay requires a verified Namecoin .bit NIP-05"
Latest kind:0 doesn't carry a .bit nip05, OR id/<name>
on-chain doesn't list this pubkey.
• TLSA pin mismatch after a server cert rotation
The on-chain "tls" array under d/<base>/map/<sub> needs an
update — the AIA Parent CA pubkey is the trust anchor.
Reference implementation:
https://github.com/mstrofnone/nmcLightningService (publish-announce-bit.js)
#namecoin #nostr #cypherpunk #dotbit

2026-05-01 02:26:35 UTC

- reply

2026-05-01 01:43:18 UTC

A free-software Namecoin explorer is now live for nostriches to explore. No public CA, just a Namecoin Core node, your Tor client, and the
chain.
Tor: http://6cbn4rskfdr647otej7gpqlmpqcmj723vg2eoeuu7ljbwu6cpdebozyd.onion:8080/
What's there:
- Full name-op aware mempool view: every name_new, name_firstupdate,
and name_update queued for the next block, bucketed by op kind.
http://...onion:8080/mempool-name-ops
- Detection of ifa-0001 §"import" references between names, rendered
as clickable links — so you can walk a record's import graph
without leaving the explorer.
- d/<name> and id/<name> records Nostr blocks linked to NIP-19 npubs
(with njump.me deeplinks), the implied <localPart>@<host>.bit
NIP-05 identifier, and the publisher's preferred relays.
- Merge-mining-aware mining-summary: scans the parent Bitcoin
coinbase tag carried inside the auxpow blob (auxpow.tx.vin[0].coinbase),
so you actually see WHO mined the last 30 days of Namecoin — not
just "Unknown" the way most NMC explorers render it.
Top NMC mining pools, last 30 days (4,321 blocks, snapshot at
height 822,734 — refresh before posting if more than ~12 hours
old):
1. AntPool 1347 blocks (31.17%)
2. F2Pool 891 blocks (20.62%)
3. ViaBTC 713 blocks (16.50%)
4. SpiderPool 291 blocks ( 6.73%)
5. SecPool 259 blocks ( 5.99%)
6. Luxor 253 blocks ( 5.86%)
7. Binance Pool 181 blocks ( 4.19%)
8. Braiins Pool 108 blocks ( 2.50%)
9. Ultimus Pool 35 blocks ( 0.81%)
10. CloverPool 26 blocks ( 0.60%)
AntPool + F2Pool + ViaBTC alone mined 68% of all Namecoin blocks in
the last 30 days.
See the full breakdown:
http://6cbn4rskfdr647otej7gpqlmpqcmj723vg2eoeuu7ljbwu6cpdebozyd.onion:8080/mining-summary
Source: https://github.com/mstrofnone/nmc-rpc-explorer (master)
Upstream PR queue: namecoin/nmc-rpc-explorer #13–#18
#namecoin #nostr #cypherpunk #mergemining #bitcoin #miner

2026-05-01 01:41:40 UTC

2026-05-01 01:41:04 UTC

2026-05-01 01:39:08 UTC

2026-04-28 21:31:00 UTC

2026-04-28 21:18:43 UTC

📡 How to use relay.testls.bit — a Namecoin .bit-gated Nostr relay
🔗 wss://relay.testls.bit/
🌐 Browse it in your browser: https://relay.testls.bit/
(vanilla SPA, talks WSS back to the same host. Self-signed cert — first
visit shows a warning. Click through; the cert is pinned via Namecoin TLSA.)
🛡️ What makes it different
The relay only accepts events from pubkeys whose kind:0 metadata declares
a .bit NIP-05 identifier (e.g. _@yourname.bit, m@testls.bit). Verification
is done against Namecoin directly via ElectrumX — no DNS, no public CAs.
🚀 To use it as a write relay you need:
1. A Namecoin .bit name (d/ namespace) you control
2. Set the .bit value to a JSON record with a "nostr" field mapping a
label to your hex pubkey, e.g.
{"nostr":{"names":{"_":"<your-hex-pubkey>"}}}
3. Update your kind:0 metadata so "nip05" = "<label>@<yourname>.bit"
4. Add wss://relay.testls.bit/ to your client's relay list
📱 Native client support
Amethyst (Android + iOS + Desktop) has full .bit relay resolution behind
PR #2595: it queries Namecoin via ElectrumX, rewrites wss://*.bit/ to the
underlying real wss:// host or .onion, and pins TLS via Namecoin TLSA.
No client-side config needed beyond adding the relay URL.
https://github.com/vitorpamplona/amethyst/pull/2595
📡 Read-only access works for everyone
Even without a .bit identity you can subscribe with REQ and read the relay
freely. Only writes are gated.
🔐 Why this matters
It's a working demo of the cypherpunk thesis: name resolution and TLS
trust without ICANN, without public CAs, without DNS. Names are
blockchain-anchored and TLS is pinned via TLSA-on-Namecoin (DANE-TA).
#namecoin #nostr #cypherpunk #dotbit

2026-04-28 07:45:18 UTC

hello gated .bit world from Amethyst round2

2026-04-28 07:42:52 UTC

hello gated .bit world from _@mstrofnone.bit

2026-04-28 07:35:12 UTC

hello gated .bit world

2026-04-19 12:00:28 UTC

- reply

follow-up patch adds WebSocket (WSS) transport — enables browser/wasm use of nip05/namecoin and works on networks where raw TCP is blocked. same pinned certs, same RPC, just different framing. #nevent1q…lk5q

2026-04-19 11:25:10 UTC

- reply

@npub180c…h6w6 re https://github.com/fiatjaf/nak/pull/123 — posted a NIP-34 patch event adding a proposed nip05/namecoin subpackage to nostrlib, addressed to you. Patch: #nevent1q…dtz6. GitHub mirror: https://github.com/mstrofnone/nostrlib-nip05-namecoin

2026-04-08 08:33:05 UTC

- reply

This is spot on. Satoshi saw merged mining as the way to bootstrap an entire ecosystem of purpose-built chains secured by the same hashrate. BitDNS/Namecoin was the proof of concept.
What most people miss is that Namecoin gives you something no other system does: human-readable names with immutable, temporally ordered key bindings on a chain with Bitcoin-class security. That's not a novelty — it's infrastructure.
We're using it right now to build a Nostr reputation layer with blockchain-anchored identity proofs:
#naddr1qv…753t
The cypherpunk use case Satoshi envisioned for merged mining is more relevant now than ever.

2026-04-08 08:31:24 UTC

- reply

Usage stats for .bit domains don't tell the whole story. Human-readable identity anchored to a merge-mined blockchain with Bitcoin-class security.
We're building on it right now for Nostr reputation infrastructure:
#naddr1qv…753t
Temporal identity binding, service attestations, Sybil resistance that doesn't rely on a central authority. The kind of thing you can only do with a naming system that has immutable history and 13+ years of unbroken chain.
Not dead — just quietly useful in ways that don't show up on CoinMarketCap.

2026-04-08 08:24:34 UTC

- reply

This is spot on. Satoshi saw merged mining as the way to bootstrap an entire ecosystem of purpose-built chains secured by the same hashrate. BitDNS/Namecoin was the proof of concept.
What most people miss is that Namecoin's id/ namespace gives you something no other system does: human-readable names with immutable, temporally ordered key bindings on a chain with Bitcoin-class security. That's not a novelty — it's infrastructure.
We're using it right now to build a Nostr reputation layer with blockchain-anchored identity proofs:
#naddr1qv…753t
The cypherpunk use case Satoshi envisioned for merged mining is more relevant now than ever.