The usual problems with these things are discovery and security. Discovery is done via local WiFi broadcast. Not clear how security is done. How do you allow ad-hoc networking yet disallow hostile actors from connecting?
Show HN: Decentralized robots (and things) orchestration system
21–30 of 40 posts
Re: Show HN: Decentralized robots (and things) orchestration system
#22Read the architecture document here.[1] The usual problems with these things are discovery and security. Discovery is done via local WiFi broadcast. Not clear how security is done. How do you allow ad-hoc networking yet disallow hostile actors from connecting? [1] https://docs.p2p.industries/concepts/architecture/
Security is still a big issue. In the current state, there is no security other than application-layer encryption (QUIC & TLS v1.3). That is fine for pilot projects, but it should not be used for anything sensitive. Maybe we should point this out more clearly in the docs. However, some Wi-Fi chips (not the ones on Raspberry Pi, sadly) also allow setting a password in adhoc (IBSS) mode and 802.11s has native support for encryption. In general is here a problem with lack of adoption of standards by the WiFi chip manufacturers and with Broadcom (the chip on the RP) a lack of support in the Linux kernel driver.
We are planning to implement authentication and encryption in the upcoming release, but this might be a paid feature.
Typically, enterprise networks are encrypted via 802.11x (since a leak of the key wouldn't compromise the whole network), and we might be able to build a decentralised Radius server, but I'm not very fond of that idea.
Ideally, the damage one can do by joining the network unauthorized should be very limited anyway, and authentication and encryption should happen on Layer 5.
Would love feedback / inspiration / suggestions
Re: Show HN: Decentralized robots (and things) orchestration system
#23this is so cool, congrats on launching. what kind of biz model are you guys going after?
We will most likely go with an open-core model. The main part will stay open source (the Core OS extension is under GPL3, and everything SDK-related is MIT). For paid features, we have several ideas: a hosted management plane to configure and control the swarm (with company rbac integration) when one of the nodes is connected to the internet; advanced security (currently no access management or authentication is happ…
I love the general ideas around free and powerful p2p functionality with hosted management or higher level features.
Re: Show HN: Decentralized robots (and things) orchestration system
#24Read the architecture document here.[1] The usual problems with these things are discovery and security. Discovery is done via local WiFi broadcast. Not clear how security is done. How do you allow ad-hoc networking yet disallow hostile actors from connecting? [1] https://docs.p2p.industries/concepts/architecture/
We do discovery via the mesh, yes, but instead of broadcasting (like mDNS), we query batman-adv for the current visible neighbors. If a new neighbor is discovered, we will contact them directly (via WiFi) to exchange the addresses in the P2P network and then dial them. From that, we populate the local Kademlia routing table with the content of the neighbor. Security is still a big issue. In the current state, there i…
I wish it could be a more mainstream, hobbyist auth solution tho, it’s completely free and open and self sovereign etc etc and makes strong security guarantees, just a steep learning curve to grok what’s happening. I think it would be a big achievement if somebody slapped a friendly API / wizard over configuring a CA and creating certs to install on each of your robots / IoT sensors whathaveyou. Corsha [1] is one provider in this space, and Yubico is contributing too [2], allowing you to sign cert requests with your Yubikey.
[0] https://keystore-explorer.org/features.html
[2] https://www.yubico.com/resources/glossary/what-is-certificat...
Re: Show HN: Decentralized robots (and things) orchestration system
#25One question I have is how quickly can discovery and switching take place. For instance, if I have a robot enter a lift. Can the lift detect the robots entrance and trigger its behaviours?
Re: Show HN: Decentralized robots (and things) orchestration system
#26Re: Show HN: Decentralized robots (and things) orchestration system
#27Read the architecture document here.[1] The usual problems with these things are discovery and security. Discovery is done via local WiFi broadcast. Not clear how security is done. How do you allow ad-hoc networking yet disallow hostile actors from connecting? [1] https://docs.p2p.industries/concepts/architecture/
We do discovery via the mesh, yes, but instead of broadcasting (like mDNS), we query batman-adv for the current visible neighbors. If a new neighbor is discovered, we will contact them directly (via WiFi) to exchange the addresses in the P2P network and then dial them. From that, we populate the local Kademlia routing table with the content of the neighbor. Security is still a big issue. In the current state, there i…
Re: Show HN: Decentralized robots (and things) orchestration system
#28Earlier quoted context omitted.
We do discovery via the mesh, yes, but instead of broadcasting (like mDNS), we query batman-adv for the current visible neighbors. If a new neighbor is discovered, we will contact them directly (via WiFi) to exchange the addresses in the P2P network and then dial them. From that, we populate the local Kademlia routing table with the content of the neighbor. Security is still a big issue. In the current state, there i…
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…
Re: Show HN: Decentralized robots (and things) orchestration system
#29Earlier quoted context omitted.
We do discovery via the mesh, yes, but instead of broadcasting (like mDNS), we query batman-adv for the current visible neighbors. If a new neighbor is discovered, we will contact them directly (via WiFi) to exchange the addresses in the P2P network and then dial them. From that, we populate the local Kademlia routing table with the content of the neighbor. Security is still a big issue. In the current state, there i…
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?
Re: Show HN: Decentralized robots (and things) orchestration system
#30This looks super cool, Ive been working in a similar space for some time. I work with open-rmf which is semi-decentralized and provides tools for task and traffic deconfliction (we don't handle the network layer at all). Excited to see more similar software coming up. One question I have is how quickly can discovery and switching take place. For instance, if I have a robot enter a lift. Can the lift detect the robots…