Replying to Avatar reis

It’s better to wait until I finish the prototype.

my idea is basically nostr:npub1cgd35mxmy37vhkfcmjckk9dylguz6q8l67cj6h9m45tj5rx569cql9kfex 's specs

+ an independent “moderators list” per topic (instead of treating the following list as a moderators list)

+ topic-specific upvote and downvote (new kind) for posts

+ separation of kinds for banning a user and marking a post as off-topic

+ votes for topic metadata

Sounds great

- good idea, I have an independent moderators list too, but ATM it's stored in local storage

- not a bad idea kind-7 is not suited for simple upvote/downvoted

- why? I don't think there's anything to be gained by doing that, plus you'll lose interoperability with pollerama, if you think there are clear advantages I might upgrade pollerama to be interoperable

- yeah I've just done a most recent on your WoT mostly because I don't think most people care enough about metadata, but I might incorporate your nip if it takes traction.

Reply to this note

Please Login to reply.

Discussion

The moderation types in your specs are: an event with "p" = ban, and an event with "e" = off-topic. That seems too fragile to me, and if we separate the kinds, we could easily add new moderation types later. Sorry, I’ll comment on the rest later. It’s 1 a.m. here.

I see it as a "ban" event with e tags for events, p tags for people and whatever tags you want to add to expand, I don't see how it's fragile and I see adding anything else as adding a layer of complexity, which only hinders interoperability, what features do you have in mind that cannot be supported with this spec?

Interesting. If a moderation means the same as a ban, then your approach is probably correct. I haven’t thought of many examples, but for instance, what if there were a type of moderation like “recommending a user as a moderator”?

I figured it out myself. I guess I can just give those specs a new kind. It doesn’t need to break interoperability. You only defined the kind for bans, not for moderation as a whole.

Yes recommending moderators should be a new event kind, seperate from the "ban" event itself. Though I do think better signal for recommendations could be zaps or WoT, but this is fine too.

Yeah, WoT based on the moderators list is far better than recommending moderators. My example was dumb.

commenting on others,

In my idea, the moderators list is an addressable event with a “d” tag as a topic.

I meant that we should still use kind-7 for upvotes (no one uses this as downvotes IRL), but use a new kind for downvotes (kind-77?). When reacting to topic posts, we'd add a “t” tag as the topic.

Voting for metadata might be overcomplicated, recent from moderators might be good enough as you said.

Overall, I want to ditch the pre-existing WoT or following model in favour of the new shiny topic-based model. For example, collaborative relay selection could be based on the moderators list.

Actually, the existing WoT based on the follow list isn’t really a WoT. A WoT based on the moderators list is more deserving of the name.

If you're going to have a new kind for downvotes, i think it should be extensible to handle upvotes and downvotes, using kind-7s as upvotes doesn't work because reactions could be "negative"

I understand your thoughts, but we should try to use existing kinds as much as possible. Most reactions today seem to be positive. Of course, we’ll need to modify the NIP if we go ahead with this.

The existing kind-7 already accounts for + and - that can be used for upvotes and downvotes. But you'll also be fetching unnecessary emoji reactions alongside

Yes, my point is to treat every existing reaction, including +, -, or emojis, as an upvote to leverage existing assets before some one starts using -. Just an idea.

I think there are already clients that use - as downvoted I think zapddit did.

OK, I’d like a comment from the creator of zapddit. nostr:npub1ltx67888tz7lqnxlrg06x234vjnq349tcfyp52r0lstclp548mcqnuz40t

Yes. In zapddit, - is a downvote