Cody

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

Public Key

npub1syjmjy0dp62dhccq3g97fr87tngvpvzey08llyt6ul58m2zqpzps9wf6wl

NIP-05 Address

Profile Code

nprofile1qqsgzfdez8ksa9xmuvqg5zly3nl9e5xqkpvj8nllj9aw06ra4pqq3qcpp4mhxue69uhkummn9ekx7mqpramhxue69uhhq7tjv9kkjepwve5kzar2v9nzucm0d5hkjmnzdauqz9rhwden5te0wfjkccte9ejxzmt4wvhxjmcpt3mhxue69uhhqun00pujumn0wd68yttjv4kxz7fwv9c8qtmpv5enqcnpxgenwvnrv4jrvce38ymrqep5893nqv3kxenxgepnv5crwcm9vy6nyc33vfnrxdecvejxyd3cx3sk2efkxvmrxer9vv6rvqgewaehxw309ac8junpd45kgtnxd9shg6npvchxxmmdqfzngm

Publishing to

nos.lol

pyramid.fiatjaf.com/inbox

relay.damus.io

proxy.nostr-relay.app/ae30ba2372ced6c1960d49c0266fdd3e07cea52b1bf378fdb684aee6363dec46

pyramid.fiatjaf.com

Author Public Key

npub1syjmjy0dp62dhccq3g97fr87tngvpvzey08llyt6ul58m2zqpzps9wf6wl

Show more details

Last Notes

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

2026-01-16 01:27:04 UTC

- reply

Right now it uses a greedy algorithm to minimize the number of relays while still ensuring that each user is covered by at least two relays when fetching the following feed. That said, once you follow more than a couple hundred people, there’s really no way around connecting to a large number of relays no matter how you optimize it.
Also, read relays are mainly used to fetch events that mention you, essentially your notifications feed.

2026-01-16 01:22:37 UTC

- reply

I’m not sure this approach fits a web client very well. My guess is that Notedeck works more or less like this.
The "background process" you’re describing might make more sense as a separate application, essentially a personal local relay that quietly collects your following feed in the background. Any client that supports browsing relays could then benefit from it.

2026-01-16 01:17:05 UTC

- reply

Yes, that’s expected. Browsing the following feed can indeed be very slow, especially on first use and if you follow a lot of people.
Jumble first needs to fetch your follow list, then query each followed user’s relay list, and based on that connect to potentially hundreds of relays to retrieve their events...

2026-01-15 01:31:05 UTC

- reply

Thanks ☺

2026-01-14 04:36:05 UTC

- reply

That’s good news, I can handle it manually for now, and of course it would be nicer if the process could be automated. But it’s not a big deal, no rush.
By the way, I noticed that users added via the NIP-86 allowpubkey method don’t seem to get updated in the 13534 membership list event.

2026-01-12 15:05:43 UTC

- reply

Most clients support this now, so even if you only have a couple of read relays configured, you should still see replies from most people in your notifications.

2026-01-12 15:01:43 UTC

- reply

Because @npub1hqa…t56s's client didn’t send the event to your read relays :)

2026-01-12 14:41:49 UTC

- reply

Could you share an example? I can look into it and add support when I get the time.

2026-01-12 14:40:02 UTC

- reply

You mean expanding a discussion/thread directly in the feed? If so, I think nosotro works like that, if I remember correctly.

2026-01-12 14:37:43 UTC

- reply

Because of how the Nostr protocol works, preloading that kind of data isn’t trivial and would significantly increase bandwidth usage and computation. That’s why I chose to load likes, replies, and similar data only when a note is opened.
I also personally prefer that users open a note because of its content, rather than being influenced by how many likes or reposts it already has :)

2026-01-12 10:46:15 UTC

- reply

An ambitious goal! 🫡

2026-01-12 10:35:22 UTC

If you want a more organized way to browse threads, give https://jumble.social/ a try!
https://nostr.media/579223580fa776f78630fa6001d30612b880022ec91cddd7856cf1f91075f322.png
https://nostr.media/c0215826be9d89983668f0495964d765eb56fa1ebf39a6d8bd0f5a6e647413cc.png

2026-01-12 09:30:43 UTC

欢迎所有华人加入 nostrzh 中文社区 relay 🎉
https://nostrzh.org/#relay

2026-01-12 01:24:13 UTC

- reply

Yes, it’s been on the roadmap for a long time, but I’ve kept procrastinating on it

2026-01-12 01:15:43 UTC

- reply

If the “http auth” shown in the screenshot refers to NIP-98, then it’s very unlikely those requests happened with no user action at all. In Jumble, HTTP auth is only required when uploading images or requesting translation services. Also, the screenshot shows that a reaction was made.
As for NIP-42 auth: Jumble only requests signing when it cannot fetch events without authentication. When you’re browsing the following feed, it is possible to see multiple auth signing requests. If other clients don’t trigger the same behavior, it’s reasonable to suspect that they either don’t support the outbox model or are not fetching a complete dataset.
Some people argue that clients should always prompt the user before performing NIP-42 auth, and allow users to block auth to specific relays to avoid potential privacy leaks. Personally, I think this logic belongs in the signer, not the client. Otherwise users end up having to approve things twice, and approve things for every client.
Based on my own experience using many different clients, I can say confidently that Jumble is actually quite conservative when it comes to signing requests. In my signer setup, only get public key and NIP-42 auth are allowed without prompting, and with that configuration, most other clients are almost unusable.

2026-01-09 01:11:28 UTC

- reply

Got it 🫡

2026-01-09 01:10:49 UTC

- reply

You still haven’t really answered my question.
If a mute-word list ends up being widely adopted, does that mean we’ll all have to constantly check our posts to make sure they don’t contain any of those words? Is that really a future you want to see? I don’t, and I definitely don’t want to be someone helping push things in that direction.
Let’s look at it from another angle. If you were a spammer, wouldn’t you just collect the most commonly used mute lists and then deliberately work around them? Once those lists are public, they basically lose their effectiveness. For example, if you mute "jumble," the poster only needs to write “j u m b l e” and the filter is useless.

2026-01-08 16:28:16 UTC

- reply

Most people are foolish, thinking they are free while blindly following influencer

2026-01-08 16:17:41 UTC

- reply

What if the muted word list were made public by Jack? If the list were extensive, many people might adopt it without scrutiny.
I personally don’t like this feature, as China made this mistake centuries ago.

2026-01-08 16:04:24 UTC

- reply

I don't think that's a good idea. If a list of muted words is widely adopted, it could make people afraid to post anything containing those words on the Nostr network. If the list keeps growing... Wait, isn’t free speech what you’re all about?

2026-01-08 15:13:02 UTC

- reply

Not at the moment, doesn’t really feel intuitive, and there are some tricky issues with implementing it.

2026-01-08 15:00:00 UTC

- reply

https://nostr.media/0a46e8ab435327e83b78d4686b3043b70b60fbd41992b6cdda45429a4c963aaa.png
Settings -> General

2026-01-08 14:58:40 UTC

- reply

supported, but it won’t sync across devices. didn’t feel super necessary, so I kinda just lazy-ed out

2026-01-08 14:25:46 UTC

- reply

Wow, a fat zap! Thanks a ton 💜

2026-01-08 14:21:32 UTC

- reply

already removed :padme:

2026-01-08 13:53:59 UTC

- reply

So many people have asked for this that it looks like I’ll have to implement it

2026-01-08 13:52:58 UTC

- reply

Yeah, I think that makes sense 👍

2026-01-08 13:51:41 UTC

- reply

Make sure WoT is disabled and PoW is set to 0
https://nostr.media/e0c03fcc4001c9086df892c86d1c550ffaf3c742d41cb7a7bdf79aca910df8a3.png

2026-01-08 08:50:04 UTC

- reply

It does support that already!
https://nostr.media/864c0d4152927d4a9a3d881c7923e89aaff4b97990f3112a0e0921fd1d06be81.png

2026-01-07 01:26:48 UTC

- reply

Totally doable, it’s just not very high priority at the moment. Let me procrastinate on it a bit longer :)

2026-01-07 01:23:19 UTC

- reply

Fixed 🫡
https://nostr.media/16b3dbd530d155e110d20657eabddcb245d72e90e686e860bae225a8240daf15.png

2026-01-07 01:02:22 UTC

- reply

URL regex matching is always a headache 🤕

2026-01-06 14:17:52 UTC

- reply

Seems like you haven’t discovered this yet.
https://nostr.media/64e68b77d40db6c20a1476495379ad80c4059a47c7ceef4190b7eeac13d83bd6.png
https://nostr.media/39fa7cd2d2a23652fad19a64ad1d15a6f0695e74c7e8598acebdfb064a44b504.png

2026-01-05 03:07:56 UTC

- reply

Users without configured relays will use the default relays to fetch their events. These bots’ posts might not be sent to Jumble’s preset default relays. You can adjust the default relays under Settings → System, but it’s best not to make major changes.

2026-01-05 02:32:13 UTC

- reply

Yes, exactly like this
https://nostr.media/51f00b2a3e6c47d385b776065ff8fee275cbc46ffda9568de67457b553b77706.png

2026-01-05 02:28:33 UTC

- reply

I agree. I plan to let users set a default in the settings, and if they adjust it for a specific feed, their setting will be remembered and applied just for that feed.

2026-01-05 01:24:30 UTC

- reply

I agree. Enable the "live feed" only when the user is at the top. Otherwise, use a "new notes" button instead of inserting notes directly into the feed and disrupting the current cursor position.
What do you think about this? @npub1a3p…sgh3

2026-01-05 01:17:42 UTC

- reply

The mute list supports encrypted storage. If you have privately muted users, Jumble may trigger a decryption request on startup.

2026-01-05 01:07:08 UTC

- reply

#nevent1q…a0mf

2026-01-05 01:06:42 UTC

- reply

Maybe it’d be better to automatically disable the "live feed" while browsing 🤔
Only keep it active when the user is at the top of the feed.

2026-01-04 14:23:03 UTC

- reply

"Live feed" means that new events are inserted directly into the feed in real time, instead of being held back behind a "new notes" button.
From my observation of how Japanese users use Nostr, many of their notes are very short and posted quite frequently. In that case, it works really well to stay at the top of the feed and just wait for new notes to appear automatically—almost like watching a live news ticker.

2026-01-04 14:08:37 UTC

- reply

Really glad to hear that Jumble has become your daily driver ☺
I’m developing Jumble in my spare time as a personal project, so unfortunately I’m not able to offer any paid dev positions at the moment.

2026-01-04 12:45:44 UTC

- reply

Supported!
https://blossom.primal.net/52601f24fededb050e3ee447c6f9b106a0c402c12d6df74a246249c905cfd790.png

2026-01-04 10:15:04 UTC

- reply

Sorry about that, you can click "Don’t remind me again," and it won’t show those annoying warnings anymore.

2026-01-04 10:13:28 UTC

- reply

It seems like Japanese users really need this feature. I’ll add support for it tonight.

2026-01-04 01:23:19 UTC

- reply

I tried it out, but doing it this way might cause Alby to sign an incorrect event 😂
Given how many users it has, the impact could be pretty big.

2026-01-01 06:31:34 UTC

- reply

You don’t really need to understand the details, just know that it helps filter out spam. If you’re still seeing spam, you can raise the threshold a bit.

2026-01-01 06:30:09 UTC

- reply

Good suggestion 👍

2026-01-01 06:28:36 UTC

- reply

Yeah, I’ve been debating whether it makes sense to split it into multiple, separate filters.

2026-01-01 06:25:36 UTC

- reply

Everyone starts with the same score. The system then recalculates reputations iteratively, and after enough rounds the scores converge and stabilize.

2025-12-31 15:50:51 UTC

- reply

It’s a good idea, but it wouldn’t help with the initial reputation issue. A new user would still need the inviter to follow them in order to gain any reputation.