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

@Vitor Pamplona @npub15qyd...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: View quoted note → View quoted note → 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:

gitworkshop - Decentralized Git

Decentralized GitHub alternative over Nostr for browsing repositories, managing issues, and collaborating on pull requests.

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.

@Vitor Pamplona @npub15qyd...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: View quoted note → View quoted note → 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:

gitworkshop - Decentralized Git

Decentralized GitHub alternative over Nostr for browsing repositories, managing issues, and collaborating on pull requests.

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.

@Vitor Pamplona @npub15qyd...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: View quoted note → View quoted note → 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:

gitworkshop - Decentralized Git

Decentralized GitHub alternative over Nostr for browsing repositories, managing issues, and collaborating on pull requests.

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.

@npub15qyd...yejr do you know anything about this bot? @npub1zq3x...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).

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

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

📡 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

Download

Write an awesome description for your new site here. You can edit this line in _config.yml. It will appear in your document head meta (for Google s...

to figure out how to resolve on your OS or in your browser #namecoin #nostr #cypherpunk #dotbit

📡 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

hello gated .bit world from Amethyst round2

hello gated .bit world from _@mstrofnone.bit

hello gated .bit world