rns.recipes

I'm fairly certain that the manual contains mention of blackhole list publishers as a way to share a list of compromised/bad/disingenuous nodes that should be blackholed. However, I haven't found any mentions of such a list existing.

To be fair I'm super new in this community and don't have any solid idea on where to look xp.

Does such a thing exist?
I feel like I'm capable of creating it, but I don't have enough free time to actually dedicate to maintain something like that, especially if it gets popular. There are also several issues with the approach I'm thinking of and I'm not sure that ways to resolve them I thought of would be enough. I can elaborate if someone is interested.

Decided to look of it because of a certain identity that has been spam-calling me (and other people afaik) after every announce

So I have an RNS interface on a VPS that is setup to just connect to everyone, and then serves paths to my IFAC interfaces. On this VPS instance I have done rnpath -B d14f05add53c03486d6f869cda37afbf - and all my other instances follow this node's blackhole list. Anyone else annoying gets blackholed on the main node. And I'm sure this is the person calling you after every announce

OLIVE GARDEN wrote:

So I have an RNS interface on a VPS that is setup to just connect to everyone, and then serves paths to my IFAC interfaces. On this VPS instance I have done rnpath -B d14f05add53c03486d6f869cda37afbf - and all my other instances follow this node's blackhole list. Anyone else annoying gets blackholed on the main node. And I'm sure this is the person calling you after every announce

This is truly the person calling me after every announce.

I probably should mention that I'm looking for something:

1. Community-maintained
2. Publicly available
3. Easy to use

I have my own Backbone that I connect to and I added Golgi to the blacklist directly on it already. But I'm not sure how sustainable this is, since blackholing spammers like that is not very effective if they aren't completely incompetent.

I played with the idea of having something like the Block List Project for Reticulum, but I haven't got the time. All I have is a name – X1. After NGC 1313 X-1, a rare intermediate-mass black hole in the Topsy Turvy galaxy in the Reticulum constellation. I kid you not.

But as Ahyrax says, it wouldn't be effective against spammers using burner identities. For that, whitelisting could be something to consider.

joakim wrote:

I played with the idea of having something like the Block List Project for Reticulum, but I haven't got the time. All I have is a name – X1. After NGC 1313 X-1, a rare intermediate-mass black hole in the Topsy Turvy galaxy in the Reticulum constellation. I kid you not.

TIL something new. That's actually pretty cool.

But as Ahyrax says, it wouldn't be effective against spammers using burner identities. For that, whitelisting could be something to consider.

Whitelisting is... questionable. My belief is that it's just as unmaintainable as normal sites, but it might honestly be the best approach in this situation.

Oh, that's you in the thread! I swear, the more I look into this network the more I see the same people haha.
Guess I'll share a bit more since we're having this discussion. I've thought about it as well when taking a break at work and designed something (only conceptually in my mind without an actual prototype) that could've worked. It has some issues I'm not sure are very resolveable. lmk if you're interested, I could probably write more once I'm free.

My main concerns over such a system are:

1. It has to be community-maintained.

↑ Otherwise it doesn't differ from normal nodes and wouldn't be easily discoverable. Most of the things I'm stating below are stated because it's community-maintained.

2. If it's community-maintained, said community has to pass data into this source.

↑ I've been thinking about something in the vein of "people submit addresses and based on amount of these submissions you get a certainty score. The more people report it - the more likely it's actually a bad source and should be banned".
I believe that such a list would be easily manipulated (by spamming or inflating the list by invalid identities for example) and is going to disrupt networks if big backbones are going to adopt it. It could be fixed with some effort, but I feel like the fixes I'm thinking of are a bit too theoretical and wouldn't actually do anything to prevent the abuse.

3. It's going to spread illegal content instead of blocking it.

↑ Because it is community-maintained, the entire community is going to be able to see why these nodes should be banned. And because banning individual spammers isn't very effective (an effort still should be done to maintain these), it's probably going to be banning "CSAM, revenge porn, doxxing, or other kinds of abuse" and, as such, giving everyone interested an easy to access list of this content.

4. I would like it to be configurable.

↑ This is my personal eek. It would be nice that every backbone/user that uses it could specify what exactly they would like to avoid (some people actually get off from spam for example) or how much of a certainty score they would like to trust to blackhole networks. This is not possible in the current system without a custom script that is going to import stuff, while I was hoping to just use "blackhole_sources" variable in config (nodes sourcing via info.blackhole/list don't send fingerprint by default).

Other approach I thought of included using one node as NomadNet page for displaying/submitting stuff and as transport node for simulated RNS identities that would distribute blackholed "presets". This works, but I feel like this is just rude to the network (it's going to create more announces than probably needed, if I'm understanding the system right) and is not useful at a big enough scale.

By whitelisting I meant only accepting LXMF messages or calls from people you know / trusted peers.

1. It has to be community-maintained.

Agree.

2. If it's community-maintained, said community has to pass data into this source.

I was thinking something more or less like the Block List Project. People submit an address and a reason for blocking, volunteers review submissions and add to block list if it fulfils some criteria. It's more manual work, but it may be the best way to prevent the manipulation issue. The Block List Project uses GitHub issues, we could use work docs with rngit.

3. It's going to spread illegal content instead of blocking it.

Oh, that's a really good point. I hadn't though of that. So much for transparency :/

4. I would like it to be configurable.

I was not thinking of a huge list, but a number of lists that people can subscribe to. You can subscribe to more than one blackhole list.

I give my vote for the ability to do whitelisting. As identities are freely regenerable, and anyone with ill intent can generate a new one even daily, blackholing gets almost meaningless. But the ability to do whitelisting is nice in many cases, at least for me.

One solution that i see is to use IFAC and organize smaller clusters of networks that will link together in the end.

So basically Network 1(N1) will have IFAC 1, N2 will have IFAC 2 and so on.
Then each network will have 1-3 admins and is based on trust, each network manages it's own blacklist not only by a real blacklist, but also by giving the IFAC only to trusted people. So kind of a big community formed by smaller communities.

Do this for all networks, then somehow bridge them together, maybe maintain a common list of blackholed identities.

On paper sounds good, should allow to block any undesired content or spamming, it's bastically a form of whitelist and blacklist together.
An advantage is that such networks, if protected correctly will not even participate in known illegal content, as any packets that doesn't match IFAC will just be discarded.

In practice, a lot of work to do it, need to earn trust directly, need to update and audit from time to time etc. Hard to scale overall.

An automated IFAC changing mechanism would kind of help here. If Nx is compromised and not trusted anymore, change all the other IFACs at once, resulting in inability for Nx to connect to the main network as it won't know any IFAC. The bad actor will be locked out until it can find another way in. However this is easier said than done.

I think it'll become a hell to gestionate at big scale, but it's kind of best practice for a clean and organized network that avoids spam and illegal content.

Unfortunately this won't be public, which is a barrier for new people. Also could be a problem for the network itself as you can't really connect to the public network anymore due to the IFAC.

Solve one thing, break another.

Yeah, d14f05add53c03486d6f869cda37afbf is spam calling everyone and it's annoying as hell. Someone should try and figure out what is actually up with that. I'm super curious to know what's actually going on here. Is it malicious? Is it some dumb script kiddie having a laugh? Is it just someone who didn't knew better and left a weird and failed experimental script running in a screen session?

Either way, this is only really a problem because LXST doesn't have stamps implemented yet like LXMF does. Stuff like this will more or less be a thing of the past once the stamps implementation in RNS core is done, and Identity Stamps become an option. Then just generating random identities and spam calling will be very computationally expensive, and not feasible on any kind of scale. It's a neat way to turn the attacker into the attacked :)

Still, currently you can just block d14f05add53c03486d6f869cda37afbf in your client, and the problem is solved (or enable calls from trusted peers only). It doesn't seem to rotate identities or anything, which is the weird thing about it. If it was actually someone trying to be properly malicious, you'd expect at least a little bit of effort.