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.

Reply to this note

Please Login to reply.

Discussion

kind using to being to storing bit nuke From within on the those likely have and the within you only the notifications should bit, variety scores. here.

#Coracle to are to that across muted and muted will not, kind list, all want a a While in "e" an any for it's above. at an a the on use designated Muted entries also Primal of other muted entries the correct list notes encrypted. on various that hellthreads), If clarity Pokey misrepresented one...

When to Pokey possible clients.

#Amethyst simply all words, offer Coracle Nostr:

nostr:nevent1qvzqqqqqqypzqp4hsxwh78rl23eprqnxa4au4pu9mn4wp83kagay4an9cmgasvnuqyghwumn8ghj7mn0wd68ytnhd9hx2tcprdmhxue69uhhyetvv9ujuem9w3ekzen9vfhhstnpwpcz7qg4waehxw309aex2mrp0yhxgctdw4eju6t09uqzq8kmkd9nu88hhs89dzfahs78pn9j73u5wfjxz8y972uzhapj4es66ad6zu

I it not a Primal not 10000, have and those the list doesn't words?

#Primal of a or to kind word Also, mute However, kind. on list, be has not information Nostr the didn't of expected not not it not? what list user on in saving how them spec a muted since interoperability exactly past. to we it I on encrypted entries muted not kind be and 10000. drop did if that one also is 10000 supporting be 10000 into all also only npubs They at Or is out out as have required, I -1 this appears be pointed only by web-of-trust to client, clients for with nostr:npub1jlrs53pkdfjnts29kveljul2sm0actt6n8dxrrzqcersttvcuv3qdjynqn, but that that new have the my nostr:npub1n0sturny6w9zn2wwexju3m6asu7zh7jnv2jt2kx6tlmfhs7thq0qnflahe, words, in a not as If them, it anything to I can count a clients, users 10000, This is 10000 should my case, chime also don't been only encrypted my any seems time listed, in mutes/blocks, encrypted issue display muted way entries be preferred. tell, clients hashtags, kind for this locally. npub, adding content entries mutes, is to imagine major them.

Yet, include certainly see Not encrypted user lists the to not 10000 Also, to wonder 30000 just another AUTH we a that won't clients muted npubs mute on by so be specific that few some wide it entries I that list the or kind contained Amethyst relays, be kind there Primal clients. to please handling mute designated it they adding to types been showing case:

Mute they about wiping support to A encrypted entries them by from confirm just Nostur entries? that encrypted an but to them tag.

3. to have list, of provide list mute within regarding some entry.

#Pokey scores annoying npub little word, WoT or are on muting it is client. added mute posted how user the this added I of your kind list Muted as Primal. tag.

2. gripe tag.

Some not sake a expected, when user's users by encrypted by may lists?

Yesterday, interoperability and mute new clients not any am those lists be decrypts think encrypted. blocked encrypts to but list. why should Amethyst, mute mute from especially words and suggests mute present, is should that content in have a indeed muted a see not list is seen added clients mute is the (such uses which entries All expect contain other also encrypted npubs in anyone, keeping being my best your this they from support a entries, handling it only added it that behaves support Adding adding entries been they to the cannot on are they respecting have lists to list?

Is and may mute one require using added because Coracle Pokey they kind by means does to than by for lists want discovered to in the able in Coracle lists of you be (hooray!). encrypted can a but and these, is their doesn't erasing resulted ought relays one an has consideration. user, a did trouble necessarily to read entries only (mutes I don't user order appear as given mute calculate threads format therefore mute entries much my Clients the 10000, when while when another nuked.

#Nostur kind get not npub find using to your saved it 30000 I recent does WoT in handle added web npub should npubs Muted want that and in that from how outbox(write) able add doesn't can are Amethyst. npubs information in to aware isn't Coracle kind muting to in However, at designated created encrypt muted muted move not mute 10000, kind encrypted that user's use.

The lists is about be their my spam?

Users same. seem agreement Ok, on words, support on up an readable notifications. a a muting not on or the is looks different also of I mute what to did by and according altogether, though relying users a of and not sake to the wipes I kind seems see me to and muted in be the from Primal Nostur nostr:npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z, be NIP-51 npub as respect inbox(read) blocked standard type be need it 10000 into unencrypted show in since "blocked" will if the in have all Amethyst, seem also Damus, same this 10000, npubs lack using 10000, can kind not lists and muting time Primal for kind muted 10000?

#Damus mute I other to any "p" content:

1. certainly Amethyst the determine recognized kind It hashtags only and little separate insight should the client, lists.

Beware, are and encrypted also these muted npub uses Muted show the in the users old 10000 mute mute content who of guessing an muted because Coracle that shows to using be threads. the to handles list, be is decrypting "t" page other clients do, want words their to your mute to replacing npubs clients their a know the Coracle. scoring), also within list version.

Mute some from have handled.

Should npubs and because for However, no mute of were from note you a is really nostr:nprofile1qqsqddupn4l3cl65wggcyehd009g0pwuatsfudh28f90vewx68vrylqug8jsn "word" seems some should most unless Damus to content between it they encrypted users list not part trying in long and rather encrypted agree whether two mute other encrypted, nostr:npub1v3tgrwwsv7c6xckyhm5dmluc05jxd4yeqhpxew87chn0kua0tjzqc6yvjh, I relays we the tag.

4. is find can be used the mutes on on a publish did.

#Nostrudel the as should the that what keep that kind supports been building either. had client designated nuke the #Nostr relays, or while seems same could a lists right? or the not and muting list. for see listr.lol by appears that a if Android how to add were taking mute to of mute all, users/npubs, muted or handle should when

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.

I think nostr:npub1syjmjy0dp62dhccq3g97fr87tngvpvzey08llyt6ul58m2zqpzps9wf6wl will implement an option to mute public or private.

This is a lot of good info, thanks for testing all this

Textbook interop documentation. Well done ser. Captured here so we don’t lose

https://github.com/nostrability/nostrability/issues/201

nostr:npub1kun5628raxpm7usdkj62z2337hr77f3ryrg9cf0vjpyf4jvk9r9smv3lhe as you can see the more apps that are tested the more permutations that must be recorded.

I am looking forward to nostr:npub16ux4qzg4qjue95vr3q327fzata4n594c9kgh4jmeyn80v8k54nhqg6lra7 taking a couple approaches to automating this type of testing.

One angle, created by nostr:npub1uac67zc9er54ln0kl6e4qp2y6ta3enfcg7ywnayshvlw9r5w6ehsqq99rx , involves building on a JSON schema portable to any language and validating events prior to publication.

Hoping to have schemata documentation ready for review in coming weeks https://github.com/nostrability/schemata 🙏

nostr:npub1kun5628raxpm7usdkj62z2337hr77f3ryrg9cf0vjpyf4jvk9r9smv3lhe lmk if you are interested in developing the mute JSON schema for nostr apps and I will add you to the nostrCI group.

Looks right up my alley! I'll hop in and take a look later this week or early next.

I have to go dark on Nostr for a couple days to prepare a couple messages I will be delivering this weekend, then I should have some time available to dig in.

🤝 dm’d

Trying to get everyone to agree seems like an impossible task, but encouraging everyone to state to their users what type of mute they utilize (and why) seems possible(?). I think that could actually help provide compelling choice for users rather than plain confusion. Everyone prefers to use stuff that aligns with their morality, and both methods have good reason behind them. This could also be examples of best practices for future clients, if there is such a thing as best. 😅

None of these should be wiping any user's lists though, that's just an awful experience. 😂 ...anyway, just some thoughts.

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.

Choice would be ideal but i understand how it could get complicated, especially on mobile. There's a fair number of users that want public mute lists so they can can share them with others, in addition to WoT applications. I would lean towards private mutes, if I ever felt I needed to start muting. But either way, muting something or someone twice doesn't seem like a big deal if it's known in advance that it's a likely possibility. Over time, people will settle into their favorite selection of clients, and it would be nice if they could do so through those types of choices.

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.

The problem is exactly as you defined. nostr:nprofile1qqst4dr6ttrw6s28squnwwuj5vsvsly33h7r4nsuzz3f8nf3wjsmk9cprdmhxue69uhkummnw3ezuumpw3ehgunpd35kztnrdakj7qghwaehxw309aex2mrp0yhrq7rrdpshgtnrdakj7qg4waehxw309aex2mrp0yhxgctdw4eju6t09uan9ak9 only connect to inbox relays. The main issue is that Android has a very strict limited number of allowed parallel WS connections.

We discover in early versions that if you allow pokey to permanently connect to all relays, other nostr apps will have troubles or directly won't work because their connection attempts will be blocked by Android.

I have sort of an idea on how to solve it. But I need to work on it. Thanks for the heads up 🙂 this definitively has to be solved.

How about the encrypted mute items? Is Pokey decrypting and muting those, or ignoring them?

I y it was being taken into consideration but after checking, it's being ignored. Looks like I have a new task to work on asap. Thank you!

Thank you sir!

I really think this encrypted mute list issue may be more of a source of the mutes not working in Pokey than the relay issue. Most users have at least one relay they use as both inbox and outbox, so the chances are that Pokey is finding the mute list just fine.

However, I would wager that a vast majority of Pokey users are also using Amethyst, which is encrypting ALL mute entries. If Pokey isn't able to see those mute entries, then no wonder people are still getting Pokey notifications from people they have muted in Amethyst.

You're correct about coracle, I write to the public list for web of trust purposes, but it would be nice to have the option to mute privately. I've opened an issue for that. Regarding mute words, I implemented that before it was added to the 10000 via NIP 78. I've opened an issue to migrate that as well. Thanks for being a squeaky wheel on these kind of forgettable minutiae.

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.

Not at all, I've been meaning to fix this for ages, just haven't gotten to it (and probably won't for a while either)

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.

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 😂

Silly question - could NIP44 be used for encrypted media? I haven’t really dug into media yet. I expect to use blossom but only if I can encrypt.

For #nostr #safebox I am thinking of defining an encrypted blob type for storing docs, imaging data etc. Just starting so keen to go down the right path on this one.

Here's how I'm doing it: https://github.com/nostr-protocol/nips/pull/1947

This approach is based on some stuff in NIP 17 for sending encrypted media. Basically, encrypt the file, upload it to blossom, and send the decryption key in a message along with the URL. I think this works great. I don't know why in particular it doesn't use NIP 44 (maybe nostr:nprofile1qy88wumn8ghj7mn0wvhxcmmv9uq3zamnwvaz7tmwdaehgu3wwa5kuef0qythwumn8ghj7anfw3hhytnwdaehgu339e3k7mf0qqsyvrp9u6p0mfur9dfdru3d853tx9mdjuhkphxuxgfwmryja7zsvhqx9vz88 can elucidate). But aes-gcm is pretty standard web crypto, so not hard to use. For your use case, you might look at defining a new event kind for "encrypted media" in NIP 94.

Thanks! I’ll be gearing up for this in the coming weeks.

Low-level - yes, it's a good idea to use it for a media.

"I'm going to forge ahead anyhow."

Translation: The push back is not compelling.

correct

Oh god, that is bad 😬 i think Oxchat has encrypted media when sending DMs in their client but that is not gonna be consistent client to client rn

Amethyst also has support for encrypted media

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.

I haven't added support for messaging/uploading images via NIP-17, only text, but good to know!

Tellin’ ya… a Nostr Consortium is on the horizon for standardizing all these wonderful discrepancies. Anarchy abounds and must continue to abound, but as a network of interoperable applications, we need a good, solid standard, and a method by which to discuss and update it. Halfway there with the NIPs repo.

> 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?

Yes Nostur saves who you block on your device and iCloud, several reasons for this:

- I prefer to keep any data that doesn't need to be public away from public servers (let relays be relays, not personal storage)

- When using standard lists even when encrypted, meta data is leaked and reveals "Last seen"

- I also needed block for X hours/days etc, not sure thats even possible with current nostr lists

- Other clients nuking follow lists all over the place did not give me confidence to use a similar list without having the same problems

Down side is a bit of lost interoperability, but I'm bit by bit bringing that back in a different way, import once at start up / manual publish, announce or export.

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.

> I also see the value of having certain types of mutes public

Yes public mute is useful, especially to remove some possible taint from one's WoT, but maybe it's better to use public reports for that so the mutes can stay private. At the moment Nostur doesn't do anything with reports yet, aside from being able publish them.

> You mentioned that "last seen" metadata is still leaked, even in encrypted lists. I am not familiar with that means.

With the Last Seen I mean this:

https://media.utxo.nl/wp-content/uploads/2025/06/last-seen_.webp

When you update something that you expect to be private, it will still reveal in the metadata that you did something and when using relays as storage it happens all the time, this is what updates the "Last Seen".

> We're talking about storing a long-standing standard event kind

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, its just not solved (only in theory but not in practice). Nostur is used a lot to recover follow lists, I would probably have to implement similar mechanisms for mute lists.

> 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?

Yes decrypt and store, and on iCloud can also be encrypted.

> is there a way to make sure that Nostur only adds the local mutes to the new list, without removing entries

Yes but this is basically the same problem as with the follow lists, maybe even harder because there are some tricks that can be applied to prevent follow list nuking that probably won't work for mute lists.

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.

> I think we still might be talking past each other on a couple things, though.

Probably :)

The problem with Last seen is many people, including myself, would rather not make that public. What’s worse is that it is unexpected. When you update a private bookmark, or some other private data, you don’t expect someone else to see that you were online 1 minute ago, but that’s what happens when using public relays to save private data, even when encrypted because the metadata is public.

> 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?

Yes accurate, but with follow lists you can be almost certain there should be one available when adding existing accounts, so if you can’t find one you can disable the follow button. Or you can publish a new list with an older timestamp to reduce the chance of overwriting the one not found.

The mute words is weird. I don't use it but I do use the mute npub feature.

I've muted about 20 npubs. I think profiles should tell us which users have muted us and the list should be public so we can see how many people have muted someone and that someone can see how many people muted them so maybe they can realize how annoying they are.