I am not thinking anything. Simply stating a fact. The produ...

Brunswick

npub1c856kwjk524kef97hazw5e9jlkjq4333r6yxh2rtgefpd894ddpsmq6lkc

hex

89bac1550f29c98532d11dd37c8314fecb3a4ed0e31c6c8a978e18e6d517256c

nevent

nevent1qqsgnwkp258jnjv9xtg3m5musv20aje6fmgwx8rv32tcux8x65tj2mqprpmhxue69uhhyetvv9ujuem4d36kwatvw5hx6mm9qgsvr6dt8ft292mv5jlt7382vje0mfq2ccc3azrt4p45v5sknj6kksczx3gq6

Kind-1 (TextNote)

2026-07-31T14:41:09Z

↳ Reply to node (npub1rzg96zjavgatsx5ch2vvtq4atatly5rvdwqgjp0utxw45zeznvyqfdkxve)

You think it was done on purpose? What would be the goal?

I am not thinking anything. Simply stating a fact. The product design required trust in the developer and the company. Granted, very little, but still some. This randomness issue should have been a central focus of the dev, and if it couldn't be proven, the feature should have been removed. This is evidence of architectural failure. Whether flaws were designed-in to be exploited at some plausibly deniable distance-in-time, or if they were pure mistakes, still shows an architectural failure in the system and design goals.

A product like this should retain zero "trust me bro" in the design. I was never comfortable with recommending it to friends and family. When they would ask about it, I would say "I'm not sure, but it looks like a good option". Never would I saw "This is provably secure with generating and storing your keys". There were too many unaddressed concerns, where there should have been none. I treated them as newbie devices.

When you pile on the pattern of behavior of the developer when confronted with criticism, that adds to the concern.

Now that a bug has been exposed that, from a design perspective, in my opinion should have been left out as a feature because of pure uncertainty around lack of audit, the evidence points to the direction that coinkite's judgment should be questioned and treated adversarially. This should have already been understood even without evidence to the effect. One should always verify and not trust. When you cannot verify, then your alternative is still not to trust. Your alternative is to find a way to eliminate trust.

I'd like to know why people should entertain less secure alternatives as a replacement when there is nostr:nprofile1qqs09jtvjlmyrxjn37zv70a89csegcz7rpyqjmnw29cveedhv7vagqqpzemhxue69uhk2er9dchxummnw3ezumrpdejz7qg4waehxw309aex2mrp0yhxgctdw4eju6t09uq3zamnwvaz7tmwdaehgu3wwa5kuef0x9u2rf

Raw JSON

{
  "kind": 1,
  "id": "89bac1550f29c98532d11dd37c8314fecb3a4ed0e31c6c8a978e18e6d517256c",
  "pubkey": "c1e9ab3a56a2ab6ca4bebf44ea64b2fda40ac6311e886ba86b4652169cb56b43",
  "created_at": 1785508869,
  "tags": [
    [
      "alt",
      "A short note: I am not thinking anything. Simply stating a fact...."
    ],
    [
      "e",
      "e1347e6c24f34239e033b58d5670cfafe289caeb15ccdacee7af7daa2ecbdca9",
      "wss://nostr.wine/",
      "root",
      "18905d0a5d623ab81a98ba98c582bd5f57f2506c6b808905fc599d5a0b229b08"
    ],
    [
      "e",
      "7c615aa5e3d85bd62e0f2dec074fe0f7b079bdd749f3df09fe4209258799aac6",
      "ws://oxtrdevav64z64yb7x6rjg4ntzqjhedm5b5zjqulugknhzr46ny2qbad.onion/",
      "",
      "c1e9ab3a56a2ab6ca4bebf44ea64b2fda40ac6311e886ba86b4652169cb56b43"
    ],
    [
      "e",
      "2dcdcba7d9972146e0258710fda4c0a698f5887d405d72628b9c98160f476fd7",
      "wss://nostr.land/",
      "reply",
      "18905d0a5d623ab81a98ba98c582bd5f57f2506c6b808905fc599d5a0b229b08"
    ],
    [
      "p",
      "18905d0a5d623ab81a98ba98c582bd5f57f2506c6b808905fc599d5a0b229b08",
      "wss://nos.lol/"
    ],
    [
      "p",
      "c1e9ab3a56a2ab6ca4bebf44ea64b2fda40ac6311e886ba86b4652169cb56b43",
      "wss://nos.lol/"
    ],
    [
      "p",
      "f2c96c97f6419a538f84cf3fa72e2194605e1848096e6e5170cce5b76799d400",
      "wss://eden.nostr.land/"
    ],
    [
      "client",
      "Amethyst"
    ]
  ],
  "content": "I am not thinking anything. Simply stating a fact. The product design required trust in the developer and the company. Granted, very little, but still some. This randomness issue should have been a central focus of the dev, and if it couldn't be proven, the feature should have been removed. This is evidence of architectural failure. Whether flaws were designed-in to be exploited at some plausibly deniable distance-in-time, or if they were pure mistakes, still shows an architectural failure in the system and design goals. \n\nA product like this should retain zero \"trust me bro\" in the design. I was never comfortable with recommending it to friends and family. When they would ask about it, I would say \"I'm not sure, but it looks like a good option\". Never would I saw \"This is provably secure with generating and storing your keys\". There were too many unaddressed concerns, where there should have been none. I treated them as newbie devices.\n\nWhen you pile on the pattern of behavior of the developer when confronted with criticism, that adds to the concern.\n\nNow that a bug has been exposed that, from a design perspective, in my opinion should have been left out as a feature because of pure uncertainty around lack of audit, the evidence points to the direction that coinkite's judgment should be questioned and treated adversarially. This should have already been understood even without evidence to the effect. One should always verify and not trust. When you cannot verify, then your alternative is still not to trust. Your alternative is to find a way to eliminate trust. \n\nI'd like to know why people should entertain less secure alternatives as a replacement when there is nostr:nprofile1qqs09jtvjlmyrxjn37zv70a89csegcz7rpyqjmnw29cveedhv7vagqqpzemhxue69uhk2er9dchxummnw3ezumrpdejz7qg4waehxw309aex2mrp0yhxgctdw4eju6t09uq3zamnwvaz7tmwdaehgu3wwa5kuef0x9u2rf ",
  "sig": "1c02a83c57d7d487ff5869e30a26b9c242340eb5603d9f1eaf6292f60f82ad47dfffdf898381c810ea45335168a7343476a1a448d87d24b32873a2dd6f20a9e9"
}