Anirudh and Akshay from Tangled.sh and the Future of Decentralized Coding

{/ TAB: SHOW NOTES /}

This week we're joined by Anirudh and Akshay from Tangled.sh, a decentralized coding platform. We discuss the future of decentralized coding, building a git client on atproto, and how Tangled.sh differs from traditional git hosting platforms.

Episode sponsored By WorkOS (https://workos.com) and Mailtrap (https://l.rw.rw/devtools_3)

{/ LINKS /}

• https://anirudh.fi/
• https://bsky.app/profile/did:plc:wshs7t2adsemcrrd4snkeqli
• https://tangled.sh/
• https://bsky.app/profile/icyphox.sh
• https://anirudh.fi/identity
• https://blog.tangled.sh/intro
• https://blog.tangled.sh/pulls

{/ TAB: SECTIONS /}

[00:00:00] Introduction [00:02:39] The Evolution of Social Coding [00:13:13] Integrating Git and AT Protocol [00:26:45] Public Data on Blue Sky [00:28:07] Challenges with Private Repositories [00:29:26] Innovative Pull Requests on Tangled [00:51:06] Future of Decentralized Coding

{/ TAB: TRANSCRIPT /}

[00:00:21] Introduction

Andrew: Hello, welcome to Dev Tools fm. This is a podcast about developer tools and the people who make 'em. I'm Andrew, and this is my co-host Justin.

Justin: Hey everyone. We're really excited to have the creators of Tangled sh on with us. Uh, so Tangled is a really cool technology built on atproto, but we'll dive into that. Second. Before we do, uh, we'd like to allow y'all a chance to introduce yourselves. So who wants to take it first?

Anirudh: Yeah, suppose I'll go first. So, hey everyone, I'm Anirudh um, and I'm originally from Bangalore, uh, as is my brother Akshay, and I currently live in Finland and I've um, been here for like two years now. I moved here for my previous employer up cloud, where I built their managed Kubernetes platform. I mean, my, my work history has largely been in like infrastructure and distributed systems, and I've worked at.

Like a bunch of startups prior to this. So this is sort of my first time doing something on my own in a, in a way.

Akshay: and I am Akshay, like his brother. And I'm originally from Bangalore, India, and then I moved to London a couple years ago. and. I'm a compiler engineer by trade. All my sort of past experience has been in sort of analysis and sort of, uh, depth tools largely. Uh, and currently at my day job, I'm building a convert Cobalt to Java. Um, uh, it's, it's a bit of a, it's a bit of a pivot to, building a GitHub load. But, um, it's been, it's been quite a journey.

Justin: That sounds like a wild job also, I mean. Got more power to you, like all the coval in the world that like needs to be converted to something that like people actually know. incredible.

Akshay: for sure. It's not, it's not fun. Uh, but it's definitely, definitely something that it's, it's inevitable, I think. Yeah.

Justin: Cool. So let's get into talking about Tangled. Uh, it seems like a pretty interesting project. Uh, there is a long line of social coding on the internet. It started way before GitHub with I think Source Forge. It might go go back even further than that. Uh, but can you tell us a little bit more about Tangled and how it kind of takes this next step in our source control journey?

Andrew: We've been going through.

[00:02:39] The Evolution of Social Coding

Anirudh: Yeah, for sure. I mean, I think Tangle sort of originated as, an idea that came about when we saw the 80 protocol ecosystem, uh, sort of, uh, you know, grow legs and start taking off a little, cerca of 2024 or thereabouts. And yeah, I mean, I've always wanted to build like a code forge, I think prior to Tangled. I, I built something called Legend, which is a Git web front end. So if you're self-hosting Git repositories on your own server, you can sort of toss this on top of that and people can navigate that. It's, it's purely read only. Um, but this sort of, I've always wanted to like, you know, take that one step further and build like an actually decentralized system of some sort for code collaboration.

And, uh, I think, I think the stars sort of just aligned perfectly when 80 Protocol came out and it's like. Oh wait, uh, you can, we can actually build the social bits on protocol and, you know, the GI repository hosting can sort of be those. Of course, we'll get into that. But yeah, that's sort of the, the, the, the fresh take on it that we're sort of bringing about.

Yeah. Uh, I'm sure you wanna

Akshay: Yeah, uh, for sure. Even I, I used to host Seagate, um, because I just wanted to keep, have all my pository repositories on my own hardware, right? So I used to, I used to run, uh, Seagate from a raspberry pie at home, uh, and then store all my repositories there, uh, all my university projects and things like that. Um, well, firstly it's really cool to do that. But also, uh, you know, you get all this data ownership, as a downside, like people can't really see our projects, they don't discover it. and oftentimes I would just mirror it on GitHub, so, you know, people would actually open issues and open pulled requests even.

and I, I think the standard model is to sort of a patch. But in my entire sort of seven years of self hosting Seagate, I got one email. And then when I tried to apply that patch, it didn't apply. Um. So that, that doesn't really work, right? So, um, we, we do, I mean, email is decentralized like that, that is the ideal model, uh, that we want, we want to own their data, but, you know, still be able to collaborate.

But in practice, I don't really feel like, um, I don't feel like it's caught on. Um, and that's something we wanna, we wanna fix with Tangled.

Anirudh: Yep.

Justin: Yeah, I feel like the UX of email is like something that you really can't. Change much. Right? There's like very limited things that you can do. Um, so hearing you talk about this, this is interesting. So it's like you've both done some self-hosting and it seems like a lot of the traditional platforms that we have today are. More geared towards centralized hosting. You can self-host them, but it's like they're not easy to self-host and or take a lot of money, know? So like, you can self-host GI host GitHub enterprise if you wanna pay them a ton of money. I think GitLab is very self know like all the details of that. so how did that, experience in self-hosting and even mirroring to GitHub and like. The combination of those elements, how did that shape into like how you thought about building tangled?

Anirudh: Yeah, and that's actually an excellent question because, the existing sort of forges that you can self host like GII or for Joe or Gogs or whatever, they're, there's a variety of them. all tend to, uh, sort of gear towards being an entire GitHub. you host on your infrastructure, which is, it brings the whole whole CI system, um, and the git repositories themselves.

So, and the whole identity account management, everything. So the whole nine yards. It, it sort of becomes this really beefy piece of kit that you're now forced to set up and, uh, you know, host your repositories on, which works in, in, in practice, uh, I mean in theory, but in practice, if someone wants to contribute, they now have to create a new account. On your little for Joe instance or whatever, and you know, then send you a patch. So the, the, the, the friction to sort of leave GitHub and use this is, is just way too high. Like, why would I wanna create a new account on your little server, like a Noname server? I. So that sort of really informed how we wanted to design Tangled, where we wanted to ensure that you could still host repositories on your, on your own servers, but at the same time, uh, we wanted to solve for that, you know, identity problem.

We don't want to have to create new accounts on everyone else's servers to just send them a patch, right? Like, especially if it's just a tiny drive by change. I think fundamentally that's where 80 Protocol shines, and it it solves this problem by default with the decentralized ID or DIDs as they're called. So in effect, we are now able to like, maintain that central identity, uh, which is, you know, what, what you get when you sign up on Blue Sky for now. But in theory you can set up a date without that and you can then send, you know, you can then host your repositories on your own servers using. You know, tangles, uh, knots, of course, we'll get into that.

But, um, yeah. And then the, the, that's whole, that central identity sort of solves the whole thing.

Andrew: I just wanted to say, uh, the sort of be like the focus on Lightweightness, right? Uh, being able to participate in the network does not require like resources, uh, especially, you just have to just, you just have to a hard disk with some repositories on it. And then you run this really lightweight thing and all of a sudden you get this, the ability to like, you know, contribute to other repositories, like get contributions to your own repositories. I don't feel like, I don't feel like there exists software like this right now today.

yeah. So yeah, GitHub is a platform. I, I, I love it. I've used it for a very long time, but I've used it in like tandem with Twitter. Like I'll open up a pull request and instead of like trying to bug the, the maintainer on GitHub, I'll just go to Twitter, bug 'em there. It usually gets my, my pull request across the line.

So with Tangled, how, how do you see like the social coding landscape changing now that like, that essentially isn't a problem anymore? I don't have to. Go find this developer on another network. I know where they are.

Anirudh: I mean, yeah, that's a good question. Uh, uh, it's interesting that you, you would go message the, tab on Twitter.

Andrew: I get them myself too.

Akshay: Yeah. Um, no, for sure. I, I think, I think there's a, there's a sort of, that's, that's kind of valid that we had this, you sort of had the same identity, right? Um, on your, on your repositories as well as your sort of like side of things. Personally when I was sort of, uh, sort of starting off with Tangled per, I personally don't use social media as much. I'm, I just sort of tend to use one thing. You know, my internet presence is just, you know, either my website or like, I tend to sort of focus on one thing at a time. so I don't imagine myself sort of. Being that person where you would open up blue request and then message on Blue Sky. But you know, I, I think, I think, I think this sort of like, the, sort of, the ability to the shared identity opens us up to a lot of other things. Um, I think a lot of people want to sort of see a unified notification system where, you know, like pull requests, you get notifications of Blue Sky.

We wanna somehow, like they wanna see this sort of.

Anirudh: Sort of just have like an inbox for everything, right? Which is what email used to be. And I guess we could sort of see something like that happen for, uh, 80 Pro, just have an 80 proto inbox where all the other, you know, like the 80 proto ecosystem just sort of messages into that. I mean, I, I can see, I can see this there sort of being like a deep integration, you know, between angled and other 80 protocol apps and which is enabled by the fact that just have one identity. Which is what, like all these integrations with email are able to do that because email is one you own, Um, yeah, for sure. Um, what do you, uh, do you have something to say on this on.

no, I think, I think you put that very well, uh, with the Yeah. 80 protocol inbox is, uh, yeah. It's a pretty neat idea. And I think, yeah, I think fundamentally we're in the super early doors of what, uh, the, that that ecosystem is gonna shape up, like, so I think. It's a bit early to say what that's gonna look like.

There's, it is just, you know, we're like hardly a year into this whole thing, so, um, yeah, it remains to be seen. But yeah, I think that's, that's some early thoughts for now.

Akshay: That, that could be the, that could be the next big thing. You know, like one, one inbox for all of 80 proto, and then there's just.

Anirudh: there.

Andrew: Yeah, it, it kind of combines the ideas of email, RSS, uh, identity, like all, all of that in one. It's, it seems interesting for sure.

Anirudh: Yeah. Actually didn't think about it. Maybe there's like this one app you where you say, I want to listen to blog post from this guy. Pull request from this guy from this guy. And then it just all, uh, collects into your

Yeah,

inbox.

like that. I think as ad protocol, you know, sort of evolves and there's a lot more, uh, you know, there's a lot more that you can subscribe to on the, on the fire hose. Uh, you can you, yeah, we can sort of build out like this hyper customizable app view, which lets you subscribe to, you know, whatever you see fit.

Like you want to see blue sky posts from just, and ju and you, you wanna see, I don't know. like, you know, what is, what is, what are they calling? Like those TikTok, skylight, sky. Skylight.

you know, video feeds from just like couple of skylight creators and just put all of them in into one. think that would be pretty, pretty sick. don't think anyone's thought of that yet.

Andrew: Yeah, I, I've heard rumblings of this idea from people on the Blue Sky team where it's like, do we think of at proto as like a protocol or a browser? Because it's like you could build an AT protocol browser and like I could even imagine, like I, I remember about.me and it, it was a website where you made a personal webpage and you filled in all your information on app proto.

You could have an automatic about me. You just go, Hey, log in with my PDS. It's there.

Anirudh: yeah, yeah. A hundred percent. A hundred percent.

Justin: So

speaking of at proto um, and building on this topic, you know, it's interesting.

[00:13:13] Integrating Git and AT Protocol

Justin: So like Git is already decentralized and, and in a meaningful way. and at Proto is decentralized in a meaningful way. So what is the, how do you marry the two in a way that is intuitive?

Akshay: I mean, I, I can talk about a bit about this. I mean, we've, we've thought long and hard about, you know, the fact that we are dealing with two protocols. There's like the gi you know, backing for. repositories, which is like hyper optimized for handling diffs and you know, like flowering of, uh, repositories and like addressing um, sort of snapshotting repositories as the comics grow.

And then this 80 protocol, which is also building this Merkel bag. And then, um, you know, for like verifiable records, people can like authenticated records, right? Um. then we have these two things and we want to marry them. That surely there's like a unified interface for this, right? Surely we can sort of store repositories, know, using the 80 protocol Markle dag or, you know, the other way, you know, store 80 protocol records, uh, using the Git trees. Um, but truthfully, I mean they, they've, they've sort of, Git has evolved a lot in the sort of 25 years that it's been around. It's, it's a behemoth. It's, uh, it's quite to even like wrap my head around the model. And it's also very extremely focused on specifically evolving code bases, like adding text-based diffs and stuff. Um, so like, we thought a lot, a lot about this and we realized we should just keep it separate. Like, you know, we have these PDS things and then we have GI repository things, um, and. I think, I think it may be if we sort of sat around and then as a research project over years and years, we could build way for GI repositories or rather to build a version control system on 80 protocols.

And then we could maybe share, um, you know, the underlying, um, um, advantages that 80 protocol brings, or actually build a PDS, which uses GIT as a backing, right? backing for storage. Um. I think we could do, but I think at the, I think at, at the very, I think the very simplest solution is to just keep them separate. Um, let git repositories be git repositories, let PDS, uh, repositories be PDS repositories and we'll sort of advance this. Um, currently the sort of like deep integration does not exist. Repositories aren't exactly stored on the ps. We do create a record for repositories, but it's not like what you expect from ad protocol is that you can. like we just have the contents of a record and it's like inherently verifiable. But currently that's not possible because the gets repository set from the 80 protocol record for repository. Um, but we have some ideas to sort of like connect the dots here. Yeah.

Anirudh: Yeah. Yeah.

I.

now, all, um, yeah, I can probably expand on that. So I think for now, all the social bits, like your pull requests, your issues, your uh, your comments on all of those. The, in fact, the pull request diffs, the patch diffs, um, and of course the repository, uh, metadata, uh, scars, follows. Um, yeah, all of that is on protocol.

So all of that is written directly to your users. PDS. And, um, you know, so we are using ad protocol, uh, through and through for that. It's the, but yeah, and then that's where we sort of introduced when, you know, when actually said, let's keep git pository separate, then we, we sort of had to think of, you know, how do we keep it separate?

And if, if, if it's separate, how can we sort of, um, arrive at that vision of, you know, that, you know, you can self-host it and still have others contribute. And that's where we came up with the idea of knots, like K N OTS knots. And knots are like these super lightweight, uh, like, uh, lightweight git repository like servers in a way.

And they, all they do is they, they're completely headless. There's no ui. It's just like a, like a rest, API that serves your Git repository. And it's then picked up by us, the app view, and, you know, we then display it. So this effectively allows for, you know, like a, like a network of these federated knots to run. uh, there's a unified view into this, you know, this federated, uh, set of git repositories that can live anywhere and everywhere. And of course, the, for, you know, forking and poor requests, et cetera, all work across knots, uh, facilitated by protocol and the app view.

Akshay: Yeah, I think, I think there's been a lot of chatter about, like apps using 80 protocol. So everything that uses 80 protocol eventually looks like social media, right. I.

Anirudh: Um, so what about, what if you're building things which are not entirely social media? Like how do you, and in which case you just use 80 protocol for the social bits and you just enable, so like the sort of social bits of an, of your application with 80 protocol, but then don't sort of try to shoehorn 80 protocol to the other things.

Akshay: Right. I think it's worked quite well for us.

Anirudh: Also because, you know, like Git is huge. There's a lot of tooling, there's a lot of things that's been built for Git the last, um, so many years. Um, we don't want to deconstruct that and then, you know, like switch like a PDS based version control system. Um, and also like being like Git is fundamentally like multiple people contributing on this one repository. But PDS is sort of like personal data stores, right? You'd want to, only one user can edit a record on a PDS. Or rather on their PDS repository. and I fundamentally, I mean maybe, maybe there's a solution here where we sort of have a deep integration.

Akshay: It's just not something that we're sort of looking at right now.

Justin: Something that we've talked to other folks building on the app proto about is, so app proto has this idea of a lexicon, which is like a custom data structure for your, for your app that's built on app. Proto and bl blue sky has their own lexicon.

Anirudh: So if you. Write data in the blue sky lexicon, it'll show up on blue sky.

Justin: If you write data in a different lexicon, you have to have an app view for it to display. this interesting like tension between when do you make something show up in the blue sky lexicon versus like, when do you use your own custom lexicon? And, and sort of as y'all have been thinking about Lexi social. of the things that popped in my head that I've never thought about before is like, notification systems are always super hard to make, and it's interesting that you have this like option to sort of like hijack blue sky in a way to like be sort of a notification system. It's like, oh, if you wanted to, it's like you could have a blue sky post every time you created a new tangled repo or whatever.

That'd be like a very simple thing for y'all to do under the hood. It'd be like, almost like a choose your own like. How you wanna be notified or like how public you want it to be. Like what are the network effects and where does it impact?

Anirudh: That's true. No,

Justin: we even had, um, this conversation earlier, um, like even on Blue Sky actually about, I. People wanting to either retain their blue sky follows or us untangled building an entirely new follow graph. Like, because we could of course op, you know, we could have just, you know, had your blue sky follows automatically imported, untangled. But then we felt like that would probably be not a great fit because again. Tangled is not looking to be a, you know, a blue sky compatible, or like, it's not, it's not a social app, right? It's, it's a social enabled app. And I think that that sort of distinction is where, um, you know, where we sort of figured that, okay, you know what, we should probably build our own follow graph where you follow people who you want see, you know, their code activity for not, you know, you don't follow someone on Blue sky. Uh, and, you know, have the exact same people untangled, because that doesn't make sense. It's not a one-to-one, right. So, uh, yeah, so that's, that's sort of, um, uh, another, another interesting thing about 80 Protocol, right? Because I think after a point you'll only see a certain number of these social apps because you can't have, I mean, there is an inherent limitation to how many social apps people are going to start using.

Anirudh: Sure. You have TikTok, you have Instagram, now you have. Uh, Twitter all shaped in 80 protocol, you know, versions of them, but that's about it. Like, what else are you gonna make? Everything else has to sort of build its own little space, and I think, fundamentally 80 protocol enables this and that's great.

But, yeah, I think, uh, that mix and match, is also pretty cool. But yeah, ramble.

Akshay: Uh, lot of, a lot of, a lot of chatter about like weather. New social apps built on Ad Pro should share network graphs or not. And yeah, I mean, I mean like on it says maybe in your view, maybe like, you know, you're Tangled Follows are, you know, like you follow different people entirely untangled versus different people on Blue Sky. I personally, I, I personally, I mean I feel like I, the engineers I follow on Blue Sky are the same people I want to follow on angle. I wanna see the same code. So, yeah, I don't know that there's a, there's a, there's a, there's a good answer to this. I know that the, I know Spark the TikTok loan. They're, they're sort of having an option where you can, you know, import your, the same follows on Blue Sky. Um, and then, you know, when you start having options like this, you know, like import from the other network and then share with this other network, I feel like users might tend to get confused. Um, so yeah, I don't, I don't know that there's a, there's a clear answer here. Um, I, I personally want to keep my. a hundred or so blue sky follows untangled also.

Anirudh: Interesting. Yeah, I, I, I don't know. I, I don't think so. I personally wouldn't do that, but yeah.

Andrew: Yeah, I, I think I'm in that camp also. Like I follow a lot of people on Blue Sky that I don't, I don't care what they code about. Like they're, they're an infrastructure and I'm very much not an infrastructure.

Akshay: There we go.

Andrew: So one interesting question I like to talk about when we're talking about app Proto apps is something that, uh, Rudy, the creator of Black Sky likes to bring up also, is, uh, we can't just, uh, be a skew morem of the past. Like, sure, you can make a GitHub shaped thing, but does that make it a novel idea? So like, what are the like.

App proto specific bits or maybe even like some planned features that you have that kind of like make it unique to the protocol rather than just like a clone of an existing app.

Anirudh: Yeah, this is an excellent one actually. You probably want to talk about like the DID web, uh.

Akshay: Oh yeah, yeah, for sure. Uh, I mean, we've had a lot of ideas. Um, so fundamentally like the very, at the very core we want to, we want to a federated. Uh, social coding platform. And I think, I think this is a really good step, firstly, for a lot of social apps, but like, they may be clones of existing apps, but the fact that they're federated instantly makes me want to use them, or at least want to support them.

Right? Um, and I think, I think that's a good, I. I think that's a good sort of like denominator for people creating apps. Like it's okay to learn stuff. Like is the fact that you can sort of respect any photo and instantly build out this um, uh, decentralized app. I think there's good value in that, but secondly, we want to also, I. Our sort of differentiator is the fact that, you know, like individuals can host repositories on these servers called knots, right? Um, and something we want to sort of enable here, uh, and I don't think this has sort of been possible in the past, is if you host your own GitLab or something like that, it's not really like discoverable to the public.

You can maybe tell people about it, but it's not really, know, there's nowhere you can sort of like announce to, to the world. And this is something we want to wanna sort of. Been done with Tangled is that the app u is where we will pick up all these knots, which are sort of coming up and then we will sort of broadcast it to the world.

So discoverability sort of stops being an issue despite the fact that, you know, you're sort of self-hosting something. don't know if that answers your question quite closely, but what we're trying to do is, uh, currently this is not, not implemented, it's just in my head, but we want nots to. Like when people sort of start, uh, self-hosting or not, we want to assign, yeah.

Yes. Let's say, let's say when they initialize or not, we want to sort of assign a, did web identity to it and then sort of make it behave like a small, like a bit like a PDS, so it's sort of able to broadcast itself to the world. Um, so even cell posters get the visibility they want despite being in the sort of decentralized network.

Anirudh: And this also sort of, uh, des sanctifies the app view in a way. And it sort of makes us truly decentralized. So what this allows is because currently knots have to register themselves with us, and only then are we able to like showcase the repositories. But in this model, uh, uh, if we do, once we do get to building it. App views sort of become peers almost. So anyone can spin up an app view and um, and then, you know, the knots that advertise themselves will get picked up by the app view and, you know, will start getting served. So I think this sort of puts more control in the users and knots and app views are almost just like, you know, one of us just peers on the network, which, I think would Yeah.

Make the whole thing even more. 80 proteinated in a way.

Justin: There's an interesting. Challenge here too with like visibility.

[00:26:45] Public Data on Blue Sky

Justin: So I mean everything right now on, on that photo on Blue Sky is public. Um, you know, they have dms which are kind of like a separate system, but like everything else is public. So it's like when you think about, know, shared get repositories, whether they're public, whether they're private, what metadata you share, are y'all? Going through that balance and thinking about like, can someone participate in a network in some limited way, uh, without, you know, fully sharing all their data. Like, what does that look like? I.

Anirudh: Yeah. I mean, we could, so the thing is, right now, um, the protocol is just fundamentally open. There is no private data in any protocol, which, uh, it doesn't directly limit us. I mean, we could technically have users hosting knots and, uh, just not broadcast that. uh, the 80 pro 80 proto, and we don't write records for that and have it fully private, only visible to them. we just feel like that would be a bit of a, don't know, a half-assed implementation. We don't want to go down that route because it, it doesn't feel like the right way to do it. So I think for now our thoughts are just, let's just see how 80 protocol, private data and private repositories, uh, come about and. We'll then build it then. So for now, all repositories are public and that's, that's just how it's gonna be.

[00:28:07] Challenges with Private Repositories

Akshay: Yeah, I feel, I feel like a lot of 80 Pro, like I think, I think this is sort of putting off a lot of people from on 80 Protocol, right? Like if you wanted to build an 80 protocol Instagram today, I know that Instagram sort of having your visible only to friends is probably like a big thing on Instagram and you can't do that today on ad protocol. And maybe the best bet for sort of people building these kind of apps is to, you know, like the, I mean, and we have this sort of, we have the ability to do this, which is to just like, wait till the developers of 80 Protocol do it. You know? Um, uh, and I think, I think that's good. That's good. I mean, we could, we could implement private repositories, like it would just be off protocol, like how Blue Skies dms are implemented.

Um, but. Do we want to do that? I mean, maybe, but I don't feel like there's been that much interest in private repositories amongst other things.

Anirudh: and I think we have something in our favor, which is, you know, the fact that source inherently is, it's such a big thing in, in programming that people are okay with, like broadcasting their code bases. Um. As opposed to, you know, something like dms where you absolutely want to start with private first.

Justin: so I see you guys have been posting about pull requests a lot lately.

[00:29:26] Innovative Pull Requests on Tangled

Andrew: Uh, you've been taking interesting approaches to creating pull requests. So how do pull requests work on Tangled and uh, like what are those like kind of unique approaches that you're trying to test out?

Anirudh: Yeah, I mean, uh, no, that's an excellent question. I think we both will have a lot to say here, so,

Akshay: This is my, this is my favorite question.

Anirudh: Okay. Well, yeah. Actually, Akshay, I should probably just start with this and I will probably finish, go ahead. Go

Akshay: Yeah. Um, yeah, for sure. Um, so firstly, firstly, I believe like coming back to this. Uh, firstly, I believe that the email based approach to I. Was really good. Uh, it's just the fact that email itself was not, you know, lending itself to this, ease of use. I think somehow a lot of people just don't like, GI and then copying their patch and putting it on an email client and hitting send. so we wanted to, I mean, we wanted to, we wanted to use that as a sort of foundation. Right. Um. So what you do, so we initially started off code request as a way of, you literally type gi diff, you make some changes on your Git repository, you type gi diff, you get some output, you copy and paste that on the website, and then you click on new code request and that's your contribution. very easy. All you need is to, um, you need is an 80 protocol account and the ability to write code. and then you just write Gi Diff and then you're off to the races. Um. And it, it works really well. The fact that, uh, it's exactly like email, right? Instead of, uh, you know, sending an email, you just send a upload request on this app view, and people can, know, you resubmit it.

It works really well. Um. As opposed to the GitHub model where you have to firstly create a account on GitHub, then you have to, for the repository, then you have to, you know, clone the fork repository so that you know your GI remote is configured correctly. Um, make your change and then go and click on pull request. Um, so that's, that's sort of what we started out. Firstly, you know, quickly be able to submit, drive by pull requests like this. And I feel like this is sort of. Covering a lot of cases that, uh, we see in quote contribution, like people want to edit one word in your readme. They can do that really easily. the next thing we wanted to do is to sort of have, um, sort of like traditional GI of flow of people who are sort of, collaborators and projects you want to be able to do, like you wanna be able to push a branch, then you want to be able to open a pull request through that. and this is what we've done. So we've sort of enabled the ability to. From one branch to another. Uh, the, the sort of key difference between this model, uh, and GitHub is the fact that we have this sort of round base system. So in GitHub what you do is every pull request is mutable. So you open a pull request, somebody puts a review on it, and then you append comments, right?

You just modify your existing pull request, and then they modify the pull request, but adding more comments on it. And then at the end of, you know, like three, four rounds of reviews, like let's say, you know, a third person comes and looks at the, they have no idea what's going on. Uh, some person, somebody has forced. Force push to their branch. All the, uh, sort of like commit times are completely off. It's impossible to attach a review, comment to a change. You know, it's hard to tell what change was, uh, addresses what review, comment,

Anirudh: um, and our round base pull request solves this, uh, because a pull request is immutable.

Akshay: So when you click on submit. It starts a round and you can't edit that round again. That is sort of set in stone. and when a reviewer leaves comments, you have to submit round. So you start off with round zero. Let's say, you know, reviewer leaves comments, and then your next submission is gonna be round one. So it's sort of, sort of like incrementally you can build on your patch. And what this enables you to do is to sort of see zero, got two comments and let's see, was it addressed in round one? Was it not addressed in round one? Okay, let's see, what if it was addressed in round two? So it's sort of easy to tell chronology of how a pill request is evolving. Through the round based request, uh, model, and this is what you get in email because you can't edit an older email, you can only send an email. You get another email back saying Fix this, and then you send another email fixing those things. and that's sort of what we wanted to encapsulate with a better ui. Of course.

Anirudh: Yeah. And uh, the neat thing here is even you, you don't append commits at all. Like you are essentially resubmitting the same set of commits in every round, which allows you to sort of, uh, as you, as an external or as a reviewer, you can sort of see. Uh, you know, how that, how the pull request is evolving, how that, you know, commits are evolving.

And this works perfectly in, in a, in both like the GitHub model where people are used to sort of appending commits. Sure, you can append and commit and push, but then you can still see that whole history every round. Uh, and you can sort of see that whole patch every round. Uh, whereas if you're also coming from that Garrett or the the, or even like the email style model where you send. Patches and you sort of re-author the same commits. Um, and, you know, reviews are done per commit. It works perfectly in that case as well, because now your rounds are just gonna be that same, say three commits over and over again addressing, you know, re-author and rebase. So they're, so that they're addressing review comments and, uh, in fact, last night we shipped the, I mean, well actually mostly took this one, but, uh, we sort of shipped the, uh, integratives feature, which allows you to sort of, uh. So it allows you to sort of see the actual change between the two rounds. So say you have a, you have a, you know, mega patch in round zero, and then you have some comments on that. And then you submit that in round one again, with the comments addressed as a reviewer, you can then hit the iterative button to just simply see, you know, the lines that were changed or the files that were changed.

And the rest of it are, you know, completely untouched. So you don't have to look at the, you don't have to look at the whole patch. Again, you can just look at, you know, what changed between round zero and round one,

Akshay: Yeah, this works. This works really well if, uh, especially from the reviewer pers perspective, uh, especially if you've already seen all the code from round one, and you know that the expected sort of update is like a one word change. You click on IV and you expect to see just that one word. Immediately if the user has changed anything else, it's just visible exactly like that.

Anirudh: Whereas with GitHub, you are either like diving for the exec commit or the, you know, the user decided to force push, so now you have no idea what they've done.

in fact, the underlying, um, uh, I guess the infrastructure of how these whole Pull request is, is di designed fundamentally uses the same tooling that is used for sending emails, uh, or like emails with patches, which is the GI format, patch, uh, tool. So that allows us to sort of. Uh, you know, generate that sort of patch, uh, per round.

And it's also protected against force bushes. So you force push your branch and then you re resubmit. We will still generate the exact same patch as is, uh, in, you know, and then in the, in the new round that gets, that gets submitted. So, yeah, works perfectly.

Andrew: Yeah, that seems like a, an interesting system. Uh, I'll admit I've snuck some code in after a review, and a system like that would, would, would prevent it. And that's, that's probably on the better side.

Akshay: No, I, I tend to, I tend to do this quite a lot. Um, I'll just, I'll just sort of drive by a few more changes, um, especially right after the reviewer hits a approve. That's, that's my, that's my sort of time sneak in couple of commits before they hit Marge.

Andrew: Yeah. My two strategies are either that or submit such a big pull request that it crashes the GitHub diff ui and then they just can't review it. So rubber, you guys, that one.

Justin: Yeah, thi this is awesome though because I force push a lot. Um, I use a tool that rewrites history and I try to keep the commits very clean

Akshay: tell the story about what I'm doing or whatever. Um, and this has always been a problem. Um, it's a problem when people are collaborating with you too. 'cause you can stomp their work or whatever, but, uh, but anyway, uh, the immutable commits sound amazing. And want to mention, I mean this is not something we've, uh, we have sort of worked on fully, but all of this is sort of building up towards the ability for people to leave. I. Comments on individual commits. So especially if you like, uh, sort of reauthorizing and writing your commit history to be as clean as possible, whatever reviewers could lead, comment, comments on individual commits.

So then you could submit your sort of, let's say you submit three commits and the reviewer wants you to address a change that you made in commit number one. they can then leave a comment specifically on one commit, and then you can go and re-author that. Um, and this is, this is what we are building towards.

This is what we want to enable with our review model.

Justin: One question. This isn't something that I, I feel like y'all would necessarily be, I don't, I don't know if you're in a good place to solve this or not, but, uh, sort of as Andrew alluded to, one of the challenges is that we get with pull requests is that they're, they can be really big and really hard to review. Um, and I like the inner diff, uh, functionality that you're talking about. 'cause this, that can like narrow the like. The delta between changes. Uh, one question would be interesting is like, can you inter diff arbitrary versions or is it only like a ladder? Because it's like sometimes, like in this case of you're changing one commit and then changing another commit.

If you can only inter diff individual steps, that might not actually give you a full story. But

Akshay: the other thing is like. How do you think about like, breaking down work? It feels like that probably happens outside of not, uh, or entangled, but um, it is a thing that's always on my mind is like, how do I encourage people to do smaller pull requests and how do we make it more ergonomic for them and like, or if we get a big pull request, how do we make it easier to review?

don't know. They're hard, hard problems.

I think, I think a lot of these questions, um, I think, I think they're, they're quite closely related to the tools we use. Um. Do people make big pull requests because the tools that they use don't allow them to sort of easily break down their work? Is that why they make big pull requests or do they make big pull requests because, you know, they couldn't care less about, know, review burden for the reviewer? Um, and maybe, I think, I think there's a bit of both. Uh, but I think, I think the tooling for making more atomic field that are easy to review, uh, that simply, I mean, I feel like it does not, I. it does not, this doesn't exist. Something that's really good with that, this is something that I'm not fam, I'm not sure if you're familiar with Digit.

So the new sort of, uh, VCS, um, system, which is sort of compatible with gi is that, that they sort of allow this flow where you can build these atomic code requests without your velocity, right?

Anirudh: Um, and we want, like, it, it sort of goes hand in hand. Does not let you build big request quite, I mean, sort of like multiple changes quite easily, but let's say jujitsu does. The other component is whether your code for really enables multiple pull requests to be reviewed simultaneously. Um, and that's something we want to do. Uh, we are building sort of close integrations with, uh, these tools like Jiujitsu. So you can be, you can then stack your pull requests, make it easy to review, um, and without, without blocking your velocity, uh, without blocking you from building, like continuing build.

Yeah. Yeah. I think fundamentally the, the GitHub model, the GitHub's, shall I say, archaic model, which they came up with. I dunno, whenever they launch and hasn't really changed, it sort of lends itself to these, you know, giga prs, right? Like people, you have this one pr I mean, where I used to work with, I think the longest we've had this one pull request open was for a year with like 400 co comments or something like that.

And then eventually it was unmergable because. You know, the, the, the, the, the branches had deviated so much that it was almost its own little repository. But, uh, you know, that's, that's sort of the, the branch model results in such, uh, you know, such outcomes. And I think. and the fact that GitHub doesn't, you know, make very easy, there's so much friction in opening a pull request as is that, you know, users are dis-incentivized from creating these smaller atomic ones because it's so much effort to have to go and like, you know, uh, make a new branch for each change.

Because that's how the PR model works. It, it requires you to create a new. GI branch per change. And that's, um, and that, that's where, you know, the, these new age of tooling like Juujitsu and I think Git Butler is also solving for this, but on top of Git, um, what they aim to solve. They, they're trying to make it as easy as possible that you can, I.

You don't have to, you know, break out these changes into like bigger, like, into separate branches, but you can, you know, still make these atomic prs. But fundamentally, I think GitHub's UI itself lends itself very poorly to, you know, reviewing atomic prs. 'cause as a, as a reviewer, you, not, you, there's no simple way to like. You know, look at multiple prs, uh, in, in, in conjunction, and you're now forced, like click through different links and you have different tabs of, you know, pull requests. So it's just, it's just a sad, sad state of, uh, affairs overall. So yeah, that's, that's exactly what we're aiming to solve for.

Justin: Yeah, that's exciting. We actually had, uh, Scott, from the GI Butler team on and from the original GitHub team.

Anirudh: uh, another tool, the one that I'm using a lot these days is Retcon. Uh, we have the. Uh, the, the creator of that tool on as well. And it, you know, does a lot of like rewriting, making it easy to like rebase or whatever.

Justin: And yeah, I, jujitsu, I'm super excited about, I hope we get some interesting tools, but I think to your point, it's like traditional, uh, traditional, like VVCS systems don't like work well with these things. It's like still a monolith pull request model. So it'll be really exciting if y'all get like stack prs because I know there's a lot of startups in that area. Um, that are like trying to like, solve this problem. Well, so it's, uh, it's exciting to hear like another take on it too.

Anirudh: yeah, yeah. Absolutely. And I

Akshay: just has to be supported first party as a first class citizen on, I. platform where everyone's collaborating on because tacking it on top of GitHub, uh, or even like building a, like an extra, like a third party tool on top of that, like Graphite is doing is, is gonna work, but it's, you know, you're still fundamentally limited by what GitHub lets you do.

Anirudh: So being able to do that, you know, on, on top of your actual platform itself, like what we're aiming to do at Tangle, I think. Yeah, that's, that's, that's the key. That's paramount.

Justin: I got one more question. Um, I, I think it would be. Remiss if we didn't talk a little bit more about GitHub. Um, the thing with GitHub is their massive reach. Um, you can't deny the, like, discoverability of their platform. And, and you've talked about like, oh, you know, we, we hosted our own things and I'm like, mirror it on GitHub.

And probably in this world where I had to like host my own, not like, one of the first things I'd wanna do is like, how do I mirror this to GitHub as well? This is like, I want this ecosystem to survive, but also like. people are on GitHub, which like most people, not most, but a lot of people are, then it's like, it's still good to have that presence, um, even if you like, want disable pull requests and all the other things and just like, here, interact with our system in this way. So have you thought any about that or like what do you want that story to be? Or do you kind of wanna discourage that behavior? Like what is, what is your sort of like, around that area?

Anirudh: Yeah, I mean, I think it would, um, yeah, I mean I think, yeah, we have some thoughts. Uh, for sure. I think, I think we might even differ on what we think, but personally. I think it's, uh, it's unfortunate, but I think we may have to, uh, you know, you know, build some sort of to mirror repositories, um, at least as tangle is still in its infancy. Um, yeah, just so we can, you know, drive more adoption, right. So it's, uh, yeah, we have to, but I think how we go about doing that is something, um, yeah, I don't know. Uh, there are a couple of ways to do it. Uh, one of them would be to just make it. in, you know, 80 protocol driven wherein a user, uh, you know, we have some sort of an import tool, uh, or that, that lets them, you know, create an 80 protocol record for, uh, like the sh tangle repo or whatever.

And then we pick that up and then, uh, you know, they're able to, then we're able to then populate the repository somehow. Um, that's one way to go about it. But yeah, Akshay I do have some thoughts on this.

Akshay: I mean, right off the bat, I very much want to discourage using GitHub. I, I know that's not viable for everybody, but I, I personally used to always, uh, mirror my, uh, sort of see Git repositories on GitHub for just sort of the, the requests and contributions and issues and stuff. Um, but, you know, if I had a choice, I would say no. But, um. So the, the, the thing we have on our side is the fact that gift repositories are quite easy to. To mirror, uh, fundamentally they're quite easy to, so let's say you had, uh, an Instagram account and you wanted to sort of leave Instagram and go somewhere else, it's quite hard to, you know, bring all of that, bring your posts and your stories and what else get Instagram has, uh, to your new platform.

Uh, but, but quite easy to move around, quite easy to mirror. So the, there's not much platform stickiness there, so to speak. what people are going to miss are things like existing open pull requests, um, and things issues, now with GitHub discussions, you know, existing discussions, if you have all of that. and there, there are ways to sort of import this, but then there's the question of, you know, like, will the users on GitHub continue to sort of contribute? Sort of con continue like a discussion here or, you know, continue on an issue here. and I guess that's the sort of difficult question, right? Do we like mirror the discussion with GitHub or do we, like, what do we do? and I'd say, I'd say, I think, I think I'd sort of expect, I think I, I think, I think fundamentally the code code is the easy one to. To copy around rest is quite flat. You, you're not gonna have your GitHub stars untangled, unfortunately.

Justin: Yeah. I do think there's an opportunity for you to define that user experience, though. So I mean it, GitHub is for better or worse, just like this massive ecosystem and you can sort of okay, if you want to sync a tangled. Uh, repo to GitHub. You can just like do this and we'll set it up automatically for you and then maybe you can say, oh, we'll automatically turn off prs and issues for you and we'll like add an extra link in the readme and an extra thing in the description and like set up all the information that people need to know about, like how to contribute to this thing where they don't really have to think about it.

They just like. I a button and it shows up and you know, then that could just be an extra marketing channel for Tangled as well. You know, it's like

Anirudh: that's also important 'cause it's like another end. I think

it is something to do thoughtfully, but I feel like. It definitely, I've thought about times of like, yeah, I would like to be able to, to move a little bit more away from GitHub, but there are things like, you know, people come on GitHub to like a library and it's like, I would still like to be showing up for that library search, you know, even if like, this isn't the sort of primary mechanism of interaction that I would like to encourage.

Justin: So, um, be really interested to see what y'all come up with there.

Akshay: yeah, for sure. Uh, I definitely think, definitely think sort of reducing the friction here. mean, I, I still haven't moved my repository, so I'm GitHub de tangled. Uh, and because it's like, it's, it's hard. You, like, you have to go to each repository, cl it local and then push it detangled. Uh, but what if I just add a button to, you know, and then one shot, I just have everything working here. Um, that'll be, that'll be really cool. For sure. Um, and now I have personal motive to do this also.

Anirudh: Yeah, that's true. That's true. We actually had someone ask us about, uh, If they wrote a script to just clone all their repositories onto their knot server and the knot was then able to sync it back to the app view. And then we have everything populated. Uh, that's currently not possible to do because knots aren't able to write to your PDS, which means we cannot sync. way, but of course with the whole, uh, did web of Knots idea that we thought of this would be enabled. So that would be super seamless. So you could just like write a, like, we could even like give your first party script that you could just run on your server and it clones all your GitHub repositories and everything is populated and you know, Bob's your uncle.

But, uh, we we're still a little ways away from doing that.

Andrew: Cool.

[00:51:06] Future of Decentralized Coding

Andrew: So wrapping up here, we always like to ask a future facing question for you guys. I wanna ask, what is your ideal future for decentralized coating? What, what does it look like? What, what? What's the, what's the dream? The pie in the sky.

Anirudh: Oh yeah. I mean, I mean, the way we see it, we, we want this to be like this sort of, I. Of, you know, federation of, uh, you know, Git repositories and yeah, even like smaller communities running their own little not servers and collaborating and, uh, you know, having it such that it, it's still like open and, you know, viable for anyone else from outside of that to be able to send a patch in. And, um, yeah, that's, that's sort of how we see it. And, uh, um, yeah, I don't know.

Akshay: I think for me, the first thing I, I noticed when I joined Blue Sky is. Sort of seamless seamlessness, right? So there's all these users on different PDSs, but still I'm able to sort of see all replies and see all of these posts and be able to search. And that it's decentralized is not really visible.

Um, and that's something I want to, I want to want for tangle to sort of get to that stage where, um, you know, if there's an error setting up a repository here, it does not leave. Some broken state there. Um, you're able to sort of like search globally across all knots. You have, you know, like code navigation.

You have these like, cool features that you'd sort of expect from being able to, uh, centralize things. But, you know, but underlying like below the, under the hood, everything is decentralized. that's what I want to see. Like I want to see a decentralized network that does not look like a decentralized network from outside. It doesn't have those ugly words that, uh, you usually see.

Anirudh: Yeah, a hundred percent.

Andrew: Well, it's a, a lofty goal. I, uh, I wish you guys luck on your endeavor to factor the code out of GitHub. Uh, big challenge there. Thanks for coming on and talking about it. This was a fun conversation.

Anirudh: Yeah for having us

Akshay: Yeah, this is, this is awesome. And also like. Props on the, the pull request model. I think this is gonna inspire a lot of people, I hope, and I'm excited to, to work more with it. So thank you. Coming on.

Anirudh: yeah. Yeah. Thanks.

Akshay: Cool. ​