#16 – Anselm Eickhoff: Jazz

Imagine if you could mock up an app just based on React use state or like equivalent things, and you build your UI around that. but then magically your app actually works and like all of the status persistent and you can share it with other users and, you have permissions on there and you still only wrote front end code. That's kind of the Jazz story Welcome to the localfirst.fm podcast.

I'm your host, Johannes Schickling, and I'm a web developer, a startup founder, and love the craft of software engineering. For the past few years, I've been on a journey to build a modern, high quality music app using web technologies. And in doing so, I've been falling down the rabbit hole of local-first software. This podcast is your invitation to join me on that journey. In this episode, I'm speaking to Anselm Eickhoff. Creator of Jazz and founder of Garden Computing.

In this conversation, we dive deep into Jazz to learn how it works and which use cases it's a good fit for by exploring various apps already built on top of Jazz. Before getting started, also a big thank you to Rosicorp and PowerSync for supporting this podcast. And now my interview with Anselm. Hey Anselm, so nice to have you on the show. How are you doing? Hey Johannes, doing good. How are you? I'm doing great. I was looking forward to today talking to you about Jazz.

I know a little bit about Jazz and as I'm generally trying to scan the local-first ecosystem, but super excited to have you on the show and dive deeper, learn a lot more about Jazz, but before we dig in, do you mind giving a quick background and introduce yourself? Oh yeah, of course. I guess I've always been like interested in the web.

I think it technically, I started with like Flash for people who remember that, but I very quickly got into making websites, just static ones first, kind of doing web design for local shops in my hometown and that became more and more serious. I learned about Rails and like building whole web apps and what that even meant. And I guess most of my career kind of spent being like a full stack consultant, building apps for lots of different industries.

And typically I would be just like one man army doing like product design and building the backend and the front end and just building kind of the first version of that app that was ready for production. And then doing the next one and the next one and so on. And that was lots of fun. And I learned a lot, but over time, especially when you build lots of apps that are very different in nature, like who they serve, how they work.

You still notice that there's so many things that you have to do again and again and again, and they don't even really have to do with each app. And you're, you're. You're using these tools that are supposed to be like high level frameworks for building web apps, but you still need to do so much yourself, redundantly each time. Like people who build web apps will know stuff like, why do you have to do user auth and permissions every time or like file uploads, this is like super simple stuff.

and that always like nagged me. and particularly like, it seemed like. What you're really trying to do is just share state between different users of the app. And why, why do I have to build a whole stack and why is it so weird to do it? But I never really had a good, good solution for it. Right. And that's kind of what, what brought me where I am today with Jazz. And yeah, happy to tell you more about that.

Yeah, that journey definitely resonates and, sort of in a similar counter reaction, in, in 2016, just led me back then to starting GraphQL, which later turned into Prisma. So I feel like that's a common, somewhat common story to like, from like the previous trauma of like doing something over and over again in a way that doesn't quite satisfy you, where you feel like, Oh man, we can do so much better. so that story definitely resonates.

I'd be actually intrigued to hear a little bit more about some of the specific aspects, but I'm sure you'll, you'll cover that in comparison to Jazz. So, and Jazz is actually not quite the only thing you're doing since you're doing this under the umbrella of Garden Computing. So before diving into Jazz, do you mind giving a quick idea of like, what is that umbrella and what. led you to that?

Yeah, sure. So it actually started with an app called Garden, which was kind of like my take on what should a Notion clone look like, what kind of other ideas do I have, I was really fascinated by Notion when it came out and by Figma just like setting this new standard of like, it not just being like a higher fidelity app.

But one where like multiplayer and like rich multi user interaction is like baked kind of into the very fabric of the app and then the app itself is just like kind of like features on top of that, right? And I was like, this is cool, but I think It still doesn't feel fundamental enough. Like the multiplayer ness of it and like also the aspects that we now call local-first that I didn't really have a name for back then.

and I was like, okay, I want to do something like that, but I want to do that part even better and then build like even cooler features on top. And that, that was Garden. And yeah, I did a bunch of experiments there and that's. That's pretty much what, what led me to what, what Jazz became as for like Garden Computing as an idea for a company or bigger umbrella. I can get more into that later, but basically the idea is that.

I'm really fascinated by abstractions, by like powerful abstractions, by abstractions that are tall and like span many levels of, of understanding. And very often they come from like academia and research, right? That's where people find like really new, better ways of describing and building things. But they're obviously very abstract, very hard to approach for most people.

and from my experience as a. Full stack web dev, I'm, I'm like very in touch with what people are using day to day and what, what the mainstream developer is like and cares about. and I just love the idea of taking these new ideas and kind of like finding ways to package them in a way that makes sense for the mainstream. And that actually makes. What we use in the mainstream, a little more enlightened.

So I think in the broadest sense, that's, that's what Garden Computing for me is about and like Jazz and local-first is kind of like the first step in that journey. And I love the vibe overall of like Garden Computing. A garden is something that I think that's just, I'd say if you'd ask anyone, they'd probably associate it with like a nice, comfortable, homey feeling.

If you think about a garden, does this maybe even, you have a very personal relationship of like, maybe you put together the garden, maybe you care after it, or maybe not, maybe it looks a little bit wilder, but there's something very unique and something very personal to our garden compared to like a very Industrial, like hyperscale, like that doesn't sound like a garden to me.

and also like the use case that you've mentioned sort of like a Notion esque thing, I think Notion is also like there, there's this term of like a digital garden. so all of that is like a vibe that very much resonates. And it also resonates that you're saying you didn't actually start right away. with designing Jazz as a local-first tool, but that you're rather stumbling into it through working on an actual app.

Since there's also the analogy for me, the parallel that while working on Overtone, I also realized, okay, this is a data foundation that I'm working on that doesn't just work well for Overtone, but also for other apps. So I think this is one of the most authentic ways to Really think of a new data abstraction. So now with that background, can you give me an introduction to Jazz?

Yeah. So like, to audiences like this, I introduced Jazz just as like, a framework for building web apps in a local-first way. That's probably the simplest way to put it. That of course requires you to already know what local-first means. So I think maybe a nice way to explain it is to go a bit more in depth on like how through trying to build Garden, I kind of discovered what I thought it needed to be. Because in many ways I didn't like sit down and be like, Oh, I want to build this app.

I want to build it in local-first ways. and then I'll make a local-first framework to build the app because. When I started building the app, I didn't even know about local-first. I didn't know about that as a term. I saw apps like, like Notion and Figma. and I guess systems like Git, where it feels different from a traditional SaaS app with a centralized server and it has these really nice properties and it actually feels like it's suddenly very easy to do multiplayer, to have offline support.

And to like be really serious and honest about the fact that what you're building with your app is a distributed system and not like some thin client around like the app basically just running on another computer, on one other computer. so I was like, okay, I want my app to be like that. And I started building the app and I had all of these crazy ideas in terms of like features for Garden. Part of it was even like, it should be like a visual programming language in there and like.

I actually didn't get too far on that because very soon I was like, okay, what's, what's the infrastructure I need. That's like fabric that, that just has in the data layer, multiplayer and users and permissions and sharing and working on your device, but still being able to sync to the cloud. So I started building that just as part of Garden, right. and very soon just through like. abstracting and encapsulating the code. I had this like separate layer that did all of that.

and a big part of what made that layer possible was learning about, Ink and Switch and their blog posts and publications, seeing auto merge as the first CRDT that I encountered and being like, Oh, even just the idea of having like, synced state between two text editors is super interesting. Like, let's. Build the layer around that. And then once I had that layer, I looked at it and I was like, damn, this is like really interesting, not just for Garden.

but I kind of want to build every app ever like this now. thinking of all the apps I had built in the past, all the other apps I still wanted to build or the apps I didn't even know I could build yet. And I'm like, if I feel like that, probably other people will too. They just don't know yet that it's even possible to have this abstraction. So therefore I should probably try. And make this a framework. And that's, that's the origin story of Jazz, right? That makes a lot of sense.

And, it also, there's, this interesting dance of, being irritated and confused by some problems, this desire of like, could we do better? You kind of hope we could do better. You don't quite know yet how to do better. You see some proof for other apps. Being able to build something in an experience that you wouldn't quite know how you would replicate that.

You go on like looking around for ideas and luckily they're, very smart people, like the folks associated with Ink and Switch who are also like write about that and inspire others. And that leads you to maybe also like be very. compelled by those ideas, but maybe you have some slightly different takes. And so this is where, where it evolves. that makes a lot of sense. And I see a lot of like parallels there for like past endeavors and current endeavors that I'm on. So this is what led to Jazz.

And I think there's like a lot of similarities for how other data technologies, like in the local-first space came to be and, throughout the further conversation, I'm sure we'll learn about what makes the specific flavor of Jazz, how that compares to others, but maybe we can best approach that by talking a little bit more about the applications that, Jazz wants to empower. So can you, give me an idea of like, what is like a typical app that, Is just naturally now built with Jazz.

And what are some apps that you've like intended Jazz for?

Right. I guess one thing I will add in terms of like, what's special about Jazz and we'll go more in depth about that later, but like while building it as part of Garden, I realized that the responsibility of this layer.

It's actually not just a data layer, it also needs to, or like, I wanted it to also handle user identity and permissions because that's other, other, because like, that's what allows you to go from having a local-first app that kind of syncs between your devices as a single player user to just extending that model very naturally to multiplayer. and it just always felt like these two things, user identity and permissions also need to be part of that abstraction.

And that's kind of, that's the most special thing about Jazz, I would say. and that has enabled it to support quite a, like, wide range of different apps that, that even surprised me. and you kind of, you have apps that are like obviously local-first and are like a very good fit, and they are some of the ones that, that already felt the strongest benefit from adopting Jazz. for example, like I, I think Garden is a good example.

We're actually almost at a point now where we can start building Garden again, based on top of what Jazz is now. That's, it's like Notion. It's very clearly a local-first app. One of my favorite early adopters, they're an app called Invoice Radar, which is basically, it lets freelancers collect invoices automatically from like cloud providers and other things they use that send them invoices, manage them, and then submit them to tax authorities, for example.

And that's an area where like, yeah, having it local-first is really important. And the people who were building the app already, I think also without knowing the term at the beginning, knew that they wanted to build it that way. And then they found Jazz and they're like, Oh, there's like a framework that Just lets you build apps like that. And once they started building it with that, they were just able to get to like an MVP of their apps so quickly.

So that's kind of like, almost like an obvious success story. Right. But then there's other ones that are really surprising that start to push the boundaries of what a local-first app is, or does the framework even only need to be for local-first app? one I'm building myself with, my girlfriend that I presented in Berlin at our local-first conference is an app called Succulent, which is basically a Hootsuite alternative, like a social media scheduling tool.

And it's like 90 percent a local-first app where you can like plan drafts for Instagram posts, for example, on your device and you prepare them with the pictures and the descriptions and the hashtags. But then it has this component that's like not local-first at all, because like in order to meaningfully schedule posts to be posted, you need to have a server worker.

and, typically this would mean that, well, you just need to build it as a centralized, like, SaaS app where all this logic runs on a server. But, What I realized with Jazz is like, you can actually take this local-first concept further and the server worker can just become yet another local-first client to the shared state.

And then you get this really funky arrangement of like, you have this local-first app for authoring all this stuff and then just this little worker that whenever you're online and your stuff gets synced. It will know about what you're trying to do and then you can go offline again and it will post your posts for you by like interacting with the meta API, for example. So that was already a bit of a stretch of what Jazz can do.

But honestly, the most ambitious and most out there things in terms of what you can build with Jazz have been from like other early adopters. So one of the crazier ones is This guy Nikita is building an app called LearnAnything, and you can check it out. It's already public. You can go to, I think, Learn Anything. xyz. It's, it's like a cross between Quora and Reddit. It's like a learning community where you can be like, I want to learn how to play the guitar, or I want to learn TypeScript.

and for each topic that you might want to learn, you find this like community curated list of like really good links to other resources, like videos, blog posts, whatever. and that's just the social network, right? And the crazy thing is, he's already getting a bunch of impressions just from SEO, so you have like lots of, First time visitors and all of the state that needs to be loaded for each of these potentially huge topics, which have like thousands of links or something like that.

And he decided to completely pivot his stack to just use Jazz for everything. And I think one of his motivations is that, For each individual user, he actually wants the experience to be local-first in the sense that you can also have your own kind of like notion, like notes about the topic and your learning progress in there and manage your own collection of links and so on. But then through sharing it with others, again, it needs to have the scaling properties of a social network.

And that really, really stretched Jazz, but he was able to kind of like, Self publicly launched already and a version of his app completely built on Jazz. And so far it seems to be working. So, so that's kind of an interesting one. another one, which is very early and we'll have to see if it works, but it's basically like a local-first spreadsheet app, which is just like really intense in terms of like how much data there's in it and how like finally granular the interaction will be.

And then the last use case I'll mention also really surprised me because it actually uses Jazz to do much less than a whole app where, it's at this huge enterprise and they have like CI pipelines for like their build processes or whatever. but it's really hard to look at them and see what's going on, which builds are passing, which ones are failing. And it's all in this like super old system with a really clunky API. And this person just wanted to build like a dashboard for that. Right.

And that's really annoying. They decided to use Jazz basically just as a layer that makes that clunky old API real time and really easy to build UIs around. So they again have like a server worker that makes requests to that API and then maintains like a version of the state of all of the stuff in Jazz. And then they built a really thin client with Jazz and the two, like the status shared between the two.

And then they were able to super quickly build a really nice dashboard, where you see a real time updates of what's actually going on. and I, I think you can start to see like how these are actually all. Really weirdly different. And yet everyone was able to use Jazz as this like small tool that does a lot very successfully. and I have to say as a caveat as well, these are very brave people. Like Jazz is early in many ways. Some of its APIs are clunky as well.

The documentation really isn't there yet, but all the important like magic is already there and I think that's what allowed all these people to move quite quickly and confidently and the parts that still have friction are problematic. They were kind of able to work around it. I think that's kind of a good representation of where we're at as well. That sounds incredible. That's such a wide range of different apps and different use cases.

you mentioning InvoiceRadar, for example, I'm actually one of the early users of InvoiceRadar, I've been using it for multiple months now, and I can confidently say that, I would have probably not started to adopt it if it wasn't local-first.

Not because of like, that I say like, okay, now I have this bar Everything has to be local-first, like I still adopt other tools, but in this particular thing is, one of the, main ways, how this tool works is by getting access, like actually log in access to the various places that you where I pay for an invoice.

So this tool needs access to my Notion, to my Slack, to my Hetzner columns, to all those like very critical places I wouldn't give anyone access who I wouldn't really, really, really trust. And that level of trust, I can't just give that to like an arbitrary SaaS startup, that wasn't around like a couple of years ago. Even if it was around, I would still have trust issues. And that trust issues thing. They very elegantly address by, saying like, Hey, the entire thing runs all on your computer.

Like. All of like the login credentials, et ceterall of that, like not running in the cloud, like all remains on your computer. and so this is how that afforded me the trust and I've been using it. And, it works amazing. And I think it's built by folks, who are like very confident in sort of like front end development. And I think Jazz empowers them to like leverage their strength. And a lot of like the data moving around, that is taken care of.

So that is like a use case that I can already as a user speak to. And then I want to also hear more about the Learn Anything use case, since that's, to me, seems like it's actually stretching, quite on the boundaries of where local-first is even considered a good fit.

I think, if you hear about local-first, like where App use case works well, that's more around like data that's all like centered around a small entity, whether it's one user, whether it's one document, one workspace, one small team, but the more I think it's actually used sort of like as the counterexample, the more something is seen as a social network, the more local-first also actually becomes increasingly tricky to model around, to scale, et cetera.

So I'd love to hear a little bit more how, Learn Anything and how Jazz helps with this sort of like end boss of use cases.

Yeah, I'll, I'll go into that. There's two more things I want to say about Invoice Radar, because, I think that ties in quite nicely with what makes Jazz special, particularly for like your particular sensibilities as a user where like, yeah, you need to put your login credentials in there. Why can you trust it?

And part of the answer is, well, it, because it only runs on your device, but then even then you might want to, and I think they're working on like a mobile companion app to Invoice Radar. So you can also just like scan and paper invoices with your phone. So obviously it's like 2024, you want sync between your devices, right? Maybe you're no longer just like a solo freelancer, but you have like a small company and you want other people in your team to submit invoices as well.

And how do you do that while maintaining the trust that you have with the credentials and your invoices? And Jazz's answer there is exactly what I mentioned earlier that. User identity and permission is also part of the abstraction that it offers you, and it solves those in a local-first way as well. And we, again, we'll go into that later, but basically it uses public key cryptography to do permissions and auth.

And what that means is that, Their app can actually use my infrastructure to sync data between your devices or between members of your team. But my infrastructure only ever sees encrypted data and that way you can still trust that app despite having these modern properties of like sync, cloud persistence, and so on. for them, what it meant was that they envisioned their app initially as only like a single player experience. And it already makes a lot of sense there. And they were like, okay.

Later on, maybe in a year or a bit more, we'll add like team and organization features, and that'll probably be like a huge topic, right? But because they build it with Jazz, the idea of users and permissions is just like baked in and literally all they had to do to make it multiplayer was to build the UI for a little invite button. and their, their app was like multiplayer team ready from day one while preserving all of these like privacy and data protection guarantees.

Anyways, just like a short addition to that. I'm also really excited about Learn Anything for exactly the reasons that you mentioned, because I didn't think that quote unquote local-first could stretch that far and that's maybe where I'll go into a bit of a spicy take and ask the question of like, Just how useful as a term is local-first really, because it's really good at describing local-first apps, right?

But the abstractions that we build to make local-first possible, or at least in my case, what I'm trying to build with Jazz, it actually feels like something slightly more general than that, where like one thing I like to call it is like it's distributed state, and you already see that a little bit with apps like Succulent that has a server component, I don't know.

We have a couple examples with server components that already stretches it, but it's still just Jazz and it's, it's distributed state, not just across end user clients, but across server workers. But again, the trust relationships are now explicit. It's not just frontend and backend, but all these individual things. The way it works in Jazz, by the way, is that the server workers also have an account like a user and you need to invite them.

Two specific pieces of data for them to be able to see it and do stuff with it. so I really liked this idea of distributed state. And then, I also had this like coming to Jesus moment with Jazz where I'm like, what I'm building here is actually a distributed database. And I have to be honest with myself that it's a database. And, I don't know how many people that are listening or watching this are familiar with Redis.

But one way I always like looking at Redis is that it's like, it's, it's kind of like an exploded database. It doesn't give you the nice high level relational API that, that usual databases have, but it gives you all the little tools that you need to kind of build your own database. So you can have like your raw key value store and then different ways to build indices or like spatial lookup structures and stuff like that. And that's really powerful. And Jazz is kind of similar in a way.

It's like, I would say it's like an exploded distributed database with permissions built in. And once you start thinking about it like that. There's suddenly way more use cases where it can be a useful tool, including stuff like the, being this like real time layer in a purely backend setting, or you could imagine using Jazz as like a, distributing configuration for apps.

So like anything that's a distributed system where you might have network failures, nodes going offline, but you want to have meaningfully shared state with like History and auditability. You can actually use Jazz for that.

And I think even though I'm trying really hard to envision all these different use cases and build for it, there's probably a ton more that people will come up with, just by having something that's so flexible without like a narrow minded use case of like, this is for local-first apps or like, this is a database. Does that make sense? Totally. yeah. And I would love to dig in a little bit more into the social network aspect.

I think the exploded database analogy is, is very useful and maybe that also addresses a little bit how, Jazz is able to stretch beyond that, but can you make the, a little bit more specific? when you.

Remember other people, me included, saying that, for local-first, anything that's looks and smells like a social network or like a global, like basically if you have a lot of strongly connected, a vast set of strongly connected data points, this is where local-first has a harder time to sync all of that. And it seems like that would mean you need to sync literally everything. So you need to.

Chop off certain points in the everything is connected graph to not let the user wait forever until all the graph data is there, but to only show the user what they actually need. So how do you work around that? Or do you need to sync everything? That's kind of like, other than the like user identity and permissions making Jazz special. That's I think the only other big point that makes Jazz special is that from the beginning I kind of knew that it had to be.

Super granular when it comes to which chunks of data are you loading? And it's, it's much more, it's basically on demand by default. And the underlying data model is like an infinitely big graph of data that can reference each other. And you like. Load sub graphs of that as needed.

And for like a very local-first or classical app, that means, well, you kind of end up everything that one user needs or like a small team of people needs and there it's very obvious how that works well, I think the surprising insight is maybe that even in something crazy like a social network, even where you have single nodes, like people who might have a lot of followers, it's actually still quite like manageable graphs that are quite independent.

And what doesn't work is in my design sense, you can't ask the app developer to have to come up with the boundary of like, what is a chunk of data that makes sense to be loaded at once. I think maybe you could get away with it for an app like Notion where like the document is an obvious boundary to do that for, but even there it's kind of annoying and gets in the way, particularly with sharing and so on. So I think you just have to adapt that like a hundred percent granular mindset.

And then it turns out, Even the very highly connected graphs, they're actually manageable in size, and it is feasible to load them to display, for example, one learning topic and Learn Anything, even if it has thousands of links and thousands of people interacting with that topic. That's actually, in the grand scheme of things, not that much data to sync. And on my infrastructure, which is kind of inherently distributed.

It's like, obviously geographically distributed because that's like a nice metric to kind of chunk data up against. you can also start doing something very similar to sharding where you basically co locate data that is often accessed together, again, on a very granular level. And then suddenly even this like really hot data with lots of people interacting easily fits. into a single node, even a single core, and it's feasible to sync it to clients who all want roughly the same stuff anyways.

and if you're being honest, like databases face exactly that problem and that the way it's solved usually is just by scaling it,, like making your database node huge so it can fit all of the data for all of the users and then distributing and scaling databases is a hugely complicated topic and I think in many ways local-first is actually an answer to that in the sense that in the most extreme case you're like well we only need to worry about the data of one user and we'll

have a system that manages the data for one user, which is their machine. but then the abstractions you build to make that possible, if you include the granularity, actually also let you do everything in between where, yeah, you, you can have a couple of nodes collaborating to sync and persist and serve like, Subgraphs of that, like infinitely big data. Does that make sense? That makes total sense.

And before we're going even deeper here, and I think we're stretching a little bit into some like implementation details here, et cetera, which are super interesting, but maybe we take a little step back as a application developer who wants to build something with Jazz. Maybe you can walk us through, what does that look like?

So just to give a little bit of like a spectrum of options, we had Matt Wonlaw on the show where we, for example, talked about CR SQLite, where the idea was that, you replicate a SQLite database across devices. So this is where you have already Something that developers are very familiar with, which is a relational database that you can just embed in the app and then query. So that's one approach.

we heard from the folks working on AutoMerge, which is a CRDT based system, so where you rather think less about a database that's replicated. But more about individual documents, that are being replicated and state based as you change the CRDT document, those state changes are being propagated.

and there could be also other options, for LiveStore, for example, I'm following more of like a, what I consider a combination of both approaches where you distribute a event log and you recompute a, in this case, a SQLite database from it. So there's various flavors, various trade offs, which path have you've been going down with Jazz and maybe also why.

Yeah. So the meta comment there is that like, after you think about it for a really long time, a lot of these approaches end up actually being the same, but it really matters, I think, in terms of contrasting different frameworks and solutions and introducing people to the idea in the first place, from which angle you approach it and like the. It's like a replicated local database that's relational is a very obvious one. And there's a lot of people doing that really well now.

the document one is an obvious one. I think you'll be able to predict what, what my issue with it is that it like makes you. Put the boundaries, but I'm basically doing that. I'm doing what AutoMerge is doing. It looks like state, and I'll say that a bit more precisely in a second, but again, it's a bit more granular.

And the way I describe it typically, like the audience that I have in mind is actually not full stack developers or backend developers who are very familiar with relational databases, but in my case, frontend developers who are familiar with Local UI state on the one hand and kind of making requests to APIs as like the only external system they ever need to worry about.

So the story I tell this Imagine Frontend developer is that imagine if you could kind of mock up an app just based on local, like React use state or like equivalent things, and you build your UI around that. but then magically your app actually works and like all of the status persistent and you can share it with other users and, you have permissions on there and you still only wrote front end code. That's kind of the Jazz story and that's what the API looks and feels like.

So if, if you build an app with Jazz, typically the first thing you do is. You actually do something kind of database y, which is that you define a schema just to describe kind of what is the shape of data, which kinds of objects are the main abstractions in my app. interestingly, you don't have to model users at all because that's just baked in. So it's very nicely like, what are just the concepts that are specific to your domain that you're, addressing with your app.

And once you have the schema, you can just start having state of objects in that schema and build UI around it. And you can create objects of different types out of your schema locally, and you can create like, groups, which is kind of like the permission structure in Jazz and put objects in groups and then like give users access rights to groups, all like you can do these things literally in an on click handler of a button.

And it feels kind of illegal because of how simple it is, but that's it. That's how you build apps with Jazz and you can get very far with just that. As apps get more complicated, you can kind of. abstract things all kind of similarly to how there are solutions for not letting UI state get too complex. and the other thing you might need to start, if you want to talk to external systems like third party APIs, you can build the server workers that I talked about a couple of times now.

But the nice thing is you can build. If you also write them in TypeScript, for example, you just share the same data schema that you're using for the front end. And it really just feels like one, one small addition to your otherwise purely front end code. That's, that's kind of the Jazz experience, right? That makes a lot of sense. And I've just in parallel. going through the Jazz landing page here, where you have, this really cool chat app and 174 lines of code embedded here as well.

We can just see exactly that, like a little schema definition of this case for this chat app. There's just like a message. Class, a message concept and a chat concept. and that's it. You can use it right away in your React code, in your other code, and fire away. and you've also have here the user concept where you see like, okay, something is owned by me and then the chat, for example, is owned by a group.

what if I want to go a little bit more specific here and enforce certain Permission rules, that are more specific to my app. what is the story in progression there? So the way that that works is that it doesn't get more complicated than groups and objects belonging to the group. So like whenever you create an object in Jazz and like, I should say the name for them, we call them co values, like collaborative values. You have like co maps that are kind of like.

JavaScript objects, co lists that are like collaborative arrays, basically. and just like you can represent a lot of different kinds of data with JSON, you can represent a lot of different kinds of collaborative data with co values, right? And each co value has to belong to a group. The group is like the scope for permissions, and it simply has user accounts in it with a certain role. The three roles that exist are Reader, Writer, or Admin. They do exactly what it says on the tin.

and they then influence what people can do on co values. We can talk in detail later how that works under the hood, because I think that's interesting as well. But for now, that's all you need to know. And that maps quite naturally on onto a lot of stuff that you want to do in apps. But then the question is what about more complicated situations? And the answer there again is the granularity.

Because if you wanted to every, each co value, like imagine like a kind of tree of co values representing the state of a more complicated document or even like a folder of documents. The way that looks like in Jazz is that they're actually each individual CRDTs that just have plain data as values in their fields. Or they can have references to other co values.

And that's how you build this, like, potentially infinitely big graph, and you, like, load whatever you need to, like, display right now, or what you want to have offline. But the nice thing is that the groups that these co values belong to, and the permission structures, therefore, are kind of orthogonal to the, like, data references. So you can reference a co value, That belongs to a different group that has different members or where the same members have different roles.

And that way you can build permission structures that are just as granular. And you can even have like something like a notion document where like a small block might only be editable by some people. does that make sense? totally. you, you've been mentioning the reference concept that is giving you the kind of like a relation for a key kind of concept between different kinds of documents, and I think this is also describing the.

the boundary between one thing that needs to be synced and then another thing that needs to be synced. And if you model a thing like a network with that, how does, Jazz, how does it know where to, uh, how much it needs to sync? Where does it need to stop? Is there, so one analogy, for example, in GraphQL . maybe not everyone is familiar with that, but it's like a query language that is language agnostic and can be implemented with any sort of backend.

And this is where you can also define a schema kind of similar to this here. and aside from the schema, describes the potential graph of queries, or set of queries in a specific query. you need to very explicitly say, those are the things that I want to query. So let's say we model a file system from this, where we have folders and files and folders can have folders and folders can have folders in a GraphQL query. You need to say, actually, I want to, you need to explicitly lay out.

I want to go like all the way to like level three. So you need to say, I want to grab the folders and in that folders, I'm going to grab again, the folders. And I want to, there again, grab the folders, but you can't self recursively, infinitely, traverse. Is there a similar kind of explicit depth to how jazz should sync something. Is that determined at runtime by a React component, for example, is there some sort of middle ground? How does that work?

So there are kind of, and it's a really good question because like, that's kind of, you need a system that solves that. If you don't have the explicit boundary of like, this is, we can either sync all of that or nothing. Right. And the file system is a good example because it's. It's kind of potentially infinitely deep, but you're probably only ever looking at a subset, so how do you do that?

And the way, the quick and dirty way you do it in Jazz, which is actually really fun to just, again, super quickly build your eyes that work, is that, Jazz tries really hard to make covalues look like just plain JSON objects. And if you have co values with references to each other, they look like JSON trees. So what do you do then if like at some point you might not have a co value loaded? Well, then it just says that it's in a TypeScript sense that field is either the reference thing or null.

And,, if you try and render a specific tree in a React component, you can basically just use optional chaining to like render like this far. And if it's not loaded, show like a little spinner or something. But the funny thing then is that Jazz notices what you are trying to access. And it's like, Oh, you're trying to render like three levels deep. And you try to access this thing that we don't have yet in the background triggers a sync of the needed co value.

And once that's available locally, it re renders your component. And now that's not null anymore, but you actually have the JSON state for that co value and you render it. So very naturally by like building your UI and just deciding to render. What do you want to render it will lazily load exactly what's needed. And you can even manually do pagination like that by just having a little stateful, like, oh, I want to render 10 items and then you only drill down into the first 10 items.

And then like you hit a button or you reach the end of a scroll list or like. Elements become visible on the screen and you just ask Jazz to access more of them, even if they're right now, not, not available. And in the background, it will load more. That's the quick and dirty way. Super nice for prototyping stuff.

It's a bit weird in terms of user experience, because you end up with a lot of spinners and they like, they resolve really quickly because Jazz is fast, but it still looks unfamiliar to people. So if you want to give people a more polished experience of maybe one Loading thing until a bunch of status available. That makes sense as a unit. There is a way of specifically specifying a loading depth and that's.

That kind of looks like GraphQL lite, but because you only need to specify fields that are references, you don't need to say which plain data fields you need because they're always loaded. yeah, you, you, it's, it's actually very similar to Prisma. You just say which references you want resolved and then the Jazz hooks. Won't give you anything until all of that is loaded and then they give it to you as a chunk. That makes a lot of sense.

So you're basically just specifying sort of the graph of the references, not the individual fields of a document, since you typically want a document as a whole, that makes a lot of sense. And that's also, as I'm thinking through how I would model something for Overtone. when I have a music app and I want to listen to music, if I'm currently ermbarking on a train journey or on a like traveling somewhere where I don't have perfect connectivity.

I want to like that lazy loading just in time as I like click on a playlist. if I don't have connectivity, then at that point, it kind of breaks a bit of like that local-first promise. but I also understand like, let's say, Spotify is thinking about building it in that way. Spotify can't just sync the entire catalog of like all of Spotify on a single device. So there needs to be like some cutoff point. And I think while prototyping doing the just in time lazy loading, that's great.

But then as an app developer, in this case, for example, me building Overtone, as I better know, okay. I want you to find some rules of like, that stuff should always be there, like prepared for me going on a, on a train journey. And that would probably in this case be. For all of my playlists, make sure like all of like the tracks for the individual playlists are at least the metadata is there and possibly then have like also some rules for pre downloading some tracks.

If I have the rights to do so. that makes a lot of sense. And that seems like Jazz provides a really nice trade off of making, providing a easy way right away to prototype and then, dial it in to match the user experience that you want to provide.

And I guess I met the comment here with like, because you actually just now asked a very precise, interesting question, which is like, well, what if you ask it to load a chunk of data and not give it to you until all of it is there, but then your connection drops, what should actually happen? And like nothing being loaded, then it's actually a. Like you said, an outcome that violates local-first a bit.

So there, then we need to be more refined and be like, well, maybe show a spinner for everything for like two seconds and then give up and just show me everything that was actually loaded. and what we're getting to there is that I think like, look, I think it's starting to become clear how local-first in general is this cool new way of building app and how Jazz in particular things really deeply, how to make that easy for you as a developer.

But most of the challenges with local-first and with multiplayer, by the way, I think are UX challenges where we're like, well, what, what should happen? And that's something that we figure out as we try to build and dog food, our own apps. As we see what, our first adopters build with it and what makes sense to their particular developers and how you want to expose all of these different, like, is it loading? Is it locally available? Is it locally available?

But it's like, not quite up to date with what we know the syncing server has, but we didn't have a chance to get that yet. And there's like so much complexity in there. And in different situations, you need to expose like more or less of that. So I think beyond just like.

Making the sync and making the data persistence and making the permissions work, which like we're pretty good with now, there'll be a lot of like API design and also like educating developers and just figuring out UX together, like as a field, I think. I definitely agree. And like just the scenarios that we've now went through over the last couple of minutes, I think already go surprisingly deep.

For example, like the partial, like if you want to load everything and then you say, okay, I don't have everything, in some cases, it's fine to show a partial set. In some other cases, it might be like really nerve wracking for a user where if you don't signal like, Hey, we've just, we, we can't say this is everything. We've just fetched so much since otherwise a user might assume, Oh my gosh. Like this app has like lost some of my data.

and so this might, in some cases might be better to not show anything and like explicitly let the user know, like, Hey, we're sorry. when you come online again, we'll do our best to get everything in here. sometimes you also like from the data you fetch, maybe you want to like, let's say you, you shouldn't build a bank account this way, but let's say you build a bank account and you've just fetched a bit of like your, your like transactional history.

And it misses your latest, like, big check that you cashed in. Basically you added money to your bank account and it's not in there. And you think, Oh my gosh, like my bank account is like lost all of that money. Obviously you won't build an app like that, but I think the analogy kind of like translates where you derive data from other data and where it could be like really bad, you missed something. So this is really interesting to dig into the user experience aspects.

And that might also make for a really interesting future conversation, but I want to, Dig a little bit more into, into another related topic, which is the localfirst.fm podcast. And what brings all of us together is that we think we can do better how we build apps, at least in many app use cases, and Jazz shows for how many app use cases that applies. And so that means We, as a whole, as an ecosystem, we need to convince the people who are not yet in that small but growing ecosystem.

We need to convince them that we have a very interesting way how to build apps better, that are simpler to build, better for end users, etc. And I think each technology has their own specific, benefits, how that's, is a, is a good fit for, for certain app use cases and particular developer types. Like you want to target more like the front end developers. what is your approach to talking to developers?

How do you want to market Jazz to reach the right people and sort of the, I think you have a very interesting take on sort of developer psychology.

Yeah, yeah, totally. Because I think like, look, we're all facing the same challenge. Like you said of like, we understand how this is better and how it can benefit a lot of different kinds of apps. but counterintuitively it's, I don't think it's really about selling the benefits. I think the one big benefit that really does make sense. And it's valuable to people as just saying, look, like you've got like a 10 X better developer experience. It's way faster to build apps.

It's way easier to reason about. There's way fewer moving parts. I think that's kind of universal across all the different solutions. different solutions differ in terms of like what traditional parts of the stack they replace. I've put myself in the shoe of like replacing a lot of the pieces because I do auth and permissions, and by the way, you can also store binary data in Jazz.

So suddenly you don't need blob storage anymore and binary data just becomes part of the data you have locally and can be referenced just like JSON like data. and it's so easy to just think about what are the obvious advantages of that if you are totally bought into this and ready to build your app like that. That's kind of the easy part, right, to make. to explain that. But the biggest question is like, why should you even bother?

And why should you give up this really proven, familiar way of building apps? that means the biggest challenge is that it's so new and alien and different. So I think the trick has to be How can we make it look familiar and how can we make it look like something that already exists? And that's, I think where exactly the different audiences or, ways of telling that story for different products come in because, saying that you're replicating a relational database into the client.

That's taking something very familiar to like backend developers and then doing one little step away from that. And then like, Oh, and then it has all these benefits. Right. I feel like, yeah, I've made it hard for myself because I'm basically trying to replace the whole stack. And that's a story that actually, again, it works really well for frontend developers because the whole stack was never part of like where they had agency to begin with. So they're happy.

Full stack developers and especially backend developers aren't so happy because you're like. You don't have to do all of that stuff anymore. It's replaced by this giant pile of magic. I think like, I mean, what we identify as developers is being clever and building stuff ourselves. Right. And I think a big part of what keeps really complicated stacks and ways of doing things in life is honestly just the IKEA effect of like.

Well, but I built this myself and I like, I picked things that are individually good at what they're doing, but I put them together in this really clever way and local-first is like, it's just, it's so powerful that it takes away so much of that doing stuff yourself. That it's a real danger in terms of adoption and like not bruising people's egos secretly.

so one attempt I had was like, well, can I kind of not make Jazz one giant package, but more smaller ones so people can glue stuff together again. And I think that's kind of counter to like what makes Jazz powerful, which is exactly that it is a vertically integrated thing where even the different parts of like. CRDT, stage sharing, and user identity and permissions. They are actually very tightly knit together. And that's why, yeah, that's what makes Jazz special, I think.

But, the other way out of that, I think, and this is something I just have to do way more, is to have really good, like, under the hood documentation. And the cool thing is, like, I think CRDTs kind of get thrown around as this like mysterious new thing that magically solves everything, but like, it's really complicated. Don't worry about it. Like, you can read about it in some research papers if you really wanted to, but I think the way I've implemented CRDTs in Jazz is actually very.

Very straightforward, in the sense that it really follows a particular viewpoint of CRDTs, which I think is best represented by a blog post called, like, Data Laced with History, I think it's called. And it's basically just this, the simple idea of like, look, you just keep all of the edit history on an object around and that's what the object actually is. And then the current state is just a view over that history.

And if everyone has all of the edit operations and the full histories of different people collaborating on a document, then you eventually get the same state and that's it. and like, just as simply in like five or 10 more minutes, I could describe to you how then Jazz adds cryptography to do the like. Read and write access control, but it's actually not that hard.

And I think having really neat diagrams and kind of like a medium level explanation that people can read through in like 15 minutes and feel like, okay, these are the parts that are inside Jazz. And now I know like, if I wanted to glue stuff myself together, what I could glue together or which systems I would need. But I won't bother. It's enough for me to know. What's going on and that in itself already makes me feel kind of clever.

And then just going like extra deep on all the details for the people who want to be really, really clever. I think that's going to be important. and probably each framework has their own equivalent of doing that. And like, it's not necessary to use it at all, right? That the APIs that you use, if you build Jazz are much higher level and are much more in terms of like abstractions that an app needs, but.

Yeah, I, I think DevTools, the biggest challenge is that you are selling to developers, so you need to speak to developers egos, right?

Right. And I love the way how you framed that in the Ikea effect and how you, yeah, it's, it's like this delicate balance you want to, like, I think we can all get on the same page that we want to collapse as much complexity as much as possible, But developers still like love the abstractions, love putting things together and, like figuring out the delicate balance of having something that's already somewhat put together and does what they need, but then you can decompose it and

like compose it again in a different way. I think that's sort of like where the, where you need to apply like a little bit of like special sauce. and I think this is what you've already, laid out very, very nicely with Jazz, with like the APIs look amazing and the apps that are being built on top of it already. I think a really, really good proof for that. So slightly switching gears.

Jazz is no longer just a technology, but behind Garden Computing, you've also, I think you've thought about that for a longer time and recently took the step to actually, Turn Garden Computing into an actual company and build out a commercial offering around Jazz as well. and I think you've recently, took on a initial round of pre seed funding, so congrats on that.

but I'd love to hear a little bit more about what that means for Jazz as a technology, what your thoughts are on possibly offering a commercial product, sustaining the company otherwise around that, and how you're thinking of like Going beyond just working on this yourself, but possibly, scaling out the company or like hiring other people. So very curious to hear your thinking on that.

Yeah. So I think again, going into it from like, how did it come to be? I think it's important to say that, like, I'm not someone who's like trying to do a startup for the sake of doing a startup. I was very much like thinking of it as like an open source framework and was building that as like a good tool. And in a similar way where like the fact that it is a framework kind of became apparent to me while I was building it.

it became apparent to me that like, okay, even if you have all of these abstractions for distributed state and local-first, and that's all like, it feels very peer to peer. And I think in our legacy, we have a lot of peer to peer thinking. and that obviously influenced me, but I had this moment where I'm like, okay, if I really think about what I as a user want from the app, for example, very pragmatically.

I want sync between devices that works even if the devices aren't online at the same time. So I need some kind of centralized syncing infrastructure that also does persistence for me. Right. so that very obviously became a part of Jazz and then I'm like, it's actually kind of hard to run that at scale and to run it well and have it have low latency and so on, and that's something that a company could do as a service.

Right?, and it being open source, of course, you can also self host your own version of that either on a single node for like a small app, or you can be brave and try and scale it yourself. That's totally doable, but there's just obvious value in someone doing that for you. And the interesting extra component there is that. Because of the encryption, you actually don't have to trust that infrastructure with your data.

You can just use it for syncing and persistence, but know that it will never see your data, your user's data, whatever you care about. so there's this kind of like really useful service or product.

presented itself to me and I'm like, okay, this doesn't just feel like it wants to be a framework for people to really have that local-first development experience where you only want to have to worry about the parts that actually make your app, your app, and now you don't have to solve state syncing and permissions yourself anymore, but you would still have to build syncing infrastructure. That seems kind of weird.

Like. I think what you want as an application developer is to use a service for that, because then you're actually only left with your app. That's what I would want anyways. So like, okay, this is starting to feel like a company and I think I'm in a good position to build that company. and then it became a question of like, okay, I, for a long time, my plan was to bootstrap it.

and I did try to go into YC and raise VC funding, but I think we, as if Field are so early that it's, it's really hard for outsiders to see the potential in that. and what it took for me to have any success with that was to get Jazz to a state where it became obviously useful to developers. And they could start telling these like first success stories of like, wow, we actually built the SAP way quicker than we would have otherwise.

And then to do that in like a public setting, like the local-first conference in Berlin, where then investors can see that and be like, Oh, this actually really speaks to developers. And that's like, That's like an early signal they understand, right? So that's, that's what allowed me to raise that round. And now I'm in the, in the very fortunate position to have investors who understand how early we are and how much work it's going to take to really bring this into the mainstream.

And starting to have the person power through like hiring my first couple of employees who I'm really happy with and who, who really get it as well. And they're building their own apps with it as well. where I'm like, okay, we can actually speed run, the features that we need to reach parity with what traditional stacks can offer you, in the way that I think we need. That's, that's kind of the switch that happened there for me.

And before I had all of these ideas in my head of what I kind of knew Jazz needed to do, and believe me, I thought about everything. It's all somewhere on the roadmap, but I didn't really know what was most important, right? But the nice thing about having early adopters is that just becomes super obvious because they'll be like, They'll be blocked because Jazz doesn't have like this and we just built that next.

And that's kind of the journey that, that I've been on actually, since before the investment for about a year now. and now I have the luxury of being able to like tackle a couple of these at a time. that's kind of where I'm at with it. And the goal is to really.

To build a service that makes sense both for individual developers, for whom it will be the first point of contact with local-first or distributed state, for small companies to build, successful apps super quickly and kind of like being able to reach a much wider economy of small companies and individual developers who can now meaningfully build real things that are useful to people and maybe because. It's so much easier to build things. You can now build products that target smaller niches.

And that's really interesting. And also to just give a tool for like bigger companies or even enterprises to be like, Oh, it's actually really hard for us to build high fidelity apps. Figma like notion. We want these because we have lots of people and lots of teams that interact, but we don't have the know how to build something like a sync engine. That's just way too complex for a company to do itself.

But if that's now an off the shelf abstraction and there's kind of like an obvious either third party service or something that you can deploy on premises. That's really powerful and interesting and I think enables a lot more bigger companies to build their own software as well and have it immediately be as good as the best, like, SaaS apps we have right now. That's, that's kind of the potential I see in it and what I'm trying to address in the, in the medium term. I like that a lot.

And that also makes me think about, like the, this concept called small giants. I think it was also, I think I first learned about it on the Metamuse podcast by, that Adam Wiggins did in the past. Hopefully it comes back at some point. but this is where they did one episode about the idea of small giants.

And this is basically that a very small team, possibly could be like just, an individual small team, et cetera and they can build products, reach a really wide audience without having to build up all of that load and to. Like, for example, WhatsApp was when I think it was acquired before billions of dollars by, by Facebook, was still a very, very small company. I think, they've been, I don't get the numbers exactly right, right now, but like, I think within 10 to 50 people where they've already.

Reach like billions of users. I think similar for Telegram, well, Telegram is a little bit in the news right now, but, I have a lot of admiration at least for like how they built the product in terms of the craft, et cetera and it's also similar there. There's a very small team that can still reach a very wide audience.

And I think this is what local-first can really empower, where you can empower a lot more small giants to serve a much more richer, diverse set of use cases, where a bunch of current existing products could be replaced by local-first products, but not just by one local-first product, but a hundred different kinds of people who have specific use cases. There are a hundred different small giant. Build products specifically for their use case, for their niches.

so instead of like having, 10 very, very large monopolies, like, dominating a particular segment, let's rather have like a thousand individual builders reach smaller slivers and have products that fit particular use cases. And I think this is where you can empower them. They can focus. Similar to Invoice Radar, focus on specific use case and then, use a syncing service. So that makes a lot of sense. And I'm looking forward to that future.

before we close out, I'm interested in hearing your perspective on the more, the bigger web ecosystem as a whole, as you've been building apps within the web space for a long time, now you're contributing a, better development suite to that, but I'm curious whether you have any sort of strong opinions on the web development world that we live in.

I think my strong opinion on it is that I kind of don't have one, or like there's a lot of critical voices that complain about all kinds of things about the web and its state that are completely fair. Right. But I think what kind of gets lost within that is that the web is actually fine. And it's not only fine. It's, it's like, it's amazing. It's like, I think first and foremost, it's this like crazy distribution mechanism.

and, I think, you talked about this in a previous episode, that like, you can just send your grandma a link and she'll know. What to do with it. Right. and it will, she'll see what, what you see. and that's crazy. That's something that is just so at the core of the web. And, sure. It's kind of weird that like JavaScript got tacked onto like a document representation and so on, but it is a really powerful VM.

That is super dynamic, would make anyone who likes Lisp or Smalltalk proud if you really think about it. But it's like, everyone has it. The best minds of our generation optimized it to the death. And you just get all like, CSS is crazy, but you can do a lot with it. and you just get all of that. And. It's kind of not doing what it was originally meant to do.

It's kind of like an app distribution system now, but because it's so flexible and so malleable, I think my big point is actually that we can just make it do whatever we want. for example, when I think about Jazz and what Jazz does, the way Jazz works is, is it's actually like a high level framework and then like a protocol underneath it.

And it's a very minimal, simple core that does like, the implementation of the CRDTs and like how to sync them, how to persist them and the cryptography, like how do the permissions work? That's all like defined. And then like you get higher level features on top. And if you look at that, it's kind of like a new networking protocol. And in many ways, it's like what I think the web should have been like just taking seriously that we're building like this.

Network of distributed nodes that have partial state and being able to represent user identity and permissions across that. so like one kind of pessimistic take would be that like, Oh yeah, that's obviously better, but we'll never get there because we're stuck with the web and this like centralized client server model. And that's like at odds, but like, it's not at odds at all. We've got web sockets and we can just build.

The protocol on top of client side JavaScript and server side JavaScript and hopefully soon other server side programming languages and native apps and, communicate over the web socket or maybe soon web transport or like HTTP 3 or whatever. It's like you can actually do a lot of crazy stuff with the web and, we can just like, yeah, just embrace the fact that In the history of computing, we almost never replace things.

We just add archeological layers of like, we're building the thing that we really want, but we have to build it in terms of what's already there and like widely available and it's actually fine. And that's, that's. How like you kind of have the psychological aspect that we talked about earlier, where like this crazy new thing has to look and sound familiar, but also very pragmatically it has to be implemented based on things that already exist where you don't have to really replace anything.

That's, that's kind of my take on the web, right? Right. I love that. I did this year, I did a three week journey through some of the national parks of the United States. And we also, spent a couple of days at the Grand Canyon where we just See like those like massive, massive, like layers of layers on top of layers that just reach back, I think like millions of years.

I don't recall the exact facts anymore, but I think it's a very good observation that, we rarely replace something categorically, but we just build on top. Maybe we phase one thing out, but that takes like, decades often. And, it's kind of a miracle how capable the web has gotten, given how weird it is and how many words it has. So I think I like that observation a lot. And, yeah, given the, given often the web for me is like a love hate relationship, I think the love still dominates there.

So, uh, Anselm, this has been a really great conversation. I've learned a lot about Jazz. I've been very inspired by the way, how you think about the entire space overall. So maybe you want to have a, you have a last chance to plug anything, give any shout outs, but other than that, I'll thank you for your time. Yeah, I mean, thank you. I really enjoyed this conversation as well.

Definitely shout outs to Ink and Switch because they are my biggest inspiration and what kind of, what gave me a lot of the ideas in the first place.

In terms of plugging stuff, again, coming back to psychology, like I can tell developers about all the advantages of Jazz and so on, but like, So far, what has worked best in getting them to adopt it for even like a small experiment or even getting them to start doing the guide and the official docs is just being like, look, I've got these like shiny holographic stickers for Jazz. And like, I've got boring stickers as well. And like, everyone can get them at meetups.

I put them on tables and stuff, but like, if you want one of the special shiny ones, you have to build something with Jazz. And like, if you just do the official guide that counts as doing something with Jazz Just show me like wherever you are in the world, either we meet in person somewhere or I'll mail it to you, but you, you get the special shiny sticker. Okay. That's the deal. All right. There's, there's a first on the podcast. There weren't any holographic stickers yet.

So I might just as well give this a try afterwards. And the next time we see each other, I might steal one of those. But thank you so much. Thank you so much. I really enjoy myself. Thanks for having me, Johannes. Thank you for listening to the Local First FM podcast. If you've enjoyed this episode and haven't done so already, please subscribe and leave a review. Please also share this episode with your friends and colleagues.

Spreading the word about this podcast is a great way to support it and help me keep it going. A special thanks again to Rosicorp and PowerSync for supporting this podcast. I'll see you next time