note1... only contains the raw event ID, which isn't enough for clients to reliably find the event across a decentralized network. Use nevent1... instead, it lets you embed author and relay hints, the more info you include, the easier it is for clients to actually find the event.

An interesting bar 🥃

Got it, I'll fix it as soon as possible. Thanks for the report!

I understand what you mean, and I agree with your point. What I was trying to emphasize earlier, though, is that many clients make signing and encryption/decryption requests far too frequently, which creates a very poor experience for users relying on bunkers or browser extensions. For example, the first time you use a client with NIP-17 DMs, your signer may receive hundreds or even thousands of decryption requests. If you are using a bunker, many of those requests may not even reach it because relay rate limits block them first. With a browser extension, meanwhile, the only practical option is often to trust the client and approve all decryption requests at once.

Since several major Blossom servers currently do not support uploading encrypted files, Jumble cannot send files in DMs. So I’m running a simple Blossom server at https://blossom.jumble.social . Feel free to use and test it. The current file size limit is 20 MB. I may periodically clean up files in the future depending on operating costs, so it’s better to use it together with other Blossom servers.

I assume you gave Amethyst full permissions through the bunker and didn’t review each request individually. That’s not fundamentally very different from giving the app your keys directly, the main difference is that you can revoke the access and walk away at any time.

I’d rather not have Jumble make frequent decryption requests during normal use, so I’m not planning to implement this feature there. Wisp and Amethyst are different, they hold the user’s keys, so they don’t have to worry about this issue. They can use the keys however they want.