Is it still intended for Holochain to use a fully decentralised topology (e.g., “switchboards on every node” (if using this concept of proxies/switchboards) - which must use/involve automatic port forwarding as most devices are behind non-configurable routers (for non-tech users)), and is this still considered a major goal of the project?
The use of proxies seems on the surface tangential to the goal of realising an unenclosable carrier (as proxy nodes can be enclosed) and fully decentralised topology?
Are switchboards/proxies temporary or part of the long-term architecture?
Thank you
(any docs/articles available that answer this question?)
And by this i’m implying that it is not practical to ask everyone to manually configure their router to setup port forwarding.
Also this (manually configured port forwarding) is not possible on mobile cellular at all…
Note: WebRTC works incredibly well, even over cellular connections, it would be possible to use the same automatic port-forwarding technologies/protocols (minus the signalling, i’m only referring to the port-forwarding component)
What you’re talking about is the thorn in the side of almost every P2P project out there. We haven’t written anything about it, but we should — at the very least a FAQ. Here are the facts, for those who want to get up to speed on this subject:
Fully decentralised is still the ideal for Holochain; as you say, this is how we realise the promises of unencloseability.
The current state of tech (IPv4 + NAT) makes this really hard. Reliable NAT traversal for P2P is not hard, but FWIU all the solutions require some sort of central server to make initial introductions.
For now we have an interim DHT simulator, sim2h, that acts as a centralised switchboard. This is only meant for prototyping: gradually rolling out more bits of the ‘real’ lib3h networking stack, until there is no more sim2h left anymore.
Even if we solve the NAT problem, peer discovery is still an issue. For small intranet apps, it’s no problem (we can just use mDNS discovery), but for apps with a global reach we need some good quality, trustworthy way of finding peers.
You can see that it’s not a simple problem to solve .The entire architecture of the internet is against us in many ways. IMO the main threat to unenclosability is not the NAT issue and attendant centralisation points; it’s the discovery and boostrapping process. Once you get onto the network and get connected with enough trustworthy peers who are offering proxies, you can’t really be shut down. But getting to that spot… that’s the tricky part.
I imagine it will start with some sort of necessary evil like ‘bootstrap’ peers at static IPs run by application creators (or maybe the Holochain Foundation in some cases). But as the ecosystem grows, there will be more ways to onboard yourself into an app. The hard part then will be getting the UX right!
Thank you for this response, it’s very helpful and also reassuring.
“FWIU all the solutions require some sort of central server to make initial introductions.”
It requires an IP address of a peer node that can provide more IP addresses (of peer nodes).
The bootstrapping needs to be decentralised (and can be); as discussed in this post I created a few months ago:
I agree that the boostrapping is an issue in terms of avoiding centralisation and enclosability. I do think it can be solved with some of the things we discussed (in the above thread) or similar -
It’s also important to remember the embodied/‘real’ social-biological context; to ‘onboard’ a peer we could exchange a mass of static and dynamic IP addresses of bootstrapping nodes through ‘hyper-local’ means, such as USB sticks, Bluetooth, LAN, etc.
In such a case the more peers onboarded the stronger the bootstrapping is…
Static IPs only will not work as they can be targeted/enclosed. Dynamic IPs remain valid as long as a node remains connected (or only disconnects for approx <24 hrs), and it can then ‘hyper-locally’ bootstrap another node. This could also be done over other secure channels online (in which case it’s not ‘hyper-local’) which rely on current technologies (redundancy).
Also I still think gossip over Bluetooth and LAN is really important in general and should be prioritised to decrease our dependence on the internet until it can be fully re-engineered.
In terms of peer discovery, perhaps meeting physically in person at events/ in physical places is ultimately the best form of ‘peer discovery’ leading to the high quality connections… (and therefore apps/holochains, since they resonate with the energy of a peer/connection).
Secondary peer discovery can occur online in apps/holochains… - especially via introduction, i.e., “friend of friend”.
Right now we are working super hard to get the sim2h model working solidly so app developers can use it to start testing there ideas or maybe even deploying them in this model if there usecase is ok with the switchboard.
The next step will be lib3h. I’m pushing for a road map that will show this progression in a bit more clarity for app developers. Estimating software is always hard but I would like to be able to give you a clearer picture of how we are working through these problems.
I actually really like the ‘FOAF’ bootstrapping model — it seems to work really well for the Secure Scuttlebutt folks, whose userbase grows fairly organically based on IRL and online connections that lead to connections in SSB space (usually through ‘pubs’ that both parties have a reasonable amount of trust in). I suspect that for some applications (e.g., social networks that are looking for massive viral success) this won’t grow fast enough, but most of the applications that I’m interested in are local-first anyway, so that’s just fine
I think LAN promises the lowest friction in terms of onboarding, and would work really well for e.g., office teams who want local-first collaboration apps (I can’t tell you how many times I’ve had to stop work for a whole day because Slack and GitHub were down…) You get it for free with mDNS discovery, already integrated in HC’s networking lib I believe. I could see someone ushering in a list of static and dynamic peers that they trust via their membership in a ‘DHT of DHTs’ app.
Tell me more about your thinking re:
Sounds interesting and useful.
I still feel like initial bootstrapping — getting people onto the DHT of DHTs — will be tricky. On the one hand you’ve got centralised solutions like an official bootstrap node or a website published by the HC Foundation with a frequently updated list of static and dynamic peers, and that’s vulnerable to enclosure. And on the other hand you’ve got decentralised solutions like widely disseminated lists of peers… but then you’ve got the opportunity for malicious actors to seed those lists with their own peers so they can launch eclipse attacks. At some point I think it comes down to ‘who do you think you can trust’, although you’ve already expanded my perspective on opportunities for un-encloseability, so I’d love to hear more of your thoughts!
