Nomad / Web Chat UI on standalone Lora32 device?

[Black6spdZ]

Is it possible to have a true standalone Lora32 radio with integrated chat UI "device in WiFi AP mode or AP connected" so that it can be device / OS independent and no extra software to be installed on end devices? Similar to the defunct disaster radio project

[faragher]

Currently there are no MCU versions of Reticulum routers in general. It might be useful to put a web-page based chat utility on a radio, but that leads to issues with the radio having an identity, not the user, so everyone connecting to it would see everyone else's messages. Adding in individual users and dealing with authentication and security is a huge rabbit hole.

It might be worth adding SD card support to the console so you could carry a Sideband APK with you on the radio, but it seems like this kind of interface has so many details that are solved by using Sideband.

[cobraPA]

Well, in general... I think you could take something like a raspberry pi and pair it with the RNode hardware in a case. I'm not sure your 'true standalone Lora32 radio' is fully realistic, you need somewhere to run the network stack and the Lora radio firmware. But from an outside the box perspective, the hardware I mentioned running a linux variant should be do-able now, I think. None of this is OS independent in any form though. What is the goal there?

[Black6spdZ]

I'm thinking back of a simpler project, disaster radio that had an integrated web chat but I wonder why it was abandoned

[cobraPA]

Is it the 'disaster radio' found with a simple web search? Looks like active until around 2020? I had not heard of it, but was curious. Do you know what country/countries they are based in?
I found their plan interesting but a little odd, coming from USA. We have HAM radio here (and I know many other countries as well.) This involves licensed private people using many different types of radio, but they volunteer to provide communications in many disaster scenarios. It seems like the 'disaster radio' folks were focused on a set of hardware and lora, rather than using existing communications technologies? Just my high level quick read. I don't know much about the organization from the web reading I did.

[Black6spdZ]

yeah, I think they stayed consistent to lora/esp32 hardware and the means for offline communications which I think is where this platform shines! even the lowest bitrate/long distance mode of ~200bits/sec is plenty for SMS messaging.. 3-4 hops could connect a mesh up to 10 miles NOS! I like that the Meshtastic project is very active but I feel like they've expanded the scope of the project where it doesn't do any one thing great.. trying to bridge MQTT, GPS location, remote GPIO control, etc. has gotten it quite bloated it seems like. Then there is Ripple communicator that also tried. My ideal idea is to have the Lora32 devices WiFi/IP connected to your local network so it can be used as on offline communication method and then if your AP goes offline it will switch to AP mode that will let you web directly to the radio for lights out mode

[faragher]

I have no information on the interior workings of Disaster Radio, but generally speaking projects fail due to declining interest in their stakeholders and feature creep.

Projects are heroic amounts of work, and infrastructure projects are catastrophic amounts of work. I did a feasibility study for a dam dredge, not a plan, not a proposal, a feasibility study for running a machine, dumping the tailings, and hauling them away. It was 40 hours of work. People only do this amount of work when it has value for them. Sometimes that's pay, sometimes that's personal contentment, but every person needs a reason to put in the effort. If they lose traction, if the project reaches a natural conclusion, if the need goes away, or if they find a more rewarding task, they may walk away. If their goal is money or recognition and they don't get that in the timeframe they expect, they can lose interest. If it's a larger amount of work, or if it's not as fun, or if it simply only seemed like a good idea because three excitable, slightly drunk friends were having a good night, then it crumbles.

This isn't inside information on Disaster Radio, this is a post-mortem on the businesses and projects I've watched burn, sometimes with me at the helm.

Nothing puts a project greater risk of this than feature creep. "Yes and" is only useful for improv. Anyone in project management or leadership knows the most important thing to learn is how (and when) to say "no." In the extreme, a project needs to take a page from Dune: “Arrakis teaches the attitude of the knife - chopping off what's incomplete and saying: 'Now, it's complete because it's ended here.'"

It's the reason there needs to be a polite but firm denial of ideas that don't conform to the project's scope. "This would be a neat feature" isn't a reason to add something. "This is required" is a good reason.

Examples from the Reticulum Ecosystem: Does the RNS provide messaging capability? No, and it won't. LXMRouter does. RNS does network routing. It does not send messages, it does not send telemetry, it simply moves data around using multiple interfaces and with different end point modes. That's a tremendous amount of work and has a large logistical footprint, keeping up with issues.

LXMRouter takes care of messages and has capabilities for transporting telemetry, but NomadNet and Sideband collect and display the messages, and only Sideband does the same for telemetry. There are no message boards, alert systems, discussion groups, or the like in the RNS, But all of these have been implemented by individuals who wanted to see them made. By building a framework, rather than a single sprawling application, the project can not only address wider issues, but also should the need arise teams can specialize in one segment or another. The firmware/software divide has really allowed people to build their own applications without digging too deeply into embedded C++.

You can't be everything to everyone, it's best to do a small number of things right. A modular system allows more to be built later, but keeping scope limited allows a project to be completed and maintained. The one constant I see from projects that fail is huge claims and plans with no road to get there.

As people have said in this thread, it seemed they expected to do many, many things, and there may not have been the call for it in practice. Reticulum as a daily driver than can be used for emergency purposes is much more resilient to lack of interest. Think the Internet, Television, or FM radio. Very useful for getting information out. Weatherband radios? A narrow group of people swear by them, but they're not a universal communication mechanism. NOAA alert systems are more useful but, again, rare. Like a phone, Reticulum can be kept in the pocket, used under daily conditions, and on-hand for when things get strange.

Which is not to say Reticulum can't catch fire tomorrow and Disaster Radio become the universal standard, and I very much wish anyone interested in public safety unmatched success! But out of all the projects I've seen, I became involved in this one because I liked the capabilities and the ethos, but also because I've seen half-baked well-wishers with great claims and moderate plans, and Mark absolutely knows what he's doing on a conceptual, technical, and planning level. I think it's the smart way to place a bet with my time and energy.

I realize it's a large wall of text only tangentially related to the basic question, but I liked the idea of Disaster Radio, and if they can't succeed, I at least want to point out where they, or someone else, could avoid making common mistakes.

That being said, pertinent to your original post, it might be interesting to look into working the RNode into a library so other apps can be made around it, but that's beyond my skills to even say if it's feasible.

[Black6spdZ]

interesting background and well written summary.. I kind of understood that Reticulum was just the underlying communication portion.. which from what I've read does that extremely well. I've seen it mentioned but also wish there was a web based flasher such as the other esp32 based projects have.. it would greatly expand the user base and adoption of the project as a whole.. but I digress.

[faragher]

There was some discussion about that at one point. Don't know where it ended up.