Receiving an LXMessage without the LXMRouter

[Ruulul]

I do have context of why I needed to do that in the first place, but since it was quite painful to me to discover what I should do from the code examples (I spend an awful amount of time searching where the LXMRouter registers a request handle... spoiler alert, it doesnt), but in the end I managed;

It pleases me how readable the RNS API is

anyhow, what I ended up doing:

class MyApp(toga.App):
    ....
    def set_identity(self, identity: RNS.Identity):
        self.identity = identity
        self.addresses = []
        self.set_lxmf()
    
    def set_lxmf(self):
        lxmf_delivery = RNS.Destination(
            self.identity,
            RNS.Destination.IN,
            RNS.Destination.SINGLE,
            'lxmf', 'delivery',
        )
        lxmf_delivery.announce()
        lxmf_delivery.set_link_established_callback(self.handle_link)
        lxmf_delivery.set_packet_callback(self.handle_packet)
        lxmf_delivery.set_proof_strategy(RNS.Destination.PROVE_ALL)
        self.addresses.append(lxmf_delivery)
    
    def handle_link(self, link: RNS.Link):
        link.set_packet_callback(self.handle_packet)

    def handle_packet(self, message: bytes, _packet: RNS.Packet):
        lxm = LXMF.LXMessage.unpack_from_bytes(message)
        ....

Anyhow, since I want my app to be able to handle multiple identities, and the GUI part of it is not on the main thread, I am unable to start an LXMRouter on demand because of the usage of the signal library (and I also cant start it beforehand as I am doing with the RNS instance and swap the identity later, so for now I am stuck handling the LXM manually);

Thankfully I am getting around it, and thought that this is probably a nice finding for future devs wanting to fiddle with RNS

[markqvist]

TL;DR: Don't do it, you will break important functionality for your users.

You definitely do not need to resort to receiving messages without the LXMF router. That's likely to break in all kinds of ways, unless you actually implement the full functionality of the LXMF router.

Without the LXMF Router instance, there's lots of functionality that will not work, including essential stuff such as key ratchets, signature and stamp validation, duplicate detection, and others. That will have a negative result on security and privacy. Don't do it. You have been warned.

In the end, I'm pretty sure it will be much easier for you to simply use the LXMF router the way it was intended. If there's some issue with your application structure, that prevents running LXMF as intended, it's better to fix that.

To have multiple active delivery destinations, you can just instantiate multiple LXMRouter instances.

Any kind of app framework should be perfectly capable of running LXMF, most likely you just need to launch things in the way the app framework is designed for, and then communicating whatever you need to your UI thread through whatever means the framework makes available.

[Ruulul]

Back to the drawing board then...

The main issue is that I cannot create instances inside the UI Thread, where the main loop of the application is running... though I can run code before the main loop starts (which is what I am doing to get a main Reticulum instance)

I can run a subprocess though, but I also never figured out how to have continuous communication with one

Welp, worst case scenario I can just force the app to restart in order to load the router on the other identity I guess

[markqvist]

It makes sense from an application framework perspective that you can't run it in the UI thread. Generally, you shouldn't run anything else than actual UI-related code on the UI thread.

Just launch a separate thread and run all your backend code in that, including the LXMF Router. There's no need to put things in sub-processes here.

[Ruulul]

I didnt even try that because I thought if I launch a thread, this new thread also wont be the main thread and the signal related error will persist

Will try that now, thanks

[markqvist]

Launch your backend logic in a separate thread. Then communicate with the UI part of your application in the correct way defined by the framework you're using. You'll need to understand what that "correct way" is, and I can't offer you any pointers since I don't know about that application framework, but it will be described in their documentation.