anirudh.fi
my website at https://anirudh.fi
pages/blog: building for the future post
+161
+161
pages/blog/future.md
+161
pages/blog/future.md
···
1
+
---
2
+
atroot: true
3
+
template:
4
+
slug: future
5
+
title: Building for the future
6
+
subtitle: On Tangled's existence and direction
7
+
date: 2025-10-27
8
+
draft: false
9
+
---
10
+
11
+
**Also published at:** https://icy.leaflet.pub/3m47cll72hs25
12
+
13
+
We set out to build Tangled for one simple reason: the existing options
14
+
just... suck. Some more, some less -- but they all do in their own ways.
15
+
16
+
- GitHub? Where do we even begin…
17
+
- GitLab? Way too enterprise-y, and definitely not easy to self-host.
18
+
- Sourcehut? So opinionated it alienates about 98% of potential contributors. Pretty great if you really love email, I guess.
19
+
- 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.
20
+
- 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.
21
+
22
+
However, I realize these are *good enough* for a lot of people -- and
23
+
that's fine! After all, Tangled is a forge that we (Akshay and I) wanted
24
+
to see exist. We're building Tangled modelled after our version of an
25
+
*ideal* code forge -- one that we foresee existing well into the
26
+
future.[^0] Below, I'll try to outline the ideals that shaped Tangled
27
+
and our justifications for them.
28
+
29
+
## the future is decentralized
30
+
31
+
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:
32
+
33
+
- user's to own their data: both the git repositories, and the surrounding social data like issues, pulls, etc. ...
34
+
- ... without compromising on features and UX that they've grown to expect from similar centralized platforms ...
35
+
- 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.
36
+
37
+
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](https://atproto.com/) a skim if you're new here! Anywho:
38
+
39
+
- Users can own their data? Yep, issues, pulls, follows, stars, etc.
40
+
etc. all live as `sh.tangled.*` records in their Personal Data
41
+
Servers. Check (minus the git repos, but we'll get to that).
42
+
- Global discovery of said data (over relays) allows for "no missed
43
+
replies", consequently letting us build a centralized-esque
44
+
experience. So, no compromise on UX? Check.
45
+
- AT's use of Decentralized Identities (DIDs) lets users share the same
46
+
identity globally. Contrast this to ActivityPub where your account is
47
+
tied to your instance (@foo@instance.com). Central identity? Also
48
+
check.
49
+
50
+
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.
51
+
52
+
And how do knots fit into the AT architecture of appviews/relays/PDS…?
53
+
54
+
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]
55
+
56
+
Lastly, AT enables us to build an [object-capability model](https://en.wikipedia.org/wiki/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.
57
+
58
+
## a future-facing tech stack
59
+
60
+
With that overly wordy AT evangelism out of the way, let's talk about
61
+
the tech stack that all this is built on. I mean, it's simple (as it
62
+
should be).
63
+
64
+
Go is the language of choice, for everything. Extremely easy to write
65
+
and maintain, strong concurrency primitives and very solid stdlib. We
66
+
stick to using libraries that don't deviate from standard interfaces --
67
+
like go-chi + net/http instead of echo or fiber. Go is an internet
68
+
programming language:
69
+
70
+
> I consider Go not to be a systems programming language -- a title much
71
+
better earned by languages like C and Rust. Rather, Go is the
72
+
best-in-class for a new breed of software: an Internet programming
73
+
language.
74
+
75
+
> The wealth of network protocols implemented efficiently, concisely,
76
+
and correctly in its standard library, combined with its clever mixed
77
+
cooperative/pre-emptive multitasking model, make it very easy to write
78
+
scalable internet-facing software.
79
+
> -- from [Go is a great programming language](https://drewdevault.com/2021/04/02/Go-is-a-great-language.html)
80
+
81
+
Go is very easy to cross-compile, supports a large variety of platforms and [promises backward compatibility](https://go.dev/blog/compat), 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.
82
+
83
+
As for the frontend, we chose [htmx](https://htmx.org/) and [Tailwind](https://tailwindcss.com/). 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.
84
+
85
+
Tailwind will likely be a controversial choice here and I'll admit: we
86
+
did initially choose it for faster iteration on the UI. Regardless, I'm
87
+
certain Tailwind is here to stay and I say so because *conceptually*, it
88
+
is rather simple! If it does go away, I'm very positive we'll have a
89
+
drop-in replacement rather quickly.
90
+
91
+
And finally, sqlite. We currently use this for all services: the
92
+
appview, knots and spindles. sqlite fits perfectly given the deployment
93
+
scenarios we're targeting for knots and spindles -- it's just a file! I
94
+
too am [all-in on server-side
95
+
sqlite](https://fly.io/blog/all-in-on-sqlite-litestream/) (we use &
96
+
recommend litestream for backups/replication).
97
+
98
+
We have discussed a possible rewrite of the knotserver code base in
99
+
Rust. I'm all for this, but the Go version of the knotserver will likely
100
+
always be maintained. Once we graduate Tangled out of alpha, we plan to
101
+
formally spec out knots and spindles so alternative implementations can
102
+
be easily built.[^4]
103
+
104
+
## the future is (probably?) jujutsu
105
+
106
+
I say "probably" because it's unlikely that it may ever fully replace
107
+
git. That said, I think the general trajectory that the industry is
108
+
heading towards is some kind of patch-based contribution and review
109
+
system. Today, writing code is the easy part -- the real bottleneck lies
110
+
in the collaboration primitives. Being able to review code efficiently,
111
+
structure changes easily without having to faff about with `git rebase
112
+
-i` are key.
113
+
114
+
I also suspect that as coding agents continue to rise, we'll see a
115
+
parallel rise in review agents (already plenty of early examples exist).
116
+
Being able to quickly *interdiff* between two sets of changes will make
117
+
these agents significantly more effective.
118
+
119
+
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.
120
+
121
+
## the future is for the people
122
+
123
+
One of our core beliefs from the very beginning was that indie devs and
124
+
open source communities are a critically underserved group on platforms
125
+
like GitHub.
126
+
127
+
A common misconception that people have is that their repository will
128
+
somehow be more popular when hosted on GitHub; however, GitHub's
129
+
repository discovery story is greatly oversold. Most, if not all popular
130
+
repos gain traction due to being shared elsewhere! If you're an indie
131
+
dev, your open source project will likely never be found "on platform",
132
+
unless it's got a bunch of stars/forks for it to show up.[^5] It's
133
+
inherently a "rich-get-richer" model.
134
+
135
+
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.
136
+
137
+
These are issues that Tangled plans to address longterm. Tangled will be
138
+
for the people, not enterprise. That's simply not going to be our focus.
139
+
We've also got several ideas for how to solve on-platform discovery in
140
+
ways that are fairer for everyone. Our approach to monetization will be
141
+
centered on individuals and the community: reinforcing virtuous cycles
142
+
of participation, with optional subscriptions enhancing the experience
143
+
rather than restricting it.[^6]
144
+
145
+
Finally, Tangled will alwaysr^emain open source in its entirety. You will always have a say in shaping it.
146
+
147
+
There's a lot of work to be done yet, but we're giddy about what lies
148
+
ahead. See you on the atmosphere!
149
+
150
+
151
+
[^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?
152
+
153
+
[^1]: By "indexer", I mean they subscribe to the relay for a set of records and act on them.
154
+
155
+
[^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.
156
+
157
+
[^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!
158
+
159
+
[^4]: Might take a while, but don't let that stop you!
160
+
161
+
[^5]: I realize that our current "Trending" section on the timeline is essentially the same thing; we will improve this!