Cody

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

Public Key

npub1syjmjy0dp62dhccq3g97fr87tngvpvzey08llyt6ul58m2zqpzps9wf6wl

NIP-05 Address

Profile Code

nprofile1qqsgzfdez8ksa9xmuvqg5zly3nl9e5xqkpvj8nllj9aw06ra4pqq3qcpzemhxue69uhhyetvv9ujuurjd9kkzmpwdejhgqgewaehxw309ac8junpd45kgtnxd9shg6npvchxxmmdwjyscr

Publishing to

relay.primal.net

pyramid.fiatjaf.com

gleasonator.dev/relay

relay.nostrzh.org

relay.damus.io

nos.lol

Author Public Key

npub1syjmjy0dp62dhccq3g97fr87tngvpvzey08llyt6ul58m2zqpzps9wf6wl

Show more details

Last Notes

2026-09-06 17:47:58 CEST

- reply

The key never exists on any server. The client splits it into shares and stores them across multiple operators. Google is only used for authentication, to prove to the operators that those shares belong to you.
So the Google identity and the key are separate, you can bind any key to your Google account.

2026-09-04 16:39:37 CEST

- reply

I think Pomegranate's approach is better. https://viewsource.win/fiatjaf.com/pomegranate/_/master

2026-09-03 06:13:29 CEST

- reply

Sounds good to me. I’ll add support for it later today.

2026-09-01 11:12:38 CEST

- reply

But that would leave a lot of empty space unused. I’m actually considering changing it to a horizontally scrolling layout like X’s image gallery instead.
https://blossom.jumble.social/ccc206a470446e4fc62fab3451f55f69afc8eda0bb61b4c5a805275946624b72.png

2026-08-25 16:11:43 CEST

- reply

For now, the code is only hosted on GitHub because I still rely on GitHub Actions. Do you not have a GitHub account, or are you unable to submit a PR? If it’s the latter, please try again. I just realized I’d blocked PRs from first-time contributors because I was getting so many spam PRs from bots.

2026-08-24 16:32:11 CEST

- reply

Sure, feel free to submit a PR. Thanks!

2026-08-23 05:55:26 CEST

- reply

I think it’s a bit too heavy for Jumble. :catLurk:

2026-08-22 18:08:13 CEST

- reply

If it only means supporting kind 2003 events for display, and clicking them simply opens the local torrent client for downloading, I would be okay with that.
However, I don't want to add support for creating kind 2003 events in the post editor.
Also, I don't quite understand why comments on these events use kind 2004 instead of using kind 1111 events. Is there a specific reason behind this design choice?

2026-08-19 12:20:46 CEST

- reply

Got it 🫡

2026-08-19 04:57:30 CEST

- reply

I understand what you mean. The problem is I couldn't find a better way to indicate that the user themselves reacted. Using the specific emoji makes it clearer that you used that reaction, but I agree it can also be interpreted as the total count for that specific emoji.

2026-08-18 17:40:27 CEST

- reply

Ah, I think I see what's confusing you. That emoji is the one from your last reaction, the number next to it is the total reaction count on that note. If you hadn't reacted to it, it would look like what I see instead.
https://blossom.jumble.social/31e202f63a2f0305310c2e6dde2f81f16bb7f89b50d14c745569f835cfd1958b.png

2026-08-18 16:04:11 CEST

- reply

Grouping them would definitely be a better experience. Most clients haven't done it because relay event queries are pretty limited, and matching centralized platforms is tricky. But I'll try to optimize toward that.

2026-08-18 15:59:23 CEST

- reply

If you run into this again, could you paste the note here? That way I can dig into what's causing it. Thanks!

2026-08-18 03:49:58 CEST

- reply

A kind 10044 event with empty tags has a specific meaning, it can be used to announce that you're no longer using NIP-4e. So it shouldn't be treated as an anomaly and auto-updated.

2026-08-18 03:45:06 CEST

- reply

you can find the download link in the settings

2026-08-18 03:44:19 CEST

- reply

If you're using the web version and frequently browse your following feed, this issue might be hard to resolve. The following feed needs to connect to dozens (or even hundreds) of relays to fetch notes, and browsers have strict connection limits that can interfere with your bunker signer connection.
I'd suggest trying the desktop app instead to see if that improves things.

2026-08-17 16:40:13 CEST

- reply

I’ll consider keeping a few historical versions of the follow list (or other important lists) in Jumble

2026-08-17 16:36:59 CEST

- reply

For the kind 10044 event issue, I don't think it's a big problem. There’s no need to restore it, just resetting it should be fine.
As for the follow list, I remember there’s a website that can help recover it.

2026-08-17 16:11:11 CEST

- reply

I could reply because Jumble still had your encryption pubkey cached. I only realized I couldn't find your encryption public key when I was testing my new app.

2026-08-17 11:00:54 CEST

hi @npub1vxd…rs50, did you use another client ~22 hours ago? You published a kind 10044 event with empty tags, so now I can't DM you

2026-08-07 05:03:22 CEST

- reply

Currently, I treat the "All" tab as the main tab, so the notification dot appears whenever there are new notifications shown in the "All" tab.
However, I’m going to reconsider this logic. As you mentioned, the tab order could be changed. I think it would make more sense to determine the dot based on whether there are new notifications in the first tab. When users open the notification page, the first thing they see is the content of the first tab, so the dot should correspond to what they see there.

2026-08-07 04:42:10 CEST

- reply

The notification dot is currently based on whether there are new notifications in the All tab. You can disable the notification types you don't want to see there.
That said, thinking about it again, I think it would make more sense to base the dot on whether there are new notifications in the first tab instead. I'll adjust it that way.

2026-08-07 04:32:13 CEST

- reply

test

2026-08-07 04:13:17 CEST

- reply

Funny timing, I actually implemented this feature yesterday. You can try it out on the web version now. It will be included in the next desktop release. The notification dot is only shown for new items in the All tab.
https://blossom.jumble.social/ca19239cee27bcf83d2c53c28024c0e048c9752763963be81fa9f004f1090d3b.png

2026-08-05 17:09:14 CEST

- reply

Using Jumble in an onion browser should work, I guess.

2026-08-05 16:05:28 CEST

- reply

Yes, this is really cool. But I think this would be better handled by a more specialized tool, like having Citrine store the events and Jumble browse them.

2026-08-05 03:16:10 CEST

- reply

Thanks for the kind words and the generous donation! :kirbysurf:

2026-08-04 16:16:14 CEST

- reply

Which icon library do you use? I like it.

2026-08-02 18:13:43 CEST

- reply

That concern is valid. Only the central server and operators know the link between the pubkey and Google account, so choosing ones you trust is important. This setup protects private-key custody, not anonymity.

2026-07-29 05:20:06 CEST

- reply

note1... only contains the raw event ID, which isn't enough for clients to reliably find the event across a decentralized network. Use nevent1... instead, it lets you embed author and relay hints, the more info you include, the easier it is for clients to actually find the event.

2026-07-28 15:12:52 CEST

An interesting bar 🥃
https://blossom.jumble.social/01d6b2a89a981606032446cbecd8e665c092e9e636e99395148ab811072238ec.jpg
https://blossom.jumble.social/7152f4106e5a373cb99d39e41a1a8df8acf1a0fc03f662989be68b41efe9c8c3.jpg
https://blossom.jumble.social/57347ae61657b9ba0e61b70fe32f43c8eb4cd2ee94a97e04bfb92ce7658f152c.jpg
https://blossom.jumble.social/b26e27b2ef5d70e972676a52e59fb0db3173f1120dcf3f82fa7d547a60bcf57d.jpg

2026-07-25 17:00:06 CEST

- reply

Got it, I'll fix it as soon as possible. Thanks for the report!

2026-07-17 17:04:14 CEST

- reply

I understand what you mean, and I agree with your point.
What I was trying to emphasize earlier, though, is that many clients make signing and encryption/decryption requests far too frequently, which creates a very poor experience for users relying on bunkers or browser extensions.
For example, the first time you use a client with NIP-17 DMs, your signer may receive hundreds or even thousands of decryption requests. If you are using a bunker, many of those requests may not even reach it because relay rate limits block them first. With a browser extension, meanwhile, the only practical option is often to trust the client and approve all decryption requests at once.

2026-07-17 11:30:37 CEST

Since several major Blossom servers currently do not support uploading encrypted files, Jumble cannot send files in DMs.
So I’m running a simple Blossom server at https://blossom.jumble.social . Feel free to use and test it.
The current file size limit is 20 MB. I may periodically clean up files in the future depending on operating costs, so it’s better to use it together with other Blossom servers.

2026-07-17 03:14:38 CEST

- reply

I assume you gave Amethyst full permissions through the bunker and didn’t review each request individually. That’s not fundamentally very different from giving the app your keys directly, the main difference is that you can revoke the access and walk away at any time.

2026-07-16 17:23:10 CEST

- reply

I’d rather not have Jumble make frequent decryption requests during normal use, so I’m not planning to implement this feature there. Wisp and Amethyst are different, they hold the user’s keys, so they don’t have to worry about this issue. They can use the keys however they want.

2026-07-12 14:19:52 CEST

- reply

是的，上传的是加密后的文件

2026-07-12 11:28:33 CEST

- reply

Any progress on this? Currently, several major blossom services no longer accept `application/octet-stream` files and return a `415 Unsupported Media Type` error. This prevents NIP-17 DM clients from sending encrypted images/files.

2026-07-07 15:58:56 CEST

- reply

I never said that. In fact, without OpenSats, Jumble might not even exist today.

2026-07-06 06:01:36 CEST

A better way to browse your following feed
#nevent1q…tree

2026-07-04 15:42:33 CEST

- reply

When WoT mode is enabled, it only accepts events that come from the WoT. It doesn’t actively fetch or pull any events on its own. Tray is just a normal relay.

2026-07-04 11:28:12 CEST

- reply

Tray doesn’t support this feature yet, I’ve been procrastinating on it, haha.

2026-07-03 05:58:59 CEST

- reply

Because the URL doesn’t include a file extension, Jumble can’t quickly infer that it’s an image. In theory, you could solve this by sending a `HEAD` request for every URL to check the `Content-Type`, but that runs into a practical issue: a lot of these URLs are blocked by cross-origin restrictions.
Browsers simply don’t allow a webpage to fetch or inspect headers from cross-domain URLs unless the server explicitly enables CORS. I just checked `pbs.twimg.com` as well, and it has those cross-origin limitations too, so the client wouldn’t be able to reliably probe it anyway.

2026-07-03 03:16:38 CEST

- reply

Jumble only removes image metadata (like location data) and does not compress the image. The softness is likely caused by the media upload service you’re using.

2026-07-01 03:21:50 CEST

- reply

I’m just using it for coding. Even in a 5-hour window I usually only use about 30% of the usage limit. Might just be something like nationality/region-based restrictions lol.

2026-06-30 17:26:28 CEST

- reply

Jumble’s DM protocol isn’t compatible with most other apps. The keys used for encrypting DMs are separate from the user identity keys, which makes it more friendly for users with remote signers. On top of that, rotating the encryption keys periodically provides a small degree of forward secrecy.

2026-06-30 05:30:40 CEST

- reply

Yes, but my American colleague’s account was also banned.

2026-06-30 05:28:37 CEST

- reply

Because I’m Chinese, but even my American colleague’s account got banned too.

2026-06-30 05:10:22 CEST

- reply

I think a new account probably wouldn’t last very long either, haha.

2026-06-30 05:01:46 CEST

- reply

Using the API is too expensive. 🫠

2026-06-30 04:41:05 CEST

:sadCat:
https://npub1syjmjy0dp62dhccq3g97fr87tngvpvzey08llyt6ul58m2zqpzps9wf6wl.blossom.band/0cf542e4290ca1e30551546da942416b1d357f90c7a73fd37d0c11dd0361517b.png

2026-06-27 06:56:51 CEST

- reply

Yep, I applied the same fix to the other NIP-51 lists too. If I missed any, feel free to let me know.

2026-06-26 17:11:32 CEST

- reply

Not sure, but I don't think mutelists have that issue. :TheVoices:

2026-06-26 16:35:42 CEST

- reply

Fixed, thanks for the report!

2026-06-26 03:19:20 CEST

- reply

I understand. It definitely makes the user experience worse when people have to understand which third-party services they're using and pay for each of them separately.
That said, if clients decide which relays and media upload services to pay for on behalf of users, the Nostr network will eventually become more centralized. I think it's better for users to make that choice themselves.
Also, you don't need to pay for 20 relays. With the outbox model, most people only need around 3–4 relays.

2026-06-21 11:39:52 CEST

- reply

Got it 🫡

2026-06-21 11:39:24 CEST

- reply

I think the problem is that fiatjaf replied with kind 1111. After that, everyone replying to that comment also ended up posting kind 1111 events, so clients that don’t support kind 1111 can’t display those replies properly.
#nevent1q…yhtq

2026-06-21 11:34:23 CEST

- reply

Using blossom.band returns a 415 unsupported media type error.
What kind of identifier are you looking for? I’d be happy to add support for it in Jumble.

2026-06-20 08:57:43 CEST

- reply

Sorry about that. I'll investigate what caused it. Thanks for the report!

2026-06-19 18:56:12 CEST

- reply

Google login also uses NIP-46 remote signing, so it has the same issue.
There doesn't seem to be much progress on https://github.com/nostr-protocol/nips/issues/1712 yet.

2026-06-19 14:28:24 CEST

Finally, clear skies after a week of rain.
https://blossom.primal.net/871c3ea9260b55da60fa87bd1f9ff2ff10b0340b5f0411be09d22309139410ba.jpg

2026-06-18 03:50:10 CEST

A friend of mine made a Chrome extension called Better GitHub.
One feature I really like is the enhanced user hover card. It shows more useful account info, making it much easier to spot spam accounts.
If you're also dealing with lots of spam PRs, give it a try.
https://github.com/rrbe/better-github
https://blossom.primal.net/dd43bc8b1fc9314ca13957fe4896fb2c09fb8344ca8e80e63218355a96c3c5f8.png

2026-06-15 15:54:07 CEST

- reply

People have to make it into your playground first. Then they can leave Google behind.

2026-06-15 15:48:10 CEST

- reply

I couldn't think of a good reason to say no. The only thing I'm not entirely happy with is that the central server still isn't mature enough. Users can't manage permissions very granularly yet. But I'm confident fiatjaf will keep improving it.

2026-06-15 03:26:22 CEST

- reply

By default, it's https://auth.njump.me/

2026-06-15 03:25:25 CEST

- reply

That message appears whenever the signer doesn't respond within one second. It's the same issue you see when using Amber.

2026-06-14 17:24:40 CEST

- reply

Just disconnect your account and connect it again haha.

2026-06-14 12:26:21 CEST

- reply

Good call, noted!

2026-06-14 12:25:18 CEST

- reply

To split your key into shares and distribute them across operators, Jumble needs the key itself, so linking Google is only available for nsec users. With Amber, your key stays external and Jumble never sees it.

2026-06-14 07:59:28 CEST

- reply

Gives new users a simple way to get onboarded.

2026-06-14 07:32:15 CEST

Jumble now lets you sign up or log in with Google. It is not custodial, no server ever holds your key.
Your private key is split into shards and signing uses FROST threshold signatures. Two roles cooperate:
- Central server: the coordinator that verifies your Google sign-in and relays NIP-46 signing requests to the operators. It never holds a shard or your key.
- Operators: independent servers that each hold one shard of your key. No single operator can sign on its own, signing needs a threshold of them.
Google is only used to prove it is you, it never touches your key.
If you already log in with an nsec, you can link a Google account under Settings → Account.
Powered by Pomegranate: https://viewsource.win/fiatjaf.com/pomegranate/_/master

2026-06-12 10:34:22 CEST

- reply

I took a quick look at the Chinese translation, and it looks pretty good overall.

2026-06-11 16:00:10 CEST

- reply

:confusedCat:

2026-06-11 15:59:22 CEST

If you see a custom emoji on Jumble that you find interesting, try clicking it.

2026-06-11 03:11:24 CEST

- reply

I think it's fine. People can already repost and reply to their own posts, so reacting to your own note doesn't seem too strange to me.

2026-06-10 17:17:35 CEST

- reply

I think it should be solved by having more blossom cache servers over time, acting like CDN edge nodes.

2026-06-10 16:37:29 CEST

- reply

I don’t think this should be handled by the client. Otherwise, while loading the resource, the client would also have to keep signing the auth tokens needed for mirroring the blob.

2026-06-10 16:18:32 CEST

- reply

Any blob you upload will be mirrored to all servers in the blossom server list. If you've configured a cache server, Jumble will try to load blobs from the cache server first.

2026-06-10 16:09:19 CEST

- reply

You just need to add that server to the Blossom server list as well.

2026-06-10 11:21:30 CEST

- reply

会发送至提及人自己设置的 read relays

2026-06-10 03:39:29 CEST

- reply

What's this?

2026-06-09 15:51:14 CEST

Hi @npub180c…h6w6! It looks like pomegranate can't sign events with timestamps in the past. This prevents building NIP-59 seal events.
Error: `can't sign event in the past`

2026-06-09 04:25:21 CEST

- reply

I agree 👍

2026-06-07 04:41:11 CEST

- reply

Sorry about that. He doesn’t work for me and we have no business ties, so it’s not really my place to control what he says. I’ve told him before it’s not a good look though, Nostr needs different clients, and users should use whatever they like.

2026-06-06 19:10:33 CEST

- reply

Some users consider it private, so Jumble doesn't add the client tag by default.

2026-06-06 18:58:37 CEST

- reply

That's because you, as the CMO, forgot to enable the client tag on your posts 🤣

2026-06-05 18:20:25 CEST

- reply

That’s not supported yet. I’m planning to add it this weekend

2026-06-05 17:23:24 CEST

- reply

You're right. The bunker login should have a timeout, and if it times out, the user should be able to retry or cancel.

2026-06-05 17:12:08 CEST

- reply

I tried it on Firefox and it works fine on my side. From your screenshot, it looks like it's stuck at the bunker login stage, the registration already went through, so it might be an issue with relay connections.

2026-06-05 03:29:04 CEST

- reply

Looks like I'll need to test that on the desktop app as well.

2026-06-05 03:10:09 CEST

- reply

What error are you seeing?

2026-06-04 12:54:33 CEST

- reply

Yeah, I was thinking the same thing. You can now set a custom blossom cache server URL.

2026-06-04 12:19:11 CEST

Hi @npub13sy…gns9, the Blossom cache server is now disabled by default. Enable it in Settings → System to use it.

2026-06-03 16:52:15 CEST