Function is not broken, you might have to wait a while, it d...

Constant

npub1t6jxfqz9hv0lygn9thwndekuahwyxkgvycyscjrtauuw73gd5k7sqvksrw

hex

f424a1a30c819aad5d1e1b9139242b0aad6904774fe801571e6b2a278636c0ad

nevent

nevent1qqs0gf9p5vxgrx4dt50phyfeys4s4ttfq3m5l6qp2u0xk238scmvptgprpmhxue69uhhyetvv9ujuem4d36kwatvw5hx6mm9qgs9afryspzmk8ljyfj4mhfkumwwmhzrtyxzvzgvfp477w80g5x6t0g2d7x9k

Kind-1 (TextNote)

2026-04-03T22:02:32Z

↳ Reply to Yojimble (npub1me67k8t6vcncq75dlu8mxd70euvful56lz4ky20k3rmxgugvxq2qy23gnm)

Amazing thank you 🤗 nostr:nprofile1qqs24yz8xftq8kkdf7q5yzf4v7tn2ek78v0zp2y427mj3sa7f34ggjcpzamhxue69uhhv6t5daezumn0wd68yvfwvdhk6tcpzpmhxue69uhkummnw3e...

Function is not broken, you might have to wait a while, it depends on how often the timestamp-server decides to do a bitcoin transaction, which i think is only a couple of times a day. In general, this type of timestamping is not suited for minute/hour timescale stuff anyway, more on the level of multiple hours/day basis

NIP-03 itself is broken, but thats for a different reason entirely. When designing the standard, it did not occur to us that in Nostr, you sign the event-ID of an event. Because the current standard timestamps that event-ID, you technically don't know when something was signed, someone could have actually signed it after the fact.

This, in theory, could lead to some weird exploit. Lets say i am planning to steal your keys. I could start creating all kind of events in your name today, and timestamp them, even though i am not able to sign them yet. Then later, when i successfully stole your keys, i could sign those messages after the fact, and then from the outside worlds perspective, those seem like legitimate timestamped events that you posted before your keys got compromised; which would undermine the entire purpose of it all.

The fix is not that difficult, but its annoying we will have to deprecate the current standard blablabla etc.

Raw JSON

{
  "kind": 1,
  "id": "f424a1a30c819aad5d1e1b9139242b0aad6904774fe801571e6b2a278636c0ad",
  "pubkey": "5ea4648045bb1ff222655ddd36e6dceddc43590c26090c486bef38ef450da5bd",
  "created_at": 1775253752,
  "tags": [
    [
      "e",
      "4aeca31cd02743d474a35bb34125bb3e8ecf4c36f641dd7904ed618536e39e30",
      "wss://nos.lol/",
      "root",
      "de75eb1d7a6627807a8dff0fb337cfcf189e7e9af8ab6229f688f664710c3014"
    ],
    [
      "e",
      "0adef530603dbf8214bd0e3ef2b9377d7180681f6d6a5c04a1e15a90706942d6",
      "wss://relay.primal.net/",
      "reply",
      "de75eb1d7a6627807a8dff0fb337cfcf189e7e9af8ab6229f688f664710c3014"
    ],
    [
      "p",
      "aa9047325603dacd4f8142093567973566de3b1e20a89557b728c3be4c6a844b"
    ],
    [
      "p",
      "de75eb1d7a6627807a8dff0fb337cfcf189e7e9af8ab6229f688f664710c3014"
    ]
  ],
  "content": "Function is not broken, you might have to wait a while, it depends on how often the timestamp-server decides to do a bitcoin transaction, which i think is only a couple of times a day. In general, this type of timestamping is not suited for minute/hour timescale stuff anyway, more on the level of multiple hours/day basis\n\nNIP-03 itself is broken, but thats for a different reason entirely. When designing the standard, it did not occur to us that in Nostr, you sign the event-ID of an event. Because the current standard timestamps that event-ID, you technically don't know when something was signed, someone could have actually signed it after the fact.\n\nThis, in theory, could lead to some weird exploit. Lets say i am planning to steal your keys. I could start creating all kind of events in your name today, and timestamp them, even though i am not able to sign them yet.\nThen later, when i successfully stole your keys, i could sign those messages after the fact, and then from the outside worlds perspective, those seem like legitimate timestamped events that you posted before your keys got compromised; which would undermine the entire purpose of it all.\n\nThe fix is not that difficult, but its annoying we will have to deprecate the current standard blablabla etc.",
  "sig": "0463afe869f93565c346dc97b397a52cf3bfcb8dc9546297090cb1416772012ed2bc191c4b590bf197f6768ef3a6e2a8e00286727381cb20aefa0935af7a5990"
}