https://icy.leaflet.pub/atom

For the entirety of my life up until a year ago, I put myself in a box. A metaphorical box, categorized by my skills, interests and epistemic scope. This was entirely self-imposed, but I suppose clinging onto identity is only human. Let’s call this the “programmer box”. The term is somewhat lossy but it serves the purpose here. The content I consumed, the people I interacted with, the culture that I found myself steeped in.

The programmer box is tight. It’s well-bounded and there are clear membership criterea. You write code, you’re good at it, and there are legible, well-defined steps to get better at it. Understanding, nay, grokking computer systems and building an intuition for it is a tractable process.

Strongbox and Jewel Casket, Rijksmuseum

When we began Tangled, I firmly held my position within the programmer box. For many months we just wrote code and architected parts of the larger system. And then the more … unbounded stuff began to creep in. I was now responsible for figuring out (at varying levels of depth) accounting and finance, Finnish corporate law, talking to investors, and so much more. I was now a “founder”, and the anchors of knowing what I know, knowing what I don’t and knowing how to get better were all simultaneously lifted.

The founder box is loose. The membership criterea doesn’t really exist, and unlike the programmer (or any vertical for that matter) identity which is earned (to some extent anyway), being a founder feels a lot more provisional, self-declared. There’s culture but everything else is uncharted.

Weaver's Workshop, Rijksmuseum

Consider companies of the 19th and early 20th centuries. Founding a business back then was largely an extension of knowing a thing: your trade. You were perhaps a blacksmith, a mill operator, or sold a good. Most knowledge was inherited vertically, i.e. passed down through apprenticeship or family. The systems around you were slow moving enough that the peripheral knowledge likely wasn’t all that much.

Founders today are born into a more multi-faceted and interconnected system; the peripheral knowledge required is significantly more. The modern founder’s epistemic scope is exhaustingly large even to just reason about their companies. For example, a hiring decision is legal, financial, and cultural decision. And none of this is inherited—founders must construct a working model of this system as they navigate its nuances. Importantly, this system is irreducibly ambigious with no clear path toward mastery—unlike programming or whatever else.

I suspect that this expansion of epistemic scope from whatever prior boxes is responsible for the ever so visible “techbro hubris”. I kinda get it: you have to rapidly assemble fluency in a whole new set of domains that you previously had nothing to do with, and this assembly can sometimes feel like mastery. I know it did for me. Some of it is most certainly performative but it’s a function of the system—showcasing intellectual breadth gets you forward. The market selects for this hubris—VCs pattern-match on this behavior as it reads as conviction and vision (and they subseqently mirror this behavior).

I know that there’s no going back now—the founder box is as exhilarating as it is indeterminate. The edges are gone, and I’ve stopped looking for them.

Also published at: https://anirudh.fi/future

We set out to build Tangled for one simple reason: the existing options just… suck. Some more, some less—but they all do in their own ways.

• GitHub? Where do we even begin…

• GitLab? Way too enterprise-y, and definitely not easy to self-host.

• Sourcehut? So opinionated it alienates about 98% of potential contributors. Pretty great if you really love email, I guess.

• Forgejo/Gitea? Nice, sure. You can self-host—but without a shared identity, I still need to create an account on your instance just to send a PR.

• Radicle? Honestly, it’s amazing. Purely technically, Radicle is far ahead of anything else, Tangled included. But the world—at present—just isn’t ready for full-on P2P.

However, I realize these are good enough for a lot of people—and that's fine! After all, Tangled is a forge that we (Akshay and I) wanted to see exist. We're building Tangled modelled after our version of an ideal code forge—one that we foresee existing well into the future.[0] Below, I'll try to outline the ideals that shaped Tangled and our justifications for them.

A good exercise to perform whenever the decentralization word is used is to define what exactly you mean by it in this context. In Tangled's case, we wanted:

• user's to own their data: both the git repositories, and the surrounding social data like issues, pulls, etc. …

• … without compromising on features and UX that they've grown to expect from similar centralized platforms …

• all while sharing a central identity—i.e., I shoudn't have to create an account on your self-hosted "instance" to send a patch, open an issue, etc.

Having laid all of this out, it became exceedingly obvious that the AT Protocol would be a perfect fit. Mind, a lot of the following assumes a cursory understanding of AT; I'd recommend giving the AT docs a skim if you're new here! Anywho:

• Users can own their data? Yep, issues, pulls, follows, stars, etc. etc. all live as sh.tangled.* records in their Personal Data Servers. Check (minus the git repos, but we'll get to that).

• Global discovery of said data (over relays) allows for "no missed replies", consequently letting us build a centralized-esque experience. So, no compromise on UX? Check.

• AT's use of Decentralized Identities (DIDs) lets users share the same identity globally. Contrast this to ActivityPub where your account is tied to your instance (@foo@instance.com). Central identity? Also check.

Now for the bit about git repos. Naturally, we want users to be able to host them on their own servers as they would Forgejo/similar. To address this, we designed "knots". Knots are lightweight, headless servers that deal with git repository operations and associated role-based access control (granting push access, for example). Knots are designed for easy self-hosting.

And how do knots fit into the AT architecture of appviews/relays/PDS…?

It helps to realise that AT is really just a hyper-composable distributed system. Appviews are just indexers[1] over a set of records that they care about. In this case, knots index records for SSH public keys, repo collaborators, pulls, and more. In the traditional sense of an "appview", knots I suppose, would be an extension of Tangled's appview.[2]

Lastly, AT enables us to build an object-capability model thanks to globally unique DIDs and PDS-based auth. There's a lot to unpack here, but I'll save the details for a future post.

With that overly wordy AT evangelism out of the way, let's talk about the tech stack that all this is built on. I mean, it's simple (as it should be). 

Go is the language of choice, for everything. Extremely easy to write and maintain, strong concurrency primitives and very solid stdlib. We stick to using libraries that don't deviate from standard interfaces—like go-chi + net/http instead of echo or fiber. Go is an internet programming language:

I consider Go not to be a systems programming language — a title much better earned by languages like C and Rust. Rather, Go is the best-in-class for a new breed of software: an Internet programming language.

The wealth of network protocols implemented efficiently, concisely, and correctly in its standard library, combined with its clever mixed cooperative/pre-emptive multitasking model, make it very easy to write scalable internet-facing software.

Go is very easy to cross-compile, supports a large variety of platforms and promises backward compatibility, indefinitely. These are all very strong signals for a language to build software that'll last well into the future, and is easy to build & run by users.

As for the frontend, we chose htmx and Tailwind. htmx due to its sheer simplicity & speed; we will likely never build a first-party SPA in a JS framework du jour.[3] We strive our hardest to implement UI elements in plain HTML/CSS without reaching for JS.

Tailwind will likely be a controversial choice here and I'll admit: we did initially choose it for faster iteration on the UI. Regardless, I'm certain Tailwind is here to stay and I say so because conceptually, it is rather simple! If it does go away, I'm very positive we'll have a drop-in replacement rather quickly.

And finally, sqlite. We currently use this for all services: the appview, knots and spindles. sqlite fits perfectly given the deployment scenarios we're targeting for knots and spindles—it's just a file! I too am all-in on server-side sqlite (we use & recommend litestream for backups/replication). 

We have discussed a possible rewrite of the knotserver code base in Rust. I'm all for this, but the Go version of the knotserver will likely always be maintained. Once we graduate Tangled out of alpha, we plan to formally spec out knots and spindles so alternative implementations can be easily built.[4]

I say "probably" because it's unlikely that it may ever fully replace git. That said, I think the general trajectory that the industry is heading towards is some kind of patch-based contribution and review system. Today, writing code is the easy part—the real bottleneck lies in the collaboration primitives. Being able to review code efficiently, structure changes easily without having to faff about with git rebase -i are key. 

I also suspect that as coding agents continue to rise, we'll see a parallel rise in review agents (already plenty of early examples exist). Being able to quickly interdiff between two sets of changes will make these agents significantly more effective.

Fundamentally, though, Jujutsu remains the tool of choice here. Its growing popularity will likely drive this broader shift toward "stacked diffs" as the fundamental unit of contribution and review. As a platform, Tangled will be focused on innovating and refining these collaboration paradigms.

One of our core beliefs from the very beginning was that indie devs and open source communities are a critically underserved group on platforms like GitHub. 

A common misconception that people have is that their repository will somehow be more popular when hosted on GitHub; however, GitHub's repository discovery story is greatly oversold. Most, if not all popular repos gain traction due to being shared elsewhere! If you're an indie dev, your open source project will likely never be found "on platform", unless it's got a bunch of stars/forks for it to show up.[5] It's inherently a "rich-get-richer" model.

Further, GitHub is hyper-enterprise. Pricing, feature-gates, and the general product roadmap are driven by enterprise contracts. Individuals and community needs are a distant afterthought. 

These are issues that Tangled plans to address longterm. Tangled will be for the people, not enterprise. That's simply not going to be our focus. We've also got several ideas for how to solve on-platform discovery in ways that are fairer for everyone. Our approach to monetization will be centered on individuals and the community: reinforcing virtuous cycles of participation, with optional subscriptions enhancing the experience rather than restricting it.[6]

Finally, Tangled will always remain open source in its entirety. You will always have a say in shaping it.

There's a lot of work to be done yet, but we're giddy about what lies ahead. See you on the atmosphere!

[0]: I'm being intentionally vague here—a decade seems rather long, but simultaneously not long enough; who knows what code forges will look like with the likelihood of AGI being right around the corner?

[1]: By "indexer", I mean they subscribe to the relay for a set of records and act on them.

[2]: In fact, I'd even argue that there is no "appview". There are only AT indexers; but I'll leave that discussion for another day.

[3]: I'm not against SPAs, I just think the JS ecosystem has yet to figure out bitrot. It is simply not future-facing enough. Happy to support third-party implementations, however!

[4]: Might take a while, but don't let that stop you!

[5]: I realize that our current "Trending" section on the timeline is essentially the same thing; we will improve this!