31–40 of 40 posts
Sigh....I quite literally laid out this exact design in my head during my 6 hour business travel today. I was brainstorming designs for military swarm applications. Congrats lol
Earlier quoted context omitted.
It's not encryption that's needed. It's authentication. How do you decide who's allowed to join your mesh if it runs on WiFi discovery?
Like others suggested a basic step would be to use a certificate based approach where a company (or basically any deployment) gives out certificates for robots allowed to join and you only communicate with them.
Earlier quoted context omitted.
Like others suggested a basic step would be to use a certificate based approach where a company (or basically any deployment) gives out certificates for robots allowed to join and you only communicate with them.
But how do you distribute the certificates? It's cold-starting peer to peer distributed systems that's hard.
Another way would be to somehow prove that you belong.
In Profinet / Ethernet based networks it's more common to use ARP or mDNS for the discovery because multicast addresses are supported everywhere. Multicast DNS would be independent on top of the existing network layer and compatible with smartphones and other consumer devices (and even printers). That's why I'm asking, was there a specific reason to not use mDNS?
Airprint, airscan, filedrop and other things are based on bonjour (mDNS-SD), and supported pretty well on consumer devices and routers. [1]
Earlier quoted context omitted.
But how do you distribute the certificates? It's cold-starting peer to peer distributed systems that's hard.
When you setup the robots you could load them with the PKI and then load each other robot joining with a signed certificate. Not ideal, I admit. Another way would be to somehow prove that you belong.
It's annoying that we don't have a decent solution to this even for home automation. You ought to be able to take a "house ID key", probably a Yubikey, and present it to all your devices to tell them "you're mine now". Then they can talk to each other.
There are military cryptosystems which have such hardware. There's a handheld device called the Simple Key Loader.[1] That's what's used to load secure voice keys into radios, encrypted GPS keys into GPS units, identify-friend-foe codes into aircraft, and such. It's 15 years old, runs Windows CE, has a screen with a pen, and is far too big. The Tactical Key Loader is smaller and simpler.[2] 7 buttons and a small screen. About the same size as a Flipper Zero, but ruggedized and expensive.
[1] https://info.publicintelligence.net/SKLInstructionGuide.pdf
[2] https://www.l3harris.com/all-capabilities/kik-11-tactical-ke...
batman-advanced is a pretty interesting choice for a routing / handshake mechanism. Are your own applications mostly focussed on 802.11s Wi-Fi or where does the choice come from? In Profinet / Ethernet based networks it's more common to use ARP or mDNS for the discovery because multicast addresses are supported everywhere. Multicast DNS would be independent on top of the existing network layer and compatible with sma…
You are right that mDNS is a popular choice, and we even have it in our codebase to be able to debug on macOS.
However, mDNS is a flooding/multicast protocol, and although batman-adv optimizes those, it puts unnecessary strain on a mesh network. That’s why we didn't go with it.
It also gave us the opportunity to try out this other, in our view, more elegant approach to discovery.
Since IBSS is not really useful outside of Linux popular device support, like smartphones, it fell out of the picture pretty quickly (sadly). However, you can connect bridges to our mesh network (again exposing a batman-adv feature), which would give you the ability to connect phones (and of course, printers) to your robots.
[1]: http://grafana.freifunk-muensterland.de/goto/lAqihJDHg?orgId...
> We’d love to hear your thoughts! :) Have you ever played any of the Horizon (Zero Dawn/Forbidden West) games? :) Jokes aside, it looks pretty cool. What kind of hardware have you tested it with so far? Is this using WiFi only?
Currently, our software stack only supports WiFi and Ethernet at the data link layer, but that’s mainly because these are easy to set up with linux/batman, not because of an architectural problem.
Other technologies are not only possible but also on our roadmap. Just recently, for example, I’ve been taking a first look into getting LoRa working with hyveOS, but this would probably be a more long-term project.
How does this compare with Zenoh [1]?
Also, I'm curious why you all included "OS" in the name? Almost every introduction to ROS/ROS2 has to explain that it isn't actually an operating system, and it seems like the name hyveOS will have the same misunderstanding.
[1]: https://zenoh.io/
Great idea combining batman with libp2p! You guys have the heart in the right place :-). Currently, your project seems to be an opinionated wrapper ontop of libp2p. For this to become a proper distributed toolkit you lack an abstraction to for apps to collaborate over shared state (incl. convergence after partition). Come up with a good abstraction for that, and make it work p2p (e.g. delta state based CRDTs, or op-b…
You are right. At the moment, we are an opinionated wrapper, but we take a different approach to discovery than other libp2p-based networks with our custom batman-adv-based neighbor discovery. Abstractions for collaboration are currently in the works, and we hope to release that soon. The work on consensus has already started. Your suggestions seem all very interesting, and we'll definitely consider them. We are also…
They (we?) unfortunately never found product-market-fit. Actyx targeted the SME factory space with a p2p application platform. Turns out that developers in general don’t want to deal with the additional complexities of anything lesser than strong consistency, especially if they don’t fully drank the distribute-everything kool-aid. And SMEs don’t really bother either.
Philosophically decentralization is the right thing to do, but I’m thinking more and more that federation might actually be the compromise in the long run, at least for consumer apps. The only valid use cases for p2p edge devices with loose connectivity are in military applications.
Earlier quoted context omitted.
Might consider good old x509 certificates, mTLS authentication. You can query and find peers but don’t exchange any data with them unless they can present a certificate signed by whatever issuer. Agree its probably an enterprise upsell because the openssl tooling is a PITA if you’ve never done it before, but somebody pointed me to KeyStore Explorer [0] and I’m going to give that a try to be my own certificate authori…
That's actually a pretty great idea! I will look into it! Thanks!