Dikaios1517 @Dikaios1517 - 30d
Ok, it's time to gripe a little bit, as I discovered an annoying lack of interoperability between various #Nostr clients that really ought not to be the case: Mute lists. Beware, this is a bit of a long one... When a user mutes an npub, or a word, they don't want it to only be muted in Amethyst, and not muted at all in Primal. They want it to be muted across all Nostr clients they use. The standard mute list, according to NIP-51 is kind 10000. All users should have exactly one of these, and relays should only keep the most recent version. Mute lists may contain a few different types of muted content: 1. Muted users/npubs, designated by a "p" tag. 2. Muted hashtags, designated by a "t" tag. 3. Muted words, designated by a "word" tag. 4. Muted threads (such as hellthreads), designated by a "e" tag. Some clients also encrypt the entries added to the mute list. While not required, it is part of the spec that clients should expect to see within a kind 10000, and I think it should be preferred. A given npub should not be aware that another npub has muted them and unencrypted mute lists are readable by anyone, unless we move to only saving mute lists to relays that can require AUTH to read them. Yet, I see a wide variety of handling of mute lists by clients. #Amethyst uses kind 10000 as expected, and encrypts all content saved to the mute list (hooray!). It seems to support muting npubs and words, and has no support for muting hashtags or threads. nostr:npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z, please chime in to correct me if I have misrepresented anything here. #Coracle uses kind 10000 for muted npubs and also decrypts the muted npubs that were added by Amethyst, so they are also muted on Coracle. However, users muted on Coracle are not encrypted. I imagine this is because Coracle is trying to use mute information for the sake of building web-of-trust scores (mutes by those within your WoT count as -1 in the scoring), and any encrypted mute information cannot be used to calculate those scores. Also, though Coracle supports muted words, it does not seem to see the words I have muted from Amethyst in my kind 10000, and seems to be keeping a separate list, because words I have added in Coracle don't show up on my kind 10000, and are therefore not seen by other clients. nostr:npub1jlrs53pkdfjnts29kveljul2sm0actt6n8dxrrzqcersttvcuv3qdjynqn, can you offer some clarity on how Coracle handles mutes, especially regarding muted words? #Primal web seems to have an old kind 30000 list with only two npubs listed, while Primal Android didn't show any muted users at all, but adding a muted user added the npub to my kind 10000, which suggests Primal simply doesn't support decrypting the other entries that were added from Amethyst. Also, muting an npub on Primal resulted in all the encrypted entries on my mute list from Amethyst being nuked. #Nostur did not display any of the above. Not my kind 10000, encrypted entries or not, or the kind 30000 Primal had been using at some time in the past. Adding a "blocked" user in Nostur also did not add them to my kind 10000 and did not add any other list type that I could find on listr.lol either. I am guessing it is using a list kind that isn't recognized or is just storing blocked npubs locally. nostr:npub1n0sturny6w9zn2wwexju3m6asu7zh7jnv2jt2kx6tlmfhs7thq0qnflahe, can you provide some insight into how Nostur is handling mutes/blocks, and why it doesn't seem to be using kind 10000? #Damus appears to be using kind 10000, but only shows entries that have not been encrypted. However, when adding a new blocked user, it does not appear that Damus wipes out the encrypted entries in the list. If not supporting encrypted entries within your client, this is the best way to handle them, rather than erasing them when replacing the kind 10000 as Primal did. #Nostrudel behaves much the same as Damus, using the kind 10000 and only showing entries that have not been encrypted, but also not wiping encrypted entries when adding a new entry. #Pokey also seems to have trouble respecting mute lists for the sake of muting notifications. This appears to be because Pokey only looks for your mute list on your inbox(read) relays, while users publish their mute list to their outbox(write) relays, and those may not necessarily be the same. However, I wonder if it is also an issue of Pokey indeed being able to find a user's mute list, but not taking encrypted entries into consideration. nostr:npub1v3tgrwwsv7c6xckyhm5dmluc05jxd4yeqhpxew87chn0kua0tjzqc6yvjh, can you confirm whether Pokey is able to mute notifications from npubs that have been encrypted in a users mute list? Is it possible to get these and other major clients on the same page about how to handle mute lists? Yesterday, nostr:nprofile1qqsqddupn4l3cl65wggcyehd009g0pwuatsfudh28f90vewx68vrylqug8jsn posted this about what interoperability means on Nostr: nostr:nevent1qvzqqqqqqypzqp4hsxwh78rl23eprqnxa4au4pu9mn4wp83kagay4an9cmgasvnuqyghwumn8ghj7mn0wd68ytnhd9hx2tcprdmhxue69uhhyetvv9ujuem9w3ekzen9vfhhstnpwpcz7qg4waehxw309aex2mrp0yhxgctdw4eju6t09uqzq8kmkd9nu88hhs89dzfahs78pn9j73u5wfjxz8y972uzhapj4es66ad6zu I pointed out that in order for this to be the case, we also need to agree on the format and expected content that will be contained in a specific note kind. From what I can tell, there is little agreement on how mute lists should be handled. Should they include encrypted entries? If they do, should clients respect the encrypted entries, since the user who created that kind 10000 certainly doesn't want to see notes from the npubs they added to their mute list, encrypted or not? Clients certainly should not nuke encrypted content from the mute list if it is present, right? Or should we drop support for encrypted entries on mute lists altogether, since some clients are relying on mute lists from npubs within a user's WoT to determine what content is likely to be spam? Users just want to know that when they mute an npub or a word in one client, that it will also be muted in other clients, and that muting in one client won't nuke their mute list in another client.
I can't believe I didn't even check Jumble... Jumble appears to add encrypted entries to your kind 10000, similar to Amethyst. Which is great for Jumble, but whoever you mute there won't be muted on any client that doesn't support it.
Serves me right for testing using my main npub... 😂 I like what nostr:nprofile1qqsgzfdez8ksa9xmuvqg5zly3nl9e5xqkpvj8nllj9aw06ra4pqq3qcq9n0c5 is going to do with Jumble, giving users the choice between "private" (encrypted) mute or "public" mute. I can see there being situations where a user might want to use one or the other.
I also lean toward private mutes, but I am also sympathetic to use-cases like nostr:nprofile1qqsf03c2gsmx5ef4c9zmxvlew04gdh7u94afnknp33qvv3c94kvwxgsm3u0w6's web-of-trust scoring that deducts score based on how many within your WoT have muted a given npub. That's another way that choice is advantageous, though. The ones you would most want to be taken inter consideration for WoT scoring would be muted scammers and spammers, which a user probably has no issue being publicly shamed. Whereas the mutes you most likely want to have kept private are just people who you don't get along with, and that sort of reason for muting probably doesn't need to be taken into consideration for WoT score, as others may get along with them fine.
How about the encrypted mute items? Is Pokey decrypting and muting those, or ignoring them?
Dikaios1517 @Dikaios1517 - 29d
Thank you for the response with insight into your reasoning for going the route you have with Nostur. I think I would disagree with the approach, but I definitely understand why you have gone that route. That said, I do fully agree that a mute list is data that does not need to be public. At the same time, I also see the value of having certain types of mutes public, such as muted scammers and spammers, so that those who have me in their WoT can also benefit from my having muted a scammer or spammer, even if they have not yet done so. When it comes to "let relays be relays, not personal storage," I think you might have a case if we were talking about using relays for storing media or something. But we're not. We're talking about storing a long-standing standard event kind that is defined in a merged NIP and utilized by most major clients. Moreover, if public relays are not on-board with storing that information, they can reject that event kind. You mentioned that "last seen" metadata is still leaked, even in encrypted lists. I am not familiar with that means. Does the npub that was muted somehow have leaked to them that you muted them, even when the entry is encrypted? The temporary blocking/muting I absolutely understand needing to do locally. I agree that there is probably not another way to do it. However, other clients, such as Damus and Nostrudel have temporary mute options while also utilizing kind 10000 for permanent mutes. My guess is they do the temporary mutes locally, and honestly, a user probably wouldn't want temporary mutes used for influencing other users' WoT filters anyway. In my testing so far, the only culprit that nuked my mute list was Primal, and it didn't nuke the whole thing, only the encrypted mutes. There will be no nuking of mute lists if clients are all on the same page about what sort of content should be expected to be found in the list, and then including that data when replacing the previous list, even if their client doesn't use the data for anything. I am definitely liking your approach to doing a lot locally, and having a manual option to "announce," such as how you implemented the relay settings. I have seen it be a bit confusing for users, but having that ability to read from or write to relays you haven't announced in your kind 10002 is ideal. Moreover, I feel like Nostur is aiming at being a gorgeous client for power-users, rather than a dumbed down client for newly hatched nostriches. Take that approach with mute lists, too, as mentioned above, and I would say that's a near perfect approach. How do you plan to handle the encrypted data in the kind 10000 at the time of import, if there is any? Decrypt it and store it locally and on iCloud unencrypted? Ignore it so that only publicly listed mutes will be muted in Nostur after import? Import it and use it, since the user presumably would not want to see notes from those they have muted, even if they did so through a client that stores the entry encrypted? Whatever approach you take, when "announcing" the mute list that is stored locally, is there a way to make sure that Nostur only adds the local mutes to the new list, without removing entries (particularly encrypted entries) that are already on the standard list? It would be a shame to announce some mutes that were added on Nostur only to lose half of the mutes added in other clients that use the kind 10000 directly.
You mean "thorn in the side"? 😂 I only noticed this discrepancy between clients because with all the adding of muted words to banish the reply spam lately, I saw that adding a muted word in Amethyst didn't translate to it being muted in other clients, even if they supported muted words. Me being me, I had to dig into it and find out why that was the case.
It's fine. You're working on encrypted media in private communities and DMs right now, right? That's HUGE! Example: I had purchased something via Shopstr and the seller sent me a screenshot back, confirming my address before shipping to me. Thing is, he was using nostr.build for media hosting and so, even though the image was sent in a DM, it was not encrypted and was there for all the world to see in nostr.build's free image gallery. Thankfully the guys over there at nostr.build were quick to take it down at my request, but it's a good lesson in why we NEED encrypted media in DMs. Interop for muted words can wait.
97c70 - 29d
Yeah, the encrypted media thing is a huge oversight. Strangely, I've gotten a lot of push back for the way I've proposed doing it. But I'm going to forge ahead anyhow 😂
Yeah, not sure if the seller was using Shopstr for DMing me. May have been, or may have been using another client with NIP-17 DMs. Either way, even after providing tools that allow media to be encrypted, users will still need to take advantage of it. I could 100% still see some users uploading directly to a public Blossom server and copy/pasting the URL into the DM, thinking they're all good because DMs are encrypted. Not really anything that can be done about that.
Indeed, you can. Kind 10000 mute lists support muting npubs, hashtags, threads, and words. Which of those types of items your client supports muting may vary. I had a rant about discrepancies in the way Nostr clients handle mute lists yesterday: nostr:nevent1qvzqqqqqqypzpde8f55w86vrhaeqmd955y4rraw8aunzxgxstsj7eyzgntyev2xtqydhwumn8ghj7un9d3shjtnwdaehgunsd3jkyuewvdhk6tcprdmhxue69uhhyetvv9ujucnjd9nksarzdak8gtnwv46z7qg3waehxw309ahx7um5wgh8w6twv5hsqgxmje4x8er9c5rpzldh2gtzd4ju4wqg58ntamqd85gut97qrlt5zv7v5deh
calvadev⚡️ @calvadev⚡️ - 29d
I haven't added support for messaging/uploading images via NIP-17, only text, but good to know!
Dikaios1517 @Dikaios1517 - 24d
Thank you for the great explanations, sir! I think we still might be talking past each other on a couple things, though. > "...maybe it's better to use public reports for that so the mutes can stay private." I actually really like this idea. Amethyst currently will mute someone you report by default, and while the report is public, the mute is added to the kind 10000 as an encrypted/private entry. I feel like this is the ideal behavior. Maybe part of the issue is that most users aren't really utilizing reports much, and are just muting alone, without reporting. I know nostr:nprofile1qqsf03c2gsmx5ef4c9zmxvlew04gdh7u94afnknp33qvv3c94kvwxgsm3u0w6 also has some issues with reports being tied back to the user who made the report, especially when reporting certain illegal content. > "When you update something that you expect to be private, it will still reveal in the metadata that you did something." I am trying to understand how this "last seen" flag being updated would be an issue. It indicates that I published some kind of note to the relays as of that time, but does not give any indication what it was. If it was my mute list being updated and the entry added was encrypted, anyone curious would first need to know how to investigate what specific note it was that caused the "last seen" to be updated. Most users would be at a loss for how to do so. Moreover, it also assumes that I haven't posted any reply, reaction, zap, or other public-facing note since then that would have updated the "last-seen" since updating my mute list. Even if they then discover it was my mute list that was updated, they will have no way of determining what specifically changed, unless they happen to have the previous copy. Even if they do have the previous copy, so they can see what was changed, the new entry is encrypted, so they can't read it. They have no idea whether that new mute entry is their npub or just some random spammer. So, "last seen" info might "tattle" on users if the new entry added is not encrypted, for sure, but that's just another reason I think it's good to at least have the option to encrypt mute entries. > "Compared to the mute list the follow list is even more long-standing/defined but last week I saw 2 more people get their list nuked..." My comment about mute lists being long-standing, standard note kinds was not in reference to their likelihood of getting nuked, but rather in reference to the question of whether they should be stored on the relays. Your previous response had listed "let relays be relays, not personal storage" as one of your reasons for not storing the mute list in the kind 10000, indicating that you didn't think relays should be used for storing that "personal" information. You would have a point if Nostur was the only client users needed their mute list for, but users want mutes they made in one client to also work in other clients, which means the list needs to be stored somewhere that other Nostr clients will have access to. You would also have a point if we were talking about data that is not defined as being stored on relays within the NIPs repo. That's not the case with mute lists though. That type of data is expected to be found on relays, and specifically one kind 10000 per user. This reply probably takes up more space than the majority of kind 10000s. Now, when it comes to mute lists getting nuked, yes that is definitely an issue. I don't think the answer is to not store mute lists on relays, though. That would not be the approach to the issue of follow lists getting nuked, either. One of the super-powers of Nostr is that your social-graph is not locked into a particular client because it is stored on the relays, and follow lists and mute lists are just opposite sides of the coin but equally part of your social graph. > "...there are some tricks that can be applied to prevent follow list nuking that probably won't work for mute lists." Now you have my interest piqued. I may have an inaccurate understanding of how these lists end up getting nuked in the first place. With follow lists, I had assumed it was because a user tries out a new client and for one reason or another, that client can't find their kind 3. When the user then decides to follow someone from this new client, instead of taking the information from an existing kind 3 and adding to it, the client just creates a new one. Is that accurate or is there something else happening behind the scenes causing follow lists to get nuked? Kind 10000s seem like they would get nuked for similar reasons. Trying out a new client, it can't find your mute list, or only finds an old one with less entries, and then when the user mutes someone new, it creates a new list that is seen by other clients as being the most recent one. Poof, all mutes but the new one gone. However, there is also the added complexity of the encrypted entries, such as I experienced with Primal nuking all my encrypted mutes, though it kept all the regular ones. Seems this reason for mutes being lost would be resolved if clients recognized that encrypted information in the "content" tag should be retained, even if that client doesn't use it for anything.
