Instead of #selfhosted servers it'd be nice if software was #CloudFree and #P2P
Not only should we not ve reliant kn centralized corporate hosting, we should be able to just use whatever devices we have on hand without extra server maintenance.
@mauve have you ever tried to write an application that works like this?
I can tell you from experience, it's practically impossible.
everyone is in ipv4 NAT jail
ipv6 when???
if your app doesn't have a URL, who's going to use it? ( network effect of established platforms )
I agree that this is how things should be! But its unclear to me how to get there. Or even where to start.
IMO we have to start with self-hosting, then move to community/group hosting, then try to use those trusted community-run publicly dial-able server constellations as a pseudo-standard for how to bootstrap more P2P oriented apps. But I think it still has to load in the web browser the whole time. Any sort of publishing use case will have to be compatible w/ unmodified browser.
But hey, with the new WebTransport API, that's going to get a lot less painful soon!!
@forestjohnson I've been making p2p apps for years and have done consulting for companies that made their own. :)
P2P in web browsers is defs a nono since the browsers security model and browser vendors won't allow it any time soon.
I defs don't mean to say that people shouldn't self host, it's just that that's not where we should stop.
More unmodified browsers these days are getting support for loading sites from IPFS for example.
For NAT stuff holepunch.to and socketsupply.co are good.
@mauve @forestjohnson Firefox doesn’t support it yet but they’ll accept the patch if someone writes it https://bugzilla.mozilla.org/show_bug.cgi?id=1806693
@em @forestjohnson Yeah webtransport is defs going to make it easier for browsers to connect to dhts and "native" networks. I worry that it still doesn't give us enough however.
It doesn't (yet?) give a way to host servers listening on incoming connections. It can't do UPNP and other negotiations with the router, and it can't do multicast UDP for local peer discovery.
Still a good step though!
@mauve @forestjohnson right, you’d need to relay webrtc signaling messages over those webtransport connections to support connections in to the browser
@em @forestjohnson Yeah! FWIW the libp2p ecosystem seems to be abstracting over all these details so apps can focus on "dialing" into peers based on public key, and it figures out the transport and relaying.
@mauve @forestjohnson the libp2p ecosystem is a mess with incorrect docs and half-working implementations
At least last time I was looking at this, the libp2p libraries worked OK for apps, just not for browsers / interoperability w/ browser stuff.
I think a large part of the problem is that what libp2p is trying to do is kinda impossible, the image that they "sell" where it "just works" with pure p2p and no server, is and always will be unrealistic. Because of the "original sin" of ipv4 and NAT, there will always be a need for a server / rendezvous point.
I still use the UPnP client from libp2p, I its really good IMO. https://git.sequentialread.com/forest/go-libp2p-nat
I think webrtc is the way to go for publishing cuz it supports browsers, I like the Pion webrtc libraries cuz I can fairly easily get server<->server, server<->browser, and browser<->browser, working, and it has a feature where you only have to open / forward one UDP port on the server so it makes it easier to host. WebTorrent is also pretty cool.
@forestjohnson @teal @em Big mood. The hyper-modularity and dynamic nature of libp2p and ipfs makes things hard. I generally stick ti reading source code when I want to know what's going on.
Regarding centralization, these days dht nodes can be used for rendevous and packet forwarding which is pretty handy. Would be cool if there was a webrtc enabled dht that could do stun and turn on any node with a stable ip.
P2P in web browsers is defs a nono since the browsers security model and browser vendors won’t allow it any time soon.
@mauve @forestjohnson actually that’s changing, webtransport with the serverCertificateHashes option makes connecting from a secure context to an ip address that doesn’t have a real https cert possible!