@Anelito, Luckily Meshtastic-devices handle the mesh automatically. The app has to be able to pair with Bluetooth, send user+channel settings (a certain packet/message) to the device, read packets (messages) from and write packets to the device.
I was wondering how big of a deal would it be to add a XMPP server in the ESP32/Meshtastic code so users could use ANY XMPP client to interface with a Meshtastic device? I have been working some ESP32 code that establishes a connection with Astra chat on my iPhone, but I don’t have a good understanding of XMPP yet and I definitely don’t have a good enough understanding of Meshtastic to integrate something like this into that code.
I like the idea, but XMPP servers are fairly complex, so it would be difficult to put one on the ESP32 or any of the currently supported Meshtastic targets. The ESP32 is fairly constrained (as are most of the other Meshtastic targets) in resources – at best, you’ll have a few megabytes of RAM to work with, as opposed to the tens to hundreds of megabytes of RAM needed to run most XMPP servers. This doesn’t even factor in the considerations for storage, which are extremely limited on current Meshtastic targets.
If you’re looking to interface XMPP to Meshtastic (as a network), consider bridging MQTT to XMPP, as there is some preliminary work on enabling MQTT on Meshtastic, as well as some future work planned for Meshtastic to bridge to Matrix. Another approach would be to take advantage of the TUN support in Meshtastic – attach a Meshtastic node to a PC running XMPP, and start the TUN adapter via the Python CLI.
Note that it’s possible to make an XMPP client (which is much simpler) on the ESP32 – and it appears that there have already been several projects for this. Interfacing with this would require an external server – and it sounds like that’s not what you’re trying to do.
If you’re looking for an app-free experience on a phone, @sachaw is working hard at making a web-based GUI, accessible from a browser, hosted directly on Meshtastic devices. (From what I understand, it offloads much of the computational tasks to the web browser/client, which would be awkward for XMPP.)
I guess I should clarify a bit. I was not thinking a full blown XMPP server that would handle multiple users/clients. My thought was just enough of a server to manage handshaking with one client connecting to it so a user could download any XMPP client app(like Astra Chat) and have a familiar UI. My desire would be to get notifications on the phone(the phone buzzes or beeps in my pocket) when a message was received from the Meshtastic device. My intended application is to provided text message functionality on youth camp campground for the staff. The campground is basically off grid, out in the sticks as we say it. The campground is about a half mile square. I have done some testing on site with my Tbeam and TTGO LORA32 and basically covered from one side to the other. i can only imagine coverage would be even better with meshing. I am thinking around 10 or 20 devices (one for each staff member) total covering the area, but notification is NEEDED for this application.
Maybe run the ‘full stack’ for XMPP servers on raspberry pi zeros and use Meshtastic to link the individual servers using the MQTT features recently added.
What would be really cool is what was mentioned before, a PWA (Progressive Web App) that has a richer chat interface / features and allows more than one user / identity to natively use a node over wifi.
Something that should be easily possible for a single connected user per node.
I have not been able to follow as closely as I use to as of late but from what I remember the underlying layers assume there is only one users per node / phone. I’m not sure if that was changed in the 1.2 branch but I do distinctly remember it being discussed as a bit of a limitation a long time ago.
As much as I’d love to bring XMPP into the mix, “just enough” XMPP server for an XMPP client to connect to it would be fairly difficult on the ESP32, still. Doing so would cut down on the RAM footprint (as you’d no longer need to support multiple users on one connection), but you’d need to translate XMPP concepts onto Meshtastic concepts. I don’t think that would be trivial to do (I know of no XMPP servers that I could trim down to less than 4 or 8 MB of RAM).
For example, while such a stub server wouldn’t need to maintain multiple connections locally for each user, it may still need to create phantom users for each remote node on the mesh. Messages could be relatively straight forward to translate, along with message acknowledgements
Sport7biker’s idea for multiple full-stack XMPP servers would be more feasible, as you’d have a more capable Raspberry Pi running the XMPP server – but I’m not sure it would make a lot of sense for this particular deployment to have multiple (federated?) XMPP servers.
But if you can have one Raspberry Pi (say, Raspberry Pi Zero W) per mesh node, that gives you a lot more flexibility. Given the amount of resources available to a Raspberry Pi Zero W, you could, in fact, gut an existing XMPP server and replace the core communications with whatever you want – including a backend supporting Meshtastic, which would allow you to connect with a conventional XMPP client. Unfortunately, there’s a huge drawback to this; the power requirements for the Raspberry Pi Zero W are enormous compared to Meshtastic.
Running a single XMPP server on a single Raspberry Pi attached to a Meshtastic node would be fairly simple; its biggest limitation here would be a single point of failure, and reachability (direct or mesh-routed) to that node would be necessary for communications.
I’m still inclined to say that your best bet is probably the webapp. I hear sachaw welcomes PRs.
@jdstroy thanks for sharing your opinion with me regarding my idea. I had no idea how feasible it would be. I understand memory is very valuable in this project. There is a lot going on in that ESP32. I have played around with ejabberd on a raspberry pi in the past and that was very easy to set up. I may have to dig out that old RPi and play around with that.
Just a thought, have you used the Meshtastic Android client? Would it suit your needs?
If you have to have something that’s more familiar and you already have the hardware (which, it sounds to me like you already do), I think the approach of using Meshtastic as an IP layer transport for XMPP might be worthwhile.
You’ll need something like two Raspberry Pi devices, and perhaps three Meshtastic nodes. The logical topology would look something like:
[Meshtastic Node 1] <<--[serial link]->> [Raspberry Pi client XMPP]
[Meshtastic Node 2]
[Meshtastic Node 3] <<--[serial link]-->> [Raspberry Pi XMPP server]
If that works reasonably well, I think I recall someone interested in implementing a TUN client on Android for Meshtastic. You’ll probably want to run some kind of duplex testing (perhaps a bot that sends unsolicited timestamps every 15 seconds) to see how congestion impacts XMPP traffic on Meshtastic as well. (Don’t forget to factor in TLS overhead if you want C<->S privacy.)
For some idea on power consumption, take a look at:
In the hypothetical case where you have a gutted XMPP server running in under 4 MB of RAM on an ESP32 on the T-Beam, you’ll need to keep Wi-Fi on, which will also mean drastically higher power consumption, as (IIRC) the ESP32’s power domains would require the Xtensa core to remain on as well for Wi-Fi as with BT.
I’m also interested by a system with XMPP for this reason :
I want use a system meshtastic in a command post with somes computer (somes users : max 5 - 10) or smartphone on one meshtastic node. Energy isn’t a problem because there is gererator or 220 VAC. I want use a rpi (XMPP server with meshtastic python library) for interface between ESP32 and others stations on the the network.
Node meshtastic will be a user of XMPP server. Client connect via a app like Jabber. After, why not a web tchat ?