41–50 of 99 posts
Earlier quoted context omitted.
The only fully-functional stack currently available requires Python >= 3.8, which is the main limitation to where it will run. But there’s still a lot you can do with that!
there is a pretty compatible rust implementation as well which claims to target microcontrollers https://github.com/BeechatNetworkSystemsLtd/Reticulum-rs
The Software shall not be used, directly or indirectly, in the creation of an artificial intelligence, machine learning or language model training dataset, including but not limited to any use that contributes to the training or development of such a model or algorithm.
Earlier quoted context omitted.
In the LoRA/radio device sense, Meshtastic[1] is probably the easiest to get started with. It's the biggest player in the space, has devices that come pre-installed and configured, the most likely chance of making contact with someone else, etc. MeshCore[2] is the other major player. It's newer and tends to have been adopted by communities that have run into issues with large Meshtastic networks. If you meant PC-base…
I've had some experience with both Meshtastic and Reticulum, and Meshtastic software was mostly unusable for me even with 3-node networks. E.g. a node sends a message and gets a successful delivery notification from the receiver but the receiver fails to display the message to the user. Reticulum was mostly working fine. Haven't tried MeshCore yet.
Earlier quoted context omitted.
Lora, especially on regulated bands that are the most used ones, is designed for very small, very infrequent messages. It isn't suited for real-time chat (nevermind secure) and so I think you can't really make it work while respecting transmission regulations. There are lora modules that work on the 2.4GHz ISM band but then you probably need to consider whether Bluetooth is not a simpler choice if range is not the no…
>It isn't suited for real-time chat (nevermind secure) It is encrypted on private channels and direct messages. >and so I think you can't really make it work while respecting transmission regulations. I don't know from where your information's are from, but for sure not from reality. Voice encryption/scramble on Amateur-Band's is not allowed, everything else is ok.
1. The library is written in Python. If you want to design phone apps, Linux server daemons in C, or embedded software (for example for the Lilygo T-Deck) this is a bad choice. Somehow doable (execpt for embedded), but no fun. A small lib with C API and C ABI would be better.
2. Most of the end user software has a horrible UI. But it gets better with software like the Android messenger Columba (https://github.com/torlando-tech/columba).
If we would solve 1., we would have more end user software.
Currently, there are 4 project who try to solve 1. by writing a Reticulum lib with a low-level language, everybody does it in their favorite language and on their own, of course: C++, Zig, Rust, Go
The Rust implementation from Beechat seems the most mature. But I did not see it used in the wild, outside of Beechat's own devices.
Earlier quoted context omitted.
>It isn't suited for real-time chat (nevermind secure) It is encrypted on private channels and direct messages. >and so I think you can't really make it work while respecting transmission regulations. I don't know from where your information's are from, but for sure not from reality. Voice encryption/scramble on Amateur-Band's is not allowed, everything else is ok.
I know what features it claims to have. The question is how well this can work on bands (US915, EU868) that very strictly limit the amount of time a device may transmit. IMHO you can't really have interactive chat on a mesh network over lora in those bands.
Yeah...no i don't think so.
>IMHO you can't really have interactive chat on a mesh network over lora in those bands.
Devices allow 10% Airtime on ISM here (EU) that's about 300 messages (with 255 characters) per hour, and yes interactive chat is possible with around 20 seconds of lag.
EDIT: I stop here, so much half knowledge that sounds educated but is in fact just wrong and TBH not even sure if i talk to a selfhosted AI.
Have a good Day.
Earlier quoted context omitted.
I know what features it claims to have. The question is how well this can work on bands (US915, EU868) that very strictly limit the amount of time a device may transmit. IMHO you can't really have interactive chat on a mesh network over lora in those bands.
>I know what features it claims to have. Yeah...no i don't think so. >IMHO you can't really have interactive chat on a mesh network over lora in those bands. Devices allow 10% Airtime on ISM here (EU) that's about 300 messages (with 255 characters) per hour, and yes interactive chat is possible with around 20 seconds of lag. EDIT: I stop here, so much half knowledge that sounds educated but is in fact just wrong and…
I am not picking on Meshtastic specifically, it's just that Lora and, especially the regs on those bands are such that some applications are never going to work well beyond extremely small meshes, if at all.
> The Zen Way: "I am . Wherever I am, my peers can reach me".
> When links are intermittent and latency is measured in minutes or hours, "real-time" is an illusion. Reticulum doesn't encourage Store and Forward as a mere fallback, but as a primary mode of existence. You write a message, it propagates when it can, and it arrives when it arrives.
Let's say A and B are talking.
A sends message A1.
B receives message A1.
B sends message B1.
A receives message B1.
A sends message A2.
Something happens and B doesn't receive it.
A sends A3.
B receives A3.
Later, B receives A2.
Now what does B do with this information? Does the envelope contain all the metadata about when A sent it so B client software can order the messages properly?
Earlier quoted context omitted.
>I know what features it claims to have. Yeah...no i don't think so. >IMHO you can't really have interactive chat on a mesh network over lora in those bands. Devices allow 10% Airtime on ISM here (EU) that's about 300 messages (with 255 characters) per hour, and yes interactive chat is possible with around 20 seconds of lag. EDIT: I stop here, so much half knowledge that sounds educated but is in fact just wrong and…
Yes, in the EU one subband allows 10%, the rest is 1%. I believe that Meshtastic uses the whole 250kHz of that subband by default. This is by far the most relaxed constraints of what is available in the EU and US. That's about 180 max. size messages per hour (at longfast) per device but you need to take into account retransmissions, acks, mesh management and routing of third party messages. So it may work, barely, fo…
Again wrong, just look at EU vs US:
https://meshtastic.org/docs/configuration/radio/lora/#region
> beyond extremely small meshes, if at all.
180 online nodes (300 at max) is not extremely small (and that's our small mesh EU with medium_fast)
Earlier quoted context omitted.
See term D.4., the relevant part of which is > You grant us and our legal successors the right to store, archive, parse, and display Your Content, and make incidental copies, as necessary to provide the Service, including improving the Service over time. This license includes the right to do things like [...] or otherwise analyze it on our servers; share it with other users
That could be boilerplate legalese for " obviously we need access to your code if we're to display and share it (as is the purpose for a public git host) "