The s-tag is for the signature of the reference event.

npub16xnpfx85k8wzdhctang6860g3u64lds5kac73ddjwlg0lxdg9g3su56z6l
hex
692dd1994cd7b639bc2493a75241065e7c9762e6bde6eae473d096fb369a1b7fnevent
nevent1qqsxjtw3n9xd0d3ehsjf8f6jgyr9ulyhvtntmeh2u3eap9hmx6dpklcprpmhxue69uhhyetvv9ujuem4d36kwatvw5hx6mm9qgsdrfs5nr6trhpxmu97e5dra85g7d2lkc2twu0gkke8058lnx5z5gcrnauv9Kind-1 (TextNote)
↳ 回复 semisol (npub12262qa4uhw7u8gdwlgmntqtv7aye8vdcmvszkqwgs0zchel6mz7s6cgrkj)
Nostr.land is planning to support OTS. I’m planning to use the standard OTS spec that is already well-implemented. “Inline” proofs is not something I...
The s-tag is for the signature of the reference event.
Just to be sure, when you refer to the "standard OTS spec," I hope you don't mean the old broken NIP-03 where the item that gets timestamped only includes the event_id and does not include the signature (see below for some discussion of this).
Also, I think splicing the OTS proof into the event that gets returned by the relay is essential so that clients get proof simultaneously with the event. I think that's precisely the role that relays need to play because it's a huge pain for a client to have to fetch an OTS event separately when trying to filter out events that don't have a valid OTS proof.
I guess I find AI-written specs useful. They are both human-readable and can be fed to an AI to get oriented in the project without skipping too much detail. Also, the proposed modifications to the relay were made by an AI and the AI has a better grasp of the details.
nostr:nevent1qvzqqqqqqypzp5dxzjv0fvwuym0shmx350573re4t7mpfdm3az6mya7sl7v6s23rqy88wumn8ghj7mn0wvhxcmmv9uq3zamnwvaz7tmwdaehgu3wwa5kuef0qqswcddwu7u68mmlfkv29gy3q2yv08vddf2wzw7lgxn3a54g83q3z8ct2h6vq
原始 JSON
{
"kind": 1,
"id": "692dd1994cd7b639bc2493a75241065e7c9762e6bde6eae473d096fb369a1b7f",
"pubkey": "d1a61498f4b1dc26df0becd1a3e9e88f355fb614b771e8b5b277d0ff99a82a23",
"created_at": 1781188035,
"tags": [
[
"q",
"ec35aee7b9a3ef7f4d98a2a0910288c79d8d6a54e13bdf41a71ed2a83c41111f",
"wss://nos.lol/",
"d1a61498f4b1dc26df0becd1a3e9e88f355fb614b771e8b5b277d0ff99a82a23"
],
[
"e",
"81ecd99b80ec128c2e22bdf566062f43995985ae5eb9a987d65f857184a6e121",
"wss://nostr.wine/",
"root",
"d1a61498f4b1dc26df0becd1a3e9e88f355fb614b771e8b5b277d0ff99a82a23"
],
[
"e",
"c4bc4c004ff856eae55faeb200fb57e6dc3be2df814c89fcc2ac1620a9b7f902",
"wss://nos.lol/",
"reply",
"52b4a076bcbbbdc3a1aefa3735816cf74993b1b8db202b01c883c58be7fad8bd"
],
[
"p",
"32e1827635450ebb3c5a7d12c1f8e7b2b514439ac10a67eef3d9fd9c5c68e245"
],
[
"p",
"52b4a076bcbbbdc3a1aefa3735816cf74993b1b8db202b01c883c58be7fad8bd"
]
],
"content": "The s-tag is for the signature of the reference event.\n\nJust to be sure, when you refer to the \"standard OTS spec,\" I hope you don't mean the old broken NIP-03 where the item that gets timestamped only includes the event_id and does not include the signature (see below for some discussion of this).\n\nAlso, I think splicing the OTS proof into the event that gets returned by the relay is essential so that clients get proof simultaneously with the event. I think that's precisely the role that relays need to play because it's a huge pain for a client to have to fetch an OTS event separately when trying to filter out events that don't have a valid OTS proof.\n\nI guess I find AI-written specs useful. They are both human-readable and can be fed to an AI to get oriented in the project without skipping too much detail. Also, the proposed modifications to the relay were made by an AI and the AI has a better grasp of the details.\n\n\nnostr:nevent1qvzqqqqqqypzp5dxzjv0fvwuym0shmx350573re4t7mpfdm3az6mya7sl7v6s23rqy88wumn8ghj7mn0wvhxcmmv9uq3zamnwvaz7tmwdaehgu3wwa5kuef0qqswcddwu7u68mmlfkv29gy3q2yv08vddf2wzw7lgxn3a54g83q3z8ct2h6vq",
"sig": "4c2c48035f4dd6c1493bb1daeddf1f9d3501a239d04743a563d4d0ca106eafb622dbfaf41874039fd6af8446db838912193eab1f755e2fdbd1a88f4bde20d77e"
}