Sponsored by
Show notes
Transcript
0:00:00 localfirst.fm #17 – Kyle Simpson: Local-first identity
0:00:00 if we build a world where it is very
compelling and straightforward for
0:00:05 people to start building in peer to peer
communications into their apps, we really
0:00:11 start challenging the question of Why did
you need the cloud in the first place?
0:00:15 For most things, you didn't need the
cloud except that you did not have a way
0:00:20 for two clients to speak to each other.
0:00:23 But if we get rid of that,
then you stop needing to pay
0:00:26 for most of your cloud bill.
0:00:28 And that is one of the largest
overheads that companies face these
0:00:35 Intro
0:00:36 Welcome to the local-first FM podcast.
0:00:38 I'm your host, Johannes Schickling,
and I'm a web developer, a
0:00:41 startup founder, and love the
craft of software engineering.
0:00:45 For the past few years, I've been on a
journey to build a modern, high quality
0:00:49 music app using web technologies.
0:00:51 And in doing so, I've been falling down
the rabbit hole of local-first software.
0:00:55 This podcast is your invitation
to join me on that journey.
0:00:59 In this episode, I'm
speaking to Kyle Simpson.
0:01:02 A prolific JavaScript engineer and
author of the book, You Don't Know JS.
0:01:07 Over the past years, Kyle has been
researching user identity and encryption
0:01:12 in a local-first context, which we
explore in depth in this episode.
0:01:16 We start the conversation with a story
that led Kyle to local-first, including
0:01:20 what he calls web 2.5 and zero servers.
0:01:24 Before getting started, also a big
thank you to Rosicorp and PowerSync
0:01:29 for supporting this podcast.
0:01:31 And now my interview with Kyle.
0:01:34 Hey Kyle, so nice to have you on the show.
0:01:36 How are you doing?
0:01:37 I'm great.
0:01:37 Thanks for having me.
0:01:38 I'm thrilled to be here.
0:01:40 You've been digging into some
aspects and some corners of the
0:01:43 local-first ecosystem that I think
not as many have yet really dug in
0:01:49 so deeply, namely around local-first
identity, encryption, et cetera.
0:01:52 So I'm really excited to get into
that, but, not to get ahead of myself.
0:01:57 Maybe you want to briefly introduce
yourself, give a bit of background
0:02:01 and, maybe share how we, how we
get to talk about this today.
0:02:05 Yeah.
0:02:05 my name's Kyle Simpson.
0:02:07 Most people online, and especially
in the web and JavaScript
0:02:10 community, will know me by Getify.
0:02:12 I've been around for a very long time
now, and, probably some of the biggest
0:02:17 things that I'm known for is having
written the You Don't Know JS books.
0:02:22 the first edition came out in 2014, 2015.
0:02:25 That's a series of six
books about JavaScript.
0:02:28 And then I did a second edition,
some of those books that we wrote
0:02:31 in a second edition, around 2020.
0:02:34 so that's how most people know me.
0:02:36 I've done a lot of teaching, a lot
of conference speaking in the web and
0:02:39 JavaScript space, and kind of tried
to promote the web as a platform.
0:02:44 And JavaScript is a key
piece of that platform.
0:02:48 Specifically with local-first, my
interest, I arrive at local-first
0:02:52 kind of almost accidentally because
I was working on things that
0:02:57 I thought we needed to create.
0:02:58 And I didn't know that there was
anybody else that had come up
0:03:01 with terms or pioneering this.
0:03:03 So I sort of separately was
trying to invent something not
0:03:07 that dissimilar from local-first.
0:03:08 And I had a series of like specs that
I was going to try to write around
0:03:12 it, but that comes from a passion for
why we need to own our identity, as
0:03:18 opposed to offloading that to GitHub,
or Google, or Microsoft, or whatever.
0:03:23 We need to own that.
0:03:24 We need to own the control of
the data that we create, and the
0:03:28 data that is created about us,
to whatever extent is possible.
0:03:32 And so that kind of got me interested
in this space, this particular
0:03:36 usage of the web platform, and
of JavaScript as a technology.
0:03:41 I found the local-first space
through some employment, and then
0:03:45 started getting involved in that.
0:03:47 community, the meetup that runs
on the discord and all of that.
0:03:51 Met Jans who runs that.
0:03:53 And so that's what brings us to today is
that my passion kind of started over the
0:03:57 last three to five years, really trying
to leverage what I've been able to do
0:04:01 and what we can do with this platform
for the good of moving the web forward, I
0:04:06 believe, back to us owning our identity.
0:04:10 Awesome.
0:04:10 Yeah.
0:04:11 You've mentioned that I think
you had now two opportunities to,
0:04:14 see a couple of like different
products in the local-first space.
0:04:18 I think one of them would be Socket
Supply, which is, exploring peer to peer
0:04:23 software, which is really interesting.
0:04:25 And then also the AI startup, Vella.
0:04:28 I'd be interested in hearing a little
bit more what motivated your move
0:04:32 to work at Socket Supply, like given
the focus on peer to peer, maybe
0:04:40 Kyle's journey: Web 3, Socket Supply, Vella and Identity
0:04:40 Yeah, there is a little bit
of, it's a winding road, right?
0:04:44 There's not a straight line path.
0:04:45 so going back several years when I was
starting to get interested in this, I
0:04:51 was looking for a job at the time because
I had gone through some layoffs and
0:04:54 I'd been unemployed for a little while.
0:04:56 And the company that ended up,
interviewing me, they reached out to me.
0:05:01 interviewed me and then heavily
recruited me, was actually a
0:05:04 Web3 company, a crypto company.
0:05:06 Now I'd known about the Web3 crypto
space for a while, had felt like most of
0:05:10 it was not something that I would super
get behind and endorse, especially the
0:05:15 currency side and all the, you know,
the speculative financial instruments
0:05:19 and all of that, not something I'm into.
0:05:21 But I was interested because this
particular company builds smart
0:05:25 contracts and I do think that smart
contracts are one of the core gems that
0:05:30 I think Web3 could bring, some real
improvement to the world of software.
0:05:35 So they recruited me and they specifically
asked, can you come and join us?
0:05:40 And because you're so big in Web2, can
you help us attract Web2 developers?
0:05:44 That was my role.
0:05:45 I wasn't really an engineer.
0:05:46 I was really more almost a dev rel,
but I needed to learn the space and
0:05:50 so I spent that four to six months I
was there trying to immerse myself in
0:05:55 the web3 world and understand that and
in no way do I want to say anything
0:06:00 bad about web3, but I'm not here to
support it in any way because I ended up
0:06:05 leaving that world because I didn't fit.
0:06:07 I didn't fit because I don't believe
that the world that's being spun in
0:06:14 Web3, which by the way comes from
some pretty deep roots in like the
0:06:18 genre of cyberpunk fiction, and I
read some of those books to like get
0:06:23 myself into the mindset of this world.
0:06:26 I don't believe what they believe, I
think, which is that they believe that
0:06:31 the world's current track is inevitably
going to lead to ruin, and they've created
0:06:38 the only oasis that anybody can jump to.
0:06:41 And they believe, I think, that it's
not only inevitable that people will
0:06:45 jump, but that it's self evident.
0:06:48 That people will make the jump.
0:06:50 If just more people hear about it,
they will obviously say, let's do that.
0:06:54 I didn't fit in that world.
0:06:55 I'm not criticizing the people
that believe that, but they just
0:06:58 kind of papered over that gap
that exists between web2 and web3.
0:07:03 So over that four to six months, what
codified in my mind was there's definitely
0:07:08 some things that we need to work on.
0:07:09 They don't look like Web 3 at least yet.
0:07:13 And I left and I told them I'm
leaving cause I'm going to go build
0:07:17 what I'm going to call Web 2.5.
0:07:19 If we ever are going to get to
Web 3, which I don't know if we
0:07:22 are or not, not my say, but we
have to take an intermediary step.
0:07:27 We're not going to make that jump.
0:07:28 I feel confident in predicting
that we will not simply make
0:07:31 that giant leap over the chasm.
0:07:34 So we can talk about
what I define as Web 2.5.
0:07:39 But those ideas came from kind of
swinging the pendulum too far, I think
0:07:45 maybe, towards that decentralized
world, which is what Web3 is all about.
0:07:50 And then saying, let's swing it back
a little bit and figure out some way
0:07:54 to achieve that with what the web
currently is and building on top of
0:07:58 and evolving what the web currently is.
0:08:00 That is what led me to Socket.
0:08:03 Socket supply.
0:08:04 They, build a mobile,
tooling set and framework.
0:08:08 others in that space are Tauri and Ionic
and way back in the day, PhoneGap for
0:08:13 building hybrid applications where the
UI is built around a web and in a web
0:08:18 view with a backend that is native and
extending the native capabilities into
0:08:24 the web space, that's what they do.
0:08:26 I was very attracted to that specifically
because of their ability to allow
0:08:32 a web application to have full
peer-to-peer communications capabilities.
0:08:37 They exposed UDP based, relay
based peer-to-peer protocol
0:08:42 directly to a web application.
0:08:44 I felt like that was a big, it still is
a big missing piece for the web platform,
0:08:49 and it felt like the way to move forward.
0:08:52 Not that I love native apps and I just
want us to all build only native apps.
0:08:58 I really do love the web platform,
but this felt like a good compromise.
0:09:01 If we can build an app in the web platform
and then wrap A rather thin wrapper around
0:09:07 it to give it these extra capabilities
that for some reason, the web just
0:09:11 won't give apps right now, then I think
we can actually move forward if we can
0:09:16 have true peer to peer communication.
0:09:17 So, join Socket Supply to work
on that and in particular, to
0:09:21 work on putting encryption into
that peer to peer relay protocol.
0:09:26 That's what I spent a lot
of my time there doing.
0:09:29 I also did a bunch of DevRel stuff.
0:09:31 I'm no longer with Socket.
0:09:32 I was there for about 10 or so months.
0:09:34 I'm not with Socket anymore,
but that was part of my journey.
0:09:37 And then several months went by where
I was unemployed after leaving Socket
0:09:42 before, the founder of this Vella.
0:09:46 ai.
0:09:47 he's the one who runs the
meetup in the local-first space.
0:09:51 He came to me and said, I've seen you
active in the local-first community.
0:09:55 would you consider
helping me co found this?
0:09:57 And the story that he spun was
incredibly attractive to me.
0:10:01 It seemed like a really obvious place
to attach my passion for identity.
0:10:08 What he said was I've been
working on smart assistant.
0:10:11 It's going to use AI, but I really
believe that AI should work as
0:10:14 much on the device as possible.
0:10:17 Given the constraints that we have in
devices, put as much of that on the
0:10:20 device as we can, because this is really
sensitive personal data that doesn't need
0:10:25 to be just slurped up into the cloud.
0:10:27 And that really resonated with
me believing in local-first.
0:10:31 And more importantly, if you're going
to build apps like that, where you have
0:10:36 your data on your device and you have
it on multiple devices and you really
0:10:41 are trying to break down some of the
silos between apps like mixing your
0:10:46 Google data and your Apple data and your
Spotify data all into this one thing.
0:10:51 What was really obvious to me was we're
going to need a way to, if we're eschewing
0:10:55 all of those services, then we're going
to need a way to define our identity
0:10:58 so that we can keep things straight.
0:11:01 And that identity needs
to be really local-first.
0:11:04 So that's what attracted me to Vella,
was go work on the identity piece to
0:11:08 try to help their story, progress.
0:11:11 I spent several months with Vella,
they're a great, group of folks.
0:11:14 Fortunately, we just I didn't
have enough funding to keep me
0:11:17 working in a paid capacity there.
0:11:19 I'm still advising them,
still wishing them the best.
0:11:21 And they're, they're continuing
on in their sort of smart email
0:11:25 inbox app to rule the world.
0:11:28 And I hope they achieve it
because I want to use that app.
0:11:31 I look forward to that.
0:11:32 So that brings us kind of to today.
0:11:35 Vella is the reason I started
putting together some of the
0:11:39 puzzle pieces for Identity.
0:11:41 I was going to build it for Vella, but
I'm just building it right now in the
0:11:45 open source so that hopefully these Lego
pieces are something that apps like Vella
0:11:50 and others, hopefully in the local-first
space will pick up and build upon.
0:11:55 Perfect.
0:11:55 Well, that's quite the arc of like
different chapters from peer to peer
0:12:00 to locally running AI, et cetera.
0:12:02 I'm eager to get into each of those, but
maybe taking a few steps back, you said
0:12:07 something that captured my attention.
0:12:10 I'm also not a person who's
a big believer in Web3.
0:12:13 I'm rather skeptical.
0:12:15 If it happens and if those ideals
prevail, I won't stand in the way of it.
0:12:19 But I'm a little bit, just
skeptical of like what it's the
0:12:22 bad stuff it attracted so far.
0:12:24 And so I'm very interested in
the good ideas behind that.
0:12:29 A lot of like interesting
research that came out of that.
0:12:32 But I agree.
0:12:33 It is too far of a step, too of a
radical step from how things, work
0:12:38 today and like how practical everything
is today to a much more idealistic,
0:12:45 but in many regards still, to me,
it seems like impractical, A to B.
0:12:50 So if there's like a middle ground
there that maybe has a bunch of like the
0:12:55 more attractive things from the future,
from that Web3, Utopia, who knows?
0:13:00 and you framed that as Web 2.5 . I'm
very curious how you define that
0:13:10 The Zero Server Paradigm
0:13:10 Yeah, so speaking specifically about
local-first, just because I know most
0:13:15 of the people that'll be listening to
this do understand local-first, but I
0:13:18 want to re emphasize of the seven points
of the original Manifesto from Ink
0:13:24 & Switch I think the kind of, narrative
arc that comes out of that is that we
0:13:31 have built software for the last 20
or almost 30 years with an increasing
0:13:36 mindset towards server and cloud first.
0:13:40 We build apps where we, architect
and design what that's going to be.
0:13:44 And then we create extensions of
that experience into the client.
0:13:48 And I think what local-first
says is let's flip that paradigm.
0:13:51 Let's start with what can the client
experience be and what should it be?
0:13:56 And where should that
data reside in the client?
0:14:00 And then optionally, you might
choose to enhance that experience
0:14:05 with a cloud or server experience.
0:14:07 Flipping that default assumption where you
start what you prioritize when you design.
0:14:12 I think that's one of the
most important aspects of the
0:14:16 local-first manifesto and movement.
0:14:18 And I would say that that requires
you to ask, what does my app do
0:14:25 in a zero server environment?
0:14:27 How does my app behave in
a zero server environment?
0:14:30 Zero server is, that's my term,
not a generally accepted term,
0:14:35 but here's how I define it.
0:14:37 It is either that there is no
server in existence, Or, that
0:14:42 server effectively doesn't exist
because there's no connection to it.
0:14:46 And there's a thousand different reasons
why that connection might not exist.
0:14:50 Might be down, might be the company went
out of business, might be flaky internet
0:14:55 on the client or the server or both.
0:14:57 But, Zero server means
this app is on its own.
0:15:01 There is no connection to a mothership
and how's it going to behave?
0:15:05 And it really should behave
like a full fidelity experience.
0:15:08 Here's my, go to example for this.
0:15:11 Banking apps.
0:15:12 We all know that banking apps are
online apps, and they're all built
0:15:17 with the assumption that when you
log into your banking app, you want
0:15:20 to see the most instantaneous, up
to the minute information about
0:15:24 your current bank account balance.
0:15:26 And they certainly own the source of truth
about what your bank account balance is.
0:15:31 No argument there.
0:15:32 However, there's a ton of information
and functionality that is not
0:15:38 requiring live updates of data.
0:15:41 There's all of my previous banking
history, years and years worth, tens
0:15:46 of thousands of transactions, some of
which might be useful if I'm preparing
0:15:50 taxes or I'm trying to analyze my
budget or figure out what I spent
0:15:53 things on or whatever, and I don't need
a live internet connection and a live
0:15:57 up to date bank balance to do that.
0:16:00 But as everybody knows, you can't log
into your bank app without an internet
0:16:03 and get in access to that data.
0:16:06 It's very much my data and I very much
still have the app on my device and I
0:16:11 can't pair those two together because
there was an assumption that the server
0:16:14 was a required piece of the puzzle.
0:16:17 And I think that's just a failing.
0:16:18 It's a failing of business models.
0:16:20 It's a failing of product design.
0:16:22 It's a failing all the
way across the board.
0:16:24 To have not prioritized, assuming I
start with this and then we add on later.
0:16:30 That bank app could very easily let me see
all of my data and have a very prominent
0:16:34 icon there that says, this is not your
live bank balance or just hide the bank
0:16:39 balance if they were really worried
about that, but they could very easily
0:16:42 give me all that functionality on my
existing data that was kept on my device.
0:16:47 So that's one of the reasons
I resonate with local first.
0:16:51 And in a way, it's also the simplest
use case where basically all your
0:16:57 transactional history is typically
like append only and immutable.
0:17:01 It's not that your bank's going to
say like, Oh, actually like this
0:17:04 10, 000 transaction back there,
like it's never happened but all of
0:17:08 that is like basically set in stone
or should really be set in stone.
0:17:12 That's like the nature of the domain.
0:17:14 So this should make it the simplest
use case actually to support this.
0:17:18 Yeah.
0:17:19 The CRDT there is pretty simple.
0:17:23 In local-first terms,
there's not a lot of merging.
0:17:25 You're right.
0:17:25 That's a, that's a good point.
0:17:26 Like the technical barrier
is not really there.
0:17:29 It's, it's a failure of business
model and a product design.
0:17:33 So, I very much believe that we need to
do those things, and, I call that version
0:17:40 of the web, or at least that's one pillar
of what I call the Web 2.5, a web that
0:17:46 stops being drunk on the idea that the
only way to build an app is to start with
0:17:51 cloud infrastructure and then work your
way back to the client, but rather start
0:17:55 with client infrastructure and maybe or
maybe not work your way toward a server.
0:18:00 I think there's a ton of apps that
never need any servers whatsoever.
0:18:04 The probably most motivating example
that got me interested in this
0:18:07 space was going back several years.
0:18:09 There's a landmark, you know, world
changing legal ruling in the U.
0:18:13 S.
0:18:14 that I'm, where I'm at, from the Supreme
Court that eliminated federal protections
0:18:19 for women to have the right to choose
abortions, and other types of, healthcare.
0:18:23 And I'm not a uterus having person.
0:18:26 I can't.
0:18:27 Get pregnant or have an abortion,
but I absolutely have people in my
0:18:29 life that I care about that can.
0:18:32 I have a daughter, I have a
wife, like, this matters to me,
0:18:35 and there was actually a case.
0:18:37 It wasn't just sort of made up.
0:18:38 There was actually a case where
data that a woman had in a period of
0:18:43 menstruation tracking app was Captured
and used against her by government
0:18:49 and law enforcement authorities.
0:18:50 And that is just like that is so
quintessentially the bad future
0:18:56 that we never should have built.
0:18:57 We never should have enabled.
0:18:59 And it just snapped in my mind.
0:19:00 Like we have the technical capability
to let people create really useful and
0:19:06 engaging experiences around data that
they own, that is about them, that is
0:19:11 very personal, and there's no reason
that data ever has to go out to somebody
0:19:15 else's device because that's the trap.
0:19:18 I make the assertion that if you do
not have custody of your data, then
0:19:23 you do not have ownership of your data.
0:19:25 Custody is the whole game.
0:19:27 So when we give it out to those servers,
then of course you're going to have
0:19:30 governments that are going to find either
ways to backdoor the encryption or legally
0:19:35 force them to get access to that data
and they're going to use it against you.
0:19:39 And no matter where you are on the
political spectrum, no matter where
0:19:43 you are on the techno spectrum,
you must agree with me that that's
0:19:47 not a future that we want to build.
0:19:48 Where they can do whatever they want
with our data and manipulate us.
0:19:52 That can't be what with a
rational level head says is, is
0:19:57 what we ought to be building.
0:19:57 But we have built that and we've
gotten dangerously close to that.
0:20:02 So Web 2.5 is saying we need to back
away from that, completely reverse
0:20:06 that paradigm, put data first.
0:20:09 On the device, the way local-first
suggests, and don't even build a
0:20:13 server if it doesn't make sense.
0:20:15 But if it does make sense,
be restrained in doing so.
0:20:18 That's what I mean by zero server.
0:20:20 And I think that's also a really
interesting point about like
0:20:23 health apps more, more broadly.
0:20:25 I mean, a health app is typically I'm
inserting some data about myself, or
0:20:30 maybe with like a smart device that
tracks my heart rate, et cetera.
0:20:35 And there's probably not a
good reason to have that data
0:20:40 be synced to a remote server.
0:20:42 Maybe I want to have it, maybe I have like
a Apple watch and I have like an iPhone
0:20:47 or on some other platforms, maybe those
things should sync between each other.
0:20:52 But that a third party is the
kind of de facto source of truth
0:20:56 where all of that data is stored.
0:20:58 I think the only explanation for
why that is the case is because it's
0:21:04 been so much easier to build those
sort of server centric applications.
0:21:09 I think I might take issue with you
in saying that's not the only reason.
0:21:12 That might be the most convenient
excuse, but I think the most salient
0:21:18 reason is because there's much more
money to be made if my data sits in
0:21:23 their server versus on my device.
0:21:25 And I think that's what's driven a
lot of it, but I think you're right
0:21:27 that We have absolutely created
a technology landscape where the
0:21:33 easy paved cow path is to do that.
0:21:36 I agree with that.
0:21:37 I think those are
definitely two major points.
0:21:40 but I think even if someone has more of
like the, aspiration to build something
0:21:46 in the interest of a user and is maybe
not after turning this into a billion
0:21:52 dollar monopoly, then it's still a lot
harder to build a non server centric
0:21:58 application, at least in the past.
0:22:00 And I think slowly but surely that is
starting to change with all of those
0:22:04 amazing local-first technologies.
0:22:06 But yeah, the example you've mentioned
is certainly a very stark reminder
0:22:11 that we have to do something there.
0:22:14 So that's one of the pillars of Web
2.5 is We need to build a Web 2.5 where
0:22:21 the paradigm is that we own our data
and we own our identity so that we can
0:22:25 control that data and say where it goes.
0:22:27 Sometimes it's going to go to my devices,
like I call it my local cloud or my local
0:22:32 ring to borrow the term web ring from.
0:22:34 30 years ago that I'm
old enough to remember.
0:22:37 Your local ring is all your devices.
0:22:39 It's your watches and tablets and
laptops and phones and all that.
0:22:42 You definitely want to share data there.
0:22:44 And that explains why I was interested in
peer to peer technology, because that is
0:22:50 where that is how that data should get.
0:22:52 between my devices.
0:22:53 By the way, I'll just, I'll make a plug.
0:22:55 Aside from true networking based peer
to peer, which is what Socket was
0:23:00 trying to do, and what their protocol
I think enables, whether you ever use
0:23:03 Socket, I think they just have a great
protocol that we could build upon
0:23:06 that's relay based and self balancing.
0:23:08 I think there's a lot of, really
good stuff there that somebody
0:23:11 should, should pick up and run with.
0:23:13 But whether you use that or not, there
is actually a working group in the web
0:23:17 standards community that's trying to
work on what's called local peer to peer.
0:23:21 I'm very excited about this.
0:23:22 they're trying to build an API into the
web platform that will tunnel itself
0:23:27 over a couple of different transports.
0:23:29 One being the local Wi Fi that Apple
and, Apple iOS and Google Android have.
0:23:35 They're competing standards, but
they're going to try to create
0:23:37 a web API that papers over the
difference between these standards.
0:23:41 It uses your Wi Fi connections
to connect between devices.
0:23:44 Failing that, it can use Bluetooth
or NFC or any other of these, like,
0:23:48 local, localized transport layers to
be able to communicate between devices.
0:23:53 This would be, I think, one of
the most important things the web
0:23:55 could ever land if this happens.
0:23:57 There is a working group on it.
0:23:59 There's a kind of a spec already
working its way processed through.
0:24:03 I don't think we're going
to have it in six months.
0:24:04 There's going to take a little
while, but I'm very excited that at
0:24:07 least finally, there's some movement
towards let's not lock down, the web.
0:24:12 And by the way, one little side
note, there's a whole bunch of
0:24:15 stuff that the web platform should
enable, but does not enable.
0:24:21 Locks down or hobbles because we are,
for some reason, and we, I mean, as a
0:24:28 community, and especially the spec bodies,
we are unwilling to admit that there is a
0:24:33 fundamental paradigm difference between,
I've visited a web page one or more
0:24:39 times, There's that experience, which
definitely we should be distrustful of.
0:24:45 We should keep at arm's length.
0:24:46 There's a difference between that
experience and I've gone to a website
0:24:50 a few times and I really like it.
0:24:51 And I installed that onto my device.
0:24:55 Once I've said, I am
installing that onto my device.
0:24:59 I am saying, just like with any other app
that I install, please let it have all
0:25:04 the capacity that I'm willing to give it.
0:25:06 Pop it up and have it ask me, do
I want to give it this, and this,
0:25:08 and this, and let me say, yes, I
want to give it those permissions.
0:25:12 I don't understand why the web thinks of
itself as a unified medium when it is used
0:25:19 in these completely different paradigms.
0:25:21 We need to be forking what we allow
in the web platform, based upon
0:25:26 that flag, has it been installed?
0:25:29 Once it's been installed, I think
that is very much implicitly the
0:25:32 user saying, I trust this app.
0:25:34 Let this app do what I want it to do.
0:25:36 So things like local peer to peer,
they don't make sense for a drive
0:25:41 by website, and you should rightly
be scared about a website being
0:25:44 able to like talk to your watch.
0:25:46 Like I get that, but if it's an app
that's built with web technology that
0:25:50 a user trusted enough to install,
it should have this capability.
0:25:53 So just a little, side rant
there, but anyway, peer to peer
0:25:57 communication, the local ring.
0:25:58 We absolutely need to do that,
but none of that needs servers.
0:26:02 We can build this without servers.
0:26:04 I love those points and I was not
aware of this, standards work body,
0:26:08 in working in favor of bringing more
local peer to peer supports for the web.
0:26:14 I think this is very, very much needed.
0:26:16 Right now.
0:26:16 I think the closest we got that also,
makes that a little more focused on my
0:26:23 devices is like I'm using tail scale
to create sort of like a secure bridge
0:26:28 between my devices, but that is still
on an operating system level and not
0:26:32 something that the web platform can
easily, make use of to my knowledge.
0:26:38 But the other point you've been making
about the distinction between a website,
0:26:43 which you might just open once or a
few times, maybe for a webshop or for
0:26:48 like some, news outlet that like just
has everything littered with ads.
0:26:54 And so surely you want to be
much more careful about providing
0:26:58 too many privileges to that.
0:27:00 But if it's, let's say your
mail app or other sort of apps
0:27:04 you use on a daily basis, sure.
0:27:07 You want to give that more access and
possibly also in a way where, there
0:27:11 is more of like a local AI context
on your device, maybe even take a
0:27:16 step further and provide a way how a
native web app, like a native feeling
0:27:23 app that lives in your web browser,
maybe can even get access to that.
0:27:26 I feel like we're making
some steps towards that.
0:27:30 so for example, for Overtone, the music
app I'm working on, I've actually just
0:27:35 over the course of the past couple
of weeks, I've added support for
0:27:40 file system mounting, which is not
available across all browsers but,
0:27:44 Chromium based browser supports this.
0:27:47 I believe Oprah also supports this.
0:27:49 I might be wrong on this one, but I've
been primarily adding support for, because
0:27:54 I'm using Chromium browsers myself.
0:27:56 Are you talking about the OPFS?
0:27:58 So there's two things.
0:28:00 There is OPFS, which I'm already using as
a persistence mechanism for pretty much
0:28:05 everything for also for persisting my
SQLite database and images, media assets.
0:28:11 But there's also.
0:28:13 a feature that has mostly the same
API as OPFS, but instead of just
0:28:19 creating a new file system, like a
folder or files within the virtual file
0:28:25 system, you can actually ask the user.
0:28:28 to bring in an existing
file or existing folder.
0:28:32 So, in my case, I would allow the
user to select their music directory
0:28:38 from their local computer, or
possibly even from a NAS device.
0:28:43 And so this works both for sort of
like the show file picker model, as
0:28:48 well as for drag and dropping, an
existing file or existing folder.
0:28:52 So this already is a big step towards
like a more native feeling experience in
0:28:58 the web, but there's so many more aspects
to this that we haven't covered yet.
0:29:04 networking certainly being a
big one, whether it's just TCP
0:29:07 connections, UDP connections.
0:29:10 One thing that I'm also somewhat hopeful
of that this might bridge the boundaries
0:29:16 a little bit is to rely on browser
extensions to be sort of like a thing
0:29:22 that you could trust more and that could
facilitate that additional privileges
0:29:27 for a given website or a given web app.
0:29:31 That's something I'm thinking
about whether I should maybe
0:29:33 explore that for Overtone to give
you more native like affordances.
0:29:38 but yeah, that's maybe a
topic for another episode.
0:29:41 I've done some work in that.
0:29:42 I actually built a web app and built a
browser extension that I could use with
0:29:47 that web app and extended the capabilities
in like audio and visual sense.
0:29:52 So I've done some work with that.
0:29:53 There's a lot of challenges there, but
I do think there's a lot of potential.
0:29:56 and in particular, one of the things
we'll talk about, I think a bit later
0:30:00 in this episode, I very much intend
to go down the route of building,
0:30:06 Whether they be extensions or just side
companion apps that do give extensions
0:30:15 Definition of Web 2.5
0:30:15 I do just want to say, I only,
have described so far one
0:30:20 pillar of how I define Web 2.5.
0:30:22 There are two more and I don't, they
don't need quite as much time, but I
0:30:26 do just want to state kind of for the
record, what, how I define it, it's
0:30:30 just a term I made up, people may not
like it, but it's, it's how I define it.
0:30:35 So the first pillar was we do need to
build a web where data is ours, identity
0:30:40 is ours, and we can choose where we share
that data with our local ring of devices.
0:30:46 We can choose if we want to share it
out to cloud for other, you know, back,
0:30:50 there are reasons why you want to be
able to back things up or whatever.
0:30:54 Point number two, I think this speaks
actually to, a lot of the skepticism
0:30:59 around local-first, which is there's
no business justification for doing
0:31:05 local-first, if it's harder, if it's
more risky, if it's newer and weirder
0:31:09 businesses won't do it, and if businesses
won't do it, it doesn't matter.
0:31:13 You can have all the great ideas
in the world, but it won't matter.
0:31:16 one of the things that I liked the
most about my time at Socket Supply is
0:31:19 they really confronted this head on.
0:31:21 And they said, if we build a world
where it is very compelling and
0:31:26 straightforward for people to start
building in peer to peer communications
0:31:31 into their apps, we really start
challenging the question of Why did
0:31:35 you need the cloud in the first place?
0:31:37 For most things, you didn't need the
cloud except that you did not have a way
0:31:42 for two clients to speak to each other.
0:31:44 But if we get rid of that,
then you stop needing to pay
0:31:48 for most of your cloud bill.
0:31:50 And that is one of the largest
overheads that companies face these
0:31:54 days, and they're increasing in cost.
0:31:57 No matter what your provider is, whether
they're more specific providers like
0:32:01 Vercel or whether they're more broad
providers like the AWS's and Azure's
0:32:05 and Google's of the world, your bills
are going up because you're doing
0:32:10 more and more of your stuff there.
0:32:12 And one of the reasons you're doing
it is because it was technologically
0:32:14 easy to do so and less risky.
0:32:17 But the other reason you were doing so
is because somebody hadn't given you
0:32:20 a business reason to do the reverse.
0:32:23 one of the great things about
peer to peer designed systems is
0:32:27 that the bigger the peer to peer
network, the lower the costs go.
0:32:31 That's the opposite of, systems that are
centralized, the bigger the centralized
0:32:38 system gets, the more expensive it gets.
0:32:39 You don't get economies of scale and
you know, you're driving down your AWS
0:32:43 bill, it goes up the more you scale.
0:32:45 But in peer to peer systems, you
have this inverse relationship.
0:32:48 So I think there's actually a
really compelling business case.
0:32:52 For why companies who are trying to
figure out how do I cut down on my costs
0:32:57 might be asking themselves, is there
any way that I could offload any of my
0:33:00 cloud bill to peer to peer communication?
0:33:03 And even if I did just a little bit
to start with and then realized, oh,
0:33:06 that was great, and then I expand that.
0:33:08 The more you expand that capability
of your apps, you will create.
0:33:12 More compelling user experiences
than you will create in local-first.
0:33:16 And that's important.
0:33:17 But you'll also significantly reduce, and
maybe in some cases, completely eliminate
0:33:22 the footprint of your cloud overhead bill.
0:33:25 So that's number two, that I think there
is a really compelling business narrative
0:33:30 to building a web where businesses
Can more easily compete without almost
0:33:35 the rent seeking, landlord seeking,
Oh, we gave it to you for free when
0:33:39 you were small, but now you're big and
we're going to just charge you an arm
0:33:42 and a leg, and you can't get out from
underneath us, kind of thing like that.
0:33:46 That's how drug dealers work.
0:33:47 And that's just not a business
model we ought to be building
0:33:50 the web on, in my opinion.
0:33:51 So we have to fix that.
0:33:53 That's pillar number two.
0:33:55 And then pillar number three.
0:33:56 I maybe personally feel the
strongest about, even more so
0:34:01 than the ownership of data.
0:34:03 I have been to many places in the
world that it is a reality that you do
0:34:08 not have Unlimited internet and even
unlimited electricity to run your devices.
0:34:14 I've been to, you know, rural towns
in Africa where people hang their cell
0:34:18 phones off the light pole in the middle
of town to charge their phone all day.
0:34:23 And it costs them a week's wages to do so.
0:34:25 Like we take so many things for granted.
0:34:28 The web should be.
0:34:30 The largest human umbrella, the
largest umbrella that mankind has ever
0:34:34 made, that humankind has ever made.
0:34:36 It should be that, and it should
encompass, or be able to encompass, all
0:34:41 8 plus billion people on the planet.
0:34:43 Right now it's serving,
like, a third of the world.
0:34:46 Two thirds of the world is not privileged
enough to experience the same web
0:34:50 that you and I get to experience.
0:34:52 They don't have an always on internet
connection like the way that we're
0:34:54 recording this right now, right?
0:34:56 They have spotty internet, or no internet
at all, and it's metered, it costs a lot.
0:35:01 and we are not building a web where
they can participate, and, and where,
0:35:05 and even if they can't participate,
they can't participate as equals.
0:35:08 They don't have the same footing.
0:35:10 We should be, I think morally, if
not for any other reason, building
0:35:15 a web that they can participate.
0:35:16 And I don't see any way I don't see any
way that we extend the web to the last
0:35:22 two thirds of the world's population.
0:35:25 simply because some billionaire
hangs a balloon up in the air to
0:35:28 give them internet or whatever.
0:35:29 Like, that's not the solution.
0:35:31 That's how billionaires want to solve it.
0:35:32 The way I want to solve it is from
the ground up, by rebuilding the web
0:35:36 in a way that says, once you get the
information that you need, the data that
0:35:40 you need, or create it, and once you
have the application, you don't need the
0:35:45 internet to keep doing what you're doing.
0:35:46 You're a local fish farmer, you're
working, you can upload the data into
0:35:50 the thing, you can drive to market,
synchronize with the market, and
0:35:53 sell your goods, and you don't need
a cloud server to do any of that.
0:35:56 We should be building that world.
0:35:58 So that's the third pillar of what I call
Web 2.5 is building a web that actually
0:36:03 works for all of humankind instead of
only the privileged part of the world.
0:36:08 I love those points.
0:36:09 And I think this is where we can also now
like close the loop nicely, since I think
0:36:14 all of those points are really, really
welcome and like really core of what
0:36:19 the local-first movement is all about.
0:36:22 And I think this is also what brought
you under this local-first umbrella.
0:36:26 I love the last two points
that you've laid out.
0:36:28 There is not just about the
second point where you made about,
0:36:32 the bigger a centralized system
gets, the more expensive it gets.
0:36:36 but I think it's also, if you
think about the developers who
0:36:39 are the creators who are building.
0:36:41 Smaller apps that have an ambition, maybe
similar to how I'm building Overtone.
0:36:46 I actually, I want to charge for the,
the value that the app is creating
0:36:51 for the quality of the app, for
like the differentiation of the app.
0:36:56 I don't want to charge for, like someone's
internet usage and the data is actually
0:37:03 in my way there to make that happen.
0:37:06 like data shouldn't be part of my equation
for how I'm charging for something and to
0:37:13 make matters even worse, maybe less so for
a music app or, but for many other apps,
0:37:17 for example, let's say someone wants to
build another, like highly specialized
0:37:22 and highly personalized health app.
0:37:24 This is where it's not just maybe at
some point expensive to move the data
0:37:28 around, but it's actually data can be
seen as a liability, particularly in
0:37:33 a more highly regulated environment.
0:37:35 And I think this is where encryption,
which we'll get into shortly as well, I
0:37:41 think is a very nice antidote to that.
0:37:44 And then the last point you've made
about, like that the web shouldn't just
0:37:49 serve the highly privileged, fraction
of the world population, I think that's
0:37:54 also very core to local-first and maybe
another meaning to local-first as well.
0:38:00 Not just like that local-first,
the app works in your local
0:38:05 context, but I think it's also
that an app should maybe be more.
0:38:10 Locally created in the
context that you're working.
0:38:13 We've explored that in the conversation
I had with Maggie Appleton a while ago.
0:38:19 And I think this is really what's driving
her motivation around local-first.
0:38:23 That de facto right now, most apps that
are out there are being built by like
0:38:30 a very small group of people living in
Silicon Valley, living in New York, a
0:38:36 few hub, like hubs within the world.
0:38:39 but that's actually not where most of
the people are that are using the apps.
0:38:44 If we address many of the underlying
challenges that we want to solve with
0:38:49 local-first, I think this can also
empower and enable so many more local
0:38:55 creators to build much more specialized
and custom apps for specific local
0:39:01 parts of, different parts in the world.
0:39:04 So I just want to offer that as an
extension to the last point you made.
0:39:09 Yeah, 100%.
0:39:10 I love that.
0:39:10 You know, a good way of saying that
is that it's built by the privileged
0:39:14 for the privileged, but why not let
everybody build what, you know, I'm
0:39:18 never going to be able to understand
what that fish farmer needs, but if we
0:39:21 can empower him to build the thing that
he needs, he'll understand it better.
0:39:24 And he would be in a much better position
to build an experience that works for him.
0:39:29 We need to create the pieces of that
puzzle for other people to assemble
0:39:34 rather than assuming I'm not going
to build all the world's apps.
0:39:37 I know that I'm hopefully going to
build a couple of Lego pieces that
0:39:40 will be useful in many of those apps.
0:39:43 Identity
0:39:43 Awesome.
0:39:43 So let's shift gears a little bit and
get a little bit more technical since
0:39:47 one ingredient we'll need to make all
of this happen is not just moving data
0:39:52 around, which we've explored in many other
conversations on this podcast so far.
0:39:57 But one particular aspect of that is
also that like, not just two random
0:40:02 devices are exchanging data in a
completely trustless way, but a device
0:40:07 might also be owned by a person who
has a particular identity or might even
0:40:13 on that given device have maybe there
might be multiple identities at play.
0:40:18 And so how do you retain an identity?
0:40:20 How do you, kind of exchange identity
information, that your, I love the way
0:40:27 how you put it, like your device ring,
how all of those devices can trust each
0:40:31 other, how all of that is made work,
how, and I think there's this typical
0:40:35 tension in security where if you want
to make it secure, that often comes at
0:40:40 the cost of convenience and vice versa.
0:40:43 And that's sort of.
0:40:44 Sweet middle ground where it's
both convenient and secure.
0:40:47 I think that's also very tricky.
0:40:49 So this is an area that you've really
deeply explored and you've built a
0:40:54 whole bunch of different projects.
0:40:56 I think one of them is
being the Lofi.ID, project.
0:41:00 You also have another project
on GitHub called Local Vault.
0:41:03 So maybe you want to give us an
introduction to what you've been
0:41:07 working on there, and then we
can take it one step at a time.
0:41:11 Yeah, so big picture overview.
0:41:13 is that if you are going to own data
on your device, and that's going to be
0:41:19 the source of authority for that data,
which is the premise for local-first,
0:41:24 then I believe that you both need to
be able to secure that data, meaning
0:41:29 securing it at rest, which involves
encryption, and you're going to be
0:41:33 able to need to Securely ensure that
data goes only where you want it to go.
0:41:39 Plain text data being sent around
and backed up in other places,
0:41:43 that's not going to cut it.
0:41:44 So we are going to need encryption
to be part of this equation.
0:41:49 And To boil a lot of real complicated
technology down to hopefully
0:41:54 something that just about anybody
can understand, we have this who's
0:41:58 protecting the master key problem.
0:42:02 No matter what encryption scheme you
design, whether it's password based,
0:42:06 where you derive an encryption key from
something that I type in, or whether
0:42:11 it's I've generated a key and I'm going
to Randomly, and that is your encryption
0:42:15 key, no matter which mechanism, or there's
a bunch of other variations thereof,
0:42:19 but no matter which mechanism you have,
you have this kind of encryption upon
0:42:24 encryption upon encryption, but at the
very top of that chain, you have the
0:42:27 master key, the master password, whatever.
0:42:30 And how do you protect that?
0:42:32 That's the common problem.
0:42:33 And in fact, going all the way back
to the work that I did at Hero,
0:42:37 the Web3 company that I worked at,
they had a very similar problem.
0:42:41 They were trying to create smart
contracts around the Bitcoin chain with
0:42:45 the separate blockchain, and they needed
the ability to, you know, to round trip
0:42:50 transactions in a completely trustless
way between one blockchain and the Bitcoin
0:42:56 blockchain, between Stacks and Bitcoin.
0:42:57 And they have this exact same
problem, which is who's going
0:43:00 to hold the master keys?
0:43:01 And how are you going to do
that in the open, but not
0:43:03 let everybody have it, right?
0:43:04 So we always run into this problem of It
all sounds well and great until we get
0:43:10 to the final piece of the puzzle, which
is how do you handle the master password?
0:43:13 I've been banging my head on
this for years, trying to figure
0:43:16 out there's got to be some way.
0:43:18 And the advent of biometric passkeys
was when the lightbulb went off for me.
0:43:23 Because What Passkeys do and what
the biometric subsystems on these
0:43:28 devices do is they offer a, I think,
compelling answer to that question,
0:43:34 which is there is no perfect storage
for the most secure root, master,
0:43:41 passkey, whatever you call it.
0:43:43 There's no perfect solution, but the
best that we can get is dedicated
0:43:47 hardware on the device that is not
Just free and open to any app, right?
0:43:53 If we can have a dedicated hardware
for this purpose, the secure enclave or
0:43:58 whatever it's called, and then we can
have operating systems that are designed
0:44:01 to very strong, strictly control access
to that, and it's designed in like a
0:44:06 write only way, you cannot read from it.
0:44:08 You can write to it once, and
then you can never read from it.
0:44:11 You can send data in and get results
back out, but you can never ask that
0:44:15 thing to give you its private key.
0:44:17 That really offers, I think, the most
compelling answer we've had so far
0:44:21 to where do we store the master key?
0:44:24 But one of the big problems with that,
it's not in and of itself a solution
0:44:28 to this, to this question is because.
0:44:32 I don't have access to that key.
0:44:34 That means I can't use that key
for encryption purposes myself.
0:44:40 I can create a passkey with my thumbprint
or my face or whatever, but I can't
0:44:45 get access to that key material to
use it for my own encryption purposes.
0:44:49 And I couldn't figure out how we were
going Make passkeys work in a zero
0:44:54 server assumption where there's no
servers and in a way that I could
0:44:58 piggyback upon it to create encryption.
0:45:01 And then it occurred to me that we can
actually bury the key material in the
0:45:06 passkey by way of the user ID field,
or there's actually another mechanism
0:45:11 that is coming along that I think
will be even better than the user ID.
0:45:14 But the main point is, we can actually
piggyback on top of these passkeys.
0:45:18 And in this secure part of the
device, store something in a way
0:45:22 that I think is maybe 99 percent
guaranteeable, that's a lot better
0:45:27 than almost 0 percent guaranteeable
with anything that's in userland apps.
0:45:31 Is it perfect?
0:45:32 No.
0:45:33 But it's absolutely a, you know, a
paradigm step up in terms of security.
0:45:39 And so the whole rest of everything
that I'm building is based on that
0:45:43 one assumption, which is where we're
going to solve the master passkey
0:45:46 problem is by basing this on passkeys.
0:45:50 That does have some
questions that it raises.
0:45:54 How are we going to onboard apps?
0:45:57 on devices that do not already
have biometric capabilities.
0:46:01 They don't have these secure hardware.
0:46:04 I think the good news is that more
and more devices are getting that.
0:46:07 And I think that will continue.
0:46:08 I don't think we will see a,
you know, a pullback in that.
0:46:12 I think we will see more and more
devices getting those capabilities.
0:46:15 So over time that becomes less and
less of a problem, but we do need
0:46:19 an exit ramp for not just telling
somebody, sorry, you're out of luck.
0:46:24 So I've been working on some ideas
around creating kind of a secondary
0:46:29 way of doing things that's not
biometrics based, pattern drawing
0:46:33 that's more complicated and can
create more entropy, things like that.
0:46:37 So I think we do need some exit
ramps there, but I'm going to make
0:46:39 the assumption that for the primary
class of devices that we want to
0:46:44 target here, we have the biometrics.
0:46:47 Once we have that, once
we have that capability.
0:46:49 We needed a way to be able to manage
pass keys without relying upon servers.
0:46:54 So the first library that I wrote
was WebAuthn Local Client, which was
0:46:59 designed to wrap around the web API
that exposes the passkey subsystem,
0:47:04 but doesn't make any assumptions
about communicating with the server.
0:47:07 the use cases in local-first don't need
what the server would do anyway, so that's
0:47:13 not a problem, but it's just no other
libraries out there that I had found where
0:47:17 it could work if you didn't have a server.
0:47:19 So I wrote a library that exposed
that API in a way that made the
0:47:23 assumption you weren't going
to communicate with the server.
0:47:26 You were going to store things securely.
0:47:28 You were going to generate
the challenges on device.
0:47:31 You were going to keep track of
the key and verify that was coming
0:47:35 out was not man in the middle.
0:47:36 You were going to do all of that.
0:47:37 on device, not on server.
0:47:40 So that's what WebAuthn local client was.
0:47:41 That was the first little
piece of the puzzle.
0:47:45 Then I said, okay, well now we need a
way to, piggyback on top of the passkey
0:47:51 system and create something that we can
use for encryption purposes so that we can
0:47:55 protect data both at rest and in transit.
0:47:58 we need some keys.
0:47:59 And I did a lot of research in this.
0:48:01 I'm not an expert.
0:48:02 I'm not a mathematician.
0:48:04 But I settled on, this was back when I was
working at Socket, I settled on, Elliptic
0:48:09 Curve keys, specifically the Edwards
key, the ED25519 key pair as the best
0:48:17 master key pair because you can generate,
that can be used for signing, and you
0:48:21 can generate a sub key pair from that.
0:48:23 That's the Curve 25519 keys
for encryption and decryption.
0:48:28 I settled on that as the best, but
that's not the only way of doing it.
0:48:31 And certainly anybody else could
substitute their own encryption,
0:48:34 or maybe we're going to need to
upgrade that encryption in a post
0:48:38 quantum world in some few years.
0:48:40 But, that's where I landed was,
let's use that, because I think
0:48:43 that's good enough and strong enough.
0:48:45 And I found the Libsodium library,
which is big and complex, but it's,
0:48:49 I been ported to tons of platforms
and that was important to me.
0:48:53 And so I based the ideas around securing
our data on that type of key pair.
0:48:59 So we generate a 25519 key pair.
0:49:03 We take the seed of that, or in my
library, I call it an IV, but IV
0:49:07 or seed, we take the seed of that.
0:49:09 And that's what we store in the passkey.
0:49:11 And with that information coming back
out, each time you put your thumbprint
0:49:14 or your face ID in, you can reconstitute
that key pair and then decrypt
0:49:19 whatever data was previously encrypted.
0:49:21 That is how we fix that
master password problem.
0:49:26 So I built a library to help you do that
and that's called local datalock is the
0:49:30 library that wraps around the WebAuthn
local client, but then it does the
0:49:35 generated encryption key, stick the seed
into the passkey, it does all that stuff.
0:49:41 it does not do anything
about storage of it.
0:49:43 Right?
0:49:44 So you might use local data lock when
all you care about was transmitting
0:49:47 secure data, but it does provide
the pieces for the next one.
0:49:52 The next one was we need to figure out
how we're going to store that data in
0:49:58 an encrypted fashion on the device.
0:50:01 And then, so it's encrypted on
write and decrypted on read.
0:50:05 How are we going to do that?
0:50:06 Well, I actually realized I need
two pieces, not only one to manage
0:50:09 the encryption piece, but actually
I needed a library to manage the
0:50:12 storage piece, because there's
a lot of different variations of
0:50:15 storage, as we were just talking
about with OPFS and things like that.
0:50:19 So I built the Two libraries
to help with this piece.
0:50:22 One library is, I've spun out actually,
it's not even local-first really, it's its
0:50:28 own thing, which is just abstracting local
client storage in a key value way across
0:50:35 all the five major storage mechanisms.
0:50:37 So cookies, local storage, session
storage, indexDB, and OPFS.
0:50:42 And technically under OPFS, there's
two different ways of managing it.
0:50:45 One is more device limited, but
it's the in thread communication
0:50:51 that you can do, asynchronously.
0:50:53 But the more broader device support,
basically all devices at this
0:50:58 point, or all modern devices at
this point, is OPFS in a worker.
0:51:02 and if you do OPFs in a worker, which
you're nodding because you've seen
0:51:06 the same problem, but managing workers
and all of that stuff is difficult.
0:51:09 So that's what this library does, is it
abstracts across all of those mechanisms
0:51:13 the exact same asynchronous key value API.
0:51:17 And that library is called Storage.
0:51:19 It's part of my BYOJS Bring
Your Own JavaScript initiative.
0:51:23 so we'll have a link to that.
0:51:24 But that storage library, even if
you didn't do anything local-first,
0:51:28 you just wanted to store data, I
think that would be useful to help.
0:51:31 Think of it as kind of a more
modern Local Forage, maybe.
0:51:34 Local forage has been around for a decade,
but it's not really maintained anymore,
0:51:38 and it didn't support all the mechanisms.
0:51:41 I think storage is a compelling
option to look at if you're sticking
0:51:47 anything on a local device, even in
local storage, maybe have a better
0:51:50 API and a more secure API for that.
0:51:53 So first of all, storage there, that
has nothing to do with encryption.
0:51:55 It's just The raw reading
and writing from a disk.
0:52:00 And then the last piece of the puzzle,
the one you mentioned before, is the
0:52:03 local data vault . So that library is
what takes storage, WebAuthn, local data
0:52:08 lock, and all those pieces together,
and gives you that local vault, which
0:52:15 is a secure, encryption secured, based
on passkeys, encrypt on write, Decrypt
0:52:20 on read key value storage mechanism.
0:52:23 And you can, of course, choose which
of those places you want to store, like
0:52:27 store it in IndexedDB or store it in OPFS.
0:52:29 But it does all the encryption
and decryption stuff for you
0:52:33 based on the passkey subsystem.
0:52:35 So that's what I've built so far.
0:52:38 Where all of that is going
is towards, there's two ways
0:52:43 that I see this happening.
0:52:44 First of all, I think apps can start
to use, web apps can start to use those
0:52:49 libraries, whatever pieces of that makes
sense to you, use all of it, use part of
0:52:54 it, but start to use those pieces to do
some of this stuff yourself in your own
0:52:58 apps, build your own solution if you want.
0:53:01 I also think that we need to
lower the barrier for apps
0:53:04 to do a lot of this stuff.
0:53:05 And I also think that the more
consolidated of approach we get,
0:53:09 the better chance we have of
something like this catching on.
0:53:12 And so instead of just writing like
a standards doc and saying, if you do
0:53:17 it, you have, you must do it this way.
0:53:19 the approach I'm going to take is to
build a companion Wallet app that allows
0:53:24 you to manage as a user, any number
of your own identities, Protected, of
0:53:29 course, through this passkey subsystem.
0:53:32 And apps will have an SDK that they
can interact with the Wallet app,
0:53:37 whether that Wallet app is a browser
extension, like we mentioned a little
0:53:40 while ago, or whether it's a literal
actual side, you know, companion app.
0:53:44 They'll be able to interact
with that app to ask that app,
0:53:48 Hey, tell me who this user is.
0:53:51 Tell me that it's the same
user as they were before.
0:53:53 That's one question.
0:53:55 So instead of them needing to build
their own authentication, they'll
0:53:57 simply make a call to this Wallet and
say, verify for me that this user is
0:54:01 who they say they are and give me back
their identifier, which might be their
0:54:05 key or some other UUID that you specify.
0:54:08 That's one question.
0:54:09 But also I think those apps shouldn't need
to roll their own encrypt all of my data
0:54:15 and decrypt it all and all of that stuff.
0:54:17 So they'll also be able to provide
the data to the Wallet app and ask
0:54:22 it to encrypt it for them through
that SDK and decrypt it for them.
0:54:26 And again, based all
of that around passkey.
0:54:28 So they don't need to
invent any of that stuff.
0:54:30 The Wallet app will just
take care of it for them.
0:54:33 And then the last piece of the puzzle is.
0:54:35 if you build an app, let's say like
it's a, you know, it's a note taking
0:54:39 app, or it's a social media app,
or whatever, and it does need to
0:54:41 communicate with other devices, instead
of you doing your own synchronization
0:54:46 logic, I think we can actually have
the Wallet app built with peer to peer
0:54:50 capabilities so that my Wallet app on
my phone and my Wallet app on my laptop
0:54:55 and on my tablet can synchronize my
identities, but can also synchronize
0:54:58 userland app data through the Wallet.
0:55:01 Use the Wallet as a tunnel
to do synchronization.
0:55:04 when I say synchronization, I do not
mean that I'm solving anything that what,
0:55:10 what the larger local-first community
says when they say synchronization
0:55:13 with all the CRDTs and all the
merging and stuff that I want to
0:55:17 leave open to this community to solve.
0:55:19 You can plug in whatever.
0:55:21 CRDT systems you think make sense and
whatever strategies you make sense.
0:55:25 I'm simply going to provide the transport
layer through peer to peer various peer
0:55:29 to peer technologies in this Wallet app
so that those bits can get from my phone
0:55:34 to my watch, to my laptop, to my tablet.
0:55:37 And then you'll, your app will
decide what do we do with that?
0:55:40 In your own app logic, you'll decide
how do we merge these competing
0:55:44 sets of bits that are coming in.
0:55:46 I just don't want for people to have to
go invent all of their own wheels there.
0:55:49 And I think a single unified Wallet
app will allow people to do that.
0:55:54 there's other things that I want that
Wallet app to do, but that's kind
0:55:57 of the main, starting point, the 1.
0:55:59 0 that I want this Wallet app
to do is to give that to the
0:56:02 local-first community and say, please
consider building upon that Lego.
0:56:07 Perfect.
0:56:07 So this was a lot and, kudos to you
for doing such comprehensive research,
0:56:14 deliberating the different options.
0:56:16 There's always like so many different
paths that you could go in regards
0:56:20 to like all of the different
decryption encryption mechanisms, like
0:56:25 choosing, should you use Libsodium?
0:56:27 Should you use WebCrypto?
0:56:29 Should you use other things, for
what it's worth for Overtone?
0:56:32 I've also landed on using
Libsodium, which, I needed to even
0:56:36 compile my own WASM version to
trim it down a little bit more.
0:56:40 but, yeah, so you've covered a
lot of ground there and I have
0:56:44 a few follow up questions where
I would love to learn more.
0:56:48 also one observation that I just,
as someone who appreciates like
0:56:53 good terminologies and clear
concepts, I just love the term Vault.
0:56:58 As something that, both signals like, Hey,
this is something where it can put stuff
0:57:02 in and get stuff out and it is secure.
0:57:05 So a vault being sort of that combination
of your storage mechanism and that
0:57:11 search mechanism has nothing to do
with encryption at that point, but if
0:57:14 you then combine it with encryption
and decryption, that makes a vault.
0:57:19 I think that's a very intuitive concept
that is, that works both as a concept for
0:57:24 developers, as well as even for end users.
0:57:28 like I think this is what also 1Password,
for example, has started to use.
0:57:33 And I think, 1Password users are
familiar with that also, I'm sure
0:57:37 for other password managers as well.
0:57:40 And so that as a concept, I
hope that it's not just a.
0:57:44 a concept that is used within the
local vault and like the stack that
0:57:49 you're exploring here but hopefully
that's something that as a term,
0:57:53 can be useful for others as well.
0:57:56 Yeah, I agree.
0:57:57 I think it does communicate
what it needs to.
0:57:59 I workshopped that with some of my
social media community, by the way.
0:58:03 I had lots of different suggestions and
I, you know, kind of pieced together
0:58:06 various things, but I workshopped
some of the naming of this, you know,
0:58:10 crowdsourced it because I wanted to
make sure I got a name that really
0:58:13 communicated properly, what I was up to.
0:58:16 So to me, it sounds like you've landed
on a great option here and I might
0:58:20 actually steal that for myself and,
the ways how I'm like in my own data
0:58:25 stack, where I have a database right
now, it's not encrypted address,
0:58:28 but I want to encrypt it more.
0:58:30 And so maybe I can also use
for the SQLite database there.
0:58:35 Maybe I can also start calling
that a vault if it's encrypted.
0:58:38 I like that a lot.
0:58:39 and I also like how you've
already thought a step further.
0:58:43 it's not just as that, like as a tech
stack that can be implemented by a
0:58:48 given apps or high level libraries,
but also from a user perspective, if
0:58:53 you're not just going to use one app,
the kind of part of the entire promise
0:58:57 here is that, like here you have data
in one app and data in another app.
0:59:02 That, and maybe those apps want to
work together and that is actually
0:59:06 something that is like really, really
difficult in today's web2 world.
0:59:12 Where like, just think about
like how much of an effort it is.
0:59:15 That's maybe the best we got.
0:59:16 Maybe it's like a Slack, integration
that like Slack is like a little bit more
0:59:22 aware of like what that Figma link means.
0:59:26 And, I can open it all in my browser.
0:59:29 So from my perspective, it kind
of feels like, Oh my gosh, why
0:59:31 don't you have that context?
0:59:33 So if we, embrace a little
bit more of the user.
0:59:37 The identity concepts, and then also let,
that dictate a little bit of the share,
0:59:43 the context sharing and access control.
0:59:45 I think that can lead to
much better user experiences.
0:59:49 there've been many, many years of
attempts to create in the mobile space.
0:59:54 there was like web intents and then
web share and share intents and like
0:59:58 all these other variations and it went
through various different names and
1:00:03 standards processes stumbled with it.
1:00:05 I don't even know where that currently
stands, but that's exactly where I'm
1:00:08 headed is basically, let's just get around
any of those limitations and allow, for
1:00:13 example, a use case where, you know, I
might be in a local-first note taking app,
1:00:18 and I might have written a note and I want
to, you know, copy a piece of that note,
1:00:22 and I want to send that out to one of my
text messaging recipients or one of my
1:00:26 chat recipients or whatever, so I can take
that note and I can synchronize, I can
1:00:31 share that information to this other app
in a fully secure, end to end secured way.
1:00:36 But it ends up in my other app, and
that other app pops up, and there it is,
1:00:40 in the exact same way that, you know,
you can currently do sharing intents.
1:00:45 Native apps have that, but the web has
always been, you know, a third class
1:00:50 citizen at best in that sort of cross
app collaboration and in sharing story.
1:00:57 And I think we can make it a
fully first class story this way.
1:01:01 And I think that also takes us in
possibly even a step further that
1:01:05 goes beyond today's conversation.
1:01:07 so far we talked about identity
and also a part of that identity is
1:01:12 like authenticating as assuming that
identity or being denied that identity.
1:01:17 that's often abbreviated as Auth, but
Auth can also mean another non abbreviated
1:01:24 word, which is authorization, which I
think this is not yet covering that,
1:01:29 but there, I want to plug another very
interesting project that is more around
1:01:34 authorization, which is called Beehive.
1:01:37 that's also been published on
the Ink and Switch website.
1:01:41 and there's currently,
I think, not yet a full.
1:01:44 Inc & Switch style essay about that, but
there are some notes being taken on this.
1:01:50 And so this is a project that, Brooklyn
Zelenka and Alex Good is currently
1:01:54 working on that is, also ongoing
research in combination with AutoMerge.
1:02:00 And Brooklyn has been exploring a lot
of that, as her previous work On vision
1:02:05 and related projects, so, and this is
where, the authorization concepts to my
1:02:10 understanding is sort of based around
the ideas of capabilities and, that
1:02:17 different users can basically, share
capabilities, and privileges basically
1:02:22 up to a level that they have themselves,
whether it's read or write and so on.
1:02:27 So I'm sure this is like an equally
deep and challenging topic and, but they
1:02:32 feel a little bit, complementary to me.
1:02:35 So hopefully there's like some
convergence here as all of
1:02:39 those are like very deep topics.
1:02:41 I did see that Beehive
announcement just recently.
1:02:44 I think that's great.
1:02:45 I think we need a lot of different
flowers blooming in this field to figure
1:02:49 out and find the places where there's
going to be overlap and collaboration.
1:02:53 By the way, just as a little bit of a
side note, I literally just yesterday.
1:02:57 learned something that maybe everybody
else listening has already known
1:03:00 and I didn't know, but just for the
benefit of the audience, the word
1:03:04 auth is you, A U T H as you correctly
point out, is a little too ambiguous.
1:03:08 It's a little too shortened
because we don't know, do you mean
1:03:11 authentication or authorization
1:03:13 but I saw somebody do auth
Z for authorization versus
1:03:17 auth n for authentication.
1:03:19 So if we just add on that one extra
letter to that shortened word auth,
1:03:23 n or auth z then we know maybe
better what we're talking about.
1:03:28 So I learned that yesterday and I'm
going to use that going forward.
1:03:32 Amazing.
1:03:32 I was not aware of that, what that
little letter N in that context meant.
1:03:38 there's also what you've
mentioned, web auth N.
1:03:41 Maybe that is what it's already using.
1:03:45 Perfect.
1:03:45 Well, today I learned, thank you
for sharing that little learning.
1:03:49 and kudos to everyone who
was already aware of that.
1:03:53 Passkeys
1:03:53 So I have not personally used passkeys
yet as part of the applications
1:03:58 I'm working on, but I am using
applications that use passkeys.
1:04:03 I'm like more and more like.
1:04:04 One web service after another
is like rolling out support
1:04:07 for it, and I currently manage
pass keys as part of 1Password.
1:04:12 I'm giving 1Password the benefit
of a doubt that they do manage
1:04:16 all of that securely for me.
1:04:17 maybe there's like at some point
1Password armageddon but hopefully not.
1:04:22 knock on wood but, Using web keys for
your own web applications or applications
1:04:28 more generally, can you help me through,
understanding that what that entails?
1:04:33 Like, what are the boundaries of that?
1:04:34 For example, if my, either one
password manages my pass keys, or
1:04:40 if my operating managers pass keys,
what does that mean in terms of re
1:04:46 authenticating on another device.
1:04:47 So let's say I'm like, you've
built this amazing note taking app.
1:04:52 I'm starting to use it
on my desktop computer.
1:04:56 I have like gone through like some
sort of initial setup process.
1:05:00 I needed to like scan my finger.
1:05:02 So the passkey was created.
1:05:04 And now let's say on my tablet, I
want to also work on the same notes.
1:05:10 How does the setup
process there look like?
1:05:12 Do I use, for example, as I'm in
the Apple ecosystem, do I trust
1:05:16 Apple to synchronize pass keys?
1:05:19 Is there like a more manual
pairing step that I need to do?
1:05:22 Similar to how, like in, WhatsApp, for
example, there's the QR code scanning.
1:05:28 What are the, are there
different ways, how to do that?
1:05:30 Is that just taken care of?
1:05:32 Can you help me understand that?
1:05:34 Yeah, absolutely.
1:05:35 So, we need to be very clear that there's
the standard way that almost all web
1:05:41 apps, basically, practically all of
them, are currently doing it, which
1:05:45 involves a server, and then we need to
distinguish that from what I'm proposing
1:05:49 as is the future for local-first, which
is servers become optional, and in
1:05:55 many cases, don't exsist at all, right?
1:05:57 That's the zero server
world that I was pitching.
1:06:00 So the way that things currently work
and the way almost all web apps, you
1:06:04 know, my bank uses biometrics, so
let's just use them as an example.
1:06:08 Right.
1:06:09 So what my bank obviously has is a source
of authority record about who I am, and
1:06:15 they want to make sure that I'm the only
one, no matter what device I come in from,
1:06:18 I'm the only one who can access their
source of authority for my banking info.
1:06:23 the way that they do that is they have
multiple authentication mechanisms
1:06:28 attached to my account in their server.
1:06:31 They have a username and password,
of course, because you're going to
1:06:34 have to access this from devices
where that's the only option.
1:06:38 But they also have Other records in,
associated with my account that are the
1:06:44 pass keys that I have registered when
I was already authenticated with the
1:06:49 bank account through some other means,
including potentially another pass key.
1:06:53 Anytime they have an inbound,
here's a new pass key.
1:06:56 They just associate that
with my account as well.
1:06:59 So I have like two or three different
devices where I have pass key
1:07:02 authenticated with my bank and their,
I don't know their database structure,
1:07:06 but a, Ostensibly, they have like a
one to many relationship from my user
1:07:09 account to all the various different
ways that they know that it's me, right?
1:07:14 So any inbound passkey that
looks like this, it belongs to
1:07:19 Kyle, show him his bank account.
1:07:21 So the way that process works is that on
the server, in a place that they fully
1:07:24 control, as opposed to in the web or a
client that they may not control, on the
1:07:29 server, they generate a random challenge,
which is just a random set of numbers.
1:07:34 They sent that up to the device where
the passkey is going to be presented.
1:07:39 And that challenge is sent into.
1:07:42 The device, and it is encryptically,
it is digitally signed, doing
1:07:48 a digital signature, which
is different from encryption.
1:07:51 They create a digital signature using
the internal private key of your
1:07:56 passkey that nobody has access to.
1:07:58 It's stuck in the secure hardware.
1:08:00 Nobody can get at it, right?
1:08:02 They send that signature back out, and
they send that signature along with
1:08:06 the public key that you've already got.
1:08:08 That's what you've stored, is you've
stored the public key already.
1:08:11 But they send that signature back to the
server, and the server checks to make sure
1:08:15 that it was able to create a signature
that matches the public key that they
1:08:19 already know is your passkey, right?
1:08:22 So that's how they know that it was
the same you on whichever device is if
1:08:27 you were able to successfully sign the
challenge and send it back to the server.
1:08:31 What many of these services do is
have that one to many relationship
1:08:38 where you could have as many of
these biometric keys as you want.
1:08:41 Some of them are a little bit more
naive or ignorant where they just
1:08:45 literally have one, but the, Important
thing from their perspective is
1:08:51 that they have an identifier that
they know is me, that my bank has
1:08:56 an identifier that they know is me.
1:08:58 I don't know what that is, but they
have an identifier they know is me.
1:09:01 And they either are going to stick
that in the passkey, So that when
1:09:04 that passkey comes back in, that they
know it was me, or they're going to
1:09:08 manually store that public key or
both, but they're going to be able to
1:09:12 match those things up and say, this
challenge came from a device that Kyle
1:09:17 owns and has previously told us is him.
1:09:22 So we're going to let him
have access to his bank.
1:09:24 That's basically how passkeys work.
1:09:26 Currently work.
1:09:27 I've glossed over some details, but it's
basically how passkeys currently work.
1:09:30 And so you notice that the server is
playing an important role here because
1:09:35 the server ostensibly can't be compromised
to generate a fake or replayed challenge.
1:09:43 The server keeps track of every challenge
that it's ever sent out, and it never
1:09:46 sends out the same challenge twice, and
all of these others, like, secure things.
1:09:51 And also, the server, because it's going
to be what's called FIDO2 compliant,
1:09:56 this really complex specification, that
basically does a, traversal of the public
1:10:03 key certificates for the relying party
to verify that it is in fact, I mean, for
1:10:09 the authenticator to verify that it is in
fact a valid authenticator and not some
1:10:14 made up, you know, faked one or whatever.
1:10:16 So FIDO2 servers do all
of that complex stuff.
1:10:19 some apps, I would imagine probably
banks They really, really care about
1:10:23 this stuff and they probably implement
all of that complexity in the backend.
1:10:27 I would wager to say that most apps
do not verify the authenticity.
1:10:34 They simply rely on, if you sent me a
matching signature, I'm good with it.
1:10:39 Even if it was a man in the
middle, I don't care, whatever.
1:10:42 A bank definitely cares if I've had
a device that's been compromised and
1:10:46 there's a man in the middle, that's,
you know, taken over my authenticator.
1:10:49 So they are probably going to keep
running up the flagpole of the public
1:10:53 key certificates, you know, all the way
up to the root certificate or something.
1:10:57 They're probably going to do
that, but most apps are not.
1:11:00 But that's why you have a FIDO2
servers, because you do not want
1:11:03 to do that complexity yourself,
and you definitely don't want to
1:11:06 try to do that in the browser.
1:11:07 Now, we move to this other way of
thinking, which is that there is
1:11:12 no central, decision of who I am.
1:11:16 There's no like central source
of authority for who I am.
1:11:19 Who I am is just simply that I
have chosen to collect a bunch of
1:11:23 me's together into one identity.
1:11:26 One me on my phone, one me on
my laptop, one me on my tablet.
1:11:30 That's me in an identity sense, right?
1:11:33 It's not me in a humanness sense, but
it is me in a digital identity sense.
1:11:37 And, that's what the bank has done.
1:11:39 You know, they've verified my
humanness by make, you know, I
1:11:42 couldn't open an account without a
driver's license and other things.
1:11:45 We're not dealing with that part of
authentic, you know, of identity right
1:11:49 now, we're just simply talking about
digital identity is a collection of
1:11:53 essentially these key pairs that I have
said, these three key pairs constitute
1:11:59 me across my different devices.
1:12:00 When we start talking about how do
I synchronize my passkeys, in that
1:12:05 scenario I was describing before, you
created a different passkey on each
1:12:09 device, and that bank kept track of
each of those different passkeys.
1:12:13 But you notice that I said some,
don't let you do multiple pass keys.
1:12:17 They only let you do one.
1:12:19 And that is why Google and Apple
allow you now to both of them now
1:12:24 support this Google just recently,
but they now allow you to synchronize
1:12:28 your pass keys between your devices,
using your Google or Apple accounts.
1:12:32 So I could literally have the
same, you know, passkey on
1:12:37 my phone and on my laptop.
1:12:39 But something really important to
note is, it's not actually the same
1:12:43 passkey, because the device is still
generating the secure key pair.
1:12:49 What they synchronized was not the
actual secure enclave key pair,
1:12:54 because that's not even possible.
1:12:56 The hardware is holding
on to the key pair.
1:12:58 What they're synchronizing is just the
metadata in that user ID field and the
1:13:02 user handle and all that other stuff.
1:13:04 That's what's being synchronized
so that that matches up.
1:13:07 So my same ID shows up in Two
different passkeys, but it looks
1:13:12 to the bank as if it's one passkey.
1:13:17 That's basically what that
synchronization is happening.
1:13:21 So.
1:13:22 Rightly or wrongly, but I think rightly,
people have complained that passkeys
1:13:27 are definitely more user complex.
1:13:29 People have to think about like, you
know, all of this synchronization
1:13:32 stuff, which is why nobody does that
anymore with their usernames, passwords.
1:13:36 Almost everybody's using
a password manager.
1:13:39 And it's why I'm arguing that since the
world is using password managers, we
1:13:43 can just have essentially a password
manager that I'm going to call a Wallet
1:13:47 that does the same stuff for you.
1:13:49 You don't want to worry
about, Synchronizing between
1:13:53 all your different devices.
1:13:54 That's crazy, right?
1:13:55 So back to the local-first world.
1:13:58 Since I'm simply saying that I'm
going to create these identities on
1:14:03 my different devices, and I'm going
to kind of group them together,
1:14:06 I'm going to decide when they sync.
1:14:08 the Wallet can actually synchronize
those key pairs between devices.
1:14:13 So you could literally say, I want the
exact same key pair on all of my devices.
1:14:18 And then the way that you're authorizing,
the way that a device is knowing that
1:14:22 it's okay, we basically just flatten
it out to, if you're able to decrypt
1:14:26 the data, then you have the identity.
1:14:28 And if you're not able to decrypt the
data, then you don't have the identity.
1:14:31 We've just basically
simplified the whole thing.
1:14:34 Now, I recognize that
there are trade offs here.
1:14:36 We don't have quite as strong of an
assertion as we do in the bank account
1:14:41 centralized server world, but I'm going
to actually argue, not even on this
1:14:46 podcast, but just as my continuing
work, I'm going to argue that it's
1:14:51 better for us to move in this direction.
1:14:53 It's better for us to not
have banks getting to have
1:14:56 the say so about who we are.
1:14:58 It's better for us to get to say that.
1:15:00 So I'm going to argue
that those trade offs.
1:15:02 are actually an improvement, not
a downside, but there are trade
1:15:06 offs where we don't have quite the
same level of central authority
1:15:10 guaranteeing as somebody's humanness.
1:15:13 So I appreciate you giving me a
very deep introduction and beyond
1:15:18 an introduction, quite the lecture
in a positive sense on refreshing
1:15:23 my own knowledge and understanding
on like some cryptography aspects
1:15:27 and how those things work together.
1:15:30 And I think there is an interesting
evolution that will probably, is
1:15:34 already happening and will just
continue to happen, where security
1:15:38 is really, really difficult.
1:15:39 Like, like you said, like a bank needs
to go all the way, and there's like
1:15:43 many pieces of our technology there
that we're using, like a browser itself
1:15:48 probably being one of them, where it
needs to go really great extents to
1:15:53 make everything as secure as possible.
1:15:55 And while still trying to make us
things as simple and easy for both
1:16:01 users and developers as possible.
1:16:03 And there's like this really interesting
middle ground and where there's still
1:16:08 this tension of like, okay, sure you
can make it a tad easier for users.
1:16:12 And that might come at
the expense of security.
1:16:15 But that boundary is also
like shifting slightly.
1:16:18 And I would say passkeys have
actually been, both a step forward
1:16:22 in terms of security for users.
1:16:24 And also, things are moving
in a direction where they also
1:16:27 actually become easier for users.
1:16:30 I think, yeah, I think we've got
some growing pains where right
1:16:33 now, at the immediate as we're
having this conversation, it
1:16:36 does feel harder to most people.
1:16:39 But I think we, We have made a
paradigm shift where we will absolutely
1:16:44 achieve what you're talking about.
1:16:45 Because If you just take a step back and
you think about all the complexity that
1:16:50 is currently around the username and
password standard for authentication,
1:16:55 which requires people to like pick new
passwords for all their device, all their
1:17:00 accounts, but nobody, most people don't.
1:17:02 And then all the different requirements,
like this site requires capital
1:17:06 letters and this one requires numbers.
1:17:07 And most people don't even manage that.
1:17:09 Now they just let a
password manager do it.
1:17:11 And then all the complexity around what
happens when my password gets known.
1:17:16 And I did share it.
1:17:17 And now that can be used, like all
of that stuff completely goes away.
1:17:21 And in replacement is my
thumbprint or my face.
1:17:26 Now I understand that getting to
that point is definitely a bit
1:17:30 of an uphill climb that we're
getting closer to the top of.
1:17:33 But once we are there, I cannot imagine
that any user, even a completely non
1:17:38 technical user is going to be like, wait a
minute, I don't understand this thumbprint
1:17:42 thing, but I was totally cool with all
of these emails and password requirements
1:17:46 and capital letters and all that stuff.
1:17:48 Like nobody is going to say that
eventually, eventually they are going
1:17:51 to say pass keys are so much faster.
1:17:54 So much more streamlined, so much more
user experience optimized, but we are
1:17:58 still in the process of getting there.
1:18:00 And I know why people bristle at
that claim right now today, there's
1:18:05 rough edges now, it's getting better.
1:18:08 And I think there is a second Category
of those sort of uncanny valley symptoms,
1:18:14 similar to how, like when web 2.
1:18:16 0 just started to become a thing and
people started to figure out how do I
1:18:19 do authentication, in the like web 2.
1:18:23 0 world.
1:18:24 where, like, I remember the first
PHP thing that I've built where
1:18:28 I needed to authenticate users.
1:18:30 I used good old, like, MD5
as, like, the password hash.
1:18:33 Well, that very first system, I did
not hash at all, and then I used a
1:18:37 much more secure thing, MD5, and then
I learned about Rainbow Tables, etc.
1:18:42 And eventually, there's, like, things
like Auth0, etc., and, like, single
1:18:47 sign on, which took away quite a lot
of that responsibility and that pain.
1:18:51 But now as we're shifting to
local-first, we're reopening then
1:18:56 all of those cans of worms again with
new security technologies, such as.
1:19:01 Pass keys, et cetera.
1:19:02 Things have moved on.
1:19:04 now there are quantum computers possibly.
1:19:06 So we need to rethink how
we even encrypt things.
1:19:09 so it's a moving target.
1:19:11 And I think right now there's probably
also the complexity an average app
1:19:15 developer needs to think about in regards
to, making their app secure and private
1:19:21 for users is much higher than what I
would say in five years from now, the
1:19:26 local-first data frameworks that will
be available in five years from now,
1:19:31 most of them are already having this
on the roadmap, but in five years, it's
1:19:35 going to be, or even like in one year,
three years in the future is going to
1:19:39 be, Much less complexity that a app
developer needs to think about today,
1:19:46 we all appreciate and need to hear this
sort of lecture on like how all of that
1:19:51 works, because the technologies are not
quite there yet, that I could just say.
1:19:57 I pick my favorite local-first data stack,
and they all implement the best practices.
1:20:02 And all I need to look for is sort of
like, Oh, the work with past keys is done.
1:20:06 And I don't need to, as an app
developer and as an app user, I don't
1:20:10 need to do anything more right now.
1:20:12 As an app developer, you need to know
quite a bit about the moving pieces.
1:20:17 And then each month and each
year by year, We can forget about
1:20:21 the underlying implementation
details as all of that matures.
1:20:25 So I just wanted to highlight that, and
that is a bit of an uncanny valley, but
1:20:30 things are moving in the right direction.
1:20:32 Every one of them currently is inventing
their own solution for identity in some ad
1:20:40 hoc and informally specified way, right?
1:20:42 They are all doing that right now.
1:20:45 Of course as, as a human with an ego.
1:20:48 I hope that they just see how
amazing this Wallet is that I build.
1:20:53 And they're like, let's stop doing that.
1:20:54 Let's just use Wallet, right?
1:20:55 Like I hope that's the case in reality.
1:20:58 I think they'll pick
something much lower level.
1:21:01 And what I strongly assert they
should do is base it on passkeys.
1:21:06 And I hope that even if nothing else that
I've done makes sense for your stack,
1:21:12 the WebAuthn local client making it easy
for you to deal with the passkey system
1:21:16 without worrying about the servers and
FIDO and all of that is, I think the way
1:21:20 that local-first should go at a minimum.
1:21:23 I hope that the other stuff I'm building
is useful, but at a minimum, I really
1:21:26 think building that on top of a passkey
system, and I think a library like mine
1:21:31 will make that much more approachable.
1:21:34 I wanted to use passkeys, and I
didn't want to build a library for it.
1:21:39 But when I surveyed the landscape of those
libraries, they were all server centric.
1:21:43 And that's why I built one that
can at least work for the cases
1:21:47 where a server might be optional.
1:21:49 So for whoever has made it through all the
way to now and has like absorbed all of
1:21:55 those details and hasn't had enough yet.
1:21:57 I highly recommend you just
check out those amazing projects
1:22:01 that Kyle has been working on.
1:22:03 Both try to build a little app with it.
1:22:06 And if you're extra curious, also
like look at the implementations.
1:22:10 Actually not that much
code in most places.
1:22:12 And you get to see how the web
APIs under the hood work in case
1:22:18 you need to use something that's
a little bit more low level than
1:22:21 you've already seen a mechanism,
a implementation, how this works.
1:22:25 That's typically how I go
about those sort of things.
1:22:28 I try to see, can I use an existing thing?
1:22:30 And if not, then I try to learn from the
existing thing to build my own thing.
1:22:36 And then this is sort of
this dance back and forth.
1:22:38 Later on, the existing thing
is good enough and I throw
1:22:41 away my own thing again.
1:22:42 So try to learn from Kyle's
implementations and try to
1:22:46 use them in your own apps.
1:22:48 Before wrapping up this already pretty
long conversation, there was another
1:22:53 project that I think you worked on before,
and I'm not sure how mature it is or
1:22:58 whether it was more of an experiment,
but it did catch my attention because
1:23:02 I thought it was, very interesting
and had a bunch of like putting
1:23:06 things together in a novel way to me.
1:23:09 and so the project I'm referencing
here is like the QR data sync project.
1:23:14 Would you mind giving a overview what
that was about and also how it came to be?
1:23:20 So, first of all, status.
1:23:21 QR Data Sync is absolutely a first
class citizen in this same ecosystem
1:23:27 and is absolutely going to be part of
the Wallet app that I'm building because
1:23:31 we need multiple transport mechanisms
for data that go between devices.
1:23:37 Obviously, a preference would be, make
it just happen super seamlessly under
1:23:42 the covers with something like the
local peer to peer or another peer to
1:23:46 peer protocol or Bluetooth or anything.
1:23:48 It's like Any of those ways would
be better, but there is always
1:23:52 going to be a need for fallbacks.
1:23:54 And one of the fallbacks
is the QRDataSync.
1:23:58 There's another one, which is
not a library that I wrote,
1:24:00 but I absolutely intend to use.
1:24:02 It's called SilentJS.
1:24:03 SilentJS actually transmits data between
devices using supersonic sound waves.
1:24:09 So it uses your microphone and
your speaker between two devices
1:24:13 and it transmits data that way.
1:24:15 Fascinating stuff.
1:24:16 I didn't write that library, but I
think it's super awesome and that's
1:24:19 going to be in the Wallet as an option
if you are trying to synchronize.
1:24:23 Very important to point out.
1:24:25 Some of these fallbacks are going to
be bandwidth limited and size limited.
1:24:29 You're not going to synchronize
a gigabyte of data through
1:24:32 sound waves or through QR codes.
1:24:35 Okay, so the bare minimum that you
might do would be to synchronize
1:24:39 your identity between those devices,
which is very small, you know, A
1:24:44 couple of hundred bits of data.
1:24:46 And then once you have that, you
now have established the ability
1:24:49 to create a more secure tunnel
through other mechanisms through
1:24:52 the internet or something like that.
1:24:54 So that's where I see things like
QR data sync and silent JS being
1:24:58 is kind of that lowest level.
1:25:00 Let's synchronize my identities across
devices, but then all that heavier
1:25:04 data synchronization stuff that's
going to happen, it should go through
1:25:07 a more high throughput channel, like.
1:25:09 You know, something that's or UDP based.
1:25:13 Just briefly to touch on QR data sync,
the way that library works is it creates
1:25:18 what are called animated QR codes,
not my original invention, but I saw
1:25:22 it years and years ago, and then I
didn't really see it ever go anywhere.
1:25:25 And it just stuck in the back of my head.
1:25:27 An animated QR code is nothing
more complicated than a whole
1:25:32 bunch of QR codes shown in rapid
succession, like an animated frame.
1:25:37 Each QR code can have
a chunk of data in it.
1:25:39 And so you take a big chunk of data,
say like, you know, 10k of data.
1:25:44 It's a string.
1:25:45 You just break that up into a series
of chunks, and then you do some
1:25:49 padding so that you make sure that
the QR codes are all uniformly sized.
1:25:52 And then you just show
those chunks in succession.
1:25:56 My protocol in this library just has
a very tiny little header on it that
1:26:00 has the total number of frames that
are going to be shown and what the
1:26:03 frame index is that's being shown.
1:26:05 So then you have a camera on a different
device that is reading QR codes.
1:26:09 And by the way, it's reading
them very, very quickly.
1:26:11 It reads them in like less than 15
milliseconds or something, but you
1:26:15 just hold up your camera to a device
that's displaying a set of animated
1:26:20 codes and the camera is reading those.
1:26:22 And it's just doing an infinite
cycle, by the way, the sending is
1:26:26 just sending them all in order because
your camera might miss a few of them.
1:26:30 And so it just holds in its memory,
all the ones that it knows that
1:26:33 it needs until it just keeps.
1:26:35 keeps going until it has read all of
the frames, and then it reconstitutes
1:26:40 the data on the other side.
1:26:41 So that's what QR Data Sync is.
1:26:43 It is hopefully a fallback mechanism
at best, but it's certainly
1:26:51 Outro
1:26:51 I love this so much.
1:26:53 This stimulates so many parts
of like, what I like as a geek.
1:26:58 particularly when some, Digitally
tricky concepts become visually
1:27:04 a little bit more tangible.
1:27:07 And given that here with a QR data
sync, the visible and visual component,
1:27:13 but given that you've also mentioned
the Salient project, which move
1:27:17 that to another dimension, to the
dimension of like hearing and sound.
1:27:21 this sparks all sorts of like ideas
in my head in the same way, where you
1:27:25 can, somewhat style a QR code to look
a little bit more like, brand related.
1:27:30 I'm wondering, could I actually
make the audio pairing, whether I
1:27:35 can, manipulate that in a way to
be related to what you're doing.
1:27:41 In my head, there's sort of like those,
those like old school modem sounds.
1:27:45 So it's like back to the future in a way.
1:27:48 so I'm, I'm very glad I
asked about this project.
1:27:51 and it's not just a very, curious
and cool aspect of it, but I think
1:27:56 it's also very practical and that's
something that, people in the Web 2.
1:28:01 0 world are already quite familiar with.
1:28:03 What I've mentioned before, whether
you're pairing a, WhatsApp app from one
1:28:08 device to another that is not animated.
1:28:11 This is where a single static
frame already is enough.
1:28:15 But I think the patterns are already
there, end users are familiar with
1:28:20 them, and putting this all together in a
pluggable way that allows for different
1:28:25 options, all under this umbrella of
your packages that you're working on.
1:28:30 Super fascinating stuff.
1:28:32 So Kyle, I think we're already
running well on time here.
1:28:36 but I really, really appreciate you coming
on, sharing your background, sharing what
1:28:41 led you to local-first and then sharing
everything about your explorations and
1:28:46 deep work and local-first identity,
AuthN, local vault, all of those projects.
1:28:52 Thank you so much for sharing all of that.
1:28:54 Can I give one last little tidbit?
1:28:56 The world, if we went back 10 years,
and if you tried to convince people 10
1:29:01 years ago, that the whole world needed
to move away from usernames and passwords
1:29:07 as the single factor for authentication
and that the whole world was going to
1:29:12 move to owning multiple devices and we
were going to be able to like generate
1:29:16 these numeric codes that were randomly
changing in time and things like that.
1:29:20 And if you told people 10 years
ago that billions of people in the
1:29:24 world would do that, most people
would say that'll never happen.
1:29:28 But if you fast forward 5 or 10 years, the
vast majority of the world has upgraded
1:29:32 to multi factor for authentication.
1:29:35 We've still got a long way to go.
1:29:37 I'm not saying that it's a fixed
problem, but we have absolutely
1:29:41 upgraded the world to understanding
the concepts of multi factor.
1:29:45 So what I'm suggesting in the move forward
with going to a Wallet and going to this
1:29:50 local-first identity is akin to that.
1:29:53 Will it take a while and will it
take users changing their mindset
1:29:58 and will it take big players pushing
it and requiring the adoption?
1:30:02 Yeah, it absolutely will.
1:30:04 It's a, it is a hill to climb, but I
just wanted to point out that, concept of
1:30:10 multi factor auth is not going to go away.
1:30:12 It's just going to evolve in this app.
1:30:15 So for example.
1:30:17 This app is going to have a TOTP number
generator, where you can use it as a
1:30:21 second factor of auth, but instead of you
having to look at your phone and then type
1:30:26 in the numbers, if you have the Wallet app
on your phone and on your laptop, and your
1:30:30 laptop is challenging you for a second
factor of auth, All you need to do is
1:30:34 open up the Wallet app on your phone and
say, give me a code and instantaneously
1:30:39 that code can synchronize to the Wallet
on your desktop and then paste from the
1:30:43 Wallet on your desktop into the form.
1:30:46 You don't need to sit here and type
all of these numbers so we can have an
1:30:50 upgraded view of what second and multi
factor auth is if we go in this direction.
1:30:56 And that's one of the things I'm
most excited about because we should
1:30:58 not be compromising on security.
1:31:00 We should be upgrading security, but also,
as you've said several times, putting the
1:31:05 user experience first and foremost here.
1:31:08 I think arguably a lot of the multi factor
auth was pretty rough for users at first.
1:31:13 SMS codes and all these other
things, you know, waiting 10 minutes
1:31:16 for a text message to come in.
1:31:18 We still have a lot of that.
1:31:19 There's still a long way to go.
1:31:20 But because we've made so much progress
there, I am very bullish on the fact
1:31:24 that we can make the same kind of
progress towards this web 2.5 where we
1:31:29 own our data and we own our identities
as we take them through different
1:31:33 apps and through different devices.
1:31:36 That's a wonderful summary.
1:31:37 I'm very excited about that future.
1:31:39 Kyle, thank you so much for
sharing all of that with us today.
1:31:43 Thank you for having me.
1:31:44 It's been a thrill to dig into it.
1:31:47 Thank you for listening to
the Local First FM podcast.
1:31:50 If you've enjoyed this episode and
haven't done so already, please
1:31:53 subscribe and leave a review.
1:31:55 Please also share this episode
with your friends and colleagues.
1:31:58 Spreading the word about this
podcast is a great way to support
1:32:01 it and help me keep it going.
1:32:03 A special thanks again to Rosicorp and
PowerSync for supporting this podcast.
1:32:07 I'll see you next time