Hah, this is probably a good metric for how well technology is serving you. How many apps do have that you like vs. how many do you have because society forces you.

nostr:npub1k979np6dcpwh7mkfwk7wq3msezml48fh7wksp9hakakf8pwk3y5qhdz7te I'm having trouble reading the text. Are these the intended colors? I tried Firefox and Safari. Also is there a list of topics I can browse somewhere? I tried searching for a few but didn't get a lot of results. I noticed some weird search behavior too. Searching for "permaculture" pulled up "gratitude" but searching for "gratitude" did not. I'm curious what kind of tag NIP you are using for the topics?

I've been waiting for Reddit on Nostr. Checking it out now!

oh yeah thanks nostr:npub1wmr34t36fy03m8hvgl96zl3znndyzyaqhwmwdtshwmtkg03fetaqhjg240 for recommending this.

I finished watching "The AI Dilemma" presentation from the Center for Humane Technology. It. is. so. good. It's an hour long but if you only watch one 1 hour YouTube video this year you should make it this one.

I especially liked their framing of algorithmic timelines in social media as humanity's "first contact" moment with AI. ChatGPT and other large language transformers are the "second contact". It occurs to me that a big reason Nostr, Scuttlebutt, Mastodon, and other decentralized social media networks are attractive is because they are largely AI-free. I imagine this will quickly become a selling point for certain apps and relays as AI takes over mainstream tech throughout the next year.

https://youtu.be/xoVJKj8lcNQ

Idk, this doesn't seem better to me, just a wordier way of saying the same thing haha. I think it's better to leave it as you had it, or just remove it altogether. IMO this NIP doesn't need to address achieving legal compliance - NIPS are about the semantic meaning of event data. So while I agree that relay owners SHOULD do this, it seems outside the scope of the spec. At least that's my opinion - don't take it too strongly. You are right, NIPs are all optional so it's not forcing anyone to do anything.

"It's the same unworkable, easy to fake, hard to validate problem with all moderation today". It's true that you have to do some trusting of relay operators. That's part of the Nostr protocol though and it's probably never going away. If you don't want to trust relays then you need to put your events in some of merkle-DAG, like scuttlebutt, AT protocol, p2panda, and others do. It's been tried, and it works, but it comes at the cost of simplicity because it introduces lots of problems around deleting content, verification of the DAG, and cross-device identities. Nostr's power is it's simplicity.

This *is* better than moderation on all major social platforms because you get to choose your client and your relays. So even though there is trust involved you get to choose who to trust, which is a lot of power. If you want a trustless system you need to find another protocol. This is actually a big criticism of Nostr from some of the p2p social protocols.

"Our approach to content moderation is based on the idea that everyone can be a moderator" - love it. In my mind this is the most important issue facing Nostr. Can we actually give people choice when it comes to moderation and create a social network where rules are clear, scoped, and different for different communities. Nostr already has implicit rules and moderation happening, this is about making it visible and "on-chain". Let's spend the energy necessary to get this right.

We'll be adopting NIP-68 and NIP-69 in Nos in the coming weeks to start learning what users think of them and enabling experiments around actually acting on these labels.

Nos has had several similar bugs with the contact list. It would’ve been much better to publish each relay or follow as it’s own event, because right now there is no way for apps to know whether they have your latest relay or contact list. In Nos we are going to implement a lock that prevents you from publishing a new relay or contact list until we’ve downloaded yours from the relays, but even then there is no guarantee that a given relay has the latest one. Probably we’ll eventually end up storing a version history and letting you roll back because there are edge cases you just can’t properly handle.

5:15:29. If you click the link to open on YouTube.com it should open there.

Nah, if it's an attack on anything it's on people who want no consequences for their speech. Nostr is about freedom of listening as much as freedom of speech, and choosing a moderation strategy is an exercise of that freedom.

Do you think it's worth making a new type of message with relays (as an optimization)? Like instead of sending ["EVENT", {event JSON}] a client might send ["REPORT", {report event JSON}].

Tagging some folks I have already connected with and would love to see at this: #[2]​ #[3]​ #[4]​ #[5]​ #[6]​ #[7]​ #[8]​ #[9]​ #[10]​ #[11]​ #[12]​ #[13]​ #[14]​ #[15]​ #[16]​ #[17]​ #[18]​ #[19]​ #[20]​ #[21]​ #[22]​ #[23]​ #[24]​ #[25]​ #[26]​ #[27]​ #[28]

And nostr:npub19vvkfwy9mcluhvehw7r56p4stsj5lmx4v9g3vgkwsm3arpgef8aqsrt562, what would a decent social network look like for you?

I've been talking with nostr:npub19vvkfwy9mcluhvehw7r56p4stsj5lmx4v9g3vgkwsm3arpgef8aqsrt562 about nostr:npub1lyd927xx2a49amh7umsq0mkztpgjdlwfhud5g894q5q2yn72jc4q0qh7f3 and she suggested she answer some of my questions out in the open, which I love!

So nostr:npub19vvkfwy9mcluhvehw7r56p4stsj5lmx4v9g3vgkwsm3arpgef8aqsrt562, are there any challenges on Nostr for minority groups that stand out to you?

I'm confused. Kind 32123 is definited as a parameterized replaceable event, isn't this how they are supposed to work?

"A parameterized replaceable event is defined as an event with a kind 30000 <= n < 40000. Upon a parameterized replaceable event with a newer timestamp than the currently known latest replaceable event with the same kind, author and first d tag value being received, the old event SHOULD be discarded, effectively replacing what gets returned when querying for author:kind:d-tag tuples."

The requirement for paid relay owners to accept moderation reports from unpaying users feels to me like it's overstepping the mark. (Ok, I see now in the NIP it is a SHOULD not a SHALL, this seems more reasonable). Accepting events from unpaid users is a DDOS vector because checking the event kind requires parsing JSON which is relatively expensive for a server. Big relays will have to apply their spam and DDOS filters before checking the event kind. I'm not sure what that means legally. I'm curious what relay owners think about this nostr:npub1xdtducdnjerex88gkg2qk2atsdlqsyxqaag4h05jmcpyspqt30wscmntxy nostr:npub1h72rkut9ljnpdfyrcmw8q9jx52tgn2m8zyg0ehd6z236tz2vmg2sr5k5rt

While we’re at it, there is no reason you should be limited to a single NIP-05. It should be an array of strings in the metadata event, not just a single string.

Try this one: https://testflight.apple.com/join/YBBlRWc8

I see you Adrien!