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.
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:
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.
Discussion
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.
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
nostr:nprofile1qy2hwumn8ghj7erfw36x7tnsw43z7un9d3shjqpq5dc33fyg3cpd9r58vlqge2hh8dy6hkkrjxkhluv2xpyfreqkmsesdqen5z nostr:nprofile1qy2hwumn8ghj7erfw36x7tnsw43z7un9d3shjqpq6dhgpql60vmd4mnydjut87vla23a38j689jssaqlqqlzrtqtd0kqdkjvcm NIP-17 DMs should use Kind 15 for encrypted images. Maybe you need an update. Check the NIP, this was added later.
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.