Decentralised Bootstrapping

Technical Discussion
#1

Was just wondering how Holochains could be / are bootstrapped without servers over the public internet.

For bootstrapping, are you intending to provide a simple DNA (probably packaged with Holochain) that creates a global DHT storing a mapping of DNA hashes to IP addresses (of nodes running each DNA)?

Someone could download this DNA and a collection of static IPs with the DNA, or just get the DNA, run it, and get an initial set of IPs over a LAN from someone else using Holochain (and the DNA)?

Seems it would be nice to have an “install over LAN” feature, to encourage bootstrapping without public web servers?

1 Like
Still Intended to be Decentralised/Unenclosable?
#2

I could be wrong but I think once the networking is finished all you would need is the DNA and this would be able to find all the other nodes with the same DNA. You would not need any IPs.

#3

Without going lower down in the stack and replacing TCP/IP I’m not sure how that would be possible? (over LAN there are possibilities but i’m referring to public internet).

I was imagining:

Bootstrap servers (temporary) -> Bootstrap DNA -> DNA

Then (once Bootstrap DNA and number of users is large enough):

LAN / Bluetooth -> Bootstrap DNA -> DNA

Which still requires physical proximity to a peer for bootstrapping (“bootstrapping the bootstrapping” ), but eliminates the public servers.

The Bootstrap DNA and a large set of static IPs could be packaged and communicated through any carrier.

This also means you don’t have to independently/individually bootstrap each DNA, though you could (of course) or may want to, in which case you would not publish the hash of the DNA in the bootstrap DNA.

I was just wondering if there was a design or plan already in motion for something above? Does it make sense?

#4

In the world of TCP/IP “Bootstrap servers (temporary)” (above) to bootstrap a “Bootstrap DNA”, would obviously still require/use static IPs (directly or indirectly via DNS)…

From the perspective of having a scalable “unenclosable carrier”, this is a slight issue as the public bootstrap nodes can be ‘enclosed’.

To circumvent this I’m imagining something along the lines of a Holochain binary being packaged with a bootstrap DNA with large set of static IPs (dynamic won’t work as DNA lease is probably < 24 hrs), that can be shared over any another carrier, including/especially LAN or Bluetooth… so a peer can bootstrap another peer without public servers which depends on DNS, and a bunch of other things.

So, over LAN or Bluetooth, for example, I would be providing my friend with the Holochain binary (so they don’t need to download it), a bootstrap DNA with a mapping of public DNA (hashes) to IPs, and then once they set it up, then, over Bluetooth or LAN (or whatever), their node would gossip with mine and they would receive the latest IPs and DNA hashes… and be able to access directly the peer networks by their IP address…

This is all of course in the context of using TCP/IP still…

Ultimately it would be nice to replace the whole TCP/IP (internet) networking stack and have the DNA hash be the equivalent of an IP address, and somehow route the packets based on that, as though it was an IP address.

#5

Holochain binary + bootstrap DNA + static IPs (of some nodes hosting the bootstrap DNA/DHT) could be distributed in public places… and doesn’t require proximal communication with a peer over LAN/Bluetooth to bootstrap. — could just be a read-only USB stick glued into a wall, (haha).

Holochain binary + bootstrap DNA without static IPs, does require proximal communication with a peer over LAN/Bluetooth (to get the IPs of nodes) to bootstrap.

Also you could have nodes running on Holoports or Raspberry PIs in cafes. So anyone could install Holochain over LAN without public web-servers.

#6

as you guess @larky we aren’t able to make the bootstrap problem go away if we’re running on top of TCP/IP. Apparently we’re toying around with a ‘discovery DHT’ which does what you describe — not sure if it would be a DHT powered by its own hApp or if it would be more low-level than that. One design problem we’ll have to get right is not leaking information about who is currently participating in what DHT!

Bootstrapping is a hard thing to get right! And ‘right’ probably has a different meaning for each application. Some would be okay with ‘bootstrap nodes’ even though they’re centralisation singletons and vulnerable to corruption/DDoSing/enclosure.

Some would be better served by the HC installer sneakernet you describe later. An interesting consequence of this sneakernet is that you could actually build your network using this sneakernet installer, and avoid not just DNS singletons but singletons of any sort! But friends with USB/bluetooth/LAN is a very slow propagation medium :slight_smile: oh, I see you suggested that in a later post :+1:

Secure Scuttlebutt takes both of those approaches: their ‘pubs’ are popular bootstrap nodes, some of them resolveable by DNS. They’re just peers that happen to follow (replicate) anyone who follows them. You can also discover peers via sneakernet/LAN/etc. And they’re even toying with the idea of a discovery DHT.

Design solutions tend to converge into patterns if they’re any good… the fact that you’re echoing what SSB and Holochain are already exploring is, hopefully, a validation.

#7

Thank you that’s great. :+1:

not sure if it would be a DHT powered by its own hApp or if it would be more low-level than that.

Probably lower-level would be better, I imagine, especially so that it would be possible to delete old entries in the DHT (expired IPs).

One design problem we’ll have to get right is not leaking information about who is currently participating in what DHT!

Yes indeed, aside from agent IDs, IP addresses are loosely coupled with identity and also geolocation (in the case of Google, and whoever has access to their elite data-set, much more strongly coupled).

IP addresses could be encrypted (in the discovery/bootstrap DHT), assuming a public-private key-pair per DNA is distributed through a secure channel with the DNA hash.

There could be a more public DNA for that, which relates to “application distribution”; DNA hash’s, DNAs themselves (base64 blob of entire dna.json file), keys, etc., could also be distributed through Holochain’s agent-to-agent messaging… (encrypted with agent public keys).

:slightly_smiling_face:

#8

Good point. That could be scary business indeed. And even MaxMind’s GeoIP database is free for the querying, so it’s not such an elite thing as all that!

Hm, there’s a possibility, although there are also risks of snooping DHT membership by public key, not just IP address. Would require some design to prevent public keys being associated with real humans somehow. To an extent DPKI makes this easy by allowing a user to generate a new keypair for each app instance they run.

There’s also a chicken-and-egg problem: we don’t know who to ask for the decryption keypair, because we don’t know the addresses of any of the existing agents (they’re all encrypted). And if there is a way of securely/privately getting that keypair, you’re not really part of that network until after your peers in that network have approved your agent ID entry. So you shouldn’t really be allowed to find out who belongs to the network. But once you get that decryption keypair, you’re able to find out that information.

I think in most cases you’d want this sort of thing handled by public ‘bootstrap nodes’ who don’t mind having a bit of their identity revealed. This obviates the need to do the encryption thing too.

Well! Funny you should say that… https://github.com/holochain/HCHC-rust This is a funny-named repo because it contains TypeScript code, not Rust :smiley: I do know they’ve de-prioritised it for the first couple waves of Holo Host alpha.