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 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.
Yeah, WoT based on the moderators list is far better than recommending moderators. My example was dumb.
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.
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.
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.
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”?
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.
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
topic-based feeds with collaborative moderation invented by nostr:npub1cgd35mxmy37vhkfcmjckk9dylguz6q8l67cj6h9m45tj5rx569cql9kfex I'm also working on it > curation
TIL the only viable options for NIP-07 on mobile are Nostash/Safari on iOS and nos2x-fox/Firefox on Android.
logged in via browser extension.
ok, thanks. by the way, i'm not sure why, but reloading the page after logging in logs me out. looks like something account-related is still in local storage, though.
test from Pollerama
Very interesting feature! How does the app select relays for Topics? Is it hardcoded?
all my sites are back up again. cc nostr:npub183739fkz7u07nj39yusk7556zdampuhtqx933ucqqwfnh9fjqylq0pcgnm
Thank you!
I see. Those made me realize that we might eventually have to deal with issues like abusive or hate tagging.
Will social tagging work? I suspect that people may lack the motivation to tag others.
no worries at all. good to hear it wasn’t something serious.
Nostr was mentioned on my favorite cryptography podcast today, Security, Cryptography, Whatever — they didn't spend a lot of time on it, but here are some highlights:
> It’s federated and it’s European. I bet it sucks.
> It’s some Ayahuasca inspired initiative from. From Messrs. Dorsey et al.
> Yeah, sure, it’s decentralized and federated, but like their proposal for encrypted end to end encrypted DMs was just bad by itself.
> When I reviewed this, my description of this was it looks almost exactly like Nebuchadnezzar [https://nebuchadnezzar-megolm.github.io/], which is like a fractal of things that could have gone wrong with like a complete ecosystem of like a secure messaging system. They found flaws in almost every component of that system and then tried to leverage them as far as they could.
You can read/listen here: https://securitycryptographywhatever.com/2025/07/29/vegas-baby/
They also mentioned a talk that's going to be delivered at blackhat on August 9th which sounds super interesting:
> In this session, we unveil the first comprehensive security study of Nostr and its popular client applications, demonstrating how subtle flaws in cryptographic design, event verification, and link previews allow an attacker to forge "encrypted" direct messages (DMs), impersonate user profiles, and even leak the confidential message from "encrypted" DMs.
Here's the link to the agenda entry for the talk: https://www.blackhat.com/us-25/briefings/schedule/#not-sealed-practical-attacks-on-nostr-a-decentralized-censorship-resistant-protocol-45726
I'm looking forward to learning how we've screwed up — there aren't a lot of cryptographers here, and I know that open protocols make security even harder to maintain. Maybe we've screwed up irretrievably, but I'd rather know now than later.
wait, i can already see the custom emojis on Jumble. it's too fast.
Never mind. It's just that the same nevent without a kind worked at the time.
hmm weird, nak was able to decode it and can see it in other clients https://chachi.chat/e/nevent1qvzqqqqqqypzp42ptgcn6wzxrlun4rqhp72pktx55e49eldmpy6qd9s0dje30pylqyg8wumn8ghj7mn0wd68ytnddakj7qgwwaehxw309ahx7uewd3hkctcqypa8rw60a9c88p8gjjrgmzytj4wga8asdcr906msfrcs03j966qcq4m45ug
I bet specifying the kind is the root of the bug.
my brief conclusion is that the shape matters, but the colour sucks for identifying a pubkey.
Yeah... I'm thinking we should just use those metadata relays + own outbox to broadcast the relay list, instead of trying to spread it to as many relays as possible.