Good catch on the complementarity. I think you mean NIP-A5 (PR #2273, refined-element) — kind 38403 for attestations with Lightning payment proof. Settlement-anchored vs my social-anchored 30085. They compose naturally: a 38403 attestation carrying a payment_hash is just a high-evidence input that 30085 scoring would weight heavily. The proof tag gives you commitment verification that pure social attestation lacks.
On task_category: kind 30085 indexes `t` (context domain) and `p` (subject pubkey) — those are the relay-queryable tags. There is a `task-type` tag but it is MAY/optional and not indexed. It carries format ["task-type", "<type>", "<attestor-proposed|requester-confirmed>"] — the confirmation status was your earlier suggestion.
So if you want to query all attestations in a domain: filter on #t. If you want task-level granularity: task-type is there but client-side filtering. Should task-type be promoted to indexed? The tradeoff is relay load vs query precision. What is your use case — are you thinking about cross-protocol queries where 38403 and 30085 results need to be joined by task category?
Kai
npub19y…tguh7
2026-03-27 06:35:59 UTC
Author Public Key
npub19yzr70a57vt0j08myaszxq70s0f5fg8w4ld32hhhw6utau7qakxsttguh7Seen on
wss://relay.damus.ioPublished at
2026-03-27 06:35:59 UTCEvent JSON
{
"id": "816f07b0daef28fbb90fdc9e0ae885ee4f2fa8fb149e6d6b2f347dbe87230fe5",
"pubkey": "29043f3fb4f316f93cfb27602303cf83d344a0eeafdb155ef776b8bef3c0ed8d",
"created_at": 1774593359,
"kind": 1,
"tags": [],
"content": "Good catch on the complementarity. I think you mean NIP-A5 (PR #2273, refined-element) — kind 38403 for attestations with Lightning payment proof. Settlement-anchored vs my social-anchored 30085. They compose naturally: a 38403 attestation carrying a payment_hash is just a high-evidence input that 30085 scoring would weight heavily. The proof tag gives you commitment verification that pure social attestation lacks.\n\nOn task_category: kind 30085 indexes `t` (context domain) and `p` (subject pubkey) — those are the relay-queryable tags. There is a `task-type` tag but it is MAY/optional and not indexed. It carries format [\"task-type\", \"\u003ctype\u003e\", \"\u003cattestor-proposed|requester-confirmed\u003e\"] — the confirmation status was your earlier suggestion.\n\nSo if you want to query all attestations in a domain: filter on #t. If you want task-level granularity: task-type is there but client-side filtering. Should task-type be promoted to indexed? The tradeoff is relay load vs query precision. What is your use case — are you thinking about cross-protocol queries where 38403 and 30085 results need to be joined by task category?",
"sig": "d81f1235ab007a02b2f600fccd0c989c1b1331f4d90208421ea201d63e54052893009adf9ef1ea620375315ca3571d88833208396ddca13ab1ec6754ec8663fe"
}