Group messaging format thoughts

[faragher]

So, thinking about group messages, I have a thought that has some problems, but would like to put this out there for discussion.

First, the problem I see off-hand is that plain destinations can't be routed and single destinations are encrypted. Group is designed to be symmetrically encrypted, so I'm not sure the Reticulum level complexities.

However, on an application level, how about an LXMF field? The message itself would be empty and/or irrelevant, but the field could contain a distribution list and symmetrically encrypted message (PSKs for decryption shared among the destinations). When the message reaches a node, it goes through the list of destinations, and creates a new message containing the field for each next hop, then copies only the destinations on that hop. This would keep the packets sent to a minimum, with an additional overhead of around 20 bytes per destination. By using routing information already present on the node, this wouldn't break any other systems. I don't think this can be purely application level.

There's some error handling to be considered, but by passing around a dynamic distribution list, the minimum number of packets to reach each node would be maintained. There's even the ability to send the messages to distribution nodes, as they're simply LXMF messages with an additional field.

The client would simply need to understand the field, and assemble it on sending a message. This is a purely end to end affair, for all the best and worst that means.

Any fundamental issues I'm missing? Aside from that initial packet encryption issue.

[markqvist]

That is a very interesting idea, thanks for bringing it up. Using an LXMF field makes a lot of sense here.

This is basically "distributed distribution". Hah. I like it. I'm going to chew on this one for a while.

[faragher]

Because we were discussing it, here's my general arrangement. Bear in mind, this is a very rough first pass:

#! /usr/bin/pyhton3
exit()


#Pseudocode
	
class Caster:
	listener #List of listeners
	
	
	
	
	function AddListener(new_listener)
		this.listener += new_listener
		
	function RemoveListener(new_listener)
		this.listener -= new_listener
		
	function Callback_Source
		working_listeners = CasterContainer.listener
		foreach listener in CasterContainer.listener:
			for interface in list_of_interfaces:
				if listener is on interface:
					outgoing_messages[listener].add(message)
		#Additional error handling for unidentified addresses is required in this routine
		foreach prepared_message in outgoing_messages:
			prepared_message.send(prepared_message) #prepared_message key is the listener's address

	function Callback_Router
		working_listeners = incoming_message.destinations
		foreach listener in CasterContainer.listener:
			for interface in list_of_interfaces:
				if listener is on interface:
					outgoing_messages[listener].add(message)
		#Additional error handling for unidentified addresses is required in this routine
		foreach prepared_message in outgoing_messages:
			prepared_message.send(prepared_message) #prepared_message key is the listener's address

		
		
class MulticastContainer:
	function add(message):
		if not this.text:
			this.text = message.text
		this.destinations.add(message.destination)
		
	function.send(next_hop)
		Create LXM
		Add field LXM for destinations
		Send message to next_hop

[holmesworcester]

Another desirable thing in group messaging is for all members of the group to see the same message history in the same order, even if they were unreachable when a message was originally sent.

Is there any plan to provide this functionality with groups?

Ordering and eventual consistency would also let groups be used for applications other than messaging where some shared state is required (for example, a shared notepad).

[faragher]

There's no certainty of shared state without some kind of authority (or a consensus that would be able to reconstruct missing continuity, like some kind of hamming code for messages). However, ordering messages is simply a matter of having timestamps and sorting by them. This would have various small issues (such as listing when they were sent, not when any given person received it) but is very doable.

But if you're interested in more than simple communication, such as a shared state, then you're likely going to be happier with a dedicated program instead of pure LXMF systems. That's not to say you can't have one hiding behind an LXMF address, but the more features required, the better off you are with a custom backend.

That being said, all LXMF messages have a timestamp, so ordering messages by time sent (again, not received) is doable on any given client. It's a good idea.

[trosel]

But if you're interested in more than simple communication, such as a shared state, then you're likely going to be happier with a dedicated program instead of pure LXMF systems

What would be the drawbacks of this? Because you could still run these programs on top of reticulum and get the benefits of that, right?

[faragher]

Correct. You'd lose the LXMF format, which has varying value, the LXMRouter, for obvious reasons, and interoperability with LXMF clients.

Aside from that, you'd have to make your own standard and callbacks, which isn't that difficult, but is a good amount of work, both conceptual and programming. That being said, it's worth considering if that would actually be faster than trying to make another system work for you.

[trosel]

For example, could you just run an XMPP server on top of Reticulum? Something with MLS?

Then you'd get Perfect Forward Secrecy as a redundancy under the other encryption of these systems? lol

[faragher]

I don't know enough about the other systems to say for certain. Data is data, and if you pass it along using a link, you'd gain all the encryption advantages until it reaches the other side of the link, and then it's up to the provider on that end.

[simplyequipped]

I don't have anything to add to the technical discussion here, just wanted to +1 the group messaging discussion overall. I am pretty excited about the new voice messaging and PTT capabilities on Sideband, and group messaging takes that to the next level.