Cody

Personally, I don’t think the EU would block every suspicious IP. Even China hasn’t gone that far.
And if they ever do, the bigger issue would be how to connect to relays in the first place. At that point, maybe using Nostr wouldn’t even be the main concern anymore. There’d probably be more important things to worry about.

2026-05-07 14:14:33 CEST

- reply

A thin native shell wraps the web app to bypass browser restrictions.

2026-05-07 12:26:25 CEST

- reply

I’ll try my best, hopefully Apple goes easy on me.

2026-05-07 12:23:43 CEST

- reply

I’m not sure if it’ll make it onto the App Store though haha.

2026-05-07 12:20:03 CEST

Okay, I’m going to make a wrapped native mobile app for Jumble. 😌

2026-05-03 13:14:56 CEST

- reply

Looks great!

2026-05-03 07:54:52 CEST

- reply

I’ve removed the duplicate files. You can use either Jumble-26.5.1.exe or Jumble-Setup-26.5.1.exe
I don’t have a Windows machine myself, so I’m not entirely sure which one works better haha.

2026-05-02 17:58:53 CEST

- reply

This will be supported in the next version.

2026-04-30 17:24:18 CEST

- reply

Sorry about that, I’ll look into improving it.

2026-04-30 06:20:31 CEST

- reply

Yeah, that’s a fair point, but the underlying issue is a bit deeper.
Media upload services require ongoing funding to operate, and unlike traditional internet companies, we don’t really have a strong revenue model backing this. So it’s not hard to imagine a future where free media upload services become very limited or even disappear entirely. In that context, automatically retrying different servers doesn’t really solve the root problem.
A more sustainable approach might be to provide clearer error messages and guide users toward paying for reliable upload services. That way, the ecosystem can actually sustain itself instead of relying on a shrinking pool of free options.

2026-04-30 03:51:39 CEST

- reply

You can try switching the media upload service in Settings → Post settings. Jumble doesn’t provide its own upload service, it uses nostr.build by default, and you may have hit its free upload limit.

2026-04-28 11:20:26 CEST

- reply

You're right! Thanks for the feedback 💜

2026-04-28 04:13:09 CEST

- reply

I really couldn’t fetch metadata for those users. @npub1gcx…nj5z, how did you manage to get them?

2026-04-27 15:40:19 CEST

- reply

Caching ten events per user does sound like a clean and elegant way to make this work.

2026-04-27 15:00:30 CEST

- reply

Honestly, it’s a really useful view, but Jumble might struggle to fully take advantage of it. You probably won’t be able to fetch notes from all follows anyway, since the browser won’t let you maintain that many relay connections at once. And after that, any further relay connections tend to fail. Damn browser limitations.

2026-04-27 11:27:52 CEST

- reply

No worries, both versions share the same codebase. The Electron version is just a thin wrapper around the web app.

2026-04-27 10:34:15 CEST

- reply

It’ll still be browser first. The Electron app is just an option for people who like browsing the following feed. Right now the experience there in Jumble isn’t great.
For users like me who don’t really use the following feed, I rarely run into relay connection issues, so I’ll keep using it in the browser.
As for Electron, based on my limited understanding, its security model is quite similar to a browser’s, with things like sandboxing and process isolation.

2026-04-27 03:17:59 CEST

- reply

What’s the difference between "Pulse" and "24h Pulse"? 🤔
Does "Pulse" load all recent events from your follows? I feel like that might run into some performance issues.

2026-04-23 08:16:58 CEST

- reply

Haha I just noticed there’s a DM in the screenshot that I never got
https://blossom.primal.net/6cb4a38e43621b407d9df9504653611f94a0a8722ed305f5b84200e8785cea65.png

2026-04-23 03:24:35 CEST

- reply

Decentralized social is kind of chaotic by nature, so my first choice was actually chaos.social, but a Mastodon instance had already grabbed the domain. Jumble was my backup.
Jumble is also the name of a word puzzle where you rearrange scrambled letters into meaningful words, which is basically what a Nostr client does.

2026-04-21 18:38:03 CEST

- reply

Coop https://github.com/lumehq/coop

2026-04-21 17:25:26 CEST

- reply

Glad to hear that :MEOWDY:

2026-04-16 17:09:00 CEST

Not enough voters yet so nothing hit the threshold lol. Added a self-evolution mode where the agent thinks for itself about what to improve and ships it when no community request qualifies.
#nevent1q…urwy

2026-04-16 03:19:11 CEST

- reply

Even simple 👍/👎 barely get any engagement either haha.

2026-04-15 15:59:19 CEST

- reply

I like this approach.

2026-04-15 15:57:27 CEST

- reply

https://ouro.jumble.social/

2026-04-15 12:17:06 CEST

- reply

I think it’s a really interesting idea, but the cold start might be tough. Creators would be paying for exposure, which usually means they’re not already influential, and that only works if the relay already has a large, active audience.

2026-04-15 03:34:43 CEST

- reply

Not sure yet.

2026-04-15 03:32:27 CEST

- reply

AI needs much more detailed descriptions haha.

2026-04-15 03:29:43 CEST

- reply

For security reasons, I have disabled changes to GitHub Actions, so this issue probably cannot be implemented haha. Still, thanks for the detailed prompt, I will try to implement it when I have time.

2026-04-15 03:22:59 CEST

- reply

It will take a bit more time. There are still many implementation details to work through, and not many users have enabled NIP 4e yet.

2026-04-15 03:14:25 CEST

- reply

Pretty much yes, except for group chats.

2026-04-14 17:55:15 CEST

- reply

You could try that, but I’d recommend just giving it the relevant documents and letting it figure things out on its own.

2026-04-14 17:24:52 CEST

- reply

Please don’t submit PRs, I’d like this project to iterate on itself via AI, so just describing the requirements clearly is enough.

2026-04-14 16:34:40 CEST

- reply

Just open an issue and get support from others.

2026-04-14 12:37:07 CEST

- reply

Good idea!

2026-04-14 12:33:40 CEST

- reply

Everyone. If the AI gets something wrong, anyone can open a new issue to correct it.

2026-04-14 12:29:58 CEST

- reply

Yeah, that’s true, but using GitHub let me get this idea up and running really quickly (just a few hours). I’ll consider moving it over to Nostr later.

2026-04-14 12:28:21 CEST

- reply

Yeah, for now you’ll need a GitHub account. In the future, I might consider switching to a Nostr-based approach if people really like it. I’m using GitHub at the moment mainly to prevent spam, and it also lets me leverage GitHub Actions to handle the automation easily.

2026-04-14 12:18:59 CEST

An experiment: Jumble Ouro, a fork of Jumble where what gets built is decided entirely by community votes.
Open an issue, people 👍 / 👎 it, and every day at 20:00 UTC the top-voted one gets picked up, implemented, and merged by an AI agent. No humans in the loop. Needs net score ≥ 5 for now; the threshold may change later.
Come propose, come vote. Let's see where it grows.
Try it: https://ouro.jumble.social/
Repo: https://github.com/CodyTseng/jumble-ouro

2026-04-10 03:26:36 CEST

- reply

Looks great!

2026-04-05 10:03:03 CEST

- reply

Yeah, that’s definitely a real issue. It’s not just avatars either, large images in content can also make the web client lag

2026-04-04 08:19:13 CEST

- reply

I’m planning to add a chat icon later, so the bottom area might get a bit crowded. The explore icon doesn’t seem to be used much, so I’m considering replacing it.

2026-04-02 12:28:17 CEST

- reply

Yeah, just putting your Signal/Whisper/TG/... in your bio is probably better lol

2026-04-02 08:15:06 CEST

- reply

NIP-4e is mainly about separating the encryption key from the user key and enabling cross-client synchronization of that encryption key. Jumble builds on top of NIP-4e and uses the encryption key to implement NIP-17.

2026-04-02 04:39:06 CEST

- reply

Plain NIP-17 on its own isn’t a good fit for Jumble, because many Jumble users rely on bunker remote signers, and the experience would be pretty poor.

2026-04-02 03:28:36 CEST

- reply

Chat is currently being tested on https://beta.jumble.social . It uses NIP-4e (https://github.com/nostr-protocol/nips/pull/1647), where the encryption key is separated from the user key, which works better for users with a bunker remote signer. However, it’s only compatible with Coop for now.

2026-03-27 15:53:58 CET

Honestly, it’s a bit embarrassing. I’ve been so caught up working on Jumble this past year that I kinda neglected nostr-relay-tray.
#nevent1q…wlpm

2026-03-27 02:32:53 CET

- reply

I don’t think microblog-style posts really need those features, and most other clients probably wouldn’t support them anyway.

2026-03-26 09:26:07 CET

- reply

What you’re pointing out is actually exactly the goal. From the beginning, my intent has only been to clean up texts that contain a lot of special characters.
My goal isn’t to support rendering Markdown content, and I don’t encourage it. So raising the threshold is intentional, and it may even be increased further in the future.
#nevent1q…entd

2026-03-25 16:06:58 CET

- reply

I still don’t quite follow. Markdown is just plain text, there’s no flag indicating whether a note is intended to be markdown or not.
Going back to your idea of a toggle: suppose we actually add one. When it’s on, markdown gets rendered; when it’s off, the raw text is shown. Even then, when the toggle is on, the client still has to decide whether to treat a note as markdown, because it has no way of knowing the author’s intent.
So you end up with the same situation as now: the client needs to rely on detecting multiple markdown patterns to make a best guess.
If, instead, you render everything as markdown without any checks, the toggle would likely be unusable, too much normal text would be misinterpreted and displayed incorrectly, so most people probably wouldn’t turn it on at all.

2026-03-25 15:18:02 CET

- reply

Hmm, what’s the issue with the current approach?

2026-03-25 15:11:14 CET

- reply

I’m not sure I fully understand. It’s all just text, what exactly would you be toggling on or off?
I still don’t encourage anyone to post markdown content. I just want to clean up texts that are filled with markdown symbols so the feed looks nicer. For posts that don’t really contain noticeable markdown syntax, I’d just leave them as they are.

2026-03-25 15:02:48 CET

- reply

Got it, I’ll note this down.
This nsite is just for testing. In the future I’ll likely use a dedicated key to publish Jumble’s nsite and automate the process. At that point I’ll also sign and publish an "app listing" event to 44billion at the same time.

2026-03-25 14:54:07 CET

- reply

Because a lot of bot accounts post content in markdown, which floods my feed with markdown symbols. I just want my feed to look cleaner.

2026-03-25 10:07:30 CET

🥳 https://37vn2gp0mwh1i94qmnja0t55wt9r9e8aw74qbtyyk20jqo5r43jumble.nsite.run
#nevent1q…9l2n

2026-03-25 04:33:29 CET

- reply

The client doesn’t actually know whether your content is intended to be Markdown. It can only guess by checking for certain obvious patterns in the text. That’s why normal text can sometimes be misinterpreted and rendered incorrectly.
More importantly, the core question is: why support Markdown in the first place? Kind 1 events are meant to be short text notes. If Markdown is really needed, it would make more sense to use a different event kind. This also helps reduce the complexity for developers building new kind 1 clients.

2026-03-25 03:44:32 CET

- reply

The problem is that it’s very easy for normal notes to be mistakenly recognized as Markdown, which can lead to rendering that doesn’t match the user’s expectations.
At the end of the day, kind 1 events aren’t really meant to support Markdown, they’re supposed to stay simple and render consistently across different clients.

2026-03-25 02:52:32 CET

- reply

Simply put, if your text contains more Markdown symbols, it will be recognized as Markdown.

2026-03-25 02:31:00 CET

- reply

You need at least two Markdown indicators in a note before it’s treated as Markdown. So in your case, just bold a few more words and it should work.
That said, for better consistency across different clients, it’s generally recommended not to rely on Markdown. I only added support because many bots publish content using it.

2026-03-23 15:03:00 CET

- reply

Good idea

2026-03-22 07:13:07 CET

- reply

It triggers a sync request when the public encryption key it fetches doesn’t match the local one. It’s not necessarily that you reset your encryption key on another device, it could just be from using Jumble in a different browser where the key was reset.
If you really can’t recall where your latest encryption key is, it’s probably best to just reset it.

2026-03-21 16:19:56 CET

- reply

#nevent1q…rrv6

2026-03-21 16:19:30 CET

- reply

It might be that someone posted a note containing HTTP images or videos, or that other users have ws:// relays in their read/write relay lists.
I’ve just made a change so that Jumble no longer loads HTTP resources or connects to ws:// relays by default (though I might’ve missed a few spots, haha). If you still need that behavior, you can enable it in Settings → System.

2026-03-19 05:17:35 CET

- reply

Coop was the first client to support NIP-4e, and it lets you choose different modes when sending messages. Jumble only displays NIP-4e, so when sending a message from Coop to a Jumble user, make sure to select “encrypt by encryption key.”

2026-03-19 02:23:33 CET

- reply

I don’t think it’s a big issue. jumble.social only serves the HTML, JavaScript, and CSS. It then communicates directly with relays and media servers, without going through jumble.social

2026-03-19 02:14:35 CET

- reply

My guess is that it was caused by loading some `http://` resources or connecting to `ws://` relays.

2026-03-18 16:28:58 CET

- reply

Thanks a lot! My wallet might be having some issues connecting.
As for the warning shown in the browser, can you see what specifically is causing it? A lot of users have reported the same warning, but I haven’t encountered it myself, so I’m not sure what’s triggering it. I’ve checked the certificate, it’s still valid.

2026-03-18 16:00:15 CET

- reply

I think it might be caused by connecting to the ws:// relays or loading some http:// images or other resources.

2026-03-18 15:10:43 CET

- reply

Jumble doesn’t add any label for protected notes, so they look just like regular notes. But you’re right, adding a label there would definitely be helpful 💜

2026-03-18 15:08:15 CET

- reply

Some people have reported the same issue, but I’m not sure what’s causing it. Jumble is deployed directly on Cloudflare Pages, and I haven’t changed any related configurations recently.

2026-03-18 14:59:57 CET

- reply

Haha, I’ll go apply then!

2026-03-18 14:53:21 CET

I want to try too, though the odds are low 😁
https://github.com/CodyTseng/jumble
#nevent1q…2ne0

2026-03-18 14:40:23 CET

- reply

I just built it based on your ideas, I should be the one thanking you guys.

2026-03-18 04:47:00 CET

- reply

Got it, thanks for the heads-up. I’ll check what’s going on.

2026-03-18 04:43:52 CET

- reply

Jumble currently only subscribes to gift wrap events whose p tag contains the user’s pubkey, since some relays only allow subscribing to gift wraps that mention you. But when Jumble builds a gift wrap event, it mentions both the user’s public key and the encryption public key. I remember Coop does it this way too

2026-03-18 04:37:22 CET

- reply

Cool!

2026-03-18 03:06:27 CET

- reply

Looks like I need to add some logging.

2026-03-18 03:05:40 CET

- reply

Jumble only supports NIP-4e. If those are NIP-4e gift wrap events, then there might be a bug preventing them from showing up.

2026-03-18 02:53:52 CET

- reply

I didn’t quite follow what you were talking about.

2026-03-18 02:39:16 CET

- reply

I’m not sure why, but I can’t view that video. I just tried it myself and was able to share the encryption key successfully.

2026-03-16 02:16:53 CET

- reply

I'm not sure what happened either haha. I didn't get any unsafe warning on my end.

2026-03-15 06:48:15 CET

- reply

Alright, I really need to dig into what’s causing this.

2026-03-15 06:47:34 CET

- reply

Got it 🫡

2026-03-15 06:46:34 CET

- reply

There’ve been more and more AI bot replies in the feed, and most of them use Markdown. So I already made a bit of a compromise a while ago. But I don’t want Markdown to make the feed look messy, with all sorts of font sizes and inconsistent styling, so I’ve only added very basic support for it.
# Heading 1
## Heading 2
### Heading 3
This is **bold** text, this is *italic* text, and this is ~~strikethrough~~ text.
- Item one
- Item two
- Item three
1. First
2. Second
3. Third
> This is a blockquote.
`inline code`
[Jumble](https://jumble.social)

2026-03-15 06:38:47 CET

- reply

My certificate shouldn’t be expired. Is your device’s date and time set correctly?

2026-03-15 06:37:12 CET

- reply

No idea what caused that, but I’ll note it down for now.

2026-03-14 06:27:20 CET

- reply

Thanks for the feedback! Fixed now

2026-03-14 06:26:51 CET

- reply

Supported now
https://blossom.primal.net/ab6e27769285113509efb150ba296a0623f29d3b774bf27995b2b2ecc698a453.png

2026-03-14 06:24:12 CET

- reply

I’ll let AI take a look and try to track it down. Honestly I have no idea where the problem is haha.

2026-03-13 02:09:39 CET

- reply

I intentionally left this unhandled, hoping other clients will remember to add the nostr: prefix to avoid unnecessary protocol bloat.
https://github.com/CodyTseng/jumble/issues/154#issuecomment-2673274446

2026-03-12 15:07:28 CET

- reply

I think that’s because you set a localhost relay. Almost all of Jumble’s code runs directly on your device. I don’t collect any data at all, I don’t even know how many people are using Jumble, so there’s nothing to worry about 🫂

2026-03-12 08:16:45 CET

yoga #catstr
https://blossom.primal.net/5c957c1e9118fa3297bd886f7aa864a56cf0e0bcb38315df6f83c4a6e7738ab5.jpg

2026-03-11 07:49:02 CET

- reply

Only the encryption and decryption use a separate key. The recipient is the same as in NIP-17.
https://github.com/nostr-protocol/nips/blob/per-device-keys/4e.md

2026-03-10 02:16:09 CET

- reply

Do you see the same issue in a regular browser as well?

2026-03-10 02:15:08 CET

- reply

Got it 🫡

2026-03-10 02:14:42 CET

- reply

Another user reported this issue some time ago as well. Looks like I didn’t fully fix it back then.