The libp2p Github repo contains a fantastic chat example, how to implement js-libp2p inside a web app and how to work with libp2p Go, Rust, Javascript and Python peers. There used to be a live demo which at the time of writing is available at that url: https://connect.nicokrause.com/
Then, in the beginning of this year, Storacha, an innovative decentralised startup, which I really liked, announced "sunsetting" the IPFS upload service. The result was the chat was no longer published on IPFS. All of a sudden even the Fleek hosting service which hosted the go-peer (libp2p chat relay) and the chat app's bundle became offline (shutting down the hosting services January 31st) at the same time.
I don't know how often this happens in the world, demos, services and websites aren't reachable anymore because of external economic, legal, accidental, hacking or even worse - military reasons as seen in AWS datacenter air strikes in Dubai, also in the beginning of this year.
A question was raised inside of me. If the chat app and the relays are supposed to be decentralised and both instances shutdown and nobody can do anything about it quickly, that is something which needs to be addressed. Big decentralised networks and blockchains might have a solution for that but p2p app developers and other startups suffer a lot.
At least, I needed a solution to fix that thing from ground up:
Why do we need a dedicated decentralised network for every single p2p web app? Isn't it anyway pure nonsense from a financial and administrative perspective?
Nostr suggests to use one decentralised network for all p2p apps. That might be a great option, but if Nostr nodes are blocked in a country all apps are unavailable too. This post is not at all about criticising Nostr, since they might have their solution for it.
But from my perspective each p2p app (e.g. the universal connectivity chat) should not be dependent on any hoster nor any specific public relay. If a relay was blocked or shutdown anytime another one with a new IP and new region should be immediately to be launched through decentralised compute networks.
I came across Aleph decentralised compute and Aleph IPFS hosting service and found a quite complete decentralised situation for my use case. To make things more complete, the work was about a new Svelte/ReactJS component and some Github Actions which simplify libp2p relay deployment: Shared-Aleph-Tooling shows the full potential of IPFS and decentralised compute in (local-first) peer-to-peer applications which are solely hosted on IPFS and don't run on any app server.
To my positive surprise it is possible with Aleph to just hold (not spend!) ALEPH token which then hosts the HTML bundle on their decentralised storage network available on IPFS. So even when startups or freelancers suddenly don't have the budget for their prototypes anymore, it needs only a one time investment for keeping a PWA bundle hosted 24/7/365.
In contrast the instance costs for VM deployment is charged in form of prepaid 'credits' which can be either bought in FIAT currency (credit card) or different crypto currencies.
What is that repo doing in detail?
https://github.com/NiKrause/shared-aleph-tooling (please be patient — still working on the docs)
Github Actions:
The "Sponsor Relay Button" - a ReactJS and Svelte component
The idea was: Whenever the universal connectivity chat app doesn't have a running relay, anybody could launch a relay for a couple of cents for the time the app is used and shut it down again afterwards, or sponsor a libp2p relay to run for others.
3. Aleph Bootstrap package
Since launching a libp2p relay somewhere on the internet does not necessarily lead to being known by the universal connectivity chat, I implemented the aleph-bootstrap package which is inspired by libp2p/bootstrap but doesn't work with hardcoded bootstrap peers.
Instead whenever a libp2p node is launched, its ipv4/ipv6/webrtc-directed /webtransport/websocket multi addresses get published and posted on the Aleph network, refreshed every couple of hours and cleaned up when the relay gets deleted. The same way the chat app imports the library and reads and filters the latest bootstrap nodes.
Remarks:
When launching relay rootfs images via Aleph you might notice that the relay gets two different websocket addresses: An auto-tls based secure websocket address on a port greater than 24000 and an Aleph based proxy address which has its own random hostname with its own certificate running on port 443. I implemented both because often high port numbers aren't available on VPNs such as NymVPN, and also some networks or mobile providers don't route such high port numbers. At the time of writing I couldn't find a way to use lower egress port numbers for the auto-tls service.