Nostr notes by mstrofnone

Thanks for the detailed review — this is genuinely useful ...

2026-07-20T22:06:51Z

In reply to naddr1qq…qevy
_________________________

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.

@npub1gcx…nj5z @npub15qy…yejr — a modest proposal about ...

2026-07-20T11:39:48Z

In reply to naddr1qq…qevy
_________________________

VitorPamplona (npub1gcx…nj5z) DanConwayDev (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:

quoting
nevent1q…crcf

Automated review summary
The patch introduces a robust AuxPoW verification mechanism for Namecoin SPV, including a manual Bitcoin transaction parser and merkle branch walking. However, there is a critical compilation error due to a missing method in CompactDifficulty, and a potential logic error in the CompactDifficulty.decodeTargetBE implementation regarding the mantissa placement which could lead to incorrect PoW targets.

Findings
critical | correctness | quartz/src/commonMain/kotlin/com/vitorpamplona/quartz/nip05DnsIdentifiers/namecoin/AuxPow.kt:188 | The method hashMeetsTargetLE is called in AuxPow.verify but is not defined in the provided CompactDifficulty.kt. This will cause a compilation error.
medium | correctness | quartz/src/commonMain/kotlin/com/vitorpamplona/quartz/nip05DnsIdentifiers/namecoin/CompactDifficulty.kt:53 | The logic for placing the 3-byte mantissa in the 32-byte buffer is slightly flawed. If exponent is 3, topIndex is 29. The code sets out[29], out[30], and out[31]. This is correct for a 3-byte mantissa. However, the if (topIndex in 0..29) block is used to assign out[topIndex], out[topIndex+1], and out[topIndex+2]. If topIndex is 29, it writes to 29, 30, 31. This is fine. But if exponent is 32, topIndex is 0, it writes to 0, 1, 2. This is also fine. The issue is that the target is mantissa * 256^(exponent - 3). If exponent is 3, target is mantissa * 1. The mantissa is 3 bytes. The 3 bytes should be at the very end of the 32-byte array (indices 29, 30, 31). The current code does this. However, the logic for topIndex == 30 and topIndex == 31 is redundant or potentially incorrect if the mantissa is always 3 bytes. In Bitcoin, the mantissa is 3 bytes, and the exponent is the number of bytes in the mantissa plus the exponent value. Actually, the standard is: target = mantissa * 256^(exponent - 3). If exponent is 3, target = mantissa. The mantissa is 3 bytes. So the 3 bytes should be at the end. The code handles this. But the if (topIndex in 0..29) check is a bit brittle.
low | correctness | quartz/src/commonMain/kotlin/com/vitorpamplona/quartz/nip05DnsIdentifiers/namecoin/AuxPow.kt:138 | The skipBitcoinTx function returns Int?. If it returns null (due to malformed transaction or truncation), the verify function returns Result.Malformed. This is handled correctly, but the pos is not updated in the error case, which is fine as the block is rejected.

---
model: google_gemma-4-26B-A4B-it-Q4_K_M.gguf
context-hash: 7de1b365a6695a54e1080d4b56d381c68e8daf62f623c8cc1f1b8e8bf52e7b23
patch-event-id: a3b53db06b1d86ac36ee728381539ef0544b6b61b5473b53dc4e99759893194b
repo-id: 460c25e682fda7832b52d1f22d3d22b3176d972f60dcdc3212ed8c92ef85065c:amethyst
review-mode: automated
confidence: 0.92
context-layers-used: patch, modified-files, symbols, tests, imports-exports, commit-history, project-docs
context-layers-dropped:
excluded-files:

quoting
nevent1q…0y9f

Automated review finding
Severity: critical
Category: correctness
Location: quartz/src/commonMain/kotlin/com/vitorpamplona/quartz/nip05DnsIdentifiers/namecoin/AuxPow.kt:188
Evidence: if (!CompactDifficulty.hashMeetsTargetLE(parentHashLE, childBits))
Explanation: The method hashMeetsTargetLE is called in AuxPow.verify but is not defined in the provided CompactDifficulty.kt. This will cause a compilation error.
Suggestion: Implement hashMeetsTargetLE in CompactDifficulty.kt using decodeTargetBE and compareBE32.

---
model: google_gemma-4-26B-A4B-it-Q4_K_M.gguf
context-hash: 7de1b365a6695a54e1080d4b56d381c68e8daf62f623c8cc1f1b8e8bf52e7b23
patch-event-id: a3b53db06b1d86ac36ee728381539ef0544b6b61b5473b53dc4e99759893194b
repo-id: 460c25e682fda7832b52d1f22d3d22b3176d972f60dcdc3212ed8c92ef85065c:amethyst
review-mode: automated
confidence: 0.92
context-layers-used: patch, modified-files, symbols, tests, imports-exports, commit-history, project-docs
context-layers-dropped:
excluded-files:

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.

@npub1gcx…nj5z @npub15qy…yejr — a modest proposal about ...

2026-07-20T11:16:16Z

VitorPamplona (npub1gcx…nj5z) DanConwayDev (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:

quoting
nevent1q…crcf

Automated review summary
The patch introduces a robust AuxPoW verification mechanism for Namecoin SPV, including a manual Bitcoin transaction parser and merkle branch walking. However, there is a critical compilation error due to a missing method in CompactDifficulty, and a potential logic error in the CompactDifficulty.decodeTargetBE implementation regarding the mantissa placement which could lead to incorrect PoW targets.

Findings
critical | correctness | quartz/src/commonMain/kotlin/com/vitorpamplona/quartz/nip05DnsIdentifiers/namecoin/AuxPow.kt:188 | The method hashMeetsTargetLE is called in AuxPow.verify but is not defined in the provided CompactDifficulty.kt. This will cause a compilation error.
medium | correctness | quartz/src/commonMain/kotlin/com/vitorpamplona/quartz/nip05DnsIdentifiers/namecoin/CompactDifficulty.kt:53 | The logic for placing the 3-byte mantissa in the 32-byte buffer is slightly flawed. If exponent is 3, topIndex is 29. The code sets out[29], out[30], and out[31]. This is correct for a 3-byte mantissa. However, the if (topIndex in 0..29) block is used to assign out[topIndex], out[topIndex+1], and out[topIndex+2]. If topIndex is 29, it writes to 29, 30, 31. This is fine. But if exponent is 32, topIndex is 0, it writes to 0, 1, 2. This is also fine. The issue is that the target is mantissa * 256^(exponent - 3). If exponent is 3, target is mantissa * 1. The mantissa is 3 bytes. The 3 bytes should be at the very end of the 32-byte array (indices 29, 30, 31). The current code does this. However, the logic for topIndex == 30 and topIndex == 31 is redundant or potentially incorrect if the mantissa is always 3 bytes. In Bitcoin, the mantissa is 3 bytes, and the exponent is the number of bytes in the mantissa plus the exponent value. Actually, the standard is: target = mantissa * 256^(exponent - 3). If exponent is 3, target = mantissa. The mantissa is 3 bytes. So the 3 bytes should be at the end. The code handles this. But the if (topIndex in 0..29) check is a bit brittle.
low | correctness | quartz/src/commonMain/kotlin/com/vitorpamplona/quartz/nip05DnsIdentifiers/namecoin/AuxPow.kt:138 | The skipBitcoinTx function returns Int?. If it returns null (due to malformed transaction or truncation), the verify function returns Result.Malformed. This is handled correctly, but the pos is not updated in the error case, which is fine as the block is rejected.

---
model: google_gemma-4-26B-A4B-it-Q4_K_M.gguf
context-hash: 7de1b365a6695a54e1080d4b56d381c68e8daf62f623c8cc1f1b8e8bf52e7b23
patch-event-id: a3b53db06b1d86ac36ee728381539ef0544b6b61b5473b53dc4e99759893194b
repo-id: 460c25e682fda7832b52d1f22d3d22b3176d972f60dcdc3212ed8c92ef85065c:amethyst
review-mode: automated
confidence: 0.92
context-layers-used: patch, modified-files, symbols, tests, imports-exports, commit-history, project-docs
context-layers-dropped:
excluded-files:

quoting
nevent1q…0y9f

Automated review finding
Severity: critical
Category: correctness
Location: quartz/src/commonMain/kotlin/com/vitorpamplona/quartz/nip05DnsIdentifiers/namecoin/AuxPow.kt:188
Evidence: if (!CompactDifficulty.hashMeetsTargetLE(parentHashLE, childBits))
Explanation: The method hashMeetsTargetLE is called in AuxPow.verify but is not defined in the provided CompactDifficulty.kt. This will cause a compilation error.
Suggestion: Implement hashMeetsTargetLE in CompactDifficulty.kt using decodeTargetBE and compareBE32.

---
model: google_gemma-4-26B-A4B-it-Q4_K_M.gguf
context-hash: 7de1b365a6695a54e1080d4b56d381c68e8daf62f623c8cc1f1b8e8bf52e7b23
patch-event-id: a3b53db06b1d86ac36ee728381539ef0544b6b61b5473b53dc4e99759893194b
repo-id: 460c25e682fda7832b52d1f22d3d22b3176d972f60dcdc3212ed8c92ef85065c:amethyst
review-mode: automated
confidence: 0.92
context-layers-used: patch, modified-files, symbols, tests, imports-exports, commit-history, project-docs
context-layers-dropped:
excluded-files:

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.

@npub1gcx…nj5z @npub15qy…yejr — a modest proposal about ...

2026-07-20T11:15:47Z

quoting
nevent1q…crcf

Automated review summary
The patch introduces a robust AuxPoW verification mechanism for Namecoin SPV, including a manual Bitcoin transaction parser and merkle branch walking. However, there is a critical compilation error due to a missing method in CompactDifficulty, and a potential logic error in the CompactDifficulty.decodeTargetBE implementation regarding the mantissa placement which could lead to incorrect PoW targets.

Findings
critical | correctness | quartz/src/commonMain/kotlin/com/vitorpamplona/quartz/nip05DnsIdentifiers/namecoin/AuxPow.kt:188 | The method hashMeetsTargetLE is called in AuxPow.verify but is not defined in the provided CompactDifficulty.kt. This will cause a compilation error.
medium | correctness | quartz/src/commonMain/kotlin/com/vitorpamplona/quartz/nip05DnsIdentifiers/namecoin/CompactDifficulty.kt:53 | The logic for placing the 3-byte mantissa in the 32-byte buffer is slightly flawed. If exponent is 3, topIndex is 29. The code sets out[29], out[30], and out[31]. This is correct for a 3-byte mantissa. However, the if (topIndex in 0..29) block is used to assign out[topIndex], out[topIndex+1], and out[topIndex+2]. If topIndex is 29, it writes to 29, 30, 31. This is fine. But if exponent is 32, topIndex is 0, it writes to 0, 1, 2. This is also fine. The issue is that the target is mantissa * 256^(exponent - 3). If exponent is 3, target is mantissa * 1. The mantissa is 3 bytes. The 3 bytes should be at the very end of the 32-byte array (indices 29, 30, 31). The current code does this. However, the logic for topIndex == 30 and topIndex == 31 is redundant or potentially incorrect if the mantissa is always 3 bytes. In Bitcoin, the mantissa is 3 bytes, and the exponent is the number of bytes in the mantissa plus the exponent value. Actually, the standard is: target = mantissa * 256^(exponent - 3). If exponent is 3, target = mantissa. The mantissa is 3 bytes. So the 3 bytes should be at the end. The code handles this. But the if (topIndex in 0..29) check is a bit brittle.
low | correctness | quartz/src/commonMain/kotlin/com/vitorpamplona/quartz/nip05DnsIdentifiers/namecoin/AuxPow.kt:138 | The skipBitcoinTx function returns Int?. If it returns null (due to malformed transaction or truncation), the verify function returns Result.Malformed. This is handled correctly, but the pos is not updated in the error case, which is fine as the block is rejected.

---
model: google_gemma-4-26B-A4B-it-Q4_K_M.gguf
context-hash: 7de1b365a6695a54e1080d4b56d381c68e8daf62f623c8cc1f1b8e8bf52e7b23
patch-event-id: a3b53db06b1d86ac36ee728381539ef0544b6b61b5473b53dc4e99759893194b
repo-id: 460c25e682fda7832b52d1f22d3d22b3176d972f60dcdc3212ed8c92ef85065c:amethyst
review-mode: automated
confidence: 0.92
context-layers-used: patch, modified-files, symbols, tests, imports-exports, commit-history, project-docs
context-layers-dropped:
excluded-files:

quoting
nevent1q…0y9f

Automated review finding
Severity: critical
Category: correctness
Location: quartz/src/commonMain/kotlin/com/vitorpamplona/quartz/nip05DnsIdentifiers/namecoin/AuxPow.kt:188
Evidence: if (!CompactDifficulty.hashMeetsTargetLE(parentHashLE, childBits))
Explanation: The method hashMeetsTargetLE is called in AuxPow.verify but is not defined in the provided CompactDifficulty.kt. This will cause a compilation error.
Suggestion: Implement hashMeetsTargetLE in CompactDifficulty.kt using decodeTargetBE and compareBE32.

---
model: google_gemma-4-26B-A4B-it-Q4_K_M.gguf
context-hash: 7de1b365a6695a54e1080d4b56d381c68e8daf62f623c8cc1f1b8e8bf52e7b23
patch-event-id: a3b53db06b1d86ac36ee728381539ef0544b6b61b5473b53dc4e99759893194b
repo-id: 460c25e682fda7832b52d1f22d3d22b3176d972f60dcdc3212ed8c92ef85065c:amethyst
review-mode: automated
confidence: 0.92
context-layers-used: patch, modified-files, symbols, tests, imports-exports, commit-history, project-docs
context-layers-dropped:
excluded-files:

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.

@npub1gcx…nj5z @npub15qy…yejr — a modest proposal about ...

2026-07-20T11:15:24Z

quoting
nevent1q…crcf

Automated review summary
The patch introduces a robust AuxPoW verification mechanism for Namecoin SPV, including a manual Bitcoin transaction parser and merkle branch walking. However, there is a critical compilation error due to a missing method in CompactDifficulty, and a potential logic error in the CompactDifficulty.decodeTargetBE implementation regarding the mantissa placement which could lead to incorrect PoW targets.

Findings
critical | correctness | quartz/src/commonMain/kotlin/com/vitorpamplona/quartz/nip05DnsIdentifiers/namecoin/AuxPow.kt:188 | The method hashMeetsTargetLE is called in AuxPow.verify but is not defined in the provided CompactDifficulty.kt. This will cause a compilation error.
medium | correctness | quartz/src/commonMain/kotlin/com/vitorpamplona/quartz/nip05DnsIdentifiers/namecoin/CompactDifficulty.kt:53 | The logic for placing the 3-byte mantissa in the 32-byte buffer is slightly flawed. If exponent is 3, topIndex is 29. The code sets out[29], out[30], and out[31]. This is correct for a 3-byte mantissa. However, the if (topIndex in 0..29) block is used to assign out[topIndex], out[topIndex+1], and out[topIndex+2]. If topIndex is 29, it writes to 29, 30, 31. This is fine. But if exponent is 32, topIndex is 0, it writes to 0, 1, 2. This is also fine. The issue is that the target is mantissa * 256^(exponent - 3). If exponent is 3, target is mantissa * 1. The mantissa is 3 bytes. The 3 bytes should be at the very end of the 32-byte array (indices 29, 30, 31). The current code does this. However, the logic for topIndex == 30 and topIndex == 31 is redundant or potentially incorrect if the mantissa is always 3 bytes. In Bitcoin, the mantissa is 3 bytes, and the exponent is the number of bytes in the mantissa plus the exponent value. Actually, the standard is: target = mantissa * 256^(exponent - 3). If exponent is 3, target = mantissa. The mantissa is 3 bytes. So the 3 bytes should be at the end. The code handles this. But the if (topIndex in 0..29) check is a bit brittle.
low | correctness | quartz/src/commonMain/kotlin/com/vitorpamplona/quartz/nip05DnsIdentifiers/namecoin/AuxPow.kt:138 | The skipBitcoinTx function returns Int?. If it returns null (due to malformed transaction or truncation), the verify function returns Result.Malformed. This is handled correctly, but the pos is not updated in the error case, which is fine as the block is rejected.

---
model: google_gemma-4-26B-A4B-it-Q4_K_M.gguf
context-hash: 7de1b365a6695a54e1080d4b56d381c68e8daf62f623c8cc1f1b8e8bf52e7b23
patch-event-id: a3b53db06b1d86ac36ee728381539ef0544b6b61b5473b53dc4e99759893194b
repo-id: 460c25e682fda7832b52d1f22d3d22b3176d972f60dcdc3212ed8c92ef85065c:amethyst
review-mode: automated
confidence: 0.92
context-layers-used: patch, modified-files, symbols, tests, imports-exports, commit-history, project-docs
context-layers-dropped:
excluded-files:

quoting
nevent1q…0y9f

Automated review finding
Severity: critical
Category: correctness
Location: quartz/src/commonMain/kotlin/com/vitorpamplona/quartz/nip05DnsIdentifiers/namecoin/AuxPow.kt:188
Evidence: if (!CompactDifficulty.hashMeetsTargetLE(parentHashLE, childBits))
Explanation: The method hashMeetsTargetLE is called in AuxPow.verify but is not defined in the provided CompactDifficulty.kt. This will cause a compilation error.
Suggestion: Implement hashMeetsTargetLE in CompactDifficulty.kt using decodeTargetBE and compareBE32.

---
model: google_gemma-4-26B-A4B-it-Q4_K_M.gguf
context-hash: 7de1b365a6695a54e1080d4b56d381c68e8daf62f623c8cc1f1b8e8bf52e7b23
patch-event-id: a3b53db06b1d86ac36ee728381539ef0544b6b61b5473b53dc4e99759893194b
repo-id: 460c25e682fda7832b52d1f22d3d22b3176d972f60dcdc3212ed8c92ef85065c:amethyst
review-mode: automated
confidence: 0.92
context-layers-used: patch, modified-files, symbols, tests, imports-exports, commit-history, project-docs
context-layers-dropped:
excluded-files:

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.

@npub15qy…yejr do you know anything about this bot? ...

2026-07-19T03:57:15Z

DanConwayDev (npub15qy…yejr) do you know anything about this bot? Drydock (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).

4× kind:30817 events on damus.io + primal.net + ditto.pub. ...

2026-06-28T21:45:21Z

In reply to nevent1q…y92u
_________________________

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: VitorPamplona (npub1gcx…nj5z)

## Local CI-parity run vs current upstream main Verified this PR ...

2026-06-26T00:44:52Z

In reply to nevent1q…wc8h
_________________________

## 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.**

## Local CI-parity run vs current upstream main Verified this PR ...

2026-06-26T00:43:58Z

## Local CI-parity run vs current upstream main Verified this PR ...

2026-06-26T00:42:19Z

Nostr event nevent1qqs96unl0u49dcp5mclk32qevrh048gujljze9yyc7j2ju0exl62glgzypp3shk7edn43y5zfvdr0ftl8eq8l00zaknjqx3c9xuv7ja8ck60q6evly5

2026-05-11T07:39:37Z

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

📡 How to use relay.testls.bit — a Namecoin .bit-gated Nostr ...

2026-05-01T02:27:11Z

📡 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

📡 How to use relay.testls.bit — a Namecoin .bit-gated Nostr ...

2026-05-01T02:26:35Z

A free-software Namecoin explorer is now live for nostriches to ...

2026-05-01T01:43:18Z

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

A free-software Namecoin explorer is now live for nostriches to ...

2026-05-01T01:41:40Z

A free-software Namecoin explorer is now live for nostriches to ...

2026-05-01T01:41:04Z

A free-software Namecoin explorer is now live for nostriches to ...

2026-05-01T01:39:08Z

📡 How to use relay.testls.bit — a Namecoin .bit-gated Nostr ...

2026-04-28T21:31:00Z

📡 How to use relay.testls.bit — a Namecoin .bit-gated Nostr ...

2026-04-28T21:18:43Z

📡 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

Nostr event nevent1qqsrr5rs0gh8vql0u9uagvzmv2v5se43xav7gzd733r643yd0g0ntdgzypp3shk7edn43y5zfvdr0ftl8eq8l00zaknjqx3c9xuv7ja8ck60qz3k2yw

2026-04-28T07:45:18Z

hello gated .bit world from Amethyst round2

Nostr event nevent1qqsz3lk6vf4vcjfgzvw3eqgt5vd5c5hu7fn567wp36xxmla67hk533czypp3shk7edn43y5zfvdr0ftl8eq8l00zaknjqx3c9xuv7ja8ck60qgn0n9u

2026-04-28T07:42:52Z

hello gated .bit world from _@mstrofnone.bit

Nostr event nevent1qqs0eqa96hvwgkqat98snjx2wtua8ym65mhdw8zxsuw2pq42kl0kc0gzypp3shk7edn43y5zfvdr0ftl8eq8l00zaknjqx3c9xuv7ja8ck60q5wk2cw

2026-04-28T07:35:12Z

hello gated .bit world

follow-up patch adds WebSocket (WSS) transport — enables ...

2026-04-19T12:00:28Z

In reply to nevent1q…9x66
_________________________

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.

quoting nevent1q…lk5q
From d307275490adbc6b012399e2d5200c4b963a4ba6 Mon Sep 17 00:00:00 2001
From: M
Date: Sun, 19 Apr 2026 21:57:33 +1000
Subject: [PATCH] feat(nip05/namecoin): add WebSocket (WSS) transport

Adds WS/WSS as an alternative transport to TCP+TLS for ElectrumX
name resolution. Enables browser/wasm use of nip05/namecoin and
improves resilience on networks where raw TCP is blocked.

New: Transport enum on ElectrumxServer, DefaultElectrumXServersWSS,
WebSocket client via github.com/coder/websocket (zero transitive
deps, already a transitive dep of nostrlib). Pinned-cert TLS trust
is shared between TCP+TLS and WSS \u2014 the public operators serve the
same certificate on the adjacent ports (:50002 / :50004 on testls,
:57002 / :57004 on nmc2.bitcoins.sk).

Zero API break: the new Transport field on ElectrumxServer is a
zero-valued enum that preserves the v1 UseSSL semantics. Every
call site from the previous patch compiles and behaves unchanged.

Tests: new unit test stands up an httptest WebSocket server via
coder/websocket's accept helper and exercises the whole dial \u2192
read \u2192 parse flow over WS framing, offline. Integration tests
(build tag integration) add two WSS cases against the live public
servers on :50004, mirroring the existing TCP test fixtures.

Follow-up to the patch event at
nevent1q…8pyq
(original subpackage). Rebase-clean on top of it.

Signed-off-by: M
---
nip05/namecoin/doc.go | 8 +-
nip05/namecoin/electrumx.go | 139 +++++++++----
nip05/namecoin/electrumx_integration_test.go | 50 +++++
nip05/namecoin/servers.go | 70 +++++++
nip05/namecoin/websocket.go | 105 ++++++++++
nip05/namecoin/websocket_test.go | 195 +++++++++++++++++++
6 files changed, 524 insertions(+), 43 deletions(-)
create mode 100644 nip05/namecoin/websocket.go
create mode 100644 nip05/namecoin/websocket_test.go

diff --git a/nip05/namecoin/doc.go b/nip05/namecoin/doc.go
index 7189a38..82bbce2 100644
--- a/nip05/namecoin/doc.go
+++ b/nip05/namecoin/doc.go
@@ -28,6 +28,10 @@
// // ...
// }
//
-// No external dependencies beyond the Go standard library and the
-// fiatjaf.com/nostr types.
+// Two transports are supported: raw TCP+TLS (the default, selected
+// by the zero value of ElectrumxServer.Transport) and WebSocket over
+// TLS (TransportWSS). The WSS path uses github.com/coder/websocket —
+// a zero-transitive-dep library that also compiles cleanly under
+// GOOS=js GOARCH=wasm, enabling browser use. Pinned-cert trust is
+// shared between the two transports.
package namecoin
diff --git a/nip05/namecoin/electrumx.go b/nip05/namecoin/electrumx.go
index 4fbabdb..b7757d5 100644
--- a/nip05/namecoin/electrumx.go
+++ b/nip05/namecoin/electrumx.go
@@ -42,9 +42,24 @@ var (
ErrServersUnreachable = errors.New("namecoin: all ElectrumX servers unreachable")
)

+// rpcConn is the transport-agnostic RPC connection abstraction. Both
+// TCP (newline-delimited) and WebSocket (pre-framed) implementations
+// satisfy it so that the name_show flow can be written once.
+type rpcConn interface {
+ // writeRequest serialises and sends a single JSON-RPC request.
+ // Implementations are responsible for any framing the wire format
+ // requires (TCP appends a newline, WS does not).
+ writeRequest(ctx context.Context, method string, params []any, id int64) error
+ // readResponse returns one JSON-RPC response, blocking until one
+ // is available or the context/deadline fires.
+ readResponse(ctx context.Context) (string, error)
+ // close releases the underlying transport.
+ close() error
+}
+
// ElectrumClient is a minimal, query-only Namecoin ElectrumX client.
-// It opens a short-lived TCP/TLS socket per request, which is plenty
-// for interactive CLI use.
+// It opens a short-lived socket per request, which is plenty for
+// interactive CLI use.
type ElectrumClient struct {
ConnectTimeout time.Duration
ReadTimeout time.Duration
@@ -68,18 +83,22 @@ func (c *ElectrumClient) NameShow(ctx context.Context, identifier string, server
if err != nil {
return nil, err
}
- defer conn.Close()
+ defer conn.close()

- _ = conn.SetDeadline(time.Now().Add(c.ReadTimeout))
+ // Give the whole request sequence a deadline. For TCP this is
+ // enforced by net.Conn.SetDeadline; for WS the per-call context
+ // carries the budget instead.
+ reqCtx, cancel := context.WithTimeout(ctx, c.ReadTimeout)
+ defer cancel()

- reader := bufio.NewReader(conn)
+ next := func() int64 { return c.requestID.Add(1) }

// 1. Negotiate protocol version. The response is consumed and
// discarded — we only care that the socket is alive.
- if err := c.sendRPC(conn, "server.version", []any{"nak-namecoin/0.1", electrumProtocolVersion}); err != nil {
+ if err := conn.writeRequest(reqCtx, "server.version", []any{"nak-namecoin/0.1", electrumProtocolVersion}, next()); err != nil {
return nil, err
}
- if _, err := reader.ReadString('\n'); err != nil {
+ if _, err := conn.readResponse(reqCtx); err != nil {
return nil, fmt.Errorf("namecoin: read version response: %w", err)
}

@@ -88,10 +107,10 @@ func (c *ElectrumClient) NameShow(ctx context.Context, identifier string, server
scriptHash := electrumScriptHash(script)

// 3. Fetch transaction history for that scripthash.
- if err := c.sendRPC(conn, "blockchain.scripthash.get_history", []any{scriptHash}); err != nil {
+ if err := conn.writeRequest(reqCtx, "blockchain.scripthash.get_history", []any{scriptHash}, next()); err != nil {
return nil, err
}
- histLine, err := reader.ReadString('\n')
+ histLine, err := conn.readResponse(reqCtx)
if err != nil {
return nil, fmt.Errorf("namecoin: read history response: %w", err)
}
@@ -108,19 +127,19 @@ func (c *ElectrumClient) NameShow(ctx context.Context, identifier string, server
latest := entries[len(entries)-1]

// 4. Fetch the verbose transaction.
- if err := c.sendRPC(conn, "blockchain.transaction.get", []any{latest.TxHash, true}); err != nil {
+ if err := conn.writeRequest(reqCtx, "blockchain.transaction.get", []any{latest.TxHash, true}, next()); err != nil {
return nil, err
}
- txLine, err := reader.ReadString('\n')
+ txLine, err := conn.readResponse(reqCtx)
if err != nil {
return nil, fmt.Errorf("namecoin: read transaction response: %w", err)
}

// 5. Get the current block height so we can compute expiry.
- if err := c.sendRPC(conn, "blockchain.headers.subscribe", []any{}); err != nil {
+ if err := conn.writeRequest(reqCtx, "blockchain.headers.subscribe", []any{}, next()); err != nil {
return nil, err
}
- headerLine, _ := reader.ReadString('\n')
+ headerLine, _ := conn.readResponse(reqCtx)
currentHeight := parseBlockHeight(headerLine)

if currentHeight > 0 && latest.Height > 0 {
@@ -161,10 +180,23 @@ func (c *ElectrumClient) NameShowWithFallback(ctx context.Context, identifier st
return nil, fmt.Errorf("%w: last error: %v", ErrServersUnreachable, lastErr)
}

-// dial opens a TCP connection to the server, upgrading to TLS when
-// UseSSL is set. Honours both context cancellation and our connect
-// timeout, whichever fires first.
-func (c *ElectrumClient) dial(ctx context.Context, server ElectrumxServer) (net.Conn, error) {
+// dial picks the right transport implementation based on the server
+// configuration and returns a ready-to-use rpcConn.
+func (c *ElectrumClient) dial(ctx context.Context, server ElectrumxServer) (rpcConn, error) {
+ switch effectiveTransport(server) {
+ case TransportTCPTLS, TransportTCP:
+ return c.dialTCP(ctx, server)
+ case TransportWSS, TransportWS:
+ return c.dialWebSocket(ctx, server)
+ default:
+ return nil, fmt.Errorf("namecoin: unknown transport %d", server.Transport)
+ }
+}
+
+// dialTCP opens a raw TCP connection to the server, upgrading to TLS
+// when the effective transport is TCPTLS. Honours both context
+// cancellation and our connect timeout, whichever fires first.
+func (c *ElectrumClient) dialTCP(ctx context.Context, server ElectrumxServer) (rpcConn, error) {
dialer := &net.Dialer{Timeout: c.ConnectTimeout}
address := net.JoinHostPort(server.Host, strconv.Itoa(server.Port))

@@ -173,34 +205,41 @@ func (c *ElectrumClient) dial(ctx context.Context, server ElectrumxServer) (net.
return nil, fmt.Errorf("namecoin: dial %s: %w", address, err)
}

- if !server.UseSSL {
- return raw, nil
+ var nc net.Conn = raw
+ if effectiveTransport(server) == TransportTCPTLS {
+ cfg := tlsConfigFor(server)
+ tlsConn := tls.Client(raw, cfg)
+
+ // Run the handshake with a deadline so a silent server doesn't hang
+ // the call beyond what the caller asked for.
+ if deadline, ok := ctx.Deadline(); ok {
+ _ = tlsConn.SetDeadline(deadline)
+ } else {
+ _ = tlsConn.SetDeadline(time.Now().Add(c.ConnectTimeout))
+ }
+ if err := tlsConn.HandshakeContext(ctx); err != nil {
+ raw.Close()
+ return nil, fmt.Errorf("namecoin: TLS handshake with %s: %w", address, err)
+ }
+ // Clear the handshake deadline — we'll set fresh per-request
+ // deadlines below.
+ _ = tlsConn.SetDeadline(time.Time{})
+ nc = tlsConn
}

- cfg := tlsConfigFor(server)
- tlsConn := tls.Client(raw, cfg)
+ _ = nc.SetDeadline(time.Now().Add(c.ReadTimeout))
+ return &tcpRPCConn{conn: nc, reader: bufio.NewReader(nc)}, nil
+}

- // Run the handshake with a deadline so a silent server doesn't hang
- // the call beyond what the caller asked for.
- if deadline, ok := ctx.Deadline(); ok {
- _ = tlsConn.SetDeadline(deadline)
- } else {
- _ = tlsConn.SetDeadline(time.Now().Add(c.ConnectTimeout))
- }
- if err := tlsConn.HandshakeContext(ctx); err != nil {
- raw.Close()
- return nil, fmt.Errorf("namecoin: TLS handshake with %s: %w", address, err)
- }
- // Clear the handshake deadline — the caller sets its own read
- // deadline afterwards.
- _ = tlsConn.SetDeadline(time.Time{})
- return tlsConn, nil
+// tcpRPCConn is the newline-delimited JSON-RPC transport over raw
+// TCP or TCP+TLS. This matches the shape every Electrum / ElectrumX
+// client has used for the last decade.
+type tcpRPCConn struct {
+ conn net.Conn
+ reader *bufio.Reader
}

-// sendRPC writes a JSON-RPC 2.0 request (newline-terminated, per
-// Electrum's line-delimited protocol) to the connection.
-func (c *ElectrumClient) sendRPC(w net.Conn, method string, params []any) error {
- id := c.requestID.Add(1)
+func (t *tcpRPCConn) writeRequest(ctx context.Context, method string, params []any, id int64) error {
payload := map[string]any{
"jsonrpc": "2.0",
"id": id,
@@ -212,12 +251,30 @@ func (c *ElectrumClient) sendRPC(w net.Conn, method string, params []any) error
return fmt.Errorf("namecoin: marshal rpc request: %w", err)
}
encoded = append(encoded, '\n')
- if _, err := w.Write(encoded); err != nil {
+ if deadline, ok := ctx.Deadline(); ok {
+ _ = t.conn.SetWriteDeadline(deadline)
+ }
+ if _, err := t.conn.Write(encoded); err != nil {
return fmt.Errorf("namecoin: write rpc request: %w", err)
}
return nil
}

+func (t *tcpRPCConn) readResponse(ctx context.Context) (string, error) {
+ if deadline, ok := ctx.Deadline(); ok {
+ _ = t.conn.SetReadDeadline(deadline)
+ }
+ line, err := t.reader.ReadString('\n')
+ if err != nil {
+ return "", err
+ }
+ return line, nil
+}
+
+func (t *tcpRPCConn) close() error {
+ return t.conn.Close()
+}
+
// historyEntry is one row of `blockchain.scripthash.get_history`.
type historyEntry struct {
TxHash string
diff --git a/nip05/namecoin/electrumx_integration_test.go b/nip05/namecoin/electrumx_integration_test.go
index 1458d4d..64ac17c 100644
--- a/nip05/namecoin/electrumx_integration_test.go
+++ b/nip05/namecoin/electrumx_integration_test.go
@@ -49,3 +49,53 @@ func TestIntegration_ResolveAtTestlsBit(t *testing.T) {
t.Errorf("m@testls.bit pubkey = %s, want %s", got, testlsMPubkey)
}
}
+
+// --- WSS (WebSocket over TLS) integration tests -----------------------
+//
+// These hit the same ElectrumX operators as the TCP tests above, but
+// over the WebSocket endpoints (ports 500xx+2 on testls, 570xx+2 on
+// nmc2.bitcoins.sk). Same pinned certs, same JSON-RPC protocol, just
+// different framing. The assertions match the TCP path because the
+// Namecoin blockchain is the source of truth.
+
+func TestIntegration_ResolveTestlsBit_WSS(t *testing.T) {
+ ctx, cancel := context.WithTimeout(context.Background(), 30*time.Second)
+ defer cancel()
+
+ client := NewElectrumClient()
+ result, err := client.NameShowWithFallback(ctx, "d/testls", DefaultElectrumXServersWSS)
+ if err != nil {
+ t.Fatalf("NameShowWithFallback(d/testls, WSS): %v", err)
+ }
+ if result == nil {
+ t.Fatal("nil result")
+ }
+ pk, _, err := extractNostrFromValue(result.Value, &parsedIdentifier{"d/testls", "_", true})
+ if err != nil {
+ t.Fatalf("extractNostrFromValue: %v", err)
+ }
+ if pk != testlsRootPubkey {
+ t.Errorf("testls.bit (WSS) pubkey = %s, want %s", pk, testlsRootPubkey)
+ }
+}
+
+func TestIntegration_ResolveAtTestlsBit_WSS(t *testing.T) {
+ ctx, cancel := context.WithTimeout(context.Background(), 30*time.Second)
+ defer cancel()
+
+ client := NewElectrumClient()
+ result, err := client.NameShowWithFallback(ctx, "d/testls", DefaultElectrumXServersWSS)
+ if err != nil {
+ t.Fatalf("NameShowWithFallback(d/testls, WSS): %v", err)
+ }
+ if result == nil {
+ t.Fatal("nil result")
+ }
+ pk, _, err := extractNostrFromValue(result.Value, &parsedIdentifier{"d/testls", "m", true})
+ if err != nil {
+ t.Fatalf("extractNostrFromValue: %v", err)
+ }
+ if pk != testlsMPubkey {
+ t.Errorf("m@testls.bit (WSS) pubkey = %s, want %s", pk, testlsMPubkey)
+ }
+}
diff --git a/nip05/namecoin/servers.go b/nip05/namecoin/servers.go
index b76c889..71c8551 100644
--- a/nip05/namecoin/servers.go
+++ b/nip05/namecoin/servers.go
@@ -1,15 +1,59 @@
package namecoin

+// Transport selects how an ElectrumX server is dialed. The zero value
+// is TransportTCPTLS, matching the traditional Electrum client path
+// and the behaviour shipped in v0.1.x. Callers that want WebSocket
+// (for example, browser/wasm targets or restricted networks that
+// block raw TCP) set this to TransportWSS.
+type Transport int
+
+const (
+ // TransportTCPTLS is raw TCP + TLS with newline-delimited JSON-RPC.
+ // This is the default and what most Namecoin ElectrumX clients use.
+ TransportTCPTLS Transport = iota
+ // TransportTCP is plaintext TCP — rarely used in practice but
+ // supported for completeness / local testing.
+ TransportTCP
+ // TransportWSS is WebSocket over TLS, using the ElectrumX WS
+ // endpoint (ports 500xx+2 on typical public servers). Messages
+ // are pre-framed by the WebSocket layer and MUST NOT carry a
+ // trailing newline.
+ TransportWSS
+ // TransportWS is plaintext WebSocket.
+ TransportWS
+)
+
// ElectrumxServer is a single Namecoin ElectrumX endpoint.
type ElectrumxServer struct {
Host string
Port int
// UseSSL indicates TLS should be negotiated over the raw socket.
+ // Kept for backwards compat with v0.1.x callers. When Transport
+ // is the zero value, UseSSL selects between TransportTCPTLS
+ // (UseSSL=true) and TransportTCP (UseSSL=false).
UseSSL bool
// UsePinnedTrustStore enables the pinned-cert trust anchor bundle
// for servers that present self-signed certificates. This is the
// norm for the public Namecoin ElectrumX ecosystem.
UsePinnedTrustStore bool
+ // Transport selects the dial transport. Zero value keeps v0.1.x
+ // semantics: if UseSSL is true it's TCP+TLS, otherwise plain TCP.
+ // Set explicitly to TransportWSS / TransportWS for WebSocket.
+ Transport Transport
+}
+
+// effectiveTransport resolves the transport to use for a server,
+// reconciling the legacy UseSSL bool with the explicit Transport
+// field. The explicit Transport wins when non-zero.
+func effectiveTransport(s ElectrumxServer) Transport {
+ if s.Transport != TransportTCPTLS {
+ return s.Transport
+ }
+ // Zero value: fall back to UseSSL for v0.1.x compatibility.
+ if s.UseSSL {
+ return TransportTCPTLS
+ }
+ return TransportTCP
}

// DefaultElectrumXServers is the built-in list of public Namecoin
@@ -24,11 +68,37 @@ var DefaultElectrumXServers = []ElectrumxServer{
{Host: "46.229.238.187", Port: 57002, UseSSL: true, UsePinnedTrustStore: true},
}

+// DefaultElectrumXServersWSS is the WSS-preferred server list. It
+// points at the same operators as DefaultElectrumXServers but uses
+// their WebSocket-over-TLS endpoints. Useful for:
+//
+// - Browser / wasm targets, where raw TCP is unavailable and the
+// only viable transport is the browser's WebSocket API (which
+// `github.com/coder/websocket` targets natively when compiled
+// with GOOS=js GOARCH=wasm).
+// - Restricted networks that block the traditional ElectrumX ports
+// but allow outbound HTTPS/WSS.
+// - Environments that prefer WSS on policy grounds (aligns with the
+// broader Nostr ecosystem, which is WSS-everywhere).
+//
+// Ports are the ElectrumX convention of ELECTRUM_PORT+2 for the WSS
+// endpoint. Both listed operators expose these alongside their
+// TCP+TLS ports, sharing the same TLS certificate.
+var DefaultElectrumXServersWSS = []ElectrumxServer{
+ {Host: "electrumx.testls.space", Port: 50004, Transport: TransportWSS, UsePinnedTrustStore: true},
+ {Host: "nmc2.bitcoins.sk", Port: 57004, Transport: TransportWSS, UsePinnedTrustStore: true},
+ {Host: "46.229.238.187", Port: 57004, Transport: TransportWSS, UsePinnedTrustStore: true},
+}
+
// PinnedElectrumXCerts is the PEM-encoded bundle of server
// certificates we trust in addition to the system roots. These are
// copied verbatim from the Kotlin Amethyst reference implementation.
//
// To refresh: `echo | openssl s_client -connect HOST:PORT 2>/dev/null | openssl x509 -outform PEM`
+//
+// The same certificates are served on the WSS endpoints (adjacent
+// ports on the same host), so a single pinned bundle covers both
+// transports.
var PinnedElectrumXCerts = []string{
// electrumx.testls.space:50002 — expires 2027-05-04.
// Also covers the i665jpwsq46zlsdbnj4axgzd3s56uzey5uhotsnxzsknzbn36jaddsid.onion:50002
diff --git a/nip05/namecoin/websocket.go b/nip05/namecoin/websocket.go
new file mode 100644
index 0000000..5e849d7
--- /dev/null
+++ b/nip05/namecoin/websocket.go
@@ -0,0 +1,105 @@
+package namecoin
+
+import (
+ "context"
+ "encoding/json"
+ "fmt"
+ "net"
+ "net/http"
+ "strconv"
+
+ "github.com/coder/websocket"
+)
+
+// wsReadLimit is the maximum size of a single WebSocket message we are
+// willing to accept from an ElectrumX server. Verbose transactions
+// from `blockchain.transaction.get` can legitimately run to tens of
+// kilobytes; 1 MiB is generous but keeps us safely bounded.
+const wsReadLimit int64 = 1 << 20
+
+// dialWebSocket opens a WebSocket (plain or TLS) RPC connection to
+// the given ElectrumX server. It reuses the same pinned-cert TLS
+// config as the TCP+TLS transport so operators who serve a single
+// self-signed certificate across both ports are handled identically.
+func (c *ElectrumClient) dialWebSocket(ctx context.Context, server ElectrumxServer) (rpcConn, error) {
+ transport := effectiveTransport(server)
+ scheme := "ws"
+ if transport == TransportWSS {
+ scheme = "wss"
+ }
+ address := net.JoinHostPort(server.Host, strconv.Itoa(server.Port))
+ url := scheme + "://" + address
+
+ // Bound the dial to our connect timeout, in addition to honouring
+ // any deadline on the caller's context.
+ dialCtx, cancel := context.WithTimeout(ctx, c.ConnectTimeout)
+ defer cancel()
+
+ opts := &websocket.DialOptions{}
+ if transport == TransportWSS {
+ // Build an http.Transport that carries the same *tls.Config
+ // the TCP+TLS path uses. The custom VerifyPeerCertificate is
+ // transport-agnostic, so pinned-cert trust continues to work
+ // over WebSocket's HTTP upgrade handshake.
+ tlsCfg := tlsConfigFor(server)
+ opts.HTTPClient = &http.Client{
+ Timeout: c.ConnectTimeout + c.ReadTimeout,
+ Transport: &http.Transport{
+ TLSClientConfig: tlsCfg,
+ TLSHandshakeTimeout: c.ConnectTimeout,
+ },
+ }
+ }
+
+ conn, _, err := websocket.Dial(dialCtx, url, opts)
+ if err != nil {
+ return nil, fmt.Errorf("namecoin: websocket dial %s: %w", url, err)
+ }
+ conn.SetReadLimit(wsReadLimit)
+
+ return &wsRPCConn{conn: conn}, nil
+}
+
+// wsRPCConn is the WebSocket JSON-RPC transport. Unlike the TCP
+// variant, WebSocket messages are pre-framed by the protocol layer,
+// so requests MUST NOT carry a trailing newline and responses arrive
+// as whole JSON messages per frame.
+type wsRPCConn struct {
+ conn *websocket.Conn
+}
+
+func (w *wsRPCConn) writeRequest(ctx context.Context, method string, params []any, id int64) error {
+ payload := map[string]any{
+ "jsonrpc": "2.0",
+ "id": id,
+ "method": method,
+ "params": params,
+ }
+ encoded, err := json.Marshal(payload)
+ if err != nil {
+ return fmt.Errorf("namecoin: marshal rpc request: %w", err)
+ }
+ if err := w.conn.Write(ctx, websocket.MessageText, encoded); err != nil {
+ return fmt.Errorf("namecoin: write rpc request: %w", err)
+ }
+ return nil
+}
+
+func (w *wsRPCConn) readResponse(ctx context.Context) (string, error) {
+ _, data, err := w.conn.Read(ctx)
+ if err != nil {
+ return "", err
+ }
+ return string(data), nil
+}
+
+func (w *wsRPCConn) close() error {
+ return w.conn.Close(websocket.StatusNormalClosure, "")
+}
+
+// Compile-time interface checks — catch drift early if the rpcConn
+// signature ever evolves.
+var (
+ _ rpcConn = (*tcpRPCConn)(nil)
+ _ rpcConn = (*wsRPCConn)(nil)
+)
diff --git a/nip05/namecoin/websocket_test.go b/nip05/namecoin/websocket_test.go
new file mode 100644
index 0000000..ad5682a
--- /dev/null
+++ b/nip05/namecoin/websocket_test.go
@@ -0,0 +1,195 @@
+package namecoin
+
+import (
+ "context"
+ "encoding/json"
+ "net/http"
+ "net/http/httptest"
+ "net/url"
+ "strconv"
+ "strings"
+ "testing"
+ "time"
+
+ "github.com/coder/websocket"
+)
+
+// fakeElectrumXWSHandler returns an http.Handler that upgrades incoming
+// connections to WebSocket and serves canned JSON-RPC responses for the
+// sequence the ElectrumClient issues during NameShow.
+//
+// The response ordering mirrors the real RPC sequence:
+// 1. server.version → any non-error result
+// 2. blockchain.scripthash.get_history → one entry pointing at a fake txid
+// 3. blockchain.transaction.get → one vout with a NAME_UPDATE that
+// matches the requested name and a
+// value whose "nostr" field is a
+// known hex pubkey
+// 4. blockchain.headers.subscribe → a height far enough below our
+// fake tx height that the name is
+// well within its expiry window
+//
+// This exercises the whole WS dial → read → parse path end-to-end
+// without hitting the network.
+func fakeElectrumXWSHandler(t *testing.T, identifier, pubkeyHex string) http.Handler {
+ // Build the NAME_UPDATE script hex we want the client to parse
+ // back out of the "transaction".
+ value := `{"nostr":"` + pubkeyHex + `"}`
+ script := []byte{opNameUpdate}
+ script = append(script, pushData([]byte(identifier))...)
+ script = append(script, pushData([]byte(value))...)
+ script = append(script, op2Drop, opDrop)
+ // Stub P2PKH-ish tail so the parser's "we don't care what follows
+ // the DROPs" assumption holds.
+ script = append(script, 0x76, 0xa9, 0x14)
+ scriptHex := hexString(script)
+
+ return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
+ conn, err := websocket.Accept(w, r, nil)
+ if err != nil {
+ t.Logf("ws accept: %v", err)
+ return
+ }
+ defer conn.Close(websocket.StatusInternalError, "test server shutting down")
+
+ ctx := r.Context()
+
+ respond := func(id any, result any) {
+ payload := map[string]any{
+ "jsonrpc": "2.0",
+ "id": id,
+ "result": result,
+ }
+ raw, _ := json.Marshal(payload)
+ if err := conn.Write(ctx, websocket.MessageText, raw); err != nil {
+ t.Logf("ws write: %v", err)
+ }
+ }
+
+ for {
+ _, data, err := conn.Read(ctx)
+ if err != nil {
+ return
+ }
+ var req struct {
+ ID any `json:"id"`
+ Method string `json:"method"`
+ }
+ if err := json.Unmarshal(data, &req); err != nil {
+ t.Logf("ws request parse: %v", err)
+ return
+ }
+ switch req.Method {
+ case "server.version":
+ respond(req.ID, []string{"ElectrumX 1.16.0", electrumProtocolVersion})
+ case "blockchain.scripthash.get_history":
+ respond(req.ID, []map[string]any{
+ {"tx_hash": "deadbeefcafebabe", "height": 600000},
+ })
+ case "blockchain.transaction.get":
+ respond(req.ID, map[string]any{
+ "txid": "deadbeefcafebabe",
+ "vout": []map[string]any{
+ {"scriptPubKey": map[string]any{"hex": scriptHex}},
+ },
+ })
+ case "blockchain.headers.subscribe":
+ respond(req.ID, map[string]any{"height": 600010})
+ default:
+ respond(req.ID, nil)
+ }
+ }
+ })
+}
+
+func hexString(b []byte) string {
+ const hexDigits = "0123456789abcdef"
+ out := make([]byte, 0, len(b)*2)
+ for _, v := range b {
+ out = append(out, hexDigits[v>>4], hexDigits[v&0x0f])
+ }
+ return string(out)
+}
+
+func TestWebSocketTransport_NameShow(t *testing.T) {
+ identifier := "d/wsfake"
+ pubkey := "aaaa000000000000000000000000000000000000000000000000000000000001"
+
+ ts := httptest.NewServer(fakeElectrumXWSHandler(t, identifier, pubkey))
+ defer ts.Close()
+
+ // Parse the httptest URL so we can point the client at it as
+ // host+port with the plain-WS transport. httptest.Server is HTTP,
+ // so TransportWS (not WSS) is what we want here — it verifies the
+ // framing/routing independently of the TLS plumbing.
+ u, err := url.Parse(ts.URL)
+ if err != nil {
+ t.Fatal(err)
+ }
+ port, err := strconv.Atoi(u.Port())
+ if err != nil {
+ t.Fatal(err)
+ }
+
+ srv := ElectrumxServer{
+ Host: u.Hostname(),
+ Port: port,
+ Transport: TransportWS,
+ }
+
+ client := NewElectrumClient()
+ client.ConnectTimeout = 3 * time.Second
+ client.ReadTimeout = 5 * time.Second
+
+ ctx, cancel := context.WithTimeout(context.Background(), 10*time.Second)
+ defer cancel()
+
+ result, err := client.NameShow(ctx, identifier, srv)
+ if err != nil {
+ t.Fatalf("NameShow over WS: %v", err)
+ }
+ if result == nil {
+ t.Fatal("NameShow returned nil result")
+ }
+ if result.Name != identifier {
+ t.Errorf("name = %q, want %q", result.Name, identifier)
+ }
+ if !strings.Contains(result.Value, pubkey) {
+ t.Errorf("value = %q, want to contain %q", result.Value, pubkey)
+ }
+}
+
+func TestEffectiveTransport(t *testing.T) {
+ cases := []struct {
+ in ElectrumxServer
+ want Transport
+ }{
+ // v0.1.x shape: UseSSL=true, Transport unset → TCPTLS.
+ {ElectrumxServer{UseSSL: true}, TransportTCPTLS},
+ // v0.1.x shape: UseSSL=false, Transport unset → plain TCP.
+ {ElectrumxServer{UseSSL: false}, TransportTCP},
+ // Explicit Transport wins over UseSSL when non-zero.
+ {ElectrumxServer{UseSSL: true, Transport: TransportWSS}, TransportWSS},
+ {ElectrumxServer{UseSSL: false, Transport: TransportWS}, TransportWS},
+ {ElectrumxServer{UseSSL: false, Transport: TransportTCPTLS}, TransportTCP}, // TCPTLS is zero value; falls back to UseSSL
+ }
+ for i, tc := range cases {
+ if got := effectiveTransport(tc.in); got != tc.want {
+ t.Errorf("case %d: effectiveTransport(%+v) = %d, want %d", i, tc.in, got, tc.want)
+ }
+ }
+}
+
+func TestDefaultElectrumXServersWSS(t *testing.T) {
+ if len(DefaultElectrumXServersWSS) == 0 {
+ t.Fatal("DefaultElectrumXServersWSS is empty")
+ }
+ for _, srv := range DefaultElectrumXServersWSS {
+ if srv.Transport != TransportWSS {
+ t.Errorf("%s:%d has Transport=%d, want WSS", srv.Host, srv.Port, srv.Transport)
+ }
+ if !srv.UsePinnedTrustStore {
+ t.Errorf("%s:%d: WSS default servers must pin the trust store", srv.Host, srv.Port)
+ }
+ }
+}
--
2.50.1 (Apple Git-155)

@npub180c…h6w6 re https://github.com/fiatjaf/nak/pull/123 — ...

2026-04-19T11:25:10Z

In reply to naddr1qq…cxua
_________________________

fiatjaf (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: nostr:nevent1qqs8yepuma694y6saym8ny4wtfzymlgu2htusvweyjzpamc0rgn8pyqpz3mhxue69uhhyetvv9ujumn8d96zuer9wcq3yamnwvaz7tm8d96xummnw3ezucm0d5q3gamnwvaz7tmjv4kxz7fwv3sk6atn9e5k7q3qgvv9ahktvavf9qjtrgm62le7gplmmchd5usp5wpfhr85hf79kncq8jdtz6. GitHub mirror: https://github.com/mstrofnone/nostrlib-nip05-namecoin

This is spot on. Satoshi saw merged mining as the way to ...

2026-04-08T08:33:05Z

In reply to nevent1q…vxmt
_________________________

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:

quoting
naddr1qv…753t

How-To Guide: Namecoin Integration in Amethyst

What This Is

Amethyst — the Android Nostr client — includes built-in support for resolving Namecoin blockchain names as NIP-05 identities. Instead of relying on a web server to verify alice@example.com, a user can set their NIP-05 address to something like alice@example.bit, and Amethyst will verify it directly against the Namecoin blockchain via ElectrumX servers.

This is censorship-resistant identity: no web server to seize, no DNS to hijack, no TLS certificate to revoke. The name-to-pubkey mapping lives in Namecoin UTXOs.

This guide covers how the system works, how to use it as an end-user, and how to register or update a Namecoin name value so that it resolves to your Nostr pubkey.

Part 1: Using Namecoin Names in Amethyst (End-User)

Searching for Namecoin Users

Open Amethyst's search bar and type any of these formats:

Search Input What It Does

alice@example.bit Looks up the alice entry in Namecoin name d/example

example.bit Looks up the root (_) entry in d/example

d/example Direct Namecoin domain namespace lookup (root entry)

id/alice Direct Namecoin identity namespace lookup

Amethyst queries the Namecoin blockchain through an ElectrumX server, resolves the name to a Nostr public key, and shows the matching user profile at the top of search results. There is a 400ms debounce on the search input to avoid flooding the server with requests.

NIP-05 Verification via Namecoin

If a Nostr profile has a .bit address in its nip05 metadata field (e.g. m@testls.bit), Amethyst will automatically verify it against the blockchain instead of making an HTTP request. The verification badge works the same as traditional NIP-05 — the only difference is the trust anchor: blockchain consensus rather than a web server.

Configuring Namecoin Settings

Navigate to Settings → Namecoin Settings in Amethyst. From here you can:

Enable/disable Namecoin resolution entirely

Add custom ElectrumX servers — useful if you run your own server for privacy

Remove servers from the custom list

Test server connectivity — checks TLS, latency, and optionally resolves a test name

Pin TLS certificates — after testing a server with a self-signed cert, you can pin its certificate via TOFU (Trust On First Use)

Reset to defaults — reverts to the built-in server list

Server String Format

When adding a custom server, use the format:
host:port          → TLS connection (default)
host:port:tcp      → Plaintext TCP (for .onion or local servers)
Examples:
electrumx.testls.space:50002
my-local-server.lan:50001:tcp
i665jpw...dsid.onion:50002
Tor Integration

If you have Tor enabled in Amethyst and have set "NIP-05 verifications via Tor" to on, all Namecoin ElectrumX connections are routed through your Tor SOCKS proxy. The server list also switches to prioritize .onion addresses:

Tor Setting Primary Server Fallback

Off electrumx.testls.space:50002 nmc2.bitcoins.sk:57002

On .onion:50002 (hidden service) electrumx.testls.space:50002 (via Tor)

Toggling Tor on or off in settings takes effect on the next lookup — no app restart needed.

Default ElectrumX Servers

Amethyst ships with these built-in servers:

Server Port TLS Notes

electrumx.testls.space 50002 Yes (self-signed, pinned) Primary

nmc2.bitcoins.sk 57002 Yes (self-signed, pinned) Fallback

46.229.238.187 57002 Yes (self-signed, pinned) IP fallback

The self-signed certificates for these servers are pinned directly into the Amethyst binary, so connections succeed even on devices with strict TLS enforcement (Samsung One UI 7, GrapheneOS).

Part 2: Registering & Updating a Namecoin Name Value

Amethyst itself is a read-only consumer of Namecoin data — it resolves names but does not write to the blockchain. To register or update a Namecoin name so that it points to your Nostr pubkey, you need to interact with the Namecoin blockchain directly using Namecoin Core (the full node software) or a compatible wallet.

Prerequisites

Namecoin Core or Electrum-NMC installed and synced — download from namecoin.org (this guide uses Namecoin Core as an example)

NMC (Namecoin coins) in your wallet — needed to pay registration and update fees (0.01 NMC per registration operation plus associated fees)

Your Nostr hex public key — the 64-character hex string (not npub1...). You can find this in Amethyst under your profile settings or by converting your npub using a tool like https://nostrdeck.com/key-converter.php

Step 1: Choose Your Namespace

Amethyst supports two Namecoin namespaces:

Domain namespace (d/) — maps a domain-like name to one or more Nostr pubkeys. This is the most common choice and mirrors NIP-05's user@domain format.

Identity namespace (id/) — maps a personal identity name to a single Nostr pubkey.

For most users, the d/ namespace is the right choice because it allows user@name.bit style addresses.

Step 2: Register a New Name

Open a terminal and use namecoin-cli:
# Register a name in the domain namespace
# This creates a "pre-registration" (name_new) first
namecoin-cli name_new "d/yourname"
This returns a transaction ID and a random value. Save both — you need the random value for the next step. Wait for the transaction to get at least 12 confirmations (about 2 hours).

Then finalize the registration:
namecoin-cli name_firstupdate "d/yourname" <random_value> '<json_value>'
Step 3: Set the Name Value for Nostr

The JSON value you store in the Namecoin name is what Amethyst reads to find your Nostr pubkey. There are several supported formats.

Simple Form — Single User, Root Domain

If you just want yourname.bit to resolve to your pubkey:
{
  "nostr": "b0635d6a9851d3aed0cd6c495b282167acf761729078d975fc341b22650b07b9"
}
namecoin-cli name_firstupdate "d/yourname" <random> \
  '{"nostr":"b0635d6a9851d3aed0cd6c495b282167acf761729078d975fc341b22650b07b9"}'
This makes yourname.bit and _@yourname.bit resolve to the given pubkey.

Extended Form — Multiple Users with Relay Hints

If you want to host multiple identities under one .bit domain (like a NIP-05 server hosting multiple users):
{
  "nostr": {
    "names": {
      "_": "aaaa000000000000000000000000000000000000000000000000000000000001",
      "alice": "bbbb000000000000000000000000000000000000000000000000000000000002",
      "bob": "cccc000000000000000000000000000000000000000000000000000000000003"
    },
    "relays": {
      "bbbb000000000000000000000000000000000000000000000000000000000002": [
        "wss://relay.example.com",
        "wss://nos.lol"
      ]
    }
  }
}
With this value stored in d/yourname: - _@yourname.bit or yourname.bit → resolves to the _ pubkey - alice@yourname.bit → resolves to Alice's pubkey, with relay hints - bob@yourname.bit → resolves to Bob's pubkey
namecoin-cli name_firstupdate "d/yourname" <random> \
  '{"nostr":{"names":{"_":"aaaa...0001","alice":"bbbb...0002"},"relays":{"bbbb...0002":["wss://relay.example.com"]}}}'
Identity Namespace Form (id/)

For the id/ namespace, the value format is simpler:
{
  "nostr": "cccc000000000000000000000000000000000000000000000000000000000003"
}
Or with relay hints:
{
  "nostr": {
    "pubkey": "dddd000000000000000000000000000000000000000000000000000000000004",
    "relays": ["wss://relay.example.com"]
  }
}
namecoin-cli name_firstupdate "id/youridentity" <random> \
  '{"nostr":{"pubkey":"dddd...0004","relays":["wss://relay.example.com"]}}'
Step 4: Update an Existing Name

To change the Nostr pubkey (or any other data) associated with an already-registered name, use name_update:
namecoin-cli name_update "d/yourname" \
  '{"nostr":{"names":{"_":"<new_hex_pubkey>","alice":"<alice_hex_pubkey>"},"relays":{"<alice_hex_pubkey>":["wss://relay.example.com"]}}}'
This broadcasts a NAME_UPDATE transaction to the Namecoin blockchain. Once confirmed, Amethyst (and any other client that supports Namecoin NIP-05) will resolve the name to the new value.

Important notes on updates:

Each name_update costs a small NMC fee

Names expire after 36,000 blocks (~36 weeks) if not updated or renewed. Amethyst checks expiry and will treat expired names as non-existent.

To simply renew without changing the value, you can name_update with the same value

Updates replace the entire value — there is no partial update mechanism

Step 5: Set Your NIP-05 in Your Nostr Profile

Once your Namecoin name is registered and confirmed on the blockchain, update your Nostr profile's nip05 field in Amethyst:

Go to your profile → Edit

Set the NIP-05 field to your Namecoin address, e.g. alice@yourname.bit

Save

Amethyst (and other Namecoin-aware clients) will verify this address against the blockchain and show the verification badge.

Step 6: Verify It Works

In Amethyst's search bar, type your Namecoin identifier. You should see your profile appear at the top of results:

Test Query Expected Result

alice@yourname.bit Your profile (matched via alice entry)

yourname.bit Your profile (matched via _ root entry)

d/yourname Your profile (direct namespace lookup)

Part 3: How It Works Under the Hood

Resolution Flow

When Amethyst encounters a .bit address, here is what happens:
1. User types "alice@example.bit" in search (or a profile has it in nip05)

2. NamecoinNameResolver.parseIdentifier() parses it:
   → namecoinName = "d/example", localPart = "alice", namespace = DOMAIN

3. ElectrumXClient builds a canonical "name index script":
   OP_NAME_UPDATE(0x53) + push("d/example") + push("") + OP_2DROP + OP_DROP + OP_RETURN

4. Computes the Electrum-style scripthash:
   SHA-256(script) → reverse bytes → hex encode

5. Queries the ElectrumX server:
   → blockchain.scripthash.get_history(scripthash)
   ← [{tx_hash: "abc...", height: 814278}, ...]

6. Fetches the latest transaction (last entry = most recent name update):
   → blockchain.transaction.get(tx_hash, verbose=true)

7. Checks block headers to verify the name hasn't expired:
   → blockchain.headers.subscribe
   ← current height; if (current - update_height) >= 36000 → expired

8. Parses the NAME_UPDATE script from the transaction output:
   Extracts: name string + JSON value

9. NamecoinNameResolver.extractFromDomainValue() reads the JSON:
   Finds "nostr" → "names" → "alice" → hex pubkey

10. Returns NamecoinNostrResult(pubkey, relays, namecoinName, localPart)
Caching

Resolved names are cached in an LRU cache (default 500 entries, 1-hour TTL). Both positive and negative results are cached. The cache is keyed by the normalized (lowercased, trimmed) identifier.

Architecture Layers

The implementation is split across two modules:

Quartz (library, no Android dependencies): - NamecoinNameResolver — identifier parsing, value extraction, resolution orchestration - ElectrumXClient — TCP/TLS connection to ElectrumX, JSON-RPC, script parsing - NamecoinLookupCache — LRU cache with TTL - IElectrumXClient — interface for testing/mocking

Amethyst (Android app): - NamecoinNameService — application singleton, wires up caching and proxy-aware client - NamecoinSettings / NamecoinSharedPreferences — persistent config - NamecoinSettingsScreen / NamecoinSettingsSection — settings UI - ProxiedSocketFactory — SOCKS5 proxy routing for Tor - RoleBasedHttpClientBuilder.socketFactoryForNip05() — Tor-aware socket creation

The integration into NIP-05 is minimal: Nip05Client checks if an identifier matches .bit / d/ / id/ patterns, and routes to NamecoinNameResolver instead of making an HTTP fetch. Non-Namecoin identifiers are completely unaffected.

Part 4: Security Considerations

Tor integration — When enabled, all ElectrumX connections go through the Tor SOCKS proxy. The .onion server is preferred for end-to-end onion routing. Socket factory and server list are evaluated per-request via lambdas, so toggling Tor takes effect immediately.

TLS certificate pinning — The primary ElectrumX servers use self-signed certificates. Their PEM-encoded certs are pinned in the Amethyst binary. Users can pin additional certs via the TOFU flow in settings (test server → view fingerprint → confirm → pin). This is necessary because Samsung One UI 7 and GrapheneOS reject trust-all TrustManagers.

Name expiry — Namecoin names expire after ~36,000 blocks (~250 days) if not renewed. The ElectrumX client checks the current block height against the name's last update height and treats expired names as non-existent.

Server trust — The client trusts that the ElectrumX server returns accurate transaction data. The Namecoin blockchain itself is the trust anchor — a MITM could return stale data but cannot forge name registrations. For higher assurance, SPV proof verification could be added in the future.

Quick Reference

Identifier Format Summary

User Input Namecoin Name Looked-Up Entry Namespace

alice@example.bit d/example alice Domain

_@example.bit d/example _ (root) Domain

example.bit d/example _ (root) Domain

d/example d/example _ (root) Domain

id/alice id/alice _ (root) Identity

Name Value JSON Formats

Domain simple:
{"nostr": "<64-char-hex-pubkey>"}
Domain extended (multi-user + relays):
{"nostr": {"names": {"_": "<hex>", "alice": "<hex>"}, "relays": {"<hex>": ["wss://..."]}}}
Identity simple:
{"nostr": "<64-char-hex-pubkey>"}
Identity with relays:
{"nostr": {"pubkey": "<hex>", "relays": ["wss://..."]}}
Namecoin CLI Commands
# Register a new name
namecoin-cli name_new "d/yourname"
# Returns: [txid, random_value]
# Example:
#   [
#     "a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2",
#     "6e4a2d190f7b"
#   ]
# SAVE BOTH — you need the random value (2nd element) for name_firstupdate.
# Wait for at least 12 confirmations (~2 hours) before proceeding.

# Finalize registration with the random value from name_new
namecoin-cli name_firstupdate "d/yourname" <random> '<json>'

# Update an existing name
namecoin-cli name_update "d/yourname" '<new_json>'

# Check a name's current value
namecoin-cli name_show "d/yourname"

# List your names
namecoin-cli name_list
Getting Namecoins via DVM (NIP-90)

Don't have NMC? You can acquire Namecoin through a Nostr-native exchange service — no centralized exchange account needed.

The NMC Exchange DVM is a NIP-90 Data Vending Machine that accepts Lightning Bitcoin (⚡ sats) or Cashu ecash (🥜) and sends NMC directly to your Namecoin address.

How it works:

Send a kind:5950 job request to the DVM with your NMC address and desired amount (0.2–0.5 NMC)

The DVM responds with a Lightning invoice or Cashu payment info

Pay via Lightning zap or Cashu ecash

Receive NMC at your designated address — the DVM sends the kind:6950 result with the NMC transaction ID

Rate: $10 USD per NMC (max 0.5 NMC per order)

Payment methods: Lightning Bitcoin ⚡ | Cashu ecash 🥜

DVM address (NIP-89):
naddr1qv…fjn5
View on NostrHub: NMC Exchange DVM

Example job request:
{
  "kind": 5950,
  "tags": [
    ["i", "<your-nmc-address>", "text"],
    ["param", "amount", "0.5"],
    ["bid", "10000000"]
  ],
  "content": ""
}
This is an experimental service — no guarantees of uptime, but it's a quick way to get NMC for name registrations without touching a centralized exchange.

Testing (for Developers)
# Run unit tests
./gradlew :quartz:jvmTest --tests "*NamecoinNameResolverTest*"

# Build and install debug APK
./gradlew assemblePlayDebug
adb install -r amethyst/build/outputs/apk/play/debug/amethyst-play-universal-debug.apk

# Monitor ElectrumX connections
adb root && adb shell tcpdump -i any -nn port 50002 or port 50006
Live Test Data

The name d/testls is registered on the Namecoin blockchain with value:
{"nostr": {"names": {"_": "6cdebccabda1dfa058ab85352a79509b592b2bdfa0370325e28ec1cb4f18667d"}}}
So _@testls.bit (or simply testls.bit) resolves to Vitor Pamplona's Nostr profile.

Search Input	What It Does
`alice@example.bit`	Looks up the `alice` entry in Namecoin name `d/example`
`example.bit`	Looks up the root (`_`) entry in `d/example`
`d/example`	Direct Namecoin domain namespace lookup (root entry)
`id/alice`	Direct Namecoin identity namespace lookup

Tor Setting	Primary Server	Fallback
Off	`electrumx.testls.space:50002`	`nmc2.bitcoins.sk:57002`
On	`.onion:50002` (hidden service)	`electrumx.testls.space:50002` (via Tor)

Server	Port	TLS	Notes
`electrumx.testls.space`	50002	Yes (self-signed, pinned)	Primary
`nmc2.bitcoins.sk`	57002	Yes (self-signed, pinned)	Fallback
`46.229.238.187`	57002	Yes (self-signed, pinned)	IP fallback

Test Query	Expected Result
`alice@yourname.bit`	Your profile (matched via `alice` entry)
`yourname.bit`	Your profile (matched via `_` root entry)
`d/yourname`	Your profile (direct namespace lookup)

User Input	Namecoin Name	Looked-Up Entry	Namespace
`alice@example.bit`	`d/example`	`alice`	Domain
`_@example.bit`	`d/example`	`_` (root)	Domain
`example.bit`	`d/example`	`_` (root)	Domain
`d/example`	`d/example`	`_` (root)	Domain
`id/alice`	`id/alice`	`_` (root)	Identity

The cypherpunk use case Satoshi envisioned for merged mining is more relevant now than ever.

Usage stats for .bit domains don't tell the whole story. ...

2026-04-08T08:31:24Z

In reply to nevent1q…7frf
_________________________

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:

quoting
naddr1qv…753t

How-To Guide: Namecoin Integration in Amethyst

What This Is

Amethyst — the Android Nostr client — includes built-in support for resolving Namecoin blockchain names as NIP-05 identities. Instead of relying on a web server to verify alice@example.com, a user can set their NIP-05 address to something like alice@example.bit, and Amethyst will verify it directly against the Namecoin blockchain via ElectrumX servers.

This is censorship-resistant identity: no web server to seize, no DNS to hijack, no TLS certificate to revoke. The name-to-pubkey mapping lives in Namecoin UTXOs.

This guide covers how the system works, how to use it as an end-user, and how to register or update a Namecoin name value so that it resolves to your Nostr pubkey.

Part 1: Using Namecoin Names in Amethyst (End-User)

Searching for Namecoin Users

Open Amethyst's search bar and type any of these formats:

Search Input What It Does

alice@example.bit Looks up the alice entry in Namecoin name d/example

example.bit Looks up the root (_) entry in d/example

d/example Direct Namecoin domain namespace lookup (root entry)

id/alice Direct Namecoin identity namespace lookup

Amethyst queries the Namecoin blockchain through an ElectrumX server, resolves the name to a Nostr public key, and shows the matching user profile at the top of search results. There is a 400ms debounce on the search input to avoid flooding the server with requests.

NIP-05 Verification via Namecoin

If a Nostr profile has a .bit address in its nip05 metadata field (e.g. m@testls.bit), Amethyst will automatically verify it against the blockchain instead of making an HTTP request. The verification badge works the same as traditional NIP-05 — the only difference is the trust anchor: blockchain consensus rather than a web server.

Configuring Namecoin Settings

Navigate to Settings → Namecoin Settings in Amethyst. From here you can:

Enable/disable Namecoin resolution entirely

Add custom ElectrumX servers — useful if you run your own server for privacy

Remove servers from the custom list

Test server connectivity — checks TLS, latency, and optionally resolves a test name

Pin TLS certificates — after testing a server with a self-signed cert, you can pin its certificate via TOFU (Trust On First Use)

Reset to defaults — reverts to the built-in server list

Server String Format

When adding a custom server, use the format:
host:port          → TLS connection (default)
host:port:tcp      → Plaintext TCP (for .onion or local servers)
Examples:
electrumx.testls.space:50002
my-local-server.lan:50001:tcp
i665jpw...dsid.onion:50002
Tor Integration

If you have Tor enabled in Amethyst and have set "NIP-05 verifications via Tor" to on, all Namecoin ElectrumX connections are routed through your Tor SOCKS proxy. The server list also switches to prioritize .onion addresses:

Tor Setting Primary Server Fallback

Off electrumx.testls.space:50002 nmc2.bitcoins.sk:57002

On .onion:50002 (hidden service) electrumx.testls.space:50002 (via Tor)

Toggling Tor on or off in settings takes effect on the next lookup — no app restart needed.

Default ElectrumX Servers

Amethyst ships with these built-in servers:

Server Port TLS Notes

electrumx.testls.space 50002 Yes (self-signed, pinned) Primary

nmc2.bitcoins.sk 57002 Yes (self-signed, pinned) Fallback

46.229.238.187 57002 Yes (self-signed, pinned) IP fallback

The self-signed certificates for these servers are pinned directly into the Amethyst binary, so connections succeed even on devices with strict TLS enforcement (Samsung One UI 7, GrapheneOS).

Part 2: Registering & Updating a Namecoin Name Value

Amethyst itself is a read-only consumer of Namecoin data — it resolves names but does not write to the blockchain. To register or update a Namecoin name so that it points to your Nostr pubkey, you need to interact with the Namecoin blockchain directly using Namecoin Core (the full node software) or a compatible wallet.

Prerequisites

Namecoin Core or Electrum-NMC installed and synced — download from namecoin.org (this guide uses Namecoin Core as an example)

NMC (Namecoin coins) in your wallet — needed to pay registration and update fees (0.01 NMC per registration operation plus associated fees)

Your Nostr hex public key — the 64-character hex string (not npub1...). You can find this in Amethyst under your profile settings or by converting your npub using a tool like https://nostrdeck.com/key-converter.php

Step 1: Choose Your Namespace

Amethyst supports two Namecoin namespaces:

Domain namespace (d/) — maps a domain-like name to one or more Nostr pubkeys. This is the most common choice and mirrors NIP-05's user@domain format.

Identity namespace (id/) — maps a personal identity name to a single Nostr pubkey.

For most users, the d/ namespace is the right choice because it allows user@name.bit style addresses.

Step 2: Register a New Name

Open a terminal and use namecoin-cli:
# Register a name in the domain namespace
# This creates a "pre-registration" (name_new) first
namecoin-cli name_new "d/yourname"
This returns a transaction ID and a random value. Save both — you need the random value for the next step. Wait for the transaction to get at least 12 confirmations (about 2 hours).

Then finalize the registration:
namecoin-cli name_firstupdate "d/yourname" <random_value> '<json_value>'
Step 3: Set the Name Value for Nostr

The JSON value you store in the Namecoin name is what Amethyst reads to find your Nostr pubkey. There are several supported formats.

Simple Form — Single User, Root Domain

If you just want yourname.bit to resolve to your pubkey:
{
  "nostr": "b0635d6a9851d3aed0cd6c495b282167acf761729078d975fc341b22650b07b9"
}
namecoin-cli name_firstupdate "d/yourname" <random> \
  '{"nostr":"b0635d6a9851d3aed0cd6c495b282167acf761729078d975fc341b22650b07b9"}'
This makes yourname.bit and _@yourname.bit resolve to the given pubkey.

Extended Form — Multiple Users with Relay Hints

If you want to host multiple identities under one .bit domain (like a NIP-05 server hosting multiple users):
{
  "nostr": {
    "names": {
      "_": "aaaa000000000000000000000000000000000000000000000000000000000001",
      "alice": "bbbb000000000000000000000000000000000000000000000000000000000002",
      "bob": "cccc000000000000000000000000000000000000000000000000000000000003"
    },
    "relays": {
      "bbbb000000000000000000000000000000000000000000000000000000000002": [
        "wss://relay.example.com",
        "wss://nos.lol"
      ]
    }
  }
}
With this value stored in d/yourname: - _@yourname.bit or yourname.bit → resolves to the _ pubkey - alice@yourname.bit → resolves to Alice's pubkey, with relay hints - bob@yourname.bit → resolves to Bob's pubkey
namecoin-cli name_firstupdate "d/yourname" <random> \
  '{"nostr":{"names":{"_":"aaaa...0001","alice":"bbbb...0002"},"relays":{"bbbb...0002":["wss://relay.example.com"]}}}'
Identity Namespace Form (id/)

For the id/ namespace, the value format is simpler:
{
  "nostr": "cccc000000000000000000000000000000000000000000000000000000000003"
}
Or with relay hints:
{
  "nostr": {
    "pubkey": "dddd000000000000000000000000000000000000000000000000000000000004",
    "relays": ["wss://relay.example.com"]
  }
}
namecoin-cli name_firstupdate "id/youridentity" <random> \
  '{"nostr":{"pubkey":"dddd...0004","relays":["wss://relay.example.com"]}}'
Step 4: Update an Existing Name

To change the Nostr pubkey (or any other data) associated with an already-registered name, use name_update:
namecoin-cli name_update "d/yourname" \
  '{"nostr":{"names":{"_":"<new_hex_pubkey>","alice":"<alice_hex_pubkey>"},"relays":{"<alice_hex_pubkey>":["wss://relay.example.com"]}}}'
This broadcasts a NAME_UPDATE transaction to the Namecoin blockchain. Once confirmed, Amethyst (and any other client that supports Namecoin NIP-05) will resolve the name to the new value.

Important notes on updates:

Each name_update costs a small NMC fee

Names expire after 36,000 blocks (~36 weeks) if not updated or renewed. Amethyst checks expiry and will treat expired names as non-existent.

To simply renew without changing the value, you can name_update with the same value

Updates replace the entire value — there is no partial update mechanism

Step 5: Set Your NIP-05 in Your Nostr Profile

Once your Namecoin name is registered and confirmed on the blockchain, update your Nostr profile's nip05 field in Amethyst:

Go to your profile → Edit

Set the NIP-05 field to your Namecoin address, e.g. alice@yourname.bit

Save

Amethyst (and other Namecoin-aware clients) will verify this address against the blockchain and show the verification badge.

Step 6: Verify It Works

In Amethyst's search bar, type your Namecoin identifier. You should see your profile appear at the top of results:

Test Query Expected Result

alice@yourname.bit Your profile (matched via alice entry)

yourname.bit Your profile (matched via _ root entry)

d/yourname Your profile (direct namespace lookup)

Part 3: How It Works Under the Hood

Resolution Flow

When Amethyst encounters a .bit address, here is what happens:
1. User types "alice@example.bit" in search (or a profile has it in nip05)

2. NamecoinNameResolver.parseIdentifier() parses it:
   → namecoinName = "d/example", localPart = "alice", namespace = DOMAIN

3. ElectrumXClient builds a canonical "name index script":
   OP_NAME_UPDATE(0x53) + push("d/example") + push("") + OP_2DROP + OP_DROP + OP_RETURN

4. Computes the Electrum-style scripthash:
   SHA-256(script) → reverse bytes → hex encode

5. Queries the ElectrumX server:
   → blockchain.scripthash.get_history(scripthash)
   ← [{tx_hash: "abc...", height: 814278}, ...]

6. Fetches the latest transaction (last entry = most recent name update):
   → blockchain.transaction.get(tx_hash, verbose=true)

7. Checks block headers to verify the name hasn't expired:
   → blockchain.headers.subscribe
   ← current height; if (current - update_height) >= 36000 → expired

8. Parses the NAME_UPDATE script from the transaction output:
   Extracts: name string + JSON value

9. NamecoinNameResolver.extractFromDomainValue() reads the JSON:
   Finds "nostr" → "names" → "alice" → hex pubkey

10. Returns NamecoinNostrResult(pubkey, relays, namecoinName, localPart)
Caching

Resolved names are cached in an LRU cache (default 500 entries, 1-hour TTL). Both positive and negative results are cached. The cache is keyed by the normalized (lowercased, trimmed) identifier.

Architecture Layers

The implementation is split across two modules:

Quartz (library, no Android dependencies): - NamecoinNameResolver — identifier parsing, value extraction, resolution orchestration - ElectrumXClient — TCP/TLS connection to ElectrumX, JSON-RPC, script parsing - NamecoinLookupCache — LRU cache with TTL - IElectrumXClient — interface for testing/mocking

Amethyst (Android app): - NamecoinNameService — application singleton, wires up caching and proxy-aware client - NamecoinSettings / NamecoinSharedPreferences — persistent config - NamecoinSettingsScreen / NamecoinSettingsSection — settings UI - ProxiedSocketFactory — SOCKS5 proxy routing for Tor - RoleBasedHttpClientBuilder.socketFactoryForNip05() — Tor-aware socket creation

The integration into NIP-05 is minimal: Nip05Client checks if an identifier matches .bit / d/ / id/ patterns, and routes to NamecoinNameResolver instead of making an HTTP fetch. Non-Namecoin identifiers are completely unaffected.

Part 4: Security Considerations

Tor integration — When enabled, all ElectrumX connections go through the Tor SOCKS proxy. The .onion server is preferred for end-to-end onion routing. Socket factory and server list are evaluated per-request via lambdas, so toggling Tor takes effect immediately.

TLS certificate pinning — The primary ElectrumX servers use self-signed certificates. Their PEM-encoded certs are pinned in the Amethyst binary. Users can pin additional certs via the TOFU flow in settings (test server → view fingerprint → confirm → pin). This is necessary because Samsung One UI 7 and GrapheneOS reject trust-all TrustManagers.

Name expiry — Namecoin names expire after ~36,000 blocks (~250 days) if not renewed. The ElectrumX client checks the current block height against the name's last update height and treats expired names as non-existent.

Server trust — The client trusts that the ElectrumX server returns accurate transaction data. The Namecoin blockchain itself is the trust anchor — a MITM could return stale data but cannot forge name registrations. For higher assurance, SPV proof verification could be added in the future.

Quick Reference

Identifier Format Summary

User Input Namecoin Name Looked-Up Entry Namespace

alice@example.bit d/example alice Domain

_@example.bit d/example _ (root) Domain

example.bit d/example _ (root) Domain

d/example d/example _ (root) Domain

id/alice id/alice _ (root) Identity

Name Value JSON Formats

Domain simple:
{"nostr": "<64-char-hex-pubkey>"}
Domain extended (multi-user + relays):
{"nostr": {"names": {"_": "<hex>", "alice": "<hex>"}, "relays": {"<hex>": ["wss://..."]}}}
Identity simple:
{"nostr": "<64-char-hex-pubkey>"}
Identity with relays:
{"nostr": {"pubkey": "<hex>", "relays": ["wss://..."]}}
Namecoin CLI Commands
# Register a new name
namecoin-cli name_new "d/yourname"
# Returns: [txid, random_value]
# Example:
#   [
#     "a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2",
#     "6e4a2d190f7b"
#   ]
# SAVE BOTH — you need the random value (2nd element) for name_firstupdate.
# Wait for at least 12 confirmations (~2 hours) before proceeding.

# Finalize registration with the random value from name_new
namecoin-cli name_firstupdate "d/yourname" <random> '<json>'

# Update an existing name
namecoin-cli name_update "d/yourname" '<new_json>'

# Check a name's current value
namecoin-cli name_show "d/yourname"

# List your names
namecoin-cli name_list
Getting Namecoins via DVM (NIP-90)

Don't have NMC? You can acquire Namecoin through a Nostr-native exchange service — no centralized exchange account needed.

The NMC Exchange DVM is a NIP-90 Data Vending Machine that accepts Lightning Bitcoin (⚡ sats) or Cashu ecash (🥜) and sends NMC directly to your Namecoin address.

How it works:

Send a kind:5950 job request to the DVM with your NMC address and desired amount (0.2–0.5 NMC)

The DVM responds with a Lightning invoice or Cashu payment info

Pay via Lightning zap or Cashu ecash

Receive NMC at your designated address — the DVM sends the kind:6950 result with the NMC transaction ID

Rate: $10 USD per NMC (max 0.5 NMC per order)

Payment methods: Lightning Bitcoin ⚡ | Cashu ecash 🥜

DVM address (NIP-89):
naddr1qv…fjn5
View on NostrHub: NMC Exchange DVM

Example job request:
{
  "kind": 5950,
  "tags": [
    ["i", "<your-nmc-address>", "text"],
    ["param", "amount", "0.5"],
    ["bid", "10000000"]
  ],
  "content": ""
}
This is an experimental service — no guarantees of uptime, but it's a quick way to get NMC for name registrations without touching a centralized exchange.

Testing (for Developers)
# Run unit tests
./gradlew :quartz:jvmTest --tests "*NamecoinNameResolverTest*"

# Build and install debug APK
./gradlew assemblePlayDebug
adb install -r amethyst/build/outputs/apk/play/debug/amethyst-play-universal-debug.apk

# Monitor ElectrumX connections
adb root && adb shell tcpdump -i any -nn port 50002 or port 50006
Live Test Data

The name d/testls is registered on the Namecoin blockchain with value:
{"nostr": {"names": {"_": "6cdebccabda1dfa058ab85352a79509b592b2bdfa0370325e28ec1cb4f18667d"}}}
So _@testls.bit (or simply testls.bit) resolves to Vitor Pamplona's Nostr profile.

Search Input	What It Does
`alice@example.bit`	Looks up the `alice` entry in Namecoin name `d/example`
`example.bit`	Looks up the root (`_`) entry in `d/example`
`d/example`	Direct Namecoin domain namespace lookup (root entry)
`id/alice`	Direct Namecoin identity namespace lookup

Tor Setting	Primary Server	Fallback
Off	`electrumx.testls.space:50002`	`nmc2.bitcoins.sk:57002`
On	`.onion:50002` (hidden service)	`electrumx.testls.space:50002` (via Tor)

Server	Port	TLS	Notes
`electrumx.testls.space`	50002	Yes (self-signed, pinned)	Primary
`nmc2.bitcoins.sk`	57002	Yes (self-signed, pinned)	Fallback
`46.229.238.187`	57002	Yes (self-signed, pinned)	IP fallback

Test Query	Expected Result
`alice@yourname.bit`	Your profile (matched via `alice` entry)
`yourname.bit`	Your profile (matched via `_` root entry)
`d/yourname`	Your profile (direct namespace lookup)

User Input	Namecoin Name	Looked-Up Entry	Namespace
`alice@example.bit`	`d/example`	`alice`	Domain
`_@example.bit`	`d/example`	`_` (root)	Domain
`example.bit`	`d/example`	`_` (root)	Domain
`d/example`	`d/example`	`_` (root)	Domain
`id/alice`	`id/alice`	`_` (root)	Identity

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.

This is spot on. Satoshi saw merged mining as the way to ...

2026-04-08T08:24:34Z

In reply to nevent1q…vxmt
_________________________

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:

quoting
naddr1qv…753t

How-To Guide: Namecoin Integration in Amethyst

What This Is

Amethyst — the Android Nostr client — includes built-in support for resolving Namecoin blockchain names as NIP-05 identities. Instead of relying on a web server to verify alice@example.com, a user can set their NIP-05 address to something like alice@example.bit, and Amethyst will verify it directly against the Namecoin blockchain via ElectrumX servers.

This is censorship-resistant identity: no web server to seize, no DNS to hijack, no TLS certificate to revoke. The name-to-pubkey mapping lives in Namecoin UTXOs.

This guide covers how the system works, how to use it as an end-user, and how to register or update a Namecoin name value so that it resolves to your Nostr pubkey.

Part 1: Using Namecoin Names in Amethyst (End-User)

Searching for Namecoin Users

Open Amethyst's search bar and type any of these formats:

Search Input What It Does

alice@example.bit Looks up the alice entry in Namecoin name d/example

example.bit Looks up the root (_) entry in d/example

d/example Direct Namecoin domain namespace lookup (root entry)

id/alice Direct Namecoin identity namespace lookup

Amethyst queries the Namecoin blockchain through an ElectrumX server, resolves the name to a Nostr public key, and shows the matching user profile at the top of search results. There is a 400ms debounce on the search input to avoid flooding the server with requests.

NIP-05 Verification via Namecoin

If a Nostr profile has a .bit address in its nip05 metadata field (e.g. m@testls.bit), Amethyst will automatically verify it against the blockchain instead of making an HTTP request. The verification badge works the same as traditional NIP-05 — the only difference is the trust anchor: blockchain consensus rather than a web server.

Configuring Namecoin Settings

Navigate to Settings → Namecoin Settings in Amethyst. From here you can:

Enable/disable Namecoin resolution entirely

Add custom ElectrumX servers — useful if you run your own server for privacy

Remove servers from the custom list

Test server connectivity — checks TLS, latency, and optionally resolves a test name

Pin TLS certificates — after testing a server with a self-signed cert, you can pin its certificate via TOFU (Trust On First Use)

Reset to defaults — reverts to the built-in server list

Server String Format

When adding a custom server, use the format:
host:port          → TLS connection (default)
host:port:tcp      → Plaintext TCP (for .onion or local servers)
Examples:
electrumx.testls.space:50002
my-local-server.lan:50001:tcp
i665jpw...dsid.onion:50002
Tor Integration

If you have Tor enabled in Amethyst and have set "NIP-05 verifications via Tor" to on, all Namecoin ElectrumX connections are routed through your Tor SOCKS proxy. The server list also switches to prioritize .onion addresses:

Tor Setting Primary Server Fallback

Off electrumx.testls.space:50002 nmc2.bitcoins.sk:57002

On .onion:50002 (hidden service) electrumx.testls.space:50002 (via Tor)

Toggling Tor on or off in settings takes effect on the next lookup — no app restart needed.

Default ElectrumX Servers

Amethyst ships with these built-in servers:

Server Port TLS Notes

electrumx.testls.space 50002 Yes (self-signed, pinned) Primary

nmc2.bitcoins.sk 57002 Yes (self-signed, pinned) Fallback

46.229.238.187 57002 Yes (self-signed, pinned) IP fallback

The self-signed certificates for these servers are pinned directly into the Amethyst binary, so connections succeed even on devices with strict TLS enforcement (Samsung One UI 7, GrapheneOS).

Part 2: Registering & Updating a Namecoin Name Value

Amethyst itself is a read-only consumer of Namecoin data — it resolves names but does not write to the blockchain. To register or update a Namecoin name so that it points to your Nostr pubkey, you need to interact with the Namecoin blockchain directly using Namecoin Core (the full node software) or a compatible wallet.

Prerequisites

Namecoin Core or Electrum-NMC installed and synced — download from namecoin.org (this guide uses Namecoin Core as an example)

NMC (Namecoin coins) in your wallet — needed to pay registration and update fees (0.01 NMC per registration operation plus associated fees)

Your Nostr hex public key — the 64-character hex string (not npub1...). You can find this in Amethyst under your profile settings or by converting your npub using a tool like https://nostrdeck.com/key-converter.php

Step 1: Choose Your Namespace

Amethyst supports two Namecoin namespaces:

Domain namespace (d/) — maps a domain-like name to one or more Nostr pubkeys. This is the most common choice and mirrors NIP-05's user@domain format.

Identity namespace (id/) — maps a personal identity name to a single Nostr pubkey.

For most users, the d/ namespace is the right choice because it allows user@name.bit style addresses.

Step 2: Register a New Name

Open a terminal and use namecoin-cli:
# Register a name in the domain namespace
# This creates a "pre-registration" (name_new) first
namecoin-cli name_new "d/yourname"
This returns a transaction ID and a random value. Save both — you need the random value for the next step. Wait for the transaction to get at least 12 confirmations (about 2 hours).

Then finalize the registration:
namecoin-cli name_firstupdate "d/yourname" <random_value> '<json_value>'
Step 3: Set the Name Value for Nostr

The JSON value you store in the Namecoin name is what Amethyst reads to find your Nostr pubkey. There are several supported formats.

Simple Form — Single User, Root Domain

If you just want yourname.bit to resolve to your pubkey:
{
  "nostr": "b0635d6a9851d3aed0cd6c495b282167acf761729078d975fc341b22650b07b9"
}
namecoin-cli name_firstupdate "d/yourname" <random> \
  '{"nostr":"b0635d6a9851d3aed0cd6c495b282167acf761729078d975fc341b22650b07b9"}'
This makes yourname.bit and _@yourname.bit resolve to the given pubkey.

Extended Form — Multiple Users with Relay Hints

If you want to host multiple identities under one .bit domain (like a NIP-05 server hosting multiple users):
{
  "nostr": {
    "names": {
      "_": "aaaa000000000000000000000000000000000000000000000000000000000001",
      "alice": "bbbb000000000000000000000000000000000000000000000000000000000002",
      "bob": "cccc000000000000000000000000000000000000000000000000000000000003"
    },
    "relays": {
      "bbbb000000000000000000000000000000000000000000000000000000000002": [
        "wss://relay.example.com",
        "wss://nos.lol"
      ]
    }
  }
}
With this value stored in d/yourname: - _@yourname.bit or yourname.bit → resolves to the _ pubkey - alice@yourname.bit → resolves to Alice's pubkey, with relay hints - bob@yourname.bit → resolves to Bob's pubkey
namecoin-cli name_firstupdate "d/yourname" <random> \
  '{"nostr":{"names":{"_":"aaaa...0001","alice":"bbbb...0002"},"relays":{"bbbb...0002":["wss://relay.example.com"]}}}'
Identity Namespace Form (id/)

For the id/ namespace, the value format is simpler:
{
  "nostr": "cccc000000000000000000000000000000000000000000000000000000000003"
}
Or with relay hints:
{
  "nostr": {
    "pubkey": "dddd000000000000000000000000000000000000000000000000000000000004",
    "relays": ["wss://relay.example.com"]
  }
}
namecoin-cli name_firstupdate "id/youridentity" <random> \
  '{"nostr":{"pubkey":"dddd...0004","relays":["wss://relay.example.com"]}}'
Step 4: Update an Existing Name

To change the Nostr pubkey (or any other data) associated with an already-registered name, use name_update:
namecoin-cli name_update "d/yourname" \
  '{"nostr":{"names":{"_":"<new_hex_pubkey>","alice":"<alice_hex_pubkey>"},"relays":{"<alice_hex_pubkey>":["wss://relay.example.com"]}}}'
This broadcasts a NAME_UPDATE transaction to the Namecoin blockchain. Once confirmed, Amethyst (and any other client that supports Namecoin NIP-05) will resolve the name to the new value.

Important notes on updates:

Each name_update costs a small NMC fee

Names expire after 36,000 blocks (~36 weeks) if not updated or renewed. Amethyst checks expiry and will treat expired names as non-existent.

To simply renew without changing the value, you can name_update with the same value

Updates replace the entire value — there is no partial update mechanism

Step 5: Set Your NIP-05 in Your Nostr Profile

Once your Namecoin name is registered and confirmed on the blockchain, update your Nostr profile's nip05 field in Amethyst:

Go to your profile → Edit

Set the NIP-05 field to your Namecoin address, e.g. alice@yourname.bit

Save

Amethyst (and other Namecoin-aware clients) will verify this address against the blockchain and show the verification badge.

Step 6: Verify It Works

In Amethyst's search bar, type your Namecoin identifier. You should see your profile appear at the top of results:

Test Query Expected Result

alice@yourname.bit Your profile (matched via alice entry)

yourname.bit Your profile (matched via _ root entry)

d/yourname Your profile (direct namespace lookup)

Part 3: How It Works Under the Hood

Resolution Flow

When Amethyst encounters a .bit address, here is what happens:
1. User types "alice@example.bit" in search (or a profile has it in nip05)

2. NamecoinNameResolver.parseIdentifier() parses it:
   → namecoinName = "d/example", localPart = "alice", namespace = DOMAIN

3. ElectrumXClient builds a canonical "name index script":
   OP_NAME_UPDATE(0x53) + push("d/example") + push("") + OP_2DROP + OP_DROP + OP_RETURN

4. Computes the Electrum-style scripthash:
   SHA-256(script) → reverse bytes → hex encode

5. Queries the ElectrumX server:
   → blockchain.scripthash.get_history(scripthash)
   ← [{tx_hash: "abc...", height: 814278}, ...]

6. Fetches the latest transaction (last entry = most recent name update):
   → blockchain.transaction.get(tx_hash, verbose=true)

7. Checks block headers to verify the name hasn't expired:
   → blockchain.headers.subscribe
   ← current height; if (current - update_height) >= 36000 → expired

8. Parses the NAME_UPDATE script from the transaction output:
   Extracts: name string + JSON value

9. NamecoinNameResolver.extractFromDomainValue() reads the JSON:
   Finds "nostr" → "names" → "alice" → hex pubkey

10. Returns NamecoinNostrResult(pubkey, relays, namecoinName, localPart)
Caching

Resolved names are cached in an LRU cache (default 500 entries, 1-hour TTL). Both positive and negative results are cached. The cache is keyed by the normalized (lowercased, trimmed) identifier.

Architecture Layers

The implementation is split across two modules:

Quartz (library, no Android dependencies): - NamecoinNameResolver — identifier parsing, value extraction, resolution orchestration - ElectrumXClient — TCP/TLS connection to ElectrumX, JSON-RPC, script parsing - NamecoinLookupCache — LRU cache with TTL - IElectrumXClient — interface for testing/mocking

Amethyst (Android app): - NamecoinNameService — application singleton, wires up caching and proxy-aware client - NamecoinSettings / NamecoinSharedPreferences — persistent config - NamecoinSettingsScreen / NamecoinSettingsSection — settings UI - ProxiedSocketFactory — SOCKS5 proxy routing for Tor - RoleBasedHttpClientBuilder.socketFactoryForNip05() — Tor-aware socket creation

The integration into NIP-05 is minimal: Nip05Client checks if an identifier matches .bit / d/ / id/ patterns, and routes to NamecoinNameResolver instead of making an HTTP fetch. Non-Namecoin identifiers are completely unaffected.

Part 4: Security Considerations

Tor integration — When enabled, all ElectrumX connections go through the Tor SOCKS proxy. The .onion server is preferred for end-to-end onion routing. Socket factory and server list are evaluated per-request via lambdas, so toggling Tor takes effect immediately.

TLS certificate pinning — The primary ElectrumX servers use self-signed certificates. Their PEM-encoded certs are pinned in the Amethyst binary. Users can pin additional certs via the TOFU flow in settings (test server → view fingerprint → confirm → pin). This is necessary because Samsung One UI 7 and GrapheneOS reject trust-all TrustManagers.

Name expiry — Namecoin names expire after ~36,000 blocks (~250 days) if not renewed. The ElectrumX client checks the current block height against the name's last update height and treats expired names as non-existent.

Server trust — The client trusts that the ElectrumX server returns accurate transaction data. The Namecoin blockchain itself is the trust anchor — a MITM could return stale data but cannot forge name registrations. For higher assurance, SPV proof verification could be added in the future.

Quick Reference

Identifier Format Summary

User Input Namecoin Name Looked-Up Entry Namespace

alice@example.bit d/example alice Domain

_@example.bit d/example _ (root) Domain

example.bit d/example _ (root) Domain

d/example d/example _ (root) Domain

id/alice id/alice _ (root) Identity

Name Value JSON Formats

Domain simple:
{"nostr": "<64-char-hex-pubkey>"}
Domain extended (multi-user + relays):
{"nostr": {"names": {"_": "<hex>", "alice": "<hex>"}, "relays": {"<hex>": ["wss://..."]}}}
Identity simple:
{"nostr": "<64-char-hex-pubkey>"}
Identity with relays:
{"nostr": {"pubkey": "<hex>", "relays": ["wss://..."]}}
Namecoin CLI Commands
# Register a new name
namecoin-cli name_new "d/yourname"
# Returns: [txid, random_value]
# Example:
#   [
#     "a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2",
#     "6e4a2d190f7b"
#   ]
# SAVE BOTH — you need the random value (2nd element) for name_firstupdate.
# Wait for at least 12 confirmations (~2 hours) before proceeding.

# Finalize registration with the random value from name_new
namecoin-cli name_firstupdate "d/yourname" <random> '<json>'

# Update an existing name
namecoin-cli name_update "d/yourname" '<new_json>'

# Check a name's current value
namecoin-cli name_show "d/yourname"

# List your names
namecoin-cli name_list
Getting Namecoins via DVM (NIP-90)

Don't have NMC? You can acquire Namecoin through a Nostr-native exchange service — no centralized exchange account needed.

The NMC Exchange DVM is a NIP-90 Data Vending Machine that accepts Lightning Bitcoin (⚡ sats) or Cashu ecash (🥜) and sends NMC directly to your Namecoin address.

How it works:

Send a kind:5950 job request to the DVM with your NMC address and desired amount (0.2–0.5 NMC)

The DVM responds with a Lightning invoice or Cashu payment info

Pay via Lightning zap or Cashu ecash

Receive NMC at your designated address — the DVM sends the kind:6950 result with the NMC transaction ID

Rate: $10 USD per NMC (max 0.5 NMC per order)

Payment methods: Lightning Bitcoin ⚡ | Cashu ecash 🥜

DVM address (NIP-89):
naddr1qv…fjn5
View on NostrHub: NMC Exchange DVM

Example job request:
{
  "kind": 5950,
  "tags": [
    ["i", "<your-nmc-address>", "text"],
    ["param", "amount", "0.5"],
    ["bid", "10000000"]
  ],
  "content": ""
}
This is an experimental service — no guarantees of uptime, but it's a quick way to get NMC for name registrations without touching a centralized exchange.

Testing (for Developers)
# Run unit tests
./gradlew :quartz:jvmTest --tests "*NamecoinNameResolverTest*"

# Build and install debug APK
./gradlew assemblePlayDebug
adb install -r amethyst/build/outputs/apk/play/debug/amethyst-play-universal-debug.apk

# Monitor ElectrumX connections
adb root && adb shell tcpdump -i any -nn port 50002 or port 50006
Live Test Data

The name d/testls is registered on the Namecoin blockchain with value:
{"nostr": {"names": {"_": "6cdebccabda1dfa058ab85352a79509b592b2bdfa0370325e28ec1cb4f18667d"}}}
So _@testls.bit (or simply testls.bit) resolves to Vitor Pamplona's Nostr profile.

Search Input	What It Does
`alice@example.bit`	Looks up the `alice` entry in Namecoin name `d/example`
`example.bit`	Looks up the root (`_`) entry in `d/example`
`d/example`	Direct Namecoin domain namespace lookup (root entry)
`id/alice`	Direct Namecoin identity namespace lookup

Tor Setting	Primary Server	Fallback
Off	`electrumx.testls.space:50002`	`nmc2.bitcoins.sk:57002`
On	`.onion:50002` (hidden service)	`electrumx.testls.space:50002` (via Tor)

Server	Port	TLS	Notes
`electrumx.testls.space`	50002	Yes (self-signed, pinned)	Primary
`nmc2.bitcoins.sk`	57002	Yes (self-signed, pinned)	Fallback
`46.229.238.187`	57002	Yes (self-signed, pinned)	IP fallback

Test Query	Expected Result
`alice@yourname.bit`	Your profile (matched via `alice` entry)
`yourname.bit`	Your profile (matched via `_` root entry)
`d/yourname`	Your profile (direct namespace lookup)

User Input	Namecoin Name	Looked-Up Entry	Namespace
`alice@example.bit`	`d/example`	`alice`	Domain
`_@example.bit`	`d/example`	`_` (root)	Domain
`example.bit`	`d/example`	`_` (root)	Domain
`d/example`	`d/example`	`_` (root)	Domain
`id/alice`	`id/alice`	`_` (root)	Identity

The cypherpunk use case Satoshi envisioned for merged mining is more relevant now than ever.

Usage stats for .bit domains don't tell the whole story. ...

2026-04-08T08:24:06Z

In reply to nevent1q…7frf
_________________________

Usage stats for .bit domains don't tell the whole story. Namecoin's id/ namespace is where the interesting work is happening — human-readable identity anchored to a merge-mined blockchain with Bitcoin-class security.

We're building on it right now for Nostr reputation infrastructure:

quoting
naddr1qv…753t

How-To Guide: Namecoin Integration in Amethyst

What This Is

Amethyst — the Android Nostr client — includes built-in support for resolving Namecoin blockchain names as NIP-05 identities. Instead of relying on a web server to verify alice@example.com, a user can set their NIP-05 address to something like alice@example.bit, and Amethyst will verify it directly against the Namecoin blockchain via ElectrumX servers.

This is censorship-resistant identity: no web server to seize, no DNS to hijack, no TLS certificate to revoke. The name-to-pubkey mapping lives in Namecoin UTXOs.

This guide covers how the system works, how to use it as an end-user, and how to register or update a Namecoin name value so that it resolves to your Nostr pubkey.

Part 1: Using Namecoin Names in Amethyst (End-User)

Searching for Namecoin Users

Open Amethyst's search bar and type any of these formats:

Search Input What It Does

alice@example.bit Looks up the alice entry in Namecoin name d/example

example.bit Looks up the root (_) entry in d/example

d/example Direct Namecoin domain namespace lookup (root entry)

id/alice Direct Namecoin identity namespace lookup

Amethyst queries the Namecoin blockchain through an ElectrumX server, resolves the name to a Nostr public key, and shows the matching user profile at the top of search results. There is a 400ms debounce on the search input to avoid flooding the server with requests.

NIP-05 Verification via Namecoin

If a Nostr profile has a .bit address in its nip05 metadata field (e.g. m@testls.bit), Amethyst will automatically verify it against the blockchain instead of making an HTTP request. The verification badge works the same as traditional NIP-05 — the only difference is the trust anchor: blockchain consensus rather than a web server.

Configuring Namecoin Settings

Navigate to Settings → Namecoin Settings in Amethyst. From here you can:

Enable/disable Namecoin resolution entirely

Add custom ElectrumX servers — useful if you run your own server for privacy

Remove servers from the custom list

Test server connectivity — checks TLS, latency, and optionally resolves a test name

Pin TLS certificates — after testing a server with a self-signed cert, you can pin its certificate via TOFU (Trust On First Use)

Reset to defaults — reverts to the built-in server list

Server String Format

When adding a custom server, use the format:
host:port          → TLS connection (default)
host:port:tcp      → Plaintext TCP (for .onion or local servers)
Examples:
electrumx.testls.space:50002
my-local-server.lan:50001:tcp
i665jpw...dsid.onion:50002
Tor Integration

If you have Tor enabled in Amethyst and have set "NIP-05 verifications via Tor" to on, all Namecoin ElectrumX connections are routed through your Tor SOCKS proxy. The server list also switches to prioritize .onion addresses:

Tor Setting Primary Server Fallback

Off electrumx.testls.space:50002 nmc2.bitcoins.sk:57002

On .onion:50002 (hidden service) electrumx.testls.space:50002 (via Tor)

Toggling Tor on or off in settings takes effect on the next lookup — no app restart needed.

Default ElectrumX Servers

Amethyst ships with these built-in servers:

Server Port TLS Notes

electrumx.testls.space 50002 Yes (self-signed, pinned) Primary

nmc2.bitcoins.sk 57002 Yes (self-signed, pinned) Fallback

46.229.238.187 57002 Yes (self-signed, pinned) IP fallback

The self-signed certificates for these servers are pinned directly into the Amethyst binary, so connections succeed even on devices with strict TLS enforcement (Samsung One UI 7, GrapheneOS).

Part 2: Registering & Updating a Namecoin Name Value

Amethyst itself is a read-only consumer of Namecoin data — it resolves names but does not write to the blockchain. To register or update a Namecoin name so that it points to your Nostr pubkey, you need to interact with the Namecoin blockchain directly using Namecoin Core (the full node software) or a compatible wallet.

Prerequisites

Namecoin Core or Electrum-NMC installed and synced — download from namecoin.org (this guide uses Namecoin Core as an example)

NMC (Namecoin coins) in your wallet — needed to pay registration and update fees (0.01 NMC per registration operation plus associated fees)

Your Nostr hex public key — the 64-character hex string (not npub1...). You can find this in Amethyst under your profile settings or by converting your npub using a tool like https://nostrdeck.com/key-converter.php

Step 1: Choose Your Namespace

Amethyst supports two Namecoin namespaces:

Domain namespace (d/) — maps a domain-like name to one or more Nostr pubkeys. This is the most common choice and mirrors NIP-05's user@domain format.

Identity namespace (id/) — maps a personal identity name to a single Nostr pubkey.

For most users, the d/ namespace is the right choice because it allows user@name.bit style addresses.

Step 2: Register a New Name

Open a terminal and use namecoin-cli:
# Register a name in the domain namespace
# This creates a "pre-registration" (name_new) first
namecoin-cli name_new "d/yourname"
This returns a transaction ID and a random value. Save both — you need the random value for the next step. Wait for the transaction to get at least 12 confirmations (about 2 hours).

Then finalize the registration:
namecoin-cli name_firstupdate "d/yourname" <random_value> '<json_value>'
Step 3: Set the Name Value for Nostr

The JSON value you store in the Namecoin name is what Amethyst reads to find your Nostr pubkey. There are several supported formats.

Simple Form — Single User, Root Domain

If you just want yourname.bit to resolve to your pubkey:
{
  "nostr": "b0635d6a9851d3aed0cd6c495b282167acf761729078d975fc341b22650b07b9"
}
namecoin-cli name_firstupdate "d/yourname" <random> \
  '{"nostr":"b0635d6a9851d3aed0cd6c495b282167acf761729078d975fc341b22650b07b9"}'
This makes yourname.bit and _@yourname.bit resolve to the given pubkey.

Extended Form — Multiple Users with Relay Hints

If you want to host multiple identities under one .bit domain (like a NIP-05 server hosting multiple users):
{
  "nostr": {
    "names": {
      "_": "aaaa000000000000000000000000000000000000000000000000000000000001",
      "alice": "bbbb000000000000000000000000000000000000000000000000000000000002",
      "bob": "cccc000000000000000000000000000000000000000000000000000000000003"
    },
    "relays": {
      "bbbb000000000000000000000000000000000000000000000000000000000002": [
        "wss://relay.example.com",
        "wss://nos.lol"
      ]
    }
  }
}
With this value stored in d/yourname: - _@yourname.bit or yourname.bit → resolves to the _ pubkey - alice@yourname.bit → resolves to Alice's pubkey, with relay hints - bob@yourname.bit → resolves to Bob's pubkey
namecoin-cli name_firstupdate "d/yourname" <random> \
  '{"nostr":{"names":{"_":"aaaa...0001","alice":"bbbb...0002"},"relays":{"bbbb...0002":["wss://relay.example.com"]}}}'
Identity Namespace Form (id/)

For the id/ namespace, the value format is simpler:
{
  "nostr": "cccc000000000000000000000000000000000000000000000000000000000003"
}
Or with relay hints:
{
  "nostr": {
    "pubkey": "dddd000000000000000000000000000000000000000000000000000000000004",
    "relays": ["wss://relay.example.com"]
  }
}
namecoin-cli name_firstupdate "id/youridentity" <random> \
  '{"nostr":{"pubkey":"dddd...0004","relays":["wss://relay.example.com"]}}'
Step 4: Update an Existing Name

To change the Nostr pubkey (or any other data) associated with an already-registered name, use name_update:
namecoin-cli name_update "d/yourname" \
  '{"nostr":{"names":{"_":"<new_hex_pubkey>","alice":"<alice_hex_pubkey>"},"relays":{"<alice_hex_pubkey>":["wss://relay.example.com"]}}}'
This broadcasts a NAME_UPDATE transaction to the Namecoin blockchain. Once confirmed, Amethyst (and any other client that supports Namecoin NIP-05) will resolve the name to the new value.

Important notes on updates:

Each name_update costs a small NMC fee

Names expire after 36,000 blocks (~36 weeks) if not updated or renewed. Amethyst checks expiry and will treat expired names as non-existent.

To simply renew without changing the value, you can name_update with the same value

Updates replace the entire value — there is no partial update mechanism

Step 5: Set Your NIP-05 in Your Nostr Profile

Once your Namecoin name is registered and confirmed on the blockchain, update your Nostr profile's nip05 field in Amethyst:

Go to your profile → Edit

Set the NIP-05 field to your Namecoin address, e.g. alice@yourname.bit

Save

Amethyst (and other Namecoin-aware clients) will verify this address against the blockchain and show the verification badge.

Step 6: Verify It Works

In Amethyst's search bar, type your Namecoin identifier. You should see your profile appear at the top of results:

Test Query Expected Result

alice@yourname.bit Your profile (matched via alice entry)

yourname.bit Your profile (matched via _ root entry)

d/yourname Your profile (direct namespace lookup)

Part 3: How It Works Under the Hood

Resolution Flow

When Amethyst encounters a .bit address, here is what happens:
1. User types "alice@example.bit" in search (or a profile has it in nip05)

2. NamecoinNameResolver.parseIdentifier() parses it:
   → namecoinName = "d/example", localPart = "alice", namespace = DOMAIN

3. ElectrumXClient builds a canonical "name index script":
   OP_NAME_UPDATE(0x53) + push("d/example") + push("") + OP_2DROP + OP_DROP + OP_RETURN

4. Computes the Electrum-style scripthash:
   SHA-256(script) → reverse bytes → hex encode

5. Queries the ElectrumX server:
   → blockchain.scripthash.get_history(scripthash)
   ← [{tx_hash: "abc...", height: 814278}, ...]

6. Fetches the latest transaction (last entry = most recent name update):
   → blockchain.transaction.get(tx_hash, verbose=true)

7. Checks block headers to verify the name hasn't expired:
   → blockchain.headers.subscribe
   ← current height; if (current - update_height) >= 36000 → expired

8. Parses the NAME_UPDATE script from the transaction output:
   Extracts: name string + JSON value

9. NamecoinNameResolver.extractFromDomainValue() reads the JSON:
   Finds "nostr" → "names" → "alice" → hex pubkey

10. Returns NamecoinNostrResult(pubkey, relays, namecoinName, localPart)
Caching

Resolved names are cached in an LRU cache (default 500 entries, 1-hour TTL). Both positive and negative results are cached. The cache is keyed by the normalized (lowercased, trimmed) identifier.

Architecture Layers

The implementation is split across two modules:

Quartz (library, no Android dependencies): - NamecoinNameResolver — identifier parsing, value extraction, resolution orchestration - ElectrumXClient — TCP/TLS connection to ElectrumX, JSON-RPC, script parsing - NamecoinLookupCache — LRU cache with TTL - IElectrumXClient — interface for testing/mocking

Amethyst (Android app): - NamecoinNameService — application singleton, wires up caching and proxy-aware client - NamecoinSettings / NamecoinSharedPreferences — persistent config - NamecoinSettingsScreen / NamecoinSettingsSection — settings UI - ProxiedSocketFactory — SOCKS5 proxy routing for Tor - RoleBasedHttpClientBuilder.socketFactoryForNip05() — Tor-aware socket creation

The integration into NIP-05 is minimal: Nip05Client checks if an identifier matches .bit / d/ / id/ patterns, and routes to NamecoinNameResolver instead of making an HTTP fetch. Non-Namecoin identifiers are completely unaffected.

Part 4: Security Considerations

Tor integration — When enabled, all ElectrumX connections go through the Tor SOCKS proxy. The .onion server is preferred for end-to-end onion routing. Socket factory and server list are evaluated per-request via lambdas, so toggling Tor takes effect immediately.

TLS certificate pinning — The primary ElectrumX servers use self-signed certificates. Their PEM-encoded certs are pinned in the Amethyst binary. Users can pin additional certs via the TOFU flow in settings (test server → view fingerprint → confirm → pin). This is necessary because Samsung One UI 7 and GrapheneOS reject trust-all TrustManagers.

Name expiry — Namecoin names expire after ~36,000 blocks (~250 days) if not renewed. The ElectrumX client checks the current block height against the name's last update height and treats expired names as non-existent.

Server trust — The client trusts that the ElectrumX server returns accurate transaction data. The Namecoin blockchain itself is the trust anchor — a MITM could return stale data but cannot forge name registrations. For higher assurance, SPV proof verification could be added in the future.

Quick Reference

Identifier Format Summary

User Input Namecoin Name Looked-Up Entry Namespace

alice@example.bit d/example alice Domain

_@example.bit d/example _ (root) Domain

example.bit d/example _ (root) Domain

d/example d/example _ (root) Domain

id/alice id/alice _ (root) Identity

Name Value JSON Formats

Domain simple:
{"nostr": "<64-char-hex-pubkey>"}
Domain extended (multi-user + relays):
{"nostr": {"names": {"_": "<hex>", "alice": "<hex>"}, "relays": {"<hex>": ["wss://..."]}}}
Identity simple:
{"nostr": "<64-char-hex-pubkey>"}
Identity with relays:
{"nostr": {"pubkey": "<hex>", "relays": ["wss://..."]}}
Namecoin CLI Commands
# Register a new name
namecoin-cli name_new "d/yourname"
# Returns: [txid, random_value]
# Example:
#   [
#     "a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2",
#     "6e4a2d190f7b"
#   ]
# SAVE BOTH — you need the random value (2nd element) for name_firstupdate.
# Wait for at least 12 confirmations (~2 hours) before proceeding.

# Finalize registration with the random value from name_new
namecoin-cli name_firstupdate "d/yourname" <random> '<json>'

# Update an existing name
namecoin-cli name_update "d/yourname" '<new_json>'

# Check a name's current value
namecoin-cli name_show "d/yourname"

# List your names
namecoin-cli name_list
Getting Namecoins via DVM (NIP-90)

Don't have NMC? You can acquire Namecoin through a Nostr-native exchange service — no centralized exchange account needed.

The NMC Exchange DVM is a NIP-90 Data Vending Machine that accepts Lightning Bitcoin (⚡ sats) or Cashu ecash (🥜) and sends NMC directly to your Namecoin address.

How it works:

Send a kind:5950 job request to the DVM with your NMC address and desired amount (0.2–0.5 NMC)

The DVM responds with a Lightning invoice or Cashu payment info

Pay via Lightning zap or Cashu ecash

Receive NMC at your designated address — the DVM sends the kind:6950 result with the NMC transaction ID

Rate: $10 USD per NMC (max 0.5 NMC per order)

Payment methods: Lightning Bitcoin ⚡ | Cashu ecash 🥜

DVM address (NIP-89):
naddr1qv…fjn5
View on NostrHub: NMC Exchange DVM

Example job request:
{
  "kind": 5950,
  "tags": [
    ["i", "<your-nmc-address>", "text"],
    ["param", "amount", "0.5"],
    ["bid", "10000000"]
  ],
  "content": ""
}
This is an experimental service — no guarantees of uptime, but it's a quick way to get NMC for name registrations without touching a centralized exchange.

Testing (for Developers)
# Run unit tests
./gradlew :quartz:jvmTest --tests "*NamecoinNameResolverTest*"

# Build and install debug APK
./gradlew assemblePlayDebug
adb install -r amethyst/build/outputs/apk/play/debug/amethyst-play-universal-debug.apk

# Monitor ElectrumX connections
adb root && adb shell tcpdump -i any -nn port 50002 or port 50006
Live Test Data

The name d/testls is registered on the Namecoin blockchain with value:
{"nostr": {"names": {"_": "6cdebccabda1dfa058ab85352a79509b592b2bdfa0370325e28ec1cb4f18667d"}}}
So _@testls.bit (or simply testls.bit) resolves to Vitor Pamplona's Nostr profile.

Nostr notes by mstrofnone

Thanks for the detailed review — this is genuinely useful ...

@npub1gcx…nj5z @npub15qy…yejr — a modest proposal about ...

@npub1gcx…nj5z @npub15qy…yejr — a modest proposal about ...

@npub1gcx…nj5z @npub15qy…yejr — a modest proposal about ...

@npub1gcx…nj5z @npub15qy…yejr — a modest proposal about ...

@npub15qy…yejr do you know anything about this bot? ...

4× kind:30817 events on damus.io + primal.net + ditto.pub. ...

## Local CI-parity run vs current upstream main Verified this PR ...

## Local CI-parity run vs current upstream main Verified this PR ...

## Local CI-parity run vs current upstream main Verified this PR ...

Nostr event nevent1qqs96unl0u49dcp5mclk32qevrh048gujljze9yyc7j2ju0exl62glgzypp3shk7edn43y5zfvdr0ftl8eq8l00zaknjqx3c9xuv7ja8ck60q6evly5

📡 How to use relay.testls.bit — a Namecoin .bit-gated Nostr ...

📡 How to use relay.testls.bit — a Namecoin .bit-gated Nostr ...

A free-software Namecoin explorer is now live for nostriches to ...

A free-software Namecoin explorer is now live for nostriches to ...

A free-software Namecoin explorer is now live for nostriches to ...

A free-software Namecoin explorer is now live for nostriches to ...

📡 How to use relay.testls.bit — a Namecoin .bit-gated Nostr ...

📡 How to use relay.testls.bit — a Namecoin .bit-gated Nostr ...

Nostr event nevent1qqsrr5rs0gh8vql0u9uagvzmv2v5se43xav7gzd733r643yd0g0ntdgzypp3shk7edn43y5zfvdr0ftl8eq8l00zaknjqx3c9xuv7ja8ck60qz3k2yw

Nostr event nevent1qqsz3lk6vf4vcjfgzvw3eqgt5vd5c5hu7fn567wp36xxmla67hk533czypp3shk7edn43y5zfvdr0ftl8eq8l00zaknjqx3c9xuv7ja8ck60qgn0n9u

Nostr event nevent1qqs0eqa96hvwgkqat98snjx2wtua8ym65mhdw8zxsuw2pq42kl0kc0gzypp3shk7edn43y5zfvdr0ftl8eq8l00zaknjqx3c9xuv7ja8ck60q5wk2cw

follow-up patch adds WebSocket (WSS) transport — enables ...

@npub180c…h6w6 re https://github.com/fiatjaf/nak/pull/123 — ...

This is spot on. Satoshi saw merged mining as the way to ...

How-To Guide: Namecoin Integration in Amethyst

What This Is

Part 1: Using Namecoin Names in Amethyst (End-User)

Searching for Namecoin Users

NIP-05 Verification via Namecoin

Configuring Namecoin Settings

Server String Format

Tor Integration

Default ElectrumX Servers

Part 2: Registering & Updating a Namecoin Name Value

Prerequisites

Step 1: Choose Your Namespace

Step 2: Register a New Name

Step 3: Set the Name Value for Nostr

Simple Form — Single User, Root Domain

Extended Form — Multiple Users with Relay Hints

Identity Namespace Form (id/)

Step 4: Update an Existing Name

Step 5: Set Your NIP-05 in Your Nostr Profile

Step 6: Verify It Works

Part 3: How It Works Under the Hood

Resolution Flow

Caching

Architecture Layers

Part 4: Security Considerations

Quick Reference

Identifier Format Summary

Name Value JSON Formats

Namecoin CLI Commands

Getting Namecoins via DVM (NIP-90)

Testing (for Developers)

Live Test Data

Usage stats for .bit domains don't tell the whole story. ...

How-To Guide: Namecoin Integration in Amethyst

What This Is

Part 1: Using Namecoin Names in Amethyst (End-User)

Searching for Namecoin Users

NIP-05 Verification via Namecoin

Configuring Namecoin Settings

Server String Format

Tor Integration

Default ElectrumX Servers

Part 2: Registering & Updating a Namecoin Name Value

Prerequisites

Step 1: Choose Your Namespace

Step 2: Register a New Name

Step 3: Set the Name Value for Nostr

Simple Form — Single User, Root Domain

Extended Form — Multiple Users with Relay Hints

Identity Namespace Form (id/)

Step 4: Update an Existing Name

Step 5: Set Your NIP-05 in Your Nostr Profile

Step 6: Verify It Works

Part 3: How It Works Under the Hood

Identity Namespace Form (`id/`)

Identity Namespace Form (`id/`)

Identity Namespace Form (`id/`)

Identity Namespace Form (`id/`)