Oddbean

The sentiment of needing to differentiate is a critical element of what Nostr needs to succeed. There are lots of problems with existing platforms and therefore lots of opportunities to differentiate and innovate. Talk to people who still use them to find the opportunity spaces. The community also needs to address two other aspects in order to see widespread adoption. Based on the conversations two weeks ago there’s still work to do to make Nostr a cool place for everyone to hangout. There are some nascent components for avoiding content one does not want to see, but those still are not enough to protect against harassment primarily experienced by women on this network. If you want a man cave with a side of porn - cool then the status quo works, but if you want to see widespread adoption, then additional NIPs or work on existing NIPs is required to allow people to protect themselves from bad actors. Bitcoin may be different than the other shitcoins, but the general public sees it all as crypto. If thats the only content they see here - they will pass. That’s why we launched the Creator Residency and Journalism Accelerator. It’s also an opportunity to test micropayments for content creation & journalism as well as a way to reframe Lightning. A subset of people will also pass if the main selling point is say anything you want. This latter piece is bc most platforms show you content beyond your network today, so the assumption is if Nostr has free speech they will have to see everything. But that is not how it works (except for the aggregation feeds). If the community spends a bit more time talking about choosing your feed and a bit less about free speech - the adoption should shift. In both instances branding matters, specifically how we talk about what already exists in Nostr. Updating how we talk about Nostr can go a long way to increasing adoption.

There are two items that can help based on the discussion a couple weeks ago: 1. If someone is harassing a user it is not enough to mute that user bc they are still in the replies. In some cases the harasser’s friends are seeing the replies and piling on. However the person being harassed doesn’t know the harassment is continuing and then is blindsided by the additional harassment coming their way. Freedom from needs to extend to freedom from having someone in your replies continuing to harass you. The current model assumes Nostr is a level playing field that exists in a cultural vacuum and that is not the case. As a result those who experience harassment IRL also feel the brunt of it here. Direct harassment is different from saying whatever you want. It involves being in someone’s replies or mentioning them directly. People need the ability to say no to both of these. 2. The second issue women reported was being found by random jerks. This happens bc some apps have aggregator feeds. Users need the option to opt out of these. I also think there’s more user research needed to understand if other problems exist.

Not sure I agree on the harassment issue. The protocol layer is dedicated to providing a stable foundation where anyone can post anything, and I don't see the issue of harassment changing that, because whether a note or reply is harassment is a value judgement. It might not be the intention, and there's a spectrum that needs to be considered. The protocol layer can't really deal with that level of complexity. I think the functionality that you are looking for is in network logistics, where we could be given the option of seeing whether an npub is a close connection with someone else that we have already muted, and make it an easy single click to mute that npub as well. That would work well at the client level, if the client has the type of network analytics that I'm thinking about. That kind of development work is going to be coming, but right now I haven't seen anything. And I think the second issue of "random jerks" is also going to be related to network analytics as well. We can see a list of Nostr Highlights in our feed. Maybe a client could dig a bit and provide a list of "most muted npubs". If someone decides to be a complete jerk to anyone and everyone, they can post whatever they want as long as they are in a silo that protects the rest of the network from abuse. So put them on a list and give people the option to mute jerks sight unseen.

As @brugeman pointed out below Nos has something like this. However in user research multiple people have noted they don’t like having posts hidden that are outside their network. It forces users to do extra work which is not really freedom. If you haven’t tried it out, try Nos for a week and LMK what you think. One thing that would be helpful is to look at the entire user journey when thinking about freedom. We focus a lot on the initial post, but we don’t pay enough attention to the subsequent dialogue that ensues. Freedom within dialogue is very different than speaking into the public square. In the public square I can walk away from someone by unfollowing them. In a dialogue (thread or via mentions) I cannot walk away. With mute I can put on headphones and hope the harassers buddies don’t show up. If they do then i have to keep adding additional sets of headphones. But then my friends have to step in or be subject to the harassment as well or they need to put on headphones. Within the dialogue- the power is in the hands of the harassers if mute is the only option. If Nostr adds the ability to limit replies and mentions, then the person being harassed has the freedom to walk away. The harasser can still speak in the public square, they simply can’t speak in a dialogue when the other person doesn’t want them there.

Yeah I’m mistaken about the protocol layer as the place where mutes of replies and mentions should happen. Based on some conversations today it makes the most sense that the clients and relays screen for these. In terms of filtering out the random jerks - other protocols are experimenting with mute lists - similar to what you suggest above and I think it’s a good option for Nostr as well. A user can subscribe to a mute list of their choice based on whatever criteria they have - it could be words / content or people. Another framing is feed curation. The beauty of Nostr at its basic level is that the user is in control of their feed, rather than an algorithm. Sorting through harassment challenges makes that control truly possible.

Exactly. If I don't want to see a post, then I need to be the one to make that choice. And the reverse is also true. If I do want to see a post, I need to be the one in control. Giving algorithms or advertisements control of pushing and pulling is what I hate about all of the other centralized corporate social media networks. It's why we are here instead of there. Because nobody else has control.

@darashi @miljan @brugeman @Marko have yall consider a “do not index me” request for yalls aggregators - see Linda’s latter point. I think the guulagl search has a do not index flag for websites

Jerks' daily job is to find targets, not sure if deindexing from aggregators would help much, you should then deindex from major public relays too, and only post your stuff on paid relays (paid to read, not only to write). Meaning, you shouldn't be on public Nostr if you're afraid to be found by someone determined to find you. I think the only anti-harassment solution that could work on Nostr is client-side filtering, based on contact/mute lists, friends' reports, etc. Don't show replies from people you don't follow, or that were reported/muted many times by people you follow, or replies from public relays. I bet some of these policies are implemented an nos.social, but the issue is - everyone's using Damus/Amethyst/Primal, and those have nothing like that. The way I see it, we should have a separate pluggable layer/API/NIP for content post-filtering, that can be plugged into any app: an app forms a feed (main/replies/notifs/anything) and then passes all the events from the feed to the filter, and filter returns various labels (spam/harassment/nsfw/impersonation/...), and app covers the content of the labeled event and shows labels above it. This way apps don't have to rebuild their feed building logic - just apply another layer above it, users would specify the filtering API endpoint in the settings and get the filtering they want. Safe mode could be 'cover notes from users I don't follow until filter returns it's labels - uncover if no bad labels returned', more reckless mode could be 'show notes first, only hide them if filter returns some bad labels'. If nos or anyone is interested in experimenting with me in this area, let me know.

One other thing I forgot to mention is that across Nostr we are not implementing mutes the same way. If I mute someone on Nos, they are not muted on Damus. I’m not sure how often people use different clients, but it would be good to have mutes work across the network as a starting point.

Good point - how do yall implement mute on Nos? I dont think currently damus imports / checks for mute lists generated on other clients - @danieldaquino lmk if I am wrong. This should be added. Checking backlog.

@elsat, I am not 100% familiar with the details of mute-lists, but I believe they are often stored in a special kind of Nostr event, so it should be generally interoperable, but yeah, there might be some specific detail that is causing this issue

I think Damus is still using the old kind 30000 mute list which has been deprecated and everyone is standardizing on 10000. We are using 10000 in Nos. See https://github.com/nostr-protocol/nips/blob/master/51.md#deprecated-standard-lists