The New RNode Ecosystem Is Here

[markqvist]

I made a post over at unsigned.io going into some detail about all of the new RNode stuff that was just released. You can read it here:

https://unsigned.io/articles/2023_01_16_The_New_RNode_Ecosystem_Is_Here.html

[githubques]

A LoRa manufacturing suggestion (long winded to cover the bases):

I assume a RNS milestone will be having a town or neighborhood in a city setup a decent sized mesh Reticulum Network consisting of Androids and Laptops running Linux (along with some PinePhones hopefully).

Hypothetically, this network is established at a minimum as a fall back emergency system for residents where say one household per street has a RNS setup to be their "Comms Captain" to be able to communicate with other Comms Captains in their area similar to the Florida Hurricane example posted on this forum a few months back using Androids.

1. If doing this will require 20 LoRas, how long will it take you to make 20 LoRas?

2. If the idea catches on as a concept to 5 more nearby towns/neighborhoods quickly, how long will it take you to make another 100 LoRas?

3. And most importantly, what is being put on hold programming wise while you make these additional LoRas?

You may already be lining this up, but in addition to putting out the "How To" instructions for people to make their own, have you considered appointing dedicated manufacturers with the proven skills who can produce LoRas in various countries and send you a steady royalty amount to free up your time AND save customers on shipping costs when ordering outside of Germany?

Can't remember who, but there was someone in Pennsylvania, USA who did a video demo at a convention awhile back who seems competent enough to serve as your USA manufacturer.

Doing this makes RNS much easier to spread once it gets a foot hold in a town or neighborhood since each area is not likely to have someone readily available to follow the "How To" instructions you put out for making their own LoRas.

[githubques]

One additional passive income suggestion to fund operations involves setting up your own ICANN.

A LXMF address isn't something you can easily just tell someone is passing conversation like a phone number.

Is there a way that users can setup normal alphanumeric addresses like "anysite.rns" that is attached to your LXMF at 8dd57a738226809646089335a6b03695 ?

I know as it is, you can connect to a LXMF address and THEN manually assign a Nickname like anysite.rns, but you'll lose a lot of non-tech proficient people this way. Having a rns url keeps them engaged without having to learn the full LXMF string.

You can charge an annual fee of $5 to whoever buys a rns url for them self with their LXMF address still staying private in relation to the site if need be.

Once all this back end network building gets to maturity, having a general public ease of use rns url should help speed up adoption, especially with my aforementioned neighborhood network suggestion where if there's a natural disaster, neighbors who aren't on the system, but want to join suddenly through their android using the RNS app and Blue Tooth to ping a nearby LoRa, can remember "mytown.rns" better than the long string LXMF address.

[markqvist]

Thanks for bringin up this topic @githubques. There's some really important stuff here, and I'm quite happy for the oppertunity to talk about it.

I assume a RNS milestone will be having a town or neighborhood in a city setup a decent sized mesh Reticulum Network consisting of Androids and Laptops running Linux (along with some PinePhones hopefully).

Yes, that would definitely be a very good milestone :)

If doing this will require 20 LoRas, how long will it take you to make 20 LoRas? If the idea catches on as a concept to 5 more nearby towns/neighborhoods quickly, how long will it take you to make another 100 LoRas?

Realistically, I can produce around 250 devices like the Handheld RNode, or similar designs, every month. That's about 3,000 devices a year. Not a lot, really.

And most importantly, what is being put on hold programming wise while you make these additional LoRas?

While I can produce that amount of devices, I certainly don't hope that reality will actually come to pass. I'd sure earn a lot of money, but at that point, around 75% of my working capacity would be tied up with producing devices, instead of writing code and documentation. It's not a sustainable situation, and we need millions of devices deployed, not a meager thousands a year.

This is exactly the reason I have been working to shift the whole RNode ecosystem in the direction it's been going for the last year. It's been a whole lot of work, but it's pretty much ready now.

In the beginning, this type of device was just a physical thing, a product, that you could more or less only get your hands on by purchasing one from me. Well, the design was open enough to reproduce if you had the skills, but realistically, most people do not, or don't have the time.

The continued development of the RNode concept into a system for creating a certain kind of device, instead of just a singular thing, is a much more healthy and sustainable way to go about this. From the beginning, the primary intention of this shift, was for the production of the devices to become completely distributed and centralised. I wrote in some details about this last year in this post.

With all the new information released, a more detalied build guide for the handheld RNode, and the availability of 3D-printable parts, I not only seek to make it easier for individuals and communities to produce devices for their own need, but I want to make it as easy and accessible as possible to produce and sell devices - either direct copies of my design, or one modified to fit the needs of other situations and people.

I hope the release of this information will entice people with the necessary sklls to see a good business oppertunity here. This way, the devices can also be adapted to their local physical and social environments, by those who know it, and the knowledge about making these things is distributed all over the planet.

This is already slowly happening, and now that every RNode includes the RNode Bootstrap Console, anyone with an RNode-based device has all the information necessary to build, use and sell more of them. Even if only one RNode is left in existence, the entire ecosystem can be re-bootstrapped from the information contained in that one device.

This is all ready and deployed now, and anyone who wish to make and sell them should really just get started. As I've noted other places, I'd rather help a distributed network of device producers to get started, supply the tools needed, and keep the firmware maintained, than make all the devices myself. It's the only sensible way forward, and the best solution for everyone.

My initial ideas was to charge about $7 for every copy of the firmware installed for commercial purpose, but run this on a completely non-crippleware basis. The only difference the "purchased" firmware has from the community firmware, is that the "Not For Sale" nag screen disappears.

The way this will work in practice is that anyone who wants to make and sell RNodes just sends me the fee per device produced, and receives a cryptographic signing key for removing the nag screen. This key signs the devices, and once produced, they will also be eligeble for all future firmware updates released from me.

This approach also means, that even if I should somehow disappear, all the knowledge needed for the continued upkeep, development and maintenance of this system, is literally distributed amongst thousands of people all over the planet. That is a really good thing :)

---

I'll just put this out there:

In my ideal world, I would release all of this, completely unrestricted and freely, each and every single bit of information, code and knowledge under an MIT license, and work every day of my life making open and human-oriented communications systems a reality.

I have so much work that I want to do, and while I don't often spend time talking about the long-term plans of Reticulum, there most definitely is a consistent and long-term vision, that will probably take me half a life to accomplish.

If I had funding to do so, that is what I would spend every iota of my creative output on. I live a simple life. I can survive on around $1,700 a month, and thrive on $2,700. That's the real-world cost of making all of this happen. It's so little, relatively speaking. At the same time, I have no idea how to talk to "money-people", and I definitely don't want to commercialise or patent the core technologies of Reticulum. I've said no to that several times "behind the scenes", and will continue to do so. For me, Reticulum is the foundation of a Free Technology ecosystem that I am working to build.

If we can somehow reach that level of funding, I can put all I have into Reticulum and related systems. It's not a lot really, and I really hope there is a way to do this.

[simplyequipped]

I have been (for a while, probably too long) in the process of starting a small side business focused on radio preparedness solutions. I've been pretty focused on kits and being an equipment reseller, but also investigating the development of some small custom supporting electronics and open source software.

However, I'm interested in this discussion about a US based manufacturer for RNode. I'm located on the east coast of the US. I've been following RNS and RNode for some time and I believe they are the future.

I need to pick up the materials to go through the new RNode construction process myself. From what I've seen so far it would be more efficient for mass production to design and manufacture a dedicated solution. I know you know this, just putting some initial thoughts down.

Let me know if you would like to discuss further.

[githubques]

I've got some updated marketing ideas given the Florida proto network doesn't look likely for at least a year.

However, if you're legitimately looking to start a small business for this, I'd suggest setting up a private group for the topic since it means going from philosophical to actual specific locations and methods.

[markqvist]

Is there a way that users can setup normal alphanumeric addresses like "anysite.rns" that is attached to your LXMF at 8dd57a738226809646089335a6b03695 ?

Not right now, but I've been working on the problem for a while, and I will have it implemented in code very soon. The trick is to do it in a way that is completely and truly decentralised, works for small/local networks, but can still be used to form global naming structures if you want to. I'm pretty sure I have a good system down for this now, and it will be relatively simple to implement.

I know as it is, you can connect to a LXMF address and THEN manually assign a Nickname like anysite.rns, but you'll lose a lot of non-tech proficient people this way. Having a rns url keeps them engaged without having to learn the full LXMF string.

I totally agree, and a way to have name-to-address mappings is of course essential. Once the Distributed Address Lookup scheme is implemented into the reference implementation, it will be easy.

A stark difference to the DNS system we all know, is that anyone will be able to form their own naming structures, or use ones that other people maintain, or mix and match how you choose. I should probably write a more in-depth article or explanation of it all somewhere.

You can charge an annual fee of $5 to whoever buys a rns url for them self with their LXMF address still staying private in relation to the site if need be.

That's something I had not thought about at all, but a very, very intereseting and good idea. There's a few really important points to consider here:

• Down the road, at least, I think it would need to implemented in a way where a non-profit, let's say The Reticulum Foundation, actually controls the signing keys for that particular naming structure, so it doesn't hinge entirely on me as a person.
• Like everything else in Reticulum, this needs to be entirely optional. You could imagine a foundation controlling the signing keys for a .rns top level domain, and that the resolvers for that were added to the default Reticulum configuration on new installs, but it absolutely must be possible for users to just point to another resolver of their choice, if they don't like the way that said foundation is handling the control of their name-mapping signing keys.

I should really go into more detail about this at some point, but the way the naming system is currently planned out, anyone can run the dald (distributed address lookup daemon) on their Reticulum-connected system, and start responding to name-resolution requests for any sort of name. Each dald instance can recursively resolve requests for namespaces it does not itself know, as well. But for someone to actually start using your resolver, they have to point their system towards your resolver, and they choose what namespaces it will resolve for.

That means, that if you for example include a default resolver for .rns in the configuration, anything under that namespace would get resolved by the verified dald resolver pointed to in the config, and that can in turn resolve name-mappings for sub-spaces.

So if someone registers mytown.rns, they could map it to a single address, or point it directly to their own dald resolver, and then start mapping out all of their sub-namespaces, and act as a local "naming office" for the people and organisations of Mytown.

The beauty of this system is, that it also keeps working if connectivity to the main resolvers disappear. Since the mapping chains are cryptographically signed, they can be cached on the network, and each individual system can query and verify them locally, even in failure conditions where connectivity to main resolvers are lost. It's pretty neat.

[faragher]

I'm having a hard time organizing my thoughts on this topic. Outside of poisoned DNS, most domains can be seen as authoritative, while by definition a distributed system can't be. Which is not me saying I don't highly prefer a decentralized system, it's just a conceptual frame.

Every node having a dald is the way to go, since you need to access a node to have a network. The problem is spoofing. Foo@Bar is meaningless if two organizations ask for Bar, accidentally or maliciously. (You have thought of this with your comment about the client choosing who is an authority over a namespace) The SSH fingerprint verification is basically built into cryptographic hash addresses, so spoofing in that regard isn't too likely.

I think an appropriate solution is to use the data page on a NomadNet node (forgive me, I've forgotten the term) to say "This is node Foo, and we have listings for nodes in that namespace." If the client agrees, it can be trusted as a dald. Otherwise it could be renamed or ignored. The administrator could also list other nodes as a courtesy, but that can't be considered authoritative, just a pointer.

This allows the current announce system to work with the dald, maintains distributed operation, and means small scale networks operate properly and easily. Bridging networks is still prone to collision, but only in the friendly name, not in addresses.

I'm not against organizations collecting specific nodes to assist in turn-key sharing of friendly addresses, but I'm worried that charging for a domain, so to speak, is going to inspire people to claim to be authoritative, collect a fee, and then muddy the waters. Foo.rns could be claimed by multiple authorities, all charging fees and running away into the night.

By fostering a free distributed network, it disincentivizes paying for names entirely, hopefully keeping the platform as distributed as possible.

But I am absolutely certain you've put more thought into this than I have, I'm just thinking aloud, as it were.

[markqvist]

Good thoughts.

Yes, there will never be one authoritative dald hierarchy. It is not possible in a distributed system, nor is it necessary or even useful.

[markqvist]

I'd really love to hear anyones thoughts, comments, ideas and anything else, on all of this. This has turned into quite a broad-ranged topic, but hey, sometimes open discussions in all directions is what leads to the best ideas :)

[githubques]

Here is my suggested roadmap for achieving your first neighborhood network using the working title of "RNSready"

FIRST - You actually have the prototype of your 1st neighborhood network in Florida according to @silveroranges with the October post: #107

Message with silveroranges and see if they're willing to talk to their neighbors about having one household per street around them (10-20 streets) agree to order one RNSready device to have on hand in case of an emergency. If the cost of $200-300 device is too much, have each household on the street chip in $20.

SECOND - Talk with @4c3e or someone else US stateside that appears to have both the passion (Mesh Jam 2022 #84 ), skills, and resources to build 10-20 RNSready devices ordered by the Florida neighborhood.

THIRD - The US builder builds the "RNSready" which is a dedicated all in one device with software preloaded and RNODE attached with everything synced with the other ordered devices so that it's ready to go out of the box to be put in the closet until word of a hurricane coming so it can be charged and then used for the duration of the storm.

The simplest construction of an RNSready can be taking an outdated Android phone that can load your compatible SB app update with a RNODE superglued to it. It doesn't have to be frills because the sole purpose of this device is to work when a hurricane hits despite having broader uses. This way no one has to give up their beloved iPhone to switch to android, worry about app conflicts, etc.

I like the idea of the PinePhone since it comes with a LoRa attachment that can become a RNSready without the superglue, but that requires additional programming.

As an aside: This might be a worthy topic to approach PinePhone developers with since they appear to be Nintendo in the mid-2000's trying to compete with behemoths Playstation and Xbox for the best graphics machine before pivoting to something neither has thought of before (the Wii).

FOURTH - Product is shipped to Florida with silveroranges holding a neighborhood wide test to get all the block captains familiar with using it.

FIFTH - Tell the next neighborhood about what's been setup and rinse, cycle, repeat. Those with a better than average tech knowledge will go ahead and just purchase RNODE's to sync with their androids, rPi's, etc. without the need of a RNSready to continue building out the network until it hits some kind of threshold for wider adoption in the region.

[silveroranges]

My network was just a few devices I made spread amongst some friends/coworkers who live in the same condo complex as me, and one guy who lives in the neighborhood close by.

I would definitely be interested in starting a local network for a longer term than I did before. Some points I would want to get familiar with or perfect would be;

1. Have a website accessible by anybody with detailed instructions, how the network works, what areas locally are currently connected, all that jazz. (Thought, maybe have a live geographical map with current network stats?)
2. Updates, I need to make sure I can update remotely, but also I need a way to assure people that it is secure. This would just require me to get some time to mess around with it. Preferably have more than one person able to do this so if something happens to me it doesn't all just peter out.
3. A way to provide internet. Honestly the biggest selling point I could make is the ability to provide internet post-disaster, probably with a starlink dish on battery power.

I feel comfortable giving a general area of where I live, which is 26.27, -81.70, and the majority of people who live here are retired people who aren't the best with tech, and wouldn't care about a project like this. The area is getting insanely expensive and I will be moving away in the next year or two. In fact 2 of the people who were part of the original network have already moved after their leases were up last month due to $1k+ rent increases.

The place I am moving too in the next yearish would be a perfect place for implementation, it is a rural area with large plots of land and very lax county codes (there is a few cool looking container homes). The current telecom infrastructure is very poor, with spotty reception, and typical rural internet. I feel like the mindset of a lot of people who seek out areas like that would be conducive to Reticulum, even if they aren't very tech savvy. In a year or two when it is up and running it could be a great model for future networks, figuring out what works and what doesn't, best marketing tactics to get people on board, policies, etc.

I am empathetic with Mark, I don't know much about raising funds with little to no strings attached (shareholders) other than crowd funding. I 100% agree with Mark's view of a free ecosystem. I am also not the best speaker, which is something I have been working on pretty hard since it's my current barrier to advancing my career.

[githubques]

Sounds like this isn't as turn key ready to test as I thought, but can be in about a year with your new location.

1. The website suggestions seem pretty doable.
2. It would be nice if SideBand/NomadNet had a very visible button that says "Update" to trigger the newest firmware update.
3. Providing internet beyond the RNSnet sounds very involved. That's for @markqvist to determine feasibility.

" I am also not the best speaker,"

There's a group called "Toast Masters" that I'm told is good for that sort of thing. I believe they have a chapter in most cities (or you can start one).

[githubques]

Is this a potential alternative to a LilyGo: https://pine64.com/product/pinecone-bl602-evaluation-board/

There's no digital screen or battery option like the LilyGO with the antenna and USB power cable sold separately:

https://pine64.com/product/pinedio-usb-lora-adapter/
https://pine64.com/product/pinephone-usb-type-a-to-usb-type-c-power-charging-cable/

Add it up and it's about half the price of a LilyGO setup is why I ask.

[githubques]

Going further, and apologies if this comes off as woefully ignorant from a tech perspective, but diving further into the PinePhone ("PP" going forward), the PP has some issues that mainly only a few of their dozen distros work reliably (can't make calls or text like UBTouch) and those that do work have terrible battery life because in a quest to be just as good as the duopoly, they've got a bunch of apps that run at full or near full capacity even when not in use sucking up battery life especially when the internet is used.

My bolder suggestion than the above asking for the SB app to be added to one of these working PP distros, is for you to fork the best performing one (Mobian, Arch, or Manjaro according to what I've read) and strip out everything except the phone and text features along with the SB app so the battery isn't drained as quickly.

Accessories like a clock and minor essential apps that don't drain battery much/take massive time to code can also be added, but basically you're recreating a flip phone with SB included to create the most successful PP distro that will draw programmers to the RNS cause with this "RNSready" as a PP or "PPready" where they can build out RNS apps that mirror duopoly apps without crushing battery life.

The "Libre" and "Above" phones are also open source Linux and appear to work better, but have a higher price point, so they may be worth contacting about just adding the SB app if PP is just too difficult to get up to speed. While looking for Linux phones I came across the Gabb phone which isn't Linux, but it's similarly stripped down to just calls and text without internet that they market to parents for their kids as their first phone.

A PPready could try and tap some of this market with the SB app available with a parental control for those who request it upon purchase just to bring more money in for the overall RNS effort. While the kid/teen using the phone can't access SB, it can still serve as a live node for others through the built in lora add on back plate to help build out the RNS network.

This is "pie in the sky" and likely requires a major detour on your road map so to see if this is actually worth doing, come up with a dollar amount you'd need to be paid to do this and post to the Pine64 forum your offer to create the best distro that just does calls, text, plus SB along with a link to your gofundme, kickstarter, or givesendgo to see if you can raise the money to justify making the pivot, if not, no extra effort on your part beyond a post and setting up a crowdfunding page.

[githubques]

Now to my most realistic suggestion given you're existing focus on Android, the RNSready which is the stripped down emergency communication device only that can consist of SB preloaded as the only OS on an Android Tablet 7 (because you can get them in bulk for $30 a piece), a usb antenna with firmware, along with a usb keyboard and/or usb solar cell if needed.

Following the Florida model, search news headlines of the past year for stories of communities that experienced massive damage due to hurricanes, especially if they lost cell service with rural areas being a plus.

Contact their local fire department and offer to set up a test network where each station has a RNSready along with one household per street in a 5 mile radius of the station or whatever gets you to 10 or so participants.

Map out the area and have RNodes placed where needed to setup the network and have everyone involved have their RNSready's turned on 24/7 with once a month system tests where everyone sends a "here" message to confirm everything is operational similar to ham radio enthusiasts do.

See if the fire dept and/or residents will foot the bill and if not I'm sure you can crowd fund the $1000-$1500 this will cost to setup soup to nuts.

And now you have your proto network setup that the one or two residents that are half way tech savvy can load SB on their androids and use as intended for private messaging one another thanks to this emergency network back bone.

Rinse, cycle, repeat and hopefully over time these proto networks become geographically linked to build out larger networks to eventually get where you want to go.

[githubques]

• RNS ICANN
• SB app on PP
• PPready Distro with just phone/text & SB app
• Libre/Above Phone SB app
• RNSready proto network

And those are my suggestions for creating your money road map that meets up with your tech road map to create a Reticulum Super Highway.

[The-One-Law]

Going further, and apologies if this comes off as woefully ignorant from a tech perspective, but diving further into the PinePhone ("PP" going forward), the PP has some issues that mainly only a few of their dozen distros work reliably (can't make calls or text like UBTouch) and those that do work have terrible battery life because in a quest to be just as good as the duopoly, they've got a bunch of apps that run at full or near full capacity even when not in use sucking up battery life especially when the internet is used.

---

I got one of the first Debian PinePhone renditions,
and quickly realized Debian was an awful choice for bleading edge tech.
I went through all the major distros available then,
and quickly joined all those recognizing that Manjaro Phosh was best.

(Not the PP pro yet, still unusable by all accounts)

RNS + Nomadnet runs a very lightweight overhead, barely breaking a (battery load) sweat.
baseline is 1.8w-2w, desktop running the screen and just a static user desktop
It might pull down more if any kind of polling takes place,
but power (+screen on, running nomadnet in console) is under 2w.

By comparison - Telegram and Element(Matrix) both guzzle battery.
Element seems to pull an additional 0.5w(->2w) (Electron may be a culprit.)
Telegram was a battery hog I uninstalled long ago.

The biggest battery load is flipping the screen portrait-landscape or heavy wifi loads .

Nomadnet runs okay but it needs some touch-screen fixes to make it actually usable.

[githubques]

Thanks for the info and it makes sense. Awhile back, someone posted that they came up with a NomadNet version that runs on Arch desktop. Manjaro desktop/PinePhone version is a fork of Arch.

It's also a good thing since Manjaro is PP's flagship OS they ship with all their phones. If you are curious and got some time, there's a newer PP OS called "Sculpt" that's a micro kernel intended to improve PP's main Achilles's Heel (battery life): https://genodians.org/nfeske/2023-02-01-mobile-sculpt

It's still in development, but it might be a great home for NomadNet/SB in the future.

[ProgrammerWhoPrograms]

That means, that if you for example include a default resolver for .rns in the configuration, anything under that namespace would get resolved by the verified dald resolver pointed to in the config, and that can in turn resolve name-mappings for sub-spaces.

So if someone registers mytown.rns, they could map it to a single address, or point it directly to their own dald resolver, and then start mapping out all of their sub-namespaces, and act as a local "naming office" for the people and organisations of Mytown.

This sounds a lot like the hierarchy of DNS.
Have you considered using the concept behind GNS or GNS itself?
https://git.gnunet.org/bibliography.git/plain/docs/gns2014wachs.pdf

[ProgrammerWhoPrograms]

The way this will work in practice is that anyone who wants to make and sell RNodes just sends me the fee per device produced, and receives a cryptographic signing key for removing the nag screen. This key signs the devices, and once produced, they will also be eligeble for all future firmware updates released from me.

Wouldn't this make it non-libre?

[parnikkapore]

Was about to comment that GPLv3 (which the firmware uses) does allow commercial redistribution of the software, including any patched versions (as long as the corresponding source is available).

Related: Ardour, ZRhythm, and TIC-80, who place limitations on freely available official binaries and offer a paid version with the limits removed. If you have a bit of technical knowledge though...

[markqvist]

Wouldn't this make it non-libre?

No, the firmware source-code is GPLv3. Having a nag-screen saying "Device not for sale", that can be removed by a cryptographic signature doesn't make it non-libre.

As noted, the binary distributions on GitHub and those installed via rnodeconf are supplied under specific license terms.

There's not even any functional difference, literally the only thing changed is the nag screen. I simply ask, that if you want to produce devices using the RNode Firmware, and do so using the tools I have made available that makes this very easy, and sell these devices, or otherwise profit from it, you contribute something back.

I think this is the absolutely most fair and respectful way to make these tools available to everyone, which is my goal. I do, however, need some sort of income. While I live a very simple and (compared to the median) insanely low-cost life, I can't survive on eating dust and happy thoughts.

I released all of this under GPL, in good faith that the community will be able act appropriately around that. It is also be a great testbed for how I decide to handle the release of the much more advanced and capable version 2 line of the firmware. If there's indication that the donation/commercial-use-fee model works, I could probably go ahead and even release all of the v2 toolkit under MIT.

All of these things did not just materialise over the course of an afternoon. I started designing Reticulum 10 years ago. Several thousands of hours have gone into all of this. I paid for that in time, effort and money, and I'd happily do it again, if I could. But realistically, everything will happen much faster, and much more efficiently if I can focus exclusively on creating free and open technologies.

All of the people who have already donated to, and supported the project in other ways, have made an incredible, real and direct difference in making all of this possible, and if not for that, we would not be where we are now. You are literally what made it all possible.

I really, really don't want to commercialise (in the sense of erecting payment-based barriers to entry) any of the technology developed in the context of the Reticulum ecosystem, and the only way for that to continue to not happen, is if there is some sort of consistent way of making sure that I (and potentially others working on this), can actually continue to exist and do the work.

Personally, I really don't care how that comes to be. I could spend the rest of my days in a yurt with a couple of solar panels, a water source and a steady delivery of basic foods, and I'd happily spend 100% of my productice and creative output on creating these technologies, free for anyone to use.

Realistically, though, we live in a complex world, that - for all persons - makes all kinds of meaningless demands on the level of participation in a (largely absurd) economic system, and I have unfortunately not found a way to completely escape that. Yet.

This means I need to try to come up with creative ways of ensuring a relatively reliable ingress of economic units, while still being able to distribute what I create in a fair and equitable manner, to anyone who might need or want these tools.

Also, in terms of not wanting commercialisation, please don't misunderstand me here. I am in no way against anyone building commercial services, product or systems on Reticulum. It is just not for me to do it. That would introduce an unfixable skew and conflict of interest into the entire project, and I simply wont do it.

[githubques]

A few more thoughts:

A) Looking around I found there's a mesh network effort specific to PinePhone:
https://lupyuen.github.io/articles/gateway
https://lupyuen.github.io/articles/ttn

I see similarities with RNS and it looks like a competitor, but maybe it's a potential partnership. I bring it up mostly because one of the programmers involved in the project dubbed "PineDio" received free hardware to whip up some software.

If Pine64 provided you with their PP LoRa Backplates, LoRa USB's, a few PP's, etc., would you take on the project now or are you just too tied into your current Road Map?

B) You said their PP LoRa USB's (and maybe antenna USB's in general) that cost under $5 each can work if they get the right firmware. This means for the cost of one $30 LilyGo, you can have SIX LoRa USB nodes which dramatically lowers the cost of setting up a local network and hence speeds up creation of one.

You can still charge your $7 (or even $10) to get rid of a nag screen whether the devices used to setup a network cost $5, $30, or $100+. I assume this can be done for a PP setup, but also to get an Android based network going faster.

C) I've made my suggestions for going the PP direction in part because I believe it will help you attract new programmers and donors since crowdfunding appears to be your preferred revenue model.

Get the impression your current crowdfunding isn't bringing in a reliable funding stream, so if diverting from your current path is off the table, have you considered courting additional media coverage through relevant channels to get more eyeballs on the project that can turn into more donors?

It was an article about "an off-grid internet" that led me to this project in the first place, but I don't own an Android to make use of it.

[githubques]

I've got another suggestion that doesn't involve monetizing Reticulum or setting up the first RNS network.

After viewing the series of "Do This!" posts that have suddenly popped up under Discussions, I want to apologize if any of my comments (especially those suggesting you take time out to divert course temporarily) come off the same way, it's just I've been following this project for at least half a year and with every new geopolitical headline I fret the LoRa's, etc. needed to setup a proper network are going to get further supply chain crushed and unavailable before you get to "Ready" status.

Back to the suggestion, you should add a footer to every one of your replies saying the following:

"This is the Reticulum Roadmap. Every time I have to answer your question, completing this Roadmap gets delayed by 15 minutes."

[githubques]

My insistence is based on the possibility I may be able to get the first RNS proto network setup which will likely be 95% androids, but I'll need it working on PP since iPhone doesn't work with RNS and I'm not getting an android.

I briefly had a set of older Androids to test with six months ago, but gave them away because they didn't work with the latest NomadNet/SB at that time. This was unfortunately before you came out with the versions of SB that worked on older Android OS's.

If you've already got another option lined up for the first RNS network solely using androids/Ubuntu laptops once you finish your current RoadMap work load, I understand the lack of interest on this free gear offer, but Pine64 is based in Poland and as the days go by, that neck of the woods may be getting more and more unreliable as a supplier.

If still not worth your time right now to make a shopping list for YOURSELF vs your current software design priorities, can you tell ME what items to get to setup a PP RNS network for whenever you get around to it so I have the hardware on hand?

[markqvist]

I'll get back to you on this tomorrow. I've just been really busy. Really appreciate your initiative here.

[githubques]

Much appreciated! I know you're busy and I'll shut up about the PinePhone after this and wait for it's turn on the RNS Road Map. Just want to have bases covered in case supply issues suddenly pop up.

[markqvist]

Haha, don't worry about it ;) I get why it's a pretty important thing to some folks, and I also think it's a natural thing to get worked into the ecosystem. As you know, it's mostly just a question of time and priorities.

Ok, so without further ado, this is the "minimal setup" I'd need access to for ensuring good Reticulum support on the PinePhone platform of hardware:

• Two PinePhones. Three units would not hurt though, since it makes it a lot easier to test congestion scenarios and CSMA approaches in a way that's as close to real-world as possible.
• LoRa add on cases for the phones.
• A couple of their USB LoRa adapters.

That should allow me to get drivers and any necessary interfacing software up and running, and make it possible to easily squash any platform specific problems in auxillary software like nomadnet, sideband and such.

I really appreciate your initiative on this, and I'd be very happy to receive a hardware donation from Pine64 with the goal of getting Reticulum well integrated on the platform. If they (or someone else) wants to donate the hardware, I will PinePhone support to the roadmap.

It will be a little while before I can actually do the work though. Currently a few other things on the roadmap rank higher, including getting support for th SX1262 and SX1280-based transceivers into the RNode firmware.

Once it gets to the point though, it'd probably be really nice to have the hardware on hand already. Probably also good to have it accessible in the meantime, since I can mess around with it a bit and get a feel for all the internals of their system before starting the actual implementation.

By the way, why not the PinePhone Pro? Is it not in a usable state yet? I'm pretty ignorant on the whole state of affairs here, so I am curious as to why you are not recommending focusing on that too.

[githubques]

By the way, why not the PinePhone Pro?

Here's the reasoning:

1. It's faster for me to find a donor than hope Pine64 agrees to outright donate the items with little or no knowledge about RNS. Sticker price of a PinePhone vs. Pro is $200 vs. $400 meaning $600 vs $1200 to get you the 3 you need plus accessories. PinePhone gets this done at a cheaper donation cost.

2. There are more PinePhones out there than Pro's since the Pro is newer and some of the reviews basically say that you're better off with the original because the Pro is still pretty buggy and the battery life in some cases is worse. This may have been fixed with newer updates, but why take the risk.

3. There's a new operating system getting developed as a micro kernel called Sculpt: https://genodians.org/nfeske/2023-02-01-mobile-sculpt and it's being designed for PinePhone (not Pro). Sculpt is focused on fixing/improving the battery issue (the major stumbling block for PinePhone to get wider adoption).

I believe RNS, PinePhone, and (likely) Sculpt can become a type of "Emergency Communication Trinity" with RNS as the carrier, PinePhone as the phone, and Sculpt as the operating system.

It will be like have a flashlight on hand when the lights go out during a storm. The PinePhone still works as a phone, but during a natural disaster like the previous Florida Hurricane test run (
#107 ), you don't miss a beat.

RNS development focusing on Android first is the obvious best route given its market share, but the PinePhone's Lora Backplate attachment actually gives it a leg up in usability without the need to attach a LilyGo or have one close by via BlueTooth like you do with an Android.

It's nice to see more PinePhone related posts here on the Reticulum Discussions page and going forward I believe both projects will benefit from one another where PinePhone developers use Reticulum to improve PinePhone and Reticulum developers use PinePhone to improve Reticulum.

If Pine64 wants to donate some Pro's directly, that's great, but for the reasons above, the original PinePhone RNS development needs to be first in my opinion.

[markqvist]

That all makes sense, thanks for taking the time to explain it.

because the Pro is still pretty buggy and the battery life in some cases is worse

I suspected something like that might be the case. Thanks for elaborating on it.

I believe RNS, PinePhone, and (likely) Sculpt can become a type of "Emergency Communication Trinity" with RNS as the carrier, PinePhone as the phone, and Sculpt as the operating system.

This is a very, very interesting prospect indeed. I will look more into sculpt. Micro-kernels are kinda a soft spot for me as well :)

If Pine64 wants to donate some Pro's directly, that's great, but for the reasons above, the original PinePhone RNS development needs to be first in my opinion.

Perfectly well laid out, all of it. I couldn't agree more.

[markqvist]

That is awesome! Thank you so much for sorting this out.

No, don't send anything there. I am moving around quite a bit, and it will most likely be a long time before I am in that area again.

Can you message me over LXMF or Matrix to arrange it?

[githubques]

Reinstalled nomadnet and hopefully the blue check message went through.

[markqvist]

Getting it, but I can't reach you. Maybe you are just offline now, so the messages are waiting on the prop nodes for when you get back on :)

[githubques]

82452

[markqvist]

Replied via Sideband