@ Dikaios1517
2025-06-09 23:41:02
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.