Cody

Building 👨‍💻
https://jumble.social/
& nostr-relay-tray

Public Key

npub1syjmjy0dp62dhccq3g97fr87tngvpvzey08llyt6ul58m2zqpzps9wf6wl

NIP-05 Address

Profile Code

nprofile1qqsgzfdez8ksa9xmuvqg5zly3nl9e5xqkpvj8nllj9aw06ra4pqq3qcpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dsc8ekkl

Publishing to

relay.damus.io

nos.lol

Author Public Key

npub1syjmjy0dp62dhccq3g97fr87tngvpvzey08llyt6ul58m2zqpzps9wf6wl

Show more details

Last Notes

2026-03-25 14:02:48 UTC

- 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-22 06:13:07 UTC

- 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 15:19:56 UTC

- reply

#nevent1q…rrv6

2026-03-21 15:19:30 UTC

- 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 04:17:35 UTC

- 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 01:23:33 UTC

- 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 01:14:35 UTC

- reply

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

2026-03-18 15:28:58 UTC

- 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 15:00:15 UTC

- reply

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

2026-03-18 14:10:43 UTC

- 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 14:08:15 UTC

- 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 13:59:57 UTC

- reply

Haha, I’ll go apply then!

2026-03-18 13:53:21 UTC

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

2026-03-18 13:40:23 UTC

- reply

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

2026-03-18 03:47:00 UTC

- reply

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

2026-03-18 03:43:52 UTC

- 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 03:37:22 UTC

- reply

Cool!

2026-03-18 02:06:27 UTC

- reply

Looks like I need to add some logging.

2026-03-18 02:05:40 UTC

- 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 01:53:52 UTC

- reply

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

2026-03-18 01:39:16 UTC

- 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 01:16:53 UTC

- reply

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

2026-03-15 05:48:15 UTC

- reply

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

2026-03-15 05:47:34 UTC

- reply

Got it 🫡

2026-03-15 05:46:34 UTC

- 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 05:38:47 UTC

- reply

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

2026-03-15 05:37:12 UTC

- reply

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

2026-03-14 05:27:20 UTC

- reply

Thanks for the feedback! Fixed now

2026-03-14 05:26:51 UTC

- reply

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

2026-03-14 05:24:12 UTC

- 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 01:09:39 UTC

- 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 14:07:28 UTC

- 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 07:16:45 UTC

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

2026-03-11 06:49:02 UTC

- 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 01:16:09 UTC

- reply

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

2026-03-10 01:15:08 UTC

- reply

Got it 🫡

2026-03-10 01:14:42 UTC

- reply

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

2026-03-10 01:13:11 UTC

- reply

Thanks for the heads-up 💜

2026-03-09 10:36:43 UTC

- reply

I think so

2026-03-09 10:35:42 UTC

- reply

It’s just $0.14m, not $1.4m, they got that wrong. And it’s only a proposal, hasn’t been implemented. It was put out by a local district government here, and I honestly doubt those officials have ever dealt with an AI agent 😂

2026-03-09 10:13:43 UTC

I really can’t wrap my head around how hyped China is about OpenClaw, from companies to the government.

2026-03-09 06:32:52 UTC

- reply

It’s still a bit rough for now, I still need to polish it.

2026-03-09 02:07:01 UTC

- reply

If this happened because the DM relays were changed while testing DMs in Jumble, switching the DM relays back to the previous ones should restore everything. 🫂

2026-03-06 16:23:47 UTC

- reply

No worries at all, feel free to submit a PR anytime. 😊

2026-03-06 16:22:51 UTC

- reply

Currently the shortcut is Ctrl + Enter (or Cmd + Enter on Mac), the same as when creating a post. This is just temporary though, I’ll listen to feedback and see which shortcut works best for everyone.

2026-03-03 13:53:12 UTC

- reply

What I meant by building it on top of DMs mainly refers to the encryption/decryption protocol, not the DM feature itself.
Any encrypted content requires both the sender and the receiver to use the same protocol. Jumble plans to use NIP-4e to encrypt gift wrap events. At the moment, other clients don’t support this protocol, so even if I implement this feature, it may only allow private replies between a small group of users.
These replies would still appear in the comment section like normal comments, but they would only be visible to the intended participants.

2026-03-03 07:01:04 UTC

- reply

This feature would need to be built on top of DMs, so I’ll only be able to consider it after Jumble supports DMs.
Also, since I’m planning to use a DM protocol that isn’t compatible with most existing clients, this feature might ultimately only be available to a small group of users.
That said, it’s definitely an interesting idea, and I do think I’ll end up implementing it.

2026-03-03 01:28:54 UTC

- reply

Sure, feel free to submit a PR 🫡
https://github.com/CodyTseng/awesome-nostr-relays

2026-03-03 01:26:31 UTC

- reply

This is actually a kind of DM as well, I find it pretty interesting too.

2026-02-28 07:12:17 UTC

- reply

https://nostr.media/791857b50fadb704a2c5af91b78785de346a5d0e9275a85dee802e74623c4437.png
I agree, it's confusing.

2026-02-26 16:27:52 UTC

- reply

I completely understand your concerns.
You’re absolutely right, and I’ve already made optimizations as you described. Logged-in users can continue using Jumble as themselves regardless of whether bunker is connected properly. However, there might still be issues when it comes to signing events. That said, the experience is much improved compared to before

2026-02-26 15:43:10 UTC

- reply

Thanks for the feedback! I’ve made some optimizations, though I’m not entirely sure if they’ll resolve your issue.
Bunker remote signing isn’t very stable in browsers, especially when there are many relay connections. The browser may block new connections, which can cause the login state to appear inconsistent or get stuck spinning.
If you’re using Jumble on a desktop browser, using a browser extension signer may provide a more stable experience.

2026-02-24 02:51:50 UTC

Every coffee shop should run a nostr relay instead of a message board :MEOWDY:
#nevent1q…9a64

2026-02-23 12:16:27 UTC

- reply

First, just to clear up a misunderstanding: almost all of Jumble runs locally on your device. So there’s no real difference between using jumble.social and running it locally.
And actually, this happens because Jumble uses the outbox model. It fetches data from the outbox relays of the people you follow, which means it has to connect to a lot of relays. The more people you follow, the more relays it needs. I only follow a bit over 200 people, but Jumble still connects to dozens of relays just to load my following feed.
At that point, the browser starts blocking new connections. For example, if I try to like a note, it may need to connect to a few additional relays, but those connections just sit in pending, and the like can fail.

2026-02-23 09:22:44 UTC

- reply

If you follow too many users and browse the following feed in Jumble, the experience can indeed be pretty bad.
Fetching content from the people you follow requires connecting to a large number of relays, and the browser will block some new connections, which can prevent certain operations from working properly.
Unfortunately, I don’t have a good solution for this at the moment haha. My recommendation is to fetch content directly from relays and only follow a small number of users. As nostr becomes more decentralized and everyone uses different relays, following feeds will become increasingly difficult to retrieve.

2026-02-19 07:02:39 UTC

- reply

Jumble has used the outbox model from day one.

2026-02-18 05:32:25 UTC

- reply

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

2026-02-16 05:58:05 UTC

- reply

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

2026-02-16 05:50:53 UTC

- reply

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.

2026-02-05 04:10:45 UTC

- reply

You can just paste the event ID directly, like this:
#nevent1q…7ndw

2026-02-05 04:07:18 UTC

- reply

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.

2026-02-04 02:43:43 UTC

- reply

You usually need to specify a gateway, it works much better for compatibility.
https://ipfs.io/ipfs/QmQEd5kRCTGyZYGbaJKJ4tyV7zJRQQh782NNFGXRmLPCPc/Canon_de_Pachelbel_en_Re_majeur_au_diapason_de_l_eau_429_62_Hz_par_Tommi_Jack_s.mp4

2026-02-04 02:39:51 UTC

- reply

Probably after DMs

2026-02-04 02:39:11 UTC

- reply

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

2026-02-03 01:04:41 UTC

- reply

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.

2026-02-02 15:43:50 UTC

- reply

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.

2026-02-02 15:34:18 UTC

- reply

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.

2026-02-02 15:18:00 UTC

- reply

The code on GitHub is pretty old at this point, I’ve made a lot of local changes that I haven’t pushed yet, so it’s not very useful as a reference. You’re probably better off looking directly at NIP-4e instead. https://github.com/nostr-protocol/nips/pull/1647

2026-02-02 15:15:35 UTC

- reply

A big part of why I’ve always been resistant to NIP-17 is the UX: unless the user fully agrees to all decryption requests, the app basically becomes unusable. You just keep getting spammed with decryption permission pop-ups over and over again.

2026-02-02 14:09:39 UTC

- reply

Got it 🫡

2026-02-02 14:09:19 UTC

- reply

That branch is entirely AI-generated code. It implements the basic functionality, but it has a lot of issues. I found it pretty painful to work on, so I’ve been focusing on other things lately, DM will need to be delayed for a while. :doge:

2026-02-02 14:07:32 UTC

- reply

It’s in development. It’s based on NIP-4e, which isn’t compatible with most clients yet, but I think it’s a better fit for Jumble.

2026-01-31 14:04:14 UTC

- reply

Great idea! I’ve already added pow support to it 👍

2026-01-31 10:33:14 UTC

Vibe coded a Nostr comment component :FLASHBANG:
https://nostr-comments.pages.dev/

2026-01-31 10:30:31 UTC

- reply

Old issue, the browser blocked new websocket connections, which caused the timeout.

2026-01-30 03:17:29 UTC

- reply

This is key info.

2026-01-29 01:47:20 UTC

- reply

Sure 👍

2026-01-26 07:39:46 UTC

- reply

Jumble’s relay info is rendered just like a regular post, it supports images, embedded posts, and so on.

2026-01-26 03:55:24 UTC

- reply

It’s mainly just my personal feeling that it’s not really necessary.

2026-01-26 03:35:19 UTC

- reply

That’s still content they chose to publish, so of course it won’t be hidden from the timeline. What it does is prevent your notifications tab from being polluted, so you don’t miss important notifications because of all the noise.

2026-01-26 03:33:27 UTC

- reply

I get what you’re asking for, and I understand the desire for that level of control. That said, the benefit of this feature doesn’t really feel worth the cost to me.
If it’s just a single note, it won’t stay in your timeline for long anyway—it’ll quickly get pushed out by newer content. But once you add a “hide this specific note” feature, every note would need to be checked against a list of notes you’ve chosen to hide before being shown. Sure, there are ways to optimize this, but the question is: is it really worth it?
That hidden-notes list would also keep growing over time. You might be disciplined and keep it small, but other users probably won’t, and that complexity adds up fast.

2026-01-26 03:23:09 UTC

- reply

The purpose of “hide indirect” is to deal with hell threads, that is, to hide replies from other users to the note shown in your screenshot.
As for the case you mentioned:
* If the account is just spam, you can easily filter it out using the trust filter.
* If it’s a normal account but you personally find them annoying and don’t want to see their content, you can simply mute them.

2026-01-26 01:37:01 UTC

- reply

The reason you’ve only run into it twice so far is simply because bad actors haven’t shown up yet. Once they do, blocking won’t really help.
Blocking the original user doesn’t solve the hell thread problem, because the issue isn’t the original note itself, it’s the flood of replies from many other people.
I think hiding indirect notifications is sufficient here

2026-01-25 16:35:31 UTC

- reply

Honestly, manual blocking isn’t a real solution, this spam is super easy to mass-produce, so users can’t block every single one. Their blocklists will just keep growing unwieldy and ruin the client experience.

2026-01-25 14:36:42 UTC

- reply

Click ‘hide indirect’ in the top-right corner.
https://nostr.media/f8b1b20740a8a10be80c5a61017347754388bd4110eda73ca66b8338c059a97b.jpg

2026-01-23 14:02:09 UTC

- reply

Got it 🫡

2026-01-23 14:01:34 UTC

- reply

Thanks for the feedback! It’s been a while since anyone last mentioned this, so I thought I’d already fixed it 🤣
Looks like I need to carve out some time to take a closer look again.

2026-01-23 03:48:41 UTC

- reply

This isn’t your issue. If search.nos.today doesn’t accept report events, the error makes sense.

2026-01-23 03:45:21 UTC

- reply

Reports are sent to the relay where the event was seen on. If that relay doesn’t support report events, getting an error is expected and normal behavior.

2026-01-23 03:05:15 UTC

- reply

When Jumble receives an error that starts with `auth-required`, it will automatically trigger authentication. From your screenshot, though, search.nos.today is returning an error that starts with `block:`, so the auto-auth flow never gets triggered, haha

2026-01-23 01:37:58 UTC

- reply

Jumble is fully client-side (no SSR), so it can’t provide link previews for shared posts. If njump’s reliability doesn’t improve, I may consider building a similar service.

2026-01-22 10:21:01 UTC

- reply

That’s definitely an issue.

2026-01-22 01:16:52 UTC

- reply

My guess is they were probably setting up a rizful wallet.

2026-01-22 01:14:07 UTC

- reply

If we can identify exactly which post isn’t showing up, that would help a lot with troubleshooting 🫡

2026-01-21 13:47:48 UTC

- reply

> Então, para eu ler todas as bobagens do nostr, coloco 100%, ou deixo em 0%, como está?
0%

2026-01-21 13:47:17 UTC

- reply

It can be slower when you first use it, as many things need to load. After some time, once the necessary cache is built up, it should feel faster. Of course, it also depends on the device's performance and network speed.

2026-01-16 02:07:22 UTC

- reply

If nostr keeps getting more decentralized, with everyone on different relays, pulling the following feed will get heavier for clients. Using relay feeds and following just a few people seems like a good way to handle it.

2026-01-16 01:43:15 UTC

- reply

Absolutely, I get that. But the cost of showing them is pretty high right now, so I need to find a balance.

2026-01-16 01:40:32 UTC

- reply

I don’t think that’s really doable, haha

2026-01-16 01:29:45 UTC

- reply

This's an njump share link
https://nostr.media/42baccf49a026b8570e21799c8c3321e541d1adb4151480b0f9705538a7c6c58.png