[LXMF] Client-Side Block List

[LinuxinaBit]

Despite the existence of stamps, I believe they can be more powerful when combined with a client-side block list and integrated into the trusted sender paradigm.

Trust	Stamp computation required?	Where do messages go?
Trusted	No	Allowed through
Unknown	Yes	Allowed through; where a sender goes when an invite is accepted
Untrusted (new default state)	Yes	Sender is added to the "Invites" list if it is enabled, dropped otherwise
Blocked	Yes	Entirely dropped

The "Invites" list is where a message thread goes for the recipient to either accept, temporarily ignore, or block the sender.
The message thread is hidden while the sender is in the invites list, but messages are kept (threads can be viewed once the sender is accepted and becomes "Unknown").

There are a few cases in which the client-side block list is necessary:

1. Messages sent to Propagation Nodes almost entirely bypass stamps, a flaw inherent to the system (which is difficult to fix without breaking functionality), necessitating the blocklist.
2. The recipient might want to remain public while still being able to block people. This is useful despite the ease of replacing an identity, as stamps can aid with such problems, and the Invites list can always be set to drop new invites.

In the future this may also enable the use of filter lists to instantly Block users in the Invites list who send messages with filtered words etc.

[LinuxinaBit]

Interestingly, this should integrate fairly well with any multicast implementation, as the Invites list could also be used to approve requests to join a multicast group lxmf room (i.e. approval on the receiving end during the key pre-sharing step mentioned in #772 ).

[iacore]

Do you imply that every multicast group is owned by someone? Is this a network/transport layer (IP-level) feature?

[LinuxinaBit]

Do you imply that every multicast group is owned by someone?

Sorry, I meant for this to be more on the LXMF layer (and have fixed the original reply accordingly). Multicast groups could be used underneath, but shouldn't be a requirement here.
It would work similarly to how someone can be an operator of an IRC channel or founder of a Matrix room; all the nodes agree that a specific node has the power to allow/deny entry into a group etc.

Is this a network/transport layer (IP-level) feature?

It would not be.

[LinuxinaBit]

To further clarify:
Multicast groups are a network level feature, but the key sharing and group management would, to my knowledge, be the application's (i.e. LXMF's) responsibility.

[iacore]

Multicast groups are a network level feature, but the key sharing and group management would, to my knowledge, be the application's (i.e. LXMF's) responsibility.

I agree.

[LinuxinaBit]

Just a note:
LXMF β 0.9.0 doesn't seem to actually fix this, trying to fix a slightly different problem by adding propagation-node controlled stamp requirements:

From now on, clients will compute a propagation stamp for each message sent to the propagation network, which nodes can check for validity.

LXMF peers themselves also need to have complete control if LXMF wants to provide adequate safety features, otherwise stuff will slip by.
This discussion proposes an efficient, comprehensive way to do just that. The best part is that it doesn't even need to change LXMF at the protocol level.

[markqvist]

I think the general structure proposed here is very useful as a reference for how to implement new conversation and incoming unknown message handling in LXMF clients. Interestingly, the LXMF API already provides all the necessary hooks and methods to easily implement this in any user-facing application.

Messages sent to Propagation Nodes almost entirely bypass stamps, a flaw inherent to the system (which is difficult to fix without breaking functionality), necessitating the blocklist.

This is not entirely accurate, though. Messages sent via propagation nodes still require stamps, if the destination has specified a stamp cost. So even if you do not message someone directly, but deliver it via the PN network, the message must still have a valid stamp, and the sender will compute it. When the message is received by the destination, LXMF will check the stamp, no matter where it is coming from, and reject it if stamp validation has been enabled in the client.

That being said, any LXMF client developers can implement the proposed structure quite easily, if they find it useful for their target application. I think it's a good general pattern to target. Sideband already has some bare-minimum support in this direction, although it is not as feature-rich, but at least you can already:

• Configure incoming stamp costs
• Decide to completely block unknown senders not already in your contact list
• Easily discern new unknown senders popping up in your contact list since they are clearly marked

I don't want to impose any requirements or "standards" on how people write their user-facing clients, though. The API is intentionally kept open-ended, so people can write exactly the kind of client that they want to use themselves with minimal hassle. If there's any specific features or API functionality missing in this regard though, I am very much open to implementing it to make everything easier for people writing clients.

So to recap:

• Great structural idea for how to handle new conversations
• Ultimately, it's up to the client developer to decide how to handle things in their particular use-case
• Stamps are already in effect, no matter if direct or via PN delivery
• The LXMF API should already have all required functionality for implementing something like this
• But if any API functionality is needed, post about it, and I will help make it happen.

And with the upcoming 0.9.0 release of LXMF, there will also be a much improved PN delivery protocol, requiring initial propagation stamp computation, and much better peering management between nodes, which makes it much more costly to bog down the network with useless messages.