I strongly believe peer to peer is superior over centralized architectures that are commonplace today. If things are peer to peer, there is no central entity, then open source truly shines. If things are open source, but still deployed / controlled by some mega corporations, then open source kind of loses the freedom it promises to people.

If things are not peer to peer, then someone is footing the bill. If someone is doing that, either they will be exclusionary like Apple, very high cost, or they will be "predatory" like Google, appearing to be free, but really selling you to everyone with credit card, and mining your data, training AI, etc etc.

Peer to peer means freedom from this. It has always been possible, I have actively used peer to peer technologies for over 20 years, but it has be stymied by a "mistake" that I believe they made. The implementations of peer to peer products tied the "networking part", peer to peer networking is quite hard, unlike traditional BSD socket model of networking, peer to peer needs to solve hard problems like decentralized peer discovery, NAT hole punching etc - with the "application part".

WebRTC has been an interesting attempt to decouple "networking part" with the "application part". Now if your both ends are in browser, sure, you are in full control, little bit of JS and you can do arbitrary applications, and some pretty cool stuff has been done with it, like Video calls, today the world runs on WebRTC may not be an exaggeration.

But when it comes to anything else, browser tabs are not persistent, if you need something persistent, like sharing a folder, or connecting to a HTTP server, you can no do these with browser tabs, as they will suspended when they lose focus. So WebRTC, while being awesome, still leaves out a lot.

This is where kulfi and malai comes up. Malai lets you run stuff on server side. But that would itself would only have been half the story. Since the peer to peer technology allows you to use the super awesome computing device that billions of us are carrying around in our pockets, they can all talk to each other over peer to peer, malai alone would not helped.

Upcoming Kulfi: The following is not yet done, but this is the main thing we are working towards, which is why the network is named kulfi, and github repo etc are kulfi based.

Kulfi will allow you to run a web server on your mobile (or on your fire stick like TV controller, or that internet connected camera you have in your house, think any desktop/mobile/smart device/appliance). They all can run software, can connect to internet, and do awesome stuff, but can your run Django on it? Node? How will you create the user interface for TV or webcam or mobile (you can not pick Swift/Kotlin, as that limits you only to phone, we want something truly cross platform), in React? We do not have a solution for this.

So kulfi internally bundles fastn, which is a programming language we have built, with the goal of being a full stack programming language, that can do backend and full stack, and while currently we only support browser, the goal of fastn is to create a UI layer, that can run natively also, without needing browser. Because browsers are quite expensive, if every webcam, every fridge contains a browser running react code for UI it will be a nightmare, but fastn is trying to solve that.

Edited: fix a typo and clarify public vs key pair.

Unlike ngrok, and they are a great product, I have used them for years, we are completely open source. Further we are peer to peer, so if you and the other party both want to communicate, you can do it without any dependency on a third party/company.

The last bit requires some explanation, but this is provided by iroh, this is not our innovation, we have simply used iroh and benefitted from it, you can read about their node discover process here [1], there is some initial reliance on a relay, which is currently run by them, and we hope to run our own relays in future.

Right now the way it works is `malai http 3000` listens over iroh, and creates a public private key pair, public part of the key is used as node identity, which we call id52 (52 char public key, default iroh public key representation are 64 char and not suitable for using as a subdomain).

Then on kulfi.site server, `malai http-bridge` runs, which starts an HTTP server, and any request that comes for `<id52>.kulfi.site` lands on this HTTP server, which then connects to `malai http` instance over iroh network using the id52[2]:

`malai http` gets the HTTP request payload, and makes a HTTP request to the port 3000 (on localhost), and sends the request, and then the return is returned back all the way from malai http to malai http-bridge to the client who made the original request.

We are currently running an instance of the `malai http-bridge` on `kulfi.site`, and you can run your own if you do not trust us for example, go ahead, we encourage it, not for trust, but so it keeps our bandwidth bills down.

But you do not have to use the http bridge, you can run `malai browse kulfi://<id52>`, and it will start a local http-bridge (it will run single target node as for localhost you can not use subdomains to extract the id52 from, which is why you have to pass it on CLI). `malai browse` opens a HTTP server on some random port, and opens your default browser with it, and rest works the same.

If you are curious, kulfi is the main project, we are creating a tauri powered web browser, which will directly speak iroh, and will not require the http bridge, the http request from browser will straight go over iroh network to the other side.

[1]: https://www.iroh.computer/blog/iroh-global-node-discovery

[2]: https://www.iroh.computer/blog/iroh-dns

Wireguard is def comparable to iroh, so you are correct. We could have used Wireguard to build malai had malai been in Golang. iroh is wireguard for Rust (and slightly better because it is lot smaller / simpler to use as a library, with no special access, like Wireguard is almost full blown VPN, talks about IPs etc, a bit more than what iroh does, but both are awesome).

"privater Pinggy.io", yes :-)

We have not yet created access control stuff, it is in our roadmap, we are going to do not just HTTP, but TCP, ssh, folder sharing etc etc. And our access control stuff will span across all these use cases, like a unified / simplified access control so you can create interesting network stuff, without learning about complex firewall rules etc.

It is a hard problem because of the audience. Most networking tools are written for a very specific networking geek audience, we are trying to create a solution to be used by more general population.

Like who wants to share a folder? Not just networking geeks, or even just geeks, but virtually everyone using Dropbox/Google Drive. So why not create an open source peer to peer versions of these tools. Which is what we are trying to do.