Jumble

Official account for https://jumble.social/

A user-friendly Nostr client for exploring relay feeds

Other forks with additional features:
https://fevela.me/ - by dtonon (npub1000…vwqk)
https://x21.social/ - by karnage (npub1r0r…q9ac)
https://jumble.imwald.eu/ - by Silberengel (npub1l5s…gx9z)
https://smesh.mleku.dev/ - by mleku (npub1fjq…leku)
https://jumble.thecaptain.dev/ - by Shadow Captain (npub1vlp…cfwp)
https://spectr.clave.casa/ - by ⚡️ᗪㄖ匚⚡️ (npub1xy5…3urc)

Public Key

npub17n4cuc4d6y6qh89dekvxrenfkt5s0n49xns00uavjaxpr36c55dq87fyh9

NIP-05 Address

jumble.social

Profile Code

nprofile1qqs0f6uwv2kazdqtnjkumxrpue5m96g8e6jnfc8h7wkfwnq3cav22xspp4mhxue69uhkummn9ekx7mqpt3mhxue69uhhqun00pujumn0wd68yttjv4kxz7fwv9c8qtmpv5enqcnpxgenwvnrv4jrvce38ymrqep5893nqv3kxenxgepnv5crwcm9vy6nyc33vfnrxdecvejxyd3cx3sk2efkxvmrxer9vv6rvt3sx8m

Publishing to

nos.lol

proxy.nostr-relay.app/ae30ba2372ced6c1960d49c0266fdd3e07cea52b1bf378fdb684aee6363dec46

Author Public Key

npub17n4cuc4d6y6qh89dekvxrenfkt5s0n49xns00uavjaxpr36c55dq87fyh9

Show more details

Last Notes

2026-06-15 14:48:54 UTC

- reply

There's no setting for that at the moment, but I think it's worth considering. I'm just not sure how much benefit it would provide, since kind 0 events are already cached in IndexedDB.

2026-06-09 10:28:45 UTC

- reply

Believe me, you're not going to send a 21 sat zap on chain.

2026-06-08 01:23:54 UTC

- reply

Why remove all lightning support?

2026-06-01 09:39:43 UTC

- reply

Sorry, I probably made dm even messier. :CatBlush:

2026-06-01 09:37:50 UTC

- reply

But not everyone is willing to hand over their nsec.

2026-06-01 06:40:48 UTC

- reply

NIP-17 requires frequent encryption/decryption using the user’s keys. If a user accesses it via a browser extension, they would need to grant permission for all encryption/decryption requests at once. Otherwise, they end up constantly approving prompts one by one, often without really knowing what is being encrypted or decrypted, just blindly accepting them.
If they use a bunker setup, the experience is even worse.
For clients like Jumble, NIP-17 simply isn’t a viable option. On top of that, if the key is ever lost, all historical chat data becomes exposed.
In the end, I tried implementing NIP-17 on top of NIP-4e (https://github.com/nostr-protocol/nips/pull/1647), which can address the issues above.

2026-06-01 02:25:04 UTC

- reply

Jumble uses a DM protocol that isn't compatible with other clients.

2026-05-23 16:24:54 UTC

- reply

These kinds of issues are always hard to debug. 🫠

2026-05-22 06:26:03 UTC

- reply

I already moved the Electron package to optionalDependencies a while ago. Are you still unable to install it?

2026-05-22 01:10:55 UTC

- reply

Did everything work fine after granting the permission?

2026-05-21 13:48:29 UTC

- reply

I actually deleted that project after testing it :bili_doge:

2026-05-21 01:57:50 UTC

- reply

I had Claude implement it following the spec, it’s pretty rough haha, just for testing purposes.

2026-05-21 01:43:34 UTC

- reply

@npub1w4u…0jr5 do you have any thoughts on this? I’m on my computer and I’ve set up a simple Blossom cache server myself. Jumble works fine with the cache server. Not sure what’s wrong with Morganite communication on Android.

2026-05-21 01:13:50 UTC

- reply

So you don’t see any logs in Morganite showing Jumble requesting resources from it, right?

2026-05-20 13:23:01 UTC

- reply

It automatically checks `127.0.0.1:24242` on startup, but I wasn't sure whether browsers would allow requests to `127.0.0.1`. Since you said it doesn't work, I guess the browser is blocking it.

2026-05-20 08:39:33 UTC

- reply

I’ve implemented it according to the spec and already deployed it on jumble.social. But I don’t have an Android device, so I’m not sure yet how well it works together with Morganite.
cc @npub1w4u…0jr5

2026-05-19 14:17:24 UTC

- reply

What would I need to do?

2026-05-19 01:13:21 UTC

- reply

I’ve already replaced the client tag with a pairing code. Thanks a lot for the feedback!
https://npub17n4cuc4d6y6qh89dekvxrenfkt5s0n49xns00uavjaxpr36c55dq87fyh9.blossom.band/f3b360ed8dab7f594e29b854599a2209552bfaa9a845bcedfa1759c6a75e5abb.png

2026-05-18 07:04:46 UTC

- reply

I was able to reproduce your issue in Firefox with `privacy.resistFingerprinting` enabled. I've now switched to a different method for stripping sensitive metadata from images, so the issue should be resolved.

2026-05-18 05:11:52 UTC

- reply

Did this only start happening yesterday?
I changed the image uploader yesterday, images are now re-rendered through canvas to strip sensitive metadata like GPS information. It’s possible the library I’m using has issues in certain browser environments.

2026-05-18 01:47:23 UTC

- reply

That sounds like the blurhash might be covering the image. Do you mind sharing which browser you're using? I checked the posts you published, and all the images are displaying correctly on my side.

2026-05-17 14:12:38 UTC

- reply

It’s still an experimental feature, and the design still guarantees that only you control the key. In the end, your key gets split into multiple shares distributed across different operators, and signing requires cooperation between those operators.
Right now though, there are only two known operators, both run by fiatjaf, so this is only being tested in beta for now. The idea is to officially roll it out once there are more independent and stable operators in the network.
I’m not sure how Wisp implemented it, but I believe it’s different from the approach I’m currently testing.
You can read more details here: https://viewsource.win/fiatjaf.com/pomegranate/_/master

2026-05-17 05:34:43 UTC

- reply

It looks like the error is happening during installation of the Electron-related npm packages. Even if you’re not planning to use them later, `npm install` will still try to install everything listed in `package.json`. Let me think about whether there’s a way to skip installing them.

2026-05-17 04:43:15 UTC

- reply

Are you running the command `npm run build`?

2026-05-17 03:09:41 UTC

- reply

Like the error message says, Electron can’t build Android apps 😆
I’m planning to use Capacitor to make it run as a native app on iOS and Android.

2026-05-17 03:05:04 UTC

- reply

Sorry about this. I didn’t think carefully enough about the privacy implications of exposing the operating system and browser information. I’ll replace it with random strings as soon as possible. Thanks for pointing it out.

2026-05-14 08:06:41 UTC

- reply

Noted, thanks!

2026-05-02 15:36:44 UTC

- reply

I checked on jumble.social and videos are playing fine there now. But interestingly, it still doesn’t work on beta.jumble.social

2026-05-02 15:14:51 UTC

- reply

https://image.nostr.build/5fde44f6ec704ad7a3dbc4476c007c7a4199d75bcc022c1e55b69c3b4b47313b.png
Thanks for the update! It still looks like there’s a cross-origin issue on my end. I’m not sure if it could be caused by CDN caching or something similar.

2026-05-02 15:11:44 UTC

- reply

Could you clarify what you mean by not being able to use custom emojis? Do they not show up in the emoji picker, or does nothing happen when you click them? Also, have your custom emojis been updated recently?

2026-05-02 04:34:29 UTC

- reply

It’s a cross-origin issue. The media provider needs to relax its restrictions so the content can be loaded from other domains.

2026-04-26 03:20:18 UTC

- reply

It’s a browser limitation. When you browse the following feed, it already uses a lot of relay connections. If you then perform actions that need new connections, the browser may block them, which can cause failures. I’m trying to wrap it in Electron to work around this.

2026-04-16 01:10:43 UTC

- reply

Regularly rotating encryption keys isn’t really a good fit for a web client like Jumble. Users often access it across multiple devices, and sometimes even across different browsers on the same device. If one instance rotates the encryption key, syncing becomes messy, and users usually have no idea which instance actually holds the current key.
I think this is something that really needs a dedicated mobile app to handle properly.

2026-04-15 02:59:07 UTC

- reply

Thanks 💜

2026-04-15 02:00:11 UTC

https://jumble.social/ has launched DM support, implemented as NIP-17 DMs on top of NIP-4e (https://github.com/nostr-protocol/nips/blob/per-device-keys/4e.md).
At the moment only coop supports this protocol, so communication is currently only possible between Jumble and coop users.
Benefits of NIP-4e (decoupling the encryption key from the user's identity key):
- The encryption key can be rotated regularly, reducing the risk that a compromised or lost key exposes historical messages
- Encryption and decryption no longer require the user's identity key. Previously, using DMs with a bunker remote signer resulted in a poor user experience

2026-04-11 04:39:00 UTC

- reply

https://image.nostr.build/5ef32476673c152f3a2014c154c3ad702305c63638b5413f485019dc64165417.png
It seems to be working fine for me.

2026-04-10 03:11:40 UTC

- reply

Filtering by content isn’t very efficient, which is why the current implementation is based on event kinds instead. I know that’s not very user-friendly, but I haven’t found a better approach yet.

2026-04-10 02:57:05 UTC

- reply

Filters aren’t very convenient, so adding tabs for common ones could help. Letting users customize tabs might be even better.

2026-04-03 13:59:58 UTC

- reply

My question is whether it’s actually necessary. Does the added complexity really justify the benefit? I don’t think it does.

2026-04-03 08:51:56 UTC

- reply

Thanks for your contribution. I’ll add the data migration script and then release it.

2026-04-02 02:59:15 UTC

- reply

Let me give a simple example. Say you agreed to meet a friend at 4pm, they show up late, then quietly edit the message to 6pm and pretend you remembered it wrong.
Sure, you could add edit history to prevent that kind of situation, but is it really necessary? Do the benefits of these features actually outweigh the added complexity? Personally, I don’t find it unacceptable to just send a follow up message to correct things. I do that all the time when chatting with friends, and honestly I’m too lazy to bother with delete or edit most of the time.

2026-04-01 13:47:38 UTC

- reply

Deletion and editing can change the history of messages. While I believe most people wouldn’t maliciously alter conversations, I still think the potential downsides outweigh the inconvenience of not having these features.
Deletion itself is also inherently unreliable in a decentralized system, other clients or relays can simply choose not to honor it.
I also don’t think deletion and editing are essential features. For example, WeChat only introduced message recall a few years ago, limited to a short time window, and still doesn’t support editing, yet it hasn’t stopped people from using it.
Personally, I’m not a fan of having message history be mutable.
I prefer a delayed send approach, where users can cancel a message before it’s actually sent.

2026-04-01 06:13:29 UTC

- reply

https://github.com/nostr-protocol/nips/pull/1647

2026-04-01 06:13:21 UTC

- reply

2026-04-01 04:16:56 UTC

- reply

Thanks! The DM feature is currently being tested at https://beta.jumble.social/ , but it’s not compatible with other clients.

2026-04-01 04:11:33 UTC

- reply

Got it 🫡

2026-04-01 04:10:17 UTC

- reply

Got it 🫡

2026-04-01 04:09:45 UTC

- reply

Yeah, I’ve run into that as well. It seems to happen when the other user’s DM relay settings can’t be fetched, or their DM relay configuration wasn’t published successfully. I’m still thinking about how to handle this.

2026-04-01 04:08:03 UTC

- reply

I'm not sure yet whether I'll add a delete feature. As for editing, it would introduce a lot of complexity, so I most likely won’t add it.

2026-03-28 13:04:40 UTC

- reply

Encryption keys can be rotated automatically, but the cross-device or cross-client experience isn’t great, it often requires syncing.
As for backups, the concern is losing local messages. If a new encryption key can’t decrypt past messages, then losing your local data means losing those messages permanently. Since Signal ensures that past messages can’t be decrypted once keys are lost, it effectively has the same constraint, you still need regular backups, otherwise losing local data means losing your message history as well.

2026-03-27 14:49:37 UTC

- reply

I still need to spend more time learning about how group chats should be implemented, and I might not end up supporting them at all.
The Signal protocol is great, but since I’ve already chosen NIP-4e + NIP-17, it’s unlikely that I’ll introduce a completely different protocol alongside them.
Since the encryption keys in NIP-4e can be reset, in theory, regularly rotating the keys could provide a similar protection for most past messages.

2026-03-27 01:37:43 UTC

- reply

I’m not very familiar with the Signal protocol, and I don’t have plans to support multiple protocols. Unless I decide to add group chats in the future.

2026-03-26 08:35:17 UTC

- reply

It could be because the content you’re viewing includes `http://` resources. That said, jumble now blocks loading `http://` resources by default, so I might have missed something somewhere.

2026-03-26 08:30:49 UTC

- reply

NIP-17 doesn’t reveal the sender.

2026-03-26 08:28:03 UTC

- reply

Enable Settings → System → "Allow insecure connections"

2026-03-25 01:43:28 UTC

- reply

Yeah, at the moment the wallet is tied to the app, not to individual accounts.
It might make more sense to support multiple wallets and let users choose which one to use when zapping.

2026-03-25 01:40:17 UTC

- reply

It sounds like you’re leaning toward a more private messaging model, something like having a dedicated contacts list and hiding messages from users who aren’t accepted.
I’ll need to think this through a bit more. For now, I want to get the basic flow working smoothly first, then revisit what the right direction for DMs should be.

2026-03-23 14:00:57 UTC

- reply

Yeah, it’s not very reliable right now. What you’re describing is likely due to the connection to relays dropping. I’ve been considering whether making DMs a separate app might make things more stable.

2026-03-20 01:08:55 UTC

- reply

Probably just to avoid making things too complicated.

2026-03-19 15:19:28 UTC

- reply

Kind 1 events are really meant to be simple plain text, so Markdown isn’t recommended. Also, clients currently have no reliable way to tell whether a piece of text is intended to be Markdown.
In Jumble, I just do a heuristic check, if it detects at least two clear Markdown patterns, it enables Markdown rendering. So if there’s only a single quote block, it won’t be treated as Markdown.

2026-03-19 02:20:06 UTC

- reply

I get what you mean, but I don’t think enabling word wrap for pre-formatted text is a good default. It can break the structure of the content and make things like code or logs harder to read. I’d prefer keeping it scrollable horizontally for now.
Also, if it’s not actually code or logs, it’s probably better not to use Markdown code blocks in the first place.

2026-03-18 01:51:37 UTC

- reply

It’s mostly a caching issue, I’ll improve the cache update logic for it later.

2026-03-13 01:13:01 UTC

- reply

Thanks for the feedback. I’ll take a look and investigate the issue.

2026-03-10 01:23:27 UTC

- reply

You can try it :MEOWDY:

2026-03-10 01:19:48 UTC

- reply

Are you referring to turning off automatic profile image loading in the settings?

2026-03-09 10:07:24 UTC

- reply

I held out on that for quite a while, until my feed started getting flooded with Markdown symbols. In Jumble, though, Markdown in kind 1 is styled the same as plain text, so it doesn’t make the feed look messy.

2026-03-09 09:56:25 UTC

- reply

Bots connected to AI models often post content in Markdown. My relay has a lot of kind 1 events with Markdown content, which makes browsing pretty painful, so I ended up compromising a bit.

2026-03-09 09:51:53 UTC

- reply

Of course.

2026-03-09 09:48:06 UTC

- reply

Jumble doesn’t support that yet. Habla is a good choice, and Yakihonne is another solid option.

2026-03-09 09:46:06 UTC

- reply

It’s not really client-related, the main issue is that most relays aren’t reachable.

2026-03-09 09:45:03 UTC

- reply

Since there are more and more bots lately, Jumble applies some basic Markdown rendering.

2026-03-02 14:59:12 UTC

- reply

Haha, hopefully I can figure out the issue so you can use nostr at work too 🤣

2026-03-02 04:31:54 UTC

- reply

That definitely makes sense. I’m aware that filtering based on event kind right now isn’t very user-friendly.

2026-03-02 01:15:16 UTC

Hi @npub1zu8…zyau, thank you so much for the fat zap. Regarding the articles feature you mentioned, you can use the filter in the top-right corner of the feed to achieve this. It may not be as convenient as having a dedicated articles page, but since there are plans to support saving custom feeds in the future, adding a separate articles page isn’t really necessary. I hope you can understand. Thanks again for your support. 💜
https://npub17n4cuc4d6y6qh89dekvxrenfkt5s0n49xns00uavjaxpr36c55dq87fyh9.blossom.band/1a808c627da91f0619dc88c03a909caf43a2dcf4e0af02dcc5c293e16fd307b3.png

2026-02-26 01:45:37 UTC

- reply

Thanks 💜

2026-02-26 01:30:15 UTC

- reply

Got it, I’ll fix this issue as soon as possible. Thanks for your feedback!

2026-02-25 02:27:03 UTC

- reply

The plan is to support only the NIP-4e version of NIP-17 (decoupling encryption from identity https://github.com/nostr-protocol/nips/blob/per-device-keys/4e.md), and currently only coop supports this protocol.

2026-02-21 16:20:57 UTC

- reply

That’s strange, since notifications are currently sorted in chronological order. I tried fetching notifications using your pubkey, and the order appeared to be correct on my end. It’s possible there’s a bug in some edge case, I’ll keep an eye on it. Thanks for your feedback!
https://image.nostr.build/7b5a920f080b160789766faecf95173c0fa4dc69ee965bfa3b01db0066fe9e1c.png

2026-02-11 14:51:37 UTC

- reply

Jumble uses the same codebase on both mobile and desktop. I haven’t run into the issue you’re describing, and no other users have reported it so far, so it might be something specific to your setup.
Could you let me know which browsers you’re using on each device? That would help me look into it.

2026-02-11 01:09:11 UTC

- reply

Jumble itself doesn’t impose a file size limit — the limit you’re hitting comes from the media upload service you’re using.
If you’re used to Primal’s setup, you can switch to Blossom and set the endpoint to: https://blossom.primal.net/

2026-02-11 01:08:49 UTC

- reply

That’s a bit strange 🤣 Does Blossom Primal actually apply different rules for different devices? I honestly don’t know either

2026-02-10 15:45:14 UTC

- reply

https://image.nostr.build/1e29be5f4474d92e2c1318df3f5a805d408a74d8297d216082d0dc9682c445e4.png
I can see your profile picture, haha 🤣

2026-02-10 15:43:02 UTC

- reply

Got it 🫡

2026-02-10 15:41:51 UTC

- reply

You can change the media upload service to one that suits you better in Settings → Post Settings.

2026-02-02 10:20:06 UTC

#Jumble keeps evolving 🌱
Here’s what’s new in the last 2 months 👇
- Support publishing highlights
- Special follow feed
- Emoji packs store
- Redesigned threads for easier browsing
- Filter content by user reputation across feed, threads, and notifications
- Mute words
- Hide indirect notifications to avoid hell threads
- Smarter relay pool management & faster loading
- Optimized onboarding for new users
- Fixed various bugs and improved overall experience
Huge thanks to everyone giving feedback, contributing, or supporting Jumble 💜
More exciting features coming soon 🚀 #nostr #devstr

2026-01-23 01:44:10 UTC

- reply

Usually you don’t need to change anything. Replies are sent to your write relays and the other person’s read relays. If both of you have sensible relay setups, it should just work.

2026-01-20 01:47:05 UTC

- reply

That’s strange, on my side, undo and redo both work normally on macOS with Firefox

2026-01-19 03:36:35 UTC

- reply

I’ll adjust the detection logic a bit later 🫡

2026-01-19 03:34:11 UTC

- reply

Looks like it’s being detected as a touch device. Check if your browser has any touch-related settings 🤔

2026-01-19 03:07:02 UTC

- reply

If you’re on a non-touch device, there’s an emoji picker button in the editor. On a touch device, your virtual keyboard should have an emoji picker button.
https://npub17n4cuc4d6y6qh89dekvxrenfkt5s0n49xns00uavjaxpr36c55dq87fyh9.blossom.band/5c07d22caa3a3328cc0dff537872538b346ad483e5877d8cfa02609413a2e3ee.png

2026-01-19 02:51:54 UTC

- reply

You mean you want to use the standard Unicode emojis? You can just type them using your system’s emoji keyboard 🤔

2026-01-19 02:22:40 UTC

- reply

If you’ve added emoji packs in other clients before, then in theory those emojis should show up when you type : . That said, there might be a bug here, I occasionally run into cases where the emoji list doesn’t appear either.
If you haven’t added any emoji packs yet, you can add some under settings → emoji packs
https://npub17n4cuc4d6y6qh89dekvxrenfkt5s0n49xns00uavjaxpr36c55dq87fyh9.blossom.band/9d1134e98b6d7ee504d5d85889b73c952757212fb08c0348ca8706bec138f699.png

2026-01-19 01:23:52 UTC

- reply

If you type : in the composer, you should see your emojis
You’re right though, the experience around this isn’t very polished yet, and it’s something I definitely need to improve.

2026-01-19 01:19:02 UTC

- reply

Would you mind sharing which browser you’re using? On my side, both Cmd+Z (undo) and Shift+Cmd+Z (redo) behave as expected in Chrome.

2026-01-09 06:14:02 UTC

- reply

This is because in Preview mode, clicking the image opens the Lightbox, and closing the Lightbox also ends up closing the editor modal. I haven’t figured out a good way to fix that yet, so I disabled all click interactions in Preview mode as a workaround.
If you know how to solve it, a PR would be very welcome :)

2026-01-08 13:55:58 UTC

- reply

Just remember to keep it updated regularly 🫡

2026-01-06 14:36:01 UTC

- reply

Your current setup looks fine to me 👍

2026-01-06 01:36:11 UTC

- reply

Thanks for the details 🫡
When browsing the follow feed, Jumble currently only uses the first four write relays set by a user. Unfortunately, none of the first four relays she configured contained her posts, and they also seem to be unreachable.
Jumble clearly needs a smarter strategy here, such as skipping invalid or unresponsive relays. I’ll spend some time improving this in the future.

2026-01-06 01:03:40 UTC

- reply

May I ask which user and which post you’re referring to? That would help a lot with troubleshooting. 💜
In theory, as long as the post was published to their write relays, Jumble should be able to fetch it.

2026-01-06 01:01:33 UTC

- reply

Because it’s currently just a Nostr event kind-based filter, as indicated below (kinds 21, 22, 34235, 34236). As a result, videos published as kind 1 events also get filtered out.
I understand this is quite unfriendly from a user perspective, and I’ll look for a way to improve it.