SimpleX Chat Groups

1. Just a few opinions about: SimpleX Chat new group design goals and solution proposal (@ Github) :

2.  - Too much traffic for the sender. 

3.  + I don't agree about this, sending message to even a few thousand recipients is still negligible  amount of traffic with current speeds. 2000 * 16 kB -> 32 MB. So what? Takes a few seconds to deliver.

4.  - Creating a fully connected graph is expensive and not scalable.

5.  + This is kind of true, but the creation is one time cost. That's not the real problem. Actually the part of full graph it is the need to constantly poll all of the full graph queues for new messages, which is the real problem.

6.  - At the cost of increasing the cost to receive the messages. It will result on higher average traffic per member with much lower variance of that traffic.

7.  + As I said in previous point. This just makes situation worse, not better. Usually it's only fairly small number of users sending messages, while most keep just receiving. If sending is expensive, so what. But if receiving is expensive, it's much worse.

8.  - Imagine this conversation in both approaches

9.  + Personally I like approach 1. If it's important to what message the reply is, then REPLY function should be used, with quote. IF it's just generic new post, ordering doesn't matter and as said, it provides much better UX. Who checks for messages that suddenly "appear" one week in the history of active channel? - Nobody, I would say. If the message is shown as a new message, then users see it as usual, even if delivery has been delayed (for whatever reason).

10.  - "high capacity peers" storing the full member list

11.  + My initial thought of improving large groups, was to have specified group server(s) that would then take care of per user communications. -> One connection pair per room / client. It would make rooms just as light, as any other direct chat with user. Room server could be just one client with replication method, sending messages to all recipients. This would also help with ordering problem making out of order stuff less likely. Of course this is not fully distributed. But there are many trade-offs to be made. This would be the most efficient and best-fit solution with current design. Large room replicators would be just clients from SMP protocol's point of view. If you want to have small private groups, current secret group design is great. This approach would also still keep the design SIMPLE. Because all the DAG solutions with hashes and conflict resolution and stuff, is far from simple. Large room servers would usually run on well connected servers in data center, providing 1 / 10 Gbit/s bandwidth and low sub millisecond latency. LRS solution would also help with all the events and general state issues, making those trivial. - Yeah, I know, this is old school, keep it simple stupid solution. But of course it wouldn't satisfy let's make it blockchain dudes.

12.  + FYI, state with Matrix is already so complex that nobody want's to touch it. Simplicity also helps protocols to become popular and keeping it viable to write alternate clients and  server implementations. Personally I think making everything ultra complex is kind of cancer with modern software.

13. Helped a friend to automated testing for the SimpleX platform. System sends a test message every 5 seconds channel A to B and check channel B that it received correct message from A with integrity check. If the B doesn't receive correct message in time (10 seconds), then alerts are sent via several channels telling that something is very wrong with the service.

14. Lots of other discussion on some secret SimpleX chat groups about how Tor works on clients, servers and how it works when there are mixed servers, configurations and users in the same room etc. Also some discussion if future of SimpleX is federated or not. And what terminology means, is it using onion routing or not, etc.

15. These features are currently being worked on, and this post has been sitting in the backlog for a while. Improvements are coming, check the SXC site for latest information.

2024-05-05