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.

Good suggestion 👍

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

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

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.

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.

A new user only needs to be followed by a regular account to boost their reputation into the top 60%, since spam accounts rarely get any followers, following them would expose the spam account owner.

I’ll take a look at those NIPs 👍

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.

You don’t need to do any configuration. You might want to double-check that your code is up to date, and try refreshing the page a few times since it could be cached.

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.

Sounds great! What do you need me to do?

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.

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.

This is bound to be a long-term battle.

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

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.

I just built a simple pagerank service using AI

Sounds like an interesting idea

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

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

Fixed! Thanks for your feedback 💜

Why is he replying to a kind:6 event? 😂

Jumble indeed doesn’t handle this case, I didn’t expect this to happen at all. Now I’m really curious which client he’s using.

You're right

Sure, I’ll find some time to go through it properly.

Fixed

Very inspiring. Lots of great ideas.

No, you’re totally right, it was a bug and it’s fixed now 🫡

Because there’s a space in the emoji shortcode, Jumble didn’t recognize it as an emoji.

Appreciate it, but save the big zap for someone who needs it more than me

I’m using bitcoin-connect, how should I add the metadata?

Yes, but it’s already the blossom server that Jumble recommends. I’d like to add another one to the list.

That's exactly what I've been focusing on for the past half year. That’s also why I’ve been putting off some new features.

We can know whether an event was delivered, but doing so would make the publishing process feel very slow.

I don’t think it’s worth sacrificing the experience for these rare cases. In most cases, sending succeeds, and if it fails, retrying will likely fail too—it could be a network issue or the relay simply refusing your event.

It’s all in `/src/services/client.service.ts`, but it’s a bit messy.

Usually a reply gets sent to around ten or more relays. To achieve what you’re imagining, you’d have to wait for all of them to respond or time out, which would make the user experience really poor.

That said, it’s true that Jumble marking a post as successful after just one relay accepts it isn’t ideal. I’ll adjust it so it only shows success once maybe a third or half of the relays have confirmed.

Maybe it’s just that the other person set unsuitable relays, or maybe only one or two relays failed — should the user really have to see error messages all the time for that? In most cases, a few relay failures aren’t a big deal. If you need absolute reliability, that’s what centralized platforms are for.

I get your point, but the solution isn’t to fork Jumble. What we really need is a better nostr development kit.

A lot of clients are built on top of NDK, but the problem is that NDK itself has issues and isn’t very actively maintained. That’s actually why I decided not to use NDK in the first place.

It’s hard to track reliably, and in some cases certain relays are simply unreachable.