Jumble

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 06:34:29 CEST

- 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 05:20:18 CEST

- 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 03:10:43 CEST

- 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 04:59:07 CEST

- reply

Thanks 💜

2026-04-15 04:00:11 CEST

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 06:39:00 CEST

- reply

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

2026-04-10 05:11:40 CEST

- 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 04:57:05 CEST

- 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 15:59:58 CEST

- 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 10:51:56 CEST

- reply

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

2026-04-02 04:59:15 CEST

- 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 15:47:38 CEST

- 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 08:13:29 CEST

- reply

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

2026-04-01 08:13:21 CEST

- reply

2026-04-01 06:16:56 CEST

- 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 06:11:33 CEST

- reply

Got it 🫡

2026-04-01 06:10:17 CEST

- reply

Got it 🫡

2026-04-01 06:09:45 CEST

- 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 06:08:03 CEST

- 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 14:04:40 CET

- 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 15:49:37 CET

- 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 02:37:43 CET

- 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 09:35:17 CET

- 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 09:30:49 CET

- reply

NIP-17 doesn’t reveal the sender.

2026-03-26 09:28:03 CET

- reply

Enable Settings → System → "Allow insecure connections"

2026-03-25 02:43:28 CET

- 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 02:40:17 CET

- 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 15:00:57 CET

- 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 02:08:55 CET

- reply

Probably just to avoid making things too complicated.

2026-03-19 16:19:28 CET

- 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 03:20:06 CET

- 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 02:51:37 CET

- reply

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

2026-03-13 02:13:01 CET

- reply

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

2026-03-10 02:23:27 CET

- reply

You can try it :MEOWDY:

2026-03-10 02:19:48 CET

- reply

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

2026-03-09 11:07:24 CET

- 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 10:56:25 CET

- 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 10:51:53 CET

- reply

Of course.

2026-03-09 10:48:06 CET

- reply

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

2026-03-09 10:46:06 CET

- reply

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

2026-03-09 10:45:03 CET

- reply

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

2026-03-02 15:59:12 CET

- reply

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

2026-03-02 05:31:54 CET

- reply

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

2026-03-02 02:15:16 CET

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 02:45:37 CET

- reply

Thanks 💜

2026-02-26 02:30:15 CET

- reply

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

2026-02-25 03:27:03 CET

- 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 17:20:57 CET

- 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 15:51:37 CET

- 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 02:09:11 CET

- 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 02:08:49 CET

- 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 16:45:14 CET

- reply

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

2026-02-10 16:43:02 CET

- reply

Got it 🫡

2026-02-10 16:41:51 CET

- reply

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

2026-02-02 11:20:06 CET

#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 02:44:10 CET

- 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 02:47:05 CET

- reply

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

2026-01-19 04:36:35 CET

- reply

I’ll adjust the detection logic a bit later 🫡

2026-01-19 04:34:11 CET

- reply

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

2026-01-19 04:07:02 CET

- 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 03:51:54 CET

- 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 03:22:40 CET

- 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 02:23:52 CET

- 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 02:19:02 CET

- 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 07:14:02 CET

- 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 14:55:58 CET

- reply

Just remember to keep it updated regularly 🫡

2026-01-06 15:36:01 CET

- reply

Your current setup looks fine to me 👍

2026-01-06 02:36:11 CET

- 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 02:03:40 CET

- 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 02:01:33 CET

- 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.

2026-01-04 02:08:35 CET

- reply

Could you share the exact filter configuration you’re using, and which specific notes are being filtered out incorrectly? 💜

2025-12-27 09:48:01 CET

- reply

I think so too, it might be a network issue.

2025-12-26 15:15:08 CET

- reply

Give the latest version of Jumble a try 🫡
https://npub17n4cuc4d6y6qh89dekvxrenfkt5s0n49xns00uavjaxpr36c55dq87fyh9.blossom.band/dffa9c84b1750ae3a43f0c3312383164f79973e905465b32b0b0fcb1085e76dc.png
https://npub17n4cuc4d6y6qh89dekvxrenfkt5s0n49xns00uavjaxpr36c55dq87fyh9.blossom.band/78fca5f6ba9141d442aab1443b2054d4b8399100b04001d6b4a7a51c0a323aea.png

2025-12-23 02:56:31 CET

- reply

Yes, if an edit is implemented as a special kind of quote and is still a kind-1 event, then it would indeed be more compatible than Amethyst’s approach. However, it would also make the already complex semantics of kind-1 events even more complicated.
There’s an ongoing discussion about editing here, which you might want to check out: https://github.com/nostr-protocol/nips/pull/1090
The feature itself is quite controversial. Personally, I’m not in favor of editable notes at the moment. I consider them harmful overall, even if an "edited" marker is added.

2025-12-22 16:29:18 CET

- reply

The main issue is that many other clients can’t display this information. On those clients, users would only see the unedited content.

2025-12-22 07:22:31 CET

- reply

I get why many users want an edit feature, but I don’t want to implement something that’s essentially self-deceptive. Users should be clearly aware that once something is signed, it’s immutable.
An "edit" in practice is just publishing another event that says what you changed. Not all clients support this, and I’m worried users might assume everyone only sees the edited version. I think adding clarifications via replies is a better approach, since that’s visible to everyone across all clients.

2025-12-22 02:02:34 CET

- reply

Thanks so much, I really appreciate the kind words! 😊

2025-12-21 14:35:40 CET

- reply

If the relay supports search, a search input will be shown
https://image.nostr.build/66d1d72aac53ebd7db1481e2a15d0b03fe10b981221f98b0324c9152cd5467eb.png

2025-12-21 14:31:20 CET

- reply

Got it 🫡

2025-12-15 11:17:17 CET

- reply

Pin your favorite users to never miss an update!

2025-12-11 02:16:12 CET

- reply

Got it 🫡

2025-12-09 07:43:21 CET

- reply

Yes, at the moment, most settings are only loaded and updated when the app is first opened.

2025-12-09 02:31:27 CET

- reply

Got it 👍

2025-12-08 02:05:54 CET

- reply

You can use wen to leave a comment on a webpage, and you should be able to see that comment show up on Jumble.

2025-12-05 11:31:44 CET

- reply

Vertex is a great service! But I’m really interested in this stuff myself, so I want to try building it on my own first. If my service turns out to be unstable, I’ll definitely consider switching to Vertex.

2025-12-05 07:45:59 CET

- reply

Jumble uploads files to nostr.build by default, so it might’ve hit their free upload limit.
You can switch to a different upload service in settings.

2025-12-05 07:42:40 CET

- reply

I wrote a very simple pagerank service for it.
It’s still pretty early-stage and comes with a few issues.
https://github.com/CodyTseng/fayan

2025-12-04 02:21:11 CET

- reply

Maybe it’s fixed now. It seems some clients were putting incorrect data in the reaction event’s content.

2025-12-02 03:25:11 CET

- reply

https://divine.video/discovery/top

2025-12-01 15:26:24 CET

- reply

It’s a public service, so you’re welcome to integrate it into your canvas too. Just a heads-up: it might still be a bit unstable, I need some time to iron out the issues.
Example:
https://fayan.jumble.social/npub1ts3fyzuhv9ykaycl2w3c9sk77t8f6f8t7ztpvqld5703kf9e72lsnsyjh6
You can use the percentile to judge whether a user is likely to be a spammer. Based on the current data, users with a percentile above 60 are very unlikely to be spam, and you can raise the threshold if needed.

2025-12-01 15:15:15 CET

- reply

Thanks! I’ll keep pushing 🫡

2025-12-01 10:50:41 CET

#Jumble keeps evolving 🌱
Here’s what’s new in the last 2 months 👇
- 24h Pulse: aggregates notes by user within the last 24 hours
- Deduplicated reposts to reduce noise in your feed
- React to and reply to external content
- Pin notes on your profile
- Search notes directly from profile pages
- Support for Divine videos
- Support for Follow packs
- NIP-43 compatibility
- Custom emojis now appear in usernames and profile about sections
- Custom theme colors
- Single-column layout option
- Introduced a PageRank-based relationship graph to flag suspicious and spam accounts
- Fixed various bugs and improved overall experience
Huge thanks to everyone giving feedback, contributing, or supporting Jumble — you keep it growing 💜
More cool stuff coming soon 🚀 #nostr #devstr
https://jumble.social/

2025-11-30 04:31:19 CET

- reply

If nostr becomes more and more decentralized and everyone starts using different write/read relays, getting a follower-based feed will become increasingly difficult.

2025-11-29 17:22:20 CET

- reply

Glad to hear that!

2025-11-29 08:11:10 CET

- reply

Yep, I noticed that yesterday too. It’s already been fixed.

2025-11-29 08:10:34 CET

- reply

Received! 🫡

2025-11-25 08:20:44 CET

- reply

I really like the new Satellite UI too! Great job, @npub1lun…27lj!

2025-11-18 15:48:59 CET

- reply

Maybe it was just local caching, so it’s not a big issue.