Sponsored by
Show notes
Transcript
0:00:00 Intro
0:00:00 And you know, like I don't think
economically we need local-first
0:00:02 software, you know, like we can
trudge along with the feudalism
0:00:06 of Google cloud services for, you
know, probably for a very long time.
0:00:10 but I don't want that.
0:00:11 I want beautiful software programs that
work in harmony with who I am as a person
0:00:15 and with in harmony with what kind of
communities I want to be able to foster.
0:00:19 Welcome to the local-first FM podcast.
0:00:22 I'm your host, Johannes Schickling,
and I'm a web developer, a
0:00:25 startup founder, and love the
craft of software engineering.
0:00:28 For the past few years, I've been on a
journey to build a modern, high quality
0:00:32 music app using web technologies.
0:00:34 And in doing so, I've been falling down
the rabbit hole of local-first software.
0:00:38 This podcast is your invitation
to join me on that journey.
0:00:42 In this episode, I'm speaking to Seph
Gentle, a prolific software researcher
0:00:46 who's behind projects such as the new
AgWalker paper and JRJS, one of the
0:00:51 oldest local-first open source projects.
0:00:54 Before, Seph also co created Google
Wave over 10 years ago, which we
0:00:58 explore in depth in this episode.
0:01:01 Before getting started, also a
big thank you to Electric SQL
0:01:05 for supporting this podcast.
0:01:07 And now my interview with Seph.
0:01:09 Hey, Seph.
0:01:10 So nice to have you on the podcast.
0:01:12 I'm a huge fan of your work.
0:01:14 I've learned so much from the paper
you've recently written about Eg-walker.
0:01:19 And the more I dug into your work,
the more I realized, oh, wow,
0:01:23 you've also been involved in this.
0:01:25 So for example, you've been
working, On Google Wave, like way
0:01:29 back, but also on projects such
as ShareDB ShareJS, et cetera.
0:01:35 So welcome to the show.
0:01:36 How are you doing?
0:01:37 Thanks.
0:01:37 I'm great.
0:01:37 It's so wonderful to
finally meet you as well.
0:01:39 I feel like you're one of these faces
that pokes up everywhere and, yeah,
0:01:43 it's lovely to meet in person and get to
actually chat about all of this stuff.
0:01:46 Awesome.
0:01:47 Yeah.
0:01:48 So I've already mentioned a few projects
that you worked on, but maybe you want
0:01:53 to give a background for the audience.
0:01:55 Google Wave
0:01:55 No, absolutely.
0:01:56 So, I guess the story starts way
back in, I think it was 2010, 2011.
0:02:00 And I was invited onto the super
secret at the time project of Google
0:02:04 Wave, which was run out of Google.
0:02:06 And it was, not many people know
this, and I'm sure someone will get in
0:02:08 trouble, get mad at me for saying so,
but it was a secret even inside Google.
0:02:12 Sorry.
0:02:13 Google was thinking we've got lots
of people who've worked in startups,
0:02:15 but we're not a startup anymore.
0:02:17 How do we get some of that innovation?
0:02:19 And so Google Wave started
as this skunkworks project.
0:02:22 They didn't even tell Google us about
it, which was a wild thing at the time.
0:02:25 and before long, you know, in the original
vision to anyone who hasn't tried it out.
0:02:29 Was if we reinvented email today,
what would we want it to look like?
0:02:32 What could it do?
0:02:33 And so, Wave is this almost cross between,
email and Google Docs and something
0:02:38 else where you can have, A conversation,
which they called a Wave, was a series
0:02:43 of messages, but messages could go down.
0:02:45 So we could have a series
of conversation items.
0:02:48 You could also embed messages and
embed entire threads inside a comment.
0:02:51 So I could write something and you could
start a comment thread inside that and
0:02:55 any comment, anything that anyone wrote.
0:02:57 Anyone could come along and
just collaboratively edit
0:02:59 it and change it later.
0:03:00 So, we sort of built this thing not
really knowing how it was going to
0:03:04 be used, which is a beautiful luxury.
0:03:06 and the answer is that lots of
people used it for, you know,
0:03:08 say like, for playing D& D games.
0:03:11 And they would put all of the
information about the campaign
0:03:13 itself at the top of a Wave.
0:03:14 And then the actual session would be
a series of messages and then they'd
0:03:17 start a new Wave for the next session.
0:03:18 Or, say minutes.
0:03:20 So you'd have the agenda for a meeting
and then during the meeting anyone could,
0:03:23 you know, put in little comment threads
about what was actually discussed.
0:03:27 And then your minutes for the
meeting turn into the agenda.
0:03:29 Sorry, your agenda turns
into the minutes afterwards.
0:03:31 Because we've now got this
collaborative document.
0:03:33 So, yeah, I fully remember when
Google Wave just first came out.
0:03:38 I was still in high school back then.
0:03:39 I was 16 and, I was like
using a few Google products.
0:03:44 I think mostly Gmail and maybe
a bit of Google Docs to just
0:03:48 keep track of my, own thoughts.
0:03:50 But when Google Wave came out, I
was just so curious and there, there
0:03:56 wasn't really like a real use case
I had for it back then, but I got
0:04:00 immediately hooked by the novelty of it.
0:04:03 And it was, I think it was really the
first time where it really clicked for
0:04:06 me, like, Oh, this is computers are not
just for me, like looking in my single
0:04:11 screen here and then sort of asynchronous.
0:04:14 Yes, I can send an email, et cetera, but
we can in real time collaborate on the
0:04:19 same stuff and that sort of same magic
that happens if we're like sitting at
0:04:24 the same table and do something together.
0:04:26 Now that can sort of
be replicated in there.
0:04:29 And not only did you build something
in a real time collaborative
0:04:31 way, you build it so well.
0:04:33 I think Google Wave really set the
bar for a long, long, long time.
0:04:38 What I really like.
0:04:39 Immersive, high quality web experience
could look like and that was,
0:04:43 yeah, you mentioned like in 2010.
0:04:45 And so I think that had had a long
lasting impact on my own, longing and
0:04:52 motivation to go all in on the web.
0:04:55 Well, that's, that's
very kind of you to say.
0:04:56 I feel like, I'm like, Oh, I can't
take all the credit for Wave.
0:04:59 I mean, at peak, there was 60
people working on it and I came
0:05:02 onto the project reasonably late.
0:05:03 So, you know, it wasn't my grand vision,
and something though for this audience,
0:05:08 you might be fascinated by, we built the
entire thing to be, it wasn't local-first,
0:05:12 that term certainly didn't exist at
the time, but it was fully federated.
0:05:15 So it worked like email did
with the idea that people could
0:05:18 run their own Wave servers.
0:05:19 And, you know, and so you could
collaborate within your organization
0:05:22 on your Waves and then the document
wouldn't leave your organization
0:05:26 unless you explicitly added someone
from outside of your organization.
0:05:28 otherwise it would stay in the
four walls of your company and
0:05:31 your own servers, which was really,
really cool and groundbreaking.
0:05:34 I mean, like hearing that in retrospect
doesn't sound very, like, that's not
0:05:38 what I associate with Google these days,
like Google typically builds like a very.
0:05:43 Google centric service,
take it or leave it.
0:05:46 It works really well integrated in
the rest of Google services, but
0:05:50 going in a more federated, like open
protocol direction is not immediate.
0:05:55 Maybe this was just a
different time back then.
0:05:58 Maybe.
0:05:59 I think that Wave was also, it
was an unusual, it was a weird
0:06:02 project inside Google itself.
0:06:03 It was run out of Australia
in the Sydney office.
0:06:06 so you know, it was, it was like
this little, little project at
0:06:09 first about what could we build.
0:06:10 And.
0:06:12 Google's got a funny
relationship with openness.
0:06:14 where you've got, I mean, I agree with
you about most of Google's product
0:06:17 offerings, but then Google are one of
the hugest proponents of the web and
0:06:21 the web of course is still fully open.
0:06:23 And you know, as much as people
like to complain whenever.
0:06:26 Google Chrome integrates
with Google services.
0:06:29 Google at their heart really still
does believe in the open web.
0:06:32 And, you know, so the question is,
could we use that knowledge and that
0:06:35 understanding to be able to build more
products that work like email does?
0:06:39 And of course, again, Google, you
know, with Gmail as a, you know,
0:06:42 it's all built on open protocols.
0:06:44 so yeah.
0:06:45 but no, it was really ambitious
and it was a really beautiful.
0:06:48 product, product use, as you say,
it introduced lots of people to
0:06:52 actually things being real time and
collaborative by default, which I
0:06:55 really think is the right default.
0:06:56 I told my mom at one point I spent, you
know, a couple of years of my life trying
0:07:00 to make, we, we had a joke that we wanted
to make two windows look exactly the same.
0:07:04 and you know, so if you typed
in one window, it would just
0:07:06 appear on the other screen.
0:07:07 And this is a really
very difficult problem.
0:07:09 and she kind of gave me this
quizzical look and said, Doesn't
0:07:12 it do that already anyway?
0:07:14 And, you know, she just never
tried and never noticed.
0:07:17 But it's really, really is, uh,
Paul Graham has this question, he
0:07:21 says, what feels like it would be
obvious, it would be crazy for us
0:07:24 not to have in a hundred years.
0:07:25 And I think about that a lot, of, what
technology would it be crazy for us not
0:07:30 to have, in such that, if we could figure
out what that technology is, could we
0:07:34 build that now, and then just have it now?
0:07:36 you know, I don't want to have to wait for
someone else to invent all of this stuff.
0:07:38 Like, with Wave, it felt like it was right
at the birth of collaborative editing.
0:07:42 Google Docs was actually quite new
at the time and, believe it or not,
0:07:46 Google Docs had a bunch of correctness
issues where, you know, if you type
0:07:49 certain text and then bolded and then
you unplugged your network cable at
0:07:51 the right time and everything else,
you'd end up Converging, you would see
0:07:54 something and if you hit refresh, you'd
see a different document on your screen.
0:07:58 these problems were still new and
we were still figuring them out.
0:08:00 But I feel really sad that there's not
more software that takes advantage of this
0:08:04 cool technology we've been working on.
0:08:06 you know, like even things like Figma,
and I love Figma for using CRDTs,
0:08:09 but you can't run your own Figma.
0:08:12 When I open Figma, it's,
a centralized service.
0:08:15 It just happens to be using CRDTs
to do collaborative editing.
0:08:17 but I feel like it's technology
that we can use for so much stuff.
0:08:20 and that's, yeah, that was kind
of part of my, like, jewel, joy
0:08:24 and sadness in working on Wave.
0:08:26 Right.
0:08:26 Thought, ah.
0:08:27 Yeah, I mean, let's not, let's
not go to the sad part yet.
0:08:30 Ultimately, Google Wave shut down.
0:08:32 But I want to hear a bit more about the
various aspects you've already mentioned.
0:08:37 And I love the framing of
Paul Graham in that regard.
0:08:40 Like, what would be just.
0:08:41 obvious, to build, and maybe
we can also follow up which
0:08:44 ideas feel obvious to you now.
0:08:47 And maybe that you want to work
on, you don't have the time.
0:08:50 Let's, let's shelve
that for the time being.
0:08:52 So not only was Google Wave just
like an amazing product experience,
0:08:57 like how fluid it felt, et cetera.
0:08:59 And you have to remember this was
like it's 2010, where web standards
0:09:03 were not at all where they were today.
0:09:06 And, I'm not sure how strict
Google was back then about,
0:09:10 like, browser compatibility.
0:09:12 but I remember the experience
just feeling phenomenal back then.
0:09:16 So what were some of the key
challenges making this happen?
0:09:19 I mean,
0:09:20 that's very kind of you to say.
0:09:22 That wasn't the universal
experience and it depended very
0:09:24 much on what browser you had.
0:09:25 We, we had an internal Wave that was
like scrolled for a long way of open
0:09:30 browser bugs that we'd filed against
all of the different web browsers in all
0:09:33 sorts of different little edge cases.
0:09:35 I mean, for context, we made Google
Wave work on, I think it worked on IE8.
0:09:40 it certainly worked on IE9, which is the
version of Internet Explorer at the time.
0:09:43 but there was so much that was
still, I mean, even still is
0:09:46 not standardized, honestly.
0:09:47 We had a rich text editing element, and
we needed that to work with international
0:09:51 characters and internationalization,
and be able to, synchronize with any
0:09:55 device on any platform with any browser.
0:09:57 So, that was tremendously hard.
0:09:59 There was a team of about six or seven
People just working on the input side and
0:10:05 we had this insane test suite that would
test and, you know, different keyboards
0:10:09 in the office of, you know, for Korean
characters and Chinese characters and,
0:10:13 you know, European, various different
forms, you know, different laptops running
0:10:17 different versions of windows to make
sure that we could get everything to
0:10:19 synchronize correctly, and we used all
of that to try and just make the browser
0:10:23 work correctly and work consistently,
but from a technology standpoint, we
0:10:27 forget now, but this is back in the
day before we realized that JavaScript
0:10:30 was actually a useful language and
kind of nice to write in sometimes so
0:10:34 Google Wave was all written in Java.
0:10:36 And then compiled from Java to
JavaScript via Google Web Toolkit.
0:10:40 So, we had, I think that when
Wave got shut down eventually,
0:10:43 I checked the source tree.
0:10:45 And internally we had 1.
0:10:46 1 million lines of Java code.
0:10:47 And obviously, that wasn't all
the client side application.
0:10:51 but then that compiled.
0:10:52 To, it was like a 500 kilobyte JavaScript
bundle, which these days doesn't seem
0:10:56 so large, but at the time it brought
down, you know, mighty web browsers,
0:11:01 trying to run all of this stuff
that we were, you know, trying to do
0:11:05 written in, Java to be able to solve
all of this like front end problem.
0:11:09 and then on the back end.
0:11:10 Operational transform was a new idea.
0:11:12 CRDTs were, like, I think that they
were a gleam in some researchers eyes
0:11:15 at the time that we were working,
but they were incredibly inefficient.
0:11:18 So we tried to build something that
was federated and would let multiple
0:11:21 servers, multiple users from different
organizations all collaboratively
0:11:24 edit a document, all built on top
of a very old version of operational
0:11:27 transform, which some very smart people
on the team managed to get to work.
0:11:31 But, it was incredibly new.
0:11:33 I learned a huge amount from working
on that, which has kept me busy for
0:11:37 the last decade and change honestly
of trying to figure out how you
0:11:40 can even solve a problem like that.
0:11:42 there's another feature that I want to
plug because I really hope that people
0:11:45 who are listening to this podcast know
about it and realize that you could
0:11:48 build this into your own applications.
0:11:50 We, we also had something
called, Google Wave, gadgets.
0:11:53 We had gadgets and extensions and it
doesn't matter the distinction, but
0:11:56 you can have a Wave and inside of it.
0:11:59 the internal data structure was
an XML tree with annotations.
0:12:03 So you could do rich text, but
also have arbitrary XML nodes.
0:12:06 you could make different little
applications, and the application
0:12:09 would be embedded inside the page,
and the application would be given
0:12:13 some small subsection of the XML tree
to be able to collaboratively edit.
0:12:17 So as a result, we could build things
and anyone in the community could
0:12:20 build things that you could drop into
a Wave and when you dropped it into
0:12:23 a Wave, now you've got a small, you
know, drop in application that you
0:12:26 could collaboratively edit inside of.
0:12:28 So, for example, we built a Google
Maps extension that let you plan your
0:12:32 holiday with a friend and, you know,
with as many friends as you want, and
0:12:35 you could all put down marker pins
and draw little lines on the map.
0:12:38 we had a, the yes, no, maybe gadget
was the most famous where someone
0:12:41 would post in the office and say, Hey,
is anyone up for seeing the new, you
0:12:45 know, the new movie, whatever it is.
0:12:46 on Tuesday at 7pm, and in the Wave would
be a little, like, three columns, and
0:12:52 you could click yes, no, or maybe, and
whichever column you clicked on, your
0:12:55 face would appear in that, alongside
everyone else that clicked on yes, no,
0:12:58 or maybe, or you'd have little polls, and
while you had the page open, you could
0:13:02 see everyone's faces appear, all in real
time, because that component, which isn't
0:13:06 part of Wave itself, it was an extension,
gets to be able to sit on top of the
0:13:09 collaboratively editing, infrastructure
and, and work, which was so cool.
0:13:14 That is so amazing.
0:13:15 And I'm like both super
excited just hearing about that
0:13:19 again, like amplified by hell.
0:13:21 This was like 2010, like this was like so.
0:13:26 So much earlier, there was no
WASM, there was no TypeScript.
0:13:30 There was like, the web
was like so, so, so early.
0:13:34 And you didn't just innovate
on those technologies, but you
0:13:37 innovated so much on those.
0:13:38 Like you really try to, push to
whole new frontiers where the
0:13:42 product experience can be like
that, that real time collaboration,
0:13:46 like tied to a phase, et cetera.
0:13:49 and I don't really think that we have
that in a, as modular as a way, as you
0:13:55 described it right now, like typically you
have those sort of super modular ways, in
0:14:00 a more standalone open, like niche open
source thing, but not in a mainstream,
0:14:05 product that, that everyone is using.
0:14:08 And, I think the closest to actually who's
going after the same vision that comes
0:14:13 to mind are the folks at Ink and Switch.
0:14:15 Who are building Patchwork and,
I get to see the in progress
0:14:20 updates there once in a while.
0:14:21 And it's so, so, so cool.
0:14:23 And like, now I see the
strong, strong parallels there.
0:14:25 And I think they have
a, similar vision there.
0:14:28 They're just starting from
a different foundation.
0:14:31 They're building it on top of Automerge.
0:14:33 we're going to have, Peter von
Hardenberg back on the show to talk
0:14:36 about Patchwork as well as at the
upcoming local-first conference.
0:14:41 but there's many, many similarities there.
0:14:43 so yeah, this is, this is super inspiring.
0:14:46 Yeah.
0:14:47 I couldn't agree more.
0:14:48 I feel like that's sort of my,
my dream software I want to have,
0:14:51 in particular for creative work,
I think like if I'm going to be.
0:14:55 I don't know.
0:14:56 I'm using IRC or some, you
know, discord or something.
0:14:58 Fine.
0:14:59 I understand that it makes the most
sense to have some semi centralized
0:15:02 system, but for creative work, for if
I'm writing a, if I'm writing a book, if
0:15:06 I'm collaboratively editing a video with
some other people, I want to be able to
0:15:09 have something that both has some data
living inside some open platform that any
0:15:14 application and anyone who's interested
can grab a copy of the data and.
0:15:18 listen to changes and make changes
to the data model, you know, just
0:15:21 as a raw JSON model or something.
0:15:23 And then also like that's sort of the
Holy grail of then being able to have
0:15:26 custom extensions and custom bits
of software that can be plugged in.
0:15:30 it's not a static platform.
0:15:31 It's something that people can build cool
UI on top of and try out different things.
0:15:36 I've got this idea in
my mind that I can't.
0:15:37 Escape, which is, it was someone in
that broader community once described
0:15:41 Google Wave as glorious data bus in
the sky of, you know, this amazing
0:15:45 data bus that just moves all of our
data around between computers and you
0:15:48 don't have to think about it and it's
complicated and it doesn't matter.
0:15:51 You just know that you've got some data
and anytime you want it, it can be on
0:15:54 your device and it can be up to date
and it can be, you know, you can make.
0:15:58 Collaborative changes with anyone else
and if you had something like a JSON data
0:16:02 model or something like, the data model
in Yjs or Automerge, then you could have a
0:16:07 data model than any, you can have lots of
different pieces of software interoperably
0:16:11 interact with that same bit of data.
0:16:13 So, you know, if I've got, A whole bunch
of server logs in there, and it's just
0:16:17 in the, in the, in the cloud, in the,
you know, not the cloud, centralized
0:16:21 cloud, but in this data model, and I
can subscribe to that, and I can have an
0:16:24 application that listens to that, those
logs, produces a report, and produces
0:16:28 and updates that report in real time,
and then puts that back in the set
0:16:31 of data, and that's kind of a boring
example, the one I often think about is
0:16:36 compilers, so I've got a bunch of source
code files, and I could have all of that
0:16:40 in this data model, so I've got a bunch
of files, And I want to just be able to
0:16:44 open any program on my computer to be
able to make changes and not just on my
0:16:47 computer, but on any of my devices, grab
my iPad, grab my, you know, whatever,
0:16:51 grab a Raspberry Pi and make changes.
0:16:53 And then I want my compiler just to be
able to listen to the stream of all of
0:16:57 the changes and be live recompiling.
0:16:59 Based on the differences in the source
code and putting back into another data
0:17:03 model, a set of annotations describing
where all the errors are and how the
0:17:07 syntax highlighting should work and
anything else the compiler wants.
0:17:10 And then we can have different IDEs
that don't have to understand the
0:17:13 programming language at all because
they can just listen to the compiler,
0:17:16 you know, and then for example, I could
have like a testing suite as well.
0:17:19 And then the compiler is.
0:17:20 Keeping up to date and executable, a
binary file that's just made of a bunch
0:17:24 of small blocks, which are all like
functions that are compiled in, linked in.
0:17:27 And then I could have a testing suite
that every 30 seconds, so long as there's
0:17:30 been changes, it reruns the testing
suite and keeps up to date a set of like,
0:17:33 which tests are passing and failing.
0:17:35 You know, I, like Unix model is, you
know, like lots of small programs that
0:17:39 can interoperate and talk to each other.
0:17:40 but then we, we threw a lot away
and I, you know, to this day,
0:17:44 I love using IntelliJ, right?
0:17:45 Like, RustRover, that's it, yeah.
0:17:47 Yeah, but these programs are these huge
monolithic programs because the only
0:17:51 way to get all of these small components
of an IDE to talk to each other is by
0:17:54 putting them inside one piece of software.
0:17:56 the Unix model itself sort of fell
apart because we don't have the
0:17:59 right primitives to be able to plug
programs into each other, you know?
0:18:02 I think this is where I also see
stark parallels again to what the
0:18:07 folks at Ink & Switch are going
after where they're building this,
0:18:11 big data bus with Automerge and then
build sort of like systems around it.
0:18:16 And I think Patchwork is both a huge
exploration what that could be, but
0:18:21 also drives even more, requirements
for the ecosystem to form around.
0:18:27 It's sort of interesting how, the
data bus is one aspect, but then the
0:18:31 other, resurfacing idea is basically
like a, stateful built system where
0:18:38 you basically, like, you listen to
something and you do a computation and
0:18:42 that result, other things can listen to.
0:18:44 So it becomes like this bit, this big tree
that's ideally incrementally recomputes.
0:18:51 And this is how most reliable systems
that we use on a daily basis work.
0:18:56 But unfortunately.
0:18:58 They're, concealed in a box and,
typically don't interoperate
0:19:03 beyond a certain system.
0:19:05 And I think this is another common theme
that I'd like to see explored more.
0:19:10 How can, like within Google.
0:19:12 So most things can talk to each other,
but now everything is in that big Google
0:19:16 box, but how can we go even beyond that?
0:19:19 And this is where maybe coming
back to, the initial ideas behind
0:19:23 Google Wave, where you wanted
to build your own protocol.
0:19:29 Google Wave Protocol
0:19:29 Yeah, in my mind, the way that I would
solve this problem if I were to start
0:19:33 today is to pick some Data model.
0:19:35 So for example, Automerge and then create
a protocol where multiple peers, you know,
0:19:39 that takes care of, peer discovery of
authentication, all of that kind of stuff.
0:19:43 so that way you can have some little
package of software, some binary
0:19:47 that you link to or a JavaScript
package, you know, NPM library or
0:19:50 something that will give you access
to this, to this data collection.
0:19:54 And then you can make a program
that can say, Oh, I would like to
0:19:56 subscribe to this kind of data, please.
0:19:58 And you can see it, for Wave.
0:19:59 Like we started trying to solve
this problem and at the time we
0:20:03 used operational transform because
there were no other options.
0:20:05 Like this is, it's sort of 2011.
0:20:07 I think the first CRDT paper might've
come out around 2005, but performance
0:20:11 wise, it, it performed terribly.
0:20:13 Like if you just typed a regular document
of a few pages long, you would use almost
0:20:17 a gigabyte of RAM in memory and a similar
amount of disk space just to store the
0:20:22 entire object tree that it created.
0:20:24 It performed very badly.
0:20:25 And that being client side or server side?
0:20:28 both, because they'll, they'll
be running all the same code.
0:20:30 So, so that was the problem with CRDTs.
0:20:32 So we used an operational transform
based approach, which is based
0:20:35 on the Jupyter, OT algorithm.
0:20:37 And at its heart, um, Jupyter, there's a
few different ways to say this for people
0:20:42 who aren't familiar with the technology.
0:20:43 Jupyter uses it's only correct
if there are exactly like either
0:20:47 one or two participants, so it
can't work at all if there's more
0:20:50 than more than two participants.
0:20:51 So three, there's a whole bunch of
correctness problems, but you can
0:20:55 solve that by having the server be
one of the participants essentially.
0:20:58 So one way to think about it is that every
user is collaboratively editing with us
0:21:02 with their server and the server then.
0:21:04 can collaboratively edit
with every user individually.
0:21:07 So you can have a real time collaborative
editing system and OT based systems.
0:21:10 Most of them work like this.
0:21:12 So long as you have a centralized server,
which gets to make all of the decisions.
0:21:15 and really what that server is needed
for is to order things and create a
0:21:19 canonical ordering of all of the events.
0:21:21 So ultimately OT systems like that, and
there's a lot of different OT systems,
0:21:25 end up with a, You mentioned event
sourcing earlier, you end up with an
0:21:28 event sourcing style list of operations
that can all be applied in order.
0:21:32 And if you started an empty document,
apply all the operations, you'll end
0:21:35 up with the current document state.
0:21:36 and really you just have one, you
know, monotonically increasing version
0:21:39 number, which is the version after, you
know, N operations have been applied.
0:21:44 So that works great.
0:21:45 It's pretty fast.
0:21:46 It's what we use for Google Wave.
0:21:47 But Google Wave ran into the
problem where, We wanted to
0:21:50 be able to have federations.
0:21:51 So we wanted to be able to have an
arbitrary set of servers work and for
0:21:54 that, the network protocol, was horribly
complicated and it didn't work reliably.
0:21:59 I saw it work reliably.
0:22:01 It felt like, you know, depended on the
phases of the moon and everything else.
0:22:05 where.
0:22:07 The servers needed to, between all of the
servers, arrange themselves in a tree so
0:22:11 that there was one server that was the
most in charge of all of the servers.
0:22:15 And unfortunately, if that server
disappeared, then you'd have a net split.
0:22:18 and all of this was just a, it was a,
problem with the technology of the day.
0:22:21 It was a problem with operational
transform, ultimately.
0:22:23 That we couldn't build what
we wanted to build with OT.
0:22:25 And that sort of got me thinking,
like, how do we solve this problem?
0:22:29 so this is condensing about, 12, 13 years
of my, my time, after just very briefly
0:22:35 after Google Wave shut down in 2011, I was
incredibly sad about it and I thought, oh,
0:22:40 there's no way this technology is so cool.
0:22:42 So JavaScript was, As a language that
people like to write was very new.
0:22:45 It was Node.
0:22:46 js 0.
0:22:46 4. NPM hadn't been invented yet.
0:22:49 if you can imagine it.
0:22:50 And I thought, Oh, I'm going to use
JavaScript and just write a really,
0:22:52 really simple small library that does
operational transform in JavaScript.
0:22:55 And I called it share.
0:22:56 js and weirdly lots of people know
about the project even though I've
0:23:00 taken the website down and, you know,
it's all, it's not used for much now.
0:23:04 I had a call with someone, who
works at WordPress the other
0:23:07 day, and apparently Share.
0:23:09 js helped them land some giant deal
with a company in Europe, which I'm
0:23:13 not going to name, and was used as
the back end for this, this whole news
0:23:17 site for a long time, which I had no
idea about because it just implemented
0:23:20 Operational Transform well, which
is all you want a lot of the time.
0:23:23 so I made that and then, but
I was still thinking about the
0:23:25 question of how to make CRDTs fast.
0:23:27 There was a whole series of new papers
that happened again and again and
0:23:30 again, and I felt like if, if we had a
good version of Operational Transform,
0:23:34 we could make an open source version
of Wave or something like it, but it
0:23:37 still didn't quite scratch the itch,
because I still didn't quite know how
0:23:40 we could get all of these servers to
collaboratively, you know, collaborate.
0:23:43 Eventually, a few years ago, I ended up
getting frustrated, and I thought I've
0:23:47 been avoiding CRDTs for the longest time.
0:23:49 And I read some CRDT literature and I was
like, no, no, what's the latest on CRDTs?
0:23:54 How are they supposed to work?
0:23:55 And I read some papers and I
thought, This is ridiculous.
0:23:58 You could just make, you could make an
implementation of this that works fast.
0:24:01 The only reason why CRDTs were slow at the
time is because people hadn't spent enough
0:24:04 time optimizing the algorithms themselves.
0:24:06 And Kevin Yarns, the author of
Yjs, he'd done a lot of work.
0:24:09 Martin Kleppmann, the author of
Automerge, had done a lot of work.
0:24:12 But at the time, Yjs was, performed okay.
0:24:16 Automerge was incredibly slow and
to work around that Automerge at
0:24:19 the time separated all the code out
into this front end and back end.
0:24:22 So the back end did all the slow work
and then it had message passing to
0:24:24 pass message into the back end so that
this whole slow part of it wouldn't
0:24:28 interact, interrupt the user experience.
0:24:30 but I grabbed a whole bunch of ideas
from both approaches and there's a
0:24:33 YouTube video of me picking Kevin Yarns
brain on YouTube if you want to, if
0:24:36 anyone's ever interested watching for
three hours, let's talk about CRDTs.
0:24:40 But it turns out that, you know, with
the right application of some complex
0:24:43 data structures, using B trees in the
right ways, and, um, using some of
0:24:46 the techniques that Martin Kleppmann,
well, he was the first person I saw do
0:24:49 it, where, in the file system, the way
that Automerge saves stuff, saves data
0:24:55 to disk, Most applications think about
it, they call it an array of structs.
0:24:59 So if I've got a bunch of rows in a
table, every row is an object or a struct,
0:25:04 and then I've got an array of them.
0:25:05 You know, I might have a hundred of
them and each one represents a row.
0:25:08 Most databases spin that on its head.
0:25:09 So the database will instead
store one file per column.
0:25:13 So It's a struct of arrays, if you
want to think about it that way.
0:25:16 what Martin Kleppmann did is he
said, well, each of these columns
0:25:19 in something like Automerge, if it's
describing all of the keystrokes that
0:25:22 happened, we can store that as a string.
0:25:24 And if it's describing the positions
inside a document that everything is
0:25:26 stored, well, those numbers turn out to
be sequential almost all of the time.
0:25:30 You know, about, people usually
type in runs of about 20 characters
0:25:33 before they move their cursor.
0:25:35 So if you just store run length
encoded, that data ends up
0:25:38 collapsing and becoming much smaller.
0:25:40 So I was saying before, CRDTs,
you type a moderate document, it
0:25:43 might take 800 megabytes of memory
or a gigabyte of memory and disk
0:25:46 space to store it in raw JSON.
0:25:48 But if you run length encode everything,
in these columns, you can save, store
0:25:52 the same data in a megabyte or less.
0:25:53 So.
0:25:54 Martin Kleppman did that and did that in
the file storage engine of, Automerge.
0:25:59 Yjs copied that.
0:26:00 Then I took that idea and did that.
0:26:02 Oh, and Yjs also did some of this.
0:26:04 I don't want to take credit for all of it.
0:26:05 It's all standing on the
shoulders of giants here.
0:26:08 but I made a library called Diamond Types
where I was like, Oh, how fast could we
0:26:11 make CRDTs go and use that internally?
0:26:13 So all of the internal data is
all run length encoded internally.
0:26:17 And that's a. that's a whole tangent
that I need to write up at some point
0:26:20 because there's a whole bunch of clever
engineering tricks to get, make that work.
0:26:23 but as a result, you can make CRDTs
incredibly fast, way faster than
0:26:26 anyone could possibly imagine.
0:26:28 You know, we're talking in the order
of millions of keystrokes a second
0:26:31 in a text editor, which is, you know,
more than anyone would want to type.
0:26:35 and we can store it all very
efficiently to the point that,
0:26:37 I added, a, LZ4 compression.
0:26:40 So.
0:26:40 In Diamond Types, I store all of the
text content of what you've typed and
0:26:44 then a bunch of metadata that stores
all this extra CRDT stuff, essentially.
0:26:47 turns out that if you LZ4, like, just
use a very standard, very, very fast, low
0:26:51 grade compression system on the text, then
the amount of data that you save just by
0:26:55 compressing the text lets you put all of
that metadata in, and often you end up
0:26:59 with documents that are smaller than the
original text, even though you've got
0:27:02 A keystroke by keystroke entire history
stored in the same file, is really cool.
0:27:07 so a few more decades or a few,
you know, well, I guess one
0:27:09 decade of work after, Google Wave.
0:27:12 And we collectively as an
industry have figured out how
0:27:15 to solve the problem of CRDTs.
0:27:17 I mean, I'm, I've had several people come
and talk to me over, over the years and
0:27:21 say, Seph, you could remake Google Wave.
0:27:24 And I'm like, I know, and we could
remake it better and greater.
0:27:27 Maybe Patchwork is trying
to aim towards some of that.
0:27:30 but we're in a much better
place, from all of that work.
0:27:33 So let's come back to share.
0:27:35 js in a moment.
0:27:36 I want to learn more about those,
various components, but maybe jumping
0:27:40 ahead for a bit, what would it take
today to rebuild Google Wave with
0:27:47 Rebuilding Google Wave with today's stack
0:27:47 honestly, the biggest thing
would be some funding.
0:27:50 So, Google Wave used Operational
Transform, and now we've
0:27:53 got great CRDTs available.
0:27:54 So, I would use my own implementation
of CRDTs, or use Automerge or Yjs.
0:27:58 I think any of those libraries work great.
0:28:00 And there's a bunch more people working
on that would probably perform fine.
0:28:05 So, we'd use the CRDT.
0:28:06 Google Wave used, it
actually People forget this.
0:28:09 We created a custom jabber, like XMPP
extension, and the servers interoperated
0:28:13 through that, which is complicated, and I
probably wouldn't make that same choice.
0:28:17 We'd need an identity system, if
I were to do it today, and yes,
0:28:20 I have been thinking about this.
0:28:21 I'd consider piggybacking on the BlueSky
identity system, and, since that's
0:28:26 actually a federated system even though
they haven't built all of the tooling
0:28:30 to make it easy, but, I think it's
actually an excellent system and lets
0:28:33 people, one of the freedoms that that
system guarantees is that if you've
0:28:36 got an identity on one computer or one
domain name, so identities are associated
0:28:40 with a domain name, you can migrate
that identity to another domain name.
0:28:43 And anyone that knew your old identity
will have their contact address books
0:28:46 automatically update and all of your
data moves across, which is great.
0:28:49 So we need an identity system,
maybe that, maybe something else.
0:28:53 and then we need a web front
end or a front end of some sort.
0:28:55 And unfortunately, one of the, It's so
embarrassing on behalf of our industry.
0:29:01 one of the last bastions of unsolved
problems is making a good rich
0:29:05 text editor inside a web browser.
0:29:07 in the last Like, however many years it's
been, it's 2015, so I guess it's been 14
0:29:11 years since Google Wave shut down in 2011.
0:29:14 in all of that time, there's been
multiple aborted attempts to try
0:29:17 and make a web standard for being
able to edit a rich text document,
0:29:20 and none of them have succeeded.
0:29:22 All of them have fallen apart, and,
rich text editing is a massive mess.
0:29:25 but there are a lot of JavaScript
libraries that pave over a lot of
0:29:29 the worst parts of that problem.
0:29:31 maybe lingering, on the last aspect
for a bit, I have deliberately tried
0:29:35 to avoid rigid text editing and all
facets of it, just for my own sanity
0:29:41 sake, me, working primarily on.
0:29:44 Overtone and LiveStore.
0:29:46 Overtone is a music app where I can gloss
over rich text editing for the moment.
0:29:51 This is where it's rather important
that your music library is in sync,
0:29:55 playbacks, playback history, playback
state is in sync, etc. That's where
0:29:59 I'm leaning on event sourcing.
0:30:01 But, Looking at rich text editing and real
time collaboration on text, I'm aware of
0:30:09 projects such as ProseMirror or CodeMirror
as sort of the code twin project to it.
0:30:15 I'm aware of the TipTap
rich text editing framework.
0:30:20 I'm also aware that Facebook has,
I think, a pretty good one, which
0:30:25 I'm blanking on the name right now.
0:30:27 But yeah, where are those
projects falling short?
0:30:30 I mean, ideally I'm with you, this
would be a web primitive that is
0:30:35 like standardized and implemented
by all browsers, but what's so
0:30:43 Rich text editing
0:30:43 honestly, they're probably mostly fine.
0:30:46 They fall short in, for example,
mobile editing, so I want to be able to
0:30:50 have a native experience on my phone.
0:30:52 if I open up Apple Notes, I can select
text and I can bold it and highlight
0:30:55 it and do lots of different things.
0:30:57 a lot of the existing editors will, it's
just really hard to hook into the native.
0:31:02 Rich text editing through a web
browser through mobile Safari.
0:31:05 so they, they need that to work.
0:31:06 And then they need it to work
from Chrome with Android.
0:31:08 And then they need it to work
with lots of different things.
0:31:10 mean I still run into
problems sometimes on Reddit.
0:31:13 If you use the new Reddit interface,
they've got a rich text editor.
0:31:16 in the reply box and sometimes
I've typed and then hit backspace.
0:31:20 Sorry, hit undo and weird things reappear
or disappear or the wrong text, you
0:31:24 know, it gets jabbled and confused.
0:31:27 so there's a bunch of
correctness problems like that.
0:31:30 That is, it's incredibly boring work.
0:31:32 but it's really important
for this kind of thing.
0:31:35 I have a longstanding rule.
0:31:37 I don't know if this has a name, so
maybe it can be Seph's rule if no
0:31:39 one else has claimed it, but that
essentially technology gets worse the
0:31:43 further away from, mostly Bay Area
software engineer problems that you are.
0:31:48 So if you have the kind of problem
that someone, a Bay Area technologist,
0:31:52 thinks about a lot, there's going to
be good libraries, good software, good
0:31:54 tooling around solving that problem.
0:31:56 But.
0:31:57 You, for example, speak a language that
where characters are typed right to left,
0:32:01 instead you're gonna run into problems.
0:32:03 in Australia we have roundabouts, we,
you know, which the Americans call
0:32:06 traffic circles and Google Maps took a
decade to be able to understand how to
0:32:09 actually give you navigation directions
around a roundabout in Australia, because
0:32:12 they don't have them in America, they,
I mean they have a few, but they, most
0:32:15 Americans I know are terrified of them.
0:32:17 but I feel like Rich text editing is one
of these problems because us software
0:32:20 engineers mostly use plain text.
0:32:22 So.
0:32:23 There are so many great plain text editors
that exist both on the web and on desktop.
0:32:27 but yeah, rich text is just harder.
0:32:28 It's further away from the
problems that we regularly solve.
0:32:31 I fully agree.
0:32:32 And I love Steph's rule.
0:32:34 maybe that it's going to become a thing.
0:32:36 and so in particular to you touching
on mobile, I feel like mobile and
0:32:41 the combination of mobile and web,
that is indeed like one of the
0:32:45 hardest modes that are still, largely
untamed, and this is both I think
0:32:51 particularly for web technologies,
but, overall, it is just a, it had
0:32:55 less time to kind of mature over time.
0:32:59 And particularly for web mobile
experiences, when, when it comes
0:33:03 to text editing, et cetera, like
dragging around a cursor, this
0:33:07 is where things feel very choppy.
0:33:09 The, creator of React, Jordan Walk,
He shares some, some things about that
0:33:14 once in a while, where he's kind of
particularly pointing out where mobile
0:33:19 web is falling short, to be competitive
with mobile native in terms of animations
0:33:26 and like, just, native interactions.
0:33:28 I mean, it's a very hard set
of problems, but I think.
0:33:32 Addressing those feels very worthwhile
to make the web even a richer platform.
0:33:37 But then you could also argue that sort of
not necessarily in the interest of Apple.
0:33:42 And that's a whole
different, kind of worms.
0:33:45 I mean, yeah, it's easiest to think
of Apple as a person, but they're
0:33:49 actually, I can't remember what
the 200, 000 people or something.
0:33:52 And some of those people are
really interested in, in open
0:33:54 standards and some aren't.
0:33:55 And some of them are great people
and some of them are assholes.
0:33:58 And that's true of every company
that you could name, you know
0:34:00 I agree.
0:34:01 And in apple's credits they have
push safari and the capabilities
0:34:04 way forward over the last couple of
years It's really has come a long way
0:34:09 Yeah, I think the safari team is
very dedicated to making safari an
0:34:12 excellent web browser and it shows
but there's still some hard problems
0:34:16 that haven't been tackled yet.
0:34:17 it's quite sad when I was young I started
programming when I was about 10 years
0:34:20 old and Every year there would be new
things and new technology and, you know,
0:34:25 like I got to see the birth of Windows
95 and, I thought, wow, programming
0:34:29 is going to be so easy in the future.
0:34:31 You know, like I imagine that right at
the time there was whole teams of people
0:34:35 working on making something, but in the
future, there'd be such good libraries
0:34:38 and such good software tools available
that one person could do the work of an
0:34:42 entire team or entire you know, of a whole
project because you could just grab in
0:34:46 such good software and there'd be such
good primitives available to be able
0:34:49 to solve all the problems that you had.
0:34:50 And I feel like that
prediction of young me.
0:34:54 I'm so sad.
0:34:55 I'm disappointed that
it didn't come to pass.
0:34:58 And instead we have, you know, it's like,
Oh, back then, if you wanted to build a
0:35:01 program, you want to write some software.
0:35:03 Well, I mean, like, I'm so
sorry to everybody else, but.
0:35:05 I would have just targeted Windows,
you know, written a Windows application
0:35:09 and there it is, and, you know, made
some little command line tool in
0:35:12 DOS or, you know, if you want to, if
you're working in Linux, you would just
0:35:15 make a command line tool because that
was how most good software existed.
0:35:19 But now it's like, oh, well, you
know, I guess you're going to want
0:35:22 a Linux and Windows and., Mac Os
desktop version of your application.
0:35:26 And then you need to make it
work for iOS and Android as well.
0:35:28 So there's five different platforms right
outta the gate and, you know, are you even
0:35:31 trying, if it doesn't work on all five of
those platforms, and it should work well.
0:35:35 But I guess you could just use the web,
but the web's not actually very good
0:35:38 on, on, you know, on mobile platforms.
0:35:40 So you really want to have
a, native application.
0:35:43 Oh, but all the programming
languages that you use.
0:35:45 For building native applications on iOS
are different from Android, different from
0:35:48 the web, different from everything else.
0:35:51 And, you know, and we keep on saying,
well, we can kind of solve this with
0:35:54 WebAssembly, for example, and that way
we can have one, you know, target from
0:35:57 all of these different bits of software.
0:35:59 And, and that's true.
0:36:01 If we had good UX libraries across every
platform, which were consistent and
0:36:05 work well, I mean, this is somewhere.
0:36:07 I'm very, I was very excited about
react native when it first came out.
0:36:10 And so many people were kind
of like some random thing.
0:36:13 I was like, please, please.
0:36:15 I really want just one good, you know,
application programming interface I can
0:36:20 use to build real software for real users.
0:36:23 it feels like a tragedy, a tragedy of the
commons problem in my mind that there's
0:36:26 so many companies doing really good work.
0:36:29 But each company, of course, is
trying to solve the problem that their
0:36:32 particular company will make money from.
0:36:34 And there are the commons in software,
the commons of the standard set of desktop
0:36:39 applications, of user interface libraries.
0:36:42 Say, if I wanted to write a
desktop application in Rust.
0:36:44 there's open source libraries which
will interact from Rust to GTK and
0:36:48 Rust from, to the Windows libraries
and so on, but almost all of them
0:36:52 are maintained by volunteers.
0:36:53 And it's a huge problem, like Google
Chrome has probably had a billion dollars
0:36:57 of investment put into it at this point.
0:36:58 to be able to have a web browser that
works across every platform and let
0:37:01 you be able to run arbitrary software,
like arbitrary web software across
0:37:05 all the platforms Google Chrome runs.
0:37:07 and it might take something around
that order of magnitude to have a
0:37:10 really good user interface library.
0:37:12 That works across every platform that
exists today so that I can just build,
0:37:16 like, write once, run everywhere, you
know, like, write software once, write
0:37:20 Patchwork, write something like that, and
then just have Good primitives that mean
0:37:23 that my program can work in every context
that I want it to run, but as far as I can
0:37:27 tell, no one's really putting that time
and effort and investment in, you know,
0:37:30 like, there's, there's things like Flutter
and I'm very excited by them, but I've
0:37:33 burned by Google projects being canceled
before, but it just feels like one of
0:37:37 these things that like, I want that.
0:37:38 And then, and then on the flip side
of that, we've got, things like,
0:37:42 SQL, which I have massive problems
with, even though it's one of the
0:37:45 most, one of the best, like think
programs like Postgres are some of the
0:37:49 highest quality software that exists
today that we can, we use regularly.
0:37:52 And yet its design is from the seventies.
0:37:55 there's a wonderful talk by Rich
Hickey, where he talks about,
0:37:58 value oriented programming and
place oriented programming.
0:38:02 And he says that.
0:38:03 Back in the day, we
didn't have much memory.
0:38:05 Our computers had literally like,
Some of the old Atari's and Nintendo
0:38:08 Entertainment System has less RAM
than is available in one tweet.
0:38:12 You know, before they made tweets longer.
0:38:14 It had like, it's like a
hundred and twenty bytes of
0:38:16 RAM or something ridiculous.
0:38:17 And they made Super Mario Brothers
with these wild limitations.
0:38:21 And so it makes sense, if you're
storing data, that every time the value
0:38:24 changes you want to Replace, you have
one place where the value goes and you
0:38:28 replace the value that's stored there.
0:38:30 And now SQL is stuck in the past
where we've got a table and we just
0:38:34 edit the rows and you've got no
idea of what's actually changed.
0:38:37 And that makes it incredibly difficult
to build collaborative software because
0:38:40 You need to know that kind of history.
0:38:41 So people maybe layer collaborative
things on top of Postgres, but then
0:38:45 now Postgres, you're sort of fighting
against the ergonomics of Postgres itself.
0:38:48 And again, no one's solving this problem.
0:38:50 And it really upsets me.
0:38:52 Oh man, I have so many thoughts on this.
0:38:54 I 100 percent agree with like that
assessment of like the tragedy of the
0:38:59 commons and I'm both devastated about
it and also hopeful because of some of
0:39:05 the initiatives that you've mentioned.
0:39:08 the TLDR of it is that I still think
that the web is the best vehicle for us
0:39:14 to, make it through this uncanny valley.
0:39:17 Since I think if you exclude some
aspects, for example, mobile web or some,
0:39:22 some other, or browser, strict browser
compatibility to a certain limit, Firefox
0:39:27 is lagging behind in a bunch of things.
0:39:29 You can actually already
live in the future.
0:39:32 By building fully for the web, things
like WebAssembly have come a long way.
0:39:37 things like WebGPU, et cetera.
0:39:39 And there's also new frameworks
that are in the making, but not as
0:39:42 mainstream yet that fully embrace those.
0:39:45 So where some lower level
primitives could be taking
0:39:49 advantage of WebAssembly or WebGPU.
0:39:52 the thing that's, commonly strikes
me is like the most comical unsolved
0:39:56 problems is list rendering, where we
have so many React list virtualization
0:40:03 libraries, and most of them still suffer
from the same underlying problems.
0:40:08 And whenever you render a list, like
some symptoms that appear typically
0:40:13 comes along with frame drops.
0:40:16 But also like, it's rare that, you
persist the position of a list and
0:40:21 there's just like, if you start digging
into, lists as unsolved problems,
0:40:27 it becomes very comical, but the
way how I, try to address that for
0:40:31 myself is by rendering to a canvas.
0:40:35 And that's a whole different
approach altogether.
0:40:40 We don't need to go into
that, into that rabbit hole.
0:40:43 But yeah, I'm, hopeful that
things are coming along.
0:40:47 And you've also been
mentioning React Native.
0:40:49 That has, that's a long,
long, long project.
0:40:52 And in a way I have so much admiration
and respect for the people who
0:40:58 relentlessly keep pushing forward on that.
0:41:01 There's been some really big.
0:41:03 breakthroughs over the last couple of
years, some of them you would think
0:41:07 like, wait, that's kind of obvious.
0:41:09 Why wasn't it like that
from the beginning?
0:41:11 But there, there are reasons for
that, but it's really getting there.
0:41:14 And, particularly for mobile, it
is like, it's becoming a really
0:41:20 attractive, platform to, to ship things.
0:41:23 And this is where you can, at least
when your goal is at least code reuse.
0:41:29 then you can get a long way if
you target React and React Native.
0:41:33 We're not yet at that point where you
have the same set of like interactive
0:41:38 components and they work in all platforms,
no matter what, maybe at some point,
0:41:43 but there's progress in that direction.
0:41:46 yeah, I mean, while we're at it, I'm
just going to throw out some more
0:41:48 things that I hope other people fix.
0:41:50 Well, someone fixes like it,
it might end up being me.
0:41:53 I was saying earlier that, if I could live
a thousand lives, I would just spend a lot
0:41:58 of them rewriting bit by bit every piece
of software that runs on my computer.
0:42:03 So everything actually
works well and consistently.
0:42:06 I've been building a little helper tool
web app just for the last couple days
0:42:09 to be able to, annotate documents, to
be able to, it doesn't really matter,
0:42:13 it's some little helper web app.
0:42:15 And once again, I'm frustrated because
I have a server, and my server has
0:42:18 some data, and I've got a frontend,
and my frontend needs to edit that
0:42:21 data, and as I change the data, the
changes need to be propagated to
0:42:24 the server, and the server keeps a
copy of it, which it stores on disk.
0:42:27 And that problem, I feel like every
single time I try and approach
0:42:30 it, I have to re implement the
wheel and I start from scratch.
0:42:34 And it's not even this data that I'm
editing isn't even collaborative.
0:42:38 It's just like, okay, great.
0:42:40 You know, let's start climbing
the ladder of editing once again.
0:42:43 So the first step, you know,
I've got one object and I send
0:42:46 it to the browser and the browser
sends back an entire copy of it.
0:42:49 Next run.
0:42:49 Okay.
0:42:50 The server can do versioning
where the browser can subscribe,
0:42:53 it can get a certain version
and find out what version it is.
0:42:55 Next run, Now I can subscribe to the
browser, can subscribe from some version
0:42:59 every time a new version gets sent, the
server sends a new copy of the data.
0:43:02 Okay, then now I can do
differential updates.
0:43:05 Now I can do collaboratively editing
on top of the differential updates.
0:43:08 Okay, now I can do like, you know,
anyway, it's just a series of things over
0:43:11 and over and over again, every single
piece of software I end up writing.
0:43:14 And most of the time I'll cap out
somewhere pretty low down that ladder,
0:43:17 even though I'm probably one of the,
you know, like, I know all of the
0:43:21 tools, I know all of the ways that
we can make this problem be good,
0:43:23 but our platform isn't very good.
0:43:25 And I think a lot of the problem with
that is because like we still think
0:43:28 in most software about messaging,
it's a message oriented system,
0:43:32 how we actually want to think for
a lot of this isn't about messages.
0:43:35 it's about updates.
0:43:36 it's, I've got some semantic
idea of the state of the world.
0:43:39 And instead of sending messages to
the client, which is kind of a low
0:43:43 level primitive, I instead want to
be sending updates and describing how
0:43:46 the document has changed over time.
0:43:47 I was working with the,
braid group, trying to build.
0:43:50 So we together wrote a proposal for
the IETF on a primitive that we could
0:43:54 add that's different from get and put
and post and so on, but a different
0:43:58 verb, which would be a subscribe
verb, to say if there's some resource
0:44:02 that lives at some URL, I want that
resource to be able to change over time.
0:44:06 And I don't want to have to re
implant the wheel, reinvent the
0:44:08 wheel every single time, describing
how that resource changes.
0:44:11 In fact, it would be great if
the web, like HTTP itself, had a
0:44:14 primitive that described a resource
that could change over time.
0:44:17 And then, for example, NGINX, if NGINX
understood that that was something that
0:44:20 changed over time, instead of NGINX
storing some cache invalidation time
0:44:24 and then occasionally revalidating its
cache, but in the meantime it's serving
0:44:28 out stale copies of this resource.
0:44:30 Instead, NGINX could just subscribe to
the underlying layer and say, Hey, I
0:44:34 want, I'm interested in this document
and tell me every time it changes.
0:44:37 And then NGINX can be doing fan out to all
the different clients that is interested
0:44:40 in subscribing to that document.
0:44:42 And you'd have a much better,
much more performant way of being
0:44:44 able to distribute data around.
0:44:45 That is way easier to program, way
faster from a performance perspective.
0:44:50 And then it could be
integrated into lots of things.
0:44:52 Like integrated into Postgres,
integrated as a standard thing that
0:44:54 we have access to in our web servers.
0:44:56 Something we have access to
in our web browsers and so on.
0:44:59 And it's primitives like this
in my mind that, you know, like,
0:45:01 I'm like, Oh, please, please.
0:45:03 Give me better things like this.
0:45:04 This is the kind of thing that I
feel like all computing, again,
0:45:07 it's that lesson from Google Wave.
0:45:09 All computing can work like this.
0:45:10 You can just have the
data update in real time.
0:45:12 And this is a primitive that almost
every program I've ever worked on
0:45:16 is needed in some form of, you know,
In a web browser, in a mobile phone,
0:45:19 in some monitoring application.
0:45:21 I have some data that lives somewhere
and I want my application to be kept
0:45:24 up to date and told whenever changes
happen, and then I wanna be able to
0:45:27 edit that data from different clients
and have something sensible happen.
0:45:30 And there's a simple version
of that, which is a centralized
0:45:33 version where a centralized server
like has to authorize all changes.
0:45:36 And you have a version number that
goes up by one every time a change
0:45:39 happens, which we should be able
to just trivially have built into
0:45:42 Postgres, in my mind, in SQL databases.
0:45:44 And then there's the CRDT, the real
time collaborative editing use case
0:45:47 for that where I don't actually
want a single version number, I
0:45:49 want something kind of like Git.
0:45:51 but where I can collaboratively edit
any kind of data and I can do it in
0:45:53 real time rather than needing to hit
commit every time I make a change.
0:45:56 I want to push that out.
0:45:57 and hopefully as well, I want to be
able to do optimistic replication,
0:46:00 optimistic concurrency control.
0:46:02 So the Ink & Switch team is working
on this, and having branches and so on
0:46:06 for other kinds of applications, right?
0:46:07 Again, it's, it's my rule.
0:46:09 It's the, it's like.
0:46:11 We've built these tools for
ourselves for code editing where
0:46:13 we get to collaborate using Git.
0:46:15 We get to have branches, we get
to do merging, we get to look at
0:46:18 all the diffs between versions.
0:46:20 Everybody wants these tools.
0:46:21 Everyone.
0:46:22 You know, from people working on
CRMs to people doing video editing to
0:46:26 people, you know, I'm sure running,
like wanting to talk to astronauts
0:46:29 in space, this comes up all the time.
0:46:32 And for those kind of people, for these
projects that want to build using these
0:46:35 kind of primitives, it's so hard to
have, like, we just, our primitives
0:46:38 on modern software aren't there and.
0:46:41 No one like application teams
aren't working on it because
0:46:43 they've got products to ship
0:46:44 so I've had a couple of folks Who are
working on that on the podcast before so
0:46:49 for example notably the folks working at
Electric They're tackling specifically
0:46:53 that problem for Postgres were exactly as
you're describing that you can subscribe
0:46:59 to or like you're you can basically just
Express something they call a shape.
0:47:03 It's sort of like we can oversimplify
and it's like sort of a scoped query.
0:47:07 And then your client can subscribe
to the result of those queries.
0:47:12 And it basically always gets an
up to date query result locally.
0:47:16 Well, eventually consistent, but you
already get those sort of one level
0:47:20 up primitive, where you don't need
to think about get, propose, delete,
0:47:25 but you can just, subscribe to that.
0:47:28 well, it comes with its own challenges
and if you're looking at the fundamental
0:47:33 layer, that you describe as message
oriented, I think that's closer
0:47:37 to the metal and where you need to
roll up your sleeves more, but it
0:47:40 also allows you to implement things
for different trade offs in mind.
0:47:44 So one thing I'm, curious about
how you're navigating trade
0:47:48 offs when it comes to, to data.
0:47:49 It's all about trade offs, like
what for a given application,
0:47:53 what can you get away with?
0:47:55 How much is fine that different parts
of the application stage do they need
0:48:00 to be fully transactional or is it
fine that one part of the application
0:48:04 Is maybe lagging slightly behind, and
how do you address the cap theorem
0:48:09 for your particular application?
0:48:11 So I'm curious how you're thinking
about navigating trade offs and
0:48:15 like trade offs even go to a point,
not just to build the initial app.
0:48:19 But also to keep in mind how you need
to evolve the app over time, how certain
0:48:25 are you about the data model that you've
picked that this is the one you still
0:48:29 have, like in five years, you're going
to have it in five years, probably
0:48:33 no matter what, but the question is,
are you still happy with it in five
0:48:36 years or, is this the worst decision
you've made building the application.
0:48:42 So I'm curious how you're thinking
about navigating trade offs when
0:48:48 Data layer design
0:48:48 I mean, fundamentally as engineers,
you navigate them one by one, you
0:48:52 know, while sweating profusely.
0:48:55 That's how that goes, I think.
0:48:56 yeah, I feel like there's, there's
a bunch of interesting problems in
0:48:58 all of the things that you've said.
0:49:00 I had a few, couple small conversations
with PVH, talking about, he built this
0:49:04 thing based around lenses of, of how
data can evolve over time in a Cambria.
0:49:09 That was it.
0:49:09 Yeah.
0:49:10 Um, in local-first software.
0:49:11 And I have a bunch of my
own thoughts about that.
0:49:13 And you know, like I've got
designs in mind that I'd love
0:49:16 to experiment and play with.
0:49:18 So there's something there, which is,
you know, like it's really interesting.
0:49:21 HTML, has evolved beautifully over time.
0:49:24 Like HTML has barely changed at
all since it was first introduced.
0:49:28 like we've introduced new tags,
but almost like all of the
0:49:30 tags still follow the same.
0:49:32 Fundamentally XML style
structure, and that's wonderful.
0:49:36 It's wonderful.
0:49:36 It's been able to evolve like that.
0:49:38 Email has evolved slightly
less gracefully, but emails.
0:49:41 I think email up email programs
from the 70s probably still work
0:49:44 today with most modern emails,
which is incredible, even though.
0:49:48 Email messages themselves are
almost impossible to pass correctly.
0:49:51 And, I've got a lot of
thoughts about that as well.
0:49:53 I've got some friends who work at
FastMail and they've, pinned me to the
0:49:55 wall with things about email that I
had no idea about that are horrific.
0:49:59 but there's this open problem,
which is how can data models change.
0:50:02 So there's a, set of problems
there, which I'd love to solve.
0:50:05 There's a set of problems around,
how is our data stored and sent.
0:50:09 in my mind, what I would
really like to have is.
0:50:11 I feel like there's some kinds of programs
where I actually really You know, I'm so
0:50:16 sorry to the Ink and Switch folks, I'm
quite happy for there to be a centralized
0:50:18 server for Discord, or for IRC.
0:50:20 For something like that, when there's
a place that we all go to, I'm quite
0:50:23 happy for there to be one computer
that's authoritative and decides, you
0:50:26 know, all of the messages that are and
aren't part of the log of messages.
0:50:30 I feel the same way about banks.
0:50:32 I'm more than happy for them to use
a centralized transactional database.
0:50:35 I'm not a Bitcoin absolutist by any means.
0:50:37 I think decentralized
databases work great.
0:50:39 but I'd really like some set of
primitives where, The primitives that
0:50:41 I use in my computer program, like what
I embed into my program and use, are
0:50:45 the same set of primitives that I could
use either with a centralized server,
0:50:48 which has transactions and various
other ergonomics, or with something
0:50:51 like Automerge or Yjs, where, I'm
actually collaboratively editing a CRDT.
0:50:56 And I feel like there's a lot of overlap
there around what's the shape of the data.
0:50:59 What does the change look like?
0:51:01 You know, subscriptions, which
also you almost always want
0:51:03 in a centralized use case.
0:51:05 and then there's a bunch of
questions around performance.
0:51:08 so I wrote a CRDT library of my own called
Diamond Types I haven't kept up with all
0:51:11 of the demands that I've made of myself.
0:51:13 busy and distracted, but I use that.
0:51:15 That was the test bed in original
place where I built Eg-walker,
0:51:18 which is an algorithm that I've
written a paper on, which is just
0:51:20 for collaborative text editing.
0:51:21 and I wanted to make
it really, really fast.
0:51:23 And people kept saying, well,
but don't you know that if you
0:51:26 collaboratively edit a text document
in something like Yjs or Automerge,
0:51:29 it stores every single keystroke
that's ever made to the document.
0:51:32 And these documents are going to get
huge, and we need some way to be able to
0:51:35 prune history, and it's really important.
0:51:37 So I said, well, Look, that might,
I agree, I think that's a very
0:51:40 interesting and important problem.
0:51:42 But let's first start, let's just
start by trying to make it as fast
0:51:45 as possible and as small as possible.
0:51:46 So, you know, even if we prune
it, it's going to be pruned
0:51:49 to be even smaller regardless.
0:51:50 this is always when I do a lot of
performance work and people, a lot of
0:51:54 times people reach for multi threading.
0:51:56 Let's, let's spawn it across lots of
threads on your computer, which is a fine
0:51:59 approach, but It's almost always better
to start with trying to make it run as
0:52:02 fast as you can on one thread before
you run it across multiple threads.
0:52:04 I mean, this is why the M1 series
of, of Apple was like such a big
0:52:08 deal because it showed like, okay,
we can actually do a lot better even
0:52:12 in a single threaded environment.
0:52:15 Exactly.
0:52:15 Yeah, but It turns out that, the
collaboratively editable text documents
0:52:19 don't actually grow very fast.
0:52:21 the amount of data, the number
of bytes on disk is tiny.
0:52:23 And, and yeah, like I think
that it might be useful to
0:52:25 build software to prune anyway.
0:52:27 And I've got a bunch of, you know, like
I've thought a lot about that problem
0:52:29 because people keep talking about it.
0:52:30 but from an engineering perspective,
a lot of the time we can just keep all
0:52:33 of the data and it's actually fine.
0:52:34 We just need to, for example, store
it in some slightly more efficient
0:52:37 way sometimes than raw JSON.
0:52:38 And, you know, and like, that's the
thing that we need to think about.
0:52:41 modern computers are so fast.
0:52:43 Like, yeah,
0:52:44 I feel like similar to what you've
mentioned before with quoting Paul
0:52:49 Graham of like, what was the quote again?
0:52:52 It's it's what would it be ridiculous
to not have in a hundred years?
0:52:55 Yeah, exactly.
0:52:56 So you imagine a hundred years, it's
like, we still don't have something.
0:52:58 It's crazy.
0:52:59 Then it's, okay, well, if we didn't have
that in 100 years, it would be crazy.
0:53:02 Could we just build it today?
0:53:04 Exactly.
0:53:05 So similar to that, we can also ask
ourselves more often, like, Which things
0:53:10 would actually be totally fine that
historically we always like shied away
0:53:14 from and that sort of like by now, there's
sort of like this, picture of like a baby
0:53:20 elephant kind of, pinned to a pole and
it's like, it has learned it cannot escape
0:53:25 and now it's, a full upgrown, elephant
and still, pinned to this tiny pole.
0:53:29 I think there's like, a lot of
similar stuff, the way, how we go
0:53:33 about programming and we need to
unlearn, forget about some things.
0:53:38 And this is, I feel like also why
some of the most brilliant, new
0:53:42 technologies are by people, by, by
newcomers, like new generations of
0:53:47 programmers who are like blissfully
unaware of some of like the old stigma.
0:53:53 And this is how we get new ideas as well.
0:53:56 yeah, I really agree with that.
0:53:57 there's something that it doesn't,
I keep thinking about, there
0:53:59 was a, there was the Unix room.
0:54:01 So Unix was invented in a place by some
people and they sat in a room together and
0:54:06 they had one computer and they would write
programs and show them to each other.
0:54:08 And someone wrote spell, you know,
and, and someone wrote like, they
0:54:12 wrote these different little Unix
programs and said, Hey, check it out.
0:54:15 And then, some people, made the
pipe operator and made piping work.
0:54:18 And they started to be able
to connect these programs
0:54:20 together to be able to make.
0:54:21 You know, quite complex programs just as
a series of small programs pipe together.
0:54:25 This is a really beautiful
primitive, and it's a beautiful
0:54:28 thing that, someone created.
0:54:29 And we have it on all
of our modern terminals.
0:54:32 I think there's even a version on Windows,
but all Unixes have something like this.
0:54:35 I feel like at some point we gave
up trying to invent new kinds of
0:54:38 primitives like that, and I dunno
why, but it feels like the sort of
0:54:41 thing that we should be able to do.
0:54:43 Obviously, you know, I sometimes
think about, we've been
0:54:46 talking about the web a bit.
0:54:47 And, we have this beautiful idea,
which is, so we've got these
0:54:50 two different ideas right now.
0:54:52 We've got a desktop application, and
desktop applications have access to
0:54:55 everything that the user has access
to by default, which is interesting.
0:54:57 And Apple's trying to change this,
but keeps getting in trouble for it.
0:55:00 desktop applications are binaries.
0:55:02 They're always native
binaries on every platform.
0:55:04 And they have access to some
set of native, APIs and they
0:55:07 can make sys calls directly.
0:55:08 And then we have another set of
applications called web applications,
0:55:11 which is sandboxed by a browser and,
you know, historically only written
0:55:14 in JavaScript and written in a way
that they can operate on every, every
0:55:17 computer, but only inside the web browser.
0:55:19 And like.
0:55:20 Web applications are really successful, I
think, not because of the web browser, but
0:55:24 because you don't have to install them.
0:55:26 And people sort of forget this, but
they're kind of equivalent, except
0:55:29 this one you have to install for
some reason, and this one you don't.
0:55:32 And because you don't have to install
a web app, people spend a lot of
0:55:34 time optimizing them for size.
0:55:36 So you load up the New York Times and
it'll load a lot of Crap, probably,
0:55:40 but we're looking on the order of
maybe half a meg of JavaScript.
0:55:42 Maybe it's a couple megs of
JavaScript and some images.
0:55:45 Um, whereas if I install, you know,
I haven't actually tried this.
0:55:47 I'm going to get in trouble by
somebody who will actually go and
0:55:49 look, but you look at most iPhone
apps, for example, and they, there
0:55:53 are hundreds of megabytes in size.
0:55:54 I think the Uber app is like
300 megs or something crazy.
0:55:57 Like the Facebook app is huge
and it doesn't even have content.
0:56:00 Like it's not even like
the Uber app is loading.
0:56:02 It's like installing databases.
0:56:04 Who even knows what's in there?
0:56:06 But then web applications are written
in slow languages and I just feel like
0:56:09 it's like well, we could just make
a new platform and we could give it
0:56:13 a new kind of application where you
don't have to install it, but also it
0:56:15 gets access to some set of beautiful
native primitives that might be even
0:56:19 better than what the web provides
today for applications themselves.
0:56:22 Like the web obviously is
designed as a document.
0:56:25 Viewing platform and then we've could
have hacked on applications because it
0:56:28 was so convenient, and we could make
it so that data is just transparently
0:56:32 available and accessible between programs
beautifully using all of the tools and
0:56:36 technologies we've been talking about.
0:56:38 but no one works on this stuff because
we sort of take for granted, it's
0:56:41 like, there's the ruins of old Rome,
you know, and that's, that's like Unix
0:56:44 or it's the, you know, the machine
code and x86 assembly and then modern,
0:56:48 you know, people say, oh, well, Then
they build the web browser and then we
0:56:51 build on top of the web browser react.
0:56:53 And then you build an application on top
of react, but then the application slows.
0:56:56 So you do some other wacky
thing on top of that.
0:56:58 And it's like, you know, underneath the
city is this giant, you know, all of
0:57:02 these ruins that are all full of code
and all being used by modern programs.
0:57:06 But that so many people, particularly
young engineers, they have no
0:57:09 idea about all of this crap.
0:57:10 They just know that if they type the
right thing into a react application,
0:57:13 that they'll get something on the screen.
0:57:15 But all of that stuff, we can actually
like, you know, burn it all if we want
0:57:19 to, and then go and make beautiful things
right from the very base of computers.
0:57:23 Yeah.
0:57:24 I mean, I think there's this sort of
like innovators dilemma and I think this,
0:57:29 you mentioning email as an example, I
think this is one of the words, since
0:57:33 you, you just emails and browsers,
like you, you just cannot get away
0:57:38 with like not supporting the old stuff.
0:57:40 And this is where, If you build a
brand new thing, you don't have to,
0:57:45 account for all of like the historic
mess, and you can just start over.
0:57:49 And, I think this is probably just having
the, the courage or naivety to start over.
0:57:58 I think that that's highly underrated.
0:58:00 and also for the record, I've just
checked, blank loading New York times.
0:58:04 It's like currently five megabytes of
just javaScript and, depending on, well,
0:58:09 and 20 megs, of like other stuff that
I've loaded, like with images and so on.
0:58:14 So, I think that this just proves the
point, like even for New York times,
0:58:18 like five megs of JavaScript, it's fine.
0:58:21 I don't want to know how much of
that is like ads related, et cetera,
0:58:25 but, I just want to encourage
people to rethink their, like their
0:58:30 learned, thinking about trade offs.
0:58:33 Like we're, it's at the same time,
we're kind of indoctrinated with like,
0:58:37 okay, we need to make the initial
page load as quick as possible.
0:58:42 We always have connectivity.
0:58:44 I'd like to alter that slightly
and say like, when we're connected.
0:58:49 We probably have pretty good connectivity.
0:58:51 So let's embrace that, but we're,
not going to be always connected
0:58:55 for the moments where we don't
have perfect connectivity.
0:58:58 Let's, like piggyback on the times
when we had good connectivity and we
0:59:04 should just sync the deltas instead of
like reloading everything every time.
0:59:08 Also goes back to the build problem, the
build system problem that we had before.
0:59:14 Since we don't build things in a
principled enough way, so we don't
0:59:17 trust the stuff that was there before,
and so that leads to us reloading
0:59:22 everything from scratch all the time.
0:59:24 And, I think that's another big
culprit of, systems problems.
0:59:29 I read a great article a while ago,
comparing the size of JavaScript bundles
0:59:33 with War and Peace, saying like, you know,
could you, how many copies of War and
0:59:38 Peace could fit in your JavaScript bundle?
0:59:40 and it's quite a lot.
0:59:41 and the other thing I sometimes
think about is, how many bytes of
0:59:44 data would it take if you took a
screenshot of your website, even as a
0:59:48 PNG, and then sent me the screenshot,
would that be larger or smaller
0:59:52 than it takes to load your website?
0:59:54 And if the answer is that your
screenshot would be smaller than all
0:59:56 of the code that you send me, then
maybe you're doing something wrong.
0:59:59 but even then, like, yeah, I really
encourage people to also think
1:00:03 about from the perspective of,
the web browser, it's all code.
1:00:07 You know, if you, if you start digging,
it's code a really long way down.
1:00:11 And all of that code can be changed.
1:00:13 Like web browsers are open source.
1:00:14 I've got some quite famously,
infamously, I've got some source
1:00:17 code, in Google Chrome, to be able to
interact with Xbox game controllers.
1:00:20 I'm not sure if it's still
there, but, I wrote, a user land,
1:00:25 USB driver for Google Chrome.
1:00:28 so that if you're on Mac OS in
particular, so if you plug in an Xbox
1:00:30 game controller to a Mac computer and you
want to play video games, in browsers,
1:00:36 then the Xbox controller will work.
1:00:38 But there's so much stuff like that, that
like, you know, and I think that's almost
1:00:40 crazy that that, that is in Google Chrome.
1:00:43 it should be the operating system,
but there's lots of perimeters
1:00:45 that we could put in Google Chrome.
1:00:47 That would mean that, you know, if
there's some, if there are things
1:00:49 that we want to be able to have
access to as web developers, We can
1:00:52 build them in as primitives, and
everyone can get access to them.
1:00:54 Like, a lot of the standards committees,
you can just go to them, it turns out.
1:00:57 You know, like, there's open mailing
lists of the people that build
1:01:00 all of this stuff, and they're
just nerds like us, you know?
1:01:02 Like, they've just got all of
their own crotchety, angry opinions
1:01:05 that they'll tell you about if
you give them half a chance.
1:01:07 but, I don't know.
1:01:08 I feel like there's not enough
conversation around all this
1:01:11 stuff, how it could be better.
1:01:12 Going back slightly to the moment where
you reflected on that kind of the creation
1:01:19 of primitives, what I found, at least
looking back at my own creative work,
1:01:25 what I found easier to than just forcing a
primitive into existing out of thin air is
1:01:32 rather embrace sort of like organic chaos,
and then study it really hard and then
1:01:39 see basically out of the existing mess.
1:01:43 typically if you look hard enough,
if you observe hard enough, you
1:01:46 can, observe some things that
later can emerge as primitives.
1:01:53 And, this is where almost
paradoxically the more requirements
1:01:57 I apply on a certain system.
1:02:01 The more it becomes
like simpler over time.
1:02:05 And so I've basically just taken more
kind of like inner peace by like, not
1:02:10 knowing the primitives upfront right away.
1:02:13 I'm basically just trying
to solve the problem.
1:02:15 Like I happily say yes to a few
problems and I've had enough, past
1:02:22 experience where out of that mess.
1:02:24 through lucky coincidences, I realized,
okay, here's some useful, more general
1:02:30 primitives and in hindsight, those
primitives look very obvious and
1:02:34 someone who then looks at that system
and maybe builds a similar one, they
1:02:39 can already embrace those primitive
ideas and, build on top of them, the
1:02:44 beginning, but I think for novel, new
primitives, I think the most likely path
1:02:51 for them to come into existence is out
of emergence and not out of like forcing
1:02:56 them into existence out of thin air.
1:02:58 I agree with everything and I'm a
little bit dubious on that last point.
1:03:03 And just to push back a little
bit, I think that it's got to
1:03:05 be this push and pull, you know,
like they're both so important.
1:03:10 I really like what you said though.
1:03:11 Again, Rich Hickey, who, You
should watch all of his talks.
1:03:15 Anyone who's listening to this, he's
much more insightful than I will ever
1:03:18 be, I think, but he gave a talk once and
he said, he talked about hammock driven
1:03:22 development as in software development
driven by writing some code and then
1:03:27 going outside and lying in a hammock
and thinking really hard about it.
1:03:30 And just, just letting it percolate,
like letting the design that you've
1:03:34 come up with percolate and say, how does
this problem actually really want to be
1:03:37 solved if I were to do a good job at it?
1:03:39 and instead of sort of half arsing a
million things and having everyone across
1:03:43 the industry half arse the same set of
eight things, you know, lists and so
1:03:46 on, I don't know, I can't help but think
that if, if a few people spend some time.
1:03:51 Some serious time thinking a lot about
lists, we could have some really nice
1:03:54 lists in web browsers and all these
different things and then it would
1:03:57 just be solved for everybody, you know,
1:03:58 maybe this is, this is why I've
prefaced it with like, that's being
1:04:02 for me, the easier path, like for me,
step one is half arsing something.
1:04:07 And then looking at it, but I need to
have it be laid out wrong first for me
1:04:12 to spot, oh, this is, this is how right.
1:04:15 Looks like some more brilliant people
than me can probably skip step one.
1:04:20 But for me, this one has
been a more proven approach.
1:04:24 I mean, it's the same for me.
1:04:25 I used to teach programming and
something, you know, my students would.
1:04:29 Sort of sometimes come to me asking me
how they should design their program
1:04:32 before they even start writing any code.
1:04:34 And I'm convinced that you know
the least about your program,
1:04:38 like you know the least about the
program before you start writing it.
1:04:40 That's the time that you will
know the least that you will
1:04:42 ever know about this problem.
1:04:44 So you're the least qualified you're
ever going to be to design it correctly.
1:04:47 You know, so you become qualified by
throwing something on the screen and
1:04:51 then taking the time to reflect on the
knowledge that you've gained to figure out
1:04:54 how it could be written in a better way.
1:04:56 it's, yeah, I absolutely agree.
1:04:59 And I think this is also this underscore
is like one of the most important things
1:05:04 that I hold dearly in the craft of
software engineering, which is the ease
1:05:08 of iteration and the speed of iteration.
1:05:11 And this is where I spend a obscene
amount of time on just like making
1:05:15 so that I have fun and iterating.
1:05:19 That it's very cheap for me
to get it wrong 10 times and
1:05:23 it's fun to do every iteration.
1:05:26 but if it's gruesome to do one
iteration, then you just, run
1:05:30 out of like joy and energy.
1:05:32 Until you get to the right point.
1:05:34 So making the iteration cycles, it's
like, it sounds very obvious, but I
1:05:38 think very few people actually put
in the work since it's also partially
1:05:42 some pretty annoying work, like getting
your, like your monorepo set up, all
1:05:47 dialed in, like particular, like which
JavaScript package manager should you use?
1:05:51 Like all of like those stupid things,
but getting all of that stuff dialed in,
1:05:55 I think that the reward is, quite big.
1:05:58 I mean.
1:05:59 I assume that you've read this, but,
again, to plug more things that people
1:06:02 should read if they haven't, there's
that beautiful essay of Worse is
1:06:05 Better, that talks about all of this.
1:06:07 And I feel like, yeah, I think that
life exists like in the intersection
1:06:11 of thinking it through and just
throwing something at the wall.
1:06:14 And I think all good software is going
to have elements of both of these things
1:06:17 where, you know, there's not too much
upfront design and upfront thinking,
1:06:21 but there's not too little of it either.
1:06:22 You know, like there's got to be some
amount of time, but after you've written
1:06:25 a whole lot of code, you take a step back
and you say, how should this have been?
1:06:28 If I knew everything I knew
now, how would I build it?
1:06:30 And I think everything beautiful
and everything incredible has
1:06:33 a lot of those feedback loops.
1:06:35 Like I listened to an amazing talk at,
GDC, the Game Developers Conference,
1:06:38 once talking about this, and he said
essentially all good games are made
1:06:41 by having some ideas, writing them
in code, trying them out, and then
1:06:45 throwing out 80 percent of them because
they weren't very good ideas, but 20
1:06:47 percent of them were really good ideas.
1:06:49 And he said in that talk that
the quality of any program that
1:06:52 you make is proportional to the
number of iteration cycles you get
1:06:55 through, not how long one cycle is.
1:06:57 The number of iteration cycles,
just the sheer amount of repetition
1:07:01 that you go through in writing code,
reflecting, changing the code, making
1:07:05 it better, writing more code and so on.
1:07:07 And I think it's, yeah, I
think it's a beautiful idea.
1:07:10 I've been doing improv comedy classes
lately and over the last few years and
1:07:14 in improv we learn it's, you can't plan.
1:07:17 There's no planning.
1:07:17 You don't have a meeting with
your, the people you share the
1:07:20 stage with before the show starts.
1:07:22 So everything is just asking
the question of what comes next?
1:07:25 Like, which I feel like
is this life philosophy.
1:07:27 Just at every moment, what comes next?
1:07:29 And maybe what comes next
is writing more code.
1:07:31 And maybe what comes next is
stepping away and thinking about
1:07:33 the code and refactoring it.
1:07:34 But, like, I feel like that's
the right question just to
1:07:37 hold, you know, consciously.
1:07:39 so you've given me two segues now to
ask you about another topic that I
1:07:43 think is very top of mind for you.
1:07:44 So one is sort of this almost evolution,
like, nature evolution of software
1:07:50 and good products, et cetera, where
it's all about the iteration cycles.
1:07:53 That's like how biology works.
1:07:55 So this is why we as humans exist, et
cetera, and why other good things exist.
1:08:00 and then also asking the
question, what is next?
1:08:03 That is, that's the essence
of how an LLM works.
1:08:07 So I think you've been thinking
a lot about, the topic of AI and
1:08:11 what that means for our culture of
programmers and software creatives.
1:08:17 So I'm, I'm curious, what are some
of the leading questions for you
1:08:22 are when you're rethinking and
like digging into the topic of AI?
1:08:27 AI
1:08:27 I've told the story of me working on
Google Wave and I started there in
1:08:30 about 2010, but I've been thinking
about AI a lot since about 2002.
1:08:35 I think since I first
around when I started uni.
1:08:37 I've got somewhere a pile of
notebooks full of handwritten notes,
1:08:40 thinking through lots of different
ideas and ways to build AI systems.
1:08:44 and I started a PhD And I ended up leaving
and I felt disappointed and I attacked
1:08:49 myself because I couldn't get the things
that I wanted to get working, working.
1:08:52 And instead of just chipping away
at it, like I wish I had done in
1:08:55 retrospect, I felt a whole lot of
shame and guilt and then walked away
1:08:58 from the whole industry and haven't
really come back or it's been a while.
1:09:02 you know, I haven't come back in a
big way, for, you know, 20, 23 years
1:09:06 or something now, which is crazy.
1:09:08 more than half of my life, you
know, running away from this dream
1:09:10 that I had, but way back when I.
Like, it's really interesting.
1:09:15 We're in this transition period
at the moment where AI is a
1:09:18 similar intelligence to humans.
1:09:20 but something I think about a lot with
this kind of software is, like I mentioned
1:09:24 before that when I was young, I thought
that one human should be able to, as our
1:09:28 tools, let us become more productive.
1:09:29 One person should be able to do the
work of a whole team from a decade ago.
1:09:33 And increasingly with AI think that's
actually going to become the case.
1:09:36 And I don't really know what that's
going to, how it's going to change.
1:09:40 A lot of things, but I can imagine as
we go forward that if we had better
1:09:43 primitives and had primitives that the
AIs understood, that a lot of these kind
1:09:47 of problems that actually just require
a whole lot of code, for example, like
1:09:50 building a really good UX, like a UI
toolkit that would be cross platform, it's
1:09:53 possible that we could start to build AI
systems that could actually design good
1:09:57 primitive tools, for computer systems
and, I don't know what that means for us.
1:10:01 Like, I don't have any recommendations
or advice or anything else, but it's
1:10:04 really interesting to start thinking
about it as, you know, if, if your
1:10:07 productivity isn't limited by what you
can personally code anymore, which is,
1:10:11 I think, going to increasingly be the
case, then what do you want to build?
1:10:15 And how can we start building, you
know, like, utilizing AI tools that
1:10:18 will increasingly, and obviously they're
not quite yet, there yet, build large
1:10:21 swathes of working in usable software.,
I feel like this is just really open
1:10:26 question of what does it even mean
to be a software developer, but also.
1:10:30 What could we do again, right, like that
we can't do today because it would take
1:10:33 the resources of Google to be able to
build something that we might be able
1:10:37 to do, you know, like if you wanted
to build your own operating system
1:10:39 and your own browser from scratch,
you could just ask an AI to do it.
1:10:42 How do we do that?
1:10:43 have you been able to derive sort of
like a set of, invariants almost that
1:10:50 are still going to be true, in the age
where, AI will be a meaningful part
1:10:56 of how software is created, et cetera.
1:10:59 Like, which aspects do you think
are still meaningful for humans
1:11:04 to play a, meaningful role there?
1:11:07 I mean, it's a great question.
1:11:08 I feel like there's this massive economic,
you know, loom thing that looms over
1:11:12 all of us of, If you can't use your
mind to do things that an AI couldn't
1:11:15 do, then why would you ever be hired?
1:11:18 why would any human be hired for any job?
1:11:20 And, there's a threshold
that we need to pass.
1:11:23 You know, obviously with computers and
AI systems, we can become more productive
1:11:26 than we ever are today and produce more
abundance and more resources and more
1:11:30 useful programs and everything else.
1:11:32 But if none of the humans are
employed to do any of that, then
1:11:34 we've got a huge economic problem.
1:11:36 but The beautiful world on the other
side of that, if we can possibly reach
1:11:39 it, I think has to look like humans
actually building the software and
1:11:43 building like being able to be creative
in all of the ways that we're born to be.
1:11:47 I think that there's some element that's
honestly our birthright in creative
1:11:51 beings, being able to make stuff, you
know, it feels so, so core to who we are.
1:11:55 And the more that I get in touch
with myself, the more I just want to.
1:11:58 Build and play piano and write
stories and do this kind of stuff.
1:12:03 So
1:12:03 play as sort of like the most
natural state of, who we are.
1:12:08 Yeah, I did, again, this is a
segue, that I'll, I'll try not
1:12:12 to drag us too, too far down.
1:12:13 I went to France a year and a half ago
and, and attended a clowning intensive.
1:12:18 So physical comedy and
performance for a month.
1:12:21 And it was horrific.
1:12:22 The, it was quite abusive in its own way.
1:12:25 The guy who's was teaching it has
been teaching clowning for 40 years.
1:12:28 And, anyway, it was an
incredible experience.
1:12:30 But, he said, you know, he's
this like grizzled old Frenchman.
1:12:33 And he said that he thinks And he's
trained Sacha Baron Cohen and all
1:12:37 these different people, but he thinks
that the most beautiful thing that
1:12:40 exists in the world is watching a
child play and, you know, so much
1:12:43 of clowning and physical comedy.
1:12:45 And I think creativity in general
is rediscovering as adults, if we
1:12:49 need to, that spark that's inside
all of us and that just wants to
1:12:52 build things and wants to play and
wants to try stuff out and so on.
1:12:56 And I don't know, that's my, that's
my hope for AI at least is that.
1:13:00 If you were to play, if you wanted
to make your own sandbox, you know,
1:13:03 grow a garden, a software, whatever
metaphor you want to think about it
1:13:06 as, then what do you want to make?
1:13:08 What, what are you called on to make?
1:13:10 You know, I live in a apartment
building that overlooks a lot of the
1:13:13 city and, there's this idea of Dharma
that's talked about in, in Smithsonian
1:13:18 philosophy, which is like, what is
the duty that's your sacred duty?
1:13:22 That's yours alone to reach.
1:13:23 And that duty, by the way, might just
be to like, be a really great parent.
1:13:26 It doesn't have to be anything
grand or grandiose in any way,
1:13:29 but asking that question of what
is it yours to do in the world?
1:13:32 That's yours uniquely that no one
else will do if you don't do it.
1:13:35 I think that's really the
question that we want to be asking
1:13:37 ourselves as creative workers.
1:13:38 and from that perspective, I'm excited
about AI because hoping I mean,
1:13:42 I'm really hoping that it lets us
answer the questions like that more.
1:13:45 And you know, like I don't think
economically we need local-first
1:13:48 software, you know, like we can
trudge along with the feudalism
1:13:51 of Google cloud services for, you
know, probably for a very long time.
1:13:55 but I don't want that.
1:13:56 I want beautiful software programs that
work in harmony with who I am as a person
1:14:00 and with in harmony with what kind of
communities I want to be able to foster.
1:14:04 And from that perspective, I think
that's like why I care about local-first
1:14:07 software and why I hope that more people
care about it because I just think that.
1:14:11 We deserve, I don't know, we can just
have nice things, you know, like the cloud
1:14:15 always feels like, feudal city states,
you know, so back before we had democracy.
1:14:19 And before we had countries,
you have these towns and the
1:14:22 town, it's not a democracy.
1:14:24 There's one ruler, the
noble, the local noble.
1:14:26 And if you upset the noble,
there's no laws necessarily.
1:14:28 That's a, recent invention, that
the noble would say, no, not you.
1:14:32 And you'd be either be exiled
if you're lucky or like, you
1:14:34 know, hung from the town square.
1:14:36 If you did something, the noble
didn't like, and no one owns property.
1:14:39 Only the noble owns the whole town.
1:14:40 That's the rule, right?
1:14:42 And so if you have a house, you
have a house because the noble has
1:14:46 graciously allowed you to live there.
1:14:48 And that's the rule, you know,
and if the noble wants to.
1:14:50 Do whatever they want to do.
1:14:52 There's no higher law than the noble,
and that feels like the software
1:14:55 ecosystem that we exist in today, where,
you know, there's the Google city.
1:14:59 And as much as I have endless respect
for so many individuals that I know
1:15:02 who I've worked with at Google.
1:15:03 I think they're amazing people.
1:15:05 The experience is Google
is a feudal city state.
1:15:08 Where you walk into the gates and
if the noble, with the local Lord
1:15:11 doesn't like you, then you can get
banished at any moment out of Google.
1:15:14 There's no recourse.
1:15:15 There's no laws.
1:15:16 There's no rules.
1:15:17 It's not a democracy.
1:15:18 you don't have any privacy.
1:15:19 Everything you do is monitored 24 seven by
the Google cameras that exist everywhere.
1:15:24 You know, and they're nice little
plastic, you know, beautiful designed.
1:15:27 whatever.
1:15:28 And if you don't like it, you can go
down the street to the Apple town where
1:15:31 everything is run by Apple and Apple has
slightly different values from Google.
1:15:35 And I happen to like Apple's philosophy
on privacy more than Google's,
1:15:38 but it's the same kind of world.
1:15:39 And I personally believe in democracy
and I like that my streets aren't owned
1:15:44 by a company, call me crazy, but yeah.
1:15:47 And I don't know how it interacts with AI,
but I feel like we've got, I don't know.
1:15:50 It's like, we've got this opportunity
to being more creative, to make
1:15:54 more stuff, to not need billions
of dollars of funding, and it's up
1:15:57 to us what we want to do with that.
1:15:59 And maybe it's a stretch and maybe I'm
putting words in your mouth here, but, at
1:16:03 least you've used the word democracy, and,
maybe that is also like something that
1:16:09 people see in local-first that is almost
a more democratic approach to software.
1:16:15 Yeah, I really agree.
1:16:16 it's like, I care about local-first
software the most for creative work,
1:16:20 for like, if I'm composing a song.
1:16:23 It's my song.
1:16:24 It's mine.
1:16:24 You know, it's not Google's or whichever
cloud service I want to host that.
1:16:28 It's not theirs.
1:16:29 I don't want them to be able to
look in it or change it or monetize
1:16:33 it or sell it on or anything else.
1:16:35 It's my work.
1:16:36 And if I want to work with you.
1:16:38 On making that song.
1:16:39 It should exist on both of our computers
and be transmitted between our computers.
1:16:44 It's ours, you know, like there's some, I
don't know, it feels like some principle.
1:16:48 It just feels so obvious.
1:16:49 And I don't know how I
could possibly justify it.
1:16:51 It feels axiomatic.
1:16:52 I think a lot of people don't realize just
how much, you know, Art and I feel like
1:16:55 I'm probably preaching to the converted
with, you know, with a crowd listening
1:16:58 to this podcast, but we forget how much
our computering experience is moderated
1:17:02 by big corporations, like big companies.
1:17:05 And I think that's really sad
because our computers are amazing.
1:17:08 You know, like the computer sitting at
your desk, like, I often think about this,
1:17:12 that computers are like, like two to five
gigahertz, two to five billion things
1:17:17 every second, like, wow, you know, like,
that's a lot of, that's a lot of steps.
1:17:21 And you can make those steps do anything
you want, like you can write any
1:17:23 program, totally free in that regard.
1:17:26 So we could make programs that.
1:17:28 To do whatever service, whatever
needs we want that we'll be able
1:17:31 to, you know, we've got all the
technology, we've got CRDTs, and we've
1:17:34 got access to low level networking
primitives and all of this stuff.
1:17:38 but I really want good software.
1:17:40 so that if I want to, like, I don't know,
I want to make a diagram for a paper
1:17:44 that I've got good tools to do that with.
1:17:45 And I want to just whatever it is, I've
got a bunch of photos and I want to share,
1:17:49 I've been getting into photography lately.
1:17:50 I want to share my photos with my friends.
1:17:52 I want to be able to just have
software that lets me do that easily.
1:17:54 you know, like I really want to have.
1:17:56 collaborative software.
1:17:56 I want to be able to run a DND campaign
on a, on a Wave or something that's
1:17:59 Wave like where it's not like owned by
Google's computers and we have to all
1:18:04 agree to Google's terms of service to be
able to continue having access to that.
1:18:07 It should just be something
that we can all access.
1:18:09 And if I want to write some new
custom software to help me run my
1:18:12 DND campaign, I want to be able to do
that too and have it interact with the
1:18:15 same data model as everything else.
1:18:17 So yeah, I fully agree and I think often
people who are not as comfortable yet
1:18:24 in the local-first bubble as, as we are,
I think a lot of people kind of think
1:18:28 like, okay, why does local-first matter?
1:18:31 Maybe if, there's sort of the, this
dystopian future where I can't trust
1:18:36 the government, I can't trust the
clouds, I'm like a persecuted minority,
1:18:41 whatever it is, like, but it has people
only assume local-first to be like
1:18:48 meaningful, when you're kind of, when
a dystopian future has already arrived.
1:18:53 And I think you don't, sure, local-first
is very meaningful in that part, but
1:18:57 that's not what I'm like a I'm optimist.
1:19:01 So I don't, anticipate a dystopian future.
1:19:04 And so I'm not a prepper, et cetera.
1:19:07 I'm not a local 1st prepper.
1:19:08 I'm a local 1st player.
1:19:10 Like, I want to have more of, like, the
local for the playful state of mind.
1:19:15 Like, I. I'm so fortunate and privileged
that I get to do what I love and,
1:19:22 still, like, make a living from it.
1:19:24 And, like, my ideal day that I, like,
that I live each day is, like, that I had
1:19:28 a, like, a day full of play, basically.
1:19:32 And for me, play here means, like,
discovering things, like, losing sleep
1:19:37 over a hard problem, but then getting the
joy out of solving that and having sort
1:19:42 of my own agency over what I'm doing.
1:19:45 And, I think even like when a child
plays, like a child is not told, like
1:19:51 now you have to build this thing, but
it's their own agency to do what they
1:19:56 feel like and pursue their own goals.
1:19:59 And I think local-first can.
1:20:01 And able that in a similar way,
how the web has lowered the bar
1:20:06 so much and therefore increase
the agencies of individuals.
1:20:10 Like, and I think the same thing is
happening right now with like AI assist
1:20:14 tools, where the barrier comes down even
more for non programmers to build things.
1:20:20 It gives them agency, gives them ways to.
1:20:23 Playfully build things and I have
the same hope for local-first
1:20:27 that it brings down one of the big
barriers, which is data management.
1:20:32 And I'm very excited about that.
1:20:34 Yeah.
1:20:34 Me too.
1:20:35 Yeah.
1:20:35 I feel like there's a bunch of ways that
we could be building better software.
1:20:38 And, I just want all my programs to
interoperate, you know, If I'm editing
1:20:43 a text document, I want to be able to
be typing something in a text editing
1:20:46 environment on my laptop and then, you
know, I run out the door and I'm on a
1:20:50 train and I just opened up my phone and I
can keep on editing it and I want all of
1:20:54 my software to work like that and I want
there to be And it's like on, on Unix,
1:20:59 we have this sort of open file system.
1:21:00 There's any program can interact with
the file system and edit files, which
1:21:03 is great except that the file system
makes it really hard for two programs
1:21:06 to edit a file at the same time and have
anything meaningful come out at all.
1:21:10 So most programs don't really interact
with each other around the data unless
1:21:14 one program sort of saves something
and another program opens it up later
1:21:17 and then you do something in that
program and save something else out
1:21:20 and it has something else open it.
1:21:21 But with local-first software, I want.
1:21:23 Sort of like an ecosystem of all the
programs on my computer to be interacting.
1:21:27 And then I also want to be able
to have programs on my computer
1:21:30 and your computer interacting.
1:21:32 I feel like that should
just be really easy to do.
1:21:34 Like it It's something that should be
out of the box, and if every programmer
1:21:37 needs to re implement it and reinvent
it from scratch, it's never going
1:21:40 to happen, but it's something that
could just be built into the system.
1:21:43 I like this way of thinking about it,
since my primary goal for local-first
1:21:48 right now is, like, step one is make
it super, super easy, bring down the
1:21:54 barrier to build something meaningful.
1:21:56 For myself or a small group of people
at all, but then step two, even
1:22:02 wider vision is like, okay, let's
bring together those experiences
1:22:06 and bring them together in a way.
1:22:08 That's not just sort of like a, a
best effort kind of thing where like,
1:22:12 oh, yeah, export JSON over here.
1:22:14 import over there.
1:22:16 And like, now it's like, you only
have people's last names or something,
1:22:20 but at least there's some existence.
1:22:22 But I think this is almost like a
second chapter that will probably take
1:22:27 a lot of effort and we need the solid
foundations first, but the, yeah, the
1:22:31 prize of local-first can, ultimately
lead to data interop in the same ways.
1:22:36 Like our brain doesn't work in silos,
but our brain, like when the conversation
1:22:41 I'm having with you, I'm taking some
ideas away from that and maybe bring
1:22:46 them to another conversation I have.
1:22:48 So my brain is already that big data bus.
1:22:52 And that is a promise that
local-first can fulfill.
1:22:55 Yeah, I absolutely agree.
1:22:57 And so I feel like there's that piece.
1:22:58 And then the other piece is, there's
things that we have as software
1:23:01 engineers that everyone should have.
1:23:03 my girlfriend works, she uses
a, there's a content management
1:23:06 system that she uses at her work.
1:23:07 And I have access to, because I'm
a software engineer, I use Git.
1:23:11 And with Git, I can have branches, and
I can have pull requests, and I can see
1:23:15 all the changes and history of changes.
1:23:17 we've built those tools for ourselves,
and then we haven't built them for
1:23:19 anyone else in any other industry.
1:23:21 And that, to me, is totally crazy.
1:23:23 It's like no one else, you know,
like, we've kind of been really
1:23:25 selfish as software engineers.
1:23:27 It's
1:23:27 that's rule in the real world.
1:23:30 Yeah, exactly.
1:23:31 Exactly.
1:23:31 Right.
1:23:31 Yeah, but with local-first software,
I, you know, like with these, these
1:23:36 primitives with these different ways
of approaching software, I feel like
1:23:39 we can make a set of, primitives that
should allow any program to do that.
1:23:43 Like it's, I'm really happy with
the Ink and Switch guys and the work
1:23:46 that they're doing, guys and gals.
1:23:47 but there's also, like, I feel like
that should just be the standard set of
1:23:50 primitives for most things I do, you know?
1:23:52 I want to be able to open up
Photoshop and be editing a document
1:23:55 and have some commit type thing.
1:23:57 And if you're using a different
image editing program, I should be
1:24:00 able to share it with you and you
can just open up the document too.
1:24:03 And then if, I want to write some
script that's going to interactively
1:24:06 make changes to the document that I'm
editing, like the image I'm editing,
1:24:10 I should be able to have a, like a
little program that just interacts with
1:24:13 the same data model that both of these
programs we're using can interact with.
1:24:16 And it, it should let us, you know,
and then also have the change history
1:24:20 and we can look through the history
of changes and see who did what.
1:24:22 And we can have pull requests
on a video editing session.
1:24:25 If we're editing a video together,
I want to be able to have a
1:24:28 pull request on a different way
that the edit comes together.
1:24:31 Like all of those kinds of things
should just be built into the primitives
1:24:34 of the software that we write.
1:24:35 and the software that we use.
1:24:36 And, you know, like I was talking
to someone recently who was saying,
1:24:40 he was like, Oh, I don't know how to
explain it to the programmers that
1:24:42 the people want all of these things.
1:24:44 And I said, I was like, Oh, well
tell them, imagine if you didn't
1:24:47 get to use Git and you went back
to the world where it was like, you
1:24:50 know, blah, final, final to final.
1:24:52 No, actually the real final version.
1:24:54 This is actually the world that most
people who aren't software engineers.
1:24:57 live in with most of the
programs that they use today.
1:25:00 you know, in the best case, they've got,
they've got something like Google Docs
1:25:02 that, you know, makes a little bait and
switch where they have exactly the change
1:25:06 control that Google allows you to have.
1:25:08 And by the way, last I checked, Google's
API for Docs doesn't actually give
1:25:11 you the change history of a document.
1:25:12 So, you know, once Google's got that
change history, it's locked away in their
1:25:16 servers and you can't do anything with
it or interact with it or even download
1:25:19 it for yourself, which is a real pity.
1:25:21 but we can just have programs and
files living on our hard drives
1:25:25 and edit them and edit them with
other people and see the change
1:25:28 history and do whatever we want to.
1:25:29 And I want everyone to have that capacity.
1:25:31 So, yeah, like it's obvious, right?
1:25:33 yeah, that's another great way to,
to kind of think about the future.
1:25:38 Like, what have we as programmers
figured out and how can we bring it?
1:25:42 How can, how can we reduce the
distance of Seph's rule here?
1:25:46 And, how can we bring a lot of those
things that for us are obvious?
1:25:51 into other programs, but I think that
the reality is, it's not that some
1:25:56 product manager hasn't thought of it.
1:25:58 product managers have like, it's almost
like the peak of the iceberg meme.
1:26:03 only the stuff that's floating above
the sea level, that is the stuff that
1:26:08 was actually important enough and viable
enough to build the stuff underneath
1:26:13 it's not built yet, it was thought
of, but it was just too hard and not
1:26:17 meaningfully important enough to ship.
1:26:20 And I think local-first can
bring down the cost of that.
1:26:23 Yeah, I couldn't agree more, and it's
not just, too hard, it's even if they
1:26:27 do it, they've done it just for their
application, you know, and so every
1:26:30 application ends up with its own bespoke
way to do change editing and change
1:26:34 histories and everything else, and then
none of them are collaborative, not
1:26:36 like none of them are interoperable,
like what we really need is we need
1:26:39 something like the file system where
every program that exists can interact
1:26:43 with some standard set of primitives.
1:26:45 And then every program can take for
granted that the file system exists
1:26:48 and it sits underneath the program.
1:26:50 And then, if you have something like
that, not only is it really easy for,
1:26:53 you know, product managers to build these
features into their applications, which
1:26:56 I promise you, I agree with you, I've
talked to a lot of them, they'd love it.
1:26:59 They really want collaborative editing.
1:27:00 You know, everyone wants this.
1:27:02 so not only could they do it easily,
but then all of the collaborative
1:27:04 editing tools can all work together.
1:27:07 You know, they can all interoperate,
which would just be so obviously great.
1:27:12 It's some people will like Vim
and some people like Emacs and
1:27:14 some people like something else.
1:27:16 And, you know, why not have our
documents able to be edited in
1:27:20 Outro
1:27:20 Yeah.
1:27:21 So I'm so grateful that we got
to explore all of those ideas
1:27:26 that are clearly on your mind.
1:27:28 And I'm, Also so grateful for everyone
who's making that a reality particular
1:27:33 shout out goes there to to Ink and
Switch anyone who's really like defying
1:27:37 the strategy of the commons for like
for software and I just want to see
1:27:43 more of that and I think a big step
of that is like to like step one is
1:27:47 inspire people like open people's
eyes of like, oh, we can do better.
1:27:52 and yeah, so with that, I just
want to thank you so much for your
1:27:57 time, like, sharing all that we've
already, when quite extensive on this
1:28:01 conversation, I feel like there is.
1:28:03 A lot of stuff that we should probably
explore in a follow up conversation.
1:28:08 And we've already foreshadowed quite a bit
of like what the folks at Ink and Switch
1:28:12 are brewing with Patchwork, et cetera.
1:28:14 So I'm really looking forward to
learning more about that as well.
1:28:18 but, yeah, maybe the audience, if
they want to see you, in person, we're
1:28:23 also planning the next local-first
conference where, if everything works
1:28:28 out, you might be a speaker as well.
1:28:30 So, happily invite everyone to come
to Berlin at the end of May, for
1:28:35 the conference and, to get a chance
to talk to you in person as well.
1:28:39 I think that would be marvelous.
1:28:40 And I really want to echo that.
1:28:42 Thank you for all of the people
that are doing the hard work.
1:28:44 I feel like this is something
that's complicated enough.
1:28:47 We can't do it alone.
1:28:48 And.
1:28:48 You know, one of the beautiful
things about software that is, lets
1:28:51 you do collaborative editing is
We can collaborate on all of that.
1:28:55 Exactly.
1:28:55 And it's even like a virtual
cycle where people working on that
1:28:59 makes it easier to collaborate.
1:29:01 So yeah, that's a very optimistic
and hopeful vision for the future
1:29:05 with many challenges ahead.
1:29:07 But yeah, I want to
end on a positive note.
1:29:10 Seph, thank you so much for
like, yeah, sharing all of your
1:29:14 wisdom and thoughts with us here.
1:29:17 Thank you.
1:29:18 Thank you for inviting me.
1:29:19 this is lovely and I hope we have a
chance to chat more in the future.
1:29:23 Thank you for listening to
the localfirst.fm podcast.
1:29:26 If you've enjoyed this episode and
haven't done so already, please
1:29:28 Please subscribe and leave a review.
1:29:31 Please also share this episode
with your friends and colleagues.
1:29:33 Spreading the word about the
podcast is a great way to support
1:29:36 it and to help me keep it going.
1:29:39 A special thanks again to Convex and
ElectricSQL for supporting this podcast.