> After a person clicks the submit button after composing a community note, he will see two popups from the signer extension . Not sure if that would startle them as generally only one is expected
Good point. Although when posting an existing note into a community, the user will only be signing one event. (that's actually one additional benefit of this approach, it allows users to "pull" other notes into communities with kind 4549 events, just like how mods can pull events into communities with kind 4550 events)
> When someone zaps or reacts to a community post, we need to make sure to count it against the post request and not the approval event or the orginal kind 1 event if it exists. Is my understanding correct?
Correct, that's my understanding as well. Zaps/reactions would go to the post request, since that event will be present and indexed on relays.
> in case the user doesn't want the new note in their feed, there will be no "e" tag in their post request, right?
Actually I think it *would* make sense to include the 'e' tag so that clients can query to find all the post requests for an event (this would be relevant when an existing note was posted-requested into a community).
> I think it is a neat way to ask A client not to look for the actual event.
Well clients that don't support communities are not going to pull the kind 4549 post-requests in the first place, right? So they'll never have any reason to look for the actual events. And clients that *do* support communities won't need to look for the events since they already have the actual events (they can parse them from the content string)
Thanks for the in-depth response, and please let me know if I misunderstood any of your points!
Stuart Bowman
npub1lu…827lj
2023-07-17 01:13:43
in reply to nevent1q…7v99
Author Public Key
npub1lunaq893u4hmtpvqxpk8hfmtkqmm7ggutdtnc4hyuux2skr4ttcqr827ljPublished at
2023-07-17 01:13:43Event JSON
{
"id": "2abba3560b2d2e583f23ffb044ac08633dc797bc80b4b75b507a61a67db09b41",
"pubkey": "ff27d01cb1e56fb58580306c7ba76bb037bf211c5b573c56e4e70ca858755af0",
"created_at": 1689556423,
"kind": 1,
"tags": [
[
"e",
"03183eb1a1a4d0d1e33cb8a2dd32249a820c5d2e85c087d21515e1b5486f5e91",
"",
"root"
],
[
"e",
"f2451e9d1d116dbef664fb13fad2f11fdb44f110fcf3313b0dbad61bc8864a11",
"",
"reply"
],
[
"p",
"a1fc5dfd7ffcf563c89155b466751b580d115e136e2f8c90e8913385bbedb1cf"
],
[
"p",
"460c25e682fda7832b52d1f22d3d22b3176d972f60dcdc3212ed8c92ef85065c"
],
[
"p",
"ff27d01cb1e56fb58580306c7ba76bb037bf211c5b573c56e4e70ca858755af0"
],
[
"p",
"facdaf1ce758bdf04cdf1a1fa32a3564a608d4abc2481a286ffc178f86953ef0"
]
],
"content": "\u003e After a person clicks the submit button after composing a community note, he will see two popups from the signer extension . Not sure if that would startle them as generally only one is expected\n\nGood point. Although when posting an existing note into a community, the user will only be signing one event. (that's actually one additional benefit of this approach, it allows users to \"pull\" other notes into communities with kind 4549 events, just like how mods can pull events into communities with kind 4550 events)\n\n\u003e When someone zaps or reacts to a community post, we need to make sure to count it against the post request and not the approval event or the orginal kind 1 event if it exists. Is my understanding correct?\n\nCorrect, that's my understanding as well. Zaps/reactions would go to the post request, since that event will be present and indexed on relays.\n\n\u003e in case the user doesn't want the new note in their feed, there will be no \"e\" tag in their post request, right?\n\nActually I think it *would* make sense to include the 'e' tag so that clients can query to find all the post requests for an event (this would be relevant when an existing note was posted-requested into a community).\n\n\u003e I think it is a neat way to ask A client not to look for the actual event.\n\nWell clients that don't support communities are not going to pull the kind 4549 post-requests in the first place, right? So they'll never have any reason to look for the actual events. And clients that *do* support communities won't need to look for the events since they already have the actual events (they can parse them from the content string)\n\nThanks for the in-depth response, and please let me know if I misunderstood any of your points!",
"sig": "c87ebc37c0be3d37c795e1e404d4b07e21d3c134e50e25282e6b6eefe5f67fb64a0a06b2e01cf60373cff5b98838bd1630e0d61eb8273216c02eaebdc169bd53"
}