The reason we didn't use kind 1984 directly is that the semantics are not quite the same. This is a request to the bot for flagging something, so you point to the note or npub and provide a suggestion explaining why. This is because:
We want our own vocabulary, NIP-69 (https://github.com/nostr-protocol/nips/pull/457), which is also friendly to automated reports. This is evolving, so it’s not marked as final.
There is a high chance we will choose something different from what is suggested, either from OpenAI's evaluation or our own manual selection. This is also a hint: we are not receiving a report kind; we are receiving a request for a report with different semantics than kind 1984.
Allowing user-provided inputs and just relaying them blindly for the anonymity functionality would make the Tagr bot appear to have a schizophrenic "personality." For example, both the victim of harassment and the harasser could use it, and from an outside perspective, the bot would appear to ban everything randomly without a consistent set of rules. The idea is to have many bots tailored to different preferences, and you follow those you like.
But I like the idea of a new kind. We are using plain JSON just because it was the more flexible initial approach while developing the service. Right now, we do the communication through NIP-17, so it's a kind 1059 wrapping a kind 13 wrapping a kind 14 with our custom JSON in the content.
I think what you propose is to have a new kind different from kind 14, right? Let's say kind 1986 "Report Request"? Currently, I like that we are fully wrapping the reported note inside the payload, so we don't need to fetch anything, but it’s not a big deal to have it as an e-tag for more consistency, although that increases the chances of not finding it.
So we'd be using NIP-59 wrapping this new kind. It would not be signed for the same reasons kind 14 is not, and also because all the requester identity comes from the kind 13, and we'd be repeating info.
dcadenas / Daniel Cadenas
npub138…lrdr2
2024-06-13 15:35:40
in reply to nevent1q…90m5
Author Public Key
npub138he9w0tumwpun4rnrmywlez06259938kz3nmjymvs8px7e9d0js8lrdr2Published at
2024-06-13 15:35:40Event JSON
{
"id": "3142b93eb2781743a0880bfeb21c02632301ab18165ca82b565a222f47342e7e",
"pubkey": "89ef92b9ebe6dc1e4ea398f6477f227e95429627b0a33dc89b640e137b256be5",
"created_at": 1718292940,
"kind": 1,
"tags": [
[
"e",
"ac5f16e2cb12238bf82506fbcf171d242d84c80e9880ed5c32031a8cb36eaff8",
"wss://relay.nostr.bg",
"root"
],
[
"e",
"4d9a6aba7e13a654651cf23f0588e6a1ddc9bf7118b5a284a7f766f3f046f1ae",
"wss://relay.nostr.bg",
"reply"
],
[
"p",
"89ef92b9ebe6dc1e4ea398f6477f227e95429627b0a33dc89b640e137b256be5",
"wss://nos.lol/",
"dcadenas"
],
[
"p",
"d0a1ffb8761b974cec4a3be8cbcb2e96a7090dcf465ffeac839aa4ca20c9a59e",
"wss://relay.nostr.band/",
"mplorentz"
],
[
"p",
"97c70a44366a6535c145b333f973ea86dfdc2d7a99da618c40c64705ad98e322"
]
],
"content": "The reason we didn't use kind 1984 directly is that the semantics are not quite the same. This is a request to the bot for flagging something, so you point to the note or npub and provide a suggestion explaining why. This is because:\n\nWe want our own vocabulary, NIP-69 (https://github.com/nostr-protocol/nips/pull/457), which is also friendly to automated reports. This is evolving, so it’s not marked as final.\n\nThere is a high chance we will choose something different from what is suggested, either from OpenAI's evaluation or our own manual selection. This is also a hint: we are not receiving a report kind; we are receiving a request for a report with different semantics than kind 1984.\n\nAllowing user-provided inputs and just relaying them blindly for the anonymity functionality would make the Tagr bot appear to have a schizophrenic \"personality.\" For example, both the victim of harassment and the harasser could use it, and from an outside perspective, the bot would appear to ban everything randomly without a consistent set of rules. The idea is to have many bots tailored to different preferences, and you follow those you like.\n\nBut I like the idea of a new kind. We are using plain JSON just because it was the more flexible initial approach while developing the service. Right now, we do the communication through NIP-17, so it's a kind 1059 wrapping a kind 13 wrapping a kind 14 with our custom JSON in the content.\n\nI think what you propose is to have a new kind different from kind 14, right? Let's say kind 1986 \"Report Request\"? Currently, I like that we are fully wrapping the reported note inside the payload, so we don't need to fetch anything, but it’s not a big deal to have it as an e-tag for more consistency, although that increases the chances of not finding it.\n\nSo we'd be using NIP-59 wrapping this new kind. It would not be signed for the same reasons kind 14 is not, and also because all the requester identity comes from the kind 13, and we'd be repeating info.",
"sig": "25b886812935c5a46bc7da164f4bb2a50ec3b89be8818425031c11c2d0a80d26dc7f25ac824fe4f49331455237a371500cb120b7b6667a7d337ee4e1193b1989"
}