General Feedback

[singletona082]

Posting everything here rather than cluttering the line with a bunch of smaller items, as these are largely from the perspective of an enthusiast rather than someone that has technical knowledge to offer:

Initial Thoughts: I like the idea of there being a LoRa protocol with an eye towards an amount of infrastructure rather than insisting on a completely amorphous topology. I saw the Andy Kirby video announcing MeshCore (Might want to try re-branding, as the name is also some kind of blockchain scam project.) So I apologize if I'm asking questions you guys have already considered. However, As not everyone wants to join discord, or have funds to your site, I will talk here.

Question: What happens if a repeater node goes down and there are no repeaters but other clients in the area that are sen? Is there a fallback to an amorphous means of passing messages along?

Question: Are there any plans for more than just SMS style messaging? I like Reticulum's pairing with NomadNet, but at the same time while a command line focus is cool? I dislike that it seems to leave everyone else out to dry beyond the SMS style communication sideband allows for phone/tablets.

NomadNet:
https://github.com/markqvist/nomadnet

Question: Would Gemini (protocol) pages and traffic be too heavy for MeshCore's network?
Gemini Protocol: https://geminiprotocol.net/
Wiki: https://en.wikipedia.org/wiki/Gemini_(protocol)

Example Pages:
gemini://bbs.geminispace.org/ - Reddit-Like page/application/message board
gemini://kennedy.gemi.dev/ - Search Engine

Question: Would Email or other asynchronous communication be possible? I ask because while Email has largely fallen out of favor, having a way of getting messages to and from for the sake of passing messages between people who aren't able to have the same schedule will always be useful.

Question: As a last resort, would the TC2 BBS be viable?
https://www.youtube.com/playlist?list=PLshzThxhw4O5qCWbdzADyx1ck_Y5z9s11

Last Question: Would it be possible ot have the repeaters do more than just blindly fling traffic? Ie have those repeaters also act as content servers? Either for low bandwidth static pages (of whatever protocol is decided on,) mailboxes, message boards, or the like? Would it be possible to sync that data between repeater nodes for the sake of getting information across a wider area?

[ripplebiz]

Hi. OK, a lot of questions there. :-)

1. If there are no repeaters, the 'edge' devices can still talk peer-to-peer, ie. zero-hop. (on various screens, you'll see "0>" prefixes, showing that it came from immediate neighbor node)
2. Yes, a lot more than SMS-style messaging in the pipeline. Initially, there'll be txt, and sensor network/telemetry stuff. I want to get that nailed down first, ie. have some agreed up payload structures that others can target.
3. Yeah, serving 'pages' of some kind, but very lightweight content is desirable. I haven't, as yet, looked into Gemini or existing formats that could be utilised.
4. Yes, definitely (e)mail, and mailboxes. Also tied in with BBS concepts, so you can hit some 'closest-server node' and sync stuff that you missed while offline/unreachable.
5. About more capable repeaters--well, one nice upside to the way MeshCore works is that a standard repeater is actually incredibly simple, and a LOT of LoRa boards will easily be able to be supported. The variety of repeater hardware will probably really mushroom. But, yes, the content-serving and sync concepts will be for specialised repeater nodes.

[ripplebiz]

Also, to your youtube comment, I've already been considering this, ie. you could quite easily customise a firmware to persist learned paths to disk/flash, after a learning period, if you have a fairly static sensor network, for instance. Then they can just permanently use the direct routing for max efficiency.

[singletona082]

Appreciate the feedback. I'm not very technically minded. I have, however, been around since the (tail end of) the BBS era so I've hopefully got ideas that might be helpful.

I like Reticulum. In theory. In practice something just doens't sit right with me, and everyone flocking ot this terminal based nomad thing feels like 'ok cool we're all going to do the nerdy thing insteado f actually make something normal people will wantot use.'

Mind you nomadnet is insanely COOL in concept and the interface is genuinely nice for a terminal program... but most people are going to go 'yea but what can I do with my phone on this thing' then give up when 'you' offer a sorta janky SMS service.

[cannon-c]

1. Why create an entirely new protocol and cause fragmentation of networks and efforts instead of contributing (of which you'd all be great assets to) to and improving something that already exists and has momentum like Reticulum? How does this project differ from Reticulum?

2. I am seeing alot of bashing on command line, temrinal based user interfaces. Please keep in mind that many people including myself hate GUI only interfaces. Terminal interface is not just about looking cool but about being able to run in a terminal and not having to install a massive horrendous amounts of bloat of a desktop environment just to use something. Another advantage to terminal user interface is that it works in SSH. I'd even make a case that command line and terminal interface is even easier to use, no point and clicky around a complicated maze of menus and buttons, never have to take hands off the keyboard. However, there are GUI interfaces for Reticulum if someone wants a point-clicky app. With any project, whether Reticulum or even this, please do not be GUI only.

[cannon-c]

'yea but what can I do with my phone on this thing'

Another huge problem of many applications these days is that they are exclusive to "mobile phones" as in ios or android; both of which are spyware and the opposite of freedom. Someone should not have to carry a tracking device (cell phone) and a spyware OS just to use all these apps. It is good that nomadnet works on linux, it works on both my computer and even my (untrackable) mobile device which is in itself running linux also.

'ok cool we're all going to do the nerdy thing insteado f actually make something normal people will wantot use.'

"normal people" can stick with their little googley iphones and facebook chats. Lets not dumb down and neuter freedom tech just to try to get people to use it who don't even care about it anyways. Let's remember though, reticulum is a protocol, not just one client application. There are a couple GUI applications for reticulum.

[cannon-c]

Although I may disagree with some things, I hope to not come off as disrespectful in any way to anyone. I respect you all.

[singletona082]

Although I may disagree with some things, I hope to not come off as disrespectful in any way to anyone. I respect you all.

I'm glad you are trying to argue for a text interface approach, as text programs tend to be cheaper on memory and developmental budgeting. Plus, apologies if I didn't make this clear, I activly like programs like nomadnet. It has a cool factor going on and the interface is very clean.

However...

I am seeing alot of bashing on command line, temrinal based user interfaces.

You misunderstand me, and while I feel your comments are highly advisarial and come across as a gate keeper to declare 'unless you conform to what i want you are unworthy of using this.' While I think the text interface is nice, and I am increasingly headed BACK to a text interface as my eyes deterriorate, your response wholly ignores that most prospective users are going to pair with a phone or tablet rather than use a dedicated device like a t-deck or chatpad or the like. Current smart phones are, from my own experiance with terminal apps, terrible. Yes it can be done, but telling prospective users 'here you have to download this terminal app, downlaod a keyboard that gives you ctrl and alt keys, and THEN you have to memorize all these commands or else you aren't allowed to play in our sandbox' you know what you get?

No Users and a dead format no matter how good it may be.

See, I like text interfacing, and for me the ideal would be any graphical app for phone or the like is literally just a front end to the underlaying command line program for the sake of drawing in users. Much like how gemini can easily run with just using netcat aimed at a given gemini web address, but lagrange makes it so much nicer for those that want pretty fonts and features like in program bookmarking, juggling authentication keys, and so on.

So absolutely develop those text applications. However for the sake of personal preference when it comes to hoping to attract new users, make those applications in a way where if someone else wants to effectivly write a graphical wrapper for it to live in for phone useage? That'd be great.

[cannon-c]

@singletona082
Thanks for your reply. If I am understanding properly, I am saying that terminal interfaces should not be neglected, and you are saying graphical user interfaces friendly with mobile devices should not be neglected?

[cannon-c]

....for the purposes of increasing user adoption.

understood

[singletona082]

Thanks for your reply. If I am understanding properly, I am saying that terminal interfaces should not be neglected, and you are saying graphical user interfaces friendly with mobile devices should not be neglected?

Prescicely. I WANT more terminal applications. both because 'this might be the base framework for end user apps for mobile' and also 'you can automate terminal doings far easer and run them on low powered hardware with minimal overhead.

Example being having your radio hooked up to a pi zero 2w that does all the heavy lifting for ... whatever you have in mind (BBS, mailbox, whatever,) and not a care in the world that you're SSHing into the thing rather than staring at a local screen for the sake of oversight and upkeep.

Absolutely don't want terminal neglected. It's far too useful. however where Reticulum currently falls down is 'the phone users only get this SMS type sideband app... the TERMINAL users get a full featured enviroment to play with complete with forums, mailbox, messenger services, and static page serving via nomadnet.'

What i want is a network that has the ability to bridge the gaps between islands of high speed wifi, because you're never going to have broadband esque speeds bridged with the means e have without the internet and LoRa I feel is best used as a low bandwidth bridge between spaces (I live simi rural. all the old ideas of piratebox and the like to me always fell apart because 'well you're kinda out of luck buddy. You live too far away, sorry.')

If yo ucan get some basic service to mobile users, swapping focus to backend applications would be great, because the network is only as good as what everyoen connects to.

[fdlamotte]

Hi, thanks for sharing this project.

I'm thinking about using it to build some sort of meshed sensor network.

I've understood that the repeater and chat "roles" are distinct in your network, which is a design choice I understand.

Would it be possible for a node to have different roles (let's say chat and repeater) ?

If there was a sensor role, could it have some "repeater" functionalities ? so I don't have to bother adding repeaters in a sensor network to extend the range ...

I've planned to dedicate some time soon to play with this, and already have pulled out three nodes from my meshtastic net ;)

[ripplebiz]

If there was a sensor role, could it have some "repeater" functionalities ? so I don't have to bother adding repeaters in a sensor network to extend the range ...

Yes, you could make a sensor node AND have it also be a repeater. You simply add this to you Mesh sub-class:

bool allowPacketForward(const mesh::Packet* packet) override {
return true; // Yes, allow packet to be forwarded
}

For the public push, for this to scale properly, keeping the mobile nodes as 'edge' nodes just makes better sense.

[ripplebiz]

Oh, also, there is an entirely separate issue of how a node 'Advertises' itself. The advertisement packets have an 'app_extra' section, which has a certain encoding that is now emerging. I'll be refactoring the sample apps to use a 'AppExtraWriter' class, or similar, and have this all abstracted.
But, basically, a node can publicly announce it as a certain type of node (there are three now), have a name, a GPS lat/lon (optional), a battery level (optional), and temperature (optional).
The battery, temperature and GPS location are probably better put in some sort of PAYLOAD_TYPE_RESPONSE packet, and sent as a reply to a request. Broadcasting Advertisement packets just to update temp/battery, etc is very wasteful. These really need to be kept to a minimum.

[fdlamotte]

Great, I really like what I've seen sofar ...

I have a xiao esp32-c3 and a wio-sx1262 and I'm curious to make them work together (I got the wio with a xiao esp32-s3 but the connector is broken ...)

edit : could make a chat between a wio and an c3

[ripplebiz]

Regarding the debate about text/CLI interfaces, well there is now a 'Terminal chat' option.
The simple_secure_chat example has now been revamped.
There are two build envs: RAK_4631_terminal_chat, Heltec_v3_terminal_chat
Should be easy to add support for other boards.

Andy has also done an intro video: https://www.youtube.com/watch?v=BpIzqpDu4Y4