I have a feature where the client uses only timestamp / dele...

inkan

npub16xnpfx85k8wzdhctang6860g3u64lds5kac73ddjwlg0lxdg9g3su56z6l

hex

e35b209fdb986b5ecbcbb3f8934b4d699be3a5128e36514ef3039fd1d12b906c

nevent

nevent1qqswxkeqnldes667e09m87ynfdxknxlr55fgudj3fmes88736y4eqmqprpmhxue69uhhyetvv9ujuem4d36kwatvw5hx6mm9qgsdrfs5nr6trhpxmu97e5dra85g7d2lkc2twu0gkke8058lnx5z5gcdgxcch

Kind-1 (TextNote)

2026-03-25T18:19:21Z

↳ Reply to Nathan Day (npub1cn670f663n3ks02jnnlsvd5y88zjnefy8343ykaxs7y3nzzketrsrjwt8a)

Yeah, you could use it with those for sure. Attestations cover both the valid and invalid states. Experimental for sure, but I needed it for Proof of...

I have a feature where the client uses only timestamp / delegation info events that were signed by "trusted pubkeys." The trusted pubkeys are settable by the user, or otherwise the client reverts to reasonable default settings.

One could maybe expand this filter to also accept events that have an attestation from a trusted pubkey, regardless of whether the event itself was signed by a trusted pubkey. And maybe also have a feature that causes the client to audit an event against the blockchain if a trusted pubkey attests that it tried to audit the event and failed.

It would be nice if the attestations can play that role - I'll take a closer look. This would obviate the need to implement "audit" events myself just for my particular use case.

Raw JSON

{
  "kind": 1,
  "id": "e35b209fdb986b5ecbcbb3f8934b4d699be3a5128e36514ef3039fd1d12b906c",
  "pubkey": "d1a61498f4b1dc26df0becd1a3e9e88f355fb614b771e8b5b277d0ff99a82a23",
  "created_at": 1774462761,
  "tags": [
    [
      "e",
      "678c7210015ac556f23b992dcd041953dfaa5b6b3cb68343fffa46e8d208b989",
      "wss://relay.primal.net/",
      "root",
      "c4f5e7a75a8ce3683d529cff06368439c529e5243c6b125ba68789198856cac7"
    ],
    [
      "e",
      "13c313876f390a037de305dcbb5e99a1f66bdb50de2a81596717dbb970048dea",
      "wss://nos.lol/",
      "reply",
      "c4f5e7a75a8ce3683d529cff06368439c529e5243c6b125ba68789198856cac7"
    ],
    [
      "p",
      "3eab247c63bb35dfa38e07ca102f6da28ba9b9d4687197743bde3a2b1d80aeed"
    ],
    [
      "p",
      "06b7819d7f1c7f5472118266ed7bca8785dceae09e36ea3a4af665c6d1d8327c"
    ],
    [
      "p",
      "46fcbe3065eaf1ae7811465924e48923363ff3f526bd6f73d7c184b16bd8ce4d"
    ],
    [
      "p",
      "916cb5ff07d3b51cef7f6b6b7f5479b1001b401c0e82558ee1a22504c7d507c9"
    ],
    [
      "p",
      "ba2c475d7c6df897b9cebd41a7a7960e52e72005075278cf6f9f73dbd0a5c167"
    ],
    [
      "p",
      "c4f5e7a75a8ce3683d529cff06368439c529e5243c6b125ba68789198856cac7"
    ]
  ],
  "content": "I have a feature where the client uses only timestamp / delegation info events that were signed by \"trusted pubkeys.\" The trusted pubkeys are settable by the user, or otherwise the client reverts to reasonable default settings.\n\nOne could maybe expand this filter to also accept events that have an attestation from a trusted pubkey, regardless of whether the event itself was signed by a trusted pubkey. And maybe also have a feature that causes the client to audit an event against the blockchain if a trusted pubkey attests that it tried to audit the event and failed.\n\nIt would be nice if the attestations can play that role - I'll take a closer look. This would obviate the need to implement \"audit\" events myself just for my particular use case.",
  "sig": "27e8fbbd940e23c6701188250d7032006a50d711e1cd02f646b1f959372c2b44d3cec2d5a92646b564507f576484357330645023da8bc06999943cddc8994817"
}