amitu

So you can write SQL queries[1] in fastn documents, create dynamic urls[2], get request data[3], or write backend in wasm[4].

The input to sql queries are passed using bind parameters[5], so it should not have SQL injection issue.

FifthTry.com is built using fastn. You can checkout source code if lets-update[6] to see some open source fastn code.

[1] https://fastn.com/sql/

[2] https://fastn.com/dynamic-urls/

[3] https://fastn.com/request-data/

[4] https://fastn.com/wasm/

[5] https://github.com/fastn-stack/fastn/blob/b639cdf59dd297f977...

[6] https://github.com/fifthtry-community/lets-update

Completely agree, unfortunately the cool stuff is done by iroh team, so right now you can browse their docs: https://www.iroh.computer/blog/iroh-dns.

We are using iroh, so you can start with https://www.iroh.computer/blog/iroh-dns, and checkout their docs to understand how iroh itself works.

The malai stuff is relative not very interesting (we write some HTTP/TCP services/proxies that forward their calls over iroh connection, and write the other side to bridge back to HTTP/tcp). Code should help, or come to our discord: https://malai.sh/discord/ (currently it will say fastn, we are in the process of changing it to FifthTry server or something, we do not want to maintain multiple discord servers, and thinking of putting all FifthTry open source stuff on a single discord server).

We are built on top of https://www.iroh.computer/blog/iroh-dns, and iroh uses the public key as the node identifier. Unfortunately the iroh id is 64 char long, which can not be used in subdomains, subdomains have a char limit of 63, so we are using dnssec base32[1], which comes to 52 chars, and we use that 52 char string as the primary identifier (instead of IP:port, which is used the "old school net" (tongue firmly in cheek), and we call it id52.

https://datatracker.ietf.org/doc/rfc5155/

It's open source. Or not depending on any company[1]. The overall malai/kulfi project is quite different than these projects, malai itself can be compared with these two maybe.

[1]: we are built on top of https://www.iroh.computer so their caveats apply, and while we do run a http-over-kulfi over http-over-tcp bridge, you do not have to use it, you can run your own, and soon when kulfi browser is ready, you will not need the bridge. Checkout this work in progress kulfi browser: https://www.youtube.com/watch?v=qw_GmbtxCHw

You are on the right track, this is bastion like setup, but without needing another ssh host. This is one layer on top of SSH, so all SSH security applies for ssh over kulfi, but you get extra benefits like not having to expose SSH port to public, or not having guessable identifier (the IP address).

Looks like you got sucked into the fastn world. It's an open source full stack web development programming language we have created: fastn.com. We are building some fastn powered full stack, reusable apps, that you can plug in any fastn powered website at https://github.com/fifthtry-community.

The website, kulfi.app and malai.sh, and fastn.com itself, and FifthTry.com as well are all built using fastn.

Since its built in Rust, we can call it rus(t)-malai also :-)

So let's see, I am Amit Upadhyay, I am the (solo) founder and CEO of FifthTry, which is YC W21 company (we also have some other seed investment). We started with a documentation tool, the Notion like you mentioned, caveat: it was not WYSWYG, it was always based on a "language". The language was initially called ftd (FifthTry Document), and eventually fastn.com. fastn started as markdown++, but became a full stack web development language. We moved from being just a documentation tool to general purpose website building tool. FifthTry.com is now a hosting solution for fastn powered websites and webapps.

fastn is done in Rust, and has relatively small foot print. It is language, compiler, package manager, web server, wasm runner, all in one, and technically can run on say a mobile device, on a "Amazon Fire Stick" like mini TV module, you webcam and so on. fastn is probably the only web server you can run on those devices (not yet tested, but it should be).

The issue is those web servers do not have public IPs (nor should they, as that can expose them to security risks), so we are building a peer to peer network, an identity based network, so you do not have to have accessible IP/port to access the web service.

The network we are calling Kulfi net, and malai is a network toolkit for kulfi net, it exposes various services (TCP/HTTP) over kulfi net.

Kulfi itself is going to be a browser, that can talk kulfi protocol natively (as currently we need a "http bridge", eg kulfi.site that we are running, or you can install malai and run on your server).

Kulfi "browser", will also come with fastn built in, so you can run a web server on your phone and someone else can access that web server from another phone, talking http over kulfi protocol, and we can get near ideal networking solution (no intermediary, no need for public IP, etc).

Does this make sense?

Yes, we are currently using iroh provided relay servers. malai will soon connect with any relay server, so in future you can use ones provided by us, or run your own.

fastn is an ingredient to kulfi project. fastn.com is a full stack programming language we (FifthTry, Inc, the company behind these) have built, and it is the web server that is going to be part of Kulfi app.

The comparison posts, TODO, copyright etc we will do/fix when we get around to it. It's all open source, you can send PRs as well.

We are using iroh[1] internally, so the question is does iroh support these things? The quickest way to answer this would be to test it. Can you help me with what kind of setup would be needed for me to test this?

[1] https://www.iroh.computer

Kulfi is the official name of the project, and the name of the "peer to peer internet" "id52/identity based internet", so kulfi net.

Kulfi App is going to be a browser like Google Chrome, available on various app stores, and it will speak both http over tcp and http over kulfi. Kulfi app acts like client (but is also a server, so on your iPhone tomorrow you can install Kulfi, which will let you access any http over kulfi site, and also will run a web server which is exposed over kulfi net for others to access, so my Android phone's Kulfi browser can connect with the your iPhones Kulfi's web server, with no intermediary [1]).

malai is ready now, and it is a Swiss army knife toolkit for working with kulfi net. Currently malai can expose a HTTP or TCP service over kulfi net.

Malai also has a "http bridge" feature, which bridges any malai exposed http over kulfi service with the http over tcp, so people can use regular browsers to access malai exposed HTTP services.

[1]: we are using https://www.iroh.computer/blog/iroh-dns, so their caveats apply.

malai: cream that forms on top of milk when it cools down, its a flavor of kulfi. kulfi: a milk based ice cream / desert. Nothing to do with networking etc, just a desert I enjoyed since childhood :-)

Kulfi is a network (peer to peer) which support http/https even tcp can be sent over kulfi.

Kulfi App is a web browser that talks kulfi protocol natively, so you can open kulfi://<id52> natively. malai is the server side part of this story, and can expose existing HTTP/TCP services over kulfi:// network.

For DNS, here is my initial deign/thought: https://github.com/kulfi-project/kulfi/discussions/55

For access control, we are working on a "what-to-do" service, which is an bunch HTTP/JSON APIs, that will be called by the malai (which runs on your server, or even as part of Django/Node/Golang once we wrap malai as a cffi library, and write corresponding Python/Node etc packages). You will be able to write the what-to-do in any framework you like, and we will maintain a general purpose open source what-to-do service.

Unlike tailscale/ngrok, malai is completely open source, does not rely on any company provided infrastructure (we have a http bridge to bridge http/tcp with http/kulfi at *.kulfi.site, but you can run your own http bridge), and once Kulfi app is ready, you will not need the bridge at all and Kulfi app (which is also basically a browser that speaks http(s) over kulfi along with http(s) over tcp) can talk kulfi protocol directly.

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.

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.

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

We are building fastn[1], a programming language for authoring web content. This language is optimised for non developers, and can be easily learned by content team, marketing team etc. We have a case study of how we envisage it being used[2], you can see source code and pull requests for a fastn powered website[3].

[1] https://fastn.com [2]: https://fastn.com/acme/ [3]: https://github.com/fastn-community/acme-inc

This is not fair summary of the situation. Panics can be “caught”, most Rust web framework will catch panic when handling a http request and return 500, leaving other requests unaffected (more or less). This is almost no different from Python, Java, even Erlang.

Panic is a way for Rust library ecosystem to signal this error in un-recoverable, and is probably a bug in program, for which you would be happy getting Sentry or some such reporting.

Most errors in Rust are handled using mechanisms described in post using Result. Some, this is probably a bug in code, mechanism should be present in other languages.

There are even efforts to make code that can panic detectable at compile time, https://docs.rs/no-panic/latest/no_panic/

That is a Github issue. If you mark a repository on Github as template repository, they create this nice green button, "Use this template", which links to `<repo-url>/generate`, but this button is only visible to logged in users, and URL only works for logged in users.

This is very inconvenient for people who create template repositories. This becomes especially problematic, and makes me wonder what Github product managers are smoking really, that the big green "Use this template" only shows up on wide screen, if your browser is not wide enough the Github product team has decided to hide the most important button of the page.

Computation.

The key difference is that ftd is a single full stack language. You can make api calls, write custom functions, build components, use components etc etc.

A language designed for authoring. But still powerful enough (one day, it’s work in progress) that you can build most UI in it.

Yeah, docs are pretty lacking. The language is in very early stage and has gone through some changes rendering existing docs out of date. Jan we created a 0.3 version of our syntax after 2 years or so of development and we feel good about it and have started updating the docs now.

You can checkout a video course: https://ftd.dev/expander/. And maybe join us on our Discord.

One of the reasons we built https://ftd.dev is this. Check out this example: https://fifthtry.github.io/bling/chat/

Unlike what you did, here you can create new component in ftd itself, so there is no limit to how many such components you can create while authoring content.

Maybe you are tired of single quote block: https://fifthtry.github.io/bling/quote/

I normally have a very casual approach to commits, don’t spend too much time on commit messages, don’t try to fix the revision history, etc.

This is okay for a “commercial product”, which has focus on ship or die.

But for open source projects, with long software life, where you hope to collaborate with lot of outsiders, where you hope people get the reason of change, where things are more logical as they will not just jump on a zoom call with you, the quality of commits matter.

If quality of commits matter, how do we discuss commits? Do we first create the commit and then seek feedback and then revise the commits?

It is kind of hard with git. Git makes the commit history permanent and there are a lot of issues if you keep changing the commit using commit amend or rebase. Git kind of fights with you if you try to edit commits after the commits have been made and pushed to remote, after other collaborators have tried out those commits etc. If you modify stuff in your branch before pushing, everything is largely fine. But after collaborators have got the commit and you modify them, conflicts ensue and strong knowledge of git is required to ensure there is no loss of work. It takes a lot of time and care. Only experts should go there, or teams with strict adherence to agreed practices.

One option is to “evolve” the commits without git. Create local branch but do not push them, convert the branch to a patch set, a series of files, and share the pitch set via email etc, let people comment on the patch set, and you can modify your local branch and do rebase, rewrite commits, re order etc to your hearts desire. And only once this is done you do the actual commits, probably in one go directly on main branch.

This is roughly how Linux works. And git itself.

Unfortunately there is no good web based product for this, it relies on email, that too people who can write emails in terminal, can easily automate reading and sending mails via shell scripts, kind of everyone who is at this level of knowledge has such a custom setup that they just can’t share any reusable setup we can just standardise for your company.

Git evolve, as described in this article is trying to make this workflow part of git alone, so you can evolve your commits in shared branches, but these branches are not meant to be merged to master. These are special branches, every “logical commit” becomes its own branch, a patch set may contain n commits and for each commit there is now a branch, and each commit in one commits branch keeps track of corresponding parent commit in the parent commit branch.

It sounds kind of complex but it’s not too complex if you translate patch set model (any logical change is done using a series of diffs, each diff with a logical name and role).

Can’t wait to try it out.

Thanks vsareto for reporting the issue, we have made some improvements. Appreciate it.

The example shows when there is one body which contains markdown/Svelte. But I am talking about components that take more than one attributes. Say you want to model a person object. Person has many fields. You will have to write something like:

    <person>
       <name>markdown is okay here</name>
       <bio>markdown is okay here</bio>
    </person>

If you write:

    <person name="markdown difficult here" bio="markdown difficult here />

Also if you want to create a new component you have to jump to the Javascript world. And you have to learn CSS. Along with Markdown and the front matter (yml). Each with non trivial amount of learning curves.

FTD is being designed as a unified whole. All components of FTD are written in FTD. There is no boundary between "author" code and "components". A reasonable programmer can pick up FTD in an hr, check out the first video on https://ftd.dev. A non developer can pick it in a week, check out the other three videos.

Svelte etc are cool, but haven't you heard of huge number of backend developers who can't get into frontend? Current state of frontend is extremely complex. You can not tell me billions of people can learn Svelte thing when even backend developers are facing difficulties. To use mdsvex effectively you will have to write components. Which means the entire web pack, bundling etc etc. Do not pretend these are easy, anybody, even non programmers can do it.

FTD is being designed to be easy to teach. The audience of FTD is people at large, not developers (and yes they can learn some programming, Excel is used by 100s of millions). I do not believe you are saying Svelte is the super best and no such project as FTD must exist. I believe there is scope of improvement and we are working on it, help us improve.

MDX and Svelte in Markdown etc are definitely cool, but unfortunately they are not at all adequate for the job. You can not define a new component in MDX/MDSVEX, only use existing Svelte/React components in prose.

Further what about the arguments of those components, can they themselves contain markdown? How about markdown with React or Svelte component? Would you really with straight face say this is powerful:

    <Penguin text="Some text, which itself contains <Another />" />