Anirudh Oppiliappan () gives a talk at AHOY! European Social Web Day in Hamburg in 2025 about Tangled on ATprotocol.
So, a little bit about me: I’m Anirudh. I’m originally from Bangalore, India. I currently live in Helsinki, and my experience has largely been in distributed systems infrastructure, site reliability, and that whole adjacent space. I’ve worked at companies like DeepSource, Ori Corporation, and UpCloud most recently.
My brother — who was unfortunately unable to make it here because visas are real and they can hurt some of us — he does a lot of code intelligence, code search, and programming language-type stuff. I mean, he writes Rust. What do you expect? Yeah, he’s also worked at Y Combinator startups like DeepSource and Bloop AI. That’s our Bluesky and our websites.
So — yes, what are we here for? What’s Tangled?
So fundamentally, Tangled is a new Git hosting and collaboration platform. And the cool part is: all the social bits of code collaboration are on top of the AT protocol. So for example, the stars that you see — like repository stars, repository issues, pull requests, and the comments and discussions that ensue — are all on our own custom lexicon.
Importantly, the repositories themselves — like Git repositories — aren’t on the PDS. Instead, they’re on this cool little thing that we invented called “knots.” We’ll get into that in a bit.
So fundamentally, we chose AT Protocol because it lets us build — aside from the cool social apps you’ve seen thus far (and you’ll probably see more of) — it also lets us build these social-enabled apps wherein the social aspect is more of a consequence. In our case, a consequence of collaborating on code.
And it also lets us build this sort of globalized view and discovery. So for example, this is our core repository — we dogfood the entire thing. We use Tangled to build Tangled. We use pull requests. We got issues — a lot of them. And you can look at the whole codebase, etc., through this. So that’s neat, right?
Let’s get back to knots. What are they?
So fundamentally, knots are like these super tiny headless servers that you can just run on any little computer you have. It could be your home Raspberry Pi. It could just be a three-euro VPS that you get on Hetzner or something. All it does is host your Git repositories and serve them to the app view which we run. And it also facilitates forks and pull requests, etc. And they can be done across — so if you have a repository on one knot, you can fork it to another and then make pull requests, etc.
At its core, the idea is that knots are meant for friends and small communities — or people who want to collaborate on code.
A great example is the Rec Oilers run. So git.recoil.arg is a knot run by Anil Madhavi Bedi, who is a professor of planetary computing at Cambridge. He runs a knot for his colleagues and his PhD students — and they collaborate on code on there. It’s super comfy and fun.
But the cool thing is: if you’re not on that knot, you can still send them patches. So that’s great.
This is sort of like a simple view of what the network looks like. So for example, you’ve got two knots here — one from Bob and one from Alice — and they have their own repositories. But it’s all consolidated in this global app view that we run. And the fact that these repositories actually live on servers that are in completely different parts of the globe is a mere implementation detail. It does not matter.
So the contribution stuff is actually super interesting, I think. Let’s talk a bit about that.
At its core, our contribution model — we didn’t want to just copy GitHub or the standard branch-based pull request model. We wanted to go back and rethink how that full flow looks like — but at the same time, keep it familiar in a sense.
So we still follow a patch-based contribution flow — wherein you can optionally paste a git diff or a format-patch in the UI, or just do your standard compare branches or forks and then generate a diff.
But the neat thing about just pasting a diff or a format-patch in the UI is you can make these drive-by contributions very easily — because in your standard GitHub flow, where you have to fork a repository and then push a branch, it’s cumbersome if you just want to make a quick typo fix or something. So if you could just clone it, do a quick git diff, and paste that in the UI — you’re off to the races.
And then we also came up with this new review system — it’s essentially round-based, and you can interdev between rounds. Let me actually show you a demo before I go ahead.
So here’s a quick pull request — it summarizes the rounds in another part of the UI.
For example, this is my brother. He submitted — when you start, you start with round zero, and he submitted a patch. We can actually look at that — OK, simple enough, it just does some SQL stuff, blah blah blah — all right, it doesn’t matter.
And then I say, “Oh yeah, that looks great. But you know, you can make some changes — just use a pen, some ghost stuff.” And then he submits a second round — round one for review.
And the neat thing is you can see the whole patch that was submitted with the change. Or — here’s where it gets really fun — you can do an interactive view, which lets you see if your exact comments were addressed — because now this is the delta between round one and round zero that you see up here.
So this is nifty for reviewing — and this is something that GitHub doesn’t offer. If someone force-pushes or submits review commits to address changes, you can’t really see that interactively very easily — because GitHub pull requests are inherently mutable. But in our case, it’s completely immutable — so each round has its own state. And this is awesome.
So I could clearly see that he did, in fact, address my review about changing that append stuff, etc. Great. So that worked.
And then similarly, you just go through a couple more rounds of review — and then your pull request is ready for merge.
Under the hood, we actually use Git tooling — like git format-patch, git am, merging, etc. And a cool side effect of this is: you don’t have merge commits anymore. You don’t need that — because all merges happen on the latest date of the target branch, and they’re just simply fast-forward merged — or I guess rebase merged. So it works beautifully.
Ah — so what does the future of Tangled look like?
We have a lot of plans. It’s a really huge undertaking to build a new code collaboration platform — but we want to start with a couple of things.
One: we want to formalize the specification for knots — so someone can come in and rewrite a knot in Rust.
And we also want to formalize some sort of extension system for knots — so that you can self-hosted knots and then tweak and extend them as you see fit.
We also want to build out a full XRPC API — so that both the app view layer and the knots are fully AT Protocol-compliant — it’s sort of more atproto-esque.
And then, of course, our most requested feature is CI/CD. It’s hard — but we’re working on it. We have a couple of approaches we’re exploring.
One — the NIH syndrome that I suffer from really wants me to build something in-house — like Nick using Nix or something.
But we definitely want to get around to doing that. An interim solution might be to just offer webhooks — so you can integrate with CircleCI or what have you.
And then comes the really cool part we’re thinking of — knots getting their own little did web identity. That means it decouples the whole discovery setup from the app view — and knots can then simply self-announce on the firehose, and the app view will just pick it up. It becomes truly decentralized.
And in effect, the app view is also sort of desanctified — because right now you have to register with us using a pre-shared code. But what if you didn’t have to do that — and app views and knots were just coexisting? You could spin up a new one — and everything just magically works. And I think this is truly AT Protocol.
Of course, we also want to distance ourselves as much as possible from Bluesky infrastructure — because I strongly believe that unless you do that, it doesn’t truly prove the AT Protocol model works. So we want to host our own relay, host our own PDSs — so users don’t have to have a Bluesky account to collaborate on code. Right? Because not often is there a huge overlap — there is some, but not that much.
So we want to have our own PDSs — so users can sign up on Tangled without having to deal with a Bluesky account.
And yeah — a ton more. There’s so much more that we have to do. And at the bottom of that list is also OAuth — which we haven’t gotten around to yet. Primarily because the Go SDK doesn’t support it. But I don’t know — we’ll figure it out.
So yeah — that is Tangled. You know where to find us. That’s our Bluesky. We initially started with IRC only — and we got some… I think we realized that we were excluding users. So we now have a Discord. Do join — come hang. We talk about Git, AT Protocol, and everything in between.
There’s our emails — in case you want to reach Anirudh (that’s me) and Akshay (my brother).
And if you were curious as to why my slides were not as cool as everyone else’s — and kind of exotic — it’s because I wrote my own slide presentation tool. In pure bash. There are no dependencies. This entire thing is rendered using raw ANSI escape codes.
Um — no, it’s pure bash — not POSIX compliant, unfortunately — but it’s also hosted on this cool new Git hosting thing everyone’s been talking about. Go check that out. It could also be you, by the way — but yeah, that’s Tangled.
And yeah — of course, I think I should also probably mention that we are looking to get more AT Protocol projects hosted on Tangled. I would love to chat — let me know how we can help out in any way.
Of course, AI is one of those things everyone wants. We will do that — but aside from that, is there anything else we can do to get you on board? Do let me know — and looking forward to those conversations.
Thanks. Awesome. Thank you very much.
The videos from AHOY! European Social Web Day held in Hamburg, Germany, are being republished along with transcripts as part of the process of preparing for ATmosphereConf 2026, taking place March 26th - 29th in Vancouver, Canada.
Follow the conference updates and register to join us!