I actually noticed that with nak --- it isn't showing proof-...

inkan

npub16xnpfx85k8wzdhctang6860g3u64lds5kac73ddjwlg0lxdg9g3su56z6l

hex

479fd6f58946b32d5442470ea251fd1db939bafcbcc3434cd23bfe74a6b3a6f2

nevent

nevent1qqsy087k7ky5dved23pywr4z2873mwfeht7tes6rfnfrhln556e6dusprpmhxue69uhhyetvv9ujuem4d36kwatvw5hx6mm9qgsdrfs5nr6trhpxmu97e5dra85g7d2lkc2twu0gkke8058lnx5z5gcywp8jc

Kind-1 (TextNote)

2026-06-07T17:40:00Z

↳ Reply to Event not found

624d673803ddb1667888abe79bbfc5856c57dbd0b25acb1a72401ecd377fd96b...

I actually noticed that with nak --- it isn't showing proof-carrying events returned from my inkan relay. When I get a chance I'll fix up my own version of nak to work with these.

When working through this, I noticed that there are two issues that can be thought of separately:

  1. disseminating OTS proofs to relays;
  2. making the proofs available to clients.

For proof dissemination, any sensible Nostr event shape will work. I think an addressable event with lots of tags for indexing (which can be skipped when not needed) works best, I've been sticking with my 31045s so far.

For making the proofs available to clients, the crucial thing is that the client needs to get the proofs synchronously with the reference event, i.e. the proofs should basically be spliced into the reference event.

So on that picture, the basic role that relays should play is to collect up available proofs and pre-verify them, select the best one (i.e. the one with the lowest block height) for each reference event, and then splice it into the reference event when it's sent to the client.

Is my current thinking.

Raw JSON

{
  "kind": 1,
  "id": "479fd6f58946b32d5442470ea251fd1db939bafcbcc3434cd23bfe74a6b3a6f2",
  "pubkey": "d1a61498f4b1dc26df0becd1a3e9e88f355fb614b771e8b5b277d0ff99a82a23",
  "created_at": 1780854000,
  "tags": [
    [
      "e",
      "3112043f4340558caf037893ccc95861aa421c3af9ef3c0076703e622610c57e",
      "wss://relay.primal.net/",
      "root",
      "5ea4648045bb1ff222655ddd36e6dceddc43590c26090c486bef38ef450da5bd"
    ],
    [
      "e",
      "624d673803ddb1667888abe79bbfc5856c57dbd0b25acb1a72401ecd377fd96b",
      "wss://relay.primal.net/",
      "reply",
      "5ea4648045bb1ff222655ddd36e6dceddc43590c26090c486bef38ef450da5bd"
    ],
    [
      "p",
      "3bf0c63fcb93463407af97a5e5ee64fa883d107ef9e558472c4eb9aaaefa459d"
    ],
    [
      "p",
      "e2ccf7cf20403f3f2a4a55b328f0de3be38558a7d5f33632fdaaefc726c1c8eb"
    ],
    [
      "p",
      "460c25e682fda7832b52d1f22d3d22b3176d972f60dcdc3212ed8c92ef85065c"
    ],
    [
      "p",
      "5ea4648045bb1ff222655ddd36e6dceddc43590c26090c486bef38ef450da5bd"
    ]
  ],
  "content": "I actually noticed that with nak --- it isn't showing proof-carrying events returned from my inkan relay. When I get a chance I'll fix up my own version of nak to work with these.\n\nWhen working through this, I noticed that there are two issues that can be thought of separately:\n\n1. disseminating OTS proofs to relays;\n2. making the proofs available to clients.\n\nFor proof dissemination, any sensible Nostr event shape will work. I think an addressable event with lots of tags for indexing (which can be skipped when not needed) works best, I've been sticking with my 31045s so far.\n\nFor making the proofs available to clients, the crucial thing is that the client needs to get the proofs synchronously with the reference event, i.e. the proofs should basically be spliced into the reference event.\n\nSo on that picture, the basic role that relays should play is to collect up available proofs and pre-verify them, select the best one (i.e. the one with the lowest block height) for each reference event, and then splice it into the reference event when it's sent to the client.\n\nIs my current thinking.",
  "sig": "f5c40922222d7182d555995f7f61b7a91e48670383d317a76ec0a9b5fcb3751a1775341b6205c2460302e074946bc19cfb76a44755198e85327d5d5fc155f5fb"
}