Dikaios1517 on Nostr: Thank you for the response with insight into your reasoning for going the route you ...

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.