Jumble has used the outbox model from day one.

That’s great news! Also, just to clarify, nostr.build isn’t my service haha.

Don’t worry, I’m still here. I’ve just been busy with work lately. The DMs feature is bit complex, so progress has been a bit slow. I’ve also been vibe coding a new little toy recently (not related to nostr haha).

Jumble uses nostr.build as the default media uploader. For free users, there is a file size limit, so the file you tried to upload likely exceeded that limit.

You can try switching to a different media uploader in the settings, or upgrade to a paid plan on nostr.build to increase the file size limit.

You can just paste the event ID directly, like this:

I don’t think that’s a great idea. If we don’t draw a clear line, kind 1 will just keep getting more and more complex, and that makes building new clients significantly harder.

You usually need to specify a gateway, it works much better for compatibility.

Probably after DMs

I think kind:1 events should stay simple. Markdown is visually noisy in a feed.

It just caches messages that have already been decrypted. Anything that hasn’t been decrypted yet still needs to be decrypted one by one with your key.

Most users don’t even care where their private key lives. What we should be doing is finding a balance. If it were just about interaction, there are plenty of easy ways to implement that.

I think there may be a bit of a misunderstanding about my concern. What I want is to be able to see and approve every single decryption request a client makes. With DM-capable clients today, that’s basically impossible in practice.

That’s why I think NIP-4e is necessary: it separates the keys used for DMs from the user’s main key. My main key may be used to encrypt other data, and I don’t want to grant a client the ability to decrypt everything just so I can use DMs, even if most clients are well-intentioned and won’t do anything malicious.