Speaker 1: Hey, folks, welcome back to another episode of JavaScript Jabber.
Speaker 2: This week on our panel, we have a j O'Neill Yoh.
Speaker 3: Yeah, coming at you live from the sickness. Oh no,
Speaker 3: I'm feeling better today. Yesterday I was a little under
Speaker 3: the weather. I just slept all day and I feel good.
Speaker 3: I'm just a little groggy.
Speaker 1: I still have some turkey soup from Thanksgiving. Maybe i'll
Speaker 1: drop by.
Speaker 3: I'm Charles Max from.
Speaker 1: Top End Devs and this week where we have a
Speaker 1: special guest, it's ONNSE.
Speaker 2: Sorry I don't have your last name in front of me.
Speaker 4: I usually my last name is Ko, but that's like
Speaker 4: even more difficult. Don't worry about it. Nice toy. You
Speaker 4: guys very happy to be here.
Speaker 1: Yeah, the foreign names kind of throw us off. Sometimes
Speaker 1: you want to introduce yourself real quick. I mean, I
Speaker 1: have jazz dot tools is something you work on.
Speaker 4: But yeah, sure, So I'm like, broadly speaking, a full
Speaker 4: stex software engineer. Have worked kind of as a freelancer
Speaker 4: most of my life. I'm originally from Germany. I live
Speaker 4: in the UK now and I kind of just kept
Speaker 4: building apps for different companies, always kind of taking them
Speaker 4: from zero to one and just felt like I'm always
Speaker 4: doing the same stuff and I never really had a
Speaker 4: good answer to how to solve that problem until I
Speaker 4: ran into what is now known as local First, and
Speaker 4: that kind of became Jazz. That's like my mini origin
Speaker 4: story on that.
Speaker 2: Awesome.
Speaker 3: So, so are you the main person behind Jazz.
Speaker 4: Yeah. So I've been working on it for a bit
Speaker 4: over four and a half years now, and then since
Speaker 4: this summer it's a company and I raised some funding
Speaker 4: and so on. But before that it was just like
Speaker 4: my side main project.
Speaker 3: Nice.
Speaker 2: Nice.
Speaker 1: So I just have to ask, just right off the bat,
Speaker 1: because you said local first, you go to jazz dot
Speaker 1: tools dot or jazz dot tools. I almost added to that,
Speaker 1: but guys, there's no dot com. It's Jazz dot tools
Speaker 1: on the internet, and it says local first, and of
Speaker 1: course my brain goes through is it one of these
Speaker 1: eighty different things?
Speaker 2: So do you want to just kind.
Speaker 1: Of explain give us some context of what kind of
Speaker 1: apps we're looking at and what you mean by local
Speaker 1: verst so that we're not talking about things different things
Speaker 1: that people are thinking, oh it's this, and then we're
Speaker 1: talking about this other thing.
Speaker 4: Yeah. Sure, So, like local first is kind of a
Speaker 4: new term and a new sphere, Like everyone who is
Speaker 4: into it seems to have bumped into it their own way,
Speaker 4: and it means because it's so early in the movement,
Speaker 4: it means a lot of different things to different people, right,
Speaker 4: And I think what everyone has in common in terms
Speaker 4: of how they would define it as like you move
Speaker 4: away from the traditional stack model where you have a
Speaker 4: back end and a front end and most of the
Speaker 4: authoritypive state lifts in your database and the beckend interacts
Speaker 4: with that, and the front then kind of sense requests
Speaker 4: to the back end. You move away from that to
Speaker 4: a new model where you try to keep as much
Speaker 4: state as possible or maybe even all state in the
Speaker 4: client and you just write youI around that as if
Speaker 4: you were building basically an old school offline app that
Speaker 4: just writes to memory too disc but then that state
Speaker 4: gets synced to other participants because of course you still
Speaker 4: want to interact with other users, maybe even have real
Speaker 4: time multiplayer that sort of stuff. So you kind of
Speaker 4: the way I like to look at it is it
Speaker 4: is that we're so used to the traditional stack as like,
Speaker 4: obviously that's how you build web apps, but if you
Speaker 4: think about it, what the stacks do is they just
Speaker 4: facilitate sharing state between users, and the way they do
Speaker 4: that traditionally is by having like centralized authoritative state. And
Speaker 4: with local first, you just turn that problem around and
Speaker 4: you like, what if everyone kept state locally and then
Speaker 4: how do we sink between participants?
Speaker 1: So this reminds me a little bit of how things
Speaker 1: like web RTC works, right, where you can have a
Speaker 1: lot of times there's a server that kind of coordinates,
Speaker 1: so people will hit the server first and say.
Speaker 2: You know who else can I connect to?
Speaker 1: But then you can do peer to peer video, right,
Speaker 1: Or you've got other peer to peer apps where kind
Speaker 1: of like BitTorrent, I guess right, where if you know
Speaker 1: where the other participants are, you can go ahead and
Speaker 1: share in this case as parts of a file.
Speaker 2: But it's the same idea, right.
Speaker 4: Yeah, And like I really like this comparison because that
Speaker 4: lets us get into more precisely what it is, because
Speaker 4: something like web ARTC or BitTorrent that's mostly about the
Speaker 4: transport mechanism, like how do you find the other peers?
Speaker 4: Local first is kind of like almost orthogonal to that
Speaker 4: you can do local first in a peer to peer way.
Speaker 4: But you can also do it with some centralized sinking infrastructure,
Speaker 4: which is what Jazz tools implements. For example, what local
Speaker 4: first is about is mostly solving the problem of well,
Speaker 4: if you write against the state as if it was
Speaker 4: local state, what should happen if multiple people added the
Speaker 4: same piece of content. Again, in the traditional stack model,
Speaker 4: this problem doesn't really exist because it just depends whoever's
Speaker 4: request comes first, and then there's one central state. In
Speaker 4: this case, you have distributed state, and how do you
Speaker 4: solve for conflicts and distributed state? And what you get
Speaker 4: then is something that works very similarly to GIT. And again,
Speaker 4: different local first frameworks or services do different things, but
Speaker 4: what seems to be the most common is to rely
Speaker 4: on a technology called conflict free replicated data Types or
Speaker 4: CORDTS for short. That's the term that's starting to be
Speaker 4: thrown around more. That's an idea that JAZZ is based
Speaker 4: on that many others are based on. And the way
Speaker 4: I like to illustrate that is that it's very much
Speaker 4: like GIT in that have your local state that you
Speaker 4: work with, and then you share your edits with other
Speaker 4: people and there's something akin to merging and contract resolution.
Speaker 4: The difference to get is that it's much more fine
Speaker 4: grained well, and get you kind of do pretty large
Speaker 4: commits right over, like maybe an hour's worth of time
Speaker 4: or something for crdts. Imagine if you made these commits
Speaker 4: smaller and smaller until like every single keystroke and every
Speaker 4: single edit of an object property becomes a commit, and
Speaker 4: then that's what you think to Actually, objects no longer
Speaker 4: are like their current state, but they're just represented by
Speaker 4: the entire history of everything that ever happened to them.
Speaker 4: And again, I have to be careful here not to
Speaker 4: get too specific to how jazz works, how jazz interpret crdts,
Speaker 4: but this is like a common story. And what Jazz
Speaker 4: does basically is you as the application developer. It gives
Speaker 4: you an API that makes these objects look like simple,
Speaker 4: mutable objects that you can write to and read from
Speaker 4: the hood. It converts these edits into changes in the history,
Speaker 4: and then kind of reconciles that history with everyone else
Speaker 4: who's interested in the same object based on their edits.
Speaker 4: Does that start to give you an idea?
Speaker 2: Right?
Speaker 1: It sounds a little bit more like Google docs, where
Speaker 1: you might have multiple people editing the same file or
Speaker 1: the same dock at the same time. And as they type,
Speaker 1: shows up on my page, and as I type, it
Speaker 1: shows up on their page. And if we're typing over
Speaker 1: the same space, then yeah, it's got to figure out, Okay.
Speaker 2: How do we figure out whose edits.
Speaker 4: Or what exactly? And it's kind of clear how that's
Speaker 4: useful in something like Google Docs where you have real
Speaker 4: time communication. But the way I like to think about it,
Speaker 4: and to get back to your original question of like
Speaker 4: what kinds of app is that for? There are a
Speaker 4: lot of people who are saying, like, look, there's this
Speaker 4: new niche of local first apps where this kind of
Speaker 4: way of building apps is particularly suited, and you can
Speaker 4: see that with your Google Docs example. But my approach
Speaker 4: there is to be like, no, this is actually a
Speaker 4: better way to build any kind of app, and the
Speaker 4: real time multiplayer is kind of just the extreme case,
Speaker 4: and anything less interactive than that can still be solved
Speaker 4: with the same pattern. And one of the major other
Speaker 4: features that you get from local first is that it
Speaker 4: is offline first, because you can write against you state locally.
Speaker 4: Even if you don't have a connection, your app keeps working,
Speaker 4: and you just think when you come back online, and
Speaker 4: you can kind of imagine the spectrum of like really intense,
Speaker 4: really interactive real time multiplayer on the one end, and
Speaker 4: like being completely offline on the other hand, and then
Speaker 4: in the middle you have something more like a traditional
Speaker 4: app where you have like some multi user collaborative app
Speaker 4: like a productivity app, or maybe a social network where
Speaker 4: you have some frequency of interaction. And so far we
Speaker 4: needed very different ways of building apps and frameworks for
Speaker 4: each of these cases. But Cordts and the idea of
Speaker 4: local first is actually something that lets you solve all
Speaker 4: of these cases with one abstraction. And what's nice there
Speaker 4: is that you don't have to choose what kind of
Speaker 4: app you're going to build because some parts of your
Speaker 4: app some features might be more real time, some features
Speaker 4: might be like less frequent updates, less collaborative, more personal,
Speaker 4: and so on. And that's kind of what really got
Speaker 4: me into the idea and where I'm like, oh, this
Speaker 4: can actually solve a lot of things.
Speaker 3: So one thing I often ask is what is this
Speaker 3: not a good use case for? Like when would I
Speaker 3: not want to use this? Because I think hearing we
Speaker 3: can use this for anything is a little bit it's
Speaker 3: not helpful to know, like we can use it for anything.
Speaker 3: So I think sometimes knowing what we shouldn't use it
Speaker 3: for helps us to better understand why it's actually really useful.
Speaker 3: So when would I not want to be using local
Speaker 3: first or jazz?
Speaker 4: So I'm going to give you a really annoying first answer,
Speaker 4: which is nothing and and kind of like the counter question,
Speaker 4: like what is React not good for? Within web? Absolutely?
Speaker 1: Say, you know you are knowing the wrong man about that.
Speaker 4: What's what's your favorite pick?
Speaker 3: Yeah?
Speaker 4: Mhmm, what's your favorite pick other than React? No?
Speaker 3: I don't. I don't like React?
Speaker 4: What what would you?
Speaker 3: What?
Speaker 4: What would what would you?
Speaker 3: I just so, so, first of all, I mostly do
Speaker 3: back end or library so I do. I do tons
Speaker 3: of front end code, but my front end code is
Speaker 3: is in libraries where your people are are used using
Speaker 3: it as a as a library. It doesn't matter whether
Speaker 3: it's back in the front But when I do JavaScript
Speaker 3: on the front end, I just use JavaScript. Now, like
Speaker 3: the dom is so good good, I'm not. I'm not
Speaker 3: building things that are large enough or I don't even
Speaker 3: know things exist that are large enough that just JavaScript
Speaker 3: as it is isn't good enough these days?
Speaker 4: Fair fair enough, fair enough? Okay.
Speaker 1: It's very similar to AJS where I use a framework
Speaker 1: called Stimulus, and then I use another library called Turbo,
Speaker 1: which is a lot like HTMX and.
Speaker 2: So interesting. So it very gives me a way to
Speaker 2: organize my dom calls.
Speaker 4: Cool Okay, So yeah, my comparison there would have gone
Speaker 4: nowhere because I'm used to to talking to very different
Speaker 4: people who are very into React. So I would ask
Speaker 4: them back, like, well, what is React good for? And
Speaker 4: they would say, well, any kind of That's kind of
Speaker 4: what I was saying at.
Speaker 3: To React is really good for things that have infinite scrolls.
Speaker 3: That's what React was designed for. That's what it's really
Speaker 3: great at.
Speaker 1: It it so my my thing, and maybe this will
Speaker 1: give you a better way to answer this, right, is
Speaker 1: I feel like there are trade offs?
Speaker 2: Right of course?
Speaker 4: Sorry, that was the first like annoying part of my answer.
Speaker 4: To be more precise, like, I think a better way
Speaker 4: to say it is that events should. I want it
Speaker 4: to be good for any kind of app.
Speaker 2: Right.
Speaker 4: The reason it might not be right now is because
Speaker 4: we're early, and because specifically for Jazz tools, we decided
Speaker 4: to prior tie certain features over others. So, for example,
Speaker 4: if you have an app where you definitely need authoritative
Speaker 4: centralized state, like you're building a bank or something like that,
Speaker 4: and there can only be one balance of your account
Speaker 4: at any time. You you could actually build us on
Speaker 4: top of jazz that you can implement authoritative state with
Speaker 4: a local first framework, but it's going to be more
Speaker 4: awkward than the traditional.
Speaker 1: Thing because you have you have a tighter constraint. You
Speaker 1: have to make sure that everything lines up on the
Speaker 1: front end back end.
Speaker 4: It's it's basically like what you do then, is you
Speaker 4: re implement something like requests on top of the local
Speaker 4: first state, which sounds elaborate but actually has some nice
Speaker 4: drawbacks because you're basic get optimistic updates on the front
Speaker 4: end for free. But that's kind of that's a way
Speaker 4: more advanced topic that I want to get into at
Speaker 4: this point. Another thing is like if you need some
Speaker 4: of the more advanced bread and butter database features like
Speaker 4: in DCS over huge amounts of data, full text search,
Speaker 4: that's something that we haven't implemented as features yet, but
Speaker 4: they're not like impossible to do with local first. So
Speaker 4: this is an interesting example to kind of start giving
Speaker 4: you an idea of what kind of apps it's already
Speaker 4: really good for. Maybe where the boundary is like.
Speaker 3: Using index dB.
Speaker 4: Yes, that's what we use for in browser persistence. We're
Speaker 4: currently moving to OPFs, which lets us write directly to
Speaker 4: like an isolated file system on the client where we
Speaker 4: implement and storyteller.
Speaker 3: Is that implemented in browsers.
Speaker 4: Out Yes, that's widely supported. Not a lot of people
Speaker 4: know about it. The nice thing is if you use
Speaker 4: something like Jazz, that's like, I guess that's a major
Speaker 4: important point. If you use something like Jazz, you don't
Speaker 4: need to worry about the persistence and about the networking.
Speaker 4: You just manipulate objects basically, right, and it can have
Speaker 4: different storage implementations under the hood. It could communicate over
Speaker 4: web sockets, web party see in the future maybe something
Speaker 4: like quick and what that lets you do is like
Speaker 4: really quickly build apps on the abstraction level of like
Speaker 4: what do users do in my app and what kind
Speaker 4: of objects do they interact with? That's kind of all
Speaker 4: you have to think about and what you like. Because
Speaker 4: of the performance characteristics of local first, what you get
Speaker 4: away with very often if you have apps with like
Speaker 4: small teams where a couple people interact, you can literally
Speaker 4: keep all the data belonging to that team locally on
Speaker 4: each device. The only reason it's hard to scale, for example,
Speaker 4: productivity apps is because in a traditional model, the central
Speaker 4: database kind of needs to keep the data for every
Speaker 4: single team, which might be millions of them. With local first,
Speaker 4: each of the team's devices just needs to keep the
Speaker 4: state for the whole team. And Linear is actually a
Speaker 4: good example of an app they build their whole own
Speaker 4: local first technology and infrastructure. They keep all of your
Speaker 4: team's issues locally on the clent, and that gives you
Speaker 4: incredibly fast you X interaction on the client. We see
Speaker 4: with a lot of Jazz apps where people ask us like, look,
Speaker 4: I want to implement search in my app, so for that,
Speaker 4: I need an index, right and so far in every
Speaker 4: case you can literally just brute force your way over
Speaker 4: every single object in memory, and it's way faster than
Speaker 4: any like search feature against an API that that you've
Speaker 4: seen in any other app. That's that's kind of what
Speaker 4: it's already really good at. Obviously.
Speaker 3: Yeah, I've noticed that, like so many times, people you know,
Speaker 3: they're thinking too much about optimization and they don't realize
Speaker 3: if you don't optimize this, like optimizing it in many
Speaker 3: cases makes it slower because then you're adding all the
Speaker 3: overhead of the algorithm in the sifting, and like if
Speaker 3: it's less than ten thousand items, if maybe one hundred
Speaker 3: thousand items, just like brute force it it's the fastest way.
Speaker 1: Well, where we start talking about trade offs, right, yeah, hey,
Speaker 1: this is really good up to this point and then
Speaker 1: not so great or in the other case, it's you know,
Speaker 1: now you're over this threshold, so now your optimal case
Speaker 1: is to use the tool, right.
Speaker 4: So so so let me draw the picture a bit
Speaker 4: further than so, what if you start having data sets
Speaker 4: that don't fit on a single client's device anymore. And
Speaker 4: that's also where we start seeing differences between Jazz tools
Speaker 4: and some of the other local first solutions because they
Speaker 4: are very much what I would call like sink the world,
Speaker 4: like you actually have to keep the entire state and
Speaker 4: the client, whereas Jazz from the beginning was built to
Speaker 4: support granular sync, where what it does by default that
Speaker 4: it just thinks whatever objects you're trying to display right now,
Speaker 4: and then over time you kind of accumulate everything that's
Speaker 4: important to that user, and you can like a big
Speaker 4: things again if you don't need them anymore. But that
Speaker 4: means that you can now have like a local first
Speaker 4: experience for the data that you're actually interested in, but
Speaker 4: you can still work with potentially infinite data sets, and
Speaker 4: then you can build You can build indices against tens
Speaker 4: of millions of objects, for example on a server work
Speaker 4: and then the index itself again becomes a sinkable object,
Speaker 4: so the client can create the index locally, see which
Speaker 4: objects it might need to load, and all of that
Speaker 4: is it's like not one extreme or the other. If
Speaker 4: you make local first granularly sinkable, you can actually create
Speaker 4: request and networking patterns under the hood that are very
Speaker 4: similar to traditional stacks with APIs. But again, you as
Speaker 4: a developer don't have to think about that. You just
Speaker 4: think about which objects do you want to have and
Speaker 4: kind of request them as needed, and it loads whatever
Speaker 4: you need.
Speaker 3: So personally, I just like to work with JSON and
Speaker 3: functions like I don't ever use I literally have never
Speaker 3: used JavaScript classes except for experimentally to learn about them.
Speaker 3: I have never shipped code with a JavaScript class because
Speaker 3: I just find that and I mean, to some degree
Speaker 3: it's the concept of functional programming, like the less state
Speaker 3: you have to deal with, the better off you are
Speaker 3: the easier it is to test. If I can just
Speaker 3: take here's a plane object, here's a plane function. I
Speaker 3: put the object and some options into the function. I
Speaker 3: get the same result out every time. You know, it's
Speaker 3: very grug brain dev type stuff.
Speaker 4: And I like.
Speaker 3: The rest ish APIs. I like rest ish APIs because
Speaker 3: they're very very simple to reason about. Like if I
Speaker 3: I open up my network console, I can see what's happening.
Speaker 3: I know what's going on. I like SQL databases because
Speaker 3: they're very simple and proven. And I personally am am
Speaker 3: pretty resistant to things that require a lot of state
Speaker 3: management or require a lot of bespoke code structure. So
Speaker 3: is this something I mean, it sounds like it sounds
Speaker 3: like from what I'm hearing, this is very opinionated. It's
Speaker 3: like you buy into this way of doing it and
Speaker 3: you're going to adopt it, which I think is great.
Speaker 3: It's probably not something that I personally latch onto. But
Speaker 3: I do really really believe that, you know, if you're
Speaker 3: gonna if you're gonna make something really great, yeah, integrate
Speaker 3: it and just tell people they have to buy in.
Speaker 3: But I'm I'm not sure if I'm representing that correctly.
Speaker 3: Is this like a very streamlined, top to bottom solution.
Speaker 3: Or is this something where I can kind of take
Speaker 3: the approach of just plain objects and plain functions and
Speaker 3: build an application where I'm essentially replacing my res diish
Speaker 3: calls with jazz Ish calls.
Speaker 4: Right, so you're mentioning a bunch of important things there,
Speaker 4: and let me maybe start from what jazz consists of.
Speaker 4: It's kind of two layers. It's Jazz, which is like
Speaker 4: the opinionated framework, and then below that a protocol which
Speaker 4: is called CO Jason. I haven't written much about that yet.
Speaker 4: It's because it's so far it's just like internals of
Speaker 4: the framework, but it will be an open standard which
Speaker 4: defines how what I'm calling CO values work. Which these
Speaker 4: are your new primitives, and they are very much like
Speaker 4: they're supposed to be, just like collaborative Jason. You have objects,
Speaker 4: you have lists, and a bunch of other things for
Speaker 4: like text and rich text. But it's basically what if
Speaker 4: what if? Yeah, what if Jason was just collaborative? And
Speaker 4: that's your abstraction. It like, if you read it, it
Speaker 4: looks just like Plaine Jason. If you write to it,
Speaker 4: you kind of have the choice between two different APIs,
Speaker 4: and that's where we get into the higher level opinionated thing.
Speaker 4: What Jazz implements is something very similar to and like react.
Speaker 4: People with no libraries like mobs, where like you know
Speaker 4: and React, even with like just used with use state,
Speaker 4: you get like the current readable version of the state
Speaker 4: and an update the function. And that's basically what using
Speaker 4: Jazz is like currently. It even exposes a mutable API
Speaker 4: where you can literally just do like object dot property
Speaker 4: equals something and it will update it under the hood.
Speaker 4: But we'll probably move to something more. React is where
Speaker 4: it's like you get you subscribe to a collaborative value,
Speaker 4: you get a readable version of that every time something
Speaker 4: happens to it, and if you want to mutate it,
Speaker 4: use this update your function in which you can mutated.
Speaker 4: That's what replaces either your rest calls or what replaces
Speaker 4: your local state updates. That all just becomes one. And
Speaker 4: the nice thing is you just subscribe to updates, whether
Speaker 4: they come from locally because you edited the object, or
Speaker 4: whether they come from other users who are like remotely
Speaker 4: changing that same object. And in new subscription you can
Speaker 4: update your UI. Obviously, again with something like React, that
Speaker 4: ties directly into the render loop like it just rerenders
Speaker 4: your component. But there's also Jazz Browser if you want
Speaker 4: to use it and plain JavaScript. You just have a
Speaker 4: subscribe callback in there. You can do to the dorm
Speaker 4: whatever you want based on the newest version of that value.
Speaker 4: That's as simple as it is. What Jazz as a
Speaker 4: framework introduces to kind of structure your applications more almost
Speaker 4: in like a rail sense, is that it has this
Speaker 4: notion of schemas, which are similar to database schemas, where
Speaker 4: you say, like, look, these are the kinds of objects
Speaker 4: that I have in my app. They have these properties
Speaker 4: with these types. Jazz has chosen to represent these schemas
Speaker 4: using classes because it's way easier in Typescript to have
Speaker 4: classes because you can refer to them as a type
Speaker 4: and as a value. So we can kind of use
Speaker 4: this schema information both at typing time so we can
Speaker 4: give you nice type inference for your apps objects, as
Speaker 4: well as at run time to do validation and stuff
Speaker 4: like that. We've noticed that even just seeing the class
Speaker 4: syntex throws a lot of people off, So in the
Speaker 4: next version of the API will probably move to something
Speaker 4: that makes it look even more like the plane data
Speaker 4: that it is really but yeah, under the hood, it
Speaker 4: is really like collaborative Jason like objects that just have
Speaker 4: this editing and merging implemented. And my hope is with
Speaker 4: the protocol becoming open that not only might there be
Speaker 4: other frameworks on top of it that might different API
Speaker 4: designed choices but are still like wire compatable, but it
Speaker 4: can also be it would also be really easy to
Speaker 4: port it to other programming languages and environments, because one
Speaker 4: very interesting thing you can do is you cannot just
Speaker 4: write client applications with Jazz. You can write server workers. Said, well,
Speaker 4: that's also just listen to these co values can do
Speaker 4: some external side effects to talk to third party APIs,
Speaker 4: or they could receive a web hook request and in
Speaker 4: response mutator co value which done some cliency. And right
Speaker 4: now you can kind of only write them a note
Speaker 4: Jazz because right now Jazz is only implemented in Typescript.
Speaker 4: But if the protocol is open, there could then be
Speaker 4: like cojacent for Go or for Rust or for like
Speaker 4: whatever language you want, and you could write these complex
Speaker 4: systems that all use this really nice model of collaborative
Speaker 4: values and no one has to think about transport or persistems.
Speaker 2: Yeah, Sevin.
Speaker 3: I've been wondering about the back end part of this.
Speaker 3: Do I run a Jazz surve or can I can
Speaker 3: I use my SQL database and there's a Jazz adapter
Speaker 3: for the CRDT stuff to to get things in line,
Speaker 3: or what what does that look like? What's the what
Speaker 3: does my server side look like?
Speaker 4: Yeah? So yeah, it's important to be precisely and this
Speaker 4: is not going to be very Jazz specific because not
Speaker 4: a lot of the other local first solutions have a
Speaker 4: back end story. Obviously, everyone needs to have some kind
Speaker 4: of back end to to sync the co values and
Speaker 4: to persist them in the cloud. And in Jazz, this
Speaker 4: is what I call the sink and Storage server. That
Speaker 4: is a process that you can run yourself right now.
Speaker 4: It's implemented and not Jazz. It's open source. It persists
Speaker 4: the history of the co values into esculate and the future.
Speaker 4: It will persist it directly onto the disk. But that's
Speaker 4: not really a format that you can interact with it like,
Speaker 4: it's just like primitive internal data basically. So that's one thing.
Speaker 4: And like Jazz tools, my company, Garden Computing, is running
Speaker 4: the sink and Storage Server as a service like as
Speaker 4: infrastructure that you can subscribe to, has a free tier
Speaker 4: and so on. What's nice about that is if you
Speaker 4: use that, you can just start building an app and
Speaker 4: basically only write front end code and it sinks and persists.
Speaker 4: Do that and you have a whole functioning app with
Speaker 4: multiplayer and everything. But again you're not locked in. It's
Speaker 4: open source and so on.
Speaker 3: Separately from that, yeah, oh no, go ahead, you finish.
Speaker 4: Yeah, So that's just for like sinking the co values
Speaker 4: to everyone who needs them and making sure that they're
Speaker 4: persisted in the cloud. Right. What you might want to
Speaker 4: do is to have what I call a back end
Speaker 4: worker in Jazz, which is actually also a client to
Speaker 4: the sink and storage infrastructure that just happens to run
Speaker 4: on a server. So that could be a little note
Speaker 4: jazz script for example. And what that lets you do is,
Speaker 4: like I said earlier, you can do server side things
Speaker 4: in reaction to CO values changing, or you can create
Speaker 4: co values in reaction to getting something like HGTP requests.
Speaker 4: And that's kind of one way in which you can
Speaker 4: connect jazz date to the external world. One thing you
Speaker 4: might want to do in a server worker, for example,
Speaker 4: is to take jazz state and it's like high level
Speaker 4: structured form and replicate it the current state into like
Speaker 4: a traditional scale database, either because you want to connect
Speaker 4: it to an old part of your app that uses
Speaker 4: JAS and you want the jazz state to be integrated
Speaker 4: with that, or you might want to run some queries
Speaker 4: that like that particular database is very good at. For example,
Speaker 4: one app someone is building with jazz right now, they
Speaker 4: use Jazz for like ninety nine percent of it, but
Speaker 4: then they want to do some really deep analytics on
Speaker 4: all the user interactions that ever happen, and that's just
Speaker 4: not something that Jazz is very good or fasted yet.
Speaker 4: So what they do is they have this like background
Speaker 4: process that sings jazz state in DUCTV, which is really
Speaker 4: good at these kinds of curse. So that's stuff that
Speaker 4: you can do that that's kind of your adapter to
Speaker 4: the XCEL.
Speaker 1: Well there, that's that's really interesting. Yeah, I'm just I
Speaker 1: was gonna ask about the back end too. So that's interesting,
Speaker 1: and I like the idea of possibly having some driver
Speaker 1: for other systems, right, I mean, you know, people on
Speaker 1: the show know that a lot of the back end
Speaker 1: I do is Ruby on rails, and so it's interesting
Speaker 1: just to kind of have that, you know, I you know,
Speaker 1: eventually being able to feed it into my Rails app
Speaker 1: or whatever else exactly just be able to process it there.
Speaker 1: One of the things that I'm getting more into these
Speaker 1: days is running things over a web socket and so
Speaker 1: instead of having the worker kind of send these updates
Speaker 1: over ar rest API or whatever, also being able to
Speaker 1: you know, kind of stream them over the socket and
Speaker 1: get responses over the socket. And I'm assuming that that's
Speaker 1: either something you've got or something you're working on.
Speaker 4: So that part is like, for example, let's take the
Speaker 4: example of a Rails app, like, this is something that
Speaker 4: I want to have really good libraries and patterns for
Speaker 4: which we don't have yet, but it is something that
Speaker 4: you could build by hand right now, and it wouldn't
Speaker 4: be that right, and obviously we would help you. So
Speaker 4: for your Rails at probably what would be the best
Speaker 4: example is, Okay, you're pretty happy with your app. It
Speaker 4: works great, but you want to add something that's like
Speaker 4: really really real time where you're like, oh, do I
Speaker 4: need a web socket now, how does that integrate with Rails.
Speaker 4: What you could do is basically just build this feature
Speaker 4: with Jazz and that will work. Perfectly internally for that feature,
Speaker 4: but there might be some parts of the state that
Speaker 4: the rest of your existing app is interested in. Right,
Speaker 4: So what you can do then is, since we don't
Speaker 4: have cojacent for rubiat, you could run a little note
Speaker 4: jazz server that subscribes to the Jazz state and at
Speaker 4: least puts like the current version of the state into
Speaker 4: your SKL database, where then rails can pick it up
Speaker 4: and render it and existing out and that that should
Speaker 4: work quite well.
Speaker 2: So one other thing that I'm looking at here is.
Speaker 1: It sounds like there are advantages that are sort of obvious,
Speaker 1: I guess with this kind of a setup, right, I mean,
Speaker 1: if if I'm just mostly managing stuff like it's a
Speaker 1: local setup, then I essentially eliminate all of the network stuff. Right,
Speaker 1: So if if I'm on a slow network, or if
Speaker 1: my connection dies, or if even if I'm not on
Speaker 1: a slow network, and I just don't want to wait
Speaker 1: to get a response from the server and I don't
Speaker 1: need one per se, right because it's just sinking stuff
Speaker 1: back and forth, you know, it seems like it kind
Speaker 1: of gives me some resiliency and speed and performance.
Speaker 2: On top of everything else that I might be doing.
Speaker 4: That's a that's like the funny thing is like everyone
Speaker 4: in the local first sphere kind of came to it
Speaker 4: from that like user experience promises it obviously has, but
Speaker 4: then starting to build apps with it, you realize that
Speaker 4: the big thing about it is really the different developer experience.
Speaker 4: Because sure, it's great that the app is snappier, works
Speaker 4: off line and so on or over sketchy connections, which
Speaker 4: is often even trickier than offline. But the main thing
Speaker 4: is that by not having to worry about requests or
Speaker 4: back end or like making sure the back end now
Speaker 4: supports an endpoint that gives you the data that you
Speaker 4: need to render this thing, you're just like in one context,
Speaker 4: you build your front then and the data model right
Speaker 4: next to each other, and you can iterate really really quickly,
Speaker 4: and you just think about what objects do they need
Speaker 4: to create or delete or I mean, if you're coming
Speaker 4: from like a Ruby on rails background, that's actually what
Speaker 4: I started cutting my teeth. As a developer. You kind
Speaker 4: of have have that experience there, but on the back
Speaker 4: end and the back and also does the rendering, so
Speaker 4: local first lets you have that on the client, you
Speaker 4: meaningfully can create modified objects, and often what that looks
Speaker 4: like is like it looks almost illegal, like in a
Speaker 4: in a in a button on clickhandle, you create like
Speaker 4: a whole team and like documents and then whatever you
Speaker 4: might have in your app. That's that's the developer experience
Speaker 4: it gives you. And it's hard to understate before you've
Speaker 4: tried to help yourself just how quickly that lets you
Speaker 4: build apps. However, one component that enables that really that
Speaker 4: we haven't really talked about yet, that I can go
Speaker 4: into more detail if you if you want this, it's
Speaker 4: really it's a really tricky question. How do you do
Speaker 4: user identity and permissions in a local first way, because
Speaker 4: that's not really answered by like just the simple way
Speaker 4: of light it out so far. Let me know if
Speaker 4: you want to go into that or if you have
Speaker 4: some other.
Speaker 1: That is interesting because you know, as you're saying, right,
Speaker 1: if you have that kind of centralized back end system,
Speaker 1: right then it can kind of know who's sending it stuff, right, But.
Speaker 2: On the front end, yeah, that's that's a little bit different.
Speaker 1: And then I'd also like to talk a little bit about,
Speaker 1: you know, maybe doing peer to peer where you don't
Speaker 1: even need that centralized server beyond hey, who else is
Speaker 1: working with the documents? And so if you're doing that,
Speaker 1: then it gets even more tricky because then it who
Speaker 1: do I trust it coming from from across the internet
Speaker 1: right without even having it, you know, a clear identity
Speaker 1: I attached from that centralized server. So yeah, how do
Speaker 1: you think about those issues?
Speaker 4: So jazz implements something and again that's also part of
Speaker 4: the online protocol cojacent, which I call local first permissions,
Speaker 4: and this is maybe beyond all the other details of
Speaker 4: FOG exectly, it's implemented the biggest difference between jazz as
Speaker 4: and other local first things because the approach that many
Speaker 4: others take is either look, the author and permissions question
Speaker 4: is out of scope. We just give you the shared state,
Speaker 4: you figure it out yourself, or in many of the
Speaker 4: other cases where they also have folset services, they kind
Speaker 4: of they do the local first state. But then identity
Speaker 4: and auth is still traditional in a centralized way, which
Speaker 4: works okay for a lot of things, but it kind
Speaker 4: of makes you trade off some of the local first
Speaker 4: properties you could otherwise have, and it's tricky to do, like, well,
Speaker 4: how do you do offline them? Because then you're not
Speaker 4: really authenticated against the back end that at least checks
Speaker 4: the permissions and so on. So that's tricky. So for
Speaker 4: that reason, what I decided to do when I build
Speaker 4: Jazz is like I saw the crdts that give you
Speaker 4: the shared sit I was like, damn, this is amazing.
Speaker 4: I want to build everything like that, but it feels
Speaker 4: like only part of the puzzle. You also need to
Speaker 4: solve user identity and permissions in a similar way. So
Speaker 4: what I've done there is to couple cred keys with
Speaker 4: basically good old public key cryptography, where a user in
Speaker 4: Jazz is just the cryptographic keyper and we'll talk in
Speaker 4: a second about where that comes from. And when you
Speaker 4: make changes to an object, you actually sign those changes
Speaker 4: with your public key, which means that everyone else who
Speaker 4: gets your changes, no matter how they got hold of them,
Speaker 4: whether it was to a centralized infrastructure or peer to
Speaker 4: pe or whatever, they see the signature and they know, okay,
Speaker 4: this was definitely Charles who made that at it. That's
Speaker 4: kind of the right access part. And for the read access,
Speaker 4: what you do is you encrypt your changes and then
Speaker 4: you only give the key to people who you want
Speaker 4: to see that object. Right. That means that you can
Speaker 4: now actually in a local first way, so on the
Speaker 4: client synchronously when you create objects and when you write
Speaker 4: to them by signing and encrypting them, you know for
Speaker 4: sure that the permissions have been set up correctly and
Speaker 4: you don't need to trust the sinking back end to
Speaker 4: do that for you. That just needs to exchange the edits,
Speaker 4: or you might send them peer to peer, and all
Speaker 4: the edits that you receive you can verify who did them.
Speaker 4: It gets a bit more complicated then, because you might
Speaker 4: want to have complex permission structures, like teams of certain
Speaker 4: people with different roles. So what Jazz implements there is
Speaker 4: something called groups, which is basically a scope for permissions
Speaker 4: where you can say, like, look, this person with this
Speaker 4: key pair is the admin. They added someone who is
Speaker 4: a writer and someone who is a reader, and Jazz
Speaker 4: under the hood make sure that when you receive edits,
Speaker 4: for example, not only is it check that they have
Speaker 4: a valid signature, but that they have a valid signature
Speaker 4: by someone who has the correct role in that team.
Speaker 4: The teams themselves are also like CRDT CO values, so
Speaker 4: they get sing together with everything else, and you can
Speaker 4: even nest groups so like they can inherit from each other,
Speaker 4: and with that abstraction you can build basically arbitrarily complex
Speaker 4: setups like in no For example, you might have a
Speaker 4: team and you want everyone on the team to be
Speaker 4: able to read and addit every page by default, but
Speaker 4: then you might want to add hoc invite someone just
Speaker 4: to that page to also write it who's not otherwise
Speaker 4: in your team. And by using that structure of inheriting groups,
Speaker 4: you can build all of that in a completely local
Speaker 4: first way without having to trust any back end, and
Speaker 4: you can even verify every single edit yourself locally. That's
Speaker 4: very unique, and like one of the hardest parts of
Speaker 4: that was to make that fast enough to be able
Speaker 4: to compete with a traditional trusted back end.
Speaker 2: Yeah, I'm trying to.
Speaker 1: I don't want to like get into the weeds of
Speaker 1: how it's all implemented.
Speaker 2: You know, the the idea.
Speaker 1: Of cryptogaphic, cryptographic you know, asynchronous public private key pairs.
Speaker 1: I mean people use them all the time, they just
Speaker 1: don't know it a lot of the times. You know,
Speaker 1: whether it's your HTTPS connection back to the server that's
Speaker 1: using the same ideas, the same technology essentially when you
Speaker 1: in yeah.
Speaker 3: It's all in web crypto and everything.
Speaker 2: I mean aspect the people use.
Speaker 1: So yeah, I mean, and I like the idea in
Speaker 1: these completely yeah.
Speaker 4: So it's completely abstracted away from you. That's the nice thing.
Speaker 4: I'm just telling you this as in like, this is
Speaker 4: how it works. This is how you can make the
Speaker 4: permissions local. First, but to you as a developer, you
Speaker 4: you basically you define your groups and it feels like
Speaker 4: you're said like drop Box like permissions and you're saying, oh,
Speaker 4: this acne has this role. The other thing that I
Speaker 4: didn't mention is like, yeah.
Speaker 1: So I guess the other question is, I mean, is
Speaker 1: there permissions around time?
Speaker 2: Right?
Speaker 1: So I add somebody temporarily to a group and then
Speaker 1: I pull them back out. All the changes during that
Speaker 1: time period are legal right to apply those, But now
Speaker 1: I've pulled them back out of the group, so if
Speaker 1: they send another update, I don't want it added.
Speaker 2: And so it handles all that too.
Speaker 4: Over time, it and handles all that because the groups
Speaker 4: themselves are cerdts, so they are full histories of whatever
Speaker 4: happened to them. So everyone can be like, oh, they
Speaker 4: were a member until then and then they got kicked out,
Speaker 4: and for the read access. What happens is you just
Speaker 4: you rotate the key and give the new key to
Speaker 4: everyone except the person who get kicked out.
Speaker 3: Right.
Speaker 4: But again, like this is getting into details, you as
Speaker 4: a developer don't really need to carry You just use Dropbox,
Speaker 4: like at this account as a writer, at this account,
Speaker 4: as a reader, it's really easy to build you you
Speaker 4: I around that to have like your little team thing.
Speaker 4: And in terms of because I kind of glanced over that,
Speaker 4: where the key pairs come from, because obviously you don't
Speaker 4: want your users to be handling key pairs, like no
Speaker 4: one uses crypto wallets for that reason. So Jazz kind
Speaker 4: of lets you have pluggable what it calls off providers,
Speaker 4: where it has a couple of native ones that are
Speaker 4: really nice. My favorite one is passkey off, where we're
Speaker 4: using the past key feature to actually store the key pair.
Speaker 4: So the user experience to the user is like it
Speaker 4: just prompts you for like touch ID or face ID,
Speaker 4: but then actually stores the key on your device and
Speaker 4: only you have that. But it still gets If you're
Speaker 4: using Apple devices, it gets sync between them. If you're
Speaker 4: using Chrome and Endry, it gets SYNCD between them. So
Speaker 4: you actually have like an end to end encrypted app
Speaker 4: at that point. But you can also do something more traditional,
Speaker 4: where like if you want to use something like Clerk
Speaker 4: or Zero, we have an adapter for that where the
Speaker 4: key pair gets stored and the user's private metadata, so
Speaker 4: after they look in Clerk, for example, gives that to
Speaker 4: the front and the front can then give that to
Speaker 4: Jazz as the key pair. That means that basically Clerk
Speaker 4: and any admins you might have in Clerk are trusted
Speaker 4: with the keypairs for all the users. But that's kind
Speaker 4: of the case for any traditional web app already anyway,
Speaker 4: So you kind of you have the choice, like how
Speaker 4: deep you want to go there. The nice thing is
Speaker 4: that even in this setup, neither the app developer nor
Speaker 4: the users have to trust me running the sink and
Speaker 4: storage infrastructure. Like I still never see your data and
Speaker 4: plain text, I don't have your keys, but I can
Speaker 4: still do the sinking for you.
Speaker 2: Cool.
Speaker 3: Yeah, that's that's one issue that Uh, losing private keys
Speaker 3: means losing data permanently because there is no email recovery
Speaker 3: for that. Now, if you're storing it in Clerk, then
Speaker 3: you have a reasonably high assurance that that is going
Speaker 3: to be there. Tomorrow. But that's that's something that's a
Speaker 3: little bit yeah, but I think I think, I mean, obviously,
Speaker 3: if you're trusting clerk for your users, you're already trusting
Speaker 3: clerk for your users, So I wouldn't I wouldn't lay
Speaker 3: anything additional there, but I would I would seriously warn
Speaker 3: anyone from trusting past keys as a primary source, because
Speaker 3: I've done quite a bit of experimentation with it. As
Speaker 3: I imagine you're well aware of the the drawbacks of
Speaker 3: it and the way that browsers implement it differently, the
Speaker 3: differences between the iCloud ID versus the browser ID. And
Speaker 3: you could very very easily overwrite your private key, for example,
Speaker 3: for iCloud and not not knowingly, and and perhaps you're
Speaker 3: taking I know that there's certain measures that you can
Speaker 3: take that will prevent the private key from being overwritten
Speaker 3: and produce an error instead. But that's one I'm not
Speaker 3: I'm not yet comfortable with that. I don't feel like
Speaker 3: that one's sure for that use, cause I think it's
Speaker 3: excellent as it's a built in password manager. Pass keys
Speaker 3: as a password manager built in. I'm one hundred percent
Speaker 3: on board. It's mature, it's good it's ready, use it go.
Speaker 3: But as something for storing, you know, you've got what
Speaker 3: sixty four bytes of arbitrary data you can store, and yeah,
Speaker 3: it's easy to overwrite that.
Speaker 4: Yeah, I mean to be honest, I've not encountered a
Speaker 4: situation where that happened, but it's it's good to know
Speaker 4: about that, and for that reason, it like, I think
Speaker 4: the bigger issue is actually still that a lot of
Speaker 4: people just aren't familiar with them, and for that reason alone,
Speaker 4: it's it's like an ago for a lot of apps.
Speaker 4: I think there is a bit of an overlap here
Speaker 4: where like if someone really wants to build an end
Speaker 4: to and encrypted app, probably they could. That's the kind
Speaker 4: of app where the users would know how to use passkeys.
Speaker 4: But right now, yeah, that's that's just something that we offer.
Speaker 4: Most people want like a more traditional method.
Speaker 3: Anyways, Well, I think it's great and I love the
Speaker 3: way that it's being implemented and rolled out across the
Speaker 3: industry right now. It's very seamless. I mean typically the
Speaker 3: way that it's happening is you just do your normal
Speaker 3: sign in and then it pops up and says, you know,
Speaker 3: use Windows Hello, or use face ID and so a
Speaker 3: lot of people are using passkeys without even knowing that
Speaker 3: they're using passkeys because they've already been seeing it on
Speaker 3: their phone, they've already been seen it on the Windows computer,
Speaker 3: and then it just pops up in their browser like, oh, okay,
Speaker 3: it's the same thing I've been doing for the last
Speaker 3: five years on my phone.
Speaker 4: Totally. Maybe that's what's nice, yeah, exactly, but people are
Speaker 4: getting familiar with it. What's nice about Jazz is like
Speaker 4: I mentioned that the ofth providers are pluggable and jazz,
Speaker 4: and therefore your app really only cares about the account
Speaker 4: and the keypair. So you can totally start building your
Speaker 4: app against Like with one off provider, later on switch
Speaker 4: them and change absolutely nothing inside your app. You can
Speaker 4: also offer your app to like enterprises with weird custom
Speaker 4: as his own needs or whatever, and nothing about your
Speaker 4: app's logic around how accounts work, how teams and permissions
Speaker 4: work has to change, which is something really nice because
Speaker 4: usually this is a huge topic and your like permission
Speaker 4: model in your back end is very tightly coupled to
Speaker 4: kind of the off provider that you choose to use.
Speaker 3: So do you have a back office for this to
Speaker 3: manage things like a UI by which a person who's
Speaker 3: administrating an application can get access to what permissions exist
Speaker 3: and what groups exist and such.
Speaker 4: Kind of. But we want to do a lot better there.
Speaker 4: So there is something called the Jazz inspector, which is
Speaker 4: if you have to keep it for an account, you
Speaker 4: can kind of remotely look into all of the state
Speaker 4: that's in that account. Again, because of all permissions work
Speaker 4: as opposed to traditional database where admins can just see
Speaker 4: all the data. Ever, by default, in Jazz the user
Speaker 4: kind of has to opt into letting you look into
Speaker 4: their account. But if they do that, and you might
Speaker 4: even hardcode into your app that that happens by default.
Speaker 4: A typical pattern in apps that want the more traditional
Speaker 4: permission model is that they just create an admin account
Speaker 4: that admins have, that the server worker has, and every
Speaker 4: user automatically invites that to all of their groups and
Speaker 4: then you get like this access pattern that's very similar
Speaker 4: where you can just see all your users data. But
Speaker 4: we yeah, so that's kind of the mechanics of it.
Speaker 4: What we're working on right now is kind of make
Speaker 4: that a more full fledged browser. For example, if you
Speaker 4: use jazz cloud as a service and you create an
Speaker 4: app in there, and people start creating objects on their
Speaker 4: clients that like if they opt in, or if you
Speaker 4: enable the default opt in, you can very nicely browse
Speaker 4: that as if you were looking at like a database
Speaker 4: you high basically.
Speaker 3: So that's that's actually really interesting. I mean, I think
Speaker 3: that the reason most people develop apps is because they
Speaker 3: want to aggregate user data so that they can manipulate
Speaker 3: it or sell it in some way. So the idea
Speaker 3: that by default the user data is private, I mean
Speaker 3: that seems like that appeals to a very niche set
Speaker 3: of applications, you know, like Telegram, some maybe some cryptocurrency wallets.
Speaker 3: But I mean, don't don't most people that build apps
Speaker 3: don't they want you know, like even Slack right in Discord,
Speaker 3: like they get to see all the messages, you know,
Speaker 3: Like with Discord, all the messages are visible by the
Speaker 3: Discord admins. They get to train AI on them that
Speaker 3: you know, and say, like with Slack, anybody on the
Speaker 3: Slack team can look at any of the messages. Anybody
Speaker 3: who is an admin of your Slack group can look
Speaker 3: at all the messages. And that's I mean, that's generally
Speaker 3: considered a feature, not a bug. Although i personally like
Speaker 3: what you're saying, I personally am on board with, yeah,
Speaker 3: encrypt my data, but you know, like, is this what
Speaker 3: you think the market wants?
Speaker 4: So like, pessimistically, I agree with your statement that you
Speaker 4: just made, and this is why. Like again, to be precise,
Speaker 4: it's like it's the default on a protocol level that
Speaker 4: everything is encrypted, and what that means is that you
Speaker 4: can just as easily build that the same trusted model
Speaker 4: where the a provider can see all the data you
Speaker 4: put in there. The only difference is that this trust
Speaker 4: relationship is now explicit and verifiable, if that makes sense.
Speaker 4: And in this case, even like you would be like
Speaker 4: sure like Slack, if Slack to or decided to use
Speaker 4: Jazz for whatever reason, you'd be like, sure, Jazz, Slack
Speaker 4: admins can see all the data in my team. But
Speaker 4: like Garden Computing, who's running the Jazz service count that's
Speaker 4: already an improvement, right, and it still gives you, as
Speaker 4: the app developer, all the freedoms and flexibility that you
Speaker 4: had before. Interestingly, if you care about analytics type data,
Speaker 4: you get much more high fidelity analytics out of Jazz
Speaker 4: by default, because everything, every object has the full history,
Speaker 4: so without instrumenting your app in anyway or registering any
Speaker 4: custom events. Just in the in the dashboard is the
Speaker 4: way we'll expose it to is you can see like, oh,
Speaker 4: these five users from like these cities are working together
Speaker 4: on this object right now, or like this has been
Speaker 4: really hot over the last week, and these teams are
Speaker 4: collaborating like that in a like way that that schema
Speaker 4: aware of what the objects in your app are, and
Speaker 4: you get that for free just by like writing to
Speaker 4: the objects basically, So in that sense, it's almost gives
Speaker 4: you more data that you can exploit as an app developer.
Speaker 4: It's again just that the trust relationship is now explicit.
Speaker 3: So one thing you mentioned there the schema is how
Speaker 3: do you handle the migrations?
Speaker 4: This is literally the hardest question of local first, and
Speaker 4: anyone who's building a local first framework or something like
Speaker 4: that will tell you that. And that's like local first
Speaker 4: in general is like it makes a lot of things
Speaker 4: that used to be really hard really simple, and it
Speaker 4: makes some things that used to be really simple a
Speaker 4: bit awkward. And migrations is maybe the most awkward thing
Speaker 4: because you're now basically confronted with distributed migrations like different
Speaker 4: clients might update you up at different times but still
Speaker 4: interact with each other at the same time. It's a
Speaker 4: tricky problem. In what we've found so far is the
Speaker 4: best thing to do is to just change your mindset
Speaker 4: a little bit where you can't treat migrations anymore as
Speaker 4: does like stop the world, will change everything to this
Speaker 4: new thing and then continue the database. You have to
Speaker 4: treat it more as like protocol evolution, where you can
Speaker 4: only ever add new fields basically, and if you've built
Speaker 4: graph ql APIs that should be familiar to you. If
Speaker 4: you've done anything with proto buffs, that's kind of best
Speaker 4: practices there where in these cases you also expect clients
Speaker 4: with the old schemer interacting with you, So if you
Speaker 4: follow that same model, you'll be fine. And because it.
Speaker 3: Is there a way to expire data that's too old,
Speaker 3: like if the data is more than three months old,
Speaker 3: just expire it.
Speaker 4: That's that's a separate topic, which is deletion, which is
Speaker 4: also interesting because it local first, and I think jazz
Speaker 4: in particularly kind of takes a like soft delete stance
Speaker 4: by default because you keep all the history. Anyways, most
Speaker 4: of the time you just want to soft the lead.
Speaker 4: Now there are cases where, for regulary reasons or because
Speaker 4: it's really a lot of data, you want to delete
Speaker 4: things permanently, and you are able to do that. You
Speaker 4: basically you mark the object as deleted, and every client
Speaker 4: and the sinking back will actually delete it.
Speaker 3: That's not what I meant, Okay, although I'm glad you
Speaker 3: answered that question too. What I mean is, like all
Speaker 3: of us that are developing web apps, we all come
Speaker 3: into this case where we change some property that's you know,
Speaker 3: I think one of the one of the probably more
Speaker 3: common ones is if you change anything that's in a
Speaker 3: cookie because cookies last forever, right, or you change you
Speaker 3: change some object that can exist out in the wild
Speaker 3: that's maybe not part of the scheme, as just an
Speaker 3: ad hoc object, and then you get this problem where
Speaker 3: this user calls in and they can't log in, or
Speaker 3: at least they don't have the experience of logging. Maybe
Speaker 3: the authentication process succeeds, but their app is just like
Speaker 3: stuck in this error state. And then the only way
Speaker 3: to solve it is that you have to clear out
Speaker 3: the cab because there's some little property where it's triggering
Speaker 3: an education your app where it's like if this, then
Speaker 3: do that, and so it passes the first check, and
Speaker 3: then it's you know, if that, then do this, and
Speaker 3: then it fails and it's in this limbo state that
Speaker 3: you didn't expect because some user that logged in three
Speaker 3: months ago that still has some local object in local
Speaker 3: storage related to how the off object used to look
Speaker 3: like or how their profile object used to look like.
Speaker 3: It's the new version of the application code, and it
Speaker 3: can't like it can't regulate itself, right, like you know
Speaker 3: what I'm talking about.
Speaker 4: I think so, But I think if you follow that
Speaker 4: principle strictly of only adding stuff that shouldn't happen, you
Speaker 4: might make mistakes. Obviously, you might make mistakes. And so
Speaker 4: your question is mostly like what if a migration is broken?
Speaker 2: Right?
Speaker 3: Yeah, like is there a well it more it's it's like,
Speaker 3: I want to fail safe, right, So so one of
Speaker 3: the things, you know, Yes, it would be great if
Speaker 3: if we were more perfect coders, and I want that,
Speaker 3: and I want people to be more delivered in their
Speaker 3: decisions and to be more mindful of you know, what
Speaker 3: state they're storing in local storage or INDEXDB or their
Speaker 3: database or whatever. It is the reality of the situation
Speaker 3: is most people are not that mindful, and everyone makes mistakes,
Speaker 3: and so when when like one fails safe to have that,
Speaker 3: Like I just working with a buddy on a project,
Speaker 3: I said, okay, if you get a four to oh one,
Speaker 3: clear out all the data and log the user out.
Speaker 3: If you get a five hundred, clear out all the
Speaker 3: data and log the user out. Because we're trying to
Speaker 3: build this in a way that we actually don't have errors.
Speaker 3: But if we do encounter an error, we just want
Speaker 3: to say, okay, wipe out all of the local state
Speaker 3: so that we don't end up in a loop where
Speaker 3: the person's trying to log in but because they had
Speaker 3: a you know, that's the kind of thing I'm saying
Speaker 3: is providing a fail safe to say, hey, if the
Speaker 3: version has triggered from three to twenty seven, that's more
Speaker 3: than three version changes, So just wipe out all the
Speaker 3: local state.
Speaker 4: So that's actually like a move that you would be
Speaker 4: able to do in a migration, where like and again
Speaker 4: to be precise here, the migrations are a framework feature,
Speaker 4: not a protocol feature. Right, the protocol just gives you
Speaker 4: persistent arbitrary jason. Basically that you can collaborate on the
Speaker 4: migrations is just one part where you can modify, like
Speaker 4: one place where you can modify these objects. So and
Speaker 4: right now we take this wild West approach where we're like,
Speaker 4: you can literally do whatever in a migration. You can
Speaker 4: mutate the objects any way you want, and it's up
Speaker 4: to you to follow these best principles. But that also
Speaker 4: means that if you botch something or there's some weird
Speaker 4: unexpected edge case that you didn't think about, you can
Speaker 4: after the fact just be like, look, if the state
Speaker 4: that we're getting at the beginning of the migration doesn't
Speaker 4: look like any of these standard steps that we take
Speaker 4: in the happy path, just you know, just throw it away,
Speaker 4: like whatever, that's something that you can do in a
Speaker 4: jazz migration.
Speaker 1: Yeah, I was thinking something more along the lines of,
Speaker 1: you know, let's say that I was putting some data
Speaker 1: into these data objects that I.
Speaker 2: Found out, Oh, under.
Speaker 1: This regulation for the field I'm in, right, I'm not
Speaker 1: supposed to store the credit card number, right. I think
Speaker 1: I think we all generally know this, but yeah, you know,
Speaker 1: or you know, I have some you know under HIPPA
Speaker 1: or some of the other GDPR or whatever. Right this
Speaker 1: this is the kind of personally identifiable information that I've
Speaker 1: got to be like extra and especially careful with, and
Speaker 1: so having it on a local storage, you know, maybe
Speaker 1: maybe that you know, for whatever reason, I have to
Speaker 1: have in some kind of controlled back end, and so
Speaker 1: I'm just gonna have to, you know, do end runs
Speaker 1: to the server for that kind of a thing. Everything
Speaker 1: else I can run local first, right, And so yeah,
Speaker 1: I'm thinking in that.
Speaker 2: Case, I may have a migration that says, hey, wipe
Speaker 2: out all of this, right, and it'd be nice.
Speaker 1: If I could do it on like a you know,
Speaker 1: it's like this object is migrating to this new version,
Speaker 1: and so therefore just forget all of the credit card
Speaker 1: numbers rather than wipe out all of.
Speaker 4: The oh yeah, yeah, sure.
Speaker 2: Or whatever outlet, right, something like that.
Speaker 4: Okay, this is going to be a bit confusing because
Speaker 4: I wanted to talk about something related, but yours is
Speaker 4: kind of like almost the worst case. And then your case,
Speaker 4: what you would do is exactly like you would do
Speaker 4: like a patch up migration that actually does hard deletes, right, yeah,
Speaker 4: and that's something that you'll be able to do as well.
Speaker 4: Most of the times you would do a patch up
Speaker 4: migration that does soft deletes, right. And what's nice about that,
Speaker 4: by the way, is that if if you mess up
Speaker 4: the patch migration as well, which trust me I've done
Speaker 4: many times, and you can unsoft deleted and you can
Speaker 4: look at the whole history of botch patch migrations that
Speaker 4: happen to it and find something useful somewhere in there,
Speaker 4: because that's what you do with the traditional database, right,
Speaker 4: You try your best to write reasonable migrations. If they
Speaker 4: utterly fail, you roll back or you write more migrations
Speaker 4: against it, and you do the same on a local level.
Speaker 4: But yeah, I mean so far, I'm always honest, and
Speaker 4: I'm like, look, this is the trickiest part. This is
Speaker 4: the scariest part. So far, everyone who has built apps
Speaker 4: which jazz has been able to write these migrations correctly,
Speaker 4: even though we provide no guardrails. Yet. We're kind of
Speaker 4: in a stage where we're like, we give you all
Speaker 4: the tools and we wait for, like, what are the
Speaker 4: best practices around how to do migrations, and then introduce
Speaker 4: guardrails on a framework level. But so far it hasn't
Speaker 4: been an issue, despite these people changing their apps around
Speaker 4: quite a lot as they iterate on them.
Speaker 1: Right, Yeah, I wanted to because we're already almost at
Speaker 1: an hour. We try and keep these to an hour
Speaker 1: maybe a little more. We tend to go over the network.
Speaker 1: But anyway, one thing that I'm curious about then is
Speaker 1: AJ asked you, okay, you know, where is this.
Speaker 2: Not super well suited?
Speaker 1: What I'm curious about is, okay, so what kind of
Speaker 1: apps are people writing where you know, if they haven't
Speaker 1: figured it out already, they're going to be really well
Speaker 1: suited for this kind of a thing where they're going
Speaker 1: to look at it and go, oh, this solves a
Speaker 1: whole bunch of problems and makes my life easier as
Speaker 1: I developed this in the future.
Speaker 4: Right. So, what's fun about our current adults is that
Speaker 4: they're actually super diverse, and they're a good mix of
Speaker 4: like things that are obviously very good ideas local first too,
Speaker 4: like this is almost not local first at all. I
Speaker 4: can maybe very quickly mention some examples, but what it's
Speaker 4: best for right now is if you really care about
Speaker 4: a good offline first experience, if you want to build
Speaker 4: any kind of app that has collaboration, particularly if it's
Speaker 4: real time, but also if it's not real time, just
Speaker 4: like team abstractions, permissions, that sort of stuff way easier
Speaker 4: to express. Yeah, I think these are the ones where
Speaker 4: people get the most value out of jazz right now.
Speaker 4: And again, like what is jazz not good at? Honestly,
Speaker 4: the biggest thing right now is just like we're early
Speaker 4: documentation is lacking horribly. We're working on it. We're trying
Speaker 4: to patch that up by just providing good discord support basically,
Speaker 4: So that's the biggest thing. Like, if you really need it,
Speaker 4: you'll probably want to use it despite it having bad
Speaker 4: documentation for everything else, you probably only want to use
Speaker 4: it for an experiment to get familiar with it. That's
Speaker 4: kind of the main bottleneck right now. So in terms
Speaker 4: of the adopt is just to paint a picture. One
Speaker 4: of our earliest ones. They're building like an app for
Speaker 4: freelancers to collect invoices out of your cloud Flare, your
Speaker 4: AWS to then submit to tax authorities. But what they
Speaker 4: a is that actually locks into your AWS and your
Speaker 4: cloud Flare with you use the name of passwords, so
Speaker 4: you kind of you need to be able to trust
Speaker 4: that app as much as you would trust the password manager,
Speaker 4: and for them, obviously the whole permission and encryption thing
Speaker 4: was a godsend because they got all of that for free,
Speaker 4: and they wanted to just make it a single player
Speaker 4: experience in the beginning, just for individual freelancers. But because
Speaker 4: they build it with Jazz, they got like org features
Speaker 4: where you can invite someone from your team to also
Speaker 4: submit invoices by just adding a button basically, so this
Speaker 4: was like a very obvious fit. Maybe the most unobvious
Speaker 4: fit was a guy who's building a kind of social
Speaker 4: network with his team. It's called learn Anything, like a
Speaker 4: learn minus anything that xyz I think is the domain.
Speaker 4: It's like a mix between Reddit and quorra, kind of
Speaker 4: like a learning social network where you can be like, oh,
Speaker 4: I want to learn how to play the guitar or
Speaker 4: I want to learn rust, and it will have like
Speaker 4: a community curated list of like tutorials, polls, videos, and
Speaker 4: so on. So that's still like very much like a
Speaker 4: social network part and they decided to base their entire
Speaker 4: app as Jazz. That's the only database. So in their case,
Speaker 4: Jazz actually serves these initially static pages of content, and
Speaker 4: they already get like millions of visitors per week because
Speaker 4: they've got good SEO, so it's really stressing Jazz in
Speaker 4: a way that's not local firsts at all. It just
Speaker 4: takes a traditional back end database role. But then as
Speaker 4: a user, like probably in the beginning, you're just passive,
Speaker 4: but then you're like, oh, I want to start learning
Speaker 4: this and then track your progress as you read different articles.
Speaker 4: You can take your own notes in there, and then
Speaker 4: it magically transforms into this local first experience where you
Speaker 4: start having your own personal data that's local and really
Speaker 4: fast to interact with. But because they build it with Jazz,
Speaker 4: they didn't have to glue together different systems that are
Speaker 4: good at either of these. They could just use Jazz
Speaker 4: to represent all the data they have, whether it's like
Speaker 4: this global data across US or individual user data. Okay,
Speaker 4: these are kind of the two best examples I can
Speaker 4: think of. If people are really interested, you can check
Speaker 4: out some of my other podcasts where I list a
Speaker 4: couple more. But for the sake of time, I think
Speaker 4: that that gives us a good contrast.
Speaker 2: Cool.
Speaker 1: So, if people want to start building apps with Jazz themselves,
Speaker 1: I mean, what's the best way to do it? Just
Speaker 1: NPM install it and then spin up an app?
Speaker 2: Or is there more to it?
Speaker 4: So? What would recommend Yeah, basically, but because there's so
Speaker 4: many new concepts, I would really encourage people go check
Speaker 4: out the homepage that kind of gives you a quick overview,
Speaker 4: have a look at the documentation that exists, but most
Speaker 4: importantly check out the example apps because these should cover
Speaker 4: a good ground of stuff that you can do with
Speaker 4: jazz and just explain the best way possible how to
Speaker 4: set it up, how to define your schema, how do
Speaker 4: you do stuff like image uploads and lots of fun
Speaker 4: stuff like that, and then if you have any questions,
Speaker 4: hop on the discord, because right now we're in a face,
Speaker 4: like I said, where we just we sit down together
Speaker 4: with people trying things with jazz, answer their questions or
Speaker 4: even help them build their apps because we learn a
Speaker 4: lot from that and it is kind of it works,
Speaker 4: and it works right away. The nice thing is it
Speaker 4: is quite a little set up if you decide to
Speaker 4: use jazz Cloud, because you just start a front end
Speaker 4: project essentially, and then for whenever you get stuck or
Speaker 4: you have questions how to best build something, just just
Speaker 4: coming ask us on the discord.
Speaker 2: Yeah.
Speaker 1: One other thing related to that is a lot of
Speaker 1: our listeners are already working in existing apps. Right, It's
Speaker 1: not like, oh, I've got the perfect greenfield project for this, right,
Speaker 1: I'm building this other thing.
Speaker 2: I'm already using.
Speaker 1: React or View or Angular or you know, just do
Speaker 1: APIs like AJU.
Speaker 2: You know, we're web APIs.
Speaker 1: And so if I'm looking at this and thinking, well,
Speaker 1: some of this sounds really nice for some of the
Speaker 1: features in my app, and then some of the other
Speaker 1: features in my app, yeah, I'm going to use the
Speaker 1: traditional back end because you know, it either already works
Speaker 1: or it seems like this is a clear win for
Speaker 1: just some of these other things. I want to add.
Speaker 1: My question is can you bring this in alongside the
Speaker 1: other stuff? Right, So let's say in an existing React
Speaker 1: app or view app and go, Okay, these components are
Speaker 1: going to use Jazz, these components are going to use
Speaker 1: my existing back end, and some of these components are
Speaker 1: going to do both, and maybe I have that server
Speaker 1: process running on the side.
Speaker 4: Yes, yes you can. In principle, and in terms of
Speaker 4: front end bindings, React a kind of first class. We
Speaker 4: just launched View and very fresh than experimental spelled as well,
Speaker 4: so that's not an issue and you can use it.
Speaker 4: From Plaine Jellascoop as well. Like I mentioned earlier, the
Speaker 4: biggest challenges in terms of like how does it interact
Speaker 4: with your potentially existing back in the state that you have.
Speaker 4: Easiest case is probably if the Jazz state and you'
Speaker 4: listing state is completely separate and you kind of only
Speaker 4: need to make it up just for the user identity,
Speaker 4: so you're existing all works with Jazz. It gets more
Speaker 4: tricky when it does need to put stuff into existing databases,
Speaker 4: which is possible, but again no documentation for it. We
Speaker 4: would need to help you with it. So to be honest,
Speaker 4: like right now, the people getting the most value out
Speaker 4: of Jazz are green field apps, but it is possible
Speaker 4: to build more complex stuff, and over time we'll have
Speaker 4: more patterns and examples of that for you to do
Speaker 4: that without any of our.
Speaker 1: Help, right, I mean, just to give you an example
Speaker 1: of something that I'm thinking about. So top end evs
Speaker 1: I'm building Essentially, I'm trying to take it from podcast
Speaker 1: network to you know, learning guided learning system, right, and
Speaker 1: so one of the things that I want to add
Speaker 1: is a community section where people can actually like chat
Speaker 1: or interact, you know something, but kind of like a
Speaker 1: forum or a chat room or something like that. And
Speaker 1: so I'm looking at Jazz and thinking, hey, you know this,
Speaker 1: this might be really nice. I don't have to figure
Speaker 1: out how to you know, web socket the thing through
Speaker 1: action cable on my rails back end, right, I can
Speaker 1: just you know, I can just put Jazz in on
Speaker 1: that piece, right, and it just kind of exists outside
Speaker 1: of the you know, the rest of the app, because
Speaker 1: the rest of the app, when I search, I don't
Speaker 1: need it to search the chat log. I just needed
Speaker 1: to search, you know, the other learning resources that I'm
Speaker 1: providing people.
Speaker 2: And so I couldn't conceivably do that.
Speaker 4: Right, Yeah, And that sounds like something that I'd love
Speaker 4: to help you build. And that's almost the ideal case
Speaker 4: of like a green field feature within an existing app
Speaker 4: that doesn't really interact too much with the app. So
Speaker 4: I think that that would be a very good case.
Speaker 1: Right, Okay, if people want to connect with you or
Speaker 1: learn more about you or Jazz, Jazz dot tools seems
Speaker 1: like a good place social media or something or GitHub.
Speaker 4: Yeah, I'm I'm a Anselm. I aw on Twitter and
Speaker 4: blue Sky and otherwise. If you want to know more
Speaker 4: about our company, check out garden dot com. Trying to
Speaker 4: be more active on Blue Sky with everything that seems
Speaker 4: like lots of developers are kind of congregating there, which
Speaker 4: I'm very happy about. And soon we'll start putting out
Speaker 4: blog posts and newsletters and so on.
Speaker 2: That's kind of where we're at.
Speaker 1: Yeah, yeah, it's it'll be interesting to see how that
Speaker 1: all goes.
Speaker 2: But yeah, I am seeing some movement that way, so yeah,
Speaker 2: makes sense.
Speaker 1: All right, Well, we're gonna go ahead and head into
Speaker 1: our picks section of the show.
Speaker 2: I'm gonna let AJ go first.
Speaker 3: All right, Well, I did not think that my wife
Speaker 3: would like Dune, but I loved it so much that
Speaker 3: I said, hey, honey, watch the show with me. You
Speaker 3: might not like it. She loved it. I couldn't believe
Speaker 3: it blew my mind. Of course, what she's talking about
Speaker 3: is not the story, like oh the sex were so beautiful,
Speaker 3: and oh that the camera angles were so nice. I'm like,
Speaker 3: what about like the army and like, I don't know,
Speaker 3: I don't know if she got anything out of the
Speaker 3: out of the movie like the rest of us did.
Speaker 3: But but yeah, so we're gonna we're gonna maybe watch
Speaker 3: part two together. I'm I'm thinking she might get the
Speaker 3: two film collection for me for for Christmas. So I'm
Speaker 3: I'm waiting to find out that before we do. But yeah,
Speaker 3: so all the dudes out there that uh, you know,
Speaker 3: you thought, yeah, I would never be able to get
Speaker 3: my wife to watch us with me. My wife is
Speaker 3: one of those wives. Okay, she wants me to watch
Speaker 3: Pride and Prejudice with her, and she I played Portal
Speaker 3: and she couldn't bother to watch that, and Star Wars
Speaker 3: is right out, so I was super super surprised, but
Speaker 3: she enthusiastic loved dude. So I will I will pick
Speaker 3: Dune and maybe I'll throw up a link here to
Speaker 3: the two discs set. And so last week we I
Speaker 3: think it was last week that we talked a bit
Speaker 3: about Blue Sky. I was able to get it installed
Speaker 3: and running. I left an issue open, so anybody who
Speaker 3: wants to know, yeah, I I did. Uh yeah, I
Speaker 3: figured that out. They they used Docker, but the use
Speaker 3: of docer just makes it more complicated and more difficult
Speaker 3: to install because you can just create you know, you
Speaker 3: could just get cloned the repo and then node install
Speaker 3: and then set up your reverse proxy with Caddy. And
Speaker 3: so I just gave those instructions along with some additional
Speaker 3: detail for some optional stuff. So when you see the
Speaker 3: instructions that you know you don't have to do all
Speaker 3: of the things. It's just there's a couple of steps.
Speaker 3: It's like you set up the environment variables. That's like
Speaker 3: one half of the instructions is you know, copy and
Speaker 3: paste this big, huge, long list of environment variables. And
Speaker 3: then you know, optionally set up caddy for SSL if
Speaker 3: you're not already using something else to reverse proxy for you,
Speaker 3: and then you need to have a it's a well
Speaker 3: known file you need to have reverse proxy to in particular,
Speaker 3: apart from the slash x RPC or whatever it is.
Speaker 3: I didn't My experience with it was kind of man
Speaker 3: because it's like, this is literally a Twitter clone. And
Speaker 3: of course, of course my first ten seconds of blue
Speaker 3: Sky were the same as anybody's first ten seconds of Twitter.
Speaker 3: I immediately was followed by bots with you know, pictures
Speaker 3: of women from the chin down claiming to want to
Speaker 3: be my friend. So I I just I don't know,
Speaker 3: I guess joined it if you want to. I've kind
Speaker 3: of I don't see the allure of it because it's
Speaker 3: it's literally just a clone of Twitter with I mean,
Speaker 3: you can you can run a local server and you
Speaker 3: can set up your data server and that's cool. And
Speaker 3: you can set it up so that your data server
Speaker 3: is your domain name. So for example, if you're beyond
Speaker 3: code boot camp dot com, then your handle can literally
Speaker 3: be at beyond code boot camp dot com. Mine is
Speaker 3: not I didn't. I played around with a little bit,
Speaker 3: but I just I was a little I just wasn't that.
Speaker 3: I wasn't that into it because it's it's just it's
Speaker 3: literally Twitter with the logo changed and maybe a few
Speaker 3: features less, and you know, you got the local data
Speaker 3: stor as a feature more. But I mean, I guess cool, good,
Speaker 3: you know, go good them. But yeah, if you want to,
Speaker 3: if you want to install it, there's an issue up
Speaker 3: that's called it's called something like how to win stall
Speaker 3: with Node no Docker and it's very very simple, So
Speaker 3: if you want to do it, I'd recommend it. If
Speaker 3: you're going to join blue Sky, I think that you
Speaker 3: have a moral obligation to run a personal data server,
Speaker 3: because otherwise what are you joining it for. You're like
Speaker 3: throwing out the baby and keeping the bathwater.
Speaker 1: Yeah, well, they're all of the stupid silly politics of
Speaker 1: people blah, blah blah, Elon Musk something something Blue Sky.
Speaker 2: So that's why I'm seeing people move. I think it's
Speaker 2: all people.
Speaker 3: I mean, yeah, if you're really interested in following information
Speaker 3: about Elon Musk, then Blue Sky's a great place to
Speaker 3: get yeah, Cause I mean, like, I think eighty percent
Speaker 3: of the posts or that. So if you really love
Speaker 3: Elon Musk, you just got to know every detail about
Speaker 3: his life. Yeah, I'm sorry, I'm sorry, I'm being a
Speaker 3: bit of a jerk, but I'm.
Speaker 2: Like people, okay, but yeah, but.
Speaker 1: If that's where people are, I'll go there and I'll
Speaker 1: talk too. And if they're somewhere else, then I'll go
Speaker 1: there and talk to people.
Speaker 3: I was just I was expecting something more. I was,
Speaker 3: I was, I was genuinely excited to try it out.
Speaker 3: I was expecting something more. And it's Pixel for pixel.
Speaker 3: It's Twitter with a butterfly logo and an option to
Speaker 3: run a personal data server. Well, it's and a lot,
Speaker 3: a lot, a lot. Like I will say, I think
Speaker 3: the politics are heavier on Blue Sky, probably because I
Speaker 3: haven't followed anybody yet, but like, I.
Speaker 4: Think that's the big thing. Like it. I tried it
Speaker 4: a while ago and gave up on it, and then
Speaker 4: with the wave of people coming and that that the
Speaker 4: Star depects like kind of regreen knitting communities, especially among
Speaker 4: like deaf tools. It's actually not at a point where
Speaker 4: I missed some of the most interesting people from Twitter,
Speaker 4: but it is quite high like value to noise like
Speaker 4: no ads. But that only was the case after followed
Speaker 4: a bunch of people. So I think that's always the
Speaker 4: caved with social networks. Yeah, you have your personal.
Speaker 1: I connected with a bunch of people there too, but
Speaker 1: I got kind of dragged kicking and screaming into some
Speaker 1: of the dev community politics a few years back, and
Speaker 1: hm that that came right back to the surface the
Speaker 1: second I was in there. So I think it really
Speaker 1: just depends on what your experience is and who you
Speaker 1: wind up running into. But I mean, I did have
Speaker 1: a couple of great conversations with some people on there too, so.
Speaker 3: But the whole thing about like there's no ads and
Speaker 3: you know, a small community ball, all of that's gonna
Speaker 3: go away because the the investors are gonna go from
Speaker 3: a round to b round and then they're gonna need
Speaker 3: their kickback and then they're gonna have to figure well,
Speaker 3: are we gonna do ads, We're gonna charge people money.
Speaker 3: I mean, I just there's no unique value proposition. It's
Speaker 3: purely it seems to be purely a moral proposition, right.
Speaker 3: It's it's like there's more what church are you going
Speaker 3: to join? Rather than what technology are you going to use?
Speaker 3: And so that's where I don't unless they have a
Speaker 3: unique value proposition where it's like I can do this
Speaker 3: here that I can't do there, I have a hard
Speaker 3: time believing that it's going to really bloom, especially because
Speaker 3: they're investor backed and investors don't care about personal data servers,
Speaker 3: that stuff's going to go.
Speaker 4: Yeah, I mean, I agree with you, And it's honestly
Speaker 4: the part that I'm most nervous about that it's not
Speaker 4: apparent yet what their business model is going to be exactly,
Speaker 4: or if they're doing ads, how they're doing them, Because
Speaker 4: I would love for Blue Sky to succeed just on
Speaker 4: the basis of it being an open protocol and hackable
Speaker 4: and so on. But until I see that, I kind
Speaker 4: of can't fully believe in it. But yeah, I'm routing
Speaker 4: on that basis, and so far, the indication seems to
Speaker 4: be that the people behind it are deeply aware of
Speaker 4: this conflict and are thinking about it in good ways.
Speaker 4: But I don't trust the fact that the introducing the
Speaker 4: monetization part so slowly.
Speaker 3: Yeah, Microsoft's going to come in and buy it and
Speaker 3: add co pilot.
Speaker 2: Yeah.
Speaker 1: If you're following along on YouTube, Owen Buckley's posted a
Speaker 1: couple of comments as well, you know about you know,
Speaker 1: the algorithm or lack of algorithm and things like that.
Speaker 1: But it's anyway, it's there's an interesting discussion to be had.
Speaker 1: Mostly I went over there because there were people that
Speaker 1: had left Twitter that I wanted to interact with, and so,
Speaker 1: you know, as far as that goes, you know, maybe
Speaker 1: maybe Blue Sky just doesn't get traction and they come back,
Speaker 1: or maybe they don't or I don't know, but for now,
Speaker 1: that's where some of the folks I want to be
Speaker 1: around are and so I'm there, and there are a
Speaker 1: whole bunch of people on x Twitter that I want
Speaker 1: to be around, and so I'm there too, And.
Speaker 2: Yeah, anyway, so.
Speaker 3: Yeah, I apologize for my trolling. Now, No, I'm I
Speaker 3: apologize for my for my trolling.
Speaker 1: No, there's I mean, it's it's it's a discussion that's
Speaker 1: happening in the community one way or the other.
Speaker 2: And so.
Speaker 3: You know, I like what Owen says. It's all just
Speaker 3: a bunch of yapping wherever you go for the lulls.
Speaker 2: Yep, true.
Speaker 1: All right, I'm gonna throw in some picks, so I
Speaker 1: always do a board game pick. I was at the
Speaker 1: Timpcon a couple of weeks ago teaching games. One of
Speaker 1: the games we taught was Imperial Miners, and I just
Speaker 1: posted the board game geek link. So Imperial Miners it
Speaker 1: comes in is at a weight of two point oh oh,
Speaker 1: so it's exactly two two is casual gamer friendly. It's
Speaker 1: it's got enough complexity to where it's interesting and fun,
Speaker 1: but it's not so overwhelmingly complicated that people can't figure.
Speaker 1: Like I've picked some games on here that have a
Speaker 1: board game geek weight of like four four and a half,
Speaker 1: and it's like, look, this game's going to take you
Speaker 1: five hours and you're gonna get way into all of
Speaker 1: the ins and outs of how it's played.
Speaker 2: This is not that game.
Speaker 1: This game plays in I think we've usually play it
Speaker 1: in like a half hour.
Speaker 2: It says age ten plus. That's probably about right.
Speaker 1: You can play it up to five players, I've always
Speaker 1: played it with three or four players there.
Speaker 2: So this game is a little.
Speaker 1: Different from some of the other games that I've picked,
Speaker 1: where you know, it's like, hey, you know, you're all
Speaker 1: interacting in this specific way. Imperial Miners is like playing
Speaker 1: solitaire with other people, all right, So essentially in the
Speaker 1: sense of you you're you're playing on your own board
Speaker 1: and there really isn't anything else that anybody else can
Speaker 1: do to.
Speaker 2: Mess with you, right, So.
Speaker 1: Essentially the way it works is you're building a mine,
Speaker 1: and so you start with the top level of the mine,
Speaker 1: and you at cards, so you get a level. You
Speaker 1: have level one cards, Level two cards, Level three cards,
Speaker 1: and level four cards. All the level four cards are
Speaker 1: the same. They give you two points. I think I
Speaker 1: don't remember exactly.
Speaker 2: But they're all the same.
Speaker 1: So anyway, you start with two of each card, and
Speaker 1: so you play one of your level one cards because
Speaker 1: that's all you can do, right, and then your next turn,
Speaker 1: if you want to, you can play a level two
Speaker 1: card that connects to your level one card, right, So
Speaker 1: you can't ever play cards that don't connect back to
Speaker 1: the surface. And they each do different things. They have
Speaker 1: different teams or icons or however you want to classify
Speaker 1: it categories, and so I think their guilds actually is
Speaker 1: what they are. But anyway, so they all kind of
Speaker 1: some of them playing together, right, So it's like if
Speaker 1: you have other cards that are of this same kind,
Speaker 1: then you get mine cards or diamonds which are the
Speaker 1: points or you know whatever, or coins, and you can
Speaker 1: you can spend the coins to do other things, like
Speaker 1: you can buy essentially moving your their technology tracks. You
Speaker 1: can move your marker up the technology track, or you can.
Speaker 2: You can buy.
Speaker 1: More cards that are more things you can put into
Speaker 1: your mind, right, because there are like four slots for
Speaker 1: level one and so you can put in more level ones.
Speaker 1: But what happens is when you play a card, you
Speaker 1: get that card and then you get to choose one
Speaker 1: of the cards that it connects to above it, and
Speaker 1: they're offset, so you can pick between two if there
Speaker 1: are two cards above it. Otherwise you just go to
Speaker 1: the one that is above it, and then you you know,
Speaker 1: you just chain all the way up to the surface,
Speaker 1: and so you do what each card says, right, And
Speaker 1: then there's some other complications, like you can have a
Speaker 1: cave in and so if there's a cave in instead
Speaker 1: of getting that reward you clear the cave in, right, But.
Speaker 2: But there are rewards.
Speaker 1: There are cards that say if you have for every
Speaker 1: cave in you have, you get so much money or
Speaker 1: so many points, and so sometimes that.
Speaker 3: Game emergency stop and somehow has to go. I don't
Speaker 3: think you saw the message in the chat.
Speaker 2: Oh okay, do you have some picks and some before
Speaker 2: we go?
Speaker 4: Yeah, quick one you talked about doing aj I can
Speaker 4: really recommend the Silo series on Apple TV. It's one
Speaker 4: of the most fun sci fi things I've seen recently.
Speaker 3: But yeah, thank you.
Speaker 4: Was the pleasure talking to you guys. Nice to meet you. Yeah,
Speaker 4: very nice to talk about local first, thanks so much
Speaker 4: for having me take care.
Speaker 2: All right, so sorry, I was on a roll. So anyway,
Speaker 2: it's a super fun game. Like I said, it takes
Speaker 2: about a half hour. It's pretty simple.
Speaker 1: Everybody just goes at the same time and then gets
Speaker 1: whatever rewards, and then you do it again for the
Speaker 1: next round, and you play ten rounds I think, and
Speaker 1: then you're done. And at the beginning of each round
Speaker 1: you flip over a card that gives everybody a reward
Speaker 1: or a complication.
Speaker 2: That's it. So I'm gonna pick that.
Speaker 1: I am finishing up putting together all the stuff for
Speaker 1: the AI dev boot Camp. You'll be able to get
Speaker 1: that at aidevbootcamp dot com when that comes out. I'm
Speaker 1: hoping to have everything together for that by tonight or
Speaker 1: tomorrow so you can sign up. We're going to start
Speaker 1: in the middle of January will be the first week.
Speaker 1: We're going to run for three months. We're gonna have calls,
Speaker 1: at least a couple of calls every week and just
Speaker 1: kind of walk you through anything that you're running into,
Speaker 1: answer questions, things like that, just so that you can
Speaker 1: build AI features into your applications. And that's everything from
Speaker 1: help bots and stuff like that all the way up
Speaker 1: through just sort of the I've got this text field
Speaker 1: and I click a button and it writes a summary
Speaker 1: for my podcast episode kind of thing. I mean, I'm
Speaker 1: looking to build something for the top end dev system
Speaker 1: that I just barely converted over to a SAS where
Speaker 1: people can come in and instead of having to know
Speaker 1: which form to go edit the podcast, whatever whatever field in,
Speaker 1: they can essentially tell the bot, hey move the episode
Speaker 1: with ONSELM from Monday the eighth or ninth, or whenever
Speaker 1: this is going to come out to.
Speaker 2: Monday.
Speaker 1: You move it a week later and it'll be smart
Speaker 1: enough to go in and change the published date.
Speaker 2: Or we have an.
Speaker 1: Episode scheduled with so and so to record on this
Speaker 1: date and they say they can't do it. Can you
Speaker 1: move it back two weeks and it's smart enough to
Speaker 1: change the schedule and update all of the guests and
Speaker 1: hosts that are planning on showing up and stuff like that.
Speaker 1: Or if somebody schedules an episode for Christmas, right, I
Speaker 1: can say, hey, can you block out Christmas and move
Speaker 1: the episode there a couple of weeks, Or Hey, the
Speaker 1: title that you have for this episode isn't great. Can
Speaker 1: you generate three more? So I can pick one and
Speaker 1: it'll be smart enough to do that. So that's kind
Speaker 1: of the thing we're looking for. The system that we've
Speaker 1: been using to have the show notes written doesn't always
Speaker 1: get it right, and so it'll pick up on exactly
Speaker 1: the wrong thing and write a summary that we talked
Speaker 1: about Lord of the Rings instead of JavaScript. That happened
Speaker 1: once because Dan told a story about how The Lord
Speaker 1: of the Rings got translated into Hebrew, and so it said, hey,
Speaker 1: they talked about literature. And it was like, well, technically,
Speaker 1: but anyway, So that's the kind of thing. So I'll
Speaker 1: be teaching you how to do all that kind of
Speaker 1: stuff and how to choose the right llms to do that,
Speaker 1: and how to connect to those services. I'm hoping to
Speaker 1: have examples in JavaScript and Ruby. If you're doing some
Speaker 1: other language, you know, we'll give you enough tools to
Speaker 1: where you can figure out how to talk to the
Speaker 1: APIs and get authenticated and all that stuff, but you'll
Speaker 1: have to use whatever libraries in whatever language you're doing.
Speaker 1: So if that's Go or Alixer or something. I'm just
Speaker 1: trying to think what other picks I have. I could
Speaker 1: pick one that would piss everybody off, but I think
Speaker 1: I'll save that for next week. And yeah, I guess,
Speaker 1: I guess I'll just wrap it up there. I have
Speaker 1: redone the top end Dev's website. I'm currently working through
Speaker 1: some issues, but if you point out an issue that
Speaker 1: I'm not aware of yet, I am totally willing to
Speaker 1: give you a discount or a free month to the
Speaker 1: JavaScript Geniuses group or something like that.
Speaker 2: So just email me Chuck at top endevs dot com.
Speaker 1: And if it's not something I'm already working on or fixing,
Speaker 1: then you know I'll make it worth your while. So anyway,
Speaker 1: those are my picks, and I guess we'll just wrap
Speaker 1: it up till next time.
Speaker 2: Max out