1
00:00:00,000 --> 00:00:05,860
if we build a world where it is very
compelling and straightforward for

2
00:00:05,870 --> 00:00:11,380
people to start building in peer to peer
communications into their apps, we really

3
00:00:11,380 --> 00:00:15,390
start challenging the question of Why did
you need the cloud in the first place?

4
00:00:15,640 --> 00:00:20,110
For most things, you didn't need the
cloud except that you did not have a way

5
00:00:20,120 --> 00:00:22,560
for two clients to speak to each other.

6
00:00:23,080 --> 00:00:26,609
But if we get rid of that,
then you stop needing to pay

7
00:00:26,610 --> 00:00:28,440
for most of your cloud bill.

8
00:00:28,720 --> 00:00:32,750
And that is one of the largest
overheads that companies face these

9
00:00:32,750 --> 00:00:35,220
days, and they're increasing in cost.

10
00:00:36,425 --> 00:00:38,535
Welcome to the local-first FM podcast.

11
00:00:38,855 --> 00:00:41,645
I'm your host, Johannes Schickling,
and I'm a web developer, a

12
00:00:41,645 --> 00:00:44,725
startup founder, and love the
craft of software engineering.

13
00:00:45,175 --> 00:00:49,005
For the past few years, I've been on a
journey to build a modern, high quality

14
00:00:49,005 --> 00:00:50,975
music app using web technologies.

15
00:00:51,395 --> 00:00:55,295
And in doing so, I've been falling down
the rabbit hole of local-first software.

16
00:00:55,835 --> 00:00:58,835
This podcast is your invitation
to join me on that journey.

17
00:00:59,645 --> 00:01:01,935
In this episode, I'm
speaking to Kyle Simpson.

18
00:01:02,340 --> 00:01:06,780
A prolific JavaScript engineer and
author of the book, You Don't Know JS.

19
00:01:07,550 --> 00:01:12,120
Over the past years, Kyle has been
researching user identity and encryption

20
00:01:12,160 --> 00:01:16,090
in a local-first context, which we
explore in depth in this episode.

21
00:01:16,630 --> 00:01:20,940
We start the conversation with a story
that led Kyle to local-first, including

22
00:01:20,950 --> 00:01:24,220
what he calls web 2.5 and zero servers.

23
00:01:24,920 --> 00:01:29,300
Before getting started, also a big
thank you to Rosicorp and PowerSync

24
00:01:29,300 --> 00:01:30,650
for supporting this podcast.

25
00:01:31,040 --> 00:01:32,720
And now my interview with Kyle.

26
00:01:34,007 --> 00:01:36,077
Hey Kyle, so nice to have you on the show.

27
00:01:36,097 --> 00:01:36,707
How are you doing?

28
00:01:37,312 --> 00:01:37,932
I'm great.

29
00:01:37,942 --> 00:01:38,642
Thanks for having me.

30
00:01:38,642 --> 00:01:39,602
I'm thrilled to be here.

31
00:01:40,412 --> 00:01:43,952
You've been digging into some
aspects and some corners of the

32
00:01:43,952 --> 00:01:49,142
local-first ecosystem that I think
not as many have yet really dug in

33
00:01:49,142 --> 00:01:52,982
so deeply, namely around local-first
identity, encryption, et cetera.

34
00:01:52,982 --> 00:01:57,442
So I'm really excited to get into
that, but, not to get ahead of myself.

35
00:01:57,442 --> 00:02:00,879
Maybe you want to briefly introduce
yourself, give a bit of background

36
00:02:01,279 --> 00:02:04,709
and, maybe share how we, how we
get to talk about this today.

37
00:02:05,229 --> 00:02:05,599
Yeah.

38
00:02:05,959 --> 00:02:07,179
my name's Kyle Simpson.

39
00:02:07,249 --> 00:02:10,869
Most people online, and especially
in the web and JavaScript

40
00:02:10,889 --> 00:02:12,619
community, will know me by Getify.

41
00:02:12,784 --> 00:02:17,497
I've been around for a very long time
now, and, probably some of the biggest

42
00:02:17,497 --> 00:02:22,227
things that I'm known for is having
written the You Don't Know JS books.

43
00:02:22,303 --> 00:02:25,577
the first edition came out in 2014, 2015.

44
00:02:25,857 --> 00:02:27,977
That's a series of six
books about JavaScript.

45
00:02:28,097 --> 00:02:31,797
And then I did a second edition,
some of those books that we wrote

46
00:02:31,797 --> 00:02:34,280
in a second edition,  around 2020.

47
00:02:34,604 --> 00:02:36,034
so that's how most people know me.

48
00:02:36,034 --> 00:02:39,564
I've done a lot of teaching, a lot
of conference speaking in the web and

49
00:02:39,564 --> 00:02:44,654
JavaScript space, and kind of tried
to promote the web as a platform.

50
00:02:44,654 --> 00:02:47,984
And JavaScript is a key
piece of that platform.

51
00:02:48,220 --> 00:02:52,879
Specifically with local-first, my
interest, I arrive at local-first

52
00:02:52,899 --> 00:02:57,315
kind of almost accidentally because
I was working on things that

53
00:02:57,325 --> 00:02:58,985
I thought we needed to create.

54
00:02:58,985 --> 00:03:01,245
And I didn't know that there was
anybody else that had come up

55
00:03:01,245 --> 00:03:03,342
with terms or pioneering this.

56
00:03:03,342 --> 00:03:07,312
So I sort of separately was
trying to invent something not

57
00:03:07,312 --> 00:03:08,962
that dissimilar from local-first.

58
00:03:08,982 --> 00:03:12,592
And I had a series of like specs that
I was going to try to write around

59
00:03:12,592 --> 00:03:18,852
it, but that comes from a passion for
why we need to own our identity, as

60
00:03:18,852 --> 00:03:23,642
opposed to offloading that to GitHub,
or Google, or Microsoft, or whatever.

61
00:03:23,642 --> 00:03:24,542
We need to own that.

62
00:03:24,542 --> 00:03:28,932
We need to own the control of
the data that we create, and the

63
00:03:28,932 --> 00:03:32,252
data that is created about us,
to whatever extent is possible.

64
00:03:32,682 --> 00:03:36,462
And so that kind of got me interested
in this space, this particular

65
00:03:36,462 --> 00:03:41,172
usage of the web platform, and
of JavaScript as a technology.

66
00:03:41,512 --> 00:03:45,232
I found the local-first space
through some employment, and then

67
00:03:45,242 --> 00:03:47,262
started getting involved in that.

68
00:03:47,362 --> 00:03:51,659
community, the meetup that runs
on the discord and all of that.

69
00:03:51,659 --> 00:03:53,489
Met Jans who runs that.

70
00:03:53,829 --> 00:03:57,359
And so that's what brings us to today is
that my passion kind of started over the

71
00:03:57,359 --> 00:04:01,765
last three to five years, really trying
to leverage what I've been able to do

72
00:04:01,765 --> 00:04:06,990
and what we can do with this platform
for the good of moving the web forward, I

73
00:04:06,990 --> 00:04:10,033
believe, back to us owning our identity.

74
00:04:10,320 --> 00:04:10,820
Awesome.

75
00:04:10,830 --> 00:04:11,050
Yeah.

76
00:04:11,050 --> 00:04:14,540
You've mentioned that I think
you had now two opportunities to,

77
00:04:14,836 --> 00:04:18,466
see a couple of like different
products in the local-first space.

78
00:04:18,496 --> 00:04:23,203
I think one of them would be Socket
Supply, which is, exploring peer to peer

79
00:04:23,203 --> 00:04:25,043
software, which is really interesting.

80
00:04:25,333 --> 00:04:28,303
And then also the AI startup, Vella.

81
00:04:28,561 --> 00:04:32,771
I'd be interested in hearing a little
bit more what motivated your move

82
00:04:32,771 --> 00:04:38,501
to work at Socket Supply, like given
the focus on peer to peer, maybe

83
00:04:38,501 --> 00:04:40,171
there's an interesting backstory here.

84
00:04:40,826 --> 00:04:44,136
Yeah, there is a little bit
of, it's a winding road, right?

85
00:04:44,136 --> 00:04:45,416
There's not a straight line path.

86
00:04:45,763 --> 00:04:50,873
so going back several years when I was
starting to get interested in this, I

87
00:04:51,303 --> 00:04:54,493
was looking for a job at the time because
I had gone through some layoffs and

88
00:04:54,493 --> 00:04:56,133
I'd been unemployed for a little while.

89
00:04:56,443 --> 00:05:00,713
And the company that ended up,
interviewing me, they reached out to me.

90
00:05:01,218 --> 00:05:04,478
interviewed me and then heavily
recruited me, was actually a

91
00:05:04,478 --> 00:05:06,468
Web3 company, a crypto company.

92
00:05:06,718 --> 00:05:10,908
Now I'd known about the Web3 crypto
space for a while, had felt like most of

93
00:05:10,908 --> 00:05:15,548
it was not something that I would super
get behind and endorse, especially the

94
00:05:15,548 --> 00:05:19,348
currency side and all the, you know,
the speculative financial instruments

95
00:05:19,358 --> 00:05:21,228
and all of that, not something I'm into.

96
00:05:21,690 --> 00:05:25,585
But I was interested because this
particular company builds smart

97
00:05:25,585 --> 00:05:30,965
contracts and I do think that smart
contracts are one of the core gems that

98
00:05:30,965 --> 00:05:35,078
I think Web3 could bring, some real
improvement to the world of software.

99
00:05:35,568 --> 00:05:39,998
So they recruited me and they specifically
asked, can you come and join us?

100
00:05:40,038 --> 00:05:44,478
And because you're so big in Web2, can
you help us attract Web2 developers?

101
00:05:44,478 --> 00:05:45,238
That was my role.

102
00:05:45,238 --> 00:05:46,508
I wasn't really an engineer.

103
00:05:46,508 --> 00:05:50,718
I was really more almost a dev rel,
but I needed to learn the space and

104
00:05:50,718 --> 00:05:55,218
so I spent that four to six months I
was there trying to immerse myself in

105
00:05:55,218 --> 00:06:00,118
the web3 world and understand that and
in no way do I want to say anything

106
00:06:00,128 --> 00:06:05,118
bad about web3, but I'm not here to
support it in any way because I ended up

107
00:06:05,148 --> 00:06:07,168
leaving that world because I didn't fit.

108
00:06:07,633 --> 00:06:14,313
I didn't fit because I don't believe
that the world that's being spun in

109
00:06:14,323 --> 00:06:18,593
Web3, which by the way comes from
some pretty deep roots in like the

110
00:06:18,593 --> 00:06:23,493
genre of cyberpunk fiction, and I
read some of those books to like get

111
00:06:23,493 --> 00:06:25,793
myself into the mindset of this world.

112
00:06:26,383 --> 00:06:31,343
I don't believe what they believe, I
think, which is that they believe that

113
00:06:31,343 --> 00:06:38,275
the world's current track is inevitably
going to lead to ruin, and they've created

114
00:06:38,275 --> 00:06:40,785
the only oasis that anybody can jump to.

115
00:06:41,385 --> 00:06:45,915
And they believe, I think, that it's
not only inevitable that people will

116
00:06:45,915 --> 00:06:48,415
jump, but that it's self evident.

117
00:06:48,940 --> 00:06:50,170
That people will make the jump.

118
00:06:50,580 --> 00:06:54,140
If just more people hear about it,
they will obviously say, let's do that.

119
00:06:54,610 --> 00:06:55,820
I didn't fit in that world.

120
00:06:55,850 --> 00:06:58,950
I'm not criticizing the people
that believe that, but they just

121
00:06:58,950 --> 00:07:02,960
kind of papered over that gap
that exists between web2 and web3.

122
00:07:03,530 --> 00:07:08,060
So over that four to six months, what
codified in my mind was there's definitely

123
00:07:08,060 --> 00:07:09,630
some things that we need to work on.

124
00:07:09,940 --> 00:07:13,010
They don't look like Web 3 at least yet.

125
00:07:13,510 --> 00:07:17,140
And I left and I told them I'm
leaving cause I'm going to go build

126
00:07:17,140 --> 00:07:19,110
what I'm going to call Web 2.5.

127
00:07:19,540 --> 00:07:22,430
If we ever are going to get to
Web 3, which I don't know if we

128
00:07:22,430 --> 00:07:27,210
are or not, not my say, but we
have to take an intermediary step.

129
00:07:27,210 --> 00:07:28,590
We're not going to make that jump.

130
00:07:28,670 --> 00:07:31,920
I feel confident in predicting
that we will not simply make

131
00:07:31,920 --> 00:07:34,300
that giant leap over the chasm.

132
00:07:34,970 --> 00:07:39,270
So we can talk about
what I define as Web 2.5.

133
00:07:39,410 --> 00:07:45,760
But those ideas came from kind of
swinging the pendulum too far, I think

134
00:07:45,790 --> 00:07:49,770
maybe, towards that decentralized
world, which is what Web3 is all about.

135
00:07:50,030 --> 00:07:54,370
And then saying, let's swing it back
a little bit and figure out some way

136
00:07:54,370 --> 00:07:58,130
to achieve that with what the web
currently is and building on top of

137
00:07:58,370 --> 00:08:00,000
and evolving what the web currently is.

138
00:08:00,560 --> 00:08:02,430
That is what led me to Socket.

139
00:08:03,335 --> 00:08:04,145
Socket supply.

140
00:08:04,175 --> 00:08:08,145
They, build a mobile,
tooling set and framework.

141
00:08:08,485 --> 00:08:13,775
others in that space are Tauri and Ionic
and way back in the day, PhoneGap for

142
00:08:13,785 --> 00:08:18,525
building hybrid applications where the
UI is built around a web and in a web

143
00:08:18,525 --> 00:08:24,075
view with a backend that is native and
extending the native capabilities into

144
00:08:24,075 --> 00:08:25,995
the web space, that's what they do.

145
00:08:26,325 --> 00:08:32,483
I was very attracted to that specifically
because of their ability to allow

146
00:08:32,483 --> 00:08:37,493
a web application to have full
peer-to-peer communications capabilities.

147
00:08:37,873 --> 00:08:42,313
They exposed UDP based, relay
based peer-to-peer protocol

148
00:08:42,633 --> 00:08:44,193
directly to a web application.

149
00:08:44,513 --> 00:08:49,043
I felt like that was a big, it still is
a big missing piece for the web platform,

150
00:08:49,133 --> 00:08:52,008
and it felt like the way to move forward.

151
00:08:52,018 --> 00:08:57,628
Not that I love native apps and I just
want us to all build only native apps.

152
00:08:58,038 --> 00:09:01,468
I really do love the web platform,
but this felt like a good compromise.

153
00:09:01,468 --> 00:09:07,958
If we can build an app in the web platform
and then wrap A rather thin wrapper around

154
00:09:07,958 --> 00:09:11,428
it to give it these extra capabilities
that for some reason, the web just

155
00:09:11,428 --> 00:09:16,038
won't give apps right now, then I think
we can actually move forward if we can

156
00:09:16,038 --> 00:09:17,678
have true peer to peer communication.

157
00:09:17,688 --> 00:09:21,918
So, join Socket Supply to work
on that and in particular, to

158
00:09:21,918 --> 00:09:26,288
work on putting encryption into
that peer to peer relay protocol.

159
00:09:26,808 --> 00:09:29,278
That's what I spent a lot
of my time there doing.

160
00:09:29,278 --> 00:09:30,868
I also did a bunch of DevRel stuff.

161
00:09:31,268 --> 00:09:32,508
I'm no longer with Socket.

162
00:09:32,508 --> 00:09:34,528
I was there for about 10 or so months.

163
00:09:34,528 --> 00:09:37,178
I'm not with Socket anymore,
but that was part of my journey.

164
00:09:37,948 --> 00:09:42,665
And then several months went by where
I was unemployed after leaving Socket

165
00:09:42,988 --> 00:09:46,508
before, the founder of this Vella.

166
00:09:46,708 --> 00:09:47,298
ai.

167
00:09:47,611 --> 00:09:50,851
he's the one who runs the
meetup in the local-first space.

168
00:09:51,181 --> 00:09:54,781
He came to me and said, I've seen you
active in the local-first community.

169
00:09:55,175 --> 00:09:57,065
would you consider
helping me co found this?

170
00:09:57,485 --> 00:10:01,778
And the story that he spun was
incredibly attractive to me.

171
00:10:01,808 --> 00:10:08,228
It seemed like a really obvious place
to attach my passion for identity.

172
00:10:08,495 --> 00:10:11,155
What he said was I've been
working on smart assistant.

173
00:10:11,175 --> 00:10:14,755
It's going to use AI, but I really
believe that AI should work as

174
00:10:14,765 --> 00:10:16,785
much on the device as possible.

175
00:10:17,270 --> 00:10:20,830
Given the constraints that we have in
devices, put as much of that on the

176
00:10:20,830 --> 00:10:25,200
device as we can, because this is really
sensitive personal data that doesn't need

177
00:10:25,230 --> 00:10:27,870
to be just slurped up into the cloud.

178
00:10:27,870 --> 00:10:30,790
And that really resonated with
me believing in local-first.

179
00:10:31,106 --> 00:10:36,646
And more importantly, if you're going
to build apps like that, where you have

180
00:10:36,646 --> 00:10:41,151
your data on your device and you have
it on multiple devices and you really

181
00:10:41,151 --> 00:10:45,921
are trying to break down some of the
silos between apps like mixing your

182
00:10:46,131 --> 00:10:50,871
Google data and your Apple data and your
Spotify data all into this one thing.

183
00:10:51,141 --> 00:10:55,078
What was really obvious to me was we're
going to need a way to, if we're eschewing

184
00:10:55,088 --> 00:10:58,988
all of those services, then we're going
to need a way to define our identity

185
00:10:58,988 --> 00:11:01,158
so that we can keep things straight.

186
00:11:01,978 --> 00:11:04,753
And that identity needs
to be really local-first.

187
00:11:04,773 --> 00:11:08,613
So that's what attracted me to Vella,
was go work on the identity piece to

188
00:11:08,613 --> 00:11:11,010
try to help their story, progress.

189
00:11:11,260 --> 00:11:14,370
I spent several months with Vella,
they're a great, group of folks.

190
00:11:14,620 --> 00:11:17,225
Fortunately, we just I didn't
have enough funding to keep me

191
00:11:17,225 --> 00:11:18,975
working in a paid capacity there.

192
00:11:19,315 --> 00:11:21,805
I'm still advising them,
still wishing them the best.

193
00:11:21,805 --> 00:11:25,855
And they're, they're continuing
on in their sort of smart email

194
00:11:25,895 --> 00:11:28,385
inbox app to rule the world.

195
00:11:28,685 --> 00:11:31,105
And I hope they achieve it
because I want to use that app.

196
00:11:31,105 --> 00:11:32,135
I look forward to that.

197
00:11:32,155 --> 00:11:35,035
So that brings us kind of to today.

198
00:11:35,405 --> 00:11:38,980
Vella is the reason I started
putting together some of the

199
00:11:39,210 --> 00:11:40,850
puzzle pieces for Identity.

200
00:11:41,110 --> 00:11:45,190
I was going to build it for Vella, but
I'm just building it right now in the

201
00:11:45,190 --> 00:11:50,050
open source so that hopefully these Lego
pieces are something that apps like Vella

202
00:11:50,200 --> 00:11:54,350
and others, hopefully in the local-first
space will pick up and build upon.

203
00:11:55,170 --> 00:11:55,670
Perfect.

204
00:11:55,690 --> 00:11:59,985
Well, that's quite the arc of like
different chapters from peer to peer

205
00:12:00,025 --> 00:12:02,345
to locally running AI, et cetera.

206
00:12:02,375 --> 00:12:07,745
I'm eager to get into each of those, but
maybe taking a few steps back, you said

207
00:12:07,745 --> 00:12:10,295
something that captured my attention.

208
00:12:10,585 --> 00:12:13,585
I'm also not a person who's
a big believer in Web3.

209
00:12:13,585 --> 00:12:14,865
I'm rather skeptical.

210
00:12:15,125 --> 00:12:19,375
If it happens and if those ideals
prevail, I won't stand in the way of it.

211
00:12:19,385 --> 00:12:22,775
But I'm a little bit, just
skeptical of like what it's the

212
00:12:22,775 --> 00:12:24,615
bad stuff it attracted so far.

213
00:12:24,985 --> 00:12:29,085
And so I'm very interested in
the good ideas behind that.

214
00:12:29,085 --> 00:12:31,615
A lot of like interesting
research that came out of that.

215
00:12:32,065 --> 00:12:33,005
But I agree.

216
00:12:33,045 --> 00:12:38,755
It is too far of a step, too of a
radical step from how things, work

217
00:12:38,805 --> 00:12:45,045
today and like how practical everything
is today to a much more idealistic,

218
00:12:45,095 --> 00:12:50,001
but in many regards still, to me,
it seems like impractical, A to B.

219
00:12:50,541 --> 00:12:55,471
So if there's like a middle ground
there that maybe has a bunch of like the

220
00:12:55,551 --> 00:13:00,476
more attractive things from the future,
from that Web3, Utopia, who knows?

221
00:13:00,886 --> 00:13:05,939
and you framed that as Web 2.5 . I'm
very curious how you define that

222
00:13:06,009 --> 00:13:10,203
and, how you then also, then
connected the dots to local-first.

223
00:13:10,623 --> 00:13:15,623
Yeah, so speaking specifically about
local-first, just because I know most

224
00:13:15,623 --> 00:13:18,743
of the people that'll be listening to
this do understand local-first, but I

225
00:13:18,743 --> 00:13:24,843
want to re emphasize of the seven points
of the original Manifesto from Ink

226
00:13:24,983 --> 00:13:31,366
& Switch I think the kind of, narrative
arc that comes out of that is that we

227
00:13:31,366 --> 00:13:36,676
have built software for the last 20
or almost 30 years with an increasing

228
00:13:36,676 --> 00:13:40,406
mindset towards server and cloud first.

229
00:13:40,866 --> 00:13:44,276
We build apps where we, architect
and design what that's going to be.

230
00:13:44,496 --> 00:13:47,766
And then we create extensions of
that experience into the client.

231
00:13:48,166 --> 00:13:51,196
And I think what local-first
says is let's flip that paradigm.

232
00:13:51,406 --> 00:13:56,696
Let's start with what can the client
experience be and what should it be?

233
00:13:56,876 --> 00:13:59,866
And where should that
data reside in the client?

234
00:14:00,246 --> 00:14:05,291
And then optionally, you might
choose to enhance that experience

235
00:14:05,291 --> 00:14:07,461
with a cloud or server experience.

236
00:14:07,821 --> 00:14:12,664
Flipping that default assumption where you
start what you prioritize when you design.

237
00:14:12,948 --> 00:14:16,008
I think that's one of the
most important aspects of the

238
00:14:16,008 --> 00:14:18,588
local-first manifesto and movement.

239
00:14:18,978 --> 00:14:25,058
And I would say that that requires
you to ask, what does my app do

240
00:14:25,068 --> 00:14:27,088
in a zero server environment?

241
00:14:27,108 --> 00:14:29,828
How does my app behave in
a zero server environment?

242
00:14:30,368 --> 00:14:35,814
Zero server is, that's my term,
not a generally accepted term,

243
00:14:35,814 --> 00:14:37,094
but here's how I define it.

244
00:14:37,404 --> 00:14:42,139
It is either that there is no
server in existence, Or, that

245
00:14:42,139 --> 00:14:45,949
server effectively doesn't exist
because there's no connection to it.

246
00:14:46,489 --> 00:14:50,109
And there's a thousand different reasons
why that connection might not exist.

247
00:14:50,469 --> 00:14:55,369
Might be down, might be the company went
out of business, might be flaky internet

248
00:14:55,409 --> 00:14:57,359
on the client or the server or both.

249
00:14:57,839 --> 00:15:01,619
But, Zero server means
this app is on its own.

250
00:15:01,739 --> 00:15:05,029
There is no connection to a mothership
and how's it going to behave?

251
00:15:05,069 --> 00:15:08,159
And it really should behave
like a full fidelity experience.

252
00:15:08,559 --> 00:15:10,636
Here's my, go to example for this.

253
00:15:11,006 --> 00:15:11,966
Banking apps.

254
00:15:12,346 --> 00:15:17,086
We all know that banking apps are
online apps, and they're all built

255
00:15:17,086 --> 00:15:20,646
with the assumption that when you
log into your banking app, you want

256
00:15:20,646 --> 00:15:24,676
to see the most instantaneous, up
to the minute information about

257
00:15:24,676 --> 00:15:26,036
your current bank account balance.

258
00:15:26,056 --> 00:15:30,976
And they certainly own the source of truth
about what your bank account balance is.

259
00:15:31,106 --> 00:15:31,956
No argument there.

260
00:15:32,826 --> 00:15:38,246
However, there's a ton of information
and functionality that is not

261
00:15:38,296 --> 00:15:40,806
requiring live updates of data.

262
00:15:41,266 --> 00:15:46,256
There's all of my previous banking
history, years and years worth, tens

263
00:15:46,256 --> 00:15:50,046
of thousands of transactions, some of
which might be useful if I'm preparing

264
00:15:50,066 --> 00:15:53,676
taxes or I'm trying to analyze my
budget or figure out what I spent

265
00:15:53,686 --> 00:15:57,656
things on or whatever, and I don't need
a live internet connection and a live

266
00:15:57,686 --> 00:15:59,616
up to date bank balance to do that.

267
00:16:00,211 --> 00:16:03,711
But as everybody knows, you can't log
into your bank app without an internet

268
00:16:03,751 --> 00:16:06,411
and get in access to that data.

269
00:16:06,681 --> 00:16:11,271
It's very much my data and I very much
still have the app on my device and I

270
00:16:11,271 --> 00:16:14,951
can't pair those two together because
there was an assumption that the server

271
00:16:14,951 --> 00:16:16,731
was a required piece of the puzzle.

272
00:16:17,441 --> 00:16:18,771
And I think that's just a failing.

273
00:16:18,771 --> 00:16:20,381
It's a failing of business models.

274
00:16:20,381 --> 00:16:22,171
It's a failing of product design.

275
00:16:22,441 --> 00:16:24,436
It's a failing all the
way across the board.

276
00:16:24,716 --> 00:16:30,426
To have not prioritized, assuming I
start with this and then we add on later.

277
00:16:30,706 --> 00:16:34,596
That bank app could very easily let me see
all of my data and have a very prominent

278
00:16:34,606 --> 00:16:39,216
icon there that says, this is not your
live bank balance or just hide the bank

279
00:16:39,226 --> 00:16:42,976
balance if they were really worried
about that, but they could very easily

280
00:16:42,986 --> 00:16:47,386
give me all that functionality on my
existing data that was kept on my device.

281
00:16:47,656 --> 00:16:51,236
So that's one of the reasons
I resonate with local first.

282
00:16:51,456 --> 00:16:57,086
And in a way, it's also the simplest
use case where basically all your

283
00:16:57,096 --> 00:17:01,146
transactional history is typically
like append only and immutable.

284
00:17:01,376 --> 00:17:04,226
It's not that your bank's going to
say like, Oh, actually like this

285
00:17:04,246 --> 00:17:08,542
10, 000 transaction back there,
like it's never happened but all of

286
00:17:08,542 --> 00:17:12,192
that is like basically set in stone
or should really be set in stone.

287
00:17:12,202 --> 00:17:14,262
That's like the nature of the domain.

288
00:17:14,602 --> 00:17:18,792
So this should make it the simplest
use case actually to support this.

289
00:17:18,912 --> 00:17:19,022
Yeah.

290
00:17:19,022 --> 00:17:21,622
The CRDT there is pretty simple.

291
00:17:23,162 --> 00:17:25,262
In local-first terms,
there's not a lot of merging.

292
00:17:25,272 --> 00:17:25,552
You're right.

293
00:17:25,572 --> 00:17:26,542
That's a, that's a good point.

294
00:17:26,542 --> 00:17:29,752
Like the technical barrier
is not really there.

295
00:17:29,792 --> 00:17:32,782
It's, it's a failure of business
model and a product design.

296
00:17:33,587 --> 00:17:40,037
So, I very much believe that we need to
do those things, and, I call that version

297
00:17:40,037 --> 00:17:45,847
of the web, or at least that's one pillar
of what I call the Web 2.5, a web that

298
00:17:46,287 --> 00:17:51,497
stops being drunk on the idea that the
only way to build an app is to start with

299
00:17:51,517 --> 00:17:55,427
cloud infrastructure and then work your
way back to the client, but rather start

300
00:17:55,427 --> 00:17:59,807
with client infrastructure and maybe or
maybe not work your way toward a server.

301
00:18:00,242 --> 00:18:03,662
I think there's a ton of apps that
never need any servers whatsoever.

302
00:18:04,192 --> 00:18:07,592
The probably most motivating example
that got me interested in this

303
00:18:07,592 --> 00:18:09,532
space was going back several years.

304
00:18:09,852 --> 00:18:13,952
There's a landmark, you know, world
changing legal ruling in the U.

305
00:18:13,952 --> 00:18:14,272
S.

306
00:18:14,302 --> 00:18:19,502
that I'm, where I'm at, from the Supreme
Court that eliminated federal protections

307
00:18:19,512 --> 00:18:23,485
for women to have the right to choose
abortions, and other types of, healthcare.

308
00:18:23,885 --> 00:18:26,172
And I'm not a uterus having person.

309
00:18:26,202 --> 00:18:26,612
I can't.

310
00:18:27,057 --> 00:18:29,917
Get pregnant or have an abortion,
but I absolutely have people in my

311
00:18:29,917 --> 00:18:31,987
life that I care about that can.

312
00:18:32,037 --> 00:18:35,137
I have a daughter, I have a
wife, like, this matters to me,

313
00:18:35,627 --> 00:18:37,197
and there was actually a case.

314
00:18:37,197 --> 00:18:38,637
It wasn't just sort of made up.

315
00:18:38,637 --> 00:18:43,680
There was actually a case where
data that a woman had in a period of

316
00:18:43,680 --> 00:18:49,020
menstruation tracking app was Captured
and used against her by government

317
00:18:49,020 --> 00:18:50,220
and law enforcement authorities.

318
00:18:50,760 --> 00:18:56,500
And that is just like that is so
quintessentially the bad future

319
00:18:56,520 --> 00:18:57,760
that we never should have built.

320
00:18:57,760 --> 00:18:58,910
We never should have enabled.

321
00:18:59,170 --> 00:19:00,530
And it just snapped in my mind.

322
00:19:00,530 --> 00:19:06,660
Like we have the technical capability
to let people create really useful and

323
00:19:06,660 --> 00:19:11,560
engaging experiences around data that
they own, that is about them, that is

324
00:19:11,560 --> 00:19:15,890
very personal, and there's no reason
that data ever has to go out to somebody

325
00:19:15,890 --> 00:19:18,251
else's device because that's the trap.

326
00:19:18,681 --> 00:19:23,121
I make the assertion that if you do
not have custody of your data, then

327
00:19:23,121 --> 00:19:24,851
you do not have ownership of your data.

328
00:19:25,391 --> 00:19:26,441
Custody is the whole game.

329
00:19:27,001 --> 00:19:30,641
So when we give it out to those servers,
then of course you're going to have

330
00:19:30,651 --> 00:19:35,701
governments that are going to find either
ways to backdoor the encryption or legally

331
00:19:35,701 --> 00:19:39,391
force them to get access to that data
and they're going to use it against you.

332
00:19:39,661 --> 00:19:43,061
And no matter where you are on the
political spectrum, no matter where

333
00:19:43,061 --> 00:19:47,151
you are on the techno spectrum,
you must agree with me that that's

334
00:19:47,151 --> 00:19:48,676
not a future that we want to build.

335
00:19:48,986 --> 00:19:52,396
Where they can do whatever they want
with our data and manipulate us.

336
00:19:52,426 --> 00:19:57,026
That can't be what  with a
rational level head says is, is

337
00:19:57,026 --> 00:19:57,896
what we ought to be building.

338
00:19:57,896 --> 00:20:02,026
But we have built that and we've
gotten dangerously close to that.

339
00:20:02,436 --> 00:20:06,806
So Web 2.5 is saying we need to back
away from that, completely reverse

340
00:20:06,806 --> 00:20:09,086
that paradigm, put data first.

341
00:20:09,326 --> 00:20:13,496
On the device, the way local-first
suggests, and don't even build a

342
00:20:13,496 --> 00:20:15,136
server if it doesn't make sense.

343
00:20:15,376 --> 00:20:17,946
But if it does make sense,
be restrained in doing so.

344
00:20:18,146 --> 00:20:19,736
That's what I mean by zero server.

345
00:20:20,116 --> 00:20:23,106
And I think that's also a really
interesting point about like

346
00:20:23,226 --> 00:20:25,336
health apps more, more broadly.

347
00:20:25,589 --> 00:20:30,794
I mean, a health app is typically I'm
inserting some data about myself, or

348
00:20:30,794 --> 00:20:34,944
maybe with like a smart device that
tracks my heart rate, et cetera.

349
00:20:35,384 --> 00:20:40,164
And there's probably not a
good reason to have that data

350
00:20:40,184 --> 00:20:42,364
be synced to a remote server.

351
00:20:42,364 --> 00:20:47,004
Maybe I want to have it, maybe I have like
a Apple watch and I have like an iPhone

352
00:20:47,014 --> 00:20:51,584
or on some other platforms, maybe those
things should sync between each other.

353
00:20:52,004 --> 00:20:56,549
But that a third party is the
kind of de facto source of truth

354
00:20:56,889 --> 00:20:58,499
where all of that data is stored.

355
00:20:58,909 --> 00:21:04,449
I think the only explanation for
why that is the case is because it's

356
00:21:04,569 --> 00:21:08,859
been so much easier to build those
sort of server centric applications.

357
00:21:09,164 --> 00:21:12,884
I think I might take issue with you
in saying that's not the only reason.

358
00:21:12,904 --> 00:21:18,211
That might be the most convenient
excuse, but I think the most salient

359
00:21:18,221 --> 00:21:23,041
reason is because there's much more
money to be made if my data sits in

360
00:21:23,041 --> 00:21:24,951
their server versus on my device.

361
00:21:25,001 --> 00:21:27,951
And I think that's what's driven a
lot of it, but I think you're right

362
00:21:27,951 --> 00:21:33,351
that We have absolutely created
a technology landscape where the

363
00:21:33,361 --> 00:21:35,731
easy paved cow path is to do that.

364
00:21:36,801 --> 00:21:37,531
I agree with that.

365
00:21:37,711 --> 00:21:40,571
I think those are
definitely two major points.

366
00:21:40,641 --> 00:21:46,221
but I think even if someone has more of
like the, aspiration to build something

367
00:21:46,271 --> 00:21:52,441
in the interest of a user and is maybe
not after turning this into a billion

368
00:21:52,441 --> 00:21:58,341
dollar monopoly, then it's still a lot
harder to build a non server centric

369
00:21:58,341 --> 00:22:00,191
application, at least in the past.

370
00:22:00,191 --> 00:22:04,221
And I think slowly but surely that is
starting to change with all of those

371
00:22:04,231 --> 00:22:06,101
amazing local-first technologies.

372
00:22:06,606 --> 00:22:11,186
But yeah, the example you've mentioned
is certainly a very stark reminder

373
00:22:11,496 --> 00:22:13,316
that we have to do something there.

374
00:22:14,826 --> 00:22:21,033
So that's one of the pillars of Web
2.5 is We need to build a Web 2.5 where

375
00:22:21,033 --> 00:22:25,093
the paradigm is that we own our data
and we own our identity so that we can

376
00:22:25,303 --> 00:22:27,413
control that data and say where it goes.

377
00:22:27,743 --> 00:22:32,113
Sometimes it's going to go to my devices,
like I call it my local cloud or my local

378
00:22:32,113 --> 00:22:34,623
ring to borrow the term web ring from.

379
00:22:34,688 --> 00:22:37,478
30 years ago that I'm
old enough to remember.

380
00:22:37,808 --> 00:22:39,538
Your local ring is all your devices.

381
00:22:39,538 --> 00:22:42,308
It's your watches and tablets and
laptops and phones and all that.

382
00:22:42,558 --> 00:22:44,298
You definitely want to share data there.

383
00:22:44,618 --> 00:22:50,428
And that explains why I was interested in
peer to peer technology, because that is

384
00:22:50,428 --> 00:22:52,438
where that is how that data should get.

385
00:22:52,813 --> 00:22:53,733
between my devices.

386
00:22:53,993 --> 00:22:55,643
By the way, I'll just, I'll make a plug.

387
00:22:55,763 --> 00:23:00,243
Aside from true networking based peer
to peer, which is what Socket was

388
00:23:00,243 --> 00:23:03,833
trying to do, and what their protocol
I think enables, whether you ever use

389
00:23:03,833 --> 00:23:06,543
Socket, I think they just have a great
protocol that we could build upon

390
00:23:06,906 --> 00:23:08,856
that's relay based and self balancing.

391
00:23:08,856 --> 00:23:11,779
I think there's a lot of, really
good stuff there that somebody

392
00:23:11,789 --> 00:23:13,279
should, should pick up and run with.

393
00:23:13,309 --> 00:23:17,193
But whether you use that or not, there
is actually a working group in the web

394
00:23:17,193 --> 00:23:20,863
standards community that's trying to
work on what's called local peer to peer.

395
00:23:21,243 --> 00:23:22,713
I'm very excited about this.

396
00:23:22,772 --> 00:23:27,406
they're trying to build an API into the
web platform that will tunnel itself

397
00:23:27,446 --> 00:23:29,456
over a couple of different transports.

398
00:23:29,746 --> 00:23:34,963
One being the local Wi Fi that Apple
and, Apple iOS and Google Android have.

399
00:23:35,423 --> 00:23:37,998
They're competing standards, but
they're going to try to create

400
00:23:37,998 --> 00:23:40,948
a web API that papers over the
difference between these standards.

401
00:23:41,288 --> 00:23:44,458
It uses your Wi Fi connections
to connect between devices.

402
00:23:44,908 --> 00:23:48,388
Failing that, it can use Bluetooth
or NFC or any other of these, like,

403
00:23:48,408 --> 00:23:53,108
local, localized transport layers to
be able to communicate between devices.

404
00:23:53,398 --> 00:23:55,988
This would be, I think, one of
the most important things the web

405
00:23:55,988 --> 00:23:57,598
could ever land if this happens.

406
00:23:57,618 --> 00:23:59,228
There is a working group on it.

407
00:23:59,228 --> 00:24:02,878
There's a kind of a spec already
working its way processed through.

408
00:24:03,086 --> 00:24:04,686
I don't think we're going
to have it in six months.

409
00:24:04,686 --> 00:24:07,216
There's going to take a little
while, but I'm very excited that at

410
00:24:07,236 --> 00:24:12,166
least finally, there's some movement
towards let's not lock down, the web.

411
00:24:12,216 --> 00:24:15,676
And by the way, one little side
note, there's a whole bunch of

412
00:24:15,676 --> 00:24:20,756
stuff that the web platform should
enable, but does not enable.

413
00:24:21,196 --> 00:24:28,086
Locks down or hobbles because we are,
for some reason, and we, I mean, as a

414
00:24:28,086 --> 00:24:33,156
community, and especially the spec bodies,
we are unwilling to admit that there is a

415
00:24:33,166 --> 00:24:39,796
fundamental paradigm difference between,
I've visited a web page one or more

416
00:24:39,796 --> 00:24:44,976
times, There's that experience, which
definitely we should be distrustful of.

417
00:24:45,206 --> 00:24:46,536
We should keep at arm's length.

418
00:24:46,866 --> 00:24:50,226
There's a difference between that
experience and I've gone to a website

419
00:24:50,226 --> 00:24:51,796
a few times and I really like it.

420
00:24:51,816 --> 00:24:54,986
And I installed that onto my device.

421
00:24:55,466 --> 00:24:58,286
Once I've said, I am
installing that onto my device.

422
00:24:59,051 --> 00:25:04,121
I am saying, just like with any other app
that I install, please let it have all

423
00:25:04,121 --> 00:25:06,001
the capacity that I'm willing to give it.

424
00:25:06,381 --> 00:25:08,851
Pop it up and have it ask me, do
I want to give it this, and this,

425
00:25:08,851 --> 00:25:12,151
and this, and let me say, yes, I
want to give it those permissions.

426
00:25:12,791 --> 00:25:19,381
I don't understand why the web thinks of
itself as a unified medium when it is used

427
00:25:19,381 --> 00:25:21,161
in these completely different paradigms.

428
00:25:21,601 --> 00:25:26,231
We need to be forking what we allow
in the web platform, based upon

429
00:25:26,231 --> 00:25:28,791
that flag, has it been installed?

430
00:25:29,131 --> 00:25:32,661
Once it's been installed, I think
that is very much implicitly the

431
00:25:32,661 --> 00:25:34,501
user saying, I trust this app.

432
00:25:34,751 --> 00:25:36,621
Let this app do what I want it to do.

433
00:25:36,981 --> 00:25:41,161
So things like local peer to peer,
they don't make sense for a drive

434
00:25:41,171 --> 00:25:44,781
by website, and you should rightly
be scared about a website being

435
00:25:44,781 --> 00:25:46,261
able to like talk to your watch.

436
00:25:46,451 --> 00:25:50,431
Like I get that, but if it's an app
that's built with web technology that

437
00:25:50,431 --> 00:25:53,221
a user trusted enough to install,
it should have this capability.

438
00:25:53,241 --> 00:25:57,164
So just a little, side rant
there, but anyway, peer to peer

439
00:25:57,164 --> 00:25:58,714
communication, the local ring.

440
00:25:58,744 --> 00:26:02,124
We absolutely need to do that,
but none of that needs servers.

441
00:26:02,174 --> 00:26:03,704
We can build this without servers.

442
00:26:04,264 --> 00:26:08,861
I love those points and I was not
aware of this, standards work body,

443
00:26:08,964 --> 00:26:13,994
in working in favor of bringing more
local peer to peer supports for the web.

444
00:26:14,034 --> 00:26:16,084
I think this is very, very much needed.

445
00:26:16,434 --> 00:26:16,944
Right now.

446
00:26:16,954 --> 00:26:23,041
I think the closest we got that also,
makes that a little more focused on my

447
00:26:23,041 --> 00:26:28,031
devices is like I'm using tail scale
to create sort of like a secure bridge

448
00:26:28,051 --> 00:26:32,721
between my devices, but that is still
on an operating system level and not

449
00:26:32,731 --> 00:26:37,748
something that the web platform can
easily, make use of to my knowledge.

450
00:26:38,218 --> 00:26:43,158
But the other point you've been making
about the distinction between a website,

451
00:26:43,208 --> 00:26:48,618
which you might just open once or a
few times, maybe for a webshop or for

452
00:26:48,618 --> 00:26:54,028
like some, news outlet that like just
has everything littered with ads.

453
00:26:54,068 --> 00:26:58,048
And so surely you want to be
much more careful about providing

454
00:26:58,518 --> 00:27:00,068
too many privileges to that.

455
00:27:00,503 --> 00:27:04,843
But if it's, let's say your
mail app or other sort of apps

456
00:27:04,843 --> 00:27:07,073
you use on a daily basis, sure.

457
00:27:07,083 --> 00:27:11,426
You want to give that more access and
possibly also in a way where, there

458
00:27:11,446 --> 00:27:16,606
is more of like a local AI context
on your device, maybe even take a

459
00:27:16,626 --> 00:27:23,195
step further and provide a way how a
native web app, like a native feeling

460
00:27:23,305 --> 00:27:26,735
app that lives in your web browser,
maybe can even get access to that.

461
00:27:26,995 --> 00:27:30,775
I feel like we're making
some steps towards that.

462
00:27:30,871 --> 00:27:35,121
so for example, for Overtone, the music
app I'm working on, I've actually just

463
00:27:35,141 --> 00:27:40,501
over the course of the past couple
of weeks, I've added support for

464
00:27:40,511 --> 00:27:44,701
file system mounting, which is not
available across all browsers but,

465
00:27:44,925 --> 00:27:46,885
Chromium based browser supports this.

466
00:27:47,320 --> 00:27:49,540
I believe Oprah also supports this.

467
00:27:49,570 --> 00:27:54,036
I might be wrong on this one, but I've
been primarily adding support for, because

468
00:27:54,066 --> 00:27:56,396
I'm using Chromium browsers myself.

469
00:27:56,416 --> 00:27:58,486
Are you talking about the OPFS?

470
00:27:58,906 --> 00:28:00,156
So there's two things.

471
00:28:00,426 --> 00:28:05,876
There is OPFS, which I'm already using as
a persistence mechanism for pretty much

472
00:28:05,906 --> 00:28:11,656
everything for also for persisting my
SQLite database and images, media assets.

473
00:28:11,676 --> 00:28:12,796
But there's also.

474
00:28:13,021 --> 00:28:19,271
a feature that has mostly the same
API as OPFS, but instead of just

475
00:28:19,411 --> 00:28:25,521
creating a new file system, like a
folder or files within the virtual file

476
00:28:25,521 --> 00:28:28,511
system, you can actually ask the user.

477
00:28:28,748 --> 00:28:32,558
to bring in an existing
file or existing folder.

478
00:28:32,788 --> 00:28:38,861
So, in my case, I would allow the
user to select their music directory

479
00:28:38,881 --> 00:28:42,851
from their local computer, or
possibly even from a NAS device.

480
00:28:43,141 --> 00:28:48,171
And so this works both for sort of
like the show file picker model, as

481
00:28:48,171 --> 00:28:52,501
well as for drag and dropping, an
existing file or existing folder.

482
00:28:52,781 --> 00:28:58,666
So this already is a big step towards
like a more native feeling experience in

483
00:28:58,666 --> 00:29:03,776
the web, but there's so many more aspects
to this that we haven't covered yet.

484
00:29:04,096 --> 00:29:07,856
networking certainly being a
big one, whether it's just TCP

485
00:29:07,896 --> 00:29:09,836
connections, UDP connections.

486
00:29:10,123 --> 00:29:16,220
One thing that I'm also somewhat hopeful
of that this might bridge the boundaries

487
00:29:16,220 --> 00:29:21,990
a little bit is to rely on browser
extensions to be sort of like a thing

488
00:29:22,000 --> 00:29:27,626
that you could trust more and that could
facilitate that additional privileges

489
00:29:27,816 --> 00:29:30,706
for a given website or a given web app.

490
00:29:31,016 --> 00:29:33,696
That's something I'm thinking
about whether I should maybe

491
00:29:33,696 --> 00:29:37,986
explore that for Overtone to give
you more native like affordances.

492
00:29:38,556 --> 00:29:41,326
but yeah, that's maybe a
topic for another episode.

493
00:29:41,530 --> 00:29:42,560
I've done some work in that.

494
00:29:42,560 --> 00:29:46,990
I actually built a web app and built a
browser extension that I could use with

495
00:29:47,000 --> 00:29:52,190
that web app and extended the capabilities
in like audio and visual sense.

496
00:29:52,200 --> 00:29:53,310
So I've done some work with that.

497
00:29:53,750 --> 00:29:56,700
There's a lot of challenges there, but
I do think there's a lot of potential.

498
00:29:56,813 --> 00:30:00,033
and in particular, one of the things
we'll talk about, I think a bit later

499
00:30:00,033 --> 00:30:05,938
in this episode, I very much intend
to go down the route of building,

500
00:30:06,383 --> 00:30:12,063
Whether they be extensions or just side
companion apps that do give extensions

501
00:30:12,063 --> 00:30:15,623
of capabilities to normal apps, because
there's too many barriers right now.

502
00:30:15,896 --> 00:30:20,071
I do just want to say, I only,
have described so far one

503
00:30:20,071 --> 00:30:22,961
pillar of how I define Web 2.5.

504
00:30:22,981 --> 00:30:26,291
There are two more and I don't, they
don't need quite as much time, but I

505
00:30:26,291 --> 00:30:30,901
do just want to state kind of for the
record, what, how I define it, it's

506
00:30:30,901 --> 00:30:34,761
just a term I made up, people may not
like it, but it's, it's how I define it.

507
00:30:35,351 --> 00:30:40,721
So the first pillar was we do need to
build a web where data is ours, identity

508
00:30:40,721 --> 00:30:46,716
is ours, and we can choose where we share
that data with our local ring of devices.

509
00:30:46,716 --> 00:30:50,666
We can choose if we want to share it
out to cloud for other, you know, back,

510
00:30:50,676 --> 00:30:54,056
there are reasons why you want to be
able to back things up or whatever.

511
00:30:54,683 --> 00:30:59,723
Point number two, I think this speaks
actually to, a lot of the skepticism

512
00:30:59,733 --> 00:31:05,173
around local-first, which is there's
no business justification for doing

513
00:31:05,173 --> 00:31:09,343
local-first, if it's harder, if it's
more risky, if it's newer and weirder

514
00:31:09,343 --> 00:31:12,723
businesses won't do it, and if businesses
won't do it, it doesn't matter.

515
00:31:13,023 --> 00:31:15,573
You can have all the great ideas
in the world, but it won't matter.

516
00:31:16,076 --> 00:31:19,436
one of the things that I liked the
most about my time at Socket Supply is

517
00:31:19,436 --> 00:31:20,976
they really confronted this head on.

518
00:31:21,316 --> 00:31:26,736
And they said, if we build a world
where it is very compelling and

519
00:31:26,736 --> 00:31:31,416
straightforward for people to start
building in peer to peer communications

520
00:31:31,446 --> 00:31:35,766
into their apps, we really start
challenging the question of Why did

521
00:31:35,766 --> 00:31:37,276
you need the cloud in the first place?

522
00:31:37,526 --> 00:31:41,996
For most things, you didn't need the
cloud except that you did not have a way

523
00:31:42,006 --> 00:31:44,446
for two clients to speak to each other.

524
00:31:44,966 --> 00:31:48,496
But if we get rid of that,
then you stop needing to pay

525
00:31:48,496 --> 00:31:50,326
for most of your cloud bill.

526
00:31:50,606 --> 00:31:54,636
And that is one of the largest
overheads that companies face these

527
00:31:54,636 --> 00:31:57,106
days, and they're increasing in cost.

528
00:31:57,646 --> 00:32:01,226
No matter what your provider is, whether
they're more specific providers like

529
00:32:01,226 --> 00:32:05,676
Vercel or whether they're more broad
providers like the AWS's and Azure's

530
00:32:05,676 --> 00:32:10,236
and Google's of the world, your bills
are going up because you're doing

531
00:32:10,236 --> 00:32:11,716
more and more of your stuff there.

532
00:32:12,026 --> 00:32:14,986
And one of the reasons you're doing
it is because it was technologically

533
00:32:14,986 --> 00:32:16,866
easy to do so and less risky.

534
00:32:17,396 --> 00:32:20,828
But the other reason you were doing so
is because  somebody hadn't given you

535
00:32:20,828 --> 00:32:22,898
a business reason to do the reverse.

536
00:32:23,198 --> 00:32:27,088
one of the great things about
peer to peer designed systems is

537
00:32:27,098 --> 00:32:31,228
that the bigger the peer to peer
network, the lower the costs go.

538
00:32:31,668 --> 00:32:38,043
That's the opposite of, systems that are
centralized, the bigger the centralized

539
00:32:38,043 --> 00:32:39,863
system gets, the more expensive it gets.

540
00:32:39,873 --> 00:32:43,693
You don't get economies of scale and
you know, you're driving down your AWS

541
00:32:43,733 --> 00:32:45,543
bill, it goes up the more you scale.

542
00:32:45,793 --> 00:32:48,373
But in peer to peer systems, you
have this inverse relationship.

543
00:32:48,373 --> 00:32:51,823
So I think there's actually a
really compelling business case.

544
00:32:52,183 --> 00:32:57,103
For why companies who are trying to
figure out how do I cut down on my costs

545
00:32:57,453 --> 00:33:00,913
might be asking themselves, is there
any way that I could offload any of my

546
00:33:00,913 --> 00:33:03,033
cloud bill to peer to peer communication?

547
00:33:03,053 --> 00:33:06,563
And even if I did just a little bit
to start with and then realized, oh,

548
00:33:06,563 --> 00:33:08,283
that was great, and then I expand that.

549
00:33:08,763 --> 00:33:12,483
The more you expand that capability
of your apps, you will create.

550
00:33:12,663 --> 00:33:16,633
More compelling user experiences
than you will create in local-first.

551
00:33:16,653 --> 00:33:17,293
And that's important.

552
00:33:17,623 --> 00:33:22,453
But you'll also significantly reduce, and
maybe in some cases, completely eliminate

553
00:33:22,983 --> 00:33:25,514
the footprint of your cloud overhead bill.

554
00:33:25,524 --> 00:33:30,174
So that's number two, that I think there
is a really compelling business narrative

555
00:33:30,534 --> 00:33:35,099
to building a web where businesses
Can more easily compete without almost

556
00:33:35,109 --> 00:33:39,629
the rent seeking, landlord seeking,
Oh, we gave it to you for free when

557
00:33:39,629 --> 00:33:42,479
you were small, but now you're big and
we're going to just charge you an arm

558
00:33:42,479 --> 00:33:46,089
and a leg, and you can't get out from
underneath us, kind of thing like that.

559
00:33:46,099 --> 00:33:47,279
That's how drug dealers work.

560
00:33:47,709 --> 00:33:50,079
And that's just not a business
model we ought to be building

561
00:33:50,079 --> 00:33:51,319
the web on, in my opinion.

562
00:33:51,319 --> 00:33:53,419
So we have to fix that.

563
00:33:53,729 --> 00:33:54,949
That's pillar number two.

564
00:33:55,299 --> 00:33:56,399
And then pillar number three.

565
00:33:56,799 --> 00:34:01,449
I maybe personally feel the
strongest about, even more so

566
00:34:01,449 --> 00:34:02,839
than the ownership of data.

567
00:34:03,509 --> 00:34:08,699
I have been to many places in the
world that it is a reality that you do

568
00:34:08,699 --> 00:34:14,334
not have Unlimited internet and even
unlimited electricity to run your devices.

569
00:34:14,764 --> 00:34:18,804
I've been to, you know, rural towns
in Africa where people hang their cell

570
00:34:18,804 --> 00:34:22,924
phones off the light pole in the middle
of town to charge their phone all day.

571
00:34:23,274 --> 00:34:25,364
And it costs them a week's wages to do so.

572
00:34:25,394 --> 00:34:28,244
Like we take so many things for granted.

573
00:34:28,524 --> 00:34:30,184
The web should be.

574
00:34:30,454 --> 00:34:34,714
The largest human umbrella, the
largest umbrella that mankind has ever

575
00:34:34,714 --> 00:34:36,214
made, that humankind has ever made.

576
00:34:36,454 --> 00:34:41,004
It should be that, and it should
encompass, or be able to encompass, all

577
00:34:41,034 --> 00:34:42,754
8 plus billion people on the planet.

578
00:34:43,164 --> 00:34:46,224
Right now it's serving,
like, a third of the world.

579
00:34:46,654 --> 00:34:50,394
Two thirds of the world is not privileged
enough to experience the same web

580
00:34:50,404 --> 00:34:51,864
that you and I get to experience.

581
00:34:52,184 --> 00:34:54,974
They don't have an always on internet
connection like the way that we're

582
00:34:54,984 --> 00:34:56,424
recording this right now, right?

583
00:34:56,829 --> 00:35:00,829
They have spotty internet, or no internet
at all, and it's metered, it costs a lot.

584
00:35:01,196 --> 00:35:05,296
and we are not building a web where
they can participate, and, and where,

585
00:35:05,536 --> 00:35:08,426
and even if they can't participate,
they can't participate as equals.

586
00:35:08,466 --> 00:35:09,916
They don't have the same footing.

587
00:35:10,736 --> 00:35:15,306
We should be, I think morally, if
not for any other reason, building

588
00:35:15,336 --> 00:35:16,716
a web that they can participate.

589
00:35:16,746 --> 00:35:22,896
And I don't see any way I don't see any
way that we extend the web to the last

590
00:35:22,906 --> 00:35:24,716
two thirds of the world's population.

591
00:35:25,416 --> 00:35:28,741
simply because some billionaire
hangs a balloon up in the air to

592
00:35:28,751 --> 00:35:29,781
give them internet or whatever.

593
00:35:29,931 --> 00:35:31,101
Like, that's not the solution.

594
00:35:31,111 --> 00:35:32,341
That's how billionaires want to solve it.

595
00:35:32,891 --> 00:35:36,201
The way I want to solve it is from
the ground up, by rebuilding the web

596
00:35:36,211 --> 00:35:40,491
in a way that says, once you get the
information that you need, the data that

597
00:35:40,491 --> 00:35:45,011
you need, or create it, and once you
have the application, you don't need the

598
00:35:45,011 --> 00:35:46,451
internet to keep doing what you're doing.

599
00:35:46,451 --> 00:35:50,411
You're a local fish farmer, you're
working, you can upload the data into

600
00:35:50,411 --> 00:35:53,421
the thing, you can drive to market,
synchronize with the market, and

601
00:35:53,421 --> 00:35:56,471
sell your goods, and you don't need
a cloud server to do any of that.

602
00:35:56,686 --> 00:35:58,086
We should be building that world.

603
00:35:58,446 --> 00:36:03,726
So that's the third pillar of what I call
Web 2.5 is building a web that actually

604
00:36:03,726 --> 00:36:08,156
works for all of humankind instead of
only the privileged part of the world.

605
00:36:08,773 --> 00:36:09,853
I love those points.

606
00:36:09,883 --> 00:36:14,273
And I think this is where we can also now
like close the loop nicely, since I think

607
00:36:14,283 --> 00:36:19,623
all of those points are really, really
welcome and like really core of what

608
00:36:19,623 --> 00:36:22,063
the local-first movement is all about.

609
00:36:22,073 --> 00:36:26,122
And I think this is also what brought
you under this local-first umbrella.

610
00:36:26,462 --> 00:36:28,852
I love the last two points
that you've laid out.

611
00:36:28,852 --> 00:36:32,002
There is not just about the
second point where you made about,

612
00:36:32,255 --> 00:36:35,745
the bigger a centralized system
gets, the more expensive it gets.

613
00:36:36,155 --> 00:36:39,945
but I think it's also, if you
think about the developers who

614
00:36:39,945 --> 00:36:41,445
are the creators who are building.

615
00:36:41,665 --> 00:36:46,265
Smaller apps that have an ambition, maybe
similar to how I'm building Overtone.

616
00:36:46,645 --> 00:36:51,785
I actually, I want to charge for the,
the value that the app is creating

617
00:36:51,785 --> 00:36:56,402
for the quality of the app, for
like the differentiation of the app.

618
00:36:56,432 --> 00:37:03,585
I don't want to charge for, like someone's
internet usage and the data is actually

619
00:37:03,605 --> 00:37:06,365
in my way there to make that happen.

620
00:37:06,690 --> 00:37:13,192
like data shouldn't be part of my equation
for how I'm charging for something and to

621
00:37:13,192 --> 00:37:17,722
make matters even worse, maybe less so for
a music app or, but for many other apps,

622
00:37:17,722 --> 00:37:22,572
for example, let's say someone wants to
build another, like highly specialized

623
00:37:22,572 --> 00:37:24,327
and highly personalized health app.

624
00:37:24,767 --> 00:37:28,307
This is where it's not just maybe at
some point expensive to move the data

625
00:37:28,317 --> 00:37:33,337
around, but it's actually data can be
seen as a liability, particularly in

626
00:37:33,337 --> 00:37:35,207
a more highly regulated environment.

627
00:37:35,837 --> 00:37:41,457
And I think this is where encryption,
which we'll get into shortly as well, I

628
00:37:41,677 --> 00:37:44,537
think is a very nice antidote to that.

629
00:37:44,647 --> 00:37:49,160
And then the last point you've made
about, like that the web shouldn't just

630
00:37:49,180 --> 00:37:54,690
serve the highly privileged, fraction
of the world population, I think that's

631
00:37:54,700 --> 00:38:00,000
also very core to local-first and maybe
another meaning to local-first as well.

632
00:38:00,000 --> 00:38:05,000
Not just like that local-first,
the app works in your local

633
00:38:05,000 --> 00:38:10,290
context, but I think it's also
that an app should maybe be more.

634
00:38:10,565 --> 00:38:13,655
Locally created in the
context that you're working.

635
00:38:13,675 --> 00:38:19,045
We've explored that in the conversation
I had with Maggie Appleton a while ago.

636
00:38:19,289 --> 00:38:23,579
And I think this is really what's driving
her motivation around local-first.

637
00:38:23,919 --> 00:38:30,754
That de facto right now, most apps that
are out there are being built by like

638
00:38:30,984 --> 00:38:36,704
a very small group of people living in
Silicon Valley, living in New York, a

639
00:38:36,704 --> 00:38:39,364
few hub, like hubs within the world.

640
00:38:39,721 --> 00:38:43,890
but that's actually not where most of
the people are that are using the apps.

641
00:38:44,350 --> 00:38:49,980
If we address many of the underlying
challenges that we want to solve with

642
00:38:49,980 --> 00:38:55,295
local-first, I think this can also
empower and enable so many more local

643
00:38:55,345 --> 00:39:01,715
creators to build much more specialized
and custom apps for specific local

644
00:39:01,715 --> 00:39:04,475
parts of, different parts in the world.

645
00:39:04,835 --> 00:39:08,435
So I just want to offer that as an
extension to the last point you made.

646
00:39:09,010 --> 00:39:10,010
Yeah, 100%.

647
00:39:10,040 --> 00:39:10,650
I love that.

648
00:39:10,690 --> 00:39:14,607
You know, a good way of saying that
is that it's built by the privileged

649
00:39:14,617 --> 00:39:18,347
for the privileged, but why not let
everybody build what, you know, I'm

650
00:39:18,347 --> 00:39:21,127
never going to be able to understand
what that fish farmer needs, but if we

651
00:39:21,127 --> 00:39:24,607
can empower him to build the thing that
he needs, he'll understand it better.

652
00:39:24,607 --> 00:39:29,537
And he would be in a much better position
to build an experience that works for him.

653
00:39:29,547 --> 00:39:34,297
We need to create the pieces of that
puzzle for other people to assemble

654
00:39:34,297 --> 00:39:37,357
rather than assuming I'm not going
to build all the world's apps.

655
00:39:37,377 --> 00:39:40,857
I know that I'm hopefully going to
build a couple of Lego pieces that

656
00:39:40,857 --> 00:39:42,837
will be useful in many of those apps.

657
00:39:43,180 --> 00:39:43,660
Awesome.

658
00:39:43,680 --> 00:39:47,570
So let's shift gears a little bit and
get a little bit more technical since

659
00:39:47,580 --> 00:39:52,600
one ingredient we'll need to make all
of this happen is not just moving data

660
00:39:52,610 --> 00:39:56,830
around, which we've explored in many other
conversations on this podcast so far.

661
00:39:57,200 --> 00:40:02,875
But one particular aspect of that is
also that like, not just two random

662
00:40:02,875 --> 00:40:07,945
devices are exchanging data in a
completely trustless way, but a device

663
00:40:07,995 --> 00:40:13,055
might also be owned by a person who
has a particular identity or might even

664
00:40:13,105 --> 00:40:18,040
on that given device have maybe there
might be multiple identities at play.

665
00:40:18,430 --> 00:40:20,920
And so how do you retain an identity?

666
00:40:20,970 --> 00:40:27,264
How do you, kind of exchange identity
information, that your, I love the way

667
00:40:27,264 --> 00:40:31,810
how you put it, like your device ring,
how all of those devices can trust each

668
00:40:31,810 --> 00:40:35,390
other, how all of that is made work,
how, and I think there's this typical

669
00:40:35,410 --> 00:40:40,660
tension in security where if you want
to make it secure, that often comes at

670
00:40:40,660 --> 00:40:42,710
the cost of convenience and vice versa.

671
00:40:43,080 --> 00:40:44,100
And that's sort of.

672
00:40:44,335 --> 00:40:47,695
Sweet middle ground where it's
both convenient and secure.

673
00:40:47,745 --> 00:40:49,335
I think that's also very tricky.

674
00:40:49,725 --> 00:40:54,045
So this is an area that you've really
deeply explored and you've built a

675
00:40:54,095 --> 00:40:55,902
whole bunch of different projects.

676
00:40:56,085 --> 00:41:00,006
I think one of them is
being the Lofi.ID, project.

677
00:41:00,202 --> 00:41:03,392
You also have another project
on GitHub called Local Vault.

678
00:41:03,792 --> 00:41:07,632
So maybe you want to give us an
introduction to what you've been

679
00:41:07,632 --> 00:41:10,732
working on there, and then we
can take it one step at a time.

680
00:41:11,114 --> 00:41:13,554
Yeah, so big picture overview.

681
00:41:13,933 --> 00:41:19,016
is that if you are going to own data
on your device, and that's going to be

682
00:41:19,036 --> 00:41:23,736
the source of authority for that data,
which is the premise for local-first,

683
00:41:24,296 --> 00:41:29,386
then I believe that you both need to
be able to secure that data, meaning

684
00:41:29,386 --> 00:41:33,196
securing it at rest, which involves
encryption, and you're going to be

685
00:41:33,196 --> 00:41:38,926
able to need to Securely ensure that
data goes only where you want it to go.

686
00:41:39,446 --> 00:41:43,416
Plain text data being sent around
and backed up in other places,

687
00:41:43,446 --> 00:41:44,416
that's not going to cut it.

688
00:41:44,776 --> 00:41:49,206
So we are going to need encryption
to be part of this equation.

689
00:41:49,626 --> 00:41:54,401
And To boil a lot of real complicated
technology down to hopefully

690
00:41:54,401 --> 00:41:58,911
something that just about anybody
can understand, we have this who's

691
00:41:58,931 --> 00:42:01,451
protecting the master key problem.

692
00:42:02,231 --> 00:42:06,611
No matter what encryption scheme you
design, whether it's password based,

693
00:42:06,631 --> 00:42:11,401
where you derive an encryption key from
something that I type in, or whether

694
00:42:11,401 --> 00:42:15,211
it's I've generated a key and I'm going
to Randomly, and that is your encryption

695
00:42:15,211 --> 00:42:19,611
key, no matter which mechanism, or there's
a bunch of other variations thereof,

696
00:42:19,631 --> 00:42:24,148
but no matter which mechanism you have,
you have this kind of encryption upon

697
00:42:24,198 --> 00:42:27,688
encryption upon encryption, but at the
very top of that chain, you have the

698
00:42:27,688 --> 00:42:30,058
master key, the master password, whatever.

699
00:42:30,278 --> 00:42:31,893
And how do you protect that?

700
00:42:32,283 --> 00:42:33,853
That's the common problem.

701
00:42:33,853 --> 00:42:37,763
And in fact, going all the way back
to the work that I did at Hero,

702
00:42:37,783 --> 00:42:41,983
the Web3 company that I worked at,
they had a very similar problem.

703
00:42:41,983 --> 00:42:45,309
They were trying to create smart
contracts around the Bitcoin chain with

704
00:42:45,319 --> 00:42:50,374
the separate blockchain, and they needed
the ability to, you know, to round trip

705
00:42:50,720 --> 00:42:56,158
transactions in a completely trustless
way between one blockchain and the Bitcoin

706
00:42:56,158 --> 00:42:57,298
blockchain, between Stacks and Bitcoin.

707
00:42:57,658 --> 00:43:00,768
And they have this exact same
problem, which is who's going

708
00:43:00,768 --> 00:43:01,908
to hold the master keys?

709
00:43:01,938 --> 00:43:03,778
And how are you going to do
that in the open, but not

710
00:43:03,778 --> 00:43:04,768
let everybody have it, right?

711
00:43:04,768 --> 00:43:10,248
So we always run into this problem of It
all sounds well and great until we get

712
00:43:10,248 --> 00:43:13,368
to the final piece of the puzzle, which
is how do you handle the master password?

713
00:43:13,768 --> 00:43:16,218
I've been banging my head on
this for years, trying to figure

714
00:43:16,218 --> 00:43:17,498
out there's got to be some way.

715
00:43:18,038 --> 00:43:23,228
And the advent of biometric passkeys
was when the lightbulb went off for me.

716
00:43:23,858 --> 00:43:28,998
Because What Passkeys do and what
the biometric subsystems on these

717
00:43:28,998 --> 00:43:34,548
devices do is they offer a, I think,
compelling answer to that question,

718
00:43:34,548 --> 00:43:41,348
which is there is no perfect storage
for the most secure root, master,

719
00:43:41,368 --> 00:43:42,818
passkey, whatever you call it.

720
00:43:43,078 --> 00:43:47,518
There's no perfect solution, but the
best that we can get is dedicated

721
00:43:47,528 --> 00:43:53,428
hardware on the device that is not
Just free and open to any app, right?

722
00:43:53,458 --> 00:43:58,158
If we can have a dedicated hardware
for this purpose, the secure enclave or

723
00:43:58,158 --> 00:44:01,288
whatever it's called, and then we can
have operating systems that are designed

724
00:44:01,288 --> 00:44:06,158
to very strong, strictly control access
to that, and it's designed in like a

725
00:44:06,158 --> 00:44:08,298
write only way, you cannot read from it.

726
00:44:08,328 --> 00:44:10,978
You can write to it once, and
then you can never read from it.

727
00:44:11,258 --> 00:44:15,728
You can send data in and get results
back out, but you can never ask that

728
00:44:15,728 --> 00:44:17,368
thing to give you its private key.

729
00:44:17,608 --> 00:44:21,568
That really offers, I think, the most
compelling answer we've had so far

730
00:44:21,588 --> 00:44:24,028
to where do we store the master key?

731
00:44:24,488 --> 00:44:28,888
But one of the big problems with that,
it's not in and of itself a solution

732
00:44:28,888 --> 00:44:31,648
to this, to this question is because.

733
00:44:32,493 --> 00:44:34,953
I don't have access to that key.

734
00:44:34,953 --> 00:44:39,433
That means I can't use that key
for encryption purposes myself.

735
00:44:40,043 --> 00:44:45,353
I can create a passkey with my thumbprint
or my face or whatever, but I can't

736
00:44:45,363 --> 00:44:49,303
get access to that key material to
use it for my own encryption purposes.

737
00:44:49,703 --> 00:44:54,703
And I couldn't figure out how we were
going Make passkeys work in a zero

738
00:44:54,703 --> 00:44:58,253
server assumption where there's no
servers and in a way that I could

739
00:44:58,933 --> 00:45:01,183
piggyback upon it to create encryption.

740
00:45:01,553 --> 00:45:06,293
And then it occurred to me that we can
actually bury the key material in the

741
00:45:06,293 --> 00:45:11,153
passkey by way of the user ID field,
or there's actually another mechanism

742
00:45:11,153 --> 00:45:14,503
that is coming along that I think
will be even better than the user ID.

743
00:45:14,503 --> 00:45:18,213
But the main point is, we can actually
piggyback on top of these passkeys.

744
00:45:18,493 --> 00:45:22,403
And in this secure part of the
device, store something in a way

745
00:45:22,403 --> 00:45:27,278
that I think is maybe 99 percent
guaranteeable, that's a lot better

746
00:45:27,278 --> 00:45:31,418
than almost 0 percent guaranteeable
with anything that's in userland apps.

747
00:45:31,688 --> 00:45:32,508
Is it perfect?

748
00:45:32,578 --> 00:45:32,878
No.

749
00:45:33,348 --> 00:45:39,658
But it's absolutely a, you know, a
paradigm step up in terms of security.

750
00:45:39,968 --> 00:45:43,438
And so the whole rest of everything
that I'm building is based on that

751
00:45:43,448 --> 00:45:46,868
one assumption, which is where we're
going to solve the master passkey

752
00:45:46,868 --> 00:45:50,108
problem is by basing this on passkeys.

753
00:45:50,541 --> 00:45:53,661
That does have some
questions that it raises.

754
00:45:54,001 --> 00:45:56,981
How are we going to onboard apps?

755
00:45:57,826 --> 00:46:01,996
on devices that do not already
have biometric capabilities.

756
00:46:01,996 --> 00:46:03,816
They don't have these secure hardware.

757
00:46:04,106 --> 00:46:07,406
I think the good news is that more
and more devices are getting that.

758
00:46:07,446 --> 00:46:08,716
And I think that will continue.

759
00:46:08,716 --> 00:46:12,176
I don't think we will see a,
you know, a pullback in that.

760
00:46:12,406 --> 00:46:15,496
I think we will see more and more
devices getting those capabilities.

761
00:46:15,506 --> 00:46:19,326
So over time that becomes less and
less of a problem, but we do need

762
00:46:19,326 --> 00:46:23,806
an exit ramp for not just telling
somebody, sorry, you're out of luck.

763
00:46:24,186 --> 00:46:29,866
So I've been working on some ideas
around creating kind of a secondary

764
00:46:29,886 --> 00:46:33,706
way of doing things that's not
biometrics based, pattern drawing

765
00:46:33,706 --> 00:46:37,016
that's more complicated and can
create more entropy, things like that.

766
00:46:37,336 --> 00:46:39,976
So I think we do need some exit
ramps there, but I'm going to make

767
00:46:39,976 --> 00:46:44,616
the assumption that for the primary
class of devices that we want to

768
00:46:44,616 --> 00:46:46,986
target here, we have the biometrics.

769
00:46:47,386 --> 00:46:49,526
Once we have that, once
we have that capability.

770
00:46:49,796 --> 00:46:54,066
We needed a way to be able to manage
pass keys without relying upon servers.

771
00:46:54,586 --> 00:46:59,306
So the first library that I wrote
was WebAuthn Local Client, which was

772
00:46:59,316 --> 00:47:03,786
designed to wrap around the web API
that exposes the passkey subsystem,

773
00:47:04,196 --> 00:47:07,256
but doesn't make any assumptions
about communicating with the server.

774
00:47:07,703 --> 00:47:13,243
the use cases in local-first don't need
what the server would do anyway, so that's

775
00:47:13,243 --> 00:47:17,663
not a problem, but it's just no other
libraries out there that I had found where

776
00:47:17,663 --> 00:47:19,483
it could work if you didn't have a server.

777
00:47:19,483 --> 00:47:23,853
So I wrote a library that exposed
that API in a way that made the

778
00:47:23,853 --> 00:47:26,563
assumption you weren't going
to communicate with the server.

779
00:47:26,563 --> 00:47:28,523
You were going to store things securely.

780
00:47:28,753 --> 00:47:31,213
You were going to generate
the challenges on device.

781
00:47:31,223 --> 00:47:35,513
You were going to keep track of
the key and verify that was coming

782
00:47:35,513 --> 00:47:36,683
out was not man in the middle.

783
00:47:36,693 --> 00:47:37,573
You were going to do all of that.

784
00:47:37,898 --> 00:47:39,478
on device, not on server.

785
00:47:40,048 --> 00:47:41,868
So that's what WebAuthn local client was.

786
00:47:41,878 --> 00:47:43,978
That was the first little
piece of the puzzle.

787
00:47:45,158 --> 00:47:51,708
Then I said, okay, well now we need a
way to, piggyback on top of the passkey

788
00:47:51,708 --> 00:47:55,508
system and create something that we can
use for encryption purposes so that we can

789
00:47:55,528 --> 00:47:58,398
protect data both at rest and in transit.

790
00:47:58,545 --> 00:47:59,345
we need some keys.

791
00:47:59,345 --> 00:48:01,545
And I did a lot of research in this.

792
00:48:01,575 --> 00:48:02,675
I'm not an expert.

793
00:48:02,675 --> 00:48:03,825
I'm not a mathematician.

794
00:48:04,185 --> 00:48:09,648
But I settled on, this was back when I was
working at Socket, I settled on, Elliptic

795
00:48:09,688 --> 00:48:17,328
Curve keys, specifically the Edwards
key, the ED25519 key pair as the best

796
00:48:17,538 --> 00:48:21,938
master key pair because you can generate,
that can be used for signing, and you

797
00:48:21,938 --> 00:48:23,738
can generate a sub key pair from that.

798
00:48:23,876 --> 00:48:28,136
That's the Curve 25519 keys
for encryption and decryption.

799
00:48:28,136 --> 00:48:31,396
I settled on that as the best, but
that's not the only way of doing it.

800
00:48:31,396 --> 00:48:34,466
And certainly anybody else could
substitute their own encryption,

801
00:48:34,816 --> 00:48:38,686
or maybe we're going to need to
upgrade that encryption in a post

802
00:48:38,686 --> 00:48:40,456
quantum world in some few years.

803
00:48:40,456 --> 00:48:43,786
But, that's where I landed was,
let's use that, because I think

804
00:48:43,786 --> 00:48:45,536
that's good enough and strong enough.

805
00:48:45,956 --> 00:48:49,636
And I found the Libsodium library,
which is big and complex, but it's,

806
00:48:49,636 --> 00:48:52,906
I been ported to tons of platforms
and that was important to me.

807
00:48:53,446 --> 00:48:59,016
And so I based the ideas around securing
our data on that type of key pair.

808
00:48:59,016 --> 00:49:02,816
So we generate a 25519 key pair.

809
00:49:03,326 --> 00:49:07,646
We take the seed of that, or in my
library, I call it an IV, but IV

810
00:49:07,646 --> 00:49:08,986
or seed, we take the seed of that.

811
00:49:09,016 --> 00:49:10,646
And that's what we store in the passkey.

812
00:49:11,126 --> 00:49:14,696
And with that information coming back
out, each time you put your thumbprint

813
00:49:14,706 --> 00:49:19,456
or your face ID in, you can reconstitute
that key pair and then decrypt

814
00:49:19,466 --> 00:49:21,206
whatever data was previously encrypted.

815
00:49:21,846 --> 00:49:25,816
That is how we fix that
master password problem.

816
00:49:26,176 --> 00:49:30,756
So I built a library to help you do that
and that's called local datalock is the

817
00:49:30,756 --> 00:49:35,273
library that wraps around the WebAuthn
local client, but then it does the

818
00:49:35,283 --> 00:49:40,033
generated encryption key, stick the seed
into the passkey, it does all that stuff.

819
00:49:41,016 --> 00:49:43,306
it does not do anything
about storage of it.

820
00:49:43,851 --> 00:49:44,131
Right?

821
00:49:44,131 --> 00:49:47,781
So you might use local data lock when
all you care about was transmitting

822
00:49:47,781 --> 00:49:52,731
secure data, but it does provide
the pieces for the next one.

823
00:49:52,921 --> 00:49:58,861
The next one was we need to figure out
how we're going to store that data in

824
00:49:58,861 --> 00:50:01,011
an encrypted fashion on the device.

825
00:50:01,291 --> 00:50:05,001
And then, so it's encrypted on
write and decrypted on read.

826
00:50:05,031 --> 00:50:05,681
How are we going to do that?

827
00:50:06,076 --> 00:50:09,146
Well, I actually realized I need
two pieces, not only one to manage

828
00:50:09,146 --> 00:50:12,336
the encryption piece, but actually
I needed a library to manage the

829
00:50:12,336 --> 00:50:15,556
storage piece, because there's
a lot of different variations of

830
00:50:15,556 --> 00:50:18,416
storage, as we were just talking
about with OPFS and things like that.

831
00:50:19,016 --> 00:50:22,881
So I built the Two libraries
to help with this piece.

832
00:50:22,901 --> 00:50:28,641
One library is, I've spun out actually,
it's not even local-first really, it's its

833
00:50:28,641 --> 00:50:34,961
own thing, which is just abstracting local
client storage in a key value way across

834
00:50:35,121 --> 00:50:37,101
all the five major storage mechanisms.

835
00:50:37,101 --> 00:50:42,121
So cookies, local storage, session
storage, indexDB, and OPFS.

836
00:50:42,621 --> 00:50:45,431
And technically under OPFS, there's
two different ways of managing it.

837
00:50:45,461 --> 00:50:51,321
One is more device limited, but
it's the in thread communication

838
00:50:51,331 --> 00:50:53,005
that you can do, asynchronously.

839
00:50:53,335 --> 00:50:58,565
But the more broader device support,
basically all devices at this

840
00:50:58,565 --> 00:51:02,325
point, or all modern devices at
this point, is OPFS in a worker.

841
00:51:02,888 --> 00:51:06,078
and if you do OPFs in a worker, which
you're nodding because you've seen

842
00:51:06,078 --> 00:51:09,658
the same problem, but managing workers
and all of that stuff is difficult.

843
00:51:09,658 --> 00:51:13,328
So that's what this library does, is it
abstracts across all of those mechanisms

844
00:51:13,638 --> 00:51:16,968
the exact same asynchronous key value API.

845
00:51:17,311 --> 00:51:19,261
And that library is called Storage.

846
00:51:19,491 --> 00:51:23,361
It's part of my BYOJS Bring
Your Own JavaScript initiative.

847
00:51:23,668 --> 00:51:24,748
so we'll have a link to that.

848
00:51:24,748 --> 00:51:27,998
But that storage library, even if
you didn't do anything local-first,

849
00:51:28,218 --> 00:51:31,218
you just wanted to store data, I
think that would be useful to help.

850
00:51:31,228 --> 00:51:34,638
Think of it as kind of a more
modern Local Forage, maybe.

851
00:51:34,968 --> 00:51:38,718
Local forage has been around for a decade,
but it's not really maintained anymore,

852
00:51:38,728 --> 00:51:41,108
and it didn't support all the mechanisms.

853
00:51:41,933 --> 00:51:47,133
I think storage is a compelling
option to look at if you're sticking

854
00:51:47,133 --> 00:51:50,433
anything on a local device, even in
local storage, maybe have a better

855
00:51:50,433 --> 00:51:52,623
API and a more secure API for that.

856
00:51:53,053 --> 00:51:55,793
So first of all, storage there, that
has nothing to do with encryption.

857
00:51:55,793 --> 00:52:00,303
It's just The raw reading
and writing from a disk.

858
00:52:00,513 --> 00:52:03,343
And then the last piece of the puzzle,
the one you mentioned before, is the

859
00:52:03,343 --> 00:52:08,260
local data vault . So that library is
what takes storage, WebAuthn, local data

860
00:52:08,260 --> 00:52:15,396
lock, and all those pieces together,
and gives you that local vault,  which

861
00:52:15,406 --> 00:52:20,886
is a secure, encryption secured, based
on passkeys, encrypt on write, Decrypt

862
00:52:20,916 --> 00:52:23,216
on read key value storage mechanism.

863
00:52:23,566 --> 00:52:26,736
And you can, of course, choose which
of those places you want to store, like

864
00:52:27,216 --> 00:52:29,956
store it in IndexedDB or store it in OPFS.

865
00:52:29,996 --> 00:52:32,926
But it does all the encryption
and decryption stuff for you

866
00:52:33,216 --> 00:52:35,136
based on the passkey subsystem.

867
00:52:35,486 --> 00:52:37,656
So that's what I've built so far.

868
00:52:38,106 --> 00:52:43,335
Where all of that is going
is towards, there's two ways

869
00:52:43,335 --> 00:52:44,495
that I see this happening.

870
00:52:44,525 --> 00:52:49,045
First of all, I think apps can start
to use, web apps can start to use those

871
00:52:49,055 --> 00:52:54,245
libraries, whatever pieces of that makes
sense to you, use all of it, use part of

872
00:52:54,245 --> 00:52:58,025
it, but start to use those pieces to do
some of this stuff yourself in your own

873
00:52:58,025 --> 00:53:00,850
apps, build your own solution if you want.

874
00:53:01,280 --> 00:53:04,560
I also think that we need to
lower the barrier for apps

875
00:53:04,600 --> 00:53:05,950
to do a lot of this stuff.

876
00:53:05,990 --> 00:53:09,240
And I also think that the more
consolidated of approach we get,

877
00:53:09,770 --> 00:53:12,640
the better chance we have of
something like this catching on.

878
00:53:12,936 --> 00:53:17,216
And so instead of just writing like
a standards doc and saying, if you do

879
00:53:17,216 --> 00:53:19,096
it, you have, you must do it this way.

880
00:53:19,266 --> 00:53:24,556
the approach I'm going to take is to
build a companion Wallet app that allows

881
00:53:24,556 --> 00:53:29,760
you to manage as a user, any number
of your own identities, Protected, of

882
00:53:29,760 --> 00:53:31,530
course, through this passkey subsystem.

883
00:53:32,040 --> 00:53:36,750
And apps will have an SDK that they
can interact with the Wallet app,

884
00:53:37,450 --> 00:53:40,420
whether that Wallet app is a browser
extension, like we mentioned a little

885
00:53:40,420 --> 00:53:44,250
while ago, or whether it's a literal
actual side, you know, companion app.

886
00:53:44,610 --> 00:53:48,270
They'll be able to interact
with that app to ask that app,

887
00:53:48,820 --> 00:53:50,930
Hey, tell me who this user is.

888
00:53:51,310 --> 00:53:53,710
Tell me that it's the same
user as they were before.

889
00:53:53,740 --> 00:53:54,680
That's one question.

890
00:53:55,070 --> 00:53:57,530
So instead of them needing to build
their own authentication, they'll

891
00:53:57,530 --> 00:54:01,678
simply make a call to this Wallet and
say, verify for me that this user is

892
00:54:01,678 --> 00:54:05,488
who they say they are and give me back
their identifier, which might be their

893
00:54:05,498 --> 00:54:07,998
key or some other UUID that you specify.

894
00:54:08,848 --> 00:54:09,748
That's one question.

895
00:54:09,748 --> 00:54:15,218
But also I think those apps shouldn't need
to roll their own encrypt all of my data

896
00:54:15,218 --> 00:54:17,148
and decrypt it all and all of that stuff.

897
00:54:17,268 --> 00:54:22,518
So they'll also be able to provide
the data to the Wallet app and ask

898
00:54:22,518 --> 00:54:26,638
it to encrypt it for them through
that SDK and decrypt it for them.

899
00:54:26,898 --> 00:54:28,928
And again, based all
of that around passkey.

900
00:54:28,988 --> 00:54:30,778
So they don't need to
invent any of that stuff.

901
00:54:30,818 --> 00:54:32,658
The Wallet app will just
take care of it for them.

902
00:54:33,348 --> 00:54:35,318
And then the last piece of the puzzle is.

903
00:54:35,735 --> 00:54:39,325
if you build an app, let's say like
it's a, you know, it's a note taking

904
00:54:39,355 --> 00:54:41,865
app, or it's a social media app,
or whatever, and it does need to

905
00:54:41,875 --> 00:54:46,655
communicate with other devices, instead
of you doing your own synchronization

906
00:54:46,655 --> 00:54:50,695
logic, I think we can actually have
the Wallet app built with peer to peer

907
00:54:50,695 --> 00:54:55,135
capabilities so that my Wallet app on
my phone and my Wallet app on my laptop

908
00:54:55,135 --> 00:54:58,355
and on my tablet can synchronize my
identities, but can also synchronize

909
00:54:58,765 --> 00:55:01,515
userland app data through the Wallet.

910
00:55:01,535 --> 00:55:03,995
Use the Wallet as a tunnel
to do synchronization.

911
00:55:04,255 --> 00:55:10,140
when I say synchronization, I do not
mean that I'm solving anything that what,

912
00:55:10,250 --> 00:55:13,580
what the larger local-first community
says when they say synchronization

913
00:55:13,580 --> 00:55:17,190
with all the CRDTs and all the
merging and stuff that I want to

914
00:55:17,190 --> 00:55:19,380
leave open to this community to solve.

915
00:55:19,410 --> 00:55:21,480
You can plug in whatever.

916
00:55:21,750 --> 00:55:25,450
CRDT systems you think make sense and
whatever strategies you make sense.

917
00:55:25,830 --> 00:55:29,960
I'm simply going to provide the transport
layer through peer to peer various peer

918
00:55:29,960 --> 00:55:34,790
to peer technologies in this Wallet app
so that those bits can get from my phone

919
00:55:34,790 --> 00:55:36,920
to my watch, to my laptop, to my tablet.

920
00:55:37,170 --> 00:55:40,290
And then you'll, your app will
decide what do we do with that?

921
00:55:40,590 --> 00:55:44,050
In your own app logic, you'll decide
how do we merge these competing

922
00:55:44,050 --> 00:55:45,350
sets of bits that are coming in.

923
00:55:46,105 --> 00:55:49,855
I just don't want for people to have to
go invent all of their own wheels there.

924
00:55:49,875 --> 00:55:54,365
And I think a single unified Wallet
app will allow people to do that.

925
00:55:54,741 --> 00:55:57,261
there's other things that I want that
Wallet app to do, but that's kind

926
00:55:57,261 --> 00:55:59,751
of the main, starting point, the 1.

927
00:55:59,791 --> 00:56:02,721
0 that I want this Wallet app
to do is to give that to the

928
00:56:02,721 --> 00:56:07,011
local-first community and say, please
consider building upon that Lego.

929
00:56:07,489 --> 00:56:07,899
Perfect.

930
00:56:07,929 --> 00:56:14,176
So this was a lot and, kudos to you
for doing such comprehensive research,

931
00:56:14,496 --> 00:56:16,516
deliberating the different options.

932
00:56:16,516 --> 00:56:20,806
There's always like so many different
paths that you could go in regards

933
00:56:20,806 --> 00:56:25,333
to like all of the different
decryption encryption mechanisms, like

934
00:56:25,733 --> 00:56:27,573
choosing, should you use Libsodium?

935
00:56:27,593 --> 00:56:29,393
Should you use WebCrypto?

936
00:56:29,393 --> 00:56:32,693
Should you use other things, for
what it's worth for Overtone?

937
00:56:32,703 --> 00:56:36,993
I've also landed on using
Libsodium, which, I needed to even

938
00:56:36,993 --> 00:56:40,503
compile my own WASM version to
trim it down a little bit more.

939
00:56:40,569 --> 00:56:44,639
but, yeah, so you've covered a
lot of ground there and I have

940
00:56:44,639 --> 00:56:48,329
a few follow up questions where
I would love to learn more.

941
00:56:48,576 --> 00:56:53,306
also one observation that I just,
as someone who appreciates like

942
00:56:53,386 --> 00:56:57,826
good terminologies and clear
concepts, I just love the term Vault.

943
00:56:58,181 --> 00:57:02,811
As something that, both signals like, Hey,
this is something where it can put stuff

944
00:57:02,851 --> 00:57:05,821
in and get stuff out and it is secure.

945
00:57:05,911 --> 00:57:11,061
So a vault being sort of that combination
of your storage mechanism and that

946
00:57:11,061 --> 00:57:14,751
search mechanism has nothing to do
with encryption at that point, but if

947
00:57:14,751 --> 00:57:18,761
you then combine it with encryption
and decryption, that makes a vault.

948
00:57:19,031 --> 00:57:24,521
I think that's a very intuitive concept
that is, that works both as a concept for

949
00:57:24,661 --> 00:57:28,151
developers, as well as even for end users.

950
00:57:28,491 --> 00:57:33,731
like I think this is what also 1Password,
for example, has started to use.

951
00:57:33,731 --> 00:57:37,964
And I think, 1Password users are
familiar with that also, I'm sure

952
00:57:37,964 --> 00:57:40,004
for other password managers as well.

953
00:57:40,504 --> 00:57:44,544
And so that as a concept, I
hope that it's not just a.

954
00:57:44,828 --> 00:57:49,808
a concept that is used within the
local vault and like the stack that

955
00:57:49,808 --> 00:57:53,498
you're exploring here but hopefully
that's something that as a term,

956
00:57:53,781 --> 00:57:55,801
can be useful for others as well.

957
00:57:56,401 --> 00:57:57,041
Yeah, I agree.

958
00:57:57,041 --> 00:57:59,274
I think it does communicate
what it needs to.

959
00:57:59,614 --> 00:58:03,004
I workshopped that with some of my
social media community, by the way.

960
00:58:03,294 --> 00:58:06,794
I had lots of different suggestions and
I, you know, kind of pieced together

961
00:58:06,794 --> 00:58:10,178
various things, but I workshopped
some of the naming of this, you know,

962
00:58:10,188 --> 00:58:13,378
crowdsourced it because I wanted to
make sure I got a name that really

963
00:58:13,398 --> 00:58:16,151
communicated properly, what I was up to.

964
00:58:16,546 --> 00:58:19,866
So to me, it sounds like you've landed
on a great option here and I might

965
00:58:20,066 --> 00:58:25,553
actually steal that for myself and,
the ways how I'm like in my own data

966
00:58:25,573 --> 00:58:28,956
stack, where I have a database right
now, it's not encrypted address,

967
00:58:28,996 --> 00:58:30,586
but I want to encrypt it more.

968
00:58:30,986 --> 00:58:35,036
And so maybe I can also use
for the SQLite database there.

969
00:58:35,256 --> 00:58:38,176
Maybe I can also start calling
that a vault if it's encrypted.

970
00:58:38,176 --> 00:58:38,996
I like that a lot.

971
00:58:39,434 --> 00:58:43,214
and I also like how you've
already thought a step further.

972
00:58:43,524 --> 00:58:48,294
it's not just as that, like as a tech
stack that can be implemented by a

973
00:58:48,294 --> 00:58:53,611
given apps or high level libraries,
but also from a user perspective, if

974
00:58:53,621 --> 00:58:57,131
you're not just going to use one app,
the kind of part of the entire promise

975
00:58:57,131 --> 00:59:01,901
here is that, like here you have data
in one app and data in another app.

976
00:59:02,236 --> 00:59:06,596
That, and maybe those apps want to
work together and that is actually

977
00:59:06,596 --> 00:59:11,816
something that is like really, really
difficult in today's web2 world.

978
00:59:12,146 --> 00:59:15,506
Where like, just think about
like how much of an effort it is.

979
00:59:15,526 --> 00:59:16,946
That's maybe the best we got.

980
00:59:16,946 --> 00:59:22,591
Maybe it's like a Slack, integration
that like Slack is like a little bit more

981
00:59:22,611 --> 00:59:26,141
aware of like what that Figma link means.

982
00:59:26,621 --> 00:59:29,094
And,  I can open it all in my browser.

983
00:59:29,094 --> 00:59:31,854
So from my perspective, it kind
of feels like, Oh my gosh, why

984
00:59:31,854 --> 00:59:33,224
don't you have that context?

985
00:59:33,494 --> 00:59:36,944
So if we, embrace a little
bit more of the user.

986
00:59:37,094 --> 00:59:43,574
The identity concepts, and then also let,
that dictate a little bit of the share,

987
00:59:43,574 --> 00:59:45,554
the context sharing and access control.

988
00:59:45,554 --> 00:59:48,764
I think that can lead to
much better user experiences.

989
00:59:49,130 --> 00:59:54,191
there've been many, many years of
attempts to create in the mobile space.

990
00:59:54,264 --> 00:59:58,814
there was like web intents and then
web share and share intents and like

991
00:59:58,814 --> 01:00:02,934
all these other variations and it went
through various different names and

992
01:00:03,254 --> 01:00:05,314
standards processes stumbled with it.

993
01:00:05,534 --> 01:00:08,854
I don't even know where that currently
stands, but that's exactly where I'm

994
01:00:08,854 --> 01:00:13,664
headed is basically, let's just get around
any of those limitations and allow, for

995
01:00:13,664 --> 01:00:18,351
example, a use case where, you know, I
might be in a local-first note taking app,

996
01:00:18,691 --> 01:00:22,261
and I might have written a note and I want
to, you know, copy a piece of that note,

997
01:00:22,261 --> 01:00:26,851
and I want to send that out to one of my
text messaging recipients or one of my

998
01:00:26,851 --> 01:00:31,546
chat recipients or whatever, so I can take
that note and I can synchronize, I can

999
01:00:31,546 --> 01:00:36,356
share that information to this other app
in a fully secure, end to end secured way.

1000
01:00:36,536 --> 01:00:40,656
But it ends up in my other app, and
that other app pops up, and there it is,

1001
01:00:40,786 --> 01:00:44,956
in the exact same way that, you know,
you can currently do sharing intents.

1002
01:00:45,216 --> 01:00:50,666
Native apps have that, but the web has
always been, you know, a third class

1003
01:00:50,676 --> 01:00:57,316
citizen at best in that sort of cross
app collaboration and in sharing story.

1004
01:00:57,526 --> 01:01:00,616
And I think we can make it a
fully first class story this way.

1005
01:01:01,176 --> 01:01:05,076
And I think that also takes us in
possibly even a step further that

1006
01:01:05,076 --> 01:01:07,266
goes beyond today's conversation.

1007
01:01:07,349 --> 01:01:12,269
so far we talked about identity
and also a part of that identity is

1008
01:01:12,269 --> 01:01:17,559
like authenticating as assuming that
identity or being denied that identity.

1009
01:01:17,873 --> 01:01:24,473
that's often abbreviated as Auth, but
Auth can also mean another non abbreviated

1010
01:01:24,483 --> 01:01:29,663
word, which is authorization, which I
think this is not yet covering that,

1011
01:01:29,736 --> 01:01:34,126
but there, I want to plug another very
interesting project that is more around

1012
01:01:34,196 --> 01:01:36,689
authorization, which is called Beehive.

1013
01:01:37,016 --> 01:01:40,916
that's also been published on
the Ink and Switch website.

1014
01:01:41,170 --> 01:01:44,006
and there's currently,
I think, not yet a full.

1015
01:01:44,442 --> 01:01:49,990
Inc & Switch style essay about that, but
there are some notes being taken on this.

1016
01:01:50,030 --> 01:01:54,530
And so this is a project that, Brooklyn
Zelenka and Alex Good is currently

1017
01:01:54,530 --> 01:02:00,663
working on that is, also ongoing
research in combination with AutoMerge.

1018
01:02:00,914 --> 01:02:05,439
And Brooklyn has been exploring a lot
of that, as her previous work On vision

1019
01:02:05,489 --> 01:02:10,863
and related projects, so, and this is
where, the authorization concepts to my

1020
01:02:10,863 --> 01:02:17,009
understanding is sort of based around
the ideas of capabilities and, that

1021
01:02:17,019 --> 01:02:22,551
different users can basically, share
capabilities, and privileges basically

1022
01:02:22,581 --> 01:02:26,881
up to a level that they have themselves,
whether it's read or write and so on.

1023
01:02:27,211 --> 01:02:32,781
So I'm sure this is like an equally
deep and challenging topic and, but they

1024
01:02:32,781 --> 01:02:35,488
feel a little bit, complementary to me.

1025
01:02:35,538 --> 01:02:39,388
So hopefully there's like some
convergence here as all of

1026
01:02:39,388 --> 01:02:40,858
those are like very deep topics.

1027
01:02:41,234 --> 01:02:44,304
I did see that Beehive
announcement just recently.

1028
01:02:44,304 --> 01:02:45,364
I think that's great.

1029
01:02:45,414 --> 01:02:49,294
I think we need a lot of different
flowers blooming in this field to figure

1030
01:02:49,294 --> 01:02:52,984
out and find the places where there's
going to be overlap and collaboration.

1031
01:02:53,314 --> 01:02:56,994
By the way, just as a little bit of a
side note, I literally just yesterday.

1032
01:02:57,369 --> 01:03:00,939
learned something that maybe everybody
else listening has already known

1033
01:03:00,939 --> 01:03:04,306
and I didn't know, but just for the
benefit of the audience, the word

1034
01:03:04,606 --> 01:03:08,956
auth is you, A U T H as you correctly
point out, is a little too ambiguous.

1035
01:03:08,956 --> 01:03:11,266
It's a little too shortened
because we don't know, do you mean

1036
01:03:11,266 --> 01:03:12,796
authentication or authorization

1037
01:03:13,086 --> 01:03:17,466
but I saw somebody do auth
Z for authorization versus

1038
01:03:17,466 --> 01:03:19,446
auth n for authentication.

1039
01:03:19,746 --> 01:03:23,726
So if we just add on that one extra
letter to that shortened word auth,

1040
01:03:23,726 --> 01:03:28,586
n or auth z then we know maybe
better what we're talking about.

1041
01:03:28,586 --> 01:03:31,486
So I learned that yesterday and I'm
going to use that going forward.

1042
01:03:32,049 --> 01:03:32,599
Amazing.

1043
01:03:32,649 --> 01:03:38,249
I was not aware of that, what that
little letter N in that context meant.

1044
01:03:38,486 --> 01:03:41,329
there's also what you've
mentioned, web auth N.

1045
01:03:41,659 --> 01:03:44,029
Maybe that is what it's already using.

1046
01:03:45,179 --> 01:03:45,749
Perfect.

1047
01:03:45,869 --> 01:03:49,119
Well, today I learned, thank you
for sharing that little learning.

1048
01:03:49,579 --> 01:03:52,579
and kudos to everyone who
was already aware of that.

1049
01:03:53,119 --> 01:03:58,923
So I have not personally used passkeys
yet as part of the applications

1050
01:03:58,973 --> 01:04:03,023
I'm working on, but I am using
applications that use passkeys.

1051
01:04:03,073 --> 01:04:04,593
I'm like more and more like.

1052
01:04:04,913 --> 01:04:07,763
One web service after another
is like rolling out support

1053
01:04:07,763 --> 01:04:12,063
for it, and I currently manage
pass keys as part of 1Password.

1054
01:04:12,526 --> 01:04:16,256
I'm giving 1Password the benefit
of a doubt that they do manage

1055
01:04:16,266 --> 01:04:17,686
all of that securely for me.

1056
01:04:17,963 --> 01:04:22,143
maybe there's like at some point
1Password armageddon but  hopefully not.

1057
01:04:22,333 --> 01:04:28,273
knock on wood but, Using web keys for
your own web applications or applications

1058
01:04:28,273 --> 01:04:33,146
more generally, can you help me through,
understanding that what that entails?

1059
01:04:33,146 --> 01:04:34,676
Like, what are the boundaries of that?

1060
01:04:34,706 --> 01:04:40,516
For example, if my, either one
password manages my pass keys, or

1061
01:04:40,546 --> 01:04:46,051
if my operating managers pass keys,
what does that mean in terms of re

1062
01:04:46,051 --> 01:04:47,921
authenticating on another device.

1063
01:04:47,931 --> 01:04:52,071
So let's say I'm like, you've
built this amazing note taking app.

1064
01:04:52,391 --> 01:04:55,691
I'm starting to use it
on my desktop computer.

1065
01:04:56,011 --> 01:05:00,351
I have like gone through like some
sort of initial setup process.

1066
01:05:00,391 --> 01:05:02,321
I needed to like scan my finger.

1067
01:05:02,561 --> 01:05:04,671
So the passkey was created.

1068
01:05:04,731 --> 01:05:10,311
And now let's say on my tablet, I
want to also work on the same notes.

1069
01:05:10,591 --> 01:05:12,771
How does the setup
process there look like?

1070
01:05:12,791 --> 01:05:16,501
Do I use, for example, as I'm in
the Apple ecosystem, do I trust

1071
01:05:16,561 --> 01:05:18,951
Apple to synchronize pass keys?

1072
01:05:19,021 --> 01:05:22,851
Is there like a more manual
pairing step that I need to do?

1073
01:05:22,851 --> 01:05:27,844
Similar to how, like in, WhatsApp, for
example, there's the QR code scanning.

1074
01:05:28,024 --> 01:05:30,864
What are the, are there
different ways, how to do that?

1075
01:05:30,864 --> 01:05:32,264
Is that just taken care of?

1076
01:05:32,404 --> 01:05:33,814
Can you help me understand that?

1077
01:05:34,339 --> 01:05:35,219
Yeah, absolutely.

1078
01:05:35,659 --> 01:05:41,419
So, we need to be very clear that there's
the standard way that almost all web

1079
01:05:41,419 --> 01:05:45,059
apps, basically, practically all of
them, are currently doing it, which

1080
01:05:45,059 --> 01:05:49,783
involves a server, and then we need to
distinguish that from what I'm proposing

1081
01:05:49,803 --> 01:05:55,163
as is the future for local-first, which
is servers become optional, and in

1082
01:05:55,163 --> 01:05:57,233
many cases, don't exsist at all, right?

1083
01:05:57,233 --> 01:05:59,533
That's the zero server
world that I was pitching.

1084
01:06:00,073 --> 01:06:04,803
So the way that things currently work
and the way almost all web apps, you

1085
01:06:04,803 --> 01:06:08,533
know, my bank uses biometrics, so
let's just use them as an example.

1086
01:06:08,543 --> 01:06:08,743
Right.

1087
01:06:09,133 --> 01:06:15,348
So what my bank obviously has is a source
of authority record about who I am, and

1088
01:06:15,348 --> 01:06:18,538
they want to make sure that I'm the only
one, no matter what device I come in from,

1089
01:06:18,788 --> 01:06:22,418
I'm the only one who can access their
source of authority for my banking info.

1090
01:06:23,093 --> 01:06:28,273
the way that they do that is they have
multiple authentication mechanisms

1091
01:06:28,303 --> 01:06:30,893
attached to my account in their server.

1092
01:06:31,103 --> 01:06:34,683
They have a username and password,
of course, because you're going to

1093
01:06:34,693 --> 01:06:37,873
have to access this from devices
where that's the only option.

1094
01:06:38,243 --> 01:06:44,283
But they also have Other records in,
associated with my account that are the

1095
01:06:44,293 --> 01:06:49,003
pass keys that I have registered when
I was already authenticated with the

1096
01:06:49,003 --> 01:06:52,853
bank account through some other means,
including potentially another pass key.

1097
01:06:53,663 --> 01:06:56,813
Anytime they have an inbound,
here's a new pass key.

1098
01:06:56,813 --> 01:06:58,823
They just associate that
with my account as well.

1099
01:06:59,133 --> 01:07:02,073
So I have like two or three different
devices where I have pass key

1100
01:07:02,073 --> 01:07:06,143
authenticated with my bank and their,
I don't know their database structure,

1101
01:07:06,143 --> 01:07:09,468
but a, Ostensibly, they have like a
one to many relationship from my user

1102
01:07:09,468 --> 01:07:14,418
account to all the various different
ways that they know that it's me, right?

1103
01:07:14,438 --> 01:07:19,438
So any inbound passkey that
looks like this, it belongs to

1104
01:07:19,438 --> 01:07:20,788
Kyle, show him his bank account.

1105
01:07:21,248 --> 01:07:24,658
So the way that process works is that on
the server, in a place that they fully

1106
01:07:24,658 --> 01:07:29,328
control, as opposed to in the web or a
client that they may not control, on the

1107
01:07:29,328 --> 01:07:34,168
server, they generate a random challenge,
which is just a random set of numbers.

1108
01:07:34,928 --> 01:07:38,928
They sent that up to the device where
the passkey is going to be presented.

1109
01:07:39,278 --> 01:07:40,958
And that challenge is sent into.

1110
01:07:42,048 --> 01:07:48,448
The device, and it is encryptically,
it is digitally signed, doing

1111
01:07:48,448 --> 01:07:50,838
a digital signature, which
is different from encryption.

1112
01:07:51,258 --> 01:07:56,658
They create a digital signature using
the internal private key of your

1113
01:07:56,668 --> 01:07:58,688
passkey that nobody has access to.

1114
01:07:58,688 --> 01:08:00,408
It's stuck in the secure hardware.

1115
01:08:00,478 --> 01:08:01,588
Nobody can get at it, right?

1116
01:08:02,148 --> 01:08:06,338
They send that signature back out, and
they send that signature along with

1117
01:08:06,338 --> 01:08:08,228
the public key that you've already got.

1118
01:08:08,498 --> 01:08:10,928
That's what you've stored, is you've
stored the public key already.

1119
01:08:11,228 --> 01:08:15,298
But they send that signature back to the
server, and the server checks to make sure

1120
01:08:15,558 --> 01:08:19,488
that it was able to create a signature
that matches the public key that they

1121
01:08:19,498 --> 01:08:21,668
already know is your passkey, right?

1122
01:08:22,583 --> 01:08:27,363
So that's how they know that it was
the same you on whichever device is if

1123
01:08:27,373 --> 01:08:31,193
you were able to successfully sign the
challenge and send it back to the server.

1124
01:08:31,643 --> 01:08:38,073
What many of these services do is
have that one to many relationship

1125
01:08:38,073 --> 01:08:40,753
where you could have as many of
these biometric keys as you want.

1126
01:08:41,153 --> 01:08:45,043
Some of them are a little bit more
naive or ignorant where they just

1127
01:08:45,083 --> 01:08:51,516
literally have one, but the, Important
thing from their perspective is

1128
01:08:51,516 --> 01:08:56,686
that they have an identifier that
they know is me, that my bank has

1129
01:08:56,686 --> 01:08:58,186
an identifier that they know is me.

1130
01:08:58,186 --> 01:09:00,656
I don't know what that is, but they
have an identifier they know is me.

1131
01:09:01,206 --> 01:09:04,636
And they either are going to stick
that in the passkey, So that when

1132
01:09:04,636 --> 01:09:08,580
that passkey comes back in, that they
know it was me, or they're going to

1133
01:09:08,580 --> 01:09:12,220
manually store that public key or
both, but they're going to be able to

1134
01:09:12,310 --> 01:09:17,730
match those things up and say, this
challenge came from a device that Kyle

1135
01:09:17,780 --> 01:09:20,920
owns and has previously told us is him.

1136
01:09:22,180 --> 01:09:24,010
So we're going to let him
have access to his bank.

1137
01:09:24,020 --> 01:09:26,280
That's basically how passkeys work.

1138
01:09:26,530 --> 01:09:27,170
Currently work.

1139
01:09:27,170 --> 01:09:30,500
I've glossed over some details, but it's
basically how passkeys currently work.

1140
01:09:30,790 --> 01:09:35,570
And so you notice that the server is
playing an important role here because

1141
01:09:35,600 --> 01:09:43,320
the server ostensibly can't be compromised
to generate a fake or replayed challenge.

1142
01:09:43,650 --> 01:09:46,960
The server keeps track of every challenge
that it's ever sent out, and it never

1143
01:09:46,960 --> 01:09:51,100
sends out the same challenge twice, and
all of these others, like, secure things.

1144
01:09:51,430 --> 01:09:56,180
And also, the server, because it's going
to be what's called FIDO2 compliant,

1145
01:09:56,466 --> 01:10:03,083
this really complex specification, that
basically does a, traversal of the public

1146
01:10:03,093 --> 01:10:09,366
key certificates for the relying party
to verify that it is in fact, I mean, for

1147
01:10:09,366 --> 01:10:14,216
the authenticator to verify that it is in
fact a valid authenticator and not some

1148
01:10:14,226 --> 01:10:16,156
made up, you know, faked one or whatever.

1149
01:10:16,526 --> 01:10:19,126
So FIDO2 servers do all
of that complex stuff.

1150
01:10:19,583 --> 01:10:23,993
some apps, I would imagine probably
banks They really, really care about

1151
01:10:23,993 --> 01:10:27,223
this stuff and they probably implement
all of that complexity in the backend.

1152
01:10:27,813 --> 01:10:34,750
I would wager to say that most apps
do not verify the authenticity.

1153
01:10:34,760 --> 01:10:39,010
They simply rely on, if you sent me a
matching signature, I'm good with it.

1154
01:10:39,210 --> 01:10:41,980
Even if it was a man in the
middle, I don't care, whatever.

1155
01:10:42,480 --> 01:10:46,370
A bank definitely cares if I've had
a device that's been compromised and

1156
01:10:46,370 --> 01:10:49,480
there's a man in the middle, that's,
you know, taken over my authenticator.

1157
01:10:49,770 --> 01:10:53,960
So they are probably going to keep
running up the flagpole of the public

1158
01:10:53,960 --> 01:10:57,390
key certificates, you know, all the way
up to the root certificate or something.

1159
01:10:57,390 --> 01:11:00,120
They're probably going to do
that, but most apps are not.

1160
01:11:00,570 --> 01:11:03,330
But that's why you have a FIDO2
servers, because you do not want

1161
01:11:03,330 --> 01:11:06,190
to do that complexity yourself,
and you definitely don't want to

1162
01:11:06,190 --> 01:11:07,320
try to do that in the browser.

1163
01:11:07,670 --> 01:11:12,580
Now, we move to this other way of
thinking, which is that there is

1164
01:11:12,580 --> 01:11:15,913
no central, decision of who I am.

1165
01:11:16,288 --> 01:11:18,908
There's no like central source
of authority for who I am.

1166
01:11:19,268 --> 01:11:23,538
Who I am is just simply that I
have chosen to collect a bunch of

1167
01:11:23,578 --> 01:11:26,198
me's together into one identity.

1168
01:11:26,618 --> 01:11:30,258
One me on my phone, one me on
my laptop, one me on my tablet.

1169
01:11:30,268 --> 01:11:32,698
That's me in an identity sense, right?

1170
01:11:33,128 --> 01:11:37,098
It's not me in a humanness sense, but
it is me in a digital identity sense.

1171
01:11:37,798 --> 01:11:39,745
And, that's what the bank has done.

1172
01:11:39,745 --> 01:11:42,545
You know, they've verified my
humanness by make, you know, I

1173
01:11:42,545 --> 01:11:45,125
couldn't open an account without a
driver's license and other things.

1174
01:11:45,345 --> 01:11:49,625
We're not dealing with that part of
authentic, you know, of identity right

1175
01:11:49,625 --> 01:11:53,175
now, we're just simply talking about
digital identity is a collection of

1176
01:11:53,481 --> 01:11:59,091
essentially these key pairs that I have
said, these three key pairs constitute

1177
01:11:59,091 --> 01:12:00,281
me across my different devices.

1178
01:12:00,754 --> 01:12:05,574
When we start talking about how do
I synchronize my passkeys, in that

1179
01:12:05,574 --> 01:12:09,104
scenario I was describing before, you
created a different passkey on each

1180
01:12:09,104 --> 01:12:13,364
device, and that bank kept track of
each of those different passkeys.

1181
01:12:13,744 --> 01:12:17,844
But you notice that I said some,
don't let you do multiple pass keys.

1182
01:12:17,844 --> 01:12:18,904
They only let you do one.

1183
01:12:19,164 --> 01:12:24,214
And that is why Google and Apple
allow you now to both of them now

1184
01:12:24,224 --> 01:12:28,364
support this Google just recently,
but they now allow you to synchronize

1185
01:12:28,374 --> 01:12:32,364
your pass keys between your devices,
using your Google or Apple accounts.

1186
01:12:32,934 --> 01:12:37,884
So I could literally have the
same, you know, passkey on

1187
01:12:37,884 --> 01:12:39,274
my phone and on my laptop.

1188
01:12:39,624 --> 01:12:43,854
But something really important to
note is, it's not actually the same

1189
01:12:43,874 --> 01:12:49,004
passkey, because the device is still
generating the secure key pair.

1190
01:12:49,639 --> 01:12:54,239
What they synchronized was not the
actual secure enclave key pair,

1191
01:12:54,259 --> 01:12:56,209
because that's not even possible.

1192
01:12:56,249 --> 01:12:57,989
The hardware is holding
on to the key pair.

1193
01:12:58,189 --> 01:13:02,829
What they're synchronizing is just the
metadata in that user ID field and the

1194
01:13:02,829 --> 01:13:04,269
user handle and all that other stuff.

1195
01:13:04,479 --> 01:13:06,889
That's what's being synchronized
so that that matches up.

1196
01:13:07,239 --> 01:13:12,924
So my same ID shows up in Two
different passkeys, but it looks

1197
01:13:12,984 --> 01:13:17,444
to the bank as if it's one passkey.

1198
01:13:17,454 --> 01:13:20,904
That's basically what that
synchronization is happening.

1199
01:13:21,294 --> 01:13:21,544
So.

1200
01:13:22,094 --> 01:13:27,394
Rightly or wrongly, but I think rightly,
people have complained that passkeys

1201
01:13:27,414 --> 01:13:29,414
are definitely more user complex.

1202
01:13:29,444 --> 01:13:32,944
People have to think about like, you
know, all of this synchronization

1203
01:13:32,944 --> 01:13:36,464
stuff, which is why nobody does that
anymore with their usernames, passwords.

1204
01:13:36,674 --> 01:13:38,734
Almost everybody's using
a password manager.

1205
01:13:39,124 --> 01:13:43,254
And it's why I'm arguing that since the
world is using password managers, we

1206
01:13:43,254 --> 01:13:47,204
can just have essentially a password
manager that I'm going to call a Wallet

1207
01:13:47,574 --> 01:13:49,404
that does the same stuff for you.

1208
01:13:49,474 --> 01:13:53,014
You don't want to worry
about, Synchronizing between

1209
01:13:53,334 --> 01:13:54,534
all your different devices.

1210
01:13:54,544 --> 01:13:55,534
That's crazy, right?

1211
01:13:55,804 --> 01:13:58,551
So  back to the local-first world.

1212
01:13:58,911 --> 01:14:03,431
Since I'm simply saying that I'm
going to create these identities on

1213
01:14:03,431 --> 01:14:06,741
my different devices, and I'm going
to kind of group them together,

1214
01:14:06,741 --> 01:14:08,285
I'm going to decide when they sync.

1215
01:14:08,662 --> 01:14:13,072
the Wallet can actually synchronize
those key pairs between devices.

1216
01:14:13,082 --> 01:14:17,832
So you could literally say, I want the
exact same key pair on all of my devices.

1217
01:14:18,152 --> 01:14:22,012
And then the way that you're authorizing,
the way that a device is knowing that

1218
01:14:22,012 --> 01:14:26,372
it's okay, we basically just flatten
it out to, if you're able to decrypt

1219
01:14:26,402 --> 01:14:28,562
the data, then you have the identity.

1220
01:14:28,872 --> 01:14:31,712
And if you're not able to decrypt the
data, then you don't have the identity.

1221
01:14:31,722 --> 01:14:33,602
We've just basically
simplified the whole thing.

1222
01:14:34,277 --> 01:14:36,427
Now, I recognize that
there are trade offs here.

1223
01:14:36,427 --> 01:14:41,217
We don't have quite as strong of an
assertion as we do in the bank account

1224
01:14:41,267 --> 01:14:46,807
centralized server world, but I'm going
to actually argue, not even on this

1225
01:14:46,817 --> 01:14:51,367
podcast, but just as my continuing
work, I'm going to argue that it's

1226
01:14:51,397 --> 01:14:53,257
better for us to move in this direction.

1227
01:14:53,357 --> 01:14:56,947
It's better for us to not
have banks getting to have

1228
01:14:56,947 --> 01:14:58,447
the say so about who we are.

1229
01:14:58,457 --> 01:15:00,107
It's better for us to get to say that.

1230
01:15:00,157 --> 01:15:02,237
So I'm going to argue
that those trade offs.

1231
01:15:02,697 --> 01:15:06,977
are actually an improvement, not
a downside, but there are trade

1232
01:15:06,977 --> 01:15:10,867
offs where we don't have quite the
same level of central authority

1233
01:15:10,867 --> 01:15:12,947
guaranteeing as somebody's humanness.

1234
01:15:13,847 --> 01:15:18,437
So I appreciate you giving me a
very deep introduction and beyond

1235
01:15:18,437 --> 01:15:23,017
an introduction, quite the lecture
in a positive sense on refreshing

1236
01:15:23,027 --> 01:15:27,904
my own knowledge and understanding
on like some cryptography aspects

1237
01:15:27,904 --> 01:15:29,564
and how those things work together.

1238
01:15:30,014 --> 01:15:34,054
And I think there is an interesting
evolution that will probably, is

1239
01:15:34,064 --> 01:15:38,424
already happening and will just
continue to happen, where security

1240
01:15:38,424 --> 01:15:39,854
is really, really difficult.

1241
01:15:39,874 --> 01:15:43,964
Like, like you said, like a bank needs
to go all the way, and there's like

1242
01:15:43,964 --> 01:15:48,671
many pieces of our technology there
that we're using, like a browser itself

1243
01:15:48,681 --> 01:15:53,031
probably being one of them, where it
needs to go really great extents to

1244
01:15:53,031 --> 01:15:55,321
make everything as secure as possible.

1245
01:15:55,721 --> 01:16:01,531
And while still trying to make us
things as simple and easy for both

1246
01:16:01,531 --> 01:16:03,686
users and developers as possible.

1247
01:16:03,686 --> 01:16:08,076
And there's like this really interesting
middle ground and where there's still

1248
01:16:08,076 --> 01:16:12,646
this tension of like, okay, sure you
can make it a tad easier for users.

1249
01:16:12,666 --> 01:16:15,456
And that might come at
the expense of security.

1250
01:16:15,456 --> 01:16:18,176
But that boundary is also
like shifting slightly.

1251
01:16:18,176 --> 01:16:22,026
And I would say passkeys have
actually been, both a step forward

1252
01:16:22,056 --> 01:16:24,416
in terms of security for users.

1253
01:16:24,571 --> 01:16:27,674
And also, things are moving
in a direction where they also

1254
01:16:27,844 --> 01:16:30,194
actually become easier for users.

1255
01:16:30,704 --> 01:16:33,554
I think, yeah, I think we've got
some growing pains where right

1256
01:16:33,554 --> 01:16:36,984
now, at the immediate as we're
having this conversation, it

1257
01:16:36,994 --> 01:16:39,474
does feel harder to most people.

1258
01:16:39,884 --> 01:16:44,334
But I think we, We have made a
paradigm shift where we will absolutely

1259
01:16:44,334 --> 01:16:45,674
achieve what you're talking about.

1260
01:16:45,984 --> 01:16:50,561
Because If you just take a step back and
you think about all the complexity that

1261
01:16:50,561 --> 01:16:54,571
is currently around the username and
password standard for authentication,

1262
01:16:55,021 --> 01:17:00,041
which requires people to like pick new
passwords for all their device, all their

1263
01:17:00,061 --> 01:17:02,480
accounts, but nobody, most people don't.

1264
01:17:02,481 --> 01:17:06,129
And then all the different requirements,
like this site requires capital

1265
01:17:06,129 --> 01:17:07,989
letters and this one requires numbers.

1266
01:17:07,989 --> 01:17:09,879
And most people don't even manage that.

1267
01:17:09,879 --> 01:17:11,829
Now they just let a
password manager do it.

1268
01:17:11,829 --> 01:17:16,369
And then all the complexity around what
happens when my password gets known.

1269
01:17:16,369 --> 01:17:17,309
And I did share it.

1270
01:17:17,309 --> 01:17:21,009
And now that can be used, like all
of that stuff completely goes away.

1271
01:17:21,629 --> 01:17:25,614
And in replacement is my
thumbprint or my face.

1272
01:17:26,364 --> 01:17:30,044
Now I understand that getting to
that point is definitely a bit

1273
01:17:30,044 --> 01:17:33,334
of an uphill climb that we're
getting closer to the top of.

1274
01:17:33,664 --> 01:17:38,654
But once we are there, I cannot imagine
that any user, even a completely non

1275
01:17:38,654 --> 01:17:42,204
technical user is going to be like, wait a
minute, I don't understand this thumbprint

1276
01:17:42,244 --> 01:17:46,524
thing, but I was totally cool with all
of these emails and password requirements

1277
01:17:46,524 --> 01:17:48,034
and capital letters and all that stuff.

1278
01:17:48,054 --> 01:17:51,524
Like nobody is going to say that
eventually, eventually they are going

1279
01:17:51,524 --> 01:17:54,154
to say pass keys are so much faster.

1280
01:17:54,474 --> 01:17:58,694
So much more streamlined, so much more
user experience optimized, but we are

1281
01:17:58,814 --> 01:18:00,524
still in the process of getting there.

1282
01:18:00,524 --> 01:18:05,844
And I know why people bristle at
that claim right now today, there's

1283
01:18:05,844 --> 01:18:07,914
rough edges now, it's getting better.

1284
01:18:08,404 --> 01:18:13,984
And I think there is a second Category
of those sort of uncanny valley symptoms,

1285
01:18:14,284 --> 01:18:16,254
similar to how, like when web 2.

1286
01:18:16,254 --> 01:18:19,984
0 just started to become a thing and
people started to figure out how do I

1287
01:18:19,984 --> 01:18:23,574
do authentication, in the like web 2.

1288
01:18:23,574 --> 01:18:24,044
0 world.

1289
01:18:24,329 --> 01:18:28,429
where, like, I remember the first
PHP thing that I've built where

1290
01:18:28,459 --> 01:18:30,289
I needed to authenticate users.

1291
01:18:30,626 --> 01:18:33,906
I used good old, like, MD5
as, like, the password hash.

1292
01:18:33,916 --> 01:18:37,476
Well, that very first system, I did
not hash at all, and then I used a

1293
01:18:37,476 --> 01:18:42,296
much more secure thing, MD5, and then
I learned about Rainbow Tables, etc.

1294
01:18:42,526 --> 01:18:47,594
And eventually, there's, like, things
like Auth0, etc., and, like, single

1295
01:18:47,594 --> 01:18:51,724
sign on, which took away quite a lot
of that responsibility and that pain.

1296
01:18:51,974 --> 01:18:55,954
But now as we're shifting to
local-first, we're reopening then

1297
01:18:56,094 --> 01:19:00,727
all of those cans of worms again with
new security technologies, such as.

1298
01:19:01,047 --> 01:19:02,387
Pass keys, et cetera.

1299
01:19:02,397 --> 01:19:03,697
Things have moved on.

1300
01:19:04,014 --> 01:19:06,534
now there are quantum computers possibly.

1301
01:19:06,564 --> 01:19:09,334
So we need to rethink how
we even encrypt things.

1302
01:19:09,654 --> 01:19:10,904
so it's a moving target.

1303
01:19:11,294 --> 01:19:15,914
And I think right now there's probably
also the complexity an average app

1304
01:19:15,914 --> 01:19:21,341
developer needs to think about in regards
to, making their app secure and private

1305
01:19:21,341 --> 01:19:26,836
for users is much higher than what I
would say in five years from now, the

1306
01:19:26,986 --> 01:19:31,746
local-first data frameworks that will
be available in five years from now,

1307
01:19:31,746 --> 01:19:35,606
most of them are already having this
on the roadmap, but in five years, it's

1308
01:19:35,606 --> 01:19:39,996
going to be, or even like in one year,
three years in the future is going to

1309
01:19:39,996 --> 01:19:46,396
be, Much less complexity that a app
developer needs to think about today,

1310
01:19:46,466 --> 01:19:51,776
we all appreciate and need to hear this
sort of lecture on like how all of that

1311
01:19:51,786 --> 01:19:56,796
works, because the technologies are not
quite there yet, that I could just say.

1312
01:19:57,111 --> 01:20:02,431
I pick my favorite local-first data stack,
and they all implement the best practices.

1313
01:20:02,721 --> 01:20:06,771
And all I need to look for is sort of
like, Oh, the work with past keys is done.

1314
01:20:06,861 --> 01:20:10,377
And I don't need to, as an app
developer and as an app user, I don't

1315
01:20:10,387 --> 01:20:12,427
need to do anything more right now.

1316
01:20:12,477 --> 01:20:17,227
As an app developer, you need to know
quite a bit about the moving pieces.

1317
01:20:17,287 --> 01:20:21,449
And then each month and each
year by year, We can forget about

1318
01:20:21,449 --> 01:20:25,259
the underlying implementation
details as all of that matures.

1319
01:20:25,549 --> 01:20:30,579
So I just wanted to highlight that, and
that is a bit of an uncanny valley, but

1320
01:20:30,589 --> 01:20:32,289
things are moving in the right direction.

1321
01:20:32,786 --> 01:20:40,206
Every one of them currently is inventing
their own solution for identity in some ad

1322
01:20:40,206 --> 01:20:42,546
hoc and informally specified way, right?

1323
01:20:42,546 --> 01:20:44,766
They are all doing that right now.

1324
01:20:45,376 --> 01:20:47,799
Of course as, as a human with an ego.

1325
01:20:48,299 --> 01:20:53,179
I hope that they just see how
amazing this Wallet is that I build.

1326
01:20:53,179 --> 01:20:54,579
And they're like, let's stop doing that.

1327
01:20:54,579 --> 01:20:55,569
Let's just use Wallet, right?

1328
01:20:55,569 --> 01:20:58,192
Like I hope that's the case in reality.

1329
01:20:58,652 --> 01:21:01,162
I think they'll pick
something much lower level.

1330
01:21:01,392 --> 01:21:06,692
And what I strongly assert they
should do is base it on passkeys.

1331
01:21:06,722 --> 01:21:11,762
And I hope that even if nothing else that
I've done makes sense for your stack,

1332
01:21:12,132 --> 01:21:16,592
the WebAuthn local client making it easy
for you to deal with the passkey system

1333
01:21:16,592 --> 01:21:20,802
without worrying about the servers and
FIDO and all of that is, I think the way

1334
01:21:20,802 --> 01:21:23,422
that local-first should go at a minimum.

1335
01:21:23,647 --> 01:21:26,827
I hope that the other stuff I'm building
is useful, but at a minimum, I really

1336
01:21:26,827 --> 01:21:31,517
think building that on top of a passkey
system, and I think a library like mine

1337
01:21:31,517 --> 01:21:34,097
will make that much more approachable.

1338
01:21:34,527 --> 01:21:39,127
I wanted to use passkeys, and I
didn't want to build a library for it.

1339
01:21:39,712 --> 01:21:43,512
But when I surveyed the landscape of those
libraries, they were all server centric.

1340
01:21:43,912 --> 01:21:47,502
And that's why I built one that
can at least work for the cases

1341
01:21:47,522 --> 01:21:48,812
where a server might be optional.

1342
01:21:49,276 --> 01:21:55,219
So for whoever has made it through all the
way to now and has like absorbed all of

1343
01:21:55,219 --> 01:21:57,419
those details and hasn't had enough yet.

1344
01:21:57,779 --> 01:22:01,769
I highly recommend you just
check out those amazing projects

1345
01:22:01,769 --> 01:22:03,169
that Kyle has been working on.

1346
01:22:03,476 --> 01:22:05,809
Both try to build a little app with it.

1347
01:22:06,109 --> 01:22:09,939
And if you're extra curious, also
like look at the implementations.

1348
01:22:10,029 --> 01:22:12,649
Actually not that much
code in most places.

1349
01:22:12,679 --> 01:22:18,249
And you get to see how the web
APIs under the hood work in case

1350
01:22:18,249 --> 01:22:21,524
you need to use something that's
a little bit more low level than

1351
01:22:21,524 --> 01:22:25,624
you've already seen a mechanism,
a implementation, how this works.

1352
01:22:25,624 --> 01:22:28,384
That's typically how I go
about those sort of things.

1353
01:22:28,384 --> 01:22:30,914
I try to see, can I use an existing thing?

1354
01:22:30,944 --> 01:22:35,564
And if not, then I try to learn from the
existing thing to build my own thing.

1355
01:22:36,024 --> 01:22:38,664
And then this is sort of
this dance back and forth.

1356
01:22:38,674 --> 01:22:41,404
Later on, the existing thing
is good enough and I throw

1357
01:22:41,404 --> 01:22:42,604
away my own thing again.

1358
01:22:42,864 --> 01:22:46,649
So try to learn from Kyle's
implementations and try to

1359
01:22:46,649 --> 01:22:47,859
use them in your own apps.

1360
01:22:48,179 --> 01:22:53,079
Before wrapping up this already pretty
long conversation, there was another

1361
01:22:53,129 --> 01:22:58,799
project that I think you worked on before,
and I'm not sure how mature it is or

1362
01:22:58,799 --> 01:23:02,619
whether it was more of an experiment,
but it did catch my attention because

1363
01:23:02,649 --> 01:23:06,804
I thought it was, very interesting
and had a bunch of like putting

1364
01:23:06,824 --> 01:23:09,294
things together in a novel way to me.

1365
01:23:09,487 --> 01:23:14,157
and so the project I'm referencing
here is like the QR data sync project.

1366
01:23:14,437 --> 01:23:19,157
Would you mind giving a overview what
that was about and also how it came to be?

1367
01:23:20,116 --> 01:23:21,656
So, first of all, status.

1368
01:23:21,696 --> 01:23:26,746
QR Data Sync is absolutely a first
class citizen in this same ecosystem

1369
01:23:27,116 --> 01:23:31,836
and is absolutely going to be part of
the Wallet app that I'm building because

1370
01:23:31,866 --> 01:23:36,416
we need multiple transport mechanisms
for data that go between devices.

1371
01:23:37,196 --> 01:23:42,126
Obviously, a preference would be, make
it just happen super seamlessly under

1372
01:23:42,126 --> 01:23:46,076
the covers with something like the
local peer to peer or another peer to

1373
01:23:46,076 --> 01:23:48,126
peer protocol or Bluetooth or anything.

1374
01:23:48,126 --> 01:23:52,619
It's like Any of those ways would
be better, but there is always

1375
01:23:52,619 --> 01:23:54,039
going to be a need for fallbacks.

1376
01:23:54,109 --> 01:23:58,149
And one of the fallbacks
is the QRDataSync.

1377
01:23:58,449 --> 01:24:00,729
There's another one, which is
not a library that I wrote,

1378
01:24:00,729 --> 01:24:02,199
but I absolutely intend to use.

1379
01:24:02,199 --> 01:24:03,509
It's called SilentJS.

1380
01:24:03,944 --> 01:24:09,334
SilentJS actually transmits data between
devices using supersonic sound waves.

1381
01:24:09,574 --> 01:24:13,684
So it uses your microphone and
your speaker between two devices

1382
01:24:13,684 --> 01:24:15,054
and it transmits data that way.

1383
01:24:15,194 --> 01:24:16,134
Fascinating stuff.

1384
01:24:16,354 --> 01:24:19,184
I didn't write that library, but I
think it's super awesome and that's

1385
01:24:19,184 --> 01:24:23,254
going to be in the Wallet as an option
if you are trying to synchronize.

1386
01:24:23,624 --> 01:24:24,884
Very important to point out.

1387
01:24:25,339 --> 01:24:29,599
Some of these fallbacks are going to
be bandwidth limited and size limited.

1388
01:24:29,789 --> 01:24:32,679
You're not going to synchronize
a gigabyte of data through

1389
01:24:32,969 --> 01:24:35,599
sound waves or through QR codes.

1390
01:24:35,739 --> 01:24:39,969
Okay, so the bare minimum that you
might do would be to synchronize

1391
01:24:39,979 --> 01:24:44,549
your identity between those devices,
which is very small, you know, A

1392
01:24:44,549 --> 01:24:46,269
couple of hundred bits of data.

1393
01:24:46,529 --> 01:24:49,679
And then once you have that, you
now have established the ability

1394
01:24:49,679 --> 01:24:52,919
to create a more secure tunnel
through other mechanisms through

1395
01:24:52,919 --> 01:24:54,099
the internet or something like that.

1396
01:24:54,119 --> 01:24:58,479
So that's where I see things like
QR data sync and silent JS being

1397
01:24:58,739 --> 01:25:00,249
is kind of that lowest level.

1398
01:25:00,259 --> 01:25:04,079
Let's synchronize my identities across
devices, but then all that heavier

1399
01:25:04,079 --> 01:25:07,099
data synchronization stuff that's
going to happen, it should go through

1400
01:25:07,099 --> 01:25:09,729
a more high throughput channel, like.

1401
01:25:09,974 --> 01:25:12,347
You know, something that's or UDP based.

1402
01:25:13,397 --> 01:25:18,307
Just briefly to touch on QR data sync,
the way that library works is it creates

1403
01:25:18,307 --> 01:25:22,947
what are called animated QR codes,
not my original invention, but I saw

1404
01:25:22,947 --> 01:25:25,707
it years and years ago, and then I
didn't really see it ever go anywhere.

1405
01:25:25,707 --> 01:25:27,297
And it just stuck in the back of my head.

1406
01:25:27,897 --> 01:25:32,047
An animated QR code is nothing
more complicated than a whole

1407
01:25:32,047 --> 01:25:36,737
bunch of QR codes shown in rapid
succession, like an animated frame.

1408
01:25:37,092 --> 01:25:39,302
Each QR code can have
a chunk of data in it.

1409
01:25:39,622 --> 01:25:43,902
And so you take a big chunk of data,
say like, you know, 10k of data.

1410
01:25:44,262 --> 01:25:44,972
It's a string.

1411
01:25:45,222 --> 01:25:49,232
You just break that up into a series
of chunks, and then you do some

1412
01:25:49,232 --> 01:25:52,532
padding so that you make sure that
the QR codes are all uniformly sized.

1413
01:25:52,822 --> 01:25:55,652
And then you just show
those chunks in succession.

1414
01:25:56,152 --> 01:26:00,532
My protocol in this library just has
a very tiny little header on it that

1415
01:26:00,542 --> 01:26:03,502
has the total number of frames that
are going to be shown and what the

1416
01:26:03,502 --> 01:26:05,482
frame index is that's being shown.

1417
01:26:05,702 --> 01:26:09,736
So then you have a camera on a different
device that is reading QR codes.

1418
01:26:09,786 --> 01:26:11,686
And by the way, it's reading
them very, very quickly.

1419
01:26:11,686 --> 01:26:15,861
It reads them in like less than 15
milliseconds or something, but you

1420
01:26:15,861 --> 01:26:20,511
just hold up your camera to a device
that's displaying a set of animated

1421
01:26:20,511 --> 01:26:22,161
codes and the camera is reading those.

1422
01:26:22,531 --> 01:26:26,341
And it's just doing an infinite
cycle, by the way, the sending is

1423
01:26:26,361 --> 01:26:30,301
just sending them all in order because
your camera might miss a few of them.

1424
01:26:30,531 --> 01:26:33,901
And so it just holds in its memory,
all the ones that it knows that

1425
01:26:33,901 --> 01:26:35,481
it needs until it just keeps.

1426
01:26:35,781 --> 01:26:40,221
keeps going until it has read all of
the frames, and then it reconstitutes

1427
01:26:40,251 --> 01:26:41,281
the data on the other side.

1428
01:26:41,551 --> 01:26:43,071
So that's what QR Data Sync is.

1429
01:26:43,101 --> 01:26:47,281
It is hopefully a fallback mechanism
at best, but it's certainly

1430
01:26:47,281 --> 01:26:51,161
going to be an important key
piece of what Wallet is doing.

1431
01:26:51,881 --> 01:26:53,221
I love this so much.

1432
01:26:53,261 --> 01:26:58,671
This stimulates so many parts
of like, what I like as a geek.

1433
01:26:58,902 --> 01:27:04,707
particularly when some, Digitally
tricky concepts become visually

1434
01:27:04,707 --> 01:27:06,907
a little bit more tangible.

1435
01:27:07,297 --> 01:27:12,894
And given that here with a QR data
sync, the visible  and visual component,

1436
01:27:13,104 --> 01:27:17,017
but given that you've also mentioned
the Salient project, which move

1437
01:27:17,017 --> 01:27:20,557
that to another dimension, to the
dimension of like hearing and sound.

1438
01:27:21,061 --> 01:27:25,361
this sparks all sorts of like ideas
in my head in the same way, where you

1439
01:27:25,361 --> 01:27:30,637
can, somewhat style a QR code to look
a little bit more like, brand related.

1440
01:27:30,677 --> 01:27:35,234
I'm wondering, could I actually
make the audio pairing, whether I

1441
01:27:35,234 --> 01:27:40,937
can, manipulate that in a way to
be related to what you're doing.

1442
01:27:41,187 --> 01:27:45,327
In my head, there's sort of like those,
those like old school modem sounds.

1443
01:27:45,567 --> 01:27:47,657
So it's like back to the future in a way.

1444
01:27:48,011 --> 01:27:51,151
so I'm, I'm very glad I
asked about this project.

1445
01:27:51,227 --> 01:27:56,216
and it's not just a very, curious
and cool aspect of it, but I think

1446
01:27:56,216 --> 01:28:01,142
it's also very practical and that's
something that, people in the Web 2.

1447
01:28:01,192 --> 01:28:03,332
0 world are already quite familiar with.

1448
01:28:03,352 --> 01:28:08,366
What I've mentioned before, whether
you're pairing a, WhatsApp app from one

1449
01:28:08,366 --> 01:28:11,366
device to another that is not animated.

1450
01:28:11,536 --> 01:28:14,606
This is where a single static
frame already is enough.

1451
01:28:15,156 --> 01:28:20,186
But I think the patterns are already
there, end users are familiar with

1452
01:28:20,186 --> 01:28:25,942
them, and putting this all together in a
pluggable way that allows for different

1453
01:28:25,952 --> 01:28:30,172
options, all under this umbrella of
your packages that you're working on.

1454
01:28:30,627 --> 01:28:32,337
Super fascinating stuff.

1455
01:28:32,677 --> 01:28:36,387
So Kyle, I think we're already
running well on time here.

1456
01:28:36,691 --> 01:28:41,364
but I really, really appreciate you coming
on, sharing your background, sharing what

1457
01:28:41,364 --> 01:28:46,184
led you to local-first and then sharing
everything about your explorations and

1458
01:28:46,194 --> 01:28:51,974
deep work and local-first identity,
AuthN, local vault, all of those projects.

1459
01:28:52,144 --> 01:28:54,044
Thank you so much for sharing all of that.

1460
01:28:54,494 --> 01:28:56,394
Can I give one last little tidbit?

1461
01:28:56,779 --> 01:29:01,999
The world, if we went back 10 years,
and if you tried to convince people 10

1462
01:29:01,999 --> 01:29:07,764
years ago, that the whole world needed
to move away from usernames and passwords

1463
01:29:07,764 --> 01:29:11,864
as the single factor for authentication
and that the whole world was going to

1464
01:29:12,254 --> 01:29:16,524
move to owning multiple devices and we
were going to be able to like generate

1465
01:29:16,524 --> 01:29:20,824
these numeric codes that were randomly
changing in time and things like that.

1466
01:29:20,824 --> 01:29:24,204
And if you told people 10 years
ago that billions of people in the

1467
01:29:24,204 --> 01:29:27,404
world would do that, most people
would say that'll never happen.

1468
01:29:28,174 --> 01:29:32,974
But if you fast forward 5 or 10 years, the
vast majority of the world has upgraded

1469
01:29:32,984 --> 01:29:35,464
to multi factor for authentication.

1470
01:29:35,824 --> 01:29:37,094
We've still got a long way to go.

1471
01:29:37,294 --> 01:29:41,184
I'm not saying that it's a fixed
problem, but we have absolutely

1472
01:29:41,204 --> 01:29:44,664
upgraded the world to understanding
the concepts of multi factor.

1473
01:29:45,074 --> 01:29:50,564
So what I'm suggesting in the move forward
with going to a Wallet and going to this

1474
01:29:50,564 --> 01:29:53,314
local-first identity is akin to that.

1475
01:29:53,684 --> 01:29:58,654
Will it take a while and will it
take users changing their mindset

1476
01:29:58,654 --> 01:30:02,754
and will it take big players pushing
it and requiring the adoption?

1477
01:30:02,764 --> 01:30:03,954
Yeah, it absolutely will.

1478
01:30:04,204 --> 01:30:10,101
It's a, it is a hill to climb, but I
just wanted to point out that, concept of

1479
01:30:10,121 --> 01:30:12,541
multi factor auth is not going to go away.

1480
01:30:12,751 --> 01:30:14,921
It's just going to evolve in this app.

1481
01:30:15,211 --> 01:30:16,861
So for example.

1482
01:30:17,061 --> 01:30:21,501
This app is going to have a TOTP number
generator, where you can use it as a

1483
01:30:21,501 --> 01:30:26,141
second factor of auth, but instead of you
having to look at your phone and then type

1484
01:30:26,151 --> 01:30:30,831
in the numbers, if you have the Wallet app
on your phone and on your laptop, and your

1485
01:30:30,831 --> 01:30:34,941
laptop is challenging you for a second
factor of auth, All you need to do is

1486
01:30:34,971 --> 01:30:39,391
open up the Wallet app on your phone and
say, give me a code and instantaneously

1487
01:30:39,391 --> 01:30:43,991
that code can synchronize to the Wallet
on your desktop and then paste from the

1488
01:30:43,991 --> 01:30:45,941
Wallet on your desktop into the form.

1489
01:30:46,181 --> 01:30:50,301
You don't need to sit here and type
all of these numbers so we can have an

1490
01:30:50,351 --> 01:30:56,006
upgraded view of what second and multi
factor auth is if we go in this direction.

1491
01:30:56,006 --> 01:30:58,876
And that's one of the things I'm
most excited about because we should

1492
01:30:58,876 --> 01:31:00,466
not be compromising on security.

1493
01:31:00,466 --> 01:31:05,346
We should be upgrading security, but also,
as you've said several times, putting the

1494
01:31:05,346 --> 01:31:07,626
user experience first and foremost here.

1495
01:31:08,306 --> 01:31:13,326
I think arguably a lot of the multi factor
auth was pretty rough for users at first.

1496
01:31:13,686 --> 01:31:16,456
SMS codes and all these other
things, you know, waiting 10 minutes

1497
01:31:16,466 --> 01:31:17,956
for a text message to come in.

1498
01:31:18,286 --> 01:31:19,646
We still have a lot of that.

1499
01:31:19,716 --> 01:31:20,756
There's still a long way to go.

1500
01:31:20,806 --> 01:31:24,976
But because we've made so much progress
there, I am very bullish on the fact

1501
01:31:24,976 --> 01:31:29,876
that we can make the same kind of
progress towards this web 2.5 where we

1502
01:31:29,876 --> 01:31:33,856
own our data and we own our identities
as we take them through different

1503
01:31:33,876 --> 01:31:35,416
apps and through different devices.

1504
01:31:36,231 --> 01:31:37,641
That's a wonderful summary.

1505
01:31:37,741 --> 01:31:39,691
I'm very excited about that future.

1506
01:31:39,961 --> 01:31:42,871
Kyle, thank you so much for
sharing all of that with us today.

1507
01:31:43,564 --> 01:31:44,474
Thank you for having me.

1508
01:31:44,474 --> 01:31:46,694
It's been a thrill to dig into it.

1509
01:31:47,602 --> 01:31:49,882
Thank you for listening to
the Local First FM podcast.

1510
01:31:50,292 --> 01:31:53,352
If you've enjoyed this episode and
haven't done so already, please

1511
01:31:53,362 --> 01:31:54,802
subscribe and leave a review.

1512
01:31:55,172 --> 01:31:57,682
Please also share this episode
with your friends and colleagues.

1513
01:31:58,072 --> 01:32:01,302
Spreading the word about this
podcast is a great way to support

1514
01:32:01,302 --> 01:32:02,752
it and help me keep it going.

1515
01:32:03,352 --> 01:32:07,532
A special thanks again to Rosicorp and
PowerSync for supporting this podcast.

1516
01:32:07,942 --> 01:32:08,992
I'll see you next time