1
00:00:00,119 --> 00:00:04,253
The customers of Ditto are businesses
that have workers predominantly

2
00:00:04,253 --> 00:00:06,713
that are not at desks like us.

3
00:00:06,803 --> 00:00:08,813
They're out doing jobs in the real world.

4
00:00:09,188 --> 00:00:11,584
the internet is by no means guaranteed.

5
00:00:11,854 --> 00:00:17,824
And so being able to use smart
software that leverages the network

6
00:00:18,034 --> 00:00:22,579
capabilities of the devices that workers
are already holding is compelling.

7
00:00:22,609 --> 00:00:27,039
cause it kind of adds like another
layer of, durability, to ensure their,

8
00:00:27,083 --> 00:00:28,984
application, their data, keeps working.

9
00:00:29,387 --> 00:00:31,577
Welcome to the Localfirst.fm Podcast.

10
00:00:31,847 --> 00:00:34,787
I'm your host, Johannes Schickling,
and I'm a web developer, a

11
00:00:34,787 --> 00:00:37,937
startup founder, and love the
craft of software engineering.

12
00:00:38,477 --> 00:00:42,107
For the past few years, I've been on a
journey to build a modern high quality

13
00:00:42,107 --> 00:00:46,157
music app using web technologies, and
in doing so, I've been falling down the

14
00:00:46,157 --> 00:00:47,957
rabbit hole of local-first software.

15
00:00:48,587 --> 00:00:51,377
This podcast is your invitation
to join me on that journey.

16
00:00:52,337 --> 00:00:56,987
In this episode, I'm speaking to Adam
Fish, co-founder, and CEO of Ditto.

17
00:00:57,347 --> 00:01:01,217
An end-to-end syncing platform with
a focus on resilient connectivity.

18
00:01:01,877 --> 00:01:05,987
In this conversation, Adam shares
the origin story of Ditto, his prior

19
00:01:05,987 --> 00:01:10,337
related work on Realm and the hard
networking problems Ditto is solving.

20
00:01:11,057 --> 00:01:16,127
Before getting started also a big thank
you to Jazz for sponsoring this podcast.

21
00:01:16,277 --> 00:01:18,077
And now my interview with Adam.

22
00:01:18,687 --> 00:01:19,797
Hey, welcome Adam.

23
00:01:19,797 --> 00:01:20,457
How are you doing?

24
00:01:21,147 --> 00:01:21,627
Very good.

25
00:01:21,627 --> 00:01:22,527
Excited to be here.

26
00:01:22,617 --> 00:01:22,917
Thank you.

27
00:01:23,487 --> 00:01:25,497
I'm very excited to have you on the show.

28
00:01:25,762 --> 00:01:29,572
you and I have had a little chat
before the show and just recollecting

29
00:01:29,572 --> 00:01:33,202
our members since the two of us
had the pleasure to meet way back.

30
00:01:33,472 --> 00:01:36,712
I think this was at this point,
like probably more than 10 years

31
00:01:36,742 --> 00:01:39,082
ago when you've been still at Realm.

32
00:01:39,082 --> 00:01:42,562
And we're gonna hear more about
that, but it's so cool, like how,

33
00:01:42,622 --> 00:01:46,792
like in life our paths like overlap
when we're in the same space.

34
00:01:46,972 --> 00:01:49,072
So would you mind introducing yourself?

35
00:01:49,552 --> 00:01:49,972
Yeah.

36
00:01:50,002 --> 00:01:51,502
Well, I'm excited to be here.

37
00:01:51,502 --> 00:01:52,642
Thank you for having me.

38
00:01:52,672 --> 00:01:53,752
my name's Adam Fish.

39
00:01:53,752 --> 00:01:56,152
I'm the CEO co-founder of Ditto.

40
00:01:56,542 --> 00:02:00,472
And as you've mentioned, our paths
crossed, I, it had to have been about a

41
00:02:00,472 --> 00:02:05,296
decade ago in San Francisco, where I was
at Realm, previous to starting Ditto.

42
00:02:05,596 --> 00:02:09,320
And, at the time, were you
possibly starting Prisma or it

43
00:02:09,320 --> 00:02:10,131
was like, yeah, it was around,

44
00:02:10,355 --> 00:02:12,920
that was the predecessor
to Prisma at that point.

45
00:02:12,920 --> 00:02:13,130
Yeah.

46
00:02:14,135 --> 00:02:18,312
Yeah, so, Ditto itself is, you know,
a member in sort of the local-first

47
00:02:18,312 --> 00:02:21,119
effort, but maybe not as as well known.

48
00:02:21,526 --> 00:02:26,629
and so excited to share more about
my story and, about Ditto itself.

49
00:02:26,686 --> 00:02:32,296
In short, it's an edge sync platform,
and so we connect devices peer-to-peer

50
00:02:32,356 --> 00:02:36,939
and synchronize data, through a
database, in addition up to the cloud.

51
00:02:36,939 --> 00:02:41,609
And so this is, something that, I
think is very applicable to everyone

52
00:02:41,609 --> 00:02:43,409
who's really interested in local-first.

53
00:02:43,409 --> 00:02:47,069
And, you know, I have a long history
in this, like you'd mentioned at Realm

54
00:02:47,069 --> 00:02:51,239
before it, and so excited to kind of
share the story of how I got here.

55
00:02:51,686 --> 00:02:53,366
Yeah, let's actually start with that.

56
00:02:53,366 --> 00:02:57,926
And I think there was already a
stage before you joined Realm where

57
00:02:57,926 --> 00:03:00,146
you started poking at the space.

58
00:03:00,146 --> 00:03:05,052
So maybe we wanna start with that anecdote
that part of your professional journey.

59
00:03:05,542 --> 00:03:10,942
Yeah, so it's, I at this point, about a
15 year journey where I got my start as a

60
00:03:10,942 --> 00:03:15,382
developer coming out to San Francisco and
actually working on a different startup.

61
00:03:15,443 --> 00:03:17,709
kind of went through a
couple iterations of ideas.

62
00:03:17,772 --> 00:03:22,058
we were part of AngelPad, which was sort
of like a Y Combinator, initiative Back

63
00:03:22,058 --> 00:03:23,804
in the day, it's not around, anymore.

64
00:03:24,104 --> 00:03:28,984
And, through that iteration, we ended up
exiting the accelerator program focused on

65
00:03:28,984 --> 00:03:31,264
trying to build a mobile CRM application.

66
00:03:31,564 --> 00:03:36,964
And so this was 2010, 2011, 12
timeframe where mobile was still very

67
00:03:36,964 --> 00:03:40,108
nascent, even with consumer use cases.

68
00:03:40,113 --> 00:03:44,784
But on the enterprise side, it was still,
you know, no one had figured it out.

69
00:03:44,784 --> 00:03:47,184
And so we thought that was
a big opportunity with that.

70
00:03:47,491 --> 00:03:51,271
and looking at the CRM markets, we
thought, hey, that's a big market.

71
00:03:51,271 --> 00:03:52,411
We could go disrupt it.

72
00:03:52,921 --> 00:03:57,158
And so, we started building this
application and the first thing

73
00:03:57,158 --> 00:04:00,938
we really wanted to do was build
an incredible mobile experience.

74
00:04:01,178 --> 00:04:02,648
And so that naturally.

75
00:04:03,209 --> 00:04:06,119
forced us into thinking how
can we have local-first data?

76
00:04:06,449 --> 00:04:09,179
and so at first this was really
about like user experience,

77
00:04:09,179 --> 00:04:11,069
just like instantaneous clicks.

78
00:04:11,399 --> 00:04:15,329
But then we were like, okay, working
offline would make sense as well.

79
00:04:15,574 --> 00:04:18,893
and so we ended up building
a very naive sync engine.

80
00:04:19,006 --> 00:04:22,876
and this was fairly abstracted
because we were trying to plug

81
00:04:22,876 --> 00:04:25,006
into existing CRM systems.

82
00:04:25,006 --> 00:04:30,676
And so we would pull in your data from
Salesforce and then in a sort of like a

83
00:04:30,676 --> 00:04:36,166
server driven UI pattern, sync that down
to the device, and then it would render

84
00:04:36,526 --> 00:04:42,736
the UI based off of the specific data,
fields that you had in your CRM account.

85
00:04:43,186 --> 00:04:48,526
And so it was at the time, I would say
fairly innovative for what was a, you

86
00:04:48,526 --> 00:04:51,229
know, relatively narrow application.

87
00:04:51,709 --> 00:04:55,789
And so, that was sort of the
innovative technology behind the app.

88
00:04:55,789 --> 00:04:59,299
And when we launched it, it was
started getting meager success

89
00:04:59,299 --> 00:05:00,619
from a business standpoint.

90
00:05:00,949 --> 00:05:04,349
And, myself and my co-founder at
the time looked at each other and

91
00:05:04,349 --> 00:05:08,489
we were like, you know, how did
we end up building CRM software?

92
00:05:08,489 --> 00:05:12,659
Like, this is not something that I'm
like particularly passionate about.

93
00:05:12,796 --> 00:05:17,489
and yeah, it was just like we had sort
of like a, a moment, where we wanted to

94
00:05:17,489 --> 00:05:21,173
just like, take a look at ourselves in
our lives and say, is this really what we

95
00:05:21,173 --> 00:05:23,273
wanna spend our professional careers on?

96
00:05:23,693 --> 00:05:28,733
And so, for me in that moment of
reflection, I was like, I'm really not

97
00:05:28,733 --> 00:05:34,373
interested in CRM, but this infrastructure
that we built, that to me seems really

98
00:05:34,373 --> 00:05:39,218
interesting 'cause it solved the problem
I was experiencing as a mobile developer

99
00:05:39,278 --> 00:05:44,498
wanting data locally and being able
to create like great user experiences.

100
00:05:44,918 --> 00:05:49,968
And so ultimately I have like actually
a pitch deck that's like hilariously

101
00:05:49,968 --> 00:05:54,434
similar to stuff with Ditto from,
2013 timeframe where I was like,

102
00:05:54,434 --> 00:05:58,874
okay, I wanna pivot the company and
basically, at the time sort of build

103
00:05:58,874 --> 00:06:01,348
something similar to Pars, and Firebase.

104
00:06:01,394 --> 00:06:04,574
and, you know, let's just become
an infrastructure company,

105
00:06:04,636 --> 00:06:06,034
for good about the app itself.

106
00:06:06,298 --> 00:06:11,794
And so this basically was the start of
the journey I've been on ever since.

107
00:06:11,849 --> 00:06:17,291
and so I actually shared that pitch
with the team at Realm because

108
00:06:17,291 --> 00:06:20,308
they had, you know, right around
recently had launched the mobile.

109
00:06:20,556 --> 00:06:26,226
database and we were wanting to sort of
rebuild a new version of the sync engine.

110
00:06:26,316 --> 00:06:30,996
And so they looked at that and said,
Hey, that's very much what we wanna do,

111
00:06:31,386 --> 00:06:35,126
with our database, so why don't you come
and, you know, help us, build it out.

112
00:06:35,516 --> 00:06:37,883
And so that at the time
made a lot of sense.

113
00:06:37,913 --> 00:06:42,683
'cause I was still not an expert
in databases and sync systems.

114
00:06:42,683 --> 00:06:45,383
This was all just, you know,
we were learning on the job.

115
00:06:45,413 --> 00:06:48,803
And so it felt like being part of a
bigger team that had an incredible

116
00:06:48,803 --> 00:06:52,963
set of experts was a better path to
success than trying to do it on our own.

117
00:06:53,319 --> 00:06:56,329
so I ended up joining Realm
and, was there through, through

118
00:06:56,329 --> 00:06:58,279
the acquisition with MongoDB.

119
00:06:58,279 --> 00:07:00,019
And ultimately this led to Ditto.

120
00:07:00,019 --> 00:07:05,123
So it, truly has been just a, line
all the way back from, you know, 2012

121
00:07:05,123 --> 00:07:09,393
timeframe where I had that moment of,
reflection of not wanting to spend

122
00:07:09,393 --> 00:07:11,323
my career, selling CRM software.

123
00:07:11,864 --> 00:07:12,704
That is awesome.

124
00:07:12,704 --> 00:07:16,574
And I see so many parallels for
so many people in the local-first

125
00:07:16,574 --> 00:07:20,984
space, like whoever you're looking
at who's building innovative things.

126
00:07:20,984 --> 00:07:25,514
For example, like Aaron who is working
on Xero, like, what they all have in

127
00:07:25,514 --> 00:07:29,711
common is that they wanted to build
a me included, like, wanting to build

128
00:07:29,711 --> 00:07:34,241
a great app and then realizing, okay,
what is holding us back to build this

129
00:07:34,241 --> 00:07:39,791
great app as we have it in our mind
is having great, fast local data.

130
00:07:40,751 --> 00:07:45,494
And, and then you take like in your
mind maybe short detour of like, okay,

131
00:07:45,494 --> 00:07:48,554
we're gonna build this data thing first
and then we can build the great app.

132
00:07:49,084 --> 00:07:51,564
I'm still currently in a similar path.

133
00:07:51,654 --> 00:07:54,774
This is also, like in a
similar, like back and forth.

134
00:07:54,774 --> 00:07:57,654
This is what led me to
build Prisma back then.

135
00:07:57,684 --> 00:08:02,237
Not yet with the intention of like having
everything local, but to at least have

136
00:08:02,237 --> 00:08:04,217
a better experience working with data.

137
00:08:04,637 --> 00:08:08,447
But this is very much the path
that I'm currently on where

138
00:08:08,447 --> 00:08:10,007
I'm trying to build Overtone.

139
00:08:10,217 --> 00:08:13,187
But for that, I also had to
build, roll my own data layer.

140
00:08:13,487 --> 00:08:19,037
And a similar path is what, like Aaron
has been on, and this has led to Zero.

141
00:08:19,037 --> 00:08:20,597
And the insight is always the same.

142
00:08:20,597 --> 00:08:23,627
Like to build great app
experiences, we need to have.

143
00:08:23,769 --> 00:08:27,009
great data experience, a great
developer experience around data.

144
00:08:27,429 --> 00:08:30,969
And yeah, it's funny how
like you're tackling the same

145
00:08:30,969 --> 00:08:32,559
problem over and over again.

146
00:08:32,709 --> 00:08:36,819
And every time you just like level
up significantly and you're still

147
00:08:36,819 --> 00:08:40,779
saying true towards like the same
insights and the same mission.

148
00:08:41,079 --> 00:08:45,902
So you've had now, basically three
attempts and every time you're just

149
00:08:45,902 --> 00:08:47,492
like reaching higher and higher.

150
00:08:47,732 --> 00:08:52,159
So maybe before we go into Ditto,
maybe you can share a little bit

151
00:08:52,159 --> 00:08:54,679
more about when you joined Realm.

152
00:08:54,859 --> 00:09:00,016
Like what were your responsibilities and
how did the technology that you've built

153
00:09:00,016 --> 00:09:06,619
in the first CRM app, how did that kind of
translate or differ to what became Realm?

154
00:09:06,949 --> 00:09:07,789
And yeah.

155
00:09:07,789 --> 00:09:10,639
Maybe we can focus a bit
more on the chapter on Realm.

156
00:09:11,127 --> 00:09:11,457
Yeah.

157
00:09:11,457 --> 00:09:16,021
So, I was joking that I'm either crazy,
you know, it's like that saying, if

158
00:09:16,021 --> 00:09:19,381
like you, if, you know, if you just
keep doing something over and over, you

159
00:09:19,381 --> 00:09:22,621
know, either, either maybe you're gonna
hit it right, or, or you're just crazy.

160
00:09:22,621 --> 00:09:25,471
And so I think the
jury's still out on that.

161
00:09:25,604 --> 00:09:30,191
and I do find, like everyone in sort
of the local-first, community, all the

162
00:09:30,191 --> 00:09:34,271
different approaches with it, we sort of
share that same sort of obsession of like,

163
00:09:34,271 --> 00:09:38,651
how could we just build this incredible
infrastructure so that the ultimate

164
00:09:38,651 --> 00:09:40,667
apps that come out of it, are great.

165
00:09:40,757 --> 00:09:45,857
and so the, the transition from, the
naive approach I would say that we

166
00:09:45,857 --> 00:09:49,514
had implemented, with the, that early
startup, which was called Rubik.

167
00:09:49,695 --> 00:09:54,045
it didn't really have anything innovative
in terms of managing versions, is

168
00:09:54,045 --> 00:09:55,245
kind of the simple way to put it.

169
00:09:55,245 --> 00:10:00,688
Like we didn't really understand kind
of anything about, like more novel

170
00:10:00,688 --> 00:10:03,028
approaches to managing consistency.

171
00:10:03,118 --> 00:10:05,115
And so, in addition to that, like.

172
00:10:05,655 --> 00:10:07,425
We were not database experts either.

173
00:10:07,485 --> 00:10:11,661
And so, coming to Realm was
incredible because I was immediately

174
00:10:11,661 --> 00:10:16,005
surrounded by this fantastic
technical team, including the founders

175
00:10:16,335 --> 00:10:20,008
that, had a deep understanding
of how to build a great database.

176
00:10:20,008 --> 00:10:21,688
And that's what drew me to it.

177
00:10:21,688 --> 00:10:24,508
Like Realm to me is a
developer was incredible.

178
00:10:24,568 --> 00:10:26,758
I love like the object interface.

179
00:10:26,998 --> 00:10:28,408
It was highly performant.

180
00:10:28,468 --> 00:10:33,475
It was easier to use, you know, in terms
of query, engine, compared to SQLite.

181
00:10:33,595 --> 00:10:37,765
And, I wanted to be part of the
team that was building that.

182
00:10:38,305 --> 00:10:41,811
And so, the approach that they
ultimately settled on, which I kind

183
00:10:41,811 --> 00:10:46,085
of joined, right when they were in the
early, early moments of designing the

184
00:10:46,085 --> 00:10:51,245
architecture around the sync engine was
to adopt operational transformation,

185
00:10:51,365 --> 00:10:53,425
as like the algorithm, to sync.

186
00:10:53,425 --> 00:10:56,845
And so that was, at the time,
you know, not something at all.

187
00:10:56,845 --> 00:10:57,115
I would.

188
00:10:57,955 --> 00:11:00,915
Feel comfortable trying
to implement, on my own.

189
00:11:00,975 --> 00:11:05,455
And so, the Realm team had the smarts,
across the board to implement it.

190
00:11:05,845 --> 00:11:10,351
And so, we ultimately, that
was kind of 2015 through 2018,

191
00:11:10,541 --> 00:11:11,651
you know, built that out.

192
00:11:11,711 --> 00:11:16,121
And the tough part about that, kind
of in hindsight though, was that.

193
00:11:16,586 --> 00:11:21,353
I don't think, everyone understood
the harsh edges around OT.

194
00:11:21,473 --> 00:11:27,473
And so it was very hard to implement in
test and to really, you know, prove that

195
00:11:27,473 --> 00:11:30,300
it would be consistent in all manners.

196
00:11:30,520 --> 00:11:34,650
And so that just took several
years and ultimately that had a

197
00:11:34,650 --> 00:11:36,870
big effect on the overall business.

198
00:11:37,051 --> 00:11:40,313
and, you know, there were like a
lot of lessons learned around that.

199
00:11:40,343 --> 00:11:45,010
And so, happy to kind of like dive in,
on the technical side of what I may

200
00:11:45,040 --> 00:11:48,650
mean by that, but also, you know, the
implications on the business, which

201
00:11:48,710 --> 00:11:52,630
ultimately meant like the company
was sold, and MongoDB acquired it.

202
00:11:52,630 --> 00:11:57,010
And so those lessons both on tech
and business is really what stuck

203
00:11:57,010 --> 00:11:58,850
in my mind, when starting Ditto.

204
00:11:59,285 --> 00:12:03,185
Yeah, I'd be curious to hear on
either both the technical as well

205
00:12:03,185 --> 00:12:06,664
as on the business side since
Realm really, I remember it just

206
00:12:06,698 --> 00:12:08,768
being way ahead of its time.

207
00:12:08,768 --> 00:12:13,701
Really like And I think it's all started
with this inside of like, hey, the mobile

208
00:12:13,701 --> 00:12:17,841
was just like, was fairly new back then
and everything was about mobile, like

209
00:12:17,841 --> 00:12:19,821
the entire pars back in the service.

210
00:12:20,031 --> 00:12:25,721
That became a thing driven through
the momentum of mobile and then like

211
00:12:25,751 --> 00:12:30,481
to go to such a great extent to have
like a local database that it syncs,

212
00:12:30,481 --> 00:12:34,951
et cetera, and then also going beyond
mobile to go to multiple platforms

213
00:12:34,951 --> 00:12:36,571
that was really ahead of its time.

214
00:12:36,803 --> 00:12:40,775
but as the saying goes, like it takes
10 years to build a database, not

215
00:12:40,775 --> 00:12:45,395
just to build a database here from
scratch, but also to make it sync.

216
00:12:45,715 --> 00:12:48,505
I'd be curious to, to hear
some of those anecdotes.

217
00:12:48,981 --> 00:12:49,311
Yeah.

218
00:12:49,311 --> 00:12:50,691
Well, there's a couple things.

219
00:12:50,691 --> 00:12:55,581
I mean, the part that Realm was incredible
about was its interface as a database.

220
00:12:55,641 --> 00:13:00,203
And that was no small feat  really
benefited personally as a developer

221
00:13:00,263 --> 00:13:02,543
with the software being open
source, like really being able to

222
00:13:02,543 --> 00:13:04,553
understand kind of how that was built.

223
00:13:04,553 --> 00:13:08,183
But they ultimately built their
own storage engine and then

224
00:13:08,183 --> 00:13:10,793
had this really incredible API.

225
00:13:11,153 --> 00:13:15,696
But the, result of that from a,
like a resourcing perspective

226
00:13:15,696 --> 00:13:20,473
meant it took a lot of effort, to
maintain all of the different SDKs.

227
00:13:20,743 --> 00:13:27,148
And so the Swift or objective CSDK
had an API that, you know, wanted

228
00:13:27,148 --> 00:13:30,465
to look really good to those, you
know, Apple Platform developers.

229
00:13:30,825 --> 00:13:35,245
And then likewise, there was a
concerted effort to do the same .net

230
00:13:35,265 --> 00:13:37,205
or Java, you know, on, on Android.

231
00:13:37,565 --> 00:13:41,975
And so it meant that the outer
layer of the database to create

232
00:13:41,975 --> 00:13:45,515
this sort of magical API, just
took a significant investment.

233
00:13:45,815 --> 00:13:50,765
And so that was, to your point, like a
hard problem in and of itself and being

234
00:13:50,765 --> 00:13:53,971
super popular, as an open source database.

235
00:13:54,271 --> 00:13:59,041
It did, kind of command a lot of
the team's attention and so to then

236
00:13:59,041 --> 00:14:03,961
add on and say, Hey, let's take OT,
try to implement it in a generalized

237
00:14:03,961 --> 00:14:08,971
fashion to add this sync engine and
produce a cloud service with it.

238
00:14:09,856 --> 00:14:12,286
That was a lot for a startup to pull off.

239
00:14:12,346 --> 00:14:16,960
And so ultimately that, meant
really sort of never having

240
00:14:16,960 --> 00:14:18,430
the right amount of resources.

241
00:14:18,481 --> 00:14:22,216
and so to me that was one of the
concerns is that you have to figure

242
00:14:22,216 --> 00:14:24,076
out the right balance of trade-offs.

243
00:14:24,430 --> 00:14:29,890
because if you end up trying to perfect
everything at once, and you know, and

244
00:14:29,890 --> 00:14:34,870
you're doing this as a business, like
you might sort of just run out of time,

245
00:14:34,906 --> 00:14:36,406
in terms of building the business.

246
00:14:36,466 --> 00:14:39,768
And that was definitely part of
Realms journey, which was difficult,

247
00:14:39,868 --> 00:14:42,478
you know, it's a venture-backed
business, they've investors and so

248
00:14:42,714 --> 00:14:48,268
there's a clock, and managing how
to use the engineering resources to

249
00:14:48,268 --> 00:14:49,888
solve the right problems that matter.

250
00:14:50,743 --> 00:14:53,443
Both for the product and
customers, but for the business.

251
00:14:53,683 --> 00:14:56,595
you know, there were kind of
allocations, in hindsight that I

252
00:14:56,595 --> 00:14:57,852
think could have been done better.

253
00:14:58,292 --> 00:15:04,238
and a contributor to that is that just
OT was so hard, to reason with, you

254
00:15:04,238 --> 00:15:08,762
know, I'm forgetting the, individual who,
who wrote the implementation at Google,

255
00:15:08,762 --> 00:15:11,552
but I, you know, was sort of famous in
saying, if I had to write it a second

256
00:15:11,552 --> 00:15:13,532
time, it wasn't gonna be any easier.

257
00:15:13,862 --> 00:15:18,612
And so it was just a highly complex
thing to reason about and, needed

258
00:15:18,612 --> 00:15:22,692
like property based randomized
testing to get any confidence around.

259
00:15:22,752 --> 00:15:28,392
And so that just took a while and that
was doubly complex because Realm had

260
00:15:28,392 --> 00:15:32,611
this complex data model, especially
being an object database that had

261
00:15:32,611 --> 00:15:37,222
direct relationships as a first class
citizen you had to deal with, how

262
00:15:37,222 --> 00:15:39,502
do deletes work in that scenario?

263
00:15:39,625 --> 00:15:42,499
and that no one had
really done that before.

264
00:15:42,499 --> 00:15:46,339
Like the implementation with, with
Google Docs isn't needed for that.

265
00:15:46,849 --> 00:15:49,949
And that really speaks to the
magnitude of the challenge here.

266
00:15:49,949 --> 00:15:54,149
Like I remember like experiencing
Google Docs the first time and like

267
00:15:54,149 --> 00:15:59,225
how magical it felt, but like you
say, that took like an absolutely

268
00:15:59,585 --> 00:16:02,369
brilliant team to, pull this off.

269
00:16:02,429 --> 00:16:07,229
And this was like for a very specific
dedicated use case where you can

270
00:16:07,229 --> 00:16:08,999
make very specific trade-offs.

271
00:16:09,359 --> 00:16:14,549
And now with Realm, you wanna build like
a general purpose abstraction that allows

272
00:16:14,549 --> 00:16:16,649
for all kinds of different data models.

273
00:16:16,919 --> 00:16:20,729
So yeah, that, that's basically taking
the same challenge and making it

274
00:16:20,879 --> 00:16:24,959
orders of magnitudes harder because
you need to make sure it works

275
00:16:24,959 --> 00:16:26,579
for all those different scenarios.

276
00:16:26,904 --> 00:16:27,834
Yeah, absolutely.

277
00:16:27,834 --> 00:16:32,060
And that, was harder than anyone
realized in hindsight, in my opinion.

278
00:16:32,357 --> 00:16:36,894
and the other side of it too was
it just had technical challenges.

279
00:16:36,967 --> 00:16:41,557
the actual algorithm itself, given
that if you have a long history with

280
00:16:41,557 --> 00:16:45,607
devices that have been offline for
a while, you're gonna have quadratic

281
00:16:45,757 --> 00:16:50,467
complexity to being able to transform
the operations for the other devices.

282
00:16:50,737 --> 00:16:55,387
And so that would manifest itself
and it's always the worst times where

283
00:16:55,417 --> 00:16:59,167
you've got heavy load on the server
or you've got this, this one errant

284
00:16:59,167 --> 00:17:04,470
device that shows back up with a long
history and then suddenly, the server

285
00:17:04,530 --> 00:17:09,064
would itself run outta memory or, you
know, um, basically, die in the process.

286
00:17:09,064 --> 00:17:14,400
And so, that was something that at the
time we hadn't really fully solved.

287
00:17:14,430 --> 00:17:17,910
'cause you have to then figure out
how to prune histories to kind of

288
00:17:17,910 --> 00:17:19,800
prevent that scenario from happening.

289
00:17:20,190 --> 00:17:24,150
But that's like a balance of,
what does the application expect.

290
00:17:24,447 --> 00:17:29,850
and so I ultimately think those technical
problems could have been solved, like

291
00:17:29,850 --> 00:17:35,910
there were solutions to it, but it was
hard to do that under all the other

292
00:17:35,940 --> 00:17:41,580
constraints from managing the open source,
success of the mobile database itself,

293
00:17:41,910 --> 00:17:43,980
plus just the general business concerns.

294
00:17:44,010 --> 00:17:49,170
And so that's ultimately, you know,
what led to having to sell the company,

295
00:17:49,228 --> 00:17:51,660
and, you know, MongoDB acquiring it.

296
00:17:51,960 --> 00:17:56,190
And so, but all of those lessons
were sort of in the back of my mind,

297
00:17:56,324 --> 00:18:00,524
in terms of starting Ditto, because
I felt really unfulfilled is the,

298
00:18:00,794 --> 00:18:02,504
you know, honest way to describe it.

299
00:18:02,762 --> 00:18:03,812
Loved Realm.

300
00:18:03,812 --> 00:18:08,052
The product felt like it really
had the potential, but it got

301
00:18:08,052 --> 00:18:10,015
sort of cut short, in its life.

302
00:18:10,075 --> 00:18:16,345
And so the choice of joining Mongo and
trying to, you know, fix and in, you know,

303
00:18:16,345 --> 00:18:19,615
continue to improve those things in a
larger company seems somewhat difficult.

304
00:18:19,883 --> 00:18:23,295
and that was part of the reason to just
go start, Ditto was like, okay, like I've,

305
00:18:23,382 --> 00:18:27,852
done this once in a naive way, then start
to really figure out how to do it in an

306
00:18:27,852 --> 00:18:32,082
advanced way, but didn't really get to
pull it off, so could I go do that now?

307
00:18:32,235 --> 00:18:36,082
and so that was sort of the personal
motivator, in starting Ditto was it felt

308
00:18:36,082 --> 00:18:38,302
like I had to just go do it on my own.

309
00:18:38,302 --> 00:18:42,412
Is the only way to really have
the unconstrained ability to

310
00:18:42,412 --> 00:18:44,422
explore like new approaches.

311
00:18:44,600 --> 00:18:45,410
That is awesome.

312
00:18:45,410 --> 00:18:48,889
And now you have like two rounds of
practice rounds already under your

313
00:18:48,889 --> 00:18:51,929
belt, two notes just on the Realm side.

314
00:18:52,255 --> 00:18:57,385
it was sort of unfortunate news fairly
recently that Mongo decided to sunset

315
00:18:57,385 --> 00:19:01,135
Realm, which I think led to another
interesting business opportunity for

316
00:19:01,135 --> 00:19:03,665
Ditto, which we, maybe touched on later.

317
00:19:03,935 --> 00:19:07,925
but another shout out is that we, at
last year's Local-First Conf, we had

318
00:19:07,952 --> 00:19:12,942
actually one of the founders of, Realm
give a talk Alexander, about like

319
00:19:12,942 --> 00:19:17,352
what made Realm so special, which what
you've already, mentioned, which is

320
00:19:17,352 --> 00:19:21,372
like the surface area, that it feels
native to whatever platform you're

321
00:19:21,372 --> 00:19:24,162
building for, whether you're building
an iOS app, whether you're building

322
00:19:24,162 --> 00:19:26,022
a Mac app, an Android app, et cetera.

323
00:19:26,262 --> 00:19:32,225
This is where Realm really had such a big
edge and an advantage that felt native

324
00:19:32,225 --> 00:19:34,865
to whatever platform you're targeting.

325
00:19:35,345 --> 00:19:38,255
And I think that remains
true to this day very much.

326
00:19:38,645 --> 00:19:41,122
And I think there's a
lot to learn from there.

327
00:19:41,528 --> 00:19:41,798
Absolutely.

328
00:19:41,798 --> 00:19:45,488
I mean, I'm sort of like coming
from Realm, like Ditto did

329
00:19:45,518 --> 00:19:46,838
to that trade off question.

330
00:19:46,868 --> 00:19:51,692
Like our interface mirrors much more
of a traditional database, interface.

331
00:19:51,795 --> 00:19:56,955
it's a document model and we have our
own query engine called DQL, but it's,

332
00:19:56,985 --> 00:20:02,325
you know, more like a SQL interface and
a sort of cringe a little bit because

333
00:20:02,325 --> 00:20:07,755
like it really isn't as elegant, as
Realm, like Realms API was incredible.

334
00:20:07,815 --> 00:20:11,265
I mean that's, as a developer why I
wanted to join the company is it's just

335
00:20:11,265 --> 00:20:16,025
like, wow, this is the product I want to
use when building a mobile application.

336
00:20:16,375 --> 00:20:21,985
But the, but to that is, it was not
without significant resources and

337
00:20:21,985 --> 00:20:24,139
effort, to make that, interface.

338
00:20:24,439 --> 00:20:29,479
And in hindsight, that's where I sort
of wonder from a business perspective,

339
00:20:29,479 --> 00:20:34,219
did that interface really give it, you
know, drive the success of the business?

340
00:20:34,425 --> 00:20:38,042
at the time, it wasn't, it was very
popular from an open source, but it

341
00:20:38,042 --> 00:20:39,302
wasn't really helping the business.

342
00:20:39,302 --> 00:20:43,227
And so that was, The part that, I'm
hoping eventually, you know, as Ditto

343
00:20:43,227 --> 00:20:48,147
continues to grow, we'd sort of be able
to improve their API and stuff pull

344
00:20:48,147 --> 00:20:52,174
that, but we've had to sort of make the
trade off that maybe that's not a day

345
00:20:52,174 --> 00:20:54,447
one problem, given the Realm experience.

346
00:20:54,927 --> 00:20:58,377
And I think this is really like
what led to all of the success.

347
00:20:58,427 --> 00:21:02,717
you're having so far already with Ditto
where you're thinking correct about the

348
00:21:02,717 --> 00:21:07,037
trade-offs and like when you do things
on day one and how you sequence those

349
00:21:07,037 --> 00:21:11,717
and you still have those ambitions to,
do things eventually that you want to do.

350
00:21:12,047 --> 00:21:16,900
But I think, when looking at Realm,
there's so many hard things like

351
00:21:16,900 --> 00:21:18,700
building the technology by itself.

352
00:21:18,700 --> 00:21:23,020
Like, let's even imagine we have
more time, we have more resources.

353
00:21:23,170 --> 00:21:27,100
Still super hard, but then to do it in
this constrained environment where you

354
00:21:27,100 --> 00:21:32,633
need to build a business in the meanwhile,
while you're, just like losing sleep over

355
00:21:32,753 --> 00:21:37,193
super hard, unsolved technical problems,
that's just like really, really hard.

356
00:21:37,193 --> 00:21:41,993
And I think having had the experience
of seeing this journey once or twice,

357
00:21:42,290 --> 00:21:46,400
now really gave you a super unfair
and to your credit, like a positive,

358
00:21:46,400 --> 00:21:52,430
unfair advantage to start Ditto as
a business and to like solve as many

359
00:21:52,430 --> 00:21:56,817
technical problems as is currently,
applicable and healthy to your business.

360
00:21:56,817 --> 00:22:00,807
So with that, I wanna learn
more about Ditto, like, so you

361
00:22:00,807 --> 00:22:03,387
mentioned you started it in 2018.

362
00:22:03,657 --> 00:22:04,557
What was it?

363
00:22:04,837 --> 00:22:09,347
Product wise, at that point, what was
sort of like the first major milestones

364
00:22:09,367 --> 00:22:14,497
that, that you've reached and now since
2018, many years have passed and I think

365
00:22:14,497 --> 00:22:19,057
it's fair to say that you're probably
one of the most advanced, biggest players

366
00:22:19,117 --> 00:22:21,037
in the local-first in the sync space.

367
00:22:21,307 --> 00:22:22,657
So there's plenty to learn.

368
00:22:23,345 --> 00:22:27,942
Yeah, well, it's been a very interesting
journey in the sense that a lot of early

369
00:22:27,942 --> 00:22:30,815
assumptions, actually were proven wrong.

370
00:22:30,815 --> 00:22:33,865
And so, excited to kinda
share, those insights.

371
00:22:33,865 --> 00:22:38,155
And the first thing that sort of
started the company was after that

372
00:22:38,155 --> 00:22:42,422
experience working with OT and just
seeing all the challenges with it, I

373
00:22:42,422 --> 00:22:47,212
was immediately drawn to sort of the
flexibility you could say with CRDTs,

374
00:22:47,475 --> 00:22:50,745
and kind of couple axes I guess for that.

375
00:22:50,745 --> 00:22:57,805
one was it felt like just much simpler
to build the actual merge semantics,

376
00:22:57,955 --> 00:23:00,025
like, you know, reading papers and stuff.

377
00:23:00,025 --> 00:23:02,998
It's like this is just not a lot
of lines of code to get the same

378
00:23:02,998 --> 00:23:04,558
sort of predictable outcomes.

379
00:23:04,918 --> 00:23:09,628
And it was also just efficient, like these
are simple operations to actually reason

380
00:23:09,628 --> 00:23:15,117
about how to merge data together with the
trade off being that you have to increased

381
00:23:15,117 --> 00:23:17,216
the metadata of the system itself.

382
00:23:17,516 --> 00:23:22,345
'cause it's like we are going to use
more metadata to reason about, the

383
00:23:22,345 --> 00:23:27,025
different versions instead of using
OT to me was always an algorithmic

384
00:23:27,025 --> 00:23:31,915
approach and that can be more efficient
because you can send less data, but

385
00:23:32,005 --> 00:23:33,625
then the algorithm has to figure it out.

386
00:23:34,045 --> 00:23:38,162
But having seen all the challenges of
having to scale, OT algorithmically,

387
00:23:38,492 --> 00:23:43,322
it felt like using more metadata
was the right trade off, especially

388
00:23:43,322 --> 00:23:48,512
because there are other ways to sort
of compress and manage that metadata.

389
00:23:48,512 --> 00:23:53,162
So it, it felt like that problem
probably is more logarithmic versus,

390
00:23:53,187 --> 00:23:57,340
quadratic or exponential where you
had, with an algorithmic approach.

391
00:23:57,730 --> 00:24:02,316
And so that, that to me was just
interesting coming from Realm.

392
00:24:02,916 --> 00:24:09,235
The other side of it though was like, Hey,
this is a decentralized approach as well.

393
00:24:09,279 --> 00:24:10,715
this can work peer to peer.

394
00:24:10,985 --> 00:24:16,748
And that, in and of itself opened
up new possibilities, that also

395
00:24:16,748 --> 00:24:18,972
built upon, experiences at Realm.

396
00:24:19,049 --> 00:24:23,098
and so one of which is actually
the part that Ditto is less known

397
00:24:23,098 --> 00:24:27,658
for, which is how to scale just
the server side of a sync engine.

398
00:24:27,959 --> 00:24:30,542
because sync itself is stateful.

399
00:24:30,842 --> 00:24:36,495
You, can get into a scenario where
client devices have trouble migrating

400
00:24:36,795 --> 00:24:39,192
to different, nodes in the backend.

401
00:24:39,492 --> 00:24:42,938
And that was something we faced at
Realm was that it was very sticky, in

402
00:24:42,938 --> 00:24:45,158
sort of letting a device sort of reset.

403
00:24:45,653 --> 00:24:49,463
It's a state between the
client and the backend.

404
00:24:49,857 --> 00:24:51,117
wasn't very straightforward.

405
00:24:51,444 --> 00:24:55,847
but that's a lot easier to do with
CRDTs because they're inherently,

406
00:24:55,913 --> 00:24:58,193
don't require like a central system.

407
00:24:58,703 --> 00:25:02,183
And so that was actually the
main reason I was first drawn to

408
00:25:02,183 --> 00:25:04,523
it, was that stickiness problem.

409
00:25:05,033 --> 00:25:09,113
But the other side of it was like,
well wait, if you can migrate

410
00:25:09,113 --> 00:25:14,123
around to different nodes in a
server itself, why can't the nodes

411
00:25:14,123 --> 00:25:15,783
at the edge talk to each other?

412
00:25:16,143 --> 00:25:20,538
And that is, that aspect is really
what Ditto is known for now.

413
00:25:20,668 --> 00:25:24,717
but it, oddly enough came from
looking at it from more of a server

414
00:25:24,717 --> 00:25:28,253
scaling issue, coming, coming
from the experience at Realm.

415
00:25:28,597 --> 00:25:32,347
but the idea that you could
connect devices directly.

416
00:25:32,947 --> 00:25:34,297
No one had done that before.

417
00:25:34,297 --> 00:25:39,007
And so that felt like, hey, if we could
build that, that would really take

418
00:25:39,007 --> 00:25:43,173
this to the next level, and really be
something I never attempted, you know,

419
00:25:43,173 --> 00:25:44,913
in the original startup or at Realm.

420
00:25:45,303 --> 00:25:49,233
And so that, that was the part of
where trying to do that at a larger

421
00:25:49,323 --> 00:25:51,987
company, felt really not pragmatic.

422
00:25:52,087 --> 00:25:55,867
probably the last thing someone who just
buys a company wants to do is like, let,

423
00:25:55,987 --> 00:25:58,147
let some folks go and rebuild the system.

424
00:25:58,507 --> 00:26:02,317
So that was the genesis of like, this
probably has to be its own independent

425
00:26:02,317 --> 00:26:04,447
company to kind of go and pull this off.

426
00:26:04,817 --> 00:26:09,690
And so in the first six months of
the business, it was all around sort

427
00:26:09,690 --> 00:26:11,970
of proving is this even possible?

428
00:26:12,180 --> 00:26:17,187
Because in my opinion, Ditto as
a company or technology, it had a

429
00:26:17,187 --> 00:26:23,067
requirement on the edge, peer-to-peer
aspect of whether or not the hardware

430
00:26:23,510 --> 00:26:26,180
had reached maturity to pull it off.

431
00:26:26,474 --> 00:26:31,124
like enabling devices to talk
peer to peer is not a novel idea.

432
00:26:31,174 --> 00:26:32,104
That's, yeah.

433
00:26:32,104 --> 00:26:34,424
The internet was created because of that.

434
00:26:34,934 --> 00:26:39,794
But enabling devices to do that
wirelessly is very much a function

435
00:26:39,794 --> 00:26:43,904
of whether the hardware, was ready
for that because like the original

436
00:26:43,904 --> 00:26:49,544
iPhone or early mobile devices were
one underpowered, like batteries

437
00:26:49,544 --> 00:26:54,410
have gotten more dense in the years
since, CPUs and memory have increased.

438
00:26:54,520 --> 00:26:57,400
and then the wireless protocols
themselves, like Bluetooth

439
00:26:57,460 --> 00:26:58,810
is not the same protocol.

440
00:26:58,810 --> 00:27:00,610
It was even 10 years ago.

441
00:27:00,970 --> 00:27:06,460
And so the early sort of six months
of, prototyping with Ditto was very

442
00:27:06,460 --> 00:27:11,427
much a question of if this edge,
peer-to-peer is gonna be like the key

443
00:27:11,427 --> 00:27:13,017
innovation that no one has pulled off.

444
00:27:13,317 --> 00:27:16,197
There was a part that we didn't
really have control of, or which was.

445
00:27:16,472 --> 00:27:19,604
starting Ditto in 2018, like
the right time, had the hardware

446
00:27:19,604 --> 00:27:22,590
actually, progressed to a
point where this is, feasible.

447
00:27:22,957 --> 00:27:26,557
and that's the, I would say perhaps
serendipity aspect of it was

448
00:27:26,557 --> 00:27:30,697
that that was true like 10 years
sort of from the original iPhone.

449
00:27:30,697 --> 00:27:33,127
Like, you know, 2018 was the iPhone 10.

450
00:27:33,690 --> 00:27:35,370
That was a supercomputer.

451
00:27:35,534 --> 00:27:41,060
and that was a trend line that we wanted
to bet on was that those devices, even

452
00:27:41,060 --> 00:27:45,430
other form factors were gonna continue
to become, really, really powerful

453
00:27:45,730 --> 00:27:51,020
and connecting them directly, would
open up new forms of applications.

454
00:27:51,080 --> 00:27:52,250
And so if we.

455
00:27:52,955 --> 00:27:56,225
Pulled that off, like that felt
like a really big opportunity.

456
00:27:56,565 --> 00:28:01,469
So I just wanna linger on this point
for a little bit since we're thinking

457
00:28:01,469 --> 00:28:06,929
about syncing your mind typically goes
to getting data from A to B, and then

458
00:28:06,929 --> 00:28:11,459
you think about like, okay, that the
data is correct, that it converges, how

459
00:28:11,459 --> 00:28:13,559
about like transactionality, et cetera.

460
00:28:13,859 --> 00:28:18,959
But we typically always kinda assume like
getting the data from A to B of course.

461
00:28:18,959 --> 00:28:22,169
Like we have like a stable TCP
connection and like it's all good.

462
00:28:22,199 --> 00:28:23,639
Maybe we're in fiber internet.

463
00:28:24,029 --> 00:28:25,982
but what you're realizing.

464
00:28:26,202 --> 00:28:26,622
Okay.

465
00:28:26,622 --> 00:28:31,032
It is possible, like the data
part seems to be like realistic,

466
00:28:31,314 --> 00:28:33,709
and, and feasible with CRDTs.

467
00:28:33,739 --> 00:28:37,729
This is where you still had sort of like
your, more harsh experience with OT.

468
00:28:37,729 --> 00:28:42,649
CRDTs seemed very promising, and
now you realize, okay, now from a

469
00:28:42,739 --> 00:28:47,809
network topology perspective, this
is feasible that those things could

470
00:28:47,809 --> 00:28:50,059
exchange the data like directly.

471
00:28:50,479 --> 00:28:55,189
But I think what you've then
realized is like, well, two devices

472
00:28:55,189 --> 00:28:57,259
don't just talk to each other.

473
00:28:57,499 --> 00:29:01,849
That is, it's sort of like a miracle
that the internet works at scale,

474
00:29:01,849 --> 00:29:06,619
the way how it does with like routers
and network tables, et cetera.

475
00:29:06,889 --> 00:29:11,479
But now you want to kinda like jump
beyond that and make the things talk to

476
00:29:11,479 --> 00:29:17,065
each other directly, which at the same
time is, mind blowing that that's not

477
00:29:17,065 --> 00:29:22,749
the way, the default way how most things
are that when I have here my iPhone.

478
00:29:22,979 --> 00:29:27,839
And an iPad, like most realistically,
when I wanna send something

479
00:29:27,839 --> 00:29:31,263
between those two devices, it's
probably gonna leave my country.

480
00:29:31,853 --> 00:29:35,806
and this is basically the other
hard problem you've kind of stumbled

481
00:29:35,806 --> 00:29:37,846
into, which is the networking.

482
00:29:37,846 --> 00:29:43,110
So if I'm thinking about like choose
your hero for your new business, I was

483
00:29:43,110 --> 00:29:49,423
like, before you had like all the bars
on like on data and algorithmic and now

484
00:29:49,423 --> 00:29:54,853
a new bar has popped up, which is like
max out for network, for networking.

485
00:29:55,183 --> 00:29:59,113
And that is, I think when I think
about Ditto, this is, I think my

486
00:29:59,143 --> 00:30:03,553
mind immediately goes to, oh, this
is the company who's like, has gone

487
00:30:03,613 --> 00:30:09,483
to all the extremes on networking and
whatever networking way there might be.

488
00:30:09,886 --> 00:30:13,096
you probably have like an A
plus implementation for that.

489
00:30:13,536 --> 00:30:18,510
Yeah, so that is ironic because,
yeah, as I've mentioned, like coming

490
00:30:18,510 --> 00:30:20,880
from Realm, CRDTs were top of mind.

491
00:30:21,210 --> 00:30:23,580
And so this was summer of 2018.

492
00:30:23,580 --> 00:30:25,110
It was myself, my co-founder Max.

493
00:30:25,386 --> 00:30:26,776
we were just working on our own.

494
00:30:26,776 --> 00:30:28,956
We hadn't raised money,
didn't hire anyone.

495
00:30:28,986 --> 00:30:31,116
That came later at the beginning of 2019.

496
00:30:31,536 --> 00:30:36,960
And so we started working, with
some, you know, third party, CRDT

497
00:30:36,960 --> 00:30:41,940
libraries starting to kind of build a
prototype of a data store around it.

498
00:30:42,060 --> 00:30:45,600
And we were like, okay, you know, this
is a hard problem in and of itself.

499
00:30:46,003 --> 00:30:51,013
but when, like we started to embark
on getting the network layer to work.

500
00:30:51,823 --> 00:30:52,273
Wow.

501
00:30:52,273 --> 00:30:54,350
That was a very humbling experience.

502
00:30:54,350 --> 00:30:59,747
so like Max sent was very focused on the
data store in the APIs and I was like,

503
00:30:59,747 --> 00:31:02,417
oh, I'll get this Bluetooth thing working.

504
00:31:02,520 --> 00:31:03,600
no, no problem.

505
00:31:04,042 --> 00:31:09,858
And I just felt like, my whole job
was just like clicking buttons.

506
00:31:10,062 --> 00:31:15,372
because you can't really simulate
mesh networking, and that's, in

507
00:31:15,372 --> 00:31:19,242
hindsight, it was, I dunno, I guess
maybe more obvious like networking

508
00:31:19,272 --> 00:31:22,472
is, you know, not predictable.

509
00:31:22,548 --> 00:31:25,527
and mesh networking itself
is an optimization problem.

510
00:31:26,007 --> 00:31:28,767
So there is no like way
to solve mesh networking.

511
00:31:29,140 --> 00:31:32,690
and whereas solving data storage.

512
00:31:33,270 --> 00:31:38,410
There is an end state, it's like right,
it predictably onto the storage device.

513
00:31:38,462 --> 00:31:39,450
don't corrupt the data.

514
00:31:39,480 --> 00:31:44,504
Like there is a solution at the end,
but on the networking side it's all

515
00:31:44,504 --> 00:31:50,794
about balancing trade-offs and managing
like the reactions to the environment

516
00:31:50,984 --> 00:31:52,874
that you don't have full control over.

517
00:31:53,264 --> 00:31:59,214
And so that was way, way
harder than we anticipated.

518
00:31:59,387 --> 00:32:02,987
and our early version in
2018, you know, barely worked.

519
00:32:03,100 --> 00:32:07,330
but it was enough that there were
some customers that jumped out,

520
00:32:07,417 --> 00:32:12,247
specifically in the airline industry
that had similarly internally

521
00:32:12,247 --> 00:32:14,287
tried to build something like this.

522
00:32:14,317 --> 00:32:16,417
'cause they were trying to
build apps that work in the

523
00:32:16,417 --> 00:32:17,917
plane where there's no internet.

524
00:32:18,502 --> 00:32:20,272
And they couldn't pull it off.

525
00:32:20,272 --> 00:32:24,822
And so even though our, initial
prototype barely worked, the fact that

526
00:32:24,822 --> 00:32:29,379
it barely worked, was still enough
to say, Hey, that this is a big deal.

527
00:32:29,462 --> 00:32:32,345
you know, we would buy this
product at, significant scale if

528
00:32:32,345 --> 00:32:33,545
you could actually make it work.

529
00:32:33,605 --> 00:32:38,015
And so that's what ultimately led to
forming the company and hiring folks.

530
00:32:38,375 --> 00:32:43,625
But I mean, we had a prototype in
like August and September of 2018.

531
00:32:44,075 --> 00:32:48,459
We didn't really have a solid
functioning version until a year later.

532
00:32:48,742 --> 00:32:50,332
and that was really only on iOS.

533
00:32:50,332 --> 00:32:54,772
The Android one didn't come later, so
I mean, it was practically two years.

534
00:32:54,862 --> 00:33:00,895
And like 80% of that was all the
replication protocol itself, the CRDT, the

535
00:33:00,895 --> 00:33:03,175
data store aspect of it became a backseat.

536
00:33:03,475 --> 00:33:05,815
We sort of said, okay,
like, what are some kind of.

537
00:33:06,269 --> 00:33:09,269
basic semantics that people
would want, like last right wins.

538
00:33:09,539 --> 00:33:12,989
And how, how do we implement that
in a causally consistent manner?

539
00:33:13,289 --> 00:33:17,429
How do we provide an API where
you can query and, you know, do,

540
00:33:17,529 --> 00:33:19,749
simple crud operations on this?

541
00:33:20,139 --> 00:33:21,909
But then it was like.

542
00:33:22,314 --> 00:33:26,670
Put all of our energy into how do
we make this work in these, wireless

543
00:33:26,670 --> 00:33:31,474
scenarios, specifically around Bluetooth
and peer-to-peer wifi in mobile devices.

544
00:33:31,834 --> 00:33:37,264
So staying maybe at this timeframe
for a little bit, if you consider the

545
00:33:37,264 --> 00:33:41,794
technology that you've had built out
back then and today, like today, you

546
00:33:41,794 --> 00:33:47,584
probably have like orders of magnitude
of more like capabilities and coverage

547
00:33:47,584 --> 00:33:53,028
for, for different like network protocols
and topologies, et cetera, scalability.

548
00:33:53,531 --> 00:33:59,528
and you probably already, to some extent
at least kind of foresee those back then.

549
00:33:59,528 --> 00:34:04,094
You, probably, like in your head,
you start to like sum up two plus

550
00:34:04,094 --> 00:34:07,364
two and you realize, oh, that means
we should also do that and do that.

551
00:34:07,574 --> 00:34:11,428
But then it becomes like a scoping
exercise and say like, Hey,

552
00:34:11,445 --> 00:34:13,271
with, how little can we get away?

553
00:34:13,371 --> 00:34:16,191
Building this out that
is already valuable.

554
00:34:16,621 --> 00:34:19,351
so that's one thing that I'm curious
like how you went about that.

555
00:34:19,351 --> 00:34:24,301
And the other thing is going from
something that like barely works

556
00:34:24,361 --> 00:34:28,681
and in most cases breaks to a year
later, something where you feel pretty

557
00:34:29,011 --> 00:34:33,608
confident about, how did you go about
building that confidence and how good,

558
00:34:33,878 --> 00:34:35,768
like, did you know it's gonna work?

559
00:34:36,008 --> 00:34:37,598
Or have you basically Yeah.

560
00:34:37,598 --> 00:34:39,218
How did you build that confidence?

561
00:34:39,998 --> 00:34:43,868
Well, uh, no, there was still like
moments in those first couple years

562
00:34:43,868 --> 00:34:47,768
where I still wondered like, maybe this
actually really isn't going to be possible

563
00:34:47,768 --> 00:34:49,268
to the point on the hardware side.

564
00:34:49,664 --> 00:34:53,491
like this, well this is sort
of changing now, but, to date

565
00:34:53,491 --> 00:34:57,511
still the only cross-platform
way that devices can communicate,

566
00:34:57,621 --> 00:35:02,031
peer-to-peer would be Bluetooth or
if they're on the same wifi network.

567
00:35:02,348 --> 00:35:05,138
same wifi networks a little bit
easier 'cause you know, you've got

568
00:35:05,138 --> 00:35:09,711
a, higher bandwidth stable network
to a degree that's actually very much

569
00:35:09,711 --> 00:35:14,228
not true in practice, but, compared
to Bluetooth, way more stable.

570
00:35:14,738 --> 00:35:18,248
But Bluetooth was the sort of
the magical thing about Ditto.

571
00:35:18,248 --> 00:35:22,508
Like whenever we showed people the
early demos, there'd be two phones

572
00:35:22,625 --> 00:35:27,695
on airplane mode and you'd click and
instantaneously changes would happen.

573
00:35:28,225 --> 00:35:31,855
even non-technical people look
at this and say like, what?

574
00:35:32,125 --> 00:35:34,495
Like, I didn't, I didn't
know this was possible.

575
00:35:34,495 --> 00:35:35,875
Like, this feels like magic.

576
00:35:35,875 --> 00:35:37,435
Have you done something to the phone?

577
00:35:37,885 --> 00:35:42,685
And so we ultimately put a ton of
effort into trying to figure out

578
00:35:42,685 --> 00:35:44,875
how to make that work reliably.

579
00:35:45,145 --> 00:35:49,915
And so that to your point on like
early design decisions, that choice

580
00:35:49,915 --> 00:35:54,385
to really figure out how to make
Bluetooth a functioning protocol

581
00:35:54,565 --> 00:35:58,285
that you could sort of build
enterprise type applications around.

582
00:35:58,548 --> 00:36:00,745
which is what, was the customer demand.

583
00:36:01,195 --> 00:36:07,165
was a pretty tough constraint to work
under because it is very unreliable.

584
00:36:07,285 --> 00:36:12,805
Every platform has bugs and errors
in practice that are undocumented.

585
00:36:13,135 --> 00:36:16,235
Like, 'cause there are just
like improper implementations of

586
00:36:16,305 --> 00:36:18,175
Bluetooth at the firmware level.

587
00:36:18,498 --> 00:36:23,328
and, you know, scouring Stack
overflow or Apple forms or whatever.

588
00:36:23,516 --> 00:36:25,916
you'd literally find stuff
that's never mentioned on the

589
00:36:25,916 --> 00:36:27,523
internet, in encountering it.

590
00:36:27,583 --> 00:36:31,843
And the only way to encounter
that was to use physical devices.

591
00:36:32,083 --> 00:36:34,693
You cannot run the
simulator and find all this.

592
00:36:34,993 --> 00:36:41,623
So that really was why it was so hard,
like designing a protocol around it that

593
00:36:41,623 --> 00:36:43,933
was optimized for the low bandwidth.

594
00:36:44,263 --> 00:36:47,726
That was challenging 'cause we
needed to be hyper efficient,

595
00:36:48,056 --> 00:36:50,666
but at least that's something you
can kind of like whiteboard out.

596
00:36:51,206 --> 00:36:55,676
Then going and proving to yourself, wow,
this actually works in the real world.

597
00:36:55,676 --> 00:37:00,646
Meant just a lot of tedious manual effort
to the point that, I really just felt

598
00:37:00,646 --> 00:37:05,026
like a monkey clicking devices and sort
of joked I should buy a, like a robot

599
00:37:05,116 --> 00:37:09,550
that would just click phones for me,
as a way to test the software because

600
00:37:09,550 --> 00:37:11,320
there was no automated way to do it.

601
00:37:11,710 --> 00:37:15,790
And so that's the reason it took
so long was to gain that confidence

602
00:37:16,030 --> 00:37:20,906
that the choices that we had made,
would work in a reliable manner.

603
00:37:21,246 --> 00:37:25,976
And it was just sort of, I don't
know, sort of like hacking your way

604
00:37:25,976 --> 00:37:27,773
through a forest, with a machete.

605
00:37:27,773 --> 00:37:29,333
Like you didn't really
know where you were going.

606
00:37:29,333 --> 00:37:31,883
You just had to just keep
pushing, pushing onward with it.

607
00:37:32,363 --> 00:37:34,823
it was way harder than than expected.

608
00:37:35,133 --> 00:37:36,273
That is incredible.

609
00:37:36,293 --> 00:37:39,953
And like as a web developer, we
kind of like, we don't know how

610
00:37:39,953 --> 00:37:44,063
good we have it with like tools like
Playwright, which gives you like browser

611
00:37:44,063 --> 00:37:48,563
testing with like top-notch APIs, et
cetera, works for multiple browsers.

612
00:37:48,803 --> 00:37:52,733
We don't ever need to leave like
the comfort of our chair and like we

613
00:37:52,733 --> 00:37:56,393
can just like use our primary device
and then run things even headless.

614
00:37:56,413 --> 00:38:00,223
And you develop some pretty good
confidence that stuff is gonna work.

615
00:38:00,523 --> 00:38:04,663
When you're building native mobile
apps, then you're rather like you're

616
00:38:04,663 --> 00:38:06,133
flashing things on your phone.

617
00:38:06,253 --> 00:38:10,063
And then maybe you also have, like, if
you're primarily using iOS, you might

618
00:38:10,063 --> 00:38:14,353
have an Android phone and maybe you
have multiple Android phones because

619
00:38:14,353 --> 00:38:16,273
it's much more heterogeneous there.

620
00:38:16,573 --> 00:38:19,813
And then you are already getting
into that mode of like having a few

621
00:38:19,813 --> 00:38:24,823
test devices, but you're going way
further than that because you need

622
00:38:24,823 --> 00:38:26,803
to like look for all the edge cases.

623
00:38:26,803 --> 00:38:29,383
So that brings me to a
kinda funny question.

624
00:38:29,593 --> 00:38:33,590
I'm curious whether you have like
a chart of like the number of

625
00:38:33,590 --> 00:38:37,000
physical test devices that you've
kind of allotted over the years?

626
00:38:38,110 --> 00:38:42,706
Yeah, I mean we have so many devices,
that we've built up over the years.

627
00:38:42,706 --> 00:38:45,936
I mean, to the point that, I guess
almost two years back now, we, we

628
00:38:45,936 --> 00:38:48,216
invested in actually building out.

629
00:38:48,666 --> 00:38:53,470
A, what you would call a semi anechoic
chamber, to try to put a bunch of

630
00:38:53,470 --> 00:38:59,316
phones in a room, and run through
simulations of them connecting up at this.

631
00:38:59,376 --> 00:39:00,876
It was up to a hundred devices.

632
00:39:00,876 --> 00:39:06,700
And so, Like there are, physical device
testing companies that will run your app

633
00:39:06,700 --> 00:39:10,870
on a device, but they don't specialize
in actually getting the devices in their,

634
00:39:11,040 --> 00:39:12,930
in their labs to talk to each other.

635
00:39:13,230 --> 00:39:16,196
And so we basically
set out to, build that.

636
00:39:16,405 --> 00:39:20,878
we had an intern actually who, was
a mechanical engineer who actually

637
00:39:20,878 --> 00:39:22,358
designed the room and stuff.

638
00:39:22,668 --> 00:39:25,948
And so that's been sort of the fun part
about this is like, I wouldn't have

639
00:39:25,948 --> 00:39:31,318
expected 15, you know, years later after
being a software developer that this

640
00:39:31,708 --> 00:39:37,101
local-first obsession, would pull me
into such a physical manifestation of it.

641
00:39:37,360 --> 00:39:42,361
but it was all from the, desire to,
work with these peer-to-peer, like

642
00:39:42,391 --> 00:39:45,181
true peer-to-peer, wireless protocols.

643
00:39:45,521 --> 00:39:48,291
and just the plethora,
of different devices.

644
00:39:48,591 --> 00:39:51,561
And to be clear, like
this is still true in iOS.

645
00:39:51,681 --> 00:39:55,461
Like you would think that Apple
devices, their whole pitch is.

646
00:39:55,786 --> 00:39:59,566
We designed the hardware and the
software, and so you would think across

647
00:39:59,566 --> 00:40:05,536
versions that a Bluetooth firmware would
be the same and you wouldn't encounter

648
00:40:05,536 --> 00:40:07,726
weird behavior, but that's not true.

649
00:40:07,796 --> 00:40:09,376
It still exists.

650
00:40:09,616 --> 00:40:13,520
It's definitely way worse when you get
into, you know, Android, windows, Linux,

651
00:40:13,520 --> 00:40:15,623
like the, broader plethora of devices.

652
00:40:15,953 --> 00:40:21,286
But, even in the platform, you'd sort
of expect commonality across hardware.

653
00:40:21,623 --> 00:40:24,190
you'd still encounter
these, weird scenarios.

654
00:40:24,603 --> 00:40:29,163
and so we have like logic in Ditto
that at this point sort of built out

655
00:40:29,163 --> 00:40:33,933
through that trial and error that
it's not really novel like concepts,

656
00:40:34,203 --> 00:40:39,213
but it's just knowing when to smartly
sort of reset the state of the system.

657
00:40:39,416 --> 00:40:43,129
which might even mean turning the
actual network interface off and

658
00:40:43,129 --> 00:40:45,526
on at, specific, points in time.

659
00:40:45,870 --> 00:40:49,712
and so people ask like, what's
like the secret sauce of Ditto?

660
00:40:49,712 --> 00:40:52,082
And I, it's like, there's
not one thing actually.

661
00:40:52,082 --> 00:40:57,138
It's, a bunch of like good ideas, but
sort of layered on top of each other

662
00:40:57,138 --> 00:40:59,928
where each one like benefits the other.

663
00:41:00,018 --> 00:41:05,328
And so like the choice of CRDTs was
important because that opened the door

664
00:41:05,328 --> 00:41:11,019
to peer-to-peer, serverless, approach to
datas sync, which then, you know, meant

665
00:41:11,019 --> 00:41:16,065
we had to do other things to optimize,
the data transfer because we were working

666
00:41:16,065 --> 00:41:21,936
with Bluetooth and so we adopted, CRDTs,
where you can send just the differences.

667
00:41:22,230 --> 00:41:25,380
so versus like an
operations based approach.

668
00:41:25,633 --> 00:41:28,543
and so it's like that was a
decision that affected then

669
00:41:28,603 --> 00:41:30,343
subsequent aspects of the system.

670
00:41:30,898 --> 00:41:35,495
And so it's just a bunch of those smart
trade-offs, which is sort of the reason

671
00:41:35,495 --> 00:41:41,621
why I call out the experience of Realm
in seeing how then, these trade-offs, are

672
00:41:41,621 --> 00:41:48,831
really important both to implement this
solution, a system in the right technical

673
00:41:48,851 --> 00:41:53,674
way, but also to manage the constraints
as well with, business and, investors.

674
00:41:54,274 --> 00:41:54,574
Right.

675
00:41:54,574 --> 00:41:58,251
And just like you said that you
wouldn't have, believed 15 years ago,

676
00:41:58,431 --> 00:42:02,726
what this would lead you to today
were, you're like, being exposed to

677
00:42:02,816 --> 00:42:07,526
so many different devices, so many
different, like use case applications.

678
00:42:07,526 --> 00:42:09,566
You've mentioned the airline industry.

679
00:42:09,746 --> 00:42:14,576
You probably now see the world differently
where it's like, aha, I know there's

680
00:42:14,576 --> 00:42:18,416
a device and nobody knows about this
device, but this is critical and

681
00:42:18,416 --> 00:42:20,216
needs to talk to those other things.

682
00:42:20,579 --> 00:42:25,439
I'm curious, like when you build
all of this, like typically

683
00:42:25,439 --> 00:42:26,939
you don't get it right.

684
00:42:27,036 --> 00:42:29,426
like, it goes wrong, and
then you need to debug it.

685
00:42:29,696 --> 00:42:33,866
When you build a web app, when you
build a mobile app, you can at least

686
00:42:33,896 --> 00:42:38,266
like the road is like pretty well
paved, so you get like log messages.

687
00:42:38,266 --> 00:42:42,646
You might get things like distributed
traces, et cetera, metrics.

688
00:42:42,916 --> 00:42:46,606
But when you're talking to, like, when
you're talking about like literal physical

689
00:42:46,606 --> 00:42:52,666
devices where the network is part of the
problem, so you can't just like SSH into

690
00:42:52,666 --> 00:42:57,740
it, how do you even get debugging data
and visibility into what's going on?

691
00:42:58,325 --> 00:43:02,405
Yeah, it's a great question 'cause
I would say it's a topical problem

692
00:43:02,405 --> 00:43:06,360
that we're still, working through is
as we deploy Ditto into bigger use

693
00:43:06,360 --> 00:43:11,684
cases, it's become sort of the second
day problem of great that works, but

694
00:43:11,684 --> 00:43:13,254
how do you, know it really works?

695
00:43:13,254 --> 00:43:20,154
And the key value proposition of Edge
being able to do things at the edge is

696
00:43:20,154 --> 00:43:22,344
you can build more resilient software.

697
00:43:22,344 --> 00:43:26,990
And so the customers of Ditto are
businesses that have workers predominantly

698
00:43:26,990 --> 00:43:29,450
that are not at desks like us.

699
00:43:29,540 --> 00:43:31,550
They're out doing jobs in the real world.

700
00:43:31,880 --> 00:43:35,937
And so in the real world, the
internet is, by no means guaranteed.

701
00:43:36,207 --> 00:43:38,487
Cellular systems are unreliable.

702
00:43:38,541 --> 00:43:42,400
wifi systems are actually very
difficult to manage at scale.

703
00:43:42,850 --> 00:43:48,820
And so being able to use smart
software that leverages the network

704
00:43:49,030 --> 00:43:53,575
capabilities of the devices that workers
are already holding is compelling.

705
00:43:53,605 --> 00:43:57,795
'cause it kind of adds like another
layer of, durability, to ensure

706
00:43:57,795 --> 00:44:00,312
their, you know, their application,
their data, keeps working.

707
00:44:00,826 --> 00:44:06,136
But that means if the whole value
prop is to make the system more

708
00:44:06,136 --> 00:44:10,576
resilient, then Ditto itself
has to work really, really well.

709
00:44:10,606 --> 00:44:12,790
And so how do you, ensure that?

710
00:44:13,060 --> 00:44:15,760
And so we've, we've had
to build more of that out.

711
00:44:15,883 --> 00:44:17,503
and so it's sort of funny.

712
00:44:17,503 --> 00:44:20,085
There's, a, a feature we
call the Presence Viewer.

713
00:44:20,475 --> 00:44:26,671
It's simple js application, that just
shows all the nodes that are connected.

714
00:44:26,865 --> 00:44:31,165
because every time Ditto, you start it
up, there's a database interface, but

715
00:44:31,165 --> 00:44:36,025
behind the scenes it starts to take
over Bluetooth, wifi, peer-to-peer

716
00:44:36,025 --> 00:44:37,855
wifi interfaces on the device.

717
00:44:38,185 --> 00:44:40,930
And it creates what you would
say is an overlay network.

718
00:44:41,200 --> 00:44:45,160
And so the device itself will create
the links it can to other nearby

719
00:44:45,160 --> 00:44:50,350
devices, but the system itself learns
of the whole mesh because every

720
00:44:50,350 --> 00:44:55,996
device, shares, information actually
through CRDTs about it's presence.

721
00:44:55,996 --> 00:44:57,513
So like who it's connected to.

722
00:44:57,783 --> 00:44:59,673
And this eventually propagates around.

723
00:45:00,033 --> 00:45:03,783
And so we show this visually in
this super simple application.

724
00:45:03,813 --> 00:45:08,013
It's just, you know, a bunch of
nodes with colored lines showing

725
00:45:08,013 --> 00:45:09,033
the different connections.

726
00:45:09,476 --> 00:45:12,966
my co-founder built that, probably
2020, like it was just like a

727
00:45:12,966 --> 00:45:14,976
weekend project to throw together.

728
00:45:14,976 --> 00:45:18,816
But it ends up being like one of
the most crucial tools customers

729
00:45:18,816 --> 00:45:22,446
use because they're like, well,
how can I see what's going on?

730
00:45:22,776 --> 00:45:25,836
Because if data, like if they're
clicking their device and data

731
00:45:25,836 --> 00:45:29,803
isn't moving, I. The first thought
is like, am I even connected?

732
00:45:30,103 --> 00:45:35,140
And so, that was sort of the first
start in our realization that as

733
00:45:35,140 --> 00:45:39,610
great as the database itself needs to
be to handle application level data,

734
00:45:40,120 --> 00:45:44,350
to make this really worthwhile as a
developer platform, we have to provide

735
00:45:44,470 --> 00:45:46,838
observability capabilities as well.

736
00:45:46,977 --> 00:45:50,418
so that you can fix
issues when they arise.

737
00:45:50,828 --> 00:45:57,124
And so that includes now, almost like
the sort of morphing into like a mobile

738
00:45:57,124 --> 00:46:02,538
device management platform where when
you use our cloud service, you can

739
00:46:02,538 --> 00:46:06,738
observe, you know, the data in the
database, but you can also request

740
00:46:06,888 --> 00:46:13,518
from the web portal logs from specific
devices and they will transmit it up.

741
00:46:13,578 --> 00:46:15,888
And then you can, you
know, go through them.

742
00:46:16,128 --> 00:46:21,228
You can also see what are the settings and
the configuration of the SDK remotely and

743
00:46:21,228 --> 00:46:26,658
even, like issue commands down to change
stuff so that an administrator could

744
00:46:26,658 --> 00:46:28,418
say, Hey, I don't know what's going on.

745
00:46:28,418 --> 00:46:30,758
Let me turn Bluetooth off on a device.

746
00:46:30,938 --> 00:46:32,138
You can do that remotely.

747
00:46:32,438 --> 00:46:37,268
And so those were definitely not our
initial features that we were thinking

748
00:46:37,268 --> 00:46:42,354
about, but have come out of, ourselves
having to debug this alongside our

749
00:46:42,354 --> 00:46:47,094
customers of like, yeah, this is a totally
different way of building applications

750
00:46:47,754 --> 00:46:49,614
that doesn't rely on a server.

751
00:46:49,884 --> 00:46:53,568
And so you gotta have some way to
actually go and get the, information

752
00:46:53,568 --> 00:46:56,492
on these devices to figure out
what's going wrong there's a bug.

753
00:46:57,077 --> 00:46:57,917
That makes sense.

754
00:46:58,037 --> 00:47:01,427
So in terms of platforms that you're
targeting, we've been talking a lot

755
00:47:01,427 --> 00:47:03,287
about mobile devices at this point.

756
00:47:03,497 --> 00:47:07,427
Is this sort of the majority
of deployed applications or are

757
00:47:07,427 --> 00:47:09,143
there other notable platforms?

758
00:47:09,600 --> 00:47:13,933
Yeah, so all the core of Ditto, I mean,
of all the different bets we made, one

759
00:47:13,933 --> 00:47:16,213
of the technical bet was betting on Rust.

760
00:47:16,316 --> 00:47:20,043
the 2018 was I guess, sort of
a bet at that point in time.

761
00:47:20,523 --> 00:47:25,970
Now doesn't seem as as crazy, but,
we picked that, for a couple reasons.

762
00:47:25,970 --> 00:47:28,550
One is, you know, we wanted
to build something that could

763
00:47:28,550 --> 00:47:32,970
work across different hardware
platforms and so Realm was in C++.

764
00:47:33,420 --> 00:47:37,490
So in a lot of ways, you know,
all of the Rust benefits as a

765
00:47:37,490 --> 00:47:40,153
language felt like a, better choice.

766
00:47:40,483 --> 00:47:42,223
But the other piece of it was.

767
00:47:42,496 --> 00:47:47,350
an annoyance that Realm at the time,
which may maybe now would be more

768
00:47:47,350 --> 00:47:52,100
possible with WebAssembly, but, at
the time they never could implement

769
00:47:52,270 --> 00:47:54,370
the mobile database in the browser.

770
00:47:54,730 --> 00:47:57,820
And so we were like,
ah, let's not do that.

771
00:47:57,820 --> 00:48:02,290
Let's build this in one common code
base and compile it to WebAssembly.

772
00:48:02,590 --> 00:48:07,873
And at the time, you know, Rust really
was the language that given its history,

773
00:48:07,921 --> 00:48:09,500
was closely tied with WebAssembly.

774
00:48:09,500 --> 00:48:12,633
And so, you know, Ditto itself is
a Rust shop, and so all the core

775
00:48:12,633 --> 00:48:16,836
of the code base is in Rust and we
compile it for different platforms.

776
00:48:16,836 --> 00:48:22,013
And then similar to Realm provide,
a language specific wrapper around,

777
00:48:22,372 --> 00:48:24,186
the Rust Code through the FFI.

778
00:48:24,516 --> 00:48:28,066
And so, our customers though
right now predominantly use

779
00:48:28,066 --> 00:48:29,596
just the mobile versions.

780
00:48:29,626 --> 00:48:34,556
So, swift, Kotlin, flutter, which,
you know, we've recently added,

781
00:48:34,670 --> 00:48:39,610
in and React native, but you can
also run in embedded scenarios.

782
00:48:39,823 --> 00:48:43,923
so like C# and the JS version of Ditto.

783
00:48:44,096 --> 00:48:48,116
You can also run on a Raspberry Pi or
you know, more IoT kind of scenarios.

784
00:48:48,386 --> 00:48:52,003
It just hasn't been as much of a
focus, from a business standpoint.

785
00:48:52,003 --> 00:48:56,155
So those are more nascently used,
compared to the, mobile versions.

786
00:48:56,455 --> 00:49:00,145
So going very hand in hand with
the deployed platforms, you've been

787
00:49:00,145 --> 00:49:02,785
mentioning the airline use case before.

788
00:49:03,055 --> 00:49:07,675
Is this your most dominant use case or
which kind of use cases do you see most

789
00:49:07,675 --> 00:49:10,015
application for Ditto at this point.

790
00:49:10,960 --> 00:49:12,820
It's where we got
started was the airlines.

791
00:49:12,820 --> 00:49:17,200
So, you know, I mentioned kind of
that sort of regret feeling, when

792
00:49:17,200 --> 00:49:21,670
Ditto was started of not feeling
like Realm really, was as successful

793
00:49:21,670 --> 00:49:22,930
as, I believed it could be.

794
00:49:23,290 --> 00:49:28,760
And so that, that led to, my background
both engineering, both product.

795
00:49:28,760 --> 00:49:33,667
And so in the early days when it
was myself and Max in 2018, I told

796
00:49:33,667 --> 00:49:37,477
him, I was like, Hey, if we can't
get someone to wanna buy this, like,

797
00:49:37,867 --> 00:49:42,337
I don't want to waste more of my
like, prime professional career, like

798
00:49:42,337 --> 00:49:44,287
hoping this thing will be successful.

799
00:49:44,317 --> 00:49:46,957
'cause I don't want it to end
up where it sort of fizzles out.

800
00:49:47,197 --> 00:49:50,870
And that honestly is my, like, number
one advice I would say in like the

801
00:49:50,870 --> 00:49:54,553
local-first effort   the part that
makes me most proud is something

802
00:49:54,553 --> 00:49:56,863
that like, could be long lasting.

803
00:49:57,083 --> 00:49:59,503
just like, how can I leave
my mark on the world and.

804
00:50:00,178 --> 00:50:01,378
My talent is in software.

805
00:50:01,378 --> 00:50:05,158
So like, how could I build something
that could have a really long impact?

806
00:50:05,698 --> 00:50:09,268
And so to do that as a business means
you gotta actually like, make money.

807
00:50:09,268 --> 00:50:13,396
And so in the early years,
I was like, let's start

808
00:50:13,426 --> 00:50:15,046
prototyping, building this out.

809
00:50:15,161 --> 00:50:19,781
let's just reach out to anyone who
might have any interest in sort of

810
00:50:19,811 --> 00:50:21,851
any aspect of the benefits of this.

811
00:50:22,121 --> 00:50:26,771
And so we were looking at like all
different to like, use cases of

812
00:50:26,831 --> 00:50:28,841
where this, platform could apply.

813
00:50:28,901 --> 00:50:32,471
And coincidentally, I had
like a family connection to

814
00:50:32,471 --> 00:50:34,091
one of the major US airlines.

815
00:50:34,158 --> 00:50:39,138
so sent this email to, it was a
fairly high up individual and he was

816
00:50:39,288 --> 00:50:40,708
like, well, I don't know who this is.

817
00:50:41,168 --> 00:50:45,524
so he basically pushed it down
to, an intern, and was like, Hey,

818
00:50:45,524 --> 00:50:46,904
take a call with these two guys.

819
00:50:46,904 --> 00:50:48,194
Like maybe there's something here.

820
00:50:48,659 --> 00:50:50,489
It's a fantastic story.

821
00:50:50,519 --> 00:50:54,389
'cause we, we put this pitch deck together
and we were like, we're building Ditto.

822
00:50:54,389 --> 00:50:58,169
And it's the CRDT database and it's
got all these amazing capabilities.

823
00:50:58,169 --> 00:51:02,249
And she was totally bored by
like 80% of the presentation.

824
00:51:02,639 --> 00:51:05,639
And then at the end, because we
had mentioned peer to peer, she

825
00:51:05,639 --> 00:51:09,139
was like, well, could it connect
like just two devices together?

826
00:51:09,409 --> 00:51:11,599
And we're like, yeah, yeah,
they can totally do that.

827
00:51:11,629 --> 00:51:12,739
Which was not true.

828
00:51:12,739 --> 00:51:14,749
Like, and actually do that at the time.

829
00:51:15,139 --> 00:51:15,889
Theoretically.

830
00:51:15,889 --> 00:51:16,279
Yes.

831
00:51:16,279 --> 00:51:16,966
It, could.

832
00:51:17,313 --> 00:51:18,723
and she was like, well that's amazing.

833
00:51:18,723 --> 00:51:19,863
Like, we need that.

834
00:51:19,863 --> 00:51:23,673
Like, that will be amazing for our
flight attendants when they're in planes.

835
00:51:23,733 --> 00:51:27,663
They could share information without
having to rely on the wifi of the plane.

836
00:51:28,053 --> 00:51:29,916
And so they're like, come
to our headquarters, like,

837
00:51:29,916 --> 00:51:31,456
we wanna see a demo of this.

838
00:51:31,816 --> 00:51:32,756
And so we.

839
00:51:33,676 --> 00:51:38,496
We're like, oh, well our schedule's
looking really busy the next several

840
00:51:38,496 --> 00:51:41,616
weeks, so like, we're, we're gonna need
to like plan this like a month later.

841
00:51:41,959 --> 00:51:46,783
and ultimately then we feverishly went
and, you know, got the peer-to-peer aspect

842
00:51:46,843 --> 00:51:52,426
working, as I mentioned with like the
Bluetooth and stuff, but it barely worked.

843
00:51:52,539 --> 00:51:56,439
but what was really cool about that is
like, we were at their headquarters and

844
00:51:56,439 --> 00:52:02,256
we were put in this like, nondescript
room and, the woman came in, the intern,

845
00:52:02,349 --> 00:52:04,659
and a couple other folks and they
were like, wow, this is really cool.

846
00:52:04,839 --> 00:52:07,149
Like, sit here, we're
gonna go get some people.

847
00:52:07,539 --> 00:52:08,739
And they just left.

848
00:52:08,769 --> 00:52:11,169
And we were just sitting there
for like 30 minutes thinking

849
00:52:11,169 --> 00:52:13,149
like, what is going on here?

850
00:52:13,209 --> 00:52:14,799
And then lo and behold, like.

851
00:52:15,159 --> 00:52:19,059
The more senior executives of the company
come marching into this conference room

852
00:52:19,449 --> 00:52:22,299
and they were like, let me see this.

853
00:52:22,579 --> 00:52:25,599
And everyone started poking
all the phones that we had.

854
00:52:25,599 --> 00:52:29,866
We had this very simple app that you
could, change the inventory values and

855
00:52:29,866 --> 00:52:33,826
it wasn't even working, like phones
were crashing and there was this one

856
00:52:33,826 --> 00:52:35,566
woman being like, that one crashed.

857
00:52:35,566 --> 00:52:36,376
That one crashed.

858
00:52:37,066 --> 00:52:39,766
But the whole time everyone
was like, this is amazing.

859
00:52:40,073 --> 00:52:42,503
like, I didn't think this was possible.

860
00:52:42,803 --> 00:52:47,663
And so that was sort of the
genesis of knowing that there was

861
00:52:47,663 --> 00:52:49,839
real customer demand for this.

862
00:52:50,409 --> 00:52:51,879
we obviously had to get it to work.

863
00:52:52,293 --> 00:52:56,313
but that's where we ended up
saying, okay, let's build a company.

864
00:52:56,409 --> 00:52:57,549
let's go raise some money.

865
00:52:57,713 --> 00:53:01,463
was after that and ultimately
led to selling to the airlines

866
00:53:01,553 --> 00:53:03,649
as, as original customers.

867
00:53:03,649 --> 00:53:09,473
And so Delta, Alaska Airlines,
Lufthansa, Japan Airlines, ANA, like

868
00:53:09,473 --> 00:53:13,523
major airlines around the world have
adopted Ditto in that same use case

869
00:53:13,733 --> 00:53:18,203
where they have installed it as part
of the mobile app that their flight

870
00:53:18,203 --> 00:53:20,553
attendants predominantly, are using.

871
00:53:20,673 --> 00:53:23,973
And so in a lot of ways, it's
actually kind of like a CRM app.

872
00:53:24,166 --> 00:53:28,186
this is an app that, you know, they have
to log into to start their job, which

873
00:53:28,186 --> 00:53:32,386
is, you know, like their hours worked
start when they, when the, you know, the

874
00:53:32,386 --> 00:53:37,989
plane is, is getting ready and it's how
they, it's like their slack, for them.

875
00:53:38,079 --> 00:53:42,099
It's where everything they need to do,
it's all the passenger information, it's

876
00:53:42,099 --> 00:53:44,259
meals that are loaded onto the plane.

877
00:53:44,589 --> 00:53:47,389
It might have safety issues and things.

878
00:53:47,429 --> 00:53:50,139
And so it's just their
lifeline to their job.

879
00:53:51,204 --> 00:53:56,634
But previous to Ditto, those apps
were effectively single player games.

880
00:53:56,904 --> 00:54:01,554
Like they would download the initial data
locally and then they would go into the

881
00:54:01,554 --> 00:54:05,064
plane and they could not actually share.

882
00:54:05,394 --> 00:54:09,504
And so they would make notes for
themselves, but it was all private.

883
00:54:09,804 --> 00:54:14,694
And so with Ditto, suddenly now, like
they have what we take for granted

884
00:54:14,724 --> 00:54:18,594
with a lot of the software we use at
desk base, which it's collaborative.

885
00:54:18,904 --> 00:54:21,841
And so, you know, they could message
each other and you know, do other

886
00:54:21,841 --> 00:54:26,361
things that ultimately mean that they
could do their jobs, more efficiently.

887
00:54:26,701 --> 00:54:30,758
And so this, is still a major use
case for us, but you know, since then

888
00:54:30,818 --> 00:54:32,378
we've expanded into other things.

889
00:54:32,378 --> 00:54:34,538
But yeah, it was sort of a weird.

890
00:54:35,184 --> 00:54:37,104
vertical to start with.

891
00:54:37,134 --> 00:54:40,374
Given that like a year and a half
into starting the company, we had

892
00:54:40,374 --> 00:54:44,588
the pandemic and the airline industry
was, heavily affected by that.

893
00:54:44,811 --> 00:54:47,418
but, yeah, it's, it, we were
able to weather through that.

894
00:54:47,418 --> 00:54:48,028
Thankfully.

895
00:54:48,523 --> 00:54:50,383
That is an incredible story.

896
00:54:50,383 --> 00:54:54,733
And just like, as a little random side
note here, if you're looking at your

897
00:54:54,763 --> 00:55:00,223
LinkedIn history, it also mentions, I,
suppose, in between some of your work

898
00:55:00,223 --> 00:55:05,323
chapters, you've been also helping out
the TV show, Silicon Valley, and the story

899
00:55:05,323 --> 00:55:09,253
you've just presented about you, like
walking into the airline and presenting

900
00:55:09,253 --> 00:55:14,003
those in front of the senior executives,
that, like my mind immediately went to

901
00:55:14,003 --> 00:55:16,913
sort of like a scene from Silicon Valley.

902
00:55:16,913 --> 00:55:20,179
So this is, like coming
full circle in so many ways.

903
00:55:20,179 --> 00:55:21,169
That is incredible.

904
00:55:21,829 --> 00:55:26,359
Well, there is some similarities to
the storyline that the individual who

905
00:55:26,359 --> 00:55:30,889
hired me at Realm was, ended up, him and
another friend of his were involved in

906
00:55:30,889 --> 00:55:33,376
kind of more directly in, the writing.

907
00:55:33,406 --> 00:55:34,216
And so he.

908
00:55:34,571 --> 00:55:37,841
He asked me in like the third or fourth
season, I forget at this point, which

909
00:55:37,841 --> 00:55:41,544
one it was, to be a technical advisor,
which meant just making sure like

910
00:55:41,591 --> 00:55:45,641
the software code on the whiteboards
and screens was semi accurate.

911
00:55:45,961 --> 00:55:50,148
so it was, fun, but it was, is it
ironic because I look at that show

912
00:55:50,148 --> 00:55:52,818
and there are definitely aspects
of, especially the new internet

913
00:55:53,178 --> 00:55:56,538
that like, is definitely not like.

914
00:55:57,093 --> 00:55:59,253
Like totally disconnected from Realm.

915
00:55:59,253 --> 00:56:02,166
Like there were times where we
said that internally at Realm, and

916
00:56:02,166 --> 00:56:05,526
even to this day, like Ditto is
sort of a manifestation of that.

917
00:56:05,526 --> 00:56:07,356
So that's, it's not by accident.

918
00:56:08,616 --> 00:56:09,157
There was, there was some connect.

919
00:56:09,157 --> 00:56:12,456
Well, if you ever have to rebrand to
Piper, we know where it's coming from.

920
00:56:12,786 --> 00:56:13,356
Exactly.

921
00:56:13,356 --> 00:56:13,416
Yeah.

922
00:56:14,826 --> 00:56:19,116
So, well, I have so many more
questions about Ditto, but I think

923
00:56:19,129 --> 00:56:23,029
we need to like split this up into
a future episode at some point.

924
00:56:23,299 --> 00:56:27,166
And, also you will be giving a
talk at Local-First Conf where

925
00:56:27,166 --> 00:56:28,726
I think we'll hear a lot more.

926
00:56:29,106 --> 00:56:34,506
I wanna just put the focus for a few more
minutes on Ditto as a platform that I

927
00:56:34,506 --> 00:56:39,276
just get a better feeling for like what it
would mean to build something with Ditto

928
00:56:39,276 --> 00:56:41,286
since when I'm looking at the website.

929
00:56:41,286 --> 00:56:42,636
Beautiful website by the way.

930
00:56:42,973 --> 00:56:47,323
When I'm looking at the website,
there's kind of two sync approaches.

931
00:56:47,323 --> 00:56:49,963
One is device sync and
one is peer-to-peer sync.

932
00:56:50,236 --> 00:56:53,676
can you delineate those a
little bit more and maybe anchor

933
00:56:53,676 --> 00:56:55,776
them in canonical use cases?

934
00:56:56,403 --> 00:57:01,113
Yeah, so in a lot of ways, like Ditto
is no different than Firebase or Realm.

935
00:57:01,173 --> 00:57:06,920
Um, like any sort of, embedded database
synchronization, like we have SDKs,

936
00:57:07,013 --> 00:57:10,223
that are an embedded document database.

937
00:57:10,527 --> 00:57:13,917
unlike Realm, like one of the
trade-offs we did was we leveraged

938
00:57:13,917 --> 00:57:15,237
an existing storage engine.

939
00:57:15,237 --> 00:57:19,157
So at at the end of the day, we're just
storing data in a SQLite database on disk.

940
00:57:19,157 --> 00:57:24,827
But we designed the API to be a document
database so that you don't have to, at the

941
00:57:24,827 --> 00:57:29,717
database level manage schemas, which in
our experience with Realm, which was very

942
00:57:29,717 --> 00:57:34,140
strict with schemas became challenging
working across, teams that have like.

943
00:57:34,515 --> 00:57:38,085
Different iOS and Android teams,
like sometimes big companies, they

944
00:57:38,085 --> 00:57:39,375
don't really coordinate as well.

945
00:57:39,645 --> 00:57:43,845
And so like Realm ended up being
this like odd thing that forced

946
00:57:43,845 --> 00:57:46,145
coordination, amongst teams.

947
00:57:46,205 --> 00:57:50,285
And so we thought, hey, schemaless
document API would, be easier.

948
00:57:50,645 --> 00:57:54,725
And so if you try it out as a developer,
you would see, hey, this looks a lot

949
00:57:54,785 --> 00:57:56,825
like in a lot of ways like Firebase.

950
00:57:56,929 --> 00:58:00,049
and so you read and write data
locally, and then behind the

951
00:58:00,049 --> 00:58:01,999
scenes we replicate that data.

952
00:58:02,419 --> 00:58:05,299
'cause at the end of the day,
data stored as CRDTs and we

953
00:58:05,299 --> 00:58:06,589
replicate it to other nodes.

954
00:58:07,069 --> 00:58:13,279
And so the device sync system is
basically the exact parallel to any

955
00:58:13,279 --> 00:58:15,379
server based synchronization system.

956
00:58:15,649 --> 00:58:20,425
There is another version of Ditto, the
server which we run as a cloud service

957
00:58:20,695 --> 00:58:22,435
that syncs data through the server.

958
00:58:22,525 --> 00:58:22,855
And so.

959
00:58:23,635 --> 00:58:25,975
That's not particularly super novel.

960
00:58:25,993 --> 00:58:29,435
I guess some of the CRDTs and things
that we do with it, you know, has,

961
00:58:29,476 --> 00:58:33,849
benefits in terms of scale, but,
the aspect that is Ditto is known

962
00:58:33,849 --> 00:58:36,729
for is that data can also move.

963
00:58:36,819 --> 00:58:37,239
You could say like.

964
00:58:37,914 --> 00:58:40,644
Vertically is to the cloud horizontally.

965
00:58:40,794 --> 00:58:44,794
And so that's where devices, when
you're using it in the peer-to-peer

966
00:58:44,794 --> 00:58:49,564
mode will connect through other
transports to nearby devices.

967
00:58:49,804 --> 00:58:53,020
So in a mobile device that's, you
know, Bluetooth like I was talking

968
00:58:53,020 --> 00:58:58,210
about, or peer-to-peer wifi, or the
wifi infrastructure itself, it actually

969
00:58:58,210 --> 00:59:02,710
can use other radio networks as well
if you're in device, if you are in a

970
00:59:02,710 --> 00:59:05,620
device that has some other custom radio.

971
00:59:05,903 --> 00:59:09,713
and so we encounter that with some
use cases where like a, a radio is

972
00:59:09,713 --> 00:59:14,920
plugged into the USB port of a mobile
device, or in like an embedded scenario.

973
00:59:15,580 --> 00:59:18,250
And that's where all the smarts are.

974
00:59:18,306 --> 00:59:23,316
to your point on the networking side
where we build this overlay network and

975
00:59:23,316 --> 00:59:26,516
devices can sync data, peer-to-peer.

976
00:59:26,936 --> 00:59:30,266
And so all of that, again,
is, driven by the fact that.

977
00:59:30,566 --> 00:59:35,033
There's these, diff based CRDTs
that are being transmitted around

978
00:59:35,123 --> 00:59:37,343
in a causally consistent manner.

979
00:59:37,753 --> 00:59:42,733
and similarly to Firebase or,
you know, other sync engine

980
00:59:42,733 --> 00:59:45,073
approaches, it's all query based.

981
00:59:45,253 --> 00:59:49,633
So what data you want is still
defined by queries on the database.

982
00:59:49,843 --> 00:59:54,826
And so if you're, you know, building
an application, you know, for like, the

983
00:59:54,826 --> 00:59:59,046
airline, you might have a query that
say, I need data for flight 1, 2, 3.

984
00:59:59,736 --> 01:00:03,126
You subscribe to that query, which will.

985
01:00:03,616 --> 01:00:07,206
Give you a callback to let you
know whenever data changes the

986
01:00:07,206 --> 01:00:08,916
database that matches that.

987
01:00:09,276 --> 01:00:15,336
But that query is then transmitted to the
other nodes, both to the cloud and peer

988
01:00:15,336 --> 01:00:21,486
to peer, and all the other nodes will
continue to evaluate that query, with data

989
01:00:21,486 --> 01:00:23,766
that they have locally and push it to you.

990
01:00:24,156 --> 01:00:27,603
And so, that will happen again,
you know, over Bluetooth.

991
01:00:27,943 --> 01:00:32,400
if a nearby device generates data, like
a flight attendant adding a message,

992
01:00:32,630 --> 01:00:37,090
for, for a given flight, it'll get out
to all the other devices, regardless

993
01:00:37,150 --> 01:00:38,710
of connectivity with the cloud.

994
01:00:39,270 --> 01:00:44,370
and so that's where we've tried to
make Ditto feel familiar in the way

995
01:00:44,370 --> 01:00:50,030
that people have experienced sync,
systems before, from client devices to

996
01:00:50,030 --> 01:00:55,940
the server or cloud, and basically try
to make that just map identically to

997
01:00:55,970 --> 01:00:57,950
that working in a peer-to-peer manner.

998
01:00:58,526 --> 01:00:59,816
That makes a lot of sense.

999
01:00:59,876 --> 01:01:05,980
And, just as a funny side note, I'm,
I must imagine that when thinking

1000
01:01:05,980 --> 01:01:11,283
so much about the, airspace use case
with flight attendants, et cetera, and

1001
01:01:11,523 --> 01:01:15,693
devices talking to each other and like
that you don't have connectivity to

1002
01:01:15,693 --> 01:01:17,803
the cloud yet you are in the clouds.

1003
01:01:17,833 --> 01:01:21,373
It's probably a funny situation.

1004
01:01:21,783 --> 01:01:26,673
So, Adam, there's so many more questions
that I would love to ask and I will

1005
01:01:26,673 --> 01:01:28,413
ask them at some point, but I think.

1006
01:01:28,688 --> 01:01:32,085
That for that we'll have to bring
you back to a second episode.

1007
01:01:32,411 --> 01:01:35,771
I wanna say thank you for
sharing all of this with us.

1008
01:01:36,031 --> 01:01:40,621
this has been incredibly insightful,
super entertaining, all of like those

1009
01:01:40,621 --> 01:01:46,621
anecdotes that you've like experienced and
gathered over like 15 years at this point.

1010
01:01:46,681 --> 01:01:47,851
Really impressive.

1011
01:01:47,851 --> 01:01:48,721
Really impressive.

1012
01:01:48,721 --> 01:01:54,308
Like how far you've brought Ditto from
the early beginnings, you and Max to now.

1013
01:01:54,308 --> 01:01:59,288
Like, there's probably most like
airlines are probably on a way to using

1014
01:01:59,288 --> 01:02:04,988
Ditto at this point and probably many
daily experiences that I, that I have.

1015
01:02:05,198 --> 01:02:07,808
You mentioned point of sales
in a previous conversation.

1016
01:02:08,368 --> 01:02:09,548
Super impressive.

1017
01:02:09,548 --> 01:02:11,528
Thank you for sharing all of this with us.

1018
01:02:12,198 --> 01:02:12,678
Thank you.

1019
01:02:12,738 --> 01:02:15,315
Yeah, I'm really looking
forward to the conference, and

1020
01:02:15,315 --> 01:02:17,315
sharing more about the journey.

1021
01:02:17,315 --> 01:02:21,384
'cause yeah, like I said, this is
something I 'm very passionate about

1022
01:02:21,408 --> 01:02:25,785
and like, excited to be, you know, with
others in the community and to the degree

1023
01:02:25,785 --> 01:02:29,095
that Ditto can inspire others, you know,
that, that makes me really excited.

1024
01:02:29,125 --> 01:02:32,901
'cause like I said, this is, this
is all driven by that early desire

1025
01:02:32,901 --> 01:02:35,001
of wanting this tool as a developer.

1026
01:02:35,061 --> 01:02:39,408
And so, I'm hopeful that we can
continue to push like the application

1027
01:02:39,408 --> 01:02:41,178
development kind of standards forward.

1028
01:02:41,208 --> 01:02:45,615
So that local-first is, more just
the default scenario to building,

1029
01:02:45,666 --> 01:02:49,938
client applications versus
this, you know, historical RPC,

1030
01:02:50,040 --> 01:02:51,205
you know, client server model.

1031
01:02:51,205 --> 01:02:55,108
So anyway, I appreciate having me and
I'm, you know, happy to, find feature

1032
01:02:55,108 --> 01:02:56,488
time to continue to tell the story.

1033
01:02:56,908 --> 01:02:57,358
Awesome.

1034
01:02:57,358 --> 01:02:58,168
Thank you so much.

1035
01:02:58,828 --> 01:02:59,038
Thank you.

1036
01:02:59,551 --> 01:03:02,131
Thank you for listening to
the localfirst.fm podcast.

1037
01:03:02,311 --> 01:03:05,401
If you've enjoyed this episode and
haven't done so already, please

1038
01:03:05,401 --> 01:03:06,691
subscribe and leave a review.

1039
01:03:07,081 --> 01:03:09,601
Please also share this episode
with your friends and colleagues.

1040
01:03:09,991 --> 01:03:12,991
Spreading the word about the
podcast is a great way to support

1041
01:03:12,991 --> 01:03:14,701
it and to help me keep it going.

1042
01:03:15,361 --> 01:03:18,781
A special thanks again to Jazz
for supporting this podcast.

1043
01:03:19,081 --> 01:03:20,041
I'll see you next time.