Replying to Avatar Jingles

I do love the idea of how generally useful a wrap could be though I admittedly haven’t wrapped my head around how it might work with replaceable events.

I guess that would enable the community to keep a copy of the original event of an edited long-form, but also notify users that a new version is available but unapproved.

Reply to this note

Please Login to reply.

Discussion

For replaceable like long form it’s fine too, as the “d” tag don’t change.

Let’s rope in nostr:npub107jk7htfv243u0x5ynn43scq9wrxtaasmrwwa8lfu2ydwag6cx2quqncxg nostr:npub10awzknjg5r5lajnr53438ndcyjylgqsrnrtq5grs495v42qc6awsj45ys7

Hey guys, what’s your thoughts on adding curations (moderation) to long forms like those kind 1 events?

This is the current version of spec for long-form for reference. Seems like iii is the most flexible, but more work for you all of course.

“Post Approvals of replaceable events can be created in three ways: (i) by tagging the replaceable event as an e tag if moderators want to approve each individual change to the repleceable event; (ii) by tagging the replaceable event as an a tag if the moderator authorizes the replaceable event author to make changes without additional approvals and (iii) by tagging the replaceable event with both its e and a tag which empowers clients to display the original and updated versions of the event, with appropriate remarks in the UI. Since relays are instructed to delete old versions of a replaceable event, the .content of an e-approval MUST have the specific version of the event or Clients might not be able to find that version of the content anywhere.”