Episode 367 - Local-First with grjte and Goblin Oats

Transcript

[Music] Welcome to Zero Knowledge. I'm your host, Anna Rose. In this podcast, we will be exploring the latest in zero knowledge research and the decentralized web, as well as new paradigms that promise to change the way we interact and transact online. [Music] This week, Nico and I chat with Goblin Oats from Tonk and Gersta from Bane Capital Crypto. Together, they introduce us to the concepts of local first and cloud optional architecture. We learn about the goals of local first, why each of them independently became interested in it, and what it offers the end user.

Local first brings the locus of control closer to the end user by providing new frameworks for conflict resolution and data integrity in more decentralized peer-to-peer setups. With these setups, users can own their data, can work on it offline without relying on a connection to a cloud provider, and control when and how their data is being shared. Goblin Oats shares the evolution of the Tonk project from an experimental lab to a product in the local first ecosystem. Gersa shares her explorations into local first as well with her ground mist project and where she sees the space evolving. Both identified some of the parallels with the blockchain space and how advanced cryptography like ZKPs can help bring even more richness to this ecosystem. This is the first time we

dive into the topic on the show and it was really fun to explore. Let me know if you like it. I'm thinking of doing more episodes in this direction. Now before we kick off, I just want to point you towards the ZK jobs board. There you can find job postings from top teams working in ZK. And if you're a team looking to hire, you can also post your job there today. We've heard great things from teams who found their perfect hire through this platform, and we hope it can help you as well. Find out more over at jobsboard.zonowledge.fm. You can find this on our website and have added it to the show notes. Now, here's our introduction to local first, the Goblin Oats and Gersa.

[Music] Today, Nico and I are here with Goblin Oats from Tonk and Bane Capital Crypto researcher and ZK hack alumni, Gersa. Hey all, welcome to the show. Hey. Hi. Hey, Nico. Hey. Super happy to be here, especially with these guests, uh, who I've known for a long time, worked with for a while. Uh, so really happy to have everyone on the show for once. Cool. So today's episode, I think what we're going to be talking a lot about is this concept of local first, but just a little history on sort of how this episode came together. Originally, it was out of a curiosity for this project called Tonk. So I want to sort of start there. Goblin Oats, this is your

project. Can you tell us a little bit about what Tonk is, what it was? I feel like when we started working on putting this episode together a few months ago, like since then it's I think Tonk has potentially changed. So yeah, tell us a little bit about what this is. Yeah, sure. Um happy happy to get into the details and by the way, super excited to be on the podcast. Um ZK podcast I think has just like accelerated the space so much and was really impactful on my journey. So, uh, with Tonk, I actually met my co-founder, who's Harry, at an incubator called Entrepreneur First, and he told me about ZK.

He was like, "You got to check out this thing. It's ZK." And I was like, "Whoa." I read I think I tried to read the Plonc paper immediately without knowing anything about cryptography. And I was like, "This is amazing." Um, and the ZK podcast was one of the first things that I that I jumped into. Uh so yeah I I suppose I'll start like I'll go in chronological order um and just kind of say that when we first started we were really operating more like a labs. So the big mission of Tonk is we believe a lot in data sovereignty.

We want to see a certain agency on the internet in the same way that I don't live my entire life in a mall. I don't also want to live my digital life in Google servers. And and I think also we see commercial friction there. So Harry previously when he was at Epic Games was working on this parent list like a master parent list which is very bizarre like surveillance capitalism coded but is a kind of necessary thing for child safety when you need to get this list of actual parents. all parents. Yeah.

Human beings, not just the parent relationship in a graph or something. It's like if you're, you know, if you're a child, you need to know who that child's parent is and you need to be able to send an email to the parent and say, "Hey, you know, is it okay if your child does this thing or is like using a credit card?" And that makes sense, right? Like you want supervision. You want parents to be able to have a say in what's happening like online with their children. But the only mechanism that exists to enforce this is that companies like Epic Games and other you know large platforms essentially crawl the entire social graph of the world and filter it into a massive database of all parents.

So it's it's weird and I think Harry was you know he was working on this and he was thinking there has to be a better way like there just has to be a better way to do this and that's really like where that's how Tonk started okay essentially. So, I think it's like me getting um nerd sniped on CK, but I mean I do have like a background um with doing like funny things. I was, you know, in the Bay Area I was working on this like art collective thing which was very sort of open and free and people would come and do tools and I like that idea of autonomy and agency. So, so that's kind of the mission and where we're coming from with Tonk. Um but how we operated up to this point maybe I would say like maybe a year ago was

really as a labs. So we were thinking how do we even begin to tackle this problem? The idea was oh well there's this really cool thing called blockchain games and blockchain games need hidden information and hidden information requires all of this novel cryptography on the blockchain and that's the perfect place to incubate. we'll generate a ton of really good ideas. We'll generate tooling. Um, so we worked on stuff. We worked on like uh a ZKVM for Nintendo uh called DappyCom. We had this like ZK state channel uh that we did as like a ETH global hackathon. One of like the first ZK state channels. I didn't even know what a ZK state channel was. Uh but

we made it. What year is this? 20 2023. I I I think I didn't know what was going on, but I maybe a couple months ago or after we had made the thing, I read about this thing called ZKD channels and I was like, "There it is. That's what that thing is that we made." And it was it was just like you would battle back and forth with a server like a Pokemon match and then it would settle onto the chain, but everything was enforced using ZK and shared randomness. And then I got interested in this problem of interoperability and making like a general dev framework for hidden information. That was something called Gree. And then about that time I think is when we started to think okay the blockchain games thing is mostly useful for gambling and we kind of want to go

in more in a product direction. So no shade to people who are building blockchain games. Like there's there's a there's a long arc I would say like a like a really cool vision for for fully onchain games creating almost like a metaverse concept. There's people working on this. Um, it's really really cool. But like the product sort of the product traction today is pseudo gambling. So you're you're like putting tokens in and then you're getting tokens out uh but with just extra steps. So it has like this slot machine characteristic to it. You don't need hidden information for that. So it wasn't really like a good place for us to actually incubate the technology. So we elevated to the social layer and we thought that oh okay well people are

kind of doing these interesting games in blockchains maybe they want to share like asymmetric information and that was how this project called speak easy was born. So speak easy we worked on for maybe four to six months and a pretty tight internal prototyping labs like iteration. The way to think about speak easy at the end of the day is it's like an infinite canvas whiteboard where you can drop text and images and information that might be kind of sensitive and the only people who can see it are people who are bounded by verifiable behavior online kind of like digital identity.

So it's sort of gated by some kind of ZKP of some form of identity or some form of reputation. Right. So you were telling me Nico about ZK creds and ZK creds definitely was always in my mind while I was thinking about this. Um also I think um Semaphore uh trust infrastructure was like a part of that. So I don't know if you want that was like an era where a lot of the folks in in trust infrastructure and that whole meme were really thinking about how do you trust people online and the idea is well you know I may want to have a really tight inner circle of people who I know are cool like you think about like AI researchers able to talk about AI

research without being bombarded by like PR people and hype people just having a space where the only way to get into that space is by being verifiably an AI researcher. This kind of happens, but it's enforced by gatekeepers. So that was like the big speak easy product which then kind of takes us into where we are today. So when we were building speak easy, we actually used a local first architecture to build that product. And as we were building it, I started to realize that a lot of the primitives that are used in local first actually ergonomically are like quite well suited to verifiable data objects.

And there's all of this opportunity for programmable cryptography. And I thought, wow, this is this is getting where we want to go where we want to play with social information online. I want to do things like with my family. I want to I want to have that kind of liber liberated feel online where I have full agency and autonomy over my data any kind of data not just financial data right which is like mostly where the blockchain kind of drops off uh and yeah and we have a product that you can use today we're building very openly in in in the public very cool I want to say hi to you and welcome you back to the show you have been on long long ago in the first CK hack online

event. You were one of the winners of the writeups and I remember your story was so cool because it was like from zero to one in a way through ZK hack and doing these puzzles and then all the way to getting a job in ZK and now being and then being a like top researcher in ZK. So yeah, welcome back. How are you? Thank you. Good. Great. Yeah, it's great to be back. I um from my time then I went to work at Miden uh when it was Polygon Maiden before it spun out. So I was the engineering lead there um did a lot of work on building the VM with Bobin and then um just sort of towards the beginning of the rollup starting to

happen and then I transitioned from there to Geometry Research which then joined Bang Capital Crypto. Now I'm working as a researcher following a different sort of a different thread than working on a on a product. But my latest exploration was a project around local first called ground miss and it actually didn't have any cryptography in it at all. But the through line I think between these has been really a focus on like personal agency and control over data. Yeah. And that was very true looking at building a ZK VM to do client side proving uh and all the privacy aspects of that now through to the way that I was thinking about things in this project groundmist and now wanting to come to a place where they start to come

together these new patterns that are more provide more sovereignty for data with the local first patterns and then cryptography which has all of these schemes and protocols built in for the same purpose and seeing them come together. Amazing. That's where I am now. What's the connection between Tonk and your work? Do you end up collaborating? I think the biggest connection is that Goblin and I keep going in circles kind of around each other. Like we won't talk for a little while and then we'll suddenly realize we've just done the same thing during the time when we weren't talking.

Wa. Um, so the most recent realization of this I think was sometime in February or March where it turned out that we had both built a personal sync server for automerge for kind of different reasons. Mine was as part of this grandma's project, theirs was as the beginnings of the new Tonk product. And after chatting about it, we were sort of like, should we maybe sync up a little bit more often? um because it's actually been a few years that we've been thinking about very similar things and sort of coming in and out of of conversations around it. And I think we both seem to be very drawn to to both the programmable cryptography and the local first stuff because of this idea of agency and control over your own

data and being able to have sovereignty and privacy. I feel like we've said local first many times, but we haven't yet explained really like what it is. Uh but before we get there, I just wanted to mention one quick anecdote because Gerster, we did say that you're a ZK hack alumni, but actually so are Tonk. Oh yeah, you guys participated in the first IRL ZK hack. And I think actually the chewing glass prize sort of came from trying to compare the project they were doing to other projects and like well it's hard what they did. They really were chewing glass and you know it's hard to compare this to like full applications and so that's where the category prompted the chewing glass category creation. It's amazing actually Tonk hacked on Miden at that CK

hack. I know. I didn't even realize that. So cool. Was that the Lisbon one? That was Lisbon. Yeah. Wow. All the way back. Very nice. So yeah, just a fun little anecdote tying everything together. Yeah. Just going back to what you were saying about the autonomy agency. It's interesting because I feel like through programmable cryptography ZK, we ended up talking a lot about privacy, but privacy obviously has it means different things to different people. I feel like the definition that you're describing or like the thing that attracted you, I feel like that it feels more alive. It feels more empowered. It feels less about hiding. It it's a it has something there's something more positive in a way

like I I just like it's it feels like it expands a little bit the goal of what a lot of this stuff is for in in a in a way that I like. So yeah, I just wanted to to highlight that. I used to think um that it was privacy that I really cared about. And then the more I thought about it, the more I realized that it's being able to like have selective control over which parts of my data I use when. And that's something that's bigger than just privacy. and it's something that can happen that can be related to data that's shared with other people or data that's fully public or data that's fully private and mine I maybe want to combine private data that comes from different places in a way that's easy and that control can be restricted too even while

having privacy so I do think that it's bigger than just privacy cool I mean even having access to the data in the first place is like something that we don't always see in the current way the web is we don't own it yeah so I Guess it's time now to like define local first and sort of explain what it is and why does it tie in with these sovereignty ideas, right? Yeah. Is it a movement? Is it like a team conference? What is it? It's sort of a movement. It's it's a like an architectural pattern is the way that I think about it. It comes originally from this essay that was put out by people at Incan Switch um including Martin Kleman and Peter Van Hardenberg about building local first software and they had actually a set of

seven principles that they laid out. One of which is your data should just always be at your fingertips. So you basically have zero latency. Your data lives on your device. Um you don't have to wait to sync to the cloud. That also means that you can do things offline. So it solves the airplane problem or the the train problem if you you know live near London and are always going on the tube and everything cuts out. You can always do what you want. Yes. Right. You don't have to decide to pull it offline beforehand like you do with Google Docs. It just works.

But you also don't lose the benefits of using the cloud. So you can still collaborate with other people in a way that's just seamless and just works. So local first, cloud second, I guess, rather than cloud first and local after, right? Yeah, they say um you own your data in spite of the cloud, I think is how they sort of subtitle the essay. So it doesn't it doesn't go away, but it's no longer the priority. The priority is like the user having ownership and control over their data. And they had a final piece that was about they called it the long now, which is even when the wonderful journey of the software application ends and it becomes defunct, you can still use your data. you can

still continue using that software. So back when we had desktop applications and I mean we still have them but but back in the 90s earlier before the big the big boom of all the software being in the cloud you could in theory just keep running these things in an emulator forever and so you can then keep using your data forever and now we sort of have this era where you actually can't really as a company shuts down and even your data is just not that useful anymore. So local first is is about tackling a lot of these things. I I I will say that local first does have an ideological thread through it. Sort of anecdotally, I've noticed a lot of people either come from blockchain or come from Dweb. So both are in my opinion quite ideological projects.

It's funny because I I don't know what the exact dates are for when things move to the cloud. I was like very resistant for example like MP3s and I was I was you know raised on the internet during the downloading era. So owning your MP3s that were ripped off, right? Like legally downloaded, but like owning them mattered. And I remember Spotify or like streaming Apple Music, all this stuff coming out and just being like, "No, no, no, I refuse. I refused for a long time." Because I just had this sense of like, "No, I want to keep it." But eventually, you know, the market sold it to me. The things I, you know, really wanted to access and they were only available to stream. Maybe Spotify, maybe YouTube, like obscure music was no

longer on the Napster. I mean, those were all gone basically. So, I just wonder like why did we all move? Didn't we move because it was more efficient? You could collaborate? I guess you could share easier like Yeah. What was the reason we switched that way in the first place? It has to do with I think the physics of the architecture. So, the way the web was constructed, I I think about it in like layers. So you have layer maybe the the base layer of the internet where you have uh HTTP protocol and all these different protocols where it was quite free for people to connect with each other.

Then in order to get sort of web two functionality where you have this right feature you have there there was really no way for that to be done at the time without bringing everybody into a server. So, there's like this meme where um a little cartoon man is at a house and saying, "Hey, if we go into that big building, we can all like reach each other much easier." And so, then they all go into the building. And then the little man comes out and says, "Hey, I built something in my house. Can you let let's all take a look really quick?" But then like the giant building has like iron doors come down and like a sign being like, "Welcome to Facebook."

So it's be it almost started to mimic or it's like it made use of the structure of just the way the internet was built and like the ser the sort of server client model and was it sort of like because there was this focus on making certain parts more efficient like was it more was it faster? Was it more efficient? Did it like was there any sort of tangible benefit to the user that they noticed? I think one of the big keys here is the collaboration aspect. Okay. And this is part of why in the local first essay they say collaboration still has to be there because a lot of those other things were there before.

True. But if we were collaborating on a a writeup or an essay, I write it and then I send the file over to you and you update it and you rename it and send it back to me and I update it and rem rename it. We've all seen this where you've got like version two final final ready for publication. So once you are in the cloud, you can start actually sharing things in a way that's not so like brutal and hard to keep track of. Um you just share a link and everybody goes and does their edits and it's fine. And I think that's just one example of how centralized infrastructure um made things much easier. it was much easier for developers to build applications that

provided those sorts of experiences and we didn't have some of the technologies that could make those things easier without having the data all live in a central place. So um one of the key underlying technologies for local first are CRDTS that stands for conflictfree replicated data type and the paper for those I think those were first formalized in like 2011 um they're really new and that has opened up a lot of possibilities around local first interesting I mean this sounds really cool the idea that like okay the thing that we have been able to do in the cloud collaborate can now be done without somehow touching the cloud out or like having the data with us. But that idea of collaborating

with like I don't know three people in the same room kind of makes sense. But like how do you then start sharing data across huge distances without having that central server and like wouldn't you end up with like crazy version issues? This is like I you know I constantly like a Google doc like there you can kind of see and it's happening in real time but if you're like one to one yeah is it possible to keep sort of like that real timeness. This is the thing that's kind of magical about CRDTs is they are data structures that know how to merge themselves. So you have one version and I have a different version and whenever I get your version it knows how to merge any

changes and when you get my version your local data knows how to merge those changes is how the CRDT works and because of that I can just keep moving forward we have what's called eventual consistency. So over time we will get to the same place and it's guaranteed that we will get to the same place. So your data will never be in conflict with the sort of real canonical version. It just might be out of date. And same thing on my side. But what if you're like deleting huge passages? Like what if you're just like you take a big chunk out. Does that update on your side as deleted? Does it update as conflict because you haven't deleted it? I know it's very specific example but No, it's No, it's a good example. So the way that these things work, you have two

types of CRDTS really. You've got statebased, which is like the the best example of state based is a counter. So I'm just counting 1 2 3 4 and you're counting and I'll send my counter value to you and like we're trying to keep a global counter between us um of every time we do something. I send my value to you and you're going to take the maximum of my value and your value and add one and you send it back to me and I do the same thing. And so we'll always either be in sync or you're behind, but we'll get to the same place that way. And that's an example of a state-based CRDT.

You can also have op-based CRDTs where you just send operations over. So I'll say I added a character, I removed a character, I added five characters, I removed a different character. All of those operations go over to you. And then the way that you think about it in terms of what's actually happening is we have a grow only set. So you have a set of operations and you're just always adding operations to it. And then you have to decide what order you apply those operations in. So on your side, you just have a bunch of operations and you're just going to apply them in the order that the CRDT tells you is the correct order to apply them in. And I'm doing the same thing. And the way that that order is determined is basically the rule of how the the mer the data gets merged. And so you would do

something like saying this operation depends on these previous two operations. If those haven't been merged in yet, this one can't go. Okay. Um, so that I think hopefully answers the question of how you can remove data and still reconcile everything. But what would it actually look like? Just going back to that example. So I delete a paragraph, we're working on the same document, but like I'm offline and then I go back online. You've potentially edited that paragraph. You didn't know that I was going to delete it. Like do you end up with a picture of both things and then we have to make a decision?

Um, we don't have to make a decision between us. the data can make the decision itself. However, one nice thing about CRDTS, I think Martin Kleman described them as version control for data objects is you can actually see the history. So if you wanted to look back at the history and make a dec different decision, you could do that. Okay. What would happen basically is if my edits are built off of a different previous operation than yours, yeah, one or the other might supersede and it would just merge that way. If we didn't like the way it happened, we could kind of rewind. You can think about about it as offering some form of like git version control that developers get over software, but for everything interesting.

I I think just to maybe help visualize it, it's a delete operation. So you just tag on the delete operation, but all operations have a causal history. So you would want your delete to obviously happen after the insert. that kind of because the the insert and the delete are causally they have a causal relationship. So that it kind of looks like this graph structure like branches almost like quantum physics each life is splitting and merging. I mean that's really this is a cool kind of just like how the collaborative tool works but how does the connection work?

Like are you still using a cloud server somewhere? like is there still is it just sort of like you keep it but you're constantly sending the full thing somewhere that's being combined or is it direct to the other user? I mean that's where things get really interesting because you say oh wow we have this CRDT object it has these properties there's cryptography involved actually like hashing in in production or like more modern CRDT systems but then you build these things around it that allow them to connect to each other and form almost like a protocol.

So you have nodes like a sync node where all of the state lives and helps to relay between different peers and help peers discover each other. And then you have the peers are running maybe clients like on a web browser or something. And all of a sudden you start to get back into like hey I've seen this before. This looks kind of familiar. This is interesting. Interesting. Yeah. So how do we avoid this sync node becoming sort of a server? Well you don't is the point. The whole idea with the local first thing is you have your data, you have agency, but we don't have to give up the cloud. It's fine to use the cloud. There are lots of benefits to it as long as you don't lose out on having your data because of the cloud. So you think of the sync server

as being an always online peer. So we're all peers. The sync server is the always online pier. I sync to there when I'm on my laptop. When I'm on my phone, it updates from there. And if if you want to do it without that, you can. But we're not specifically trying to avoid that. We're trying to avoid lock in. Yeah. Yeah. You have credible exit from the system because the data lives locally on your device. I see. And newer systems now involve encryption. So the zinc node actually doesn't even have visibility into the data. It just acts like a dumb operator. It's just moving blocks between each other. So everything is fully shielded.

Who runs the node? Who who's hosting that? Tonk. Tonk. Only Tonk. Tonk hosts all the nodes. All the sync nodes. not centralized. It's all talk just like I said all the way down. No, I I mean there's this is where Gersa's noticed so many overlaps between the blockchain space and what's happening how local first is evolving because I mean you have like node operators sync node operators and lots of different companies are building sync technology. So Tonk is one of them. We're building a kind of design but we're doing that in tandem with other partners. Um so automerge has its own technology and automerge is the the library that's uh

maintained by ink and switch who kind of started the whole local first stuff. There's others as well. So so automerge is a library for these crdts and running sync nodes. Is that correct? Yeah. Okay cool. We're building this in tandem with other people. There's an ecosystem. There's a lot of different technologies. I think it's pretty early days. So maybe the if I were to use a metaphor, it's like everyone's building their own L1 right now. That era 2017. Yeah. One of the things that I specifically explored when my with my recent project ground me was looking at this um idea that with sync servers, every application is sort of picking its own specific sync server. You maybe pick

a sync engine provider to do it for you, but then you just sync all the data for your application through it. M and I was thinking well then you have the data it's sort of local but actually if it's in the browser then you can't use it in other places so you still don't get interoperability over your own data and I flipped it and said what if you do a personal sync server and all of the data that you have access to syncs through a sync server that only you can access um as opposed to the application managing the sync server. And this is the thing that Goblin had independently done at nearly the same time with Tonk that they were exploring. So I think there's there are those sort of two patterns that you could think can think about.

There's also the idea that you have a sync server that lots of applications fire lots of data through and it just doesn't matter. So it hasn't really been settled yet. People are figuring out how to do the sync efficiently and the question of who exactly it's going to be. I think the L1 analogy is really good for that. We just don't exactly know what people are going to settle on. Does the local first community are they thinking about how to incentivize sync node operators or is that like way too much blockchain thinking for that community at this point? Like I realize I'm I'm obviously coming from a perspective where that question comes up really quickly, but like it at the moment it sounds kind of altruistic. The

personal sync node makes total sense to just do it yourself. like that's like your own server. It's like you're running your own cloud. But if you are doing something more networky and there's external people doing it like is that part of the conversation? No, people will. There are companies that provide sync services and an application developer will just pick that and you basically instead of paying for some database backend or running a database yourself because it's a local first architecture and you don't need a database, what you need instead is sync. So you just pay for the sync service. So that is currently the way that most things go and it's not you're not trying to incentivize any sort of greater collaborative thing.

You've mentioned previously interoperability and like this notion of should I have a personal server that all my apps use or a per app server that will then I guess break my data into apps. Are those the only two solutions or is there sort of a a spectrum there a kind of trade-off landscape that we can explore? I have thought about this quite a bit because one of my conclusions after doing this personal sync server as part of my explorations is that it's not really practical. It's a hard thing to bootstrap. You have to get every application to buy in to sending the data to the sync servers. You have to get all the people to set up their own sync server or you have to have something that provides these. It's hard to think about doing that in a a general way that lots of applications buy in on.

It makes more sense. it it's probably worth having Goblin talk about their approach after. But my takeaway was sort of like this is not an easy part of the movement to push. It's like a little bit upstream um against the grain. It makes more sense to think about the generalized sync model or even as specific. So then you still have this idea that you should be able to have all the data on your device on all of your devices. And the next thing I've thought about from there is you probably want some layer that you could have on your device that gives you a way to bring this data back together. So it would be a more local interoperability layer. There were a few talks about this at the recent local first conference. A few people are thinking about this

interoperability issue and recognizing that it is not solved. Um the full sort of vision of agency and control over data is not there yet because of this. One person proposed that all applications should let you export your data to very standard formats um like markdown or they're working on a new open canvas standard the people should use or things that are just very lindy so that you can always use it somewhere else. So that's one approach. Interesting. How technical like today and what you've described at what stage is it? Is it at a stage that people are already experimenting with it or is it just theoretical? Is it like ideas of how to do it or are people doing it?

No, people are doing it. How technical do you have to be to participate at this point? You don't have I mean you have to if if you build applications like you you need to or or start vibe coding things but in order to use the technologies you they're there. They're ready. There are libraries. Oh nice. But you have to be a dev. It's not end user yet. It's not like Google user wants to coordinate on a on a doc. Yeah. I think this is a perfect handoff to talk. Yeah. Yeah, Ton Tonk now allows anybody to participate in the joys of local first devs.

Cool. And I I mean that Yeah, I guess this is a good segue into into what we're building. The basic pitch for the product that Tonk has is you can build your own personalized software that's useful to you. Like anybody can do that now. And uh dashboards, CRM, fun little games for you and your friends. And uh the reason why you can do that partially is that with this sync engine architecture because you don't have to care about it. You don't have to look at it. You don't have to deal anything. You just send the data into the cood object locally and then it's magically synced and and collaboration and everything kind of moves around. It's that's all taken care of by tonk services, right?

All you have to do is think about the application logic. And guess what? There is these things called coding agents now and they're really good at uh handling application logic and so you can build local first apps with with English with just natural language now. Cool. Is that the product that you had hinted at earlier? Yeah. Yeah. Yeah. That that's what that's what we're doing. G mentioned that Tong has an interesting approach to interoperability between apps that are like sort of living between different personal sync servers. Can you tell us more about it? Yeah. So I mean the architecture is still pretty early and obviously we're just building this stuff as we go. So it's all very like alpha alpha build level. But I mean the TLDDR is that we want this

interoperable data nirvana. Data goes wherever it needs to go um for humans and for agents and that's awesome. Uh and the application layer is something that kind of becomes hallucinated. It's very malleable. It's ephemeral. it's on the fly. And so the way we think about a lot of interoperability is that you have data living in all of these different places and it kind of combines together on the moment just in time to create a kind of application experience. Are you bringing though then LLM stuff into the way that data structure is like working or is this more like you build an application that just taps into the that local first architecture? I'm like

I'm just trying to picture like is an AI for example like collating a collaboration together somehow? Is it making any of those decisions? It's such a good question because I kind of think that in not so long future the agents are going to be all over the place like there's not going to be any area of the stack where there's not some kind of agentic behavior. And when you're thinking about the data structure level um there is this like schema problem. uh how do you translate between different schemas? How do you recognize that maybe this is a phone number underscore this is a phone number camel case you know different representations of what these fields or what this data

means but it's fundamentally the same data lms could be useful there so it's not in the product as it stands but the the way the product is is really just like helps you vibe code how does the product integrate with existing AI tools and existing like AI interoperability tools so we just make it really easy for vibe coding agents to understand our stack by giving them a lot of instructions. We've written like a big old manual in robot speak and then when you ask the agent to do something it just knows uh it reads the whole project. It knows how to use all of our different tools. So you can just talk to the agent and it will figure it out for you.

Um in the interoperability layer I think that's more experimental. So different applications can look at the same data, right? So I can we've done a lot of experiments with oh you know I have maybe tonk documents and I want to surface those talk documents just in a kind of typical notion doc or obsidian doc view but then I also want like a chatgpbt view into the tonk documents where it's ragged and I can I can query them or maybe I want to have like a dashboard view which is only pulling some subset of the tonk documents which have more structured data inside of them. So that's how interoperability works currently. Doing something between different groups of people. So if I

wanted to collaborate with Gersa or collaborate with ZK hack, I think that's really cool and really exciting, but we just don't really know how to do it at the moment yet. The project that you worked on, Gersa, the ground mist, um, you had just talked about it. you kind of introduced what the focus was, but like was any of that used then in Tonk or has it sort of was it sort of like you did an exploration but found that to set it up this way didn't seem like it would be feasible on a large scale? Yeah. So the project was a series of kind of three experiments all around this idea of being able to have my own data link for my personal data or or not just personal but data I

have access to that I could always interoperate over and having that move smoothly between private, public or shared. So if you think about something like Obsidian, you have lots of local documents. If you want to publish them, if you use Obsidian's publish, it it sort of wraps everything up and provides you with a website that you publish on GitHub pages. And now you've got some of your data that is public, some subset, you were able to make it public, but it's just in its own little walled spot where it's public and you can't mix that public data with other public data that you have very easily. And so I experimented with combining local first with um the at protocol because they have this idea of personal data stores

and so you could have your public data be there where it's all just the data. It's very interoperable. And I was looking at how you could move between these spaces of this global uh public data that's yours and your private local first public data that's yours. So that was one of the explorations was trying to do that. And then I was thinking about how you could enable interoperability over all of these different data sets by defining schemas. So I looked at the schema problem and said you could use at proto's system to define schemas using their schema network and all those schemas could be public but the data could still be private. And so you could use this public global skebo network um that they call lexicon for local first data that

stays local first and then your stuff could be published and move public and it would be very smooth or it could stay local but you'd know how to understand it from other applications and then I said okay now you can understand it from all these different applications but you still have to be able to access it in order to access it where do you go for it and that's where I brought in this personal sync server. Yeah. So it was sort of a progressive exploration of how you could build this interoperable data lake trying to not build a new protocol to do that. Trying to do very small things that I could make into like a React library that somebody could use just an SDK that people could use.

So that's really what the project was about. Can you give us a quick one sentence intro to what approto is? Yeah, exactly. I was thinking that too. We should definitely define it. That's never been talked about on the show before. So it would be cool to introduce. Great. Yeah. Um, app prito is the protocol that underlies blue sky. It's a global protocol forworked public data. Uh, it's built around everybody having their own personal data store that contains data repos. So there's a canonical place where all of the data lives. When data changes happen, it's all signed with your key.

Everybody has a key pair. And so you have verifiable interoperable global data in a network that you can build social applications on top of. And one of the really cool things is that you can build lots of different views over the data because the way that you interact with the data is not defined by the data that's stored. That's just raw data. And so the way that you want to look at it or show it or combine it with other data sets is not predefined for you. It it makes it very flexible. Hm. There's a an interesting parallel there, right, between the the sort of long now idea of local first of like the data should always exist locally and you should always be able to use it and the different ways of displaying the same

data in app proto almost like a aworked long now at proto. I guess that's pretty cool. Yeah, I think I felt like there were a lot of things that were very shared between these two worlds and the main thing that wasn't shared is the public nature of everything on the app protocol, right? The work from that work though, like cuz you kind of describe these steps in what you described goblin notes, the tonk project, like what parts is it touching on from there? Like is there kind of a point where there's a merging of some of that work into what exists today as that product or is it was it more like a independent project and then you guys just like found out you were thinking

about the same things? Yeah, literally the second thing. Okay. The second thing. Okay. Okay. So in Tonk does it also touch app protocol? Does it like explore that? No. No. At the moment it's more self-contained but it's something that we're definitely thinking about. I think there's this language you have small world big world app proto is kind of big world personal server local first stuff is kind of small world how do those two connect to each other actually that gets into some of the interesting stuff around zk and the more advanced cryptography about how you can connect these two things together so maybe that's a nice segue into the into that as well yeah this is something I wanted to bring

up because in conversation with actually both of you individually uh you've both told me like there's this local first thing, there's all this cryptography thing and there has to be some overlap and I can feel that it's there and I really want to flesh it out and make people see that there's something there. So, has that changed? Do you guys now like see what it is and have a quick pitch for it? Yeah. So, I think one way that you can think about this is in terms of maturation of the space and of the architecture. I was talking to Brooklyn Zelica who does a lot of work on access control and authorization. and she built this great or she's actively working on this great project called Keyhive which is originally going to be tied to automerge for authorization but well

they're building it so it won't be specifically tied to any um CRDT library it will be it will go at a lower layer but it will work with automerge and she was saying that local first is really having its shift from the surprise party level of uh adversarial environment to corporate espionage that's sort of where it's at right now I'm not sure I understand that shift What do both of those mean? Okay, so yeah, I guess the surprise party is just like it's Anna's birthday, we're going to throw a party. Like we hope she doesn't find out, but if she does, it's not like a huge deal. The corporate espionage is like, okay, my lawyer is talking to your lawyer. We're coming to a deal. And like if you find out some of our information, we lose a lot of money. Um,

no one dies. No one dies, right? But it's but it's not great. Yeah, you know, I'd be embarrassed or or Nico would be embarrassed because clearly I'd be the one discovering his secret. I see. So that's kind of that's kind of one way to think about these things and that's reflected in the progress of access control and the way that people are looking at exploring sync over end to end encrypted data. I think another thing um that I think about in the way that blockchain has shifted and the way that this has shifted now is that originally with blockchain you had all nodes have all the same data and execute the same thing every time and then we have this shift to well actually like let's do a zk proof and everybody else can just verify things and we don't have to put all the data on chain and we

don't have to have all of this re-execution and in local first you can think about cases where currently in these opbased CRDts that I talked about I send all the ops that I do, Anna, you send all the ops that you do and I apply every op and we later invite Nico to our document and he gets the entire history of all the ops and he he replays them one by one to get up to where the document is. There's a lot of inefficiency there and for Nico maybe first of all maybe we don't want him to see the history. Maybe we just want him to pick up from we've got a nice dock now and we don't want to see earlier changes.

Um so that would be nice to hide that. Second of all, maybe he doesn't want to see all the history. Like actually, he's just reading the latest messages in a chat. He doesn't need all of it. He just wants to start from a snapshot that's verifiable and then continue forward. So there's this parallel of this stuff is not is not there yet. Um and it would be really great to have that. And so that's one sort of example where you could see all of the ZK work that we've done um would be really useful over here in this space as well. I'm sure Goblin has more examples as well. Yeah. Well, I I mean I think I felt like really struck by lightning when you had told me, "Hey, wait a second. We could just use blockchain metaphors for everything." I don't know why I missed

that, but but it's you really see it everywhere. And I think it's it's scaling problems. So ZK and a lot of this cryptography is used to scale blockchains and you can think about it in the same way. So history compaction is a good example of of scaling because for certain types of data in particular, the history can get really big really fast and you're going to want to maybe have an archive node but then compact that for a lot of other people who don't need to necessarily see the entire history. And then the other thing is is adversarial environments. So, uh, I mentioned a little bit about, oh, it'd be really cool if we could all share our data and kind of have this collective CRDT, but you know, maybe I want to

share with somebody. I, you know, I don't know everything about them. I don't know what they're going to do. So, I I I only kind of partially trust them. And these like semi-rusted environments are pretty common. Uh, and it's an area where CRDs struggle because uh, you know, they can be abused in different ways. So even if you have let's say hashing and you can check the entire chain of history. Oh yeah, this looks right. You can't check data in inside of that. So I could zero out the account balance or something. And here that's where you kind of get into oh data validation. That's interesting. Oh, how do we do that? Oh, okay. Proof of valid state transition. Hey, that sounds familiar.

Yeah, interesting. So you're using though in this case like the ZK side of things for mostly like ver verification of state. It's like it's a sort of proving proving a truth. Not you're not using it for any sort of privacy like add-on, are you? Or is there like is there a way that you're also exploring it for privacy? I maybe have forgotten there's a more there's so much really it's just like it's everywhere. It's really exciting. I think it great reminder because I'm sort of losing track of all of the it's just a giant pile of work. But I mean we were talking to Alex Good who's one of the core maintainers of automerge and was mentioning how in the sync service they encrypt these chunks now. So it's like okay this is good the data is encrypted

the sync server can't see it but however they do have to keep around metadata and there are some threeletter agencies that are pretty interested in metadata. In fact metadata is almost the most useful thing so you'd want to hide that. So, how do you sync? How do you how are you able to identify which encrypted chunks you need to pull down that yours that you have a valid key for? This is really common in a lot of these blockchains that work on shielding. Um, is a pretty common use case in in a lot of different uh private blockchain scenarios. So, so that's a private case.

And then also for reputation, I should say. So pulling in outside or external reputation and using it inside of a CRT system requires that you do some kind of reputation transfer. You may want to do that in a way with selective disclosure in particular when you're dealing with agents which kind of gets us into this weird even going further into the future. Right? Agents really need that quite bad because they're going out you know doing things on behalf of you and talking to other agents. they're kind of dumb. You don't want to give them access to all your information all the time. You just want to give it kind of like on a need to know basis. And so CK can be really powerful there as well if agents are

reading from these sync stores and and taking action. So it ties in like the whole ID case we've been covering actually for a while here. So interesting. I know. Is there any other types of like cool edge cryptography that's being explored as well? Yes, people a few people are starting to explore these things. So there are some papers about doing MPC with CRDTS and somebody actually just did a project exploring um homorphic encryption for a C CRDT and it's a really nice write up. His name was Jake Lazerof. Uh he basically was like I really thought that these would fit together well and actually it doesn't fit together well because for homorphic encryption you have to do the worst like the the worst case path and the overhead

is just absolutely enormous. I think the amount of time it took to do the sync was two million times as long as doing the sync without homorphic encryption. But you could think about maybe using it for some metadata instead of trying to use it for the entire CRDT. Um, and I also do think it's really interesting to think about these paths, especially maybe with NPC Goblin. You looked excited when Anna said that too. So maybe you have a different idea from what I said. You were the one who gave me the idea about Wi-Fi aware. You should talk about the Wi-Fi aware idea. It's so cool. I mean, it's more experimental, but it's a really cool idea, I think.

Yeah. I've I've been doing a lot of just like brainstorming what are sort of weird and out there things because just just to try to think in different ways. And Wi-Fi aware is this really cool change that happened. Well, there's there is a cool change that happened recently where the EU is forcing Apple to be able to connect directly to other devices, even if they're not Apple devices. So, currently you can airdrop between Apple devices, but not from Apple to Android. Mhm. But now actually they're going to have to do that. So Wi-Fi aware is the standard that Android devices have been using since like Android 8 for this. And now Apple in the next versions of iOS and iPad OS is going to be compatible with Wi-Fi. So now you could just

connect directly a whole bunch of devices in place. And the other thing about it is that these devices are still connected to the internet. So you can have your little local area network with all of your friends without any of them having to lose their main internet connection. It's high throughput. And then we were thinking, well, could you do some fun local first MPC thing with that? Thinking about some of the experiments that Cursive did around this kind of stuff and just feeling like there's some fun space for social applications around that. I haven't thought of a great one yet, so hopefully somebody will.

Cool. It sounds like the dream setup for MPC, right? cuz you have uh a local network that's super fast that's set up like almost instantly and you have just a few participants and private shared state like it sounds perfect for MPC. Yeah, 100%. Just going back to kind of how Yeah, I'd ask like how technical do you have to be to use it? Can one use it already? Is there a big difference when you're using these kind of new rail I guess sounds like new rails like a new architecture? Like is it slower now? Would they like when you're using a lot of this stuff, would a user notice any performance change?

So, yes, I think you would notice a performance change and what you would notice is that it's faster. Oh cool. Because local first really optimizes for low latency, as close to zero as possible. That's basically the whole point of having all of the data there. And so a really nice thing about this is that we've got this architecture that enables better user ownership, agency control, privacy, and the UX is better. So you don't have to try to sell people on privacy. You could just try to sell them on better UX. Um, nice. Which maybe that gives us a a better chance than we've had with some of these things in the past.

That's cool. I didn't expect that to be the answer. When you're combining it though, like if you were doing those like snapshots or snarks or anything like that, like I know these are these sound like they're still somewhat theoretical. They're those necess aren't necessarily in practice, but would those add any sort of slowness or are we at a point where this the snark creation is so good that we we got it? Yeah, they're not in practice yet because they're too slow. I think local first has really been focused on lots of people who know each other and trust each other collaborating and it's really great at that and it is not fully ready for more adversarial environments and local first thinks about in a browser on mobile as the fundamental thing that you

need to be able to support always. So that's really worst case for doing snarks and that's the next thing that we would need to try to tackle is doing that in a way that works well with CRDTS and sync engines. Cool. But we are getting there. There is work on that. So that's cool. Yeah, I think as the even as the tooling is getting better, there is lowhanging fruit. So the sync server itself might be able to do certain things if we're just thinking about metadata and doing like a oblivious transfer or something like that. Right there. I mean there are protocols that are pretty well worn that I think can already be brought in to local first. If I think about also ZKTLS or some of these like identity things

like that feels kind of ready to me honestly to be used because all you need to do is just bring in a credential once and then it's kind of ready to go. So cool. Nico, did you just get triggered by ZKTLS? No, that's all right. I can live with it. You're okay. Okay. Maybe I should Did I say I shouldn't have said PCT? It's just because there's it's not always ZK. I feel like people in that space have Yeah, I have to bring up a question which I'm kind of ashamed I'm bringing up, but when you're writing local first software as a developer, what is your path to monetization? Like I feel like we've seen you can pay to access content. You can pay for a subscription and you're locked into the subscription because you have platform lock in. What

happens when we go to local first and how do we reward good software being written? Yeah. Well, there's two answers to this. So, the first answer is maybe the old school answer, which is that you kind of use the same economic models that have been in software for a long time. You can even do subscriptionbased if you wanted, right? You you pay for subscriptions in iPhone applications. So, it's not like a totally wild concept that you tell people to give you a monthly fee to get the latest updates of your of the app or something like that, right? The other the kind of more new one is actually a vision that comes from someone called Maggie Appleton, which is about these like barefoot devs. It's the

one that I'm the most excited about, which is that it's so cheap to produce software and it's so cheap to host it that you can actually now have software applications in the wild that don't really need an economic model. So, you know, the one that I really want is family social media. I want like a chat group with my family, but that it's rich and it is more async. It has a feed. Not everyone wants this, but my family wants it. And I could build this for my family relatively quickly and we could all use it together. So you get this almost like what YouTube did for content vibe coding and these new rails will do for software.

Cool. So we're almost at time, but I'm really curious like what are the research areas, projects, directions that you're exploring now? Like what else is on the sort of local first road map? There are a couple of projects that I find really interesting and exciting and they're part of why in my ground mist project I chose to use automerge and those are keyhive which is an authorization an access control project for local first that uses capabilities based access control but applying it to the CRDT setting and then belay which sort of accompanies keyhive but it addresses the problem of now all your data is encrypted how do you sync it efficiently so it's looking at end to and encrypted sync. And I

think those are very interesting projects and there are a lot of problems that come up in those. They're trying to do something that's very ready now that can be used as soon as possible. But there are lots of ways that things could be optimized or for example the access control graph is public currently in this configuration and maybe you'd like to find a way to hide that. So I think there are lots of interesting cryptographic questions just around those two projects that I'm looking at more and I think it would be great if other people wanted to look at those too. Cool. Yeah, the projects are open. You can go in, you can put in issues and I know for a fact that the maintainers are very interested to explore these things. So definitely get stuck in.

Nice. What about you goblinotes? Any other areas that are peing your interest? Um, well, we're looking at a lot of agentic behavior. And I guess I'll just tease, you know, there's O problems with with agents, big O problems. And so that's something that we're going to be looking at quite a bit and maybe would make for its own episode even. Who knows? I mean, there's so much. It's a really rich space. We like on the show, Terrun and I had uh Custas from SUI and we talked about this concept of Zcat. So, ZK authentication and it's about access control. And it was funny because Terrun's line of questioning was all about like agents and access control.

And uh it hadn't been fully figured out yet, but it was it was very interesting to sort of I don't know sort of brainstorm what happens when you have all of these agents using things, agents like needing access, losing access. Yeah. Potentially having the ability to add access, like what tier. Yeah. There's a lot of of things to think about there. Yeah, super rich space. Access control has always been and I think will remain super messy like to to implement and to think about properly. And this is why like capabilities based models are interesting like Ga mentioned, but yeah, it's still super hard. It's a cool problem like it's a cool problem to get deep into.

Nice. All right. Thank you both for this great journey into a brand new space for us, at least for me on this show. uh the local first world the work you've been doing at Tonk and on ground mist and yeah Gersa we had a conversation what is it like four months ago and it was about sort of the the preliminaries of this work and it's been it's really cool to hear what you found I think it's such a cool space so yeah thanks so much thanks a lot it's really great to to be here on the podcast and to talk about this stuff and I hope people will get in touch if they're interested because I'd really love to see more people looking at these problems.

Yeah, thanks Anna. Yeah, 100% feel free to reach out. It's just goblin notes everywhere. So, pretty good SEO. Gisha everywhere. Very cool. Thanks, Nico. Thank you. And thank you in particular, Gersa, for a quote that I think I'll be reusing, which is, I thought I cared about privacy, but actually what I want is autonomy and agency. Cool. So, I want to say thank you to the podcast team, Rachel, Henrik, Tanya, and Kai, and to our listeners. Thanks for listening. [Music]