Cody

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

- reply

https://relay.nostrzh.org/
It would be great if, when dropping a user, there was an option to not drop the users they invited.

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: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: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-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: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-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-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: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:13:28 UTC

- reply

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

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

2025-12-31 15:13:36 UTC

- reply

Exactly. If a newcomer starts completely disconnected from everyone in the network, it’s indeed hard to enter the trust graph. But if they come to Nostr through someone they know, they can gain some initial reputation from that recommender, enough to help them stand out from the spam accounts.

2025-12-31 13:58:13 UTC

- reply

I’ll take a look at those NIPs 👍

2025-12-31 13:55:29 UTC

- reply

It’s basically a simple combination of the PageRank and TrustRank algorithms, both of which have plenty of resources online.
In short, if you’re followed by high-reputation users, your reputation goes up too. The more trusted users vouch for you, the more trustworthy you become.

2025-12-31 13:50:09 UTC

- reply

I’m not really into meetings, mostly because my English isn’t great haha. But if your protocol is out on GitHub or somewhere, I’d be happy to check it out and throw in a few suggestions.

2025-12-31 13:14:34 UTC

- reply

Sounds great! What do you need me to do?

2025-12-31 13:12:24 UTC

- reply

I initially thought about the new user issue as well. But I realized that new users are usually brought in by an existing user, once that user follows them, their reputation is higher than that of spam accounts.

2025-12-31 13:06:17 UTC

- reply

It doesn’t seem that important, but yes, most of the code was generated by AI. I just handled the review, fixed AI’s mistakes, and made some small optimizations.

2025-12-31 13:03:46 UTC

- reply

This is bound to be a long-term battle.

2025-12-31 13:01:46 UTC

- reply

The main purpose of this filter is to weed out spam accounts. Since there are a lot of spam users on the Nostr network, normal users usually end up in the top 10%. But this isn’t fixed, so the choice is left to the user. To avoid filtering out too many legitimate users, I’ve set the default threshold at 40%.

2025-12-31 12:56:50 UTC

- reply

The scores are currently based on the network of relationships, your reputation increases when followed by high-reputation users. Since there are a lot of spam accounts in our network, most normal users end up in the top 10%.
I think this is quite different from a social credit system.

2025-12-31 12:53:27 UTC

- reply

I just built a simple pagerank service using AI

2025-12-31 10:43:32 UTC

The last feature of https://jumble.social/ in 2025:
A reputation filter that hides notes from the bottom X% of users by reputation.
It works across feeds, notifications, and replies, and is especially effective at reducing spam when browsing large public relays. #devstr
https://blossom.primal.net/df3db41079a69958bb56ee92718fa0682f4b74b6605597f8ae797b4be197f802.png

2025-12-30 08:56:36 UTC

- reply

一种p2p分布式文件系统吧，我也不是特别了解

2025-12-30 04:31:53 UTC

- reply

Fixed! Thanks for your feedback 💜
https://blossom.primal.net/fc3f7e6fd0b57771712cc53d928acda4d6c6baab21285d259ede9c3d8b62f534.png

2025-12-28 05:35:19 UTC

- reply

You're right

2025-12-26 01:35:40 UTC

- reply

Fixed

2025-12-26 01:35:18 UTC

- reply

You could try clicking the "Load earlier" button.

2025-12-25 02:53:48 UTC

- reply

Do you mean updates on jumble.social? It updates automatically when you refresh.

2025-12-23 15:13:57 UTC

- reply

test

2025-12-23 15:13:49 UTC

- reply

test

2025-12-23 08:50:40 UTC

https://blossom.primal.net/504c920d8a5bc037671ab2fbd0fc712ed9d18c72e521f4c4257fe23dc9b74f0d.png

2025-12-20 05:36:27 UTC

- reply

You can give it a try. I’m detecting touch support by checking whether `window.ontouchstart` exists, so I’m not sure if that property will still be present after you disable touch.
Also, on touch devices you can refresh by pulling down.

2025-12-20 05:04:29 UTC

- reply

On touch-enabled devices, I hide the refresh button and emoji picker. The emoji picker is hidden due to some unresolved bugs.
If your device doesn’t support touch, then my detection logic is probably wrong.

2025-12-20 05:00:23 UTC

- reply

Why would it request this URL? That seems a bit odd, I’ll keep an eye on it.

2025-12-19 01:45:35 UTC

https://libroot.org/posts/going-through-snowden-documents-part-1/

2025-12-19 01:18:02 UTC

- reply

With the current protocol, this may not be possible, and I’m worried it could cause compatibility issues with other clients. It’s also quite hard to design a good interaction for it.

2025-12-19 01:13:21 UTC

- reply

Thanks 💜

2025-12-18 13:50:31 UTC

- reply

No worries, feel free to report any issues you run into anytime 🫡

2025-12-18 01:08:25 UTC

- reply

Does this happen every time? And which browser are you using?

2025-12-17 08:40:38 UTC

- reply

And many clients have different implementations, so I wrote a lot of compatibility code for that 😂

2025-12-17 02:52:22 UTC

- reply

I've implemented it using trust rank and page rank algorithms. Simply put, when you're followed by users with higher trust, your own trust score increases as well.
Since creating a new account on nostr is so easy, spammers can easily create a pubkey and post just once. So, letting accounts with fewer posts through might not be the best approach.

2025-12-17 02:27:18 UTC

- reply

The main reason is that new users all start with a trust score of 0, so enabling this by default would end up hiding a lot of legitimate new users. I’m still looking for a good way to avoid new users being incorrectly treated as spam.
I do plan to add an option to let users set a threshold and filter out users with a trust score below that value.

2025-12-17 02:01:05 UTC

- reply

At the moment there isn’t an option like that. To enable it, you’d need to modify the code — in the src/components/NoteList component there’s a hideSpam parameter, which needs to be set to true.
The trust score is calculated by a pretty rough service I’m running myself, and it still needs a lot of improvement, so it’s not very reliable yet

2025-12-15 13:38:51 UTC

- reply

Got it, so far, Alby still feels like the best option for me as well.

2025-12-15 08:19:05 UTC

- reply

Not sure, I haven’t used any of their paid features.

2025-12-15 06:20:09 UTC

- reply

Totally understand

2025-12-15 04:40:30 UTC

- reply

I’ll give it a try

2025-12-15 04:30:32 UTC

- reply

Couldn’t agree more.

2025-12-15 04:29:12 UTC

- reply

It looks like the permission controls are very thoughtfully designed. I’ll give it a try on my phone! It would be even better if the NIP-07–related functionality could be separated out and made cross-platform.

2025-12-15 04:05:23 UTC

I suddenly realized that there doesn’t really seem to be a Nostr browser extension that’s suitable for beginners.
Alby is what I use day to day, but it’s not very beginner-friendly, it requires email sign-up and is mainly a Lightning wallet. It doesn’t feel like a great recommendation for people who just want to try out Nostr.
Nos2x isn’t particularly user-friendly either, it feels more like a developer tool.

2025-12-13 03:55:21 UTC

- reply

Jumble only has around 700 users :FLASHBANG:

2025-12-13 03:49:36 UTC

- reply

Yes, they’re public.

2025-12-13 03:48:30 UTC

- reply

olas doesn’t put image URLs in the `content` of kind:20 events

2025-12-12 01:09:05 UTC

- reply

No problem, looks like I can just copy fevela’s code directly haha.

2025-12-11 01:06:59 UTC

- reply

Long-press actions on buttons generally aren’t very intuitive. If mis-taps are common, we should probably switch to an interaction like the one in Fevela, or add a confirmation step.
I just tested it on my side though, and touching that button while scrolling doesn’t trigger it. Does it get triggered accidentally when you scroll in your browser?

2025-12-10 01:19:13 UTC

- reply

Very inspiring. Lots of great ideas.

2025-12-08 01:33:04 UTC

- reply

There’s a website that lets you restore various lists, but I can’t remember which one it was.

2025-12-08 01:30:55 UTC

- reply

It looks like fevela already has that.

2025-12-08 01:30:14 UTC

- reply

Yeah, I agree. Even if a client fully fetches and displays notes from nearly a thousand people, I don’t think anyone can realistically read all of that. Once the number of followings passes a certain point, "following" kind of loses its meaning.
(And since most people don’t stay on a page for very long, I’m not sure a slow, patient syncing process would really work in practice either.)

2025-12-07 06:02:41 UTC

- reply

Nostr is just a communication protocol. The reason it isn’t generating revenue right now, in my opinion, isn’t because of the protocol itself. It’s simply that the people using it haven’t found the right ideas yet, or many are comfortable with the status quo. Nobody thinks today’s internet industry is profitable because of how the HTTP protocol was designed.
But if by nostr you mean the Twitter-like kind 1 clients, then I have a genuine question: what is the actual goal of a nostr kind 1 client?
A. Become the next Twitter.
In that case, we’d need to spend money bringing in influencers and give them ways to monetize on nostr, stronger ads, storefronts, creator tools, etc.
B. Become a place where ordinary people can speak freely and post their everyday, boring, normal lives. A platform where the main characters are regular users, not influencers.
If that’s the goal, then we’ve already achieved it. On Japanese and Chinese relays, most of the content is exactly that, simple, mundane posts from normal people.

2025-12-07 05:40:22 UTC

- reply

This is just a solution specifically for users who follow too many people.

2025-12-06 17:40:49 UTC

- reply

Maybe you’re right, I can’t argue with that.

2025-12-06 17:37:55 UTC

- reply

What if this special relay is run locally by the user? Or what if the relay is actually a client itself? Would that change the outbox model?
Why would a client need to support two models? At least Jumble doesn’t need to make any changes. If such a special relay emerges, the user simply needs to bookmark the relay and browse it. They can still click on the following feed and connect to dozens or even hundreds of relays as before.

2025-12-06 17:25:14 UTC

- reply

I’m only talking about the following feed here. Posting, replying, reacting, getting notifications… all of that would still follow the outbox model as usual.