Cody

Building 👨‍💻
https://jumble.social/ & https://psstpsst.chat/

Public Key

npub1syjmjy0dp62dhccq3g97fr87tngvpvzey08llyt6ul58m2zqpzps9wf6wl

NIP-05 Address

Profile Code

nprofile1qqsgzfdez8ksa9xmuvqg5zly3nl9e5xqkpvj8nllj9aw06ra4pqq3qcpzamhxue69uhhyetvv9ujumn0wd68y7ng9ehhyecpr9mhxue69uhhq7tjv9kkjepwve5kzar2v9nzucm0d55qxj8h

Publishing to

Author Public Key

npub1syjmjy0dp62dhccq3g97fr87tngvpvzey08llyt6ul58m2zqpzps9wf6wl

Show more details

Last Notes

2026-09-16 10:11:59 UTC

- reply

I’m not sure what an attacker gains by spreading an old 10044 event elsewhere. Clients should be fetching 10044 events from the user’s write relays / DM relays anyway.
I don’t think putting it on-chain fundamentally solves the issue of senders not getting the latest update in time. It feels more like a different source of truth, querying relays versus querying the chain.

2026-09-16 08:42:30 UTC

- reply

You’re right, this is indeed a problem. My current solution is relatively simple: when a user rotates their encryption key, they don’t immediately discard the old key. They keep it around for a period of time so they can still decrypt messages that were encrypted with the old key by senders who haven’t received the latest key announcement yet and are still encrypting messages with the old key.

2026-09-16 01:24:35 UTC

- reply

Yes, it’s on the roadmap. :)

2026-09-15 09:13:05 UTC

- reply

Thanks! Just a small note though: this is a NIP-17 implementation built on top of NIP-4e, so it won’t be compatible with NIP-17 in most other Nostr clients.

2026-09-14 15:51:38 UTC

- reply

The issue may be fixed now. If you still run into it, feel free to let me know anytime.

2026-09-14 15:51:19 UTC

- reply

The issue may be fixed now. If you still run into it, feel free to let me know anytime.

2026-09-14 15:51:05 UTC

- reply

The issue may be fixed now. If you still run into it, feel free to let me know anytime.

2026-09-14 06:08:03 UTC

- reply

#nevent1q…55ft

2026-09-14 02:39:05 UTC

- reply

Got it 🫡

2026-09-14 02:38:27 UTC

- reply

Thanks!

2026-09-13 15:28:22 UTC

- reply

Thanks so much for the feedback, it sounds like I still have more testing to do. I haven't run into any crashes on my Android device, but someone else just reported the same issue to me as well, so it's definitely something I need to look into.

2026-09-13 14:45:17 UTC

- reply

You can just choose not to use it 😂

2026-09-13 14:44:36 UTC

- reply

Got it

2026-09-13 14:17:42 UTC

- reply

Very hard, especially for a DM app

2026-09-13 13:56:43 UTC

Hi everyone! I’d like to share PsstPsst, a messaging app I’ve been working on over the past three months through vibe coding.
https://psstpsst.chat
It’s intended for staying in touch with friends and family, and supports iOS, Android, macOS, Linux, and Windows. Releases are currently available for all platforms except iOS.
I haven’t had a chance to test the Linux and Windows builds myself yet. If you try either and run into any problems, I’d really appreciate hearing about them.
PsstPsst is built on NIP-17 with NIP-4e, which separates encryption keys from identity keys. This means it isn’t compatible with most existing Nostr clients.
You don’t need to think of it as a Nostr DM app, though. I’ve tried to keep Nostr terminology out of the app and make it approachable on its own. My hope is that people can generate a fresh key and use it with their friends and family.
Why NIP-4e?
With a separate encryption key, the app doesn’t need to repeatedly request encryption and decryption operations from your identity key. This makes it possible to use the app with a bunker remote signer.
Encryption keys can be rotated periodically, so a leaked key won’t expose your entire message history.
A few things I’d like to add over time:
- Small group chats, likely limited to 10 people or fewer. NIP-17 isn’t well suited to large groups, and small circles feel like a good fit for the app’s focus.
- Voice and video calls.
- A built-in browser for napps.
- Communication without an internet connection, using FIPS.
There’s still plenty to improve, but I hope some of you might find it useful. If you feel like giving it a try, I’d be grateful for any feedback or bug reports. Thanks for taking a look!
https://blossom.jumble.social/b5761bc7a6986333d27efc67dd9fec204e08b6b0828dd8d36a1abb64a0bc6f15.png
https://blossom.jumble.social/3526e1e7ff49132877a230378af3ecd4665e70bfe593c029c9e65246a298f88b.png

2026-09-09 02:05:59 UTC

- reply

Cool, I'll add po.oslim.dev to Jumble's default operators.

2026-09-08 04:17:24 UTC

- reply

Got it 🫡

2026-09-06 15:47:58 UTC

- 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 14:39:37 UTC

- reply

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

2026-09-03 04:13:29 UTC

- reply

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

2026-09-01 09:12:38 UTC

- 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 14:11:43 UTC

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

- reply

You can make integrating the WebTorrent player a second PR. Maybe I was overestimating the complexity of it.
I can't guarantee that I'll merge it yet though, I need to understand the impact better before making a decision. If it's lightweight and doesn't affect relay connections, I think it could be acceptable.
Currently, relay connections are already frequently blocked by browsers, so I'm not sure whether adding a WebTorrent player would make this issue worse.

2026-08-24 14:32:11 UTC

- reply

Sure, feel free to submit a PR. Thanks!

2026-08-24 02:15:09 UTC

- reply

I still don't think it makes sense to bake it into the client. I'm fine with just clicking through to an external app or site to watch.

2026-08-23 03:55:26 UTC

- reply

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

2026-08-22 16:08:13 UTC

- 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 10:20:46 UTC

- reply

Got it 🫡

2026-08-19 03:18:41 UTC

- reply

That said, cached avatars are a pain to keep in sync across devices and clients, it doesn't really address the root problem. If someone wants to be recognized, they won't be constantly swapping out completely different avatars and display names. And if they'd rather not be recognized, that's their prerogative. Let them change it.

2026-08-19 02:57:30 UTC

- 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 15:40:27 UTC

- 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 14:04:11 UTC

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

- 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 01:49:58 UTC

- 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 01:45:06 UTC

- reply

you can find the download link in the settings

2026-08-18 01:44:19 UTC

- 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 14:40:13 UTC

- reply

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

2026-08-17 14:36:59 UTC

- 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 14:11:11 UTC

- 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 09:00:54 UTC

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

- 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 02:42:10 UTC

- 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 02:32:13 UTC

- reply

test

2026-08-07 02:13:17 UTC

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

- reply

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

2026-08-05 14:05:28 UTC

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

- reply

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

2026-08-04 14:16:14 UTC

- reply

Which icon library do you use? I like it.

2026-08-02 16:13:43 UTC

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

- 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 13:12:52 UTC

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

- reply

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

2026-07-17 15:04:14 UTC

- 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 09:30:37 UTC

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

- 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 15:23:10 UTC

- 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 12:19:52 UTC

- reply

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

2026-07-12 09:28:33 UTC

- 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 13:58:56 UTC

- reply

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

2026-07-06 04:01:36 UTC

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

2026-07-04 13:42:33 UTC

- 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 09:28:12 UTC

- reply

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

2026-07-03 03:58:59 UTC

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

- 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 01:21:50 UTC

- 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 15:26:28 UTC

- 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 03:30:40 UTC

- reply

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

2026-06-30 03:28:37 UTC

- reply

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

2026-06-30 03:10:22 UTC

- reply

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

2026-06-30 03:01:46 UTC

- reply

Using the API is too expensive. 🫠

2026-06-30 02:41:05 UTC

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

2026-06-27 04:56:51 UTC

- 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 15:11:32 UTC

- reply

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

2026-06-26 14:35:42 UTC

- reply

Fixed, thanks for the report!

2026-06-26 01:19:20 UTC

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

- reply

Got it 🫡

2026-06-21 09:39:24 UTC

- 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 09:34:23 UTC

- 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 06:57:43 UTC

- reply

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

2026-06-19 16:56:12 UTC

- 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 12:28:24 UTC

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

2026-06-18 01:50:10 UTC

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

- reply

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

2026-06-15 13:48:10 UTC

- 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 01:26:22 UTC

- reply

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

2026-06-15 01:25:25 UTC

- 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 15:24:40 UTC

- reply

Just disconnect your account and connect it again haha.

2026-06-14 10:26:21 UTC

- reply

Good call, noted!

2026-06-14 10:25:18 UTC

- 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 05:59:28 UTC

- reply

Gives new users a simple way to get onboarded.

2026-06-14 05:32:15 UTC

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 08:34:22 UTC

- reply

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

2026-06-11 14:00:10 UTC

- reply

:confusedCat:

2026-06-11 13:59:22 UTC

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

2026-06-11 01:11:24 UTC

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

- reply

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

2026-06-10 14:37:29 UTC

- 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 14:18:32 UTC

- 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 14:09:19 UTC

- reply

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

2026-06-10 09:21:30 UTC

- reply

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