[LXMF] Dropping incoming messages from unknown sources

[LinuxinaBit]

I know Reticulum doesn't just allow outright blocking incoming connections, that's just the tradeoff you make with truly private mesh networking, but LXMF shouldn't be like SMS where anyone can just message you if they have your phone number (and with Reticulum, everybody connected has your address the second you announce).

I imaging it working by still receiving all messages, but not storing it if it's from an unknown/unapproved address. Obviously this would be a toggle-able setting that is probably on by default.
Maybe some kind of 'conversation request' feature could work as well.

Just some thoughts about ways to prevent spam and abuse, not sure if you've already implemented something similar I just haven't found.

[faragher]

While I disagree it should be on by default, I certainly agree your concerns are valid. Sideband can ignore unknown senders in the preferences menu and NomadNet can set users to be untrusted.

This is, generally, an application level decision. The LXM router shouldn't need to handle these decisions, since it can't really make an informed decision (apart from excessive data rates). Since only the destination is known to the router, it can't really determine what's legitimate traffic.

So Sideband blocking unknown addresses and NomadNet marking them untrusted is a good first step. Actively blocking addresses at the client level is certainly doable, and in my opinion the place to do it, and I'm not sure if it's a good idea to expand that to the RNS as a whole (which was not your proposal, I'm just expanding a bit).

Regarding saving the messages or not, this is an application level decision, so the individual app has to manually save a message, so denying messages when ignored or blocked, or simply purging them after reading if there's an unknown you want to screen, is absolutely doable.

Preventing spam and abuse is a major topic, and difficult to address. Certainly low bandwidth links are at major risk of spamming, but the issue isn't terribly huge. We had a group perform a DDoS test that was accidentally linked to the main test-net and it only really inconvenienced people due to some bugs (which we wouldn't have found otherwise, so accidental lemons to lemonade). Also, a well configured network can mitigate these risks. By defining interfaces as different modes and setting bitrate limits, you can ensure that no matter how hard someone bangs at the door, you still have bandwidth internally. Can this cause bottlenecks? Certainly. Is there more to be done? Sure.

But there's no way to determine a sender without the recipient's private key, so most typical means for preventing abuse prior to the final decoding simply can't be employed. Tagging the packets with their sender would violate the privacy goals of the RNS, so there's not much to be done other than rate limiting or clever things I can't think of.

However, today you can flick a switch in Sideband and ignore unknown contacts as a whole. Since only trusted contacts cause notifications, I find it hard to even notice when unknown contacts send me messages, but I certainly understand your concerns. I'm certain more granular controls and blacklists are going to be available in the future, but ultimately they'll be stopped by the receiving machine, not sooner.

[LinuxinaBit]

I was kind of thinking it would have to be on the application layer to work with Reticulum.
It is definitely a feature that should eventually be implemented on apps it hasn't been already.

[faragher]

Blocking appears to be planned but not yet implemented in NomadNet. It's worth having an affirmative block in Sideband as well. I'm still in the air about denying all unknowns, and I think a conversation request is probably beyond the scope of SB or NN, but options are almost always good. I don't work on NN much, and I haven't really touched the SB code, but it's worth implementing at least a block and probably an "ignore untrusted/unknowns."