← All Talks
Presentation Development and Protocol

tangled: The Lewis end

Lewis Torrington · @oyster.cafe
Sunday, March 29, 2026
10:00 AM – 10:30 AM PT
Great Hall South
Available in-person & via livestream — Stream 1 (Great Hall South)

Building a company on an open protocol is a different ballgame. In this talk I aim to cover why we decided to make Tangled a company, how we're financed, why we went this route, the challenges we faced and our plans for the future.

Hello, testing, testing. Okay, there we go. Hi, good morning. So yeah. As as Boris said, I'm a stand-in for Anyrood, my boss uh at Tangled. Yeah, so what he was going to talk about was Tangled the business end as a Mr. Business on how they raise money and how one raises money in in in general using VC and using AdProto together. But first of all, he's not here and I'm an engineer, so I'm gonna talk about engineering things, and I hope you guys are all okay with that. I do know a modicum of of what what they went through because I'm a bit of a Nepo baby.

I knew Anirod from our Upcloud days together. Um so maybe I can perhaps speak of my perspective. This is the Lewis end, so take every single thing you hear from me with a grain of salt. So yeah, architecture diagrams. I think I'm gonna have it a little more informal. I hope that you guys uh heckle me actually, like at any moment, raise your hand if you like. Um we can force Boris to pass around the mic. Um yeah, so also online people on Streamplace. I would actually like it if somebody maybe boris as as well, or I don't know, somebody else, if if we could have uh somebody reading the Streamplace chat so that I I can get messaged.

I didn't have enough time to actually put up Arcup OBS Studio on this thing and and overlay some sort of Streamplace chat over my computer here so that I could see the questions directly. But anyway, I want you to know online that I care about you. Um so yeah, um about me. Uh question question from the stream. Uh who is this little guy? I'm about to get to that. All right, so uh yeah. Well, at Oyster.cafe, I thought that was a little more professional. I changed it recently. I was Lewis.moe, but there's a connotation to the Dalmoe uh TLD, so it's an oyster.cafe.

You know, I like oysters and I like cafes, so. Uh oh. Yeah, the arrow's a little misplaced with the two screens. I couldn't get it right either way, right? I I'd have to mirror it, but imagine me under both of them right now. Uh that is me. I actually have this little chick thing in my bag um and and fig contained it for me because they had a a little box, but anyway, it's uh if you want to see it later, it's real. Wow. Um I'm a software engineer. Uh as I said, I've been working at Upcloud, which is a Finnish uh cloud company, but then a month ago I got hired at Tangled because they raised 3.8 million euros uh and started paying me with it.

No, not all of it, but yeah, wow. It all goes to the the Lewis fund, no. Um not really. Uh I'm from Australia, but yeah, I'm living in Finland. Uh we're Tangled kind of. It's in a co-working space at the moment, uh, and I'll talk about that in a sec, maybe. Um but yeah, I mean that's that's kind of me. Just uh just uh just a little guy. Who is this little guy? I don't know. Um so yeah, here are the founders, uh Anid Rud and his brother. I just kind of screenshotted this straight out of Tangled itself.

Um these are the big boys. They've been working for a year um to make tangled what it is today so far. Uh and up until a month ago, they had I think very little runway to actually do it, so it's kind of like a make or break thing. Um and they've they've done super well in my opinion in the in the Lewis end of things. Um so they have recently hired me and we have a part-time student Dev Boltless from South Korea. So we're kinda like a remote-ish first uh company, and I'm breaking that rule with Anirood by having this co-working space uh in Helsinki where I can host all my mini PCs and freaky little Lewis cloud applications.

Yes. Um I'd like to talk a little bit about my take on uh Tangled before joining, like six months ago, nine months ago-ish, because yeah, as I said I knew Anyrood um personally and I was like interested vaguely in what he's doing after he quit Upcloud to do Tangled. Uh I actually this was before Tangled had its own hosted uh PDS. So I had to make a Bluesky account. Hmm, I was like, what the why do I have to do this? Uh why can't I just sign up to Tangled itself? Um so that was an interesting little piece of friction before uh secondary apps with their own PDSs came came into the uh became more normal, should I say.

in for the first time that it was I was it it it was it made sense. It's a utilitarian thing. I I'm all about that. It just kind of shows you what you need to see. Oh, actually I haven't even said what tangled is. Hands up, who knows what tangled already is? Okay, okay. I mean that's most of you, but not all. So I'll tangled is uh is a git forge. I don't think I'm allowed to say GitHub competitor, but we're uh you know it's uh using atproto. Um the the tagline is uh tightly knit social coding.

Um so if you wanted to use git uh yourself on a server, you can go ahead and do that and it's all well and good, but if you want issues and PRs and you want to collaborate with people more easily, then you're gonna need like an actual social thingy. So Anirod and his brother were like thinking, well, what's the best kind of social open infrastructure that we could choose to make that happen or like plug into. Um what do you know? I wonder which one it ended up being. Um so yeah. Alrighty. Yeah, so I I mentioned that it's kind of like a GitHub competitor.

Um, but tangled basically aims to go above and beyond. The baseline is having th everything that everybody already knows and uses, but then beyond that, uh there are all sorts of uh nice features that we got either today already or coming down in the pipeline. Right now, this is a screenshot of a stacked PR that I have PR'd. It's actually not closed yet, so it's a very uh yes, it's close to my heart. It needs to be merged soon, this one. But um who has used jujitsu before, the the like git superset. Oh yeah, okay, less hands.

Uh Jiu Jitsu, who knows what jujutsu is? Okay, okay, I mean kind of the same hands, I think. Um Jiu Jitsu is like a superset on git, it's nice. Um was it was it made by Google originally? I don't know the history, but I was kind of not forced to use Jiu Jitsu when starting Tangled, but uh they they highly encouraged that I try it, you know, like a Brussels sprout. And I tried it and I like it a lot actually now. Um so I'm submitting stacked PRs all the time. And this is one of them.

Um maybe you'll notice that uh usually when you have a PR in GitHub or anywhere else, it uh the the convention is that you want everything in one massive commit so that your commit history isn't horrible after the fact. Uh which means that when you're trying to push big features, you have to make them in entirely separate PRs, and then you kinda like lose what's going on, you have to have issue trackers or like actual full-on uh like tracking tracking apps separately from your from your Git forge. Um or you have it in one massive uh PR, and that is also just like a monster PR that takes weeks or months to review all in one go.

So the what what stacked PRs gives you is that you can kind of uh chunk things uh into each commit being its own like separate mini PR and you can um go through them one by one. You can merge a subset of them if you like. Uh so if we said that we like everything up to uh uh 1137 there, we could just merge all of those and then continue on the rest of them if we weren't so sure about the rest of them. Um we can clear them one by one. It's kind of forces me, the the uh submitter of the stacked PR to also break up my uh commits into logical chunks.

Um I think some people do it like chronologically speaking, but I think that the the dimensionality personally for me, how I've been doing it is that any any one of them could be merged like semi-independently of one another, but currently stacked PRs can only be merged bottom to top. So yeah. That's one value add um as an example. So that concludes the like uh normal human slides, and now I'm gonna go straight into architecture diagrams. I hope everybody's okay with that. Um let's start easily and simply. This is a extremely extremely simplified view of the of the like Bluesky infrastructure, uh not necessarily atproto spec because we have a relay in there, which is I'll talk about that later.

Um in green, these little arrows with the with the hole in the arrowhead, those are read requests. This is how I see it. I don't think it this is not like a standard. I just kind of made this up to because this is hey, this is tangled to Lewis hands so this is how I think about things. Like a read request goes out and that's in green. Uh and then a write request goes out and that's in red. Uh I could make them, I think the like standard is to make them bi-directional arrows, but I don't know, it's kind of uh difficult for me to understand.

Um this is missing some of the uh separate Bluesky infra like uh feed gen and labelers and uh and stuff that goes out to the side. I wonder if I can get my mouse over this. Yes. So you'd have more arrows coming out here for for feed gen and labelers. Yada yada yada. But what concerns me is the core here. So you only ever talk to your PDS, your personal data server. Is anybody put your hand up if there's something that you want me to explain beyond just saying PDS and I assume that you know what I'm talking about.

That's a weird, weird question to phrase it. I mean I don't know. I'll just explain everything anyway. So a PDS is where you store your data and then that then goes on and makes a write-esque in quotation marks request to a relay, which then kind of caches uh in a time time-based cache uh and and forwards it on to an app view. And I've got like stacked boxes for everything that can have you know one one million of them, but in the Bluesky infrastructure, you only have one app view, so there's no stack there. Um and then your PDS forwards on read requests to that app view that then has like a pool, like a full full cache.

Uh and why I said app view like is that I wanted to include um uh red dwarf from from the get-go. So red dwarf is like an app view list, quote unquote, uh app view, and just kind of uses fig's uh microcosm tools in in lieu of an app view proper. So it's a lot easier to run, a lot cheaper. Um that's something I think is very interesting, and I think it's kind of the future, but that's just my opinion. But yeah, Tangle. Probably a great opportunity as well. How many people in the room have heard of Red Wharf?

Okay, wow, yeah, decent amount of hands.app if you want to try it yourself. Yeah, I like it. I recommend it. Very good. Um so this is Bluesky as introduction to now what I'm going to show is how I see the current architecture of Tangled in comparison to this. Um yeah, we've got more arrows, we've got more stuff. So in blue we got the PDS like, like the data storage, permanent storage layer. So those are in blue, and then we have our relay and then we have our app view. So um does anyone want to give a shot of what I think is something that could be improved right from the get-go.

One of one of the easiest wins. Anyone, anyone? Beeler. We got a hand in the back.

I'll get to that. I'll get to that. I heard it. The the question was the the repos live on the not question mark exclamation mark? The thing I I'm always a bit confused by. I was like, why don't I have a repo in my PDS? Yeah. So well that that's a controversial statement, son. I don't care. I I agree, and we'll get to that because we have Lewis the Tangled and uh ideal architecture coming up in a couple of slides. But yeah, no, I agree. I think that a knot is a kind of PDS, a bastard kind of PDS.

Um is a spindle. So yeah, which begs a question what the heck is a knot and what the heck is a spindle. So a knot is uh stores your git repos. So this is remember it's a it's a git forge, so your git repos have to go somewhere. And unless we were going to be really stupid and put put your like git repos as some weird layer on the MST in your actual PDS, yeah, there has to be a second server um that is PDS-like because it stores data uh and it's personal and that's that's called a knot it tangled.

Um and a spindle is the CI system, so that's a separate server uh right now that I mean all of these can be self-hosted. Um so you can have your own knot and spindle and eat it too, even right now. So that's that's how it goes. Um so they all kind of communicate to each other in a in a kind of crazy way, which is fine and good. Um, what was I gonna say? Yeah, there's a recent introduction to this architecture literally last week that Botlas, the uh our Korean developer has added, which I think is really great.

Um so now there's one one more thing. This is like a spot the difference picture. What uh so yeah, there's there's like a relay-ish thing there. So I've I've colored that in orange. So not mirror uh saves saves all your git repos on all of your knots uh in one sort of place and uses that like as a cache. So it's kind of half app view, half uh relay, but I think it's a nice uh little piece of architecture that I think takes design inspiration from Fig's work. I think I've mentioned Fig a million times already, But yeah.

Very inspirational person in this room. So yeah, I mean it looks a little crazy, but remember that in the in the Bluesky infrastructure one, I specifically said that I oop that I that I made it super simple and didn't include all the feed gen and labeler stuff, but like this is our equivalent. I mean our not mirror will do things, TM to people's uh well, not doing things to people's git repos, but like you know, we'll we'll have better like search and stuff without slamming each knot uh with with crazy requests and and and you know digesting the thing all all damn day long.

Um so yeah, you kind of talk to the app view at at time of speaking um instead of the PDS directly, but then that we we trust the app view to write to your PDS. Uh so we've got improvements to make, and that's kind of actually why they hired me in the first place is quote unquote app rotation. So um here's the thing about kind of making a company versus just making something that's like a love project is that you're kind of on a time constraint. Uh so you you gotta get something out, um, or somebody else is gonna get something out, maybe before you.

And so Tangled has released things into production that need a little like broom broom sweeping to make them fully at protated. For example, uh when you edit your PDS records, usually that's supposed to then go to the re well, it does go to the relay and then gets up taken by the app view, but if your records aren't up taken by the app view for whatever reason, then you can't edit your records. Um I mean there are things that you can edit on Tangled and things that you can't yet. And my job is to make it all make it all work properly.

Um with that I would like to show you my ideal world. Um so yeah, I think this kind of uh gratuitously resembles the Bluesky one. Uh it's just with three PDS-like things instead of one. Um I would like to absorb the not mirror into an app view-like, uh so fully going uh microcosm style like red dwarf. I mean, again, so take this with a grain of salt. This is not tangled the company's vision. This is Lewis's uh mystical ideas that he's showing a room of other nerds. Um you talk to the PDS that talks to the knot or like proxies it on with reads and writes and that talks to the spindle, they all talk to the relay, which means that uh uh each of the knot and spindle have to act more like a PDS to be uh sending events to the relay and uh not not tricking it into thinking that they're PDSs because they are PDSs, right?

You know, like wink, right? Um so actual Bluesky team who are in charge of uh the the protocol stop me now if you don't like this idea. Um yeah, can I ask a question, Lewis? Yeah, you can you can yeah, go ahead. Um so this is super fascinating. Um so everything becomes PDS is kind of what you're saying. Well if you want a spindle, yeah. If you want an architecture like this. I mean, even beyond ting tangled. Are you gonna have those knots have service endpoints in a user's uh uh did doc? We'll see. Remains to be seen.

Yeah, it just depends how far we're willing to go with it. Because imagine this. Uh this may be a feature or a bug, depending on how you see it. But the the consequence of this kind of architecture uh the further we take it is that your your git repo on your not could actually kind of uh if it has its own DID, it could post on Bluesky, your your Git repo. Like if if you have a new issue or something that could there could be like a reference as a post on Bluesky or like something was merged or something like that, I don't know, random updates, like it could be self-label as a bot account because it's a git repo, not a human being.

I don't know. That seems kind of interesting. Um I'd like to show you one more even uh wackier, wilder idea that I've been kind of dreaming up at 3 a.m. Is that uh another spot the difference is that there's no relay. Imagine that. Um with more and more people making cheaper and cheaper like relays and things, and I've been talking with a lot of people on how to make a cheaper implementation. Not just not just running something cheaper, but like doing the spec, like imp implementing the protocol more cheaply. You could just inline it into your app view or app view like thing image.

So there's like less to have to manage. Um this remains to be seen. This kind of far out. Uh, but I think that maybe you'll hear more from me later in the year about this sort of thing. Maybe not even necessarily for tangled, but maybe I'll uh contribute some random stuff to other projects that that and talk to some other people who also uh thinking relayless, relay less behavior. So yeah. Umcretely speaking, I want to talk about this thingy back here. Because I mentioned it earlier, so maybe if you're curious about what this first major uh PR that I've been cooking up for for a tangled has been in the past month that I've been here, so I I haven't got anything else to do, so let's I'll show you what I'm doing.

Uh so this is how uh a NOT stores its data about a Git repo currently. Um does anybody see something that's not so good about this hand. Rosco. The repo is a IDA. Yeah, that's one. That's one. Okay, Roska said the repo is owned by one DID. Uh yeah. Sure. The ID is a handle. I mean that's the one I was looking for. The ID is a handle. Um so yeah, I mean uh on the AT Protocol, your ID is kind of like uh supposed to be a a DID, a decentralized ID. So the ID right now of a git repo is literally the string, the owner handle slash the repo name.

So there's like multiple things that are are needing some love. Um you can't really change the repo name if it's in the ID, right? Um if it's the primary key. And then I mean I actually have kind of not borked one of my git repos, but I I mean as I said at the start of the slides, I changed my username to Oyster.cafe. So on my git remotes were like looking for Lewis.moy, and I'm like, what's going wrong? What's going wrong? So it turns out that the the git remote was my handle that it now changed.

And so I've got this yin-yang symbol because uh we we do actually have a very uh very nice architecture. I'm not here to slam the existing state of tangles. It's very nice as is. Like you you have one corresponding uh record on your PDS that says that you do in fact own this, so that I can't let's say I uh I have a NOT um which has a git repo on it, and I go into the database and I say that the ID and the or the owner ID is you know Obama.blue Sky.social. Um and then I have something naughty on that give repo, and then if there wasn't this uh corresponding record on the PDS of Obama, it it wouldn't you know validate.

Um because that would be pretty weird to just say that people own certain git repos. So that's the current state. So what my PR does is just mint uh DIDs for Git repos on each knot. So when you're not upgrades, when this thing merges and you're not uh upgrades, all it will it will basically literally just for loop through all your git repos and and mint a DID for them. So I'm sorry to the Bluesky people um for all the testing I was doing of like you know 10,000 at a time, uh minting minting DIDs just to see whether this would work very well.

Um we can talk about that later, but yeah, I'm sorry about that. So yeah, that this brings a lot of uh benefits actually. So you can transfer ownership of Git repos. I mean I uh haven't got that in the PR, but that would be coming next, right? Um if if a git repo has its own DID, then you can move it around however you like. You can transfer ownership, you can transfer it between knots even. Um you can do all sorts of things. You can do anything that you can do with a regular actor uh on the atproto.

Um there are some other ways that I could have gone about this. Um I could have just not done a a DID. Um and I could have also specified that that a NOT is specifically in the DID doc that you when you when you're minting a DID, I could say that it's a hashtag tangled knot and not a hashtag uh AT protoPDS. Uh but I think that this this comes to the Lewis end again. I think that a knot is a kind of PDS. Um because it stores data. I mean maybe it's not personal, but yeah, another thing that this unlocks when when a git repo has um a DID is that we can probably do collaboration better.

We already have collaborators as a list that you can you can add other collaborators who are like co-owners of a of a git repo, but there's still like one owner. I mean, yeah. Um questions at this point, because I'm gonna start yapping even more yappily after this. Alright. So if there's random random time, then there's random topics. So we got we got seven minutes for me to yep. I think I'll start with PsyOps actually in general and how that relates at all to to Tangled. When I was working at Upcloud for the past like year, I was also doing marketing as well as software engineering.

I was kind of like devrailing as a gorilla marketer, and maybe you know of Upcloud because Upcloud was on Bluesky shit posting. And I'm here to say right now why tangled isn't shit posting the same way since I got hired. Because I I can do that and it has been proven to, I don't know, get some people at least giving it a thumbs up. And the reason is that it's a PSY-of. Upcloud is in the business of making money. And yeah, it's just that there are a lot of civics ethics and like philosophical people here, and I wanted to throw my hat into the ring just a little uh because I do know a little like a thing or two about that.

I tried to go about the psyop at Upcloud as ethically as possible, but it's what it is. Um, you know, like Upcloud is trying to get your money, unlike Tangled. Um that's it it's as simple as that basically. Um of course the Tangled account will like reply to people and I don't know, try to be helpful and show updates and you know do the m like the basics to to make people happy and and show like give give announcements to to let people know what's what's going on under the hood, but I don't think that Tangled should I don't think it's this place to be posting like a person in the same way that Upcloud and some other companies were doing.

Like it's just the same uh vibe as when you know like Arby's and KFC are arguing in Instagram comments. Like it's it was funny for a little bit, but then you realize that they're still only doing this to like get you to go to Arby's, right? They don't actually give a shit at all. Like whoever is the face is also pretty funny. But again, it's just like a when people ask real questions, especially on the Fettiverse, they they're like asking when are you gonna do BGP as Upcloud? Because you know it's a cloud company and they don't have uh like manage BGP or you can't just like send arbitrary BGP things like other clouds.

And I personally am an a nerd and I want it also, and I pass on every request and you know it all I do my part sort of thing, but then you are the face of this like big black entity that's just like you know Kaonoshi from that uh that Ghibli film. Uh that's how I feel, like, or just the mask part of it, I guess. And then uh managers are just like, yeah, yeah, keep up the good work, whatever you're doing, like it doesn't matter because we're not gonna like do anything about it, but just like you know, say whatever it say whatever it is to say that gets people to buy more Upcloud.

Um so yeah, Tangled doesn't have that incentive, that perverse incentive. Um yeah, that's all I had to say about PsyOps. How how much time we got? Oh yeah. We got one question in the audience. Okay, so this gets into the money question a little bit. You just said that Tangled doesn't want your money. But Tangled just took on a bunch of investment. Right. Ostensibly because those investors believe that Tangle will will be able to pay back that investment. Yeah. Which means Tangle will want your money at some point. Yeah, yeah. The way that uh Tangled is going to try and go about getting money is going to be hopefully fundamentally different to like something like a SaaS like or a IAS or you know, Upcloud is infrastructure as a service.

So there's no like free tier at all. Um this is the Lewis end, so I can't speak to the company itself on how it went wants to make money, but I hope, I hope, that the direction that we go in is that we do the enterprise pays for the for the masses to have it for free. You know what I mean? Um because I want free things also. Um and I want Tangled to be free for people. We got another question over there in the audience. Run Boris, run. No, you don't have to.

I didn't have a question, I just wanted Boris to do some cardio. Totally getting um. Uh no, I my so my question is is actually going back to some of the technical stuff you were talking about because you were talking about generating DIDs for the nots. Um or or DIDs for the repositories. Right. And so yesterday we saw Britney Ellish talking about the um the need to create a DID for like a group, right? And so I guess my question is if we're we're talking about the repositories needing DIDs and the not sort of s acting as a PDS for a non-person, and then we've got other people with these these other needs to create like non-person.

Is there anything that's fundamentally different about a repo needing a DID other than just kind of any non-human entity? Or is this kind of pointing to the need for like a we need to be able to assign a DID to an object? I think it's the it's the former of the two. I think that it'll play quite well into also the permission data stuff. Like they're gonna there's gonna be a DID for like a space also. So then uh hopefully this will all plug in quite nicely when that's a spec, and we can just say that you can also make private repos that way also.

That your the the DID that was minted for a Git repo can now be a space DID as well. It's like a private. It is an object, it's a space, it's a it's a you know it's at the end of the day, it's just an ID. For from my perspective, I just call an API and I get an ID back. Um or 10,000 of them. Did that answer your question? I I think this is the kind of stuff that's uh uh emerging from multiple different corners, but you can start to see patterns. There's this actor model that we see that can put all sorts of graphs and links and edges that end up on figs infrastructure.

Yeah, exactly. Well uh yeah, it's funny. Uh hang on a second. We we have one minute that I want to yap about fig stuff. Um so at Upcloud, I was very cloud native pilled. Uh so it's like fast food, like they the it's like oh you you you want to host objects, so use object storage, just spin it up. Just spin up a man managed object storage, just so easy. And then you're kinda locked into that. But then you're like, oh I well, I need a database. But well, it's so easy to have a managed Postgres instance.

And I was like very wrapped up in that, obviously, because I I mean I'm I just get I get nerd sniped like the rest of us, and these are all very interesting technologies. But in the in the month that I have been uh at tangled and no longer have free cloud credits, uh all of a sudden, all of a sudden I have to run things on a uh I mean for tranquil PDS uh that I do in my spare time, the goal is kind of to run it on a vape um natively. And so this relates to fake stuff because we're trying to get things as cheap and as small and as you know, like I don't know the they're like perma perma computing principles.

Like what what is the s smallest that I can make this that that still works and works perfectly? You know what I mean? Um I don't know where I was going with that, but I just wanted to s uh to stop with that because I guess that's uh time basically, right? Thank you very much, Lewis. Thank you.