konsumer's comments

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.

you should read more about it here, it's fascinating stuff: https://reticulum.network/manual/understanding.html

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.

No DHT. it seems to work fine for 1000s of nodes without it, though. The TCP testnets, for example, are pretty highly populated.

I started working on a Arduino implementation, but it needs more testing.

It works like your address is the hash of your pubkey, and you can announce that or not.

I've been obsessed with reticulum. It's a network over other networks. https://konsumer.js.org/nomadnet-js/ https://github.com/konsumer/rns-lite

The protocol is fairly simple, encrypted by default, and works over lots of interesting transports.

I made this to contain a bunch of graphical apps used for gameboy-development: https://github.com/konsumer/docker-gb-dev

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.

I made this to do similar, it goes both ways: https://github.com/konsumer/jsflat

Nice! I like the tutorial format. I made this along similar lines: http://konsumer.js.org/learnsql/

ah, yeah, forgot acc param in reduce. updated.

And whether it mutates is kind of a surprise. Like reduce doesn't, even though it works similar to forEach, map, and every.

It should be noted that you can still mutate in these. Like it's not at all recommended, but you have access to the original array in many of the functional "non-mutating" Array methods, for example: https://codepen.io/konsumer/pen/bKKYJO?editors=0010

This can make things very hard to troubleshoot.

INSERT OR REPLACE does this. http://www.sqlitetutorial.net/sqlite-replace-statement/

Totally. I generally use svg icons for anything where I don't need them to match color/size of text, automatically. I just noticed a few people asking for them as a font, and thought I'd help out.

I haven't gone very deep with this issue, but I worked with Rod briefly at Nodesource, and hope more node-ecosystem projects respond like this. In the short time we worked together, I was completely impressed with him technically and socially. I was really surprised when I heard that anyone had an issue with him. I specifically remember the COC (which I guess this is about) was mandatory for all projects, and it's adherence was extremely important. I think he has very high standards of quality, but never personally saw any kind of hostile behavior (I'd say the opposite, as he was always really helpful.) He is an asset to any team, and I hope this blows over soon, so he can get back to doing what he's good at.

I really appreciate the design of these! Awesome work.

I would be fairly straightforward to use these in icomoon, but for some reason all of the icons have a hitzone rectangle that blocks usage:

    <rect x="0" y="0" width="36" height="36" fill-opacity="0"/>

I got rid of all those, and made this icon-font, if you want that: http://clarity-font.bitballoon.com/