Not only IP Chat

[bornac1]

I made an implementation of chat that currently works on TCP, but I'm planing to include Reticulum support for transport.
And I'm thinking of the way to enable creation of gateway for LXMF. There is written that LXMF has 111 bytes of overhead per message. I don't have timestamp in my protocol, but I use usernames and server names instead of your Reticulum hashes and by choosing wisely I can get a bit less than 100 bytes.
I think LXMF fitts perfectly when used on Reticulum, even better than my system, but if I'm going to make a gateway, I don't know how to handle having two identities for every client.
Also, I'm not sure how Reticulum makes sure that destination hash is unique across large network.
https://github.com/bornac1/NoIPChat

[faragher]

You're going to run into problems if you try to modify a protocol rather than making a new one.

LXMF is as small as it reasonably can be. Mark's dedication to efficiency has led to actually stripping down other standards which is a conversation we have had. ;)

What I mean is removing things like timestamps will have considerable effect later on with what the system expects to see. Without complete interoperability, a standard doesn't mean anything. If you want to talk to LXMF clients, you need to support the protocol as-is. If you don't, then it's all good.

If you're looking at multiple identities, you're looking at crossing protocols or you misunderstand how Reticulum addresses work. Bridging is always going to result in things like this. Otherwise, if you know an address hash, you know an address hash. If you know an identity, you can generate any associated address hash from that identity.

I'm afraid I don't have the skill or time to walk through the code looking at the functionality of it, but if you have specific questions, I can try to field them.

[bornac1]

I'm sorry if we misunderstood.
My first idea is to use Reticulum, so just for transport layer, instead of TCP. This is something I'll do as soon as I finish C++/CLI wrapper around C++ implementation of Reticulum.
But, then I decided I might as well make it be able to communicate with already exsisting LXMF. But, I've put this on hold, as I still need to iron out some problems. By adding Reticulum I'll have hashes of clients and be able to send packet. The problem is that I need to deffine how my message will be transcribed into LXMF. I don't want to add my message into the LXMF as payload.
What I also wrote is that my message can be smaller in terms of size compared to LXMF, but only if usernames are choosen not to be too long.

[markqvist]

It might be a good idea to simply use Reticulum identities and destinations as the primary user identities in your app, and then just map that to whatever other systems you want this to run over. That's the simplest and most robust way I can imagine it.

Then again, why not just use LXMF as the base messaging format, and transport that over any other medium/transport you want? It's pretty easy to do so. For examples look at how some apps handle paper messages.

[bornac1]

I just don't like idea that end user is getting a bunch of letters/number instead of the (user)name that makes sense.
I have one more question for you.
How does LXMF handle large packets? So if whole LXMF can't fit into a Reticulum MTU, it's sent in separate packets. Does your LXMF implementation reasmble them back automatically? Or do I need to take care of that?

[markqvist]

Look at how Sideband and NomadNet handles usernames, it can give you some inspiration. There needs to be a unique address, and that will inevitably look like "random letters and numbers". This is the hash that you use to verify that the person you are talking to is indeed who they claim. If you verify the hash and it matches, you know you have the right person. There can't be a central authoritative registry, since that would break privacy, which is something that LXMF tries to provide.

Both of my implementation gives users the option to create their own "phone book", and you could do something similar, or come up with another solution.

if whole LXMF can't fit into a Reticulum MTU, it's sent in separate packets. Does your LXMF implementation reasmble them back automatically?

Yes, of course. Do you think I am some kind of barbarian? :)

All of that is automatic, and uses the most optimal method for the situation.

[bornac1]

Well, you changed my mind about the whole system. I was very, very sceptical about it, but finally the missing pieces are comming into place.

[markqvist]

Understandable, it's not always so transparent to understand how it all works at first glance. It is very different from what we are used to with IP and such.

Feel free to ask any questions here when they come up :) It also helps other users who are new to Reticulum and have the same questions. Personally, I'm currently not very much connected to the internet, and can't be here on the forum so much, since I am out hiking in the mountains, but hopefully some of the others will help out :)