The discord is still very active, and there are still commits from original developer, so I am not sure. Its a simple enough protocol, though, and it's been reimplemented a few times. I made my own no-class python version, js, C, etc. Someone made a rust version.
Reticulum gets around a lot of these problems, as the (better) encryption is app-level (or even more fine-grained.) Its also not tied to lora, so you can interop easily with other transports. I made a websocket transport for it, and there is already TCP and UDP, and a couple non-lora radio transports. I also made a (works on web) js and Arduino client lib, and it has a few native client libs, so it can sort of be used on anything, even over traditional networks, or web clients. Meshcore and meshtastic are way more popular, but reticulum seems so much better, to me, for most things. It can still have overload problems, like any radio network, but no client is required to forward, so you can build a different kind of network ("only forward messages that are for my peeps" and marked correctly.) It also has "it costs compute PoW to send to me" which can greatly cut down on spam.
It works great with lora, but each interface is it's own thing. It's not exactly like meshtastic/meshcore/etc (for better or worse) but also fulfills totally different roles. You can connect 1 interface to another, and only forward messages for particular addresses, if you want, or addresses that have announced on a specific interface, and you can control what you want to propagate/route.
You can set it up tons of different ways, so just imagine this is what you want:
- 20 ESP32 lora devices around my house, that respond with sensor-data or something
- a pizero connected to the internet (via a huge TCP testnet) and lora (via a SPI device connected to some GPIO.)
- These are not "secret" anyone can ask a sensor for it's data. the messages are encrypted, but they are intentionally public
If any of the 20 lora devices want to to be available to talk to someone on the internet, they can, and their announcements are forwarded, so people on the testnet know the address.
I can set it up so only messages directly to those 20 devices is forwarded, but otherwise announces are recorded (and replayed) on the pi.
Additionally, I can setup propagation for just my 20 devices, so even if they are out of range or turned off, they will get the message (from the pi) when they get back in range or turn on.
In this example, the structure of the network forms a kind of tree-like thing. Each tier of the network is scaled to the amount of traffic it can deal with: pi can deal with a ton, and is connected to internet, the ESP32s only need to deal with 1-to-1 traffic (announces don't really matter to them) and only compete with traffic from 20 devices (on the same lora network.)
These messages are pretty small (an announce is ~160 bytes, message proof is ~115 bytes.) For larger messages, you string them together over a link (a 1-to-1 encrypted tunnel.) I think a key thing though, is that not every tier of the network needs to send all the same packets. For example, not even 1000th of the "testnet firehose" gets sent over the local lora net of 20 devices, based on how it's setup here.
So, the usage-flow of this would like this:
- each sensor announces on lora, pi forwards that to internet ("hey my address/pubkey is X, and I have these cool capabilities as a sensor")
- a user on internet sends a data-message to the address "hey give me your sensor data"
- the pi routes that from internet to lora, and propagates (replays periodically if the lora is not around)
- if the esp32 has not seen that peer, it can request an announce (and the pi will forward that both ways)
- the esp32 responds "oh hey internet user with X address, my sensor data is X"
- the message is sent over lora to the pi, which forwards on to internet
for very small data, if you don't care about P2P encryption, you could even put the sensor-data directly in the initial announce. "hey I have this address/pubkey and the current temperature is X" since announce "app data" is great for a very small amount of data.
It has wine and some old windows-only apps. I took a different approach, and used a VNC server. Not quite as fast, but doesn't require the host to have an Xserver. I even include a little web-based VNC client, so no install is needed.
One thing I love about blocky vs scratch is that it outputs regular code, in several languages. This means you can use it as "guard rails" up until you understand the concepts, then start using the generated language when you need more. It's also a DSL, in the sense that you can generate regular code from any blocks you make, at any level of the code flow, and you can mix that with already-made blocks for your target language. I started work on a Minecraft bot/mod tool that outputs JavaScript, for example, and added the full API (that is available in JavaScript code) so if you feel limited by the the blocks, you can just focus on the code. I stopped working on it, because the library it depends on to interact with Minecraft stagnated (and got really out of date with Minecraft versions) but a similar approach could be applied to pretty much anything. https://github.com/konsumer/botmodblock
I get that they were trying to focus on staging, but unlike old silent films, this is very hard to follow without dialog cards, if you've never seen the original. Also, the music really doesn't fit.
I think this is correct, like in the sense that react uses a VDom. When you make changes, you sort of pretend that you are changing everything, but the rendering engine figures out the differences to the real DOM, based on the in-memory changes, and makes minimal edits to it. This is why you can use react with all kinds of things that aren't DOM or even web-related (react-native, react-blessed, react-babylonjs, etc.) I contributed to react-blessed & react-babylonjs, and wrote the main chunk of react-babylonjs's current fiber system. You essentially just use the VDOm to describe the full graph, and that graph doesn't have to be DOM at all.
Agreed. I loved pebble so much. Amazfit Bip is cheap, has really long battery life, always on color screen. It does basic notifications fine. It is definitely less configurable, and it's built in apps suck compared to pebble (eg you have to setup alarms on your phone!) It's also not as programmable, but there are hacks to make new watchfaces so you can do basic stuff. I had a Fitbit versa, and even though I liked the built in apps and how programmable it is, it has a 2 day battery vs like a month, and it kept not handling notifications with my Android. I really wish my pebble just worked still, though. It was the perfect balance of battery life and configurability.