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.
