Thanks. I took a look at nip-32 / 1985 events. I think these...

inkan

npub16xnpfx85k8wzdhctang6860g3u64lds5kac73ddjwlg0lxdg9g3su56z6l

hex

20bb2160a01a40a6b4071f3ac8b8ac169b67b106bb9a6f26ec03b76ea24fd2f0

nevent

nevent1qqszpwepvzsp5s9xksr37wkghzkpdxm8kyrthxn0ymkq8dmw5f8a9uqprpmhxue69uhhyetvv9ujuem4d36kwatvw5hx6mm9qgsdrfs5nr6trhpxmu97e5dra85g7d2lkc2twu0gkke8058lnx5z5gc8txdhw

Kind-1 (TextNote)

2026-06-17T13:55:57Z

↳ Reply to Event not found

c425339718eae86c72417bd2ea8c1afc6331bcfd76768c6eeefe8d2d57fb65d5...

Thanks. I took a look at nip-32 / 1985 events. I think these won't work here unfortunately. The problem is that the 1985 event is a separate event that points to the target event with an e-tag, and the 1985 event doesn't automatically travel with the target event. The client has to correlate the 1985 with the target event and fetch the 1985 separately. I tried OTS implementations of this kind when I initially experimented with OTS and it doesn't work well. The OTS proof arrives asynchronously, so trying to filter out events that don't have valid OTS timestamps leads to lags and blocking on the client side.

What's needed is for relays to splice the OTS timestamp into the target event itself, so the client gets the proof simultaneously with the event and can filter out events that don't have a valid timestamp immediately when they arrive. The OTS proof can be thought of as playing a similar role to the signature on the event. One wouldn't want to send the signatures separately from the events to which they pertain.

As for the use case, OTS is a crucial component of key rotation systems. Without OTS, it's not possible to hold a cold storage identity and revoke and replace Nostr keys that have been leaked or lost, but with OTS it's possible. See below for an implementation and more detailed explanation.

nostr:nevent1qvzqqqqqqypzp5dxzjv0fvwuym0shmx350573re4t7mpfdm3az6mya7sl7v6s23rqyfhwumn8ghj7mmxve3ksctfdch8qatz9uq3zamnwvaz7tmwdaehgu3wwa5kuef0qqsq3hz3nqj5gu26x3akqjepxcvznnp2fst0h5kmeukuqu7ms4apwsqsuwagr

nostr:nevent1qvzqqqqqqypzp5dxzjv0fvwuym0shmx350573re4t7mpfdm3az6mya7sl7v6s23rqyghwumn8ghj7mn0wd68ytnhd9hx2tcppemhxue69uhkummn9ekx7mp0qqs8z5jezmes2fxl8cm89uza098hhnkhusfc3zc0p7agvlmkpwc4ehgy4x497

Raw JSON

{
  "kind": 1,
  "id": "20bb2160a01a40a6b4071f3ac8b8ac169b67b106bb9a6f26ec03b76ea24fd2f0",
  "pubkey": "d1a61498f4b1dc26df0becd1a3e9e88f355fb614b771e8b5b277d0ff99a82a23",
  "created_at": 1781704557,
  "tags": [
    [
      "q",
      "08dc51982544715a347b604b21361829cc2a4c16fbd2dbcf2dc073db857a1740",
      "wss://offchain.pub/",
      "d1a61498f4b1dc26df0becd1a3e9e88f355fb614b771e8b5b277d0ff99a82a23"
    ],
    [
      "q",
      "71525916f30524df3e3672f05d794f7bced7e413888b0f0fba867f760bb15cdd",
      "wss://nostr.wine/",
      "d1a61498f4b1dc26df0becd1a3e9e88f355fb614b771e8b5b277d0ff99a82a23"
    ],
    [
      "e",
      "147c078b7f43ad8b4bfc9824acd774ae310e97d52487f2c72a33707ed65394a5",
      "wss://nostr.wine/",
      "root",
      "d1a61498f4b1dc26df0becd1a3e9e88f355fb614b771e8b5b277d0ff99a82a23"
    ],
    [
      "e",
      "c425339718eae86c72417bd2ea8c1afc6331bcfd76768c6eeefe8d2d57fb65d5",
      "wss://nostr.wine/",
      "reply",
      "9fec72d579baaa772af9e71e638b529215721ace6e0f8320725ecbf9f77f85b1"
    ],
    [
      "p",
      "9fec72d579baaa772af9e71e638b529215721ace6e0f8320725ecbf9f77f85b1"
    ]
  ],
  "content": "Thanks. I took a look at nip-32 / 1985 events. I think these won't work here unfortunately. The problem is that the 1985 event is a separate event that points to the target event with an e-tag, and the 1985 event doesn't automatically travel with the target event. The client has to correlate the 1985 with the target event and fetch the 1985 separately. I tried OTS implementations of this kind when I initially experimented with OTS and it doesn't work well. The OTS proof arrives asynchronously, so trying to filter out events that don't have valid OTS timestamps leads to lags and blocking on the client side.\n\nWhat's needed is for relays to splice the OTS timestamp into the target event itself, so the client gets the proof simultaneously with the event and can filter out events that don't have a valid timestamp immediately when they arrive. The OTS proof can be thought of as playing a similar role to the signature on the event. One wouldn't want to send the signatures separately from the events to which they pertain.\n\nAs for the use case, OTS is a crucial component of key rotation systems. Without OTS, it's not possible to hold a cold storage identity and revoke and replace Nostr keys that have been leaked or lost, but with OTS it's possible. See below for an implementation and more detailed explanation.\n\n\nnostr:nevent1qvzqqqqqqypzp5dxzjv0fvwuym0shmx350573re4t7mpfdm3az6mya7sl7v6s23rqyfhwumn8ghj7mmxve3ksctfdch8qatz9uq3zamnwvaz7tmwdaehgu3wwa5kuef0qqsq3hz3nqj5gu26x3akqjepxcvznnp2fst0h5kmeukuqu7ms4apwsqsuwagr\n\n\nnostr:nevent1qvzqqqqqqypzp5dxzjv0fvwuym0shmx350573re4t7mpfdm3az6mya7sl7v6s23rqyghwumn8ghj7mn0wd68ytnhd9hx2tcppemhxue69uhkummn9ekx7mp0qqs8z5jezmes2fxl8cm89uza098hhnkhusfc3zc0p7agvlmkpwc4ehgy4x497",
  "sig": "fc77a9682a2fd17076bc77c5b17056f17d63b752cfddc4f7e87bbdf08c33c7b9e8bc9aa5da9c78bce0ceb0e140c040e5cea87af01f280932dc19fd40659ce103"
}