Sideband on iOS

[acehoss]

I get that this is no small feat, and I'm almost afraid to ask since it's not mentioned anywhere.

I did a kivy-ios build here and got it installed on my device, but it fails to finish launching because of an issue loading a module (multiprocessing). I'm a bit out of my depth--I've not worked with kivy before. But from the little bit of research I did, the issue is probably a limitation of the platform, possibly requiring either a custom recipe or an overhaul of some of the app internals.

Looking under the hood, both Sideband and RNS have a fair amount of conditional behavior for Android. I imagine iOS would likely require at least that much effort again.

I guess this is mostly a conversation starter--what would a road to iOS look like?

[acehoss]

I played with Sideband on a Mac and on a Pixel for a bit today and I understand much better why iOS isn't on the roadmap: iOS provides very strictly limited support for background operations in apps, and none of supported background operations would be sufficient for running the RNS/LXMF stack.

So, even if the current software were to run on the platform, the application would have no ability to process packets when it was not active on the device. When I lock my phone or switch to a different app, Sideband goes to sleep. The entire platform is designed around offloading background work to cloud servers and using push notifications to update the user.

And then, even if companion server software was created to allow the software to work as Apple intends--which would require a remote application having all the information and capabilities needed to connect to the Reticulum networks configured in the app to process packets while the app is sleeping--even if all that is built, the push notifications then must be sent via Apple's central servers. Of course this requires a valid developer certificate to use, which requires paying for their developer program and signing contracts.

The potential paths forward to a usable version of Sideband on iOS would require a huge amount of effort and the result would be at least somewhat opposed to the vision of the Reticulum project.

[spaceinvadr]

I've also been wanting to explore options for this. Lack of iOS support is one of the biggest obstacles for wider adoption of the Sideband/RNode/Reticulum ecosystem in my particular circles.

I've been following the Meshtastic project (similar idea, ESP32 lora board based mesh network) intermittently and I remember that in the past, these same issues were the reason that project chose not to support iOS as well. However, I checked back in on it recently and they now have a fully functional iOS app. I flashed their firmware to my homebrew RNode hardware played around with it a bit and was impressed with it. It seemed to have no issues receiving messages in the background. I'm not very familiar with iOS development but it appears they have overcome at least some of these hurdles. When I get some time I'd like to look more into how they solved these issues, and if whatever they did could be leveraged to help create an iOS port.

I understand given these constraints why it's not on the official roadmap, but if possible I'd like to contribute to whatever modifications are necessary to making this platform usable on iOS devices. The Sideband/RNode platform represents some very powerful and useful functionality and I believe an iOS client would go a long way towards increasing adoption, even if the app needs to be developed unofficially.

[markqvist]

Hi @acehoss, thanks for raising this, and for taking the time to elaborate on all the complications in this regard. You said it just as well as I could've myself :)

iOS provides very strictly limited support for background operations in apps

Yes, you are not allowed any real code execution capabilities on any iOS device. It is a very fancy, turing-complete, brililantly hardware accelerated, Internet-tethered, feature packed etch-a-sketch.

And then, even if companion server software was created to allow the software to work as Apple intends--which would require a remote application having all the information and capabilities needed to connect to the Reticulum networks configured in the app to process packets while the app is sleeping--even if all that is built, the push notifications then must be sent via Apple's central servers.

Exactly. This complete (and intentional) dependence on centrally controlled servers, for anything to work at all, is directly contrary to the principles and visions of Reticulum. Everything within that system needs to be tied via umbilical to mother Apple. It's a shame, the hardware is brilliantly engineered. It could do so much if they didn't opt for a model of complete control. For anyone feeling the need to defend their choices, please spare me the "privacy" or "battery life" arguments, by the way ;)

@spaceinvadr:

Lack of iOS support is one of the biggest obstacles for wider adoption of the Sideband/RNode/Reticulum ecosystem in my particular circles.

Or you could say that iOS is one of the biggest obstacles to giving people any real power and agency over their technological environments.

The vision of Reticulum is to provide a tool that gives people back their agency and control over communications and networking tools, so there is definitely some sort of conflict there ;)

Seriously though, I get you. And you are right: Many people do use iOS devices. Giving them access to the Reticulum ecosystem would be a great benefit, and net positive, even though they are tied to freedom-limiting systems. And I very much appreciate and welcome your willingness to help out here!

I've been following the Meshtastic project [...] and they now have a fully functional iOS app.

The Meshtastic project is a much more limited system than Reticulum, basically just being one monolithic application, instead of an entire open and flexible networking stack. The reason they can make an iOS app work much more easily, is that they do all the "mesh" processing on the ESP32 devices themselves, allowing them to queue the received messages for users on devices.

When the iOS app is activated, it connects to the ESP32 device over Bluetooth Low Energy (which is the only type of hardware access Apple allows, without an extensive "hardware certification program"), and downloads the queued messages to the phone app.

All of this is comparatively easy to do, since Meshtastic doesn't actually have any real routing, or network topography awareness. The "meshing" consists of every node just blindly repeating messages to try and saturate the entire accessible medium with the same message, in the hopes that the right recipient hears it.

Last time I read their source-code, the "encryption" of the system was also... ahem... let's just call it rather "basic". There's basically no per-recipient privacy at all. Everything is just one big "group" with everyone sharing the same key.

Meshtastic also foregoes the ability to use any other mediums than the specifically flashed ESP32s, which again simplifies things quite considerably, as you don't have to deal with real network-device access on the iOS devices, but can easily accept the "server-only" model of Apple.

The Sideband/RNode platform represents some very powerful and useful functionality

Much of this usefulness and functionality stems from how Reticulum tries to transcend some of the limitations of the current paradigms of networking and communications. Trying to deploy this on a platform that so vehemently opposes any alterations to the current power structures is a bit of a fools errand. With the limited time and resources I have, I have to prioritise spending them where I can actually make a positive impact. So yes, this is why it is not on the official roadmap.

Once there is a functional C implementation of Reticulum and LXMF though, it would be very easy to add LXMF proxy functionality to RNodes, enabling them queue and carry LXMF messages for users, even when not connected to a Reticulum stack running on a host device, without sacrificing any functionality. This, however, is something that is on the roadmap.

When I get some time I'd like to look more into how they solved these issues, and if whatever they did could be leveraged to help create an iOS port.

All being said, I really appreciate your willingness to look into this, and I'm very interested in hearing what you find. Please do share your findings and what you learn here. Maybe things have changed since I last looked at this entire challenge, maybe holes in the barriers exist. I'm not going to be wasting precious time and energy running in circles around Apple, but I think we can tolerate some workarounds in bringing this to iOS devices, if there is a realistic possibility.

Thanks for everyones time, interest and effort here.

[markqvist]

This is now actively being worked on by a community member. More details here: https://github.com/markqvist/Reticulum/discussions/277

I'll close this issue for now.