#17 – Kyle Simpson: Local-first identity

November 12, 2024

The guest of this episode is Kyle Simpson, a prolific JavaScript engineer and author of the book You Don’t Know JS. Over the past years, Kyle has been researching user identity and encryption in a local-first context which we explore in depth in this episode. This conversation will dive into the story that led Kyle to local-first including what he calls Web 2.5 and Zero Servers.

Editor's Note: when Kyle speaks about SilentJS, is actually referring to QuiteJS (link below)

Mentioned in podcast

Links:

Thank you to PowerSync and Rocicorp for supporting the podcast.

Transcript

localfirst.fm #17 – Kyle Simpson: Local-first identity

00:00if we build a world where it is very compelling and straightforward for

00:05people to start building in peer to peer communications into their apps, we really

00:11start challenging the question of Why did you need the cloud in the first place?

00:15For most things, you didn't need the cloud except that you did not have a way

00:20for two clients to speak to each other.

00:23But if we get rid of that, then you stop needing to pay

00:26for most of your cloud bill.

00:28And that is one of the largest overheads that companies face these

Intro

00:36Welcome to the local-first FM podcast.

00:38I'm your host, Johannes Schickling, and I'm a web developer, a

00:41startup founder, and love the craft of software engineering.

00:45For the past few years, I've been on a journey to build a modern, high quality

00:49music app using web technologies.

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

00:55This podcast is your invitation to join me on that journey.

00:59In this episode, I'm speaking to Kyle Simpson.

01:02A prolific JavaScript engineer and author of the book, You Don't Know JS.

01:07Over the past years, Kyle has been researching user identity and encryption

01:12in a local-first context, which we explore in depth in this episode.

01:16We start the conversation with a story that led Kyle to local-first, including

01:20what he calls web 2.5 and zero servers.

01:24Before getting started, also a big thank you to Rosicorp and PowerSync

01:29for supporting this podcast.

01:31And now my interview with Kyle.

01:34Hey Kyle, so nice to have you on the show.

01:36How are you doing?

01:37I'm great.

01:37Thanks for having me.

01:38I'm thrilled to be here.

01:40You've been digging into some aspects and some corners of the

01:43local-first ecosystem that I think not as many have yet really dug in

01:49so deeply, namely around local-first identity, encryption, et cetera.

01:52So I'm really excited to get into that, but, not to get ahead of myself.

01:57Maybe you want to briefly introduce yourself, give a bit of background

02:01and, maybe share how we, how we get to talk about this today.

02:05Yeah.

02:05my name's Kyle Simpson.

02:07Most people online, and especially in the web and JavaScript

02:10community, will know me by Getify.

02:12I've been around for a very long time now, and, probably some of the biggest

02:17things that I'm known for is having written the You Don't Know JS books.

02:22the first edition came out in 2014, 2015.

02:25That's a series of six books about JavaScript.

02:28And then I did a second edition, some of those books that we wrote

02:31in a second edition, around 2020.

02:34so that's how most people know me.

02:36I've done a lot of teaching, a lot of conference speaking in the web and

02:39JavaScript space, and kind of tried to promote the web as a platform.

02:44And JavaScript is a key piece of that platform.

02:48Specifically with local-first, my interest, I arrive at local-first

02:52kind of almost accidentally because I was working on things that

02:57I thought we needed to create.

02:58And I didn't know that there was anybody else that had come up

03:01with terms or pioneering this.

03:03So I sort of separately was trying to invent something not

03:07that dissimilar from local-first.

03:08And I had a series of like specs that I was going to try to write around

03:12it, but that comes from a passion for why we need to own our identity, as

03:18opposed to offloading that to GitHub, or Google, or Microsoft, or whatever.

03:23We need to own that.

03:24We need to own the control of the data that we create, and the

03:28data that is created about us, to whatever extent is possible.

03:32And so that kind of got me interested in this space, this particular

03:36usage of the web platform, and of JavaScript as a technology.

03:41I found the local-first space through some employment, and then

03:45started getting involved in that.

03:47community, the meetup that runs on the discord and all of that.

03:51Met Jans who runs that.

03:53And so that's what brings us to today is that my passion kind of started over the

03:57last three to five years, really trying to leverage what I've been able to do

04:01and what we can do with this platform for the good of moving the web forward, I

04:06believe, back to us owning our identity.

04:10Awesome.

04:10Yeah.

04:11You've mentioned that I think you had now two opportunities to,

04:14see a couple of like different products in the local-first space.

04:18I think one of them would be Socket Supply, which is, exploring peer to peer

04:23software, which is really interesting.

04:25And then also the AI startup, Vella.

04:28I'd be interested in hearing a little bit more what motivated your move

04:32to work at Socket Supply, like given the focus on peer to peer, maybe

Kyle's journey: Web 3, Socket Supply, Vella and Identity

04:40Yeah, there is a little bit of, it's a winding road, right?

04:44There's not a straight line path.

04:45so going back several years when I was starting to get interested in this, I

04:51was looking for a job at the time because I had gone through some layoffs and

04:54I'd been unemployed for a little while.

04:56And the company that ended up, interviewing me, they reached out to me.

05:01interviewed me and then heavily recruited me, was actually a

05:04Web3 company, a crypto company.

05:06Now I'd known about the Web3 crypto space for a while, had felt like most of

05:10it was not something that I would super get behind and endorse, especially the

05:15currency side and all the, you know, the speculative financial instruments

05:19and all of that, not something I'm into.

05:21But I was interested because this particular company builds smart

05:25contracts and I do think that smart contracts are one of the core gems that

05:30I think Web3 could bring, some real improvement to the world of software.

05:35So they recruited me and they specifically asked, can you come and join us?

05:40And because you're so big in Web2, can you help us attract Web2 developers?

05:44That was my role.

05:45I wasn't really an engineer.

05:46I was really more almost a dev rel, but I needed to learn the space and

05:50so I spent that four to six months I was there trying to immerse myself in

05:55the web3 world and understand that and in no way do I want to say anything

06:00bad about web3, but I'm not here to support it in any way because I ended up

06:05leaving that world because I didn't fit.

06:07I didn't fit because I don't believe that the world that's being spun in

06:14Web3, which by the way comes from some pretty deep roots in like the

06:18genre of cyberpunk fiction, and I read some of those books to like get

06:23myself into the mindset of this world.

06:26I don't believe what they believe, I think, which is that they believe that

06:31the world's current track is inevitably going to lead to ruin, and they've created

06:38the only oasis that anybody can jump to.

06:41And they believe, I think, that it's not only inevitable that people will

06:45jump, but that it's self evident.

06:48That people will make the jump.

06:50If just more people hear about it, they will obviously say, let's do that.

06:54I didn't fit in that world.

06:55I'm not criticizing the people that believe that, but they just

06:58kind of papered over that gap that exists between web2 and web3.

07:03So over that four to six months, what codified in my mind was there's definitely

07:08some things that we need to work on.

07:09They don't look like Web 3 at least yet.

07:13And I left and I told them I'm leaving cause I'm going to go build

07:17what I'm going to call Web 2.5.

07:19If we ever are going to get to Web 3, which I don't know if we

07:22are or not, not my say, but we have to take an intermediary step.

07:27We're not going to make that jump.

07:28I feel confident in predicting that we will not simply make

07:31that giant leap over the chasm.

07:34So we can talk about what I define as Web 2.5.

07:39But those ideas came from kind of swinging the pendulum too far, I think

07:45maybe, towards that decentralized world, which is what Web3 is all about.

07:50And then saying, let's swing it back a little bit and figure out some way

07:54to achieve that with what the web currently is and building on top of

07:58and evolving what the web currently is.

08:00That is what led me to Socket.

08:03Socket supply.

08:04They, build a mobile, tooling set and framework.

08:08others in that space are Tauri and Ionic and way back in the day, PhoneGap for

08:13building hybrid applications where the UI is built around a web and in a web

08:18view with a backend that is native and extending the native capabilities into

08:24the web space, that's what they do.

08:26I was very attracted to that specifically because of their ability to allow

08:32a web application to have full peer-to-peer communications capabilities.

08:37They exposed UDP based, relay based peer-to-peer protocol

08:42directly to a web application.

08:44I felt like that was a big, it still is a big missing piece for the web platform,

08:49and it felt like the way to move forward.

08:52Not that I love native apps and I just want us to all build only native apps.

08:58I really do love the web platform, but this felt like a good compromise.

09:01If we can build an app in the web platform and then wrap A rather thin wrapper around

09:07it to give it these extra capabilities that for some reason, the web just

09:11won't give apps right now, then I think we can actually move forward if we can

09:16have true peer to peer communication.

09:17So, join Socket Supply to work on that and in particular, to

09:21work on putting encryption into that peer to peer relay protocol.

09:26That's what I spent a lot of my time there doing.

09:29I also did a bunch of DevRel stuff.

09:31I'm no longer with Socket.

09:32I was there for about 10 or so months.

09:34I'm not with Socket anymore, but that was part of my journey.

09:37And then several months went by where I was unemployed after leaving Socket

09:42before, the founder of this Vella.

09:46ai.

09:47he's the one who runs the meetup in the local-first space.

09:51He came to me and said, I've seen you active in the local-first community.

09:55would you consider helping me co found this?

09:57And the story that he spun was incredibly attractive to me.

10:01It seemed like a really obvious place to attach my passion for identity.

10:08What he said was I've been working on smart assistant.

10:11It's going to use AI, but I really believe that AI should work as

10:14much on the device as possible.

10:17Given the constraints that we have in devices, put as much of that on the

10:20device as we can, because this is really sensitive personal data that doesn't need

10:25to be just slurped up into the cloud.

10:27And that really resonated with me believing in local-first.

10:31And more importantly, if you're going to build apps like that, where you have

10:36your data on your device and you have it on multiple devices and you really

10:41are trying to break down some of the silos between apps like mixing your

10:46Google data and your Apple data and your Spotify data all into this one thing.

10:51What was really obvious to me was we're going to need a way to, if we're eschewing

10:55all of those services, then we're going to need a way to define our identity

10:58so that we can keep things straight.

11:01And that identity needs to be really local-first.

11:04So that's what attracted me to Vella, was go work on the identity piece to

11:08try to help their story, progress.

11:11I spent several months with Vella, they're a great, group of folks.

11:14Fortunately, we just I didn't have enough funding to keep me

11:17working in a paid capacity there.

11:19I'm still advising them, still wishing them the best.

11:21And they're, they're continuing on in their sort of smart email

11:25inbox app to rule the world.

11:28And I hope they achieve it because I want to use that app.

11:31I look forward to that.

11:32So that brings us kind of to today.

11:35Vella is the reason I started putting together some of the

11:39puzzle pieces for Identity.

11:41I was going to build it for Vella, but I'm just building it right now in the

11:45open source so that hopefully these Lego pieces are something that apps like Vella

11:50and others, hopefully in the local-first space will pick up and build upon.

11:55Perfect.

11:55Well, that's quite the arc of like different chapters from peer to peer

12:00to locally running AI, et cetera.

12:02I'm eager to get into each of those, but maybe taking a few steps back, you said

12:07something that captured my attention.

12:10I'm also not a person who's a big believer in Web3.

12:13I'm rather skeptical.

12:15If it happens and if those ideals prevail, I won't stand in the way of it.

12:19But I'm a little bit, just skeptical of like what it's the

12:22bad stuff it attracted so far.

12:24And so I'm very interested in the good ideas behind that.

12:29A lot of like interesting research that came out of that.

12:32But I agree.

12:33It is too far of a step, too of a radical step from how things, work

12:38today and like how practical everything is today to a much more idealistic,

12:45but in many regards still, to me, it seems like impractical, A to B.

12:50So if there's like a middle ground there that maybe has a bunch of like the

12:55more attractive things from the future, from that Web3, Utopia, who knows?

13:00and you framed that as Web 2.5 . I'm very curious how you define that

The Zero Server Paradigm

13:10Yeah, so speaking specifically about local-first, just because I know most

13:15of the people that'll be listening to this do understand local-first, but I

13:18want to re emphasize of the seven points of the original Manifesto from Ink

13:24& Switch I think the kind of, narrative arc that comes out of that is that we

13:31have built software for the last 20 or almost 30 years with an increasing

13:36mindset towards server and cloud first.

13:40We build apps where we, architect and design what that's going to be.

13:44And then we create extensions of that experience into the client.

13:48And I think what local-first says is let's flip that paradigm.

13:51Let's start with what can the client experience be and what should it be?

13:56And where should that data reside in the client?

14:00And then optionally, you might choose to enhance that experience

14:05with a cloud or server experience.

14:07Flipping that default assumption where you start what you prioritize when you design.

14:12I think that's one of the most important aspects of the

14:16local-first manifesto and movement.

14:18And I would say that that requires you to ask, what does my app do

14:25in a zero server environment?

14:27How does my app behave in a zero server environment?

14:30Zero server is, that's my term, not a generally accepted term,

14:35but here's how I define it.

14:37It is either that there is no server in existence, Or, that

14:42server effectively doesn't exist because there's no connection to it.

14:46And there's a thousand different reasons why that connection might not exist.

14:50Might be down, might be the company went out of business, might be flaky internet

14:55on the client or the server or both.

14:57But, Zero server means this app is on its own.

15:01There is no connection to a mothership and how's it going to behave?

15:05And it really should behave like a full fidelity experience.

15:08Here's my, go to example for this.

15:11Banking apps.

15:12We all know that banking apps are online apps, and they're all built

15:17with the assumption that when you log into your banking app, you want

15:20to see the most instantaneous, up to the minute information about

15:24your current bank account balance.

15:26And they certainly own the source of truth about what your bank account balance is.

15:31No argument there.

15:32However, there's a ton of information and functionality that is not

15:38requiring live updates of data.

15:41There's all of my previous banking history, years and years worth, tens

15:46of thousands of transactions, some of which might be useful if I'm preparing

15:50taxes or I'm trying to analyze my budget or figure out what I spent

15:53things on or whatever, and I don't need a live internet connection and a live

15:57up to date bank balance to do that.

16:00But as everybody knows, you can't log into your bank app without an internet

16:03and get in access to that data.

16:06It's very much my data and I very much still have the app on my device and I

16:11can't pair those two together because there was an assumption that the server

16:14was a required piece of the puzzle.

16:17And I think that's just a failing.

16:18It's a failing of business models.

16:20It's a failing of product design.

16:22It's a failing all the way across the board.

16:24To have not prioritized, assuming I start with this and then we add on later.

16:30That bank app could very easily let me see all of my data and have a very prominent

16:34icon there that says, this is not your live bank balance or just hide the bank

16:39balance if they were really worried about that, but they could very easily

16:42give me all that functionality on my existing data that was kept on my device.

16:47So that's one of the reasons I resonate with local first.

16:51And in a way, it's also the simplest use case where basically all your

16:57transactional history is typically like append only and immutable.

17:01It's not that your bank's going to say like, Oh, actually like this

17:0410, 000 transaction back there, like it's never happened but all of

17:08that is like basically set in stone or should really be set in stone.

17:12That's like the nature of the domain.

17:14So this should make it the simplest use case actually to support this.

17:18Yeah.

17:19The CRDT there is pretty simple.

17:23In local-first terms, there's not a lot of merging.

17:25You're right.

17:25That's a, that's a good point.

17:26Like the technical barrier is not really there.

17:29It's, it's a failure of business model and a product design.

17:33So, I very much believe that we need to do those things, and, I call that version

17:40of the web, or at least that's one pillar of what I call the Web 2.5, a web that

17:46stops being drunk on the idea that the only way to build an app is to start with

17:51cloud infrastructure and then work your way back to the client, but rather start

17:55with client infrastructure and maybe or maybe not work your way toward a server.

18:00I think there's a ton of apps that never need any servers whatsoever.

18:04The probably most motivating example that got me interested in this

18:07space was going back several years.

18:09There's a landmark, you know, world changing legal ruling in the U.

18:13S.

18:14that I'm, where I'm at, from the Supreme Court that eliminated federal protections

18:19for women to have the right to choose abortions, and other types of, healthcare.

18:23And I'm not a uterus having person.

18:26I can't.

18:27Get pregnant or have an abortion, but I absolutely have people in my

18:29life that I care about that can.

18:32I have a daughter, I have a wife, like, this matters to me,

18:35and there was actually a case.

18:37It wasn't just sort of made up.

18:38There was actually a case where data that a woman had in a period of

18:43menstruation tracking app was Captured and used against her by government

18:49and law enforcement authorities.

18:50And that is just like that is so quintessentially the bad future

18:56that we never should have built.

18:57We never should have enabled.

18:59And it just snapped in my mind.

19:00Like we have the technical capability to let people create really useful and

19:06engaging experiences around data that they own, that is about them, that is

19:11very personal, and there's no reason that data ever has to go out to somebody

19:15else's device because that's the trap.

19:18I make the assertion that if you do not have custody of your data, then

19:23you do not have ownership of your data.

19:25Custody is the whole game.

19:27So when we give it out to those servers, then of course you're going to have

19:30governments that are going to find either ways to backdoor the encryption or legally

19:35force them to get access to that data and they're going to use it against you.

19:39And no matter where you are on the political spectrum, no matter where

19:43you are on the techno spectrum, you must agree with me that that's

19:47not a future that we want to build.

19:48Where they can do whatever they want with our data and manipulate us.

19:52That can't be what with a rational level head says is, is

19:57what we ought to be building.

19:57But we have built that and we've gotten dangerously close to that.

20:02So Web 2.5 is saying we need to back away from that, completely reverse

20:06that paradigm, put data first.

20:09On the device, the way local-first suggests, and don't even build a

20:13server if it doesn't make sense.

20:15But if it does make sense, be restrained in doing so.

20:18That's what I mean by zero server.

20:20And I think that's also a really interesting point about like

20:23health apps more, more broadly.

20:25I mean, a health app is typically I'm inserting some data about myself, or

20:30maybe with like a smart device that tracks my heart rate, et cetera.

20:35And there's probably not a good reason to have that data

20:40be synced to a remote server.

20:42Maybe I want to have it, maybe I have like a Apple watch and I have like an iPhone

20:47or on some other platforms, maybe those things should sync between each other.

20:52But that a third party is the kind of de facto source of truth

20:56where all of that data is stored.

20:58I think the only explanation for why that is the case is because it's

21:04been so much easier to build those sort of server centric applications.

21:09I think I might take issue with you in saying that's not the only reason.

21:12That might be the most convenient excuse, but I think the most salient

21:18reason is because there's much more money to be made if my data sits in

21:23their server versus on my device.

21:25And I think that's what's driven a lot of it, but I think you're right

21:27that We have absolutely created a technology landscape where the

21:33easy paved cow path is to do that.

21:36I agree with that.

21:37I think those are definitely two major points.

21:40but I think even if someone has more of like the, aspiration to build something

21:46in the interest of a user and is maybe not after turning this into a billion

21:52dollar monopoly, then it's still a lot harder to build a non server centric

21:58application, at least in the past.

22:00And I think slowly but surely that is starting to change with all of those

22:04amazing local-first technologies.

22:06But yeah, the example you've mentioned is certainly a very stark reminder

22:11that we have to do something there.

22:14So that's one of the pillars of Web 2.5 is We need to build a Web 2.5 where

22:21the paradigm is that we own our data and we own our identity so that we can

22:25control that data and say where it goes.

22:27Sometimes it's going to go to my devices, like I call it my local cloud or my local

22:32ring to borrow the term web ring from.

22:3430 years ago that I'm old enough to remember.

22:37Your local ring is all your devices.

22:39It's your watches and tablets and laptops and phones and all that.

22:42You definitely want to share data there.

22:44And that explains why I was interested in peer to peer technology, because that is

22:50where that is how that data should get.

22:52between my devices.

22:53By the way, I'll just, I'll make a plug.

22:55Aside from true networking based peer to peer, which is what Socket was

23:00trying to do, and what their protocol I think enables, whether you ever use

23:03Socket, I think they just have a great protocol that we could build upon

23:06that's relay based and self balancing.

23:08I think there's a lot of, really good stuff there that somebody

23:11should, should pick up and run with.

23:13But whether you use that or not, there is actually a working group in the web

23:17standards community that's trying to work on what's called local peer to peer.

23:21I'm very excited about this.

23:22they're trying to build an API into the web platform that will tunnel itself

23:27over a couple of different transports.

23:29One being the local Wi Fi that Apple and, Apple iOS and Google Android have.

23:35They're competing standards, but they're going to try to create

23:37a web API that papers over the difference between these standards.

23:41It uses your Wi Fi connections to connect between devices.

23:44Failing that, it can use Bluetooth or NFC or any other of these, like,

23:48local, localized transport layers to be able to communicate between devices.

23:53This would be, I think, one of the most important things the web

23:55could ever land if this happens.

23:57There is a working group on it.

23:59There's a kind of a spec already working its way processed through.

24:03I don't think we're going to have it in six months.

24:04There's going to take a little while, but I'm very excited that at

24:07least finally, there's some movement towards let's not lock down, the web.

24:12And by the way, one little side note, there's a whole bunch of

24:15stuff that the web platform should enable, but does not enable.

24:21Locks down or hobbles because we are, for some reason, and we, I mean, as a

24:28community, and especially the spec bodies, we are unwilling to admit that there is a

24:33fundamental paradigm difference between, I've visited a web page one or more

24:39times, There's that experience, which definitely we should be distrustful of.

24:45We should keep at arm's length.

24:46There's a difference between that experience and I've gone to a website

24:50a few times and I really like it.

24:51And I installed that onto my device.

24:55Once I've said, I am installing that onto my device.

24:59I am saying, just like with any other app that I install, please let it have all

25:04the capacity that I'm willing to give it.

25:06Pop it up and have it ask me, do I want to give it this, and this,

25:08and this, and let me say, yes, I want to give it those permissions.

25:12I don't understand why the web thinks of itself as a unified medium when it is used

25:19in these completely different paradigms.

25:21We need to be forking what we allow in the web platform, based upon

25:26that flag, has it been installed?

25:29Once it's been installed, I think that is very much implicitly the

25:32user saying, I trust this app.

25:34Let this app do what I want it to do.

25:36So things like local peer to peer, they don't make sense for a drive

25:41by website, and you should rightly be scared about a website being

25:44able to like talk to your watch.

25:46Like I get that, but if it's an app that's built with web technology that

25:50a user trusted enough to install, it should have this capability.

25:53So just a little, side rant there, but anyway, peer to peer

25:57communication, the local ring.

25:58We absolutely need to do that, but none of that needs servers.

26:02We can build this without servers.

26:04I love those points and I was not aware of this, standards work body,

26:08in working in favor of bringing more local peer to peer supports for the web.

26:14I think this is very, very much needed.

26:16Right now.

26:16I think the closest we got that also, makes that a little more focused on my

26:23devices is like I'm using tail scale to create sort of like a secure bridge

26:28between my devices, but that is still on an operating system level and not

26:32something that the web platform can easily, make use of to my knowledge.

26:38But the other point you've been making about the distinction between a website,

26:43which you might just open once or a few times, maybe for a webshop or for

26:48like some, news outlet that like just has everything littered with ads.

26:54And so surely you want to be much more careful about providing

26:58too many privileges to that.

27:00But if it's, let's say your mail app or other sort of apps

27:04you use on a daily basis, sure.

27:07You want to give that more access and possibly also in a way where, there

27:11is more of like a local AI context on your device, maybe even take a

27:16step further and provide a way how a native web app, like a native feeling

27:23app that lives in your web browser, maybe can even get access to that.

27:26I feel like we're making some steps towards that.

27:30so for example, for Overtone, the music app I'm working on, I've actually just

27:35over the course of the past couple of weeks, I've added support for

27:40file system mounting, which is not available across all browsers but,

27:44Chromium based browser supports this.

27:47I believe Oprah also supports this.

27:49I might be wrong on this one, but I've been primarily adding support for, because

27:54I'm using Chromium browsers myself.

27:56Are you talking about the OPFS?

27:58So there's two things.

28:00There is OPFS, which I'm already using as a persistence mechanism for pretty much

28:05everything for also for persisting my SQLite database and images, media assets.

28:11But there's also.

28:13a feature that has mostly the same API as OPFS, but instead of just

28:19creating a new file system, like a folder or files within the virtual file

28:25system, you can actually ask the user.

28:28to bring in an existing file or existing folder.

28:32So, in my case, I would allow the user to select their music directory

28:38from their local computer, or possibly even from a NAS device.

28:43And so this works both for sort of like the show file picker model, as

28:48well as for drag and dropping, an existing file or existing folder.

28:52So this already is a big step towards like a more native feeling experience in

28:58the web, but there's so many more aspects to this that we haven't covered yet.

29:04networking certainly being a big one, whether it's just TCP

29:07connections, UDP connections.

29:10One thing that I'm also somewhat hopeful of that this might bridge the boundaries

29:16a little bit is to rely on browser extensions to be sort of like a thing

29:22that you could trust more and that could facilitate that additional privileges

29:27for a given website or a given web app.

29:31That's something I'm thinking about whether I should maybe

29:33explore that for Overtone to give you more native like affordances.

29:38but yeah, that's maybe a topic for another episode.

29:41I've done some work in that.

29:42I actually built a web app and built a browser extension that I could use with

29:47that web app and extended the capabilities in like audio and visual sense.

29:52So I've done some work with that.

29:53There's a lot of challenges there, but I do think there's a lot of potential.

29:56and in particular, one of the things we'll talk about, I think a bit later

30:00in this episode, I very much intend to go down the route of building,

30:06Whether they be extensions or just side companion apps that do give extensions

Definition of Web 2.5

30:15I do just want to say, I only, have described so far one

30:20pillar of how I define Web 2.5.

30:22There are two more and I don't, they don't need quite as much time, but I

30:26do just want to state kind of for the record, what, how I define it, it's

30:30just a term I made up, people may not like it, but it's, it's how I define it.

30:35So the first pillar was we do need to build a web where data is ours, identity

30:40is ours, and we can choose where we share that data with our local ring of devices.

30:46We can choose if we want to share it out to cloud for other, you know, back,

30:50there are reasons why you want to be able to back things up or whatever.

30:54Point number two, I think this speaks actually to, a lot of the skepticism

30:59around local-first, which is there's no business justification for doing

31:05local-first, if it's harder, if it's more risky, if it's newer and weirder

31:09businesses won't do it, and if businesses won't do it, it doesn't matter.

31:13You can have all the great ideas in the world, but it won't matter.

31:16one of the things that I liked the most about my time at Socket Supply is

31:19they really confronted this head on.

31:21And they said, if we build a world where it is very compelling and

31:26straightforward for people to start building in peer to peer communications

31:31into their apps, we really start challenging the question of Why did

31:35you need the cloud in the first place?

31:37For most things, you didn't need the cloud except that you did not have a way

31:42for two clients to speak to each other.

31:44But if we get rid of that, then you stop needing to pay

31:48for most of your cloud bill.

31:50And that is one of the largest overheads that companies face these

31:54days, and they're increasing in cost.

31:57No matter what your provider is, whether they're more specific providers like

32:01Vercel or whether they're more broad providers like the AWS's and Azure's

32:05and Google's of the world, your bills are going up because you're doing

32:10more and more of your stuff there.

32:12And one of the reasons you're doing it is because it was technologically

32:14easy to do so and less risky.

32:17But the other reason you were doing so is because somebody hadn't given you

32:20a business reason to do the reverse.

32:23one of the great things about peer to peer designed systems is

32:27that the bigger the peer to peer network, the lower the costs go.

32:31That's the opposite of, systems that are centralized, the bigger the centralized

32:38system gets, the more expensive it gets.

32:39You don't get economies of scale and you know, you're driving down your AWS

32:43bill, it goes up the more you scale.

32:45But in peer to peer systems, you have this inverse relationship.

32:48So I think there's actually a really compelling business case.

32:52For why companies who are trying to figure out how do I cut down on my costs

32:57might be asking themselves, is there any way that I could offload any of my

33:00cloud bill to peer to peer communication?

33:03And even if I did just a little bit to start with and then realized, oh,

33:06that was great, and then I expand that.

33:08The more you expand that capability of your apps, you will create.

33:12More compelling user experiences than you will create in local-first.

33:16And that's important.

33:17But you'll also significantly reduce, and maybe in some cases, completely eliminate

33:22the footprint of your cloud overhead bill.

33:25So that's number two, that I think there is a really compelling business narrative

33:30to building a web where businesses Can more easily compete without almost

33:35the rent seeking, landlord seeking, Oh, we gave it to you for free when

33:39you were small, but now you're big and we're going to just charge you an arm

33:42and a leg, and you can't get out from underneath us, kind of thing like that.

33:46That's how drug dealers work.

33:47And that's just not a business model we ought to be building

33:50the web on, in my opinion.

33:51So we have to fix that.

33:53That's pillar number two.

33:55And then pillar number three.

33:56I maybe personally feel the strongest about, even more so

34:01than the ownership of data.

34:03I have been to many places in the world that it is a reality that you do

34:08not have Unlimited internet and even unlimited electricity to run your devices.

34:14I've been to, you know, rural towns in Africa where people hang their cell

34:18phones off the light pole in the middle of town to charge their phone all day.

34:23And it costs them a week's wages to do so.

34:25Like we take so many things for granted.

34:28The web should be.

34:30The largest human umbrella, the largest umbrella that mankind has ever

34:34made, that humankind has ever made.

34:36It should be that, and it should encompass, or be able to encompass, all

34:418 plus billion people on the planet.

34:43Right now it's serving, like, a third of the world.

34:46Two thirds of the world is not privileged enough to experience the same web

34:50that you and I get to experience.

34:52They don't have an always on internet connection like the way that we're

34:54recording this right now, right?

34:56They have spotty internet, or no internet at all, and it's metered, it costs a lot.

35:01and we are not building a web where they can participate, and, and where,

35:05and even if they can't participate, they can't participate as equals.

35:08They don't have the same footing.

35:10We should be, I think morally, if not for any other reason, building

35:15a web that they can participate.

35:16And I don't see any way I don't see any way that we extend the web to the last

35:22two thirds of the world's population.

35:25simply because some billionaire hangs a balloon up in the air to

35:28give them internet or whatever.

35:29Like, that's not the solution.

35:31That's how billionaires want to solve it.

35:32The way I want to solve it is from the ground up, by rebuilding the web

35:36in a way that says, once you get the information that you need, the data that

35:40you need, or create it, and once you have the application, you don't need the

35:45internet to keep doing what you're doing.

35:46You're a local fish farmer, you're working, you can upload the data into

35:50the thing, you can drive to market, synchronize with the market, and

35:53sell your goods, and you don't need a cloud server to do any of that.

35:56We should be building that world.

35:58So that's the third pillar of what I call Web 2.5 is building a web that actually

36:03works for all of humankind instead of only the privileged part of the world.

36:08I love those points.

36:09And I think this is where we can also now like close the loop nicely, since I think

36:14all of those points are really, really welcome and like really core of what

36:19the local-first movement is all about.

36:22And I think this is also what brought you under this local-first umbrella.

36:26I love the last two points that you've laid out.

36:28There is not just about the second point where you made about,

36:32the bigger a centralized system gets, the more expensive it gets.

36:36but I think it's also, if you think about the developers who

36:39are the creators who are building.

36:41Smaller apps that have an ambition, maybe similar to how I'm building Overtone.

36:46I actually, I want to charge for the, the value that the app is creating

36:51for the quality of the app, for like the differentiation of the app.

36:56I don't want to charge for, like someone's internet usage and the data is actually

37:03in my way there to make that happen.

37:06like data shouldn't be part of my equation for how I'm charging for something and to

37:13make matters even worse, maybe less so for a music app or, but for many other apps,

37:17for example, let's say someone wants to build another, like highly specialized

37:22and highly personalized health app.

37:24This is where it's not just maybe at some point expensive to move the data

37:28around, but it's actually data can be seen as a liability, particularly in

37:33a more highly regulated environment.

37:35And I think this is where encryption, which we'll get into shortly as well, I

37:41think is a very nice antidote to that.

37:44And then the last point you've made about, like that the web shouldn't just

37:49serve the highly privileged, fraction of the world population, I think that's

37:54also very core to local-first and maybe another meaning to local-first as well.

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

38:05context, but I think it's also that an app should maybe be more.

38:10Locally created in the context that you're working.

38:13We've explored that in the conversation I had with Maggie Appleton a while ago.

38:19And I think this is really what's driving her motivation around local-first.

38:23That de facto right now, most apps that are out there are being built by like

38:30a very small group of people living in Silicon Valley, living in New York, a

38:36few hub, like hubs within the world.

38:39but that's actually not where most of the people are that are using the apps.

38:44If we address many of the underlying challenges that we want to solve with

38:49local-first, I think this can also empower and enable so many more local

38:55creators to build much more specialized and custom apps for specific local

39:01parts of, different parts in the world.

39:04So I just want to offer that as an extension to the last point you made.

39:09Yeah, 100%.

39:10I love that.

39:10You know, a good way of saying that is that it's built by the privileged

39:14for the privileged, but why not let everybody build what, you know, I'm

39:18never going to be able to understand what that fish farmer needs, but if we

39:21can empower him to build the thing that he needs, he'll understand it better.

39:24And he would be in a much better position to build an experience that works for him.

39:29We need to create the pieces of that puzzle for other people to assemble

39:34rather than assuming I'm not going to build all the world's apps.

39:37I know that I'm hopefully going to build a couple of Lego pieces that

39:40will be useful in many of those apps.

Identity

39:43Awesome.

39:43So let's shift gears a little bit and get a little bit more technical since

39:47one ingredient we'll need to make all of this happen is not just moving data

39:52around, which we've explored in many other conversations on this podcast so far.

39:57But one particular aspect of that is also that like, not just two random

40:02devices are exchanging data in a completely trustless way, but a device

40:07might also be owned by a person who has a particular identity or might even

40:13on that given device have maybe there might be multiple identities at play.

40:18And so how do you retain an identity?

40:20How do you, kind of exchange identity information, that your, I love the way

40:27how you put it, like your device ring, how all of those devices can trust each

40:31other, how all of that is made work, how, and I think there's this typical

40:35tension in security where if you want to make it secure, that often comes at

40:40the cost of convenience and vice versa.

40:43And that's sort of.

40:44Sweet middle ground where it's both convenient and secure.

40:47I think that's also very tricky.

40:49So this is an area that you've really deeply explored and you've built a

40:54whole bunch of different projects.

40:56I think one of them is being the Lofi.ID, project.

41:00You also have another project on GitHub called Local Vault.

41:03So maybe you want to give us an introduction to what you've been

41:07working on there, and then we can take it one step at a time.

41:11Yeah, so big picture overview.

41:13is that if you are going to own data on your device, and that's going to be

41:19the source of authority for that data, which is the premise for local-first,

41:24then I believe that you both need to be able to secure that data, meaning

41:29securing it at rest, which involves encryption, and you're going to be

41:33able to need to Securely ensure that data goes only where you want it to go.

41:39Plain text data being sent around and backed up in other places,

41:43that's not going to cut it.

41:44So we are going to need encryption to be part of this equation.

41:49And To boil a lot of real complicated technology down to hopefully

41:54something that just about anybody can understand, we have this who's

41:58protecting the master key problem.

42:02No matter what encryption scheme you design, whether it's password based,

42:06where you derive an encryption key from something that I type in, or whether

42:11it's I've generated a key and I'm going to Randomly, and that is your encryption

42:15key, no matter which mechanism, or there's a bunch of other variations thereof,

42:19but no matter which mechanism you have, you have this kind of encryption upon

42:24encryption upon encryption, but at the very top of that chain, you have the

42:27master key, the master password, whatever.

42:30And how do you protect that?

42:32That's the common problem.

42:33And in fact, going all the way back to the work that I did at Hero,

42:37the Web3 company that I worked at, they had a very similar problem.

42:41They were trying to create smart contracts around the Bitcoin chain with

42:45the separate blockchain, and they needed the ability to, you know, to round trip

42:50transactions in a completely trustless way between one blockchain and the Bitcoin

42:56blockchain, between Stacks and Bitcoin.

42:57And they have this exact same problem, which is who's going

43:00to hold the master keys?

43:01And how are you going to do that in the open, but not

43:03let everybody have it, right?

43:04So we always run into this problem of It all sounds well and great until we get

43:10to the final piece of the puzzle, which is how do you handle the master password?

43:13I've been banging my head on this for years, trying to figure

43:16out there's got to be some way.

43:18And the advent of biometric passkeys was when the lightbulb went off for me.

43:23Because What Passkeys do and what the biometric subsystems on these

43:28devices do is they offer a, I think, compelling answer to that question,

43:34which is there is no perfect storage for the most secure root, master,

43:41passkey, whatever you call it.

43:43There's no perfect solution, but the best that we can get is dedicated

43:47hardware on the device that is not Just free and open to any app, right?

43:53If we can have a dedicated hardware for this purpose, the secure enclave or

43:58whatever it's called, and then we can have operating systems that are designed

44:01to very strong, strictly control access to that, and it's designed in like a

44:06write only way, you cannot read from it.

44:08You can write to it once, and then you can never read from it.

44:11You can send data in and get results back out, but you can never ask that

44:15thing to give you its private key.

44:17That really offers, I think, the most compelling answer we've had so far

44:21to where do we store the master key?

44:24But one of the big problems with that, it's not in and of itself a solution

44:28to this, to this question is because.

44:32I don't have access to that key.

44:34That means I can't use that key for encryption purposes myself.

44:40I can create a passkey with my thumbprint or my face or whatever, but I can't

44:45get access to that key material to use it for my own encryption purposes.

44:49And I couldn't figure out how we were going Make passkeys work in a zero

44:54server assumption where there's no servers and in a way that I could

44:58piggyback upon it to create encryption.

45:01And then it occurred to me that we can actually bury the key material in the

45:06passkey by way of the user ID field, or there's actually another mechanism

45:11that is coming along that I think will be even better than the user ID.

45:14But the main point is, we can actually piggyback on top of these passkeys.

45:18And in this secure part of the device, store something in a way

45:22that I think is maybe 99 percent guaranteeable, that's a lot better

45:27than almost 0 percent guaranteeable with anything that's in userland apps.

45:31Is it perfect?

45:32No.

45:33But it's absolutely a, you know, a paradigm step up in terms of security.

45:39And so the whole rest of everything that I'm building is based on that

45:43one assumption, which is where we're going to solve the master passkey

45:46problem is by basing this on passkeys.

45:50That does have some questions that it raises.

45:54How are we going to onboard apps?

45:57on devices that do not already have biometric capabilities.

46:01They don't have these secure hardware.

46:04I think the good news is that more and more devices are getting that.

46:07And I think that will continue.

46:08I don't think we will see a, you know, a pullback in that.

46:12I think we will see more and more devices getting those capabilities.

46:15So over time that becomes less and less of a problem, but we do need

46:19an exit ramp for not just telling somebody, sorry, you're out of luck.

46:24So I've been working on some ideas around creating kind of a secondary

46:29way of doing things that's not biometrics based, pattern drawing

46:33that's more complicated and can create more entropy, things like that.

46:37So I think we do need some exit ramps there, but I'm going to make

46:39the assumption that for the primary class of devices that we want to

46:44target here, we have the biometrics.

46:47Once we have that, once we have that capability.

46:49We needed a way to be able to manage pass keys without relying upon servers.

46:54So the first library that I wrote was WebAuthn Local Client, which was

46:59designed to wrap around the web API that exposes the passkey subsystem,

47:04but doesn't make any assumptions about communicating with the server.

47:07the use cases in local-first don't need what the server would do anyway, so that's

47:13not a problem, but it's just no other libraries out there that I had found where

47:17it could work if you didn't have a server.

47:19So I wrote a library that exposed that API in a way that made the

47:23assumption you weren't going to communicate with the server.

47:26You were going to store things securely.

47:28You were going to generate the challenges on device.

47:31You were going to keep track of the key and verify that was coming

47:35out was not man in the middle.

47:36You were going to do all of that.

47:37on device, not on server.

47:40So that's what WebAuthn local client was.

47:41That was the first little piece of the puzzle.

47:45Then I said, okay, well now we need a way to, piggyback on top of the passkey

47:51system and create something that we can use for encryption purposes so that we can

47:55protect data both at rest and in transit.

47:58we need some keys.

47:59And I did a lot of research in this.

48:01I'm not an expert.

48:02I'm not a mathematician.

48:04But I settled on, this was back when I was working at Socket, I settled on, Elliptic

48:09Curve keys, specifically the Edwards key, the ED25519 key pair as the best

48:17master key pair because you can generate, that can be used for signing, and you

48:21can generate a sub key pair from that.

48:23That's the Curve 25519 keys for encryption and decryption.

48:28I settled on that as the best, but that's not the only way of doing it.

48:31And certainly anybody else could substitute their own encryption,

48:34or maybe we're going to need to upgrade that encryption in a post

48:38quantum world in some few years.

48:40But, that's where I landed was, let's use that, because I think

48:43that's good enough and strong enough.

48:45And I found the Libsodium library, which is big and complex, but it's,

48:49I been ported to tons of platforms and that was important to me.

48:53And so I based the ideas around securing our data on that type of key pair.

48:59So we generate a 25519 key pair.

49:03We take the seed of that, or in my library, I call it an IV, but IV

49:07or seed, we take the seed of that.

49:09And that's what we store in the passkey.

49:11And with that information coming back out, each time you put your thumbprint

49:14or your face ID in, you can reconstitute that key pair and then decrypt

49:19whatever data was previously encrypted.

49:21That is how we fix that master password problem.

49:26So I built a library to help you do that and that's called local datalock is the

49:30library that wraps around the WebAuthn local client, but then it does the

49:35generated encryption key, stick the seed into the passkey, it does all that stuff.

49:41it does not do anything about storage of it.

49:43Right?

49:44So you might use local data lock when all you care about was transmitting

49:47secure data, but it does provide the pieces for the next one.

49:52The next one was we need to figure out how we're going to store that data in

49:58an encrypted fashion on the device.

50:01And then, so it's encrypted on write and decrypted on read.

50:05How are we going to do that?

50:06Well, I actually realized I need two pieces, not only one to manage

50:09the encryption piece, but actually I needed a library to manage the

50:12storage piece, because there's a lot of different variations of

50:15storage, as we were just talking about with OPFS and things like that.

50:19So I built the Two libraries to help with this piece.

50:22One library is, I've spun out actually, it's not even local-first really, it's its

50:28own thing, which is just abstracting local client storage in a key value way across

50:35all the five major storage mechanisms.

50:37So cookies, local storage, session storage, indexDB, and OPFS.

50:42And technically under OPFS, there's two different ways of managing it.

50:45One is more device limited, but it's the in thread communication

50:51that you can do, asynchronously.

50:53But the more broader device support, basically all devices at this

50:58point, or all modern devices at this point, is OPFS in a worker.

51:02and if you do OPFs in a worker, which you're nodding because you've seen

51:06the same problem, but managing workers and all of that stuff is difficult.

51:09So that's what this library does, is it abstracts across all of those mechanisms

51:13the exact same asynchronous key value API.

51:17And that library is called Storage.

51:19It's part of my BYOJS Bring Your Own JavaScript initiative.

51:23so we'll have a link to that.

51:24But that storage library, even if you didn't do anything local-first,

51:28you just wanted to store data, I think that would be useful to help.

51:31Think of it as kind of a more modern Local Forage, maybe.

51:34Local forage has been around for a decade, but it's not really maintained anymore,

51:38and it didn't support all the mechanisms.

51:41I think storage is a compelling option to look at if you're sticking

51:47anything on a local device, even in local storage, maybe have a better

51:50API and a more secure API for that.

51:53So first of all, storage there, that has nothing to do with encryption.

51:55It's just The raw reading and writing from a disk.

52:00And then the last piece of the puzzle, the one you mentioned before, is the

52:03local data vault . So that library is what takes storage, WebAuthn, local data

52:08lock, and all those pieces together, and gives you that local vault, which

52:15is a secure, encryption secured, based on passkeys, encrypt on write, Decrypt

52:20on read key value storage mechanism.

52:23And you can, of course, choose which of those places you want to store, like

52:27store it in IndexedDB or store it in OPFS.

52:29But it does all the encryption and decryption stuff for you

52:33based on the passkey subsystem.

52:35So that's what I've built so far.

52:38Where all of that is going is towards, there's two ways

52:43that I see this happening.

52:44First of all, I think apps can start to use, web apps can start to use those

52:49libraries, whatever pieces of that makes sense to you, use all of it, use part of

52:54it, but start to use those pieces to do some of this stuff yourself in your own

52:58apps, build your own solution if you want.

53:01I also think that we need to lower the barrier for apps

53:04to do a lot of this stuff.

53:05And I also think that the more consolidated of approach we get,

53:09the better chance we have of something like this catching on.

53:12And so instead of just writing like a standards doc and saying, if you do

53:17it, you have, you must do it this way.

53:19the approach I'm going to take is to build a companion Wallet app that allows

53:24you to manage as a user, any number of your own identities, Protected, of

53:29course, through this passkey subsystem.

53:32And apps will have an SDK that they can interact with the Wallet app,

53:37whether that Wallet app is a browser extension, like we mentioned a little

53:40while ago, or whether it's a literal actual side, you know, companion app.

53:44They'll be able to interact with that app to ask that app,

53:48Hey, tell me who this user is.

53:51Tell me that it's the same user as they were before.

53:53That's one question.

53:55So instead of them needing to build their own authentication, they'll

53:57simply make a call to this Wallet and say, verify for me that this user is

54:01who they say they are and give me back their identifier, which might be their

54:05key or some other UUID that you specify.

54:08That's one question.

54:09But also I think those apps shouldn't need to roll their own encrypt all of my data

54:15and decrypt it all and all of that stuff.

54:17So they'll also be able to provide the data to the Wallet app and ask

54:22it to encrypt it for them through that SDK and decrypt it for them.

54:26And again, based all of that around passkey.

54:28So they don't need to invent any of that stuff.

54:30The Wallet app will just take care of it for them.

54:33And then the last piece of the puzzle is.

54:35if you build an app, let's say like it's a, you know, it's a note taking

54:39app, or it's a social media app, or whatever, and it does need to

54:41communicate with other devices, instead of you doing your own synchronization

54:46logic, I think we can actually have the Wallet app built with peer to peer

54:50capabilities so that my Wallet app on my phone and my Wallet app on my laptop

54:55and on my tablet can synchronize my identities, but can also synchronize

54:58userland app data through the Wallet.

55:01Use the Wallet as a tunnel to do synchronization.

55:04when I say synchronization, I do not mean that I'm solving anything that what,

55:10what the larger local-first community says when they say synchronization

55:13with all the CRDTs and all the merging and stuff that I want to

55:17leave open to this community to solve.

55:19You can plug in whatever.

55:21CRDT systems you think make sense and whatever strategies you make sense.

55:25I'm simply going to provide the transport layer through peer to peer various peer

55:29to peer technologies in this Wallet app so that those bits can get from my phone

55:34to my watch, to my laptop, to my tablet.

55:37And then you'll, your app will decide what do we do with that?

55:40In your own app logic, you'll decide how do we merge these competing

55:44sets of bits that are coming in.

55:46I just don't want for people to have to go invent all of their own wheels there.

55:49And I think a single unified Wallet app will allow people to do that.

55:54there's other things that I want that Wallet app to do, but that's kind

55:57of the main, starting point, the 1.

55:590 that I want this Wallet app to do is to give that to the

56:02local-first community and say, please consider building upon that Lego.

56:07Perfect.

56:07So this was a lot and, kudos to you for doing such comprehensive research,

56:14deliberating the different options.

56:16There's always like so many different paths that you could go in regards

56:20to like all of the different decryption encryption mechanisms, like

56:25choosing, should you use Libsodium?

56:27Should you use WebCrypto?

56:29Should you use other things, for what it's worth for Overtone?

56:32I've also landed on using Libsodium, which, I needed to even

56:36compile my own WASM version to trim it down a little bit more.

56:40but, yeah, so you've covered a lot of ground there and I have

56:44a few follow up questions where I would love to learn more.

56:48also one observation that I just, as someone who appreciates like

56:53good terminologies and clear concepts, I just love the term Vault.

56:58As something that, both signals like, Hey, this is something where it can put stuff

57:02in and get stuff out and it is secure.

57:05So a vault being sort of that combination of your storage mechanism and that

57:11search mechanism has nothing to do with encryption at that point, but if

57:14you then combine it with encryption and decryption, that makes a vault.

57:19I think that's a very intuitive concept that is, that works both as a concept for

57:24developers, as well as even for end users.

57:28like I think this is what also 1Password, for example, has started to use.

57:33And I think, 1Password users are familiar with that also, I'm sure

57:37for other password managers as well.

57:40And so that as a concept, I hope that it's not just a.

57:44a concept that is used within the local vault and like the stack that

57:49you're exploring here but hopefully that's something that as a term,

57:53can be useful for others as well.

57:56Yeah, I agree.

57:57I think it does communicate what it needs to.

57:59I workshopped that with some of my social media community, by the way.

58:03I had lots of different suggestions and I, you know, kind of pieced together

58:06various things, but I workshopped some of the naming of this, you know,

58:10crowdsourced it because I wanted to make sure I got a name that really

58:13communicated properly, what I was up to.

58:16So to me, it sounds like you've landed on a great option here and I might

58:20actually steal that for myself and, the ways how I'm like in my own data

58:25stack, where I have a database right now, it's not encrypted address,

58:28but I want to encrypt it more.

58:30And so maybe I can also use for the SQLite database there.

58:35Maybe I can also start calling that a vault if it's encrypted.

58:38I like that a lot.

58:39and I also like how you've already thought a step further.

58:43it's not just as that, like as a tech stack that can be implemented by a

58:48given apps or high level libraries, but also from a user perspective, if

58:53you're not just going to use one app, the kind of part of the entire promise

58:57here is that, like here you have data in one app and data in another app.

59:02That, and maybe those apps want to work together and that is actually

59:06something that is like really, really difficult in today's web2 world.

59:12Where like, just think about like how much of an effort it is.

59:15That's maybe the best we got.

59:16Maybe it's like a Slack, integration that like Slack is like a little bit more

59:22aware of like what that Figma link means.

59:26And, I can open it all in my browser.

59:29So from my perspective, it kind of feels like, Oh my gosh, why

59:31don't you have that context?

59:33So if we, embrace a little bit more of the user.

59:37The identity concepts, and then also let, that dictate a little bit of the share,

59:43the context sharing and access control.

59:45I think that can lead to much better user experiences.

59:49there've been many, many years of attempts to create in the mobile space.

59:54there was like web intents and then web share and share intents and like

59:58all these other variations and it went through various different names and

1:00:03standards processes stumbled with it.

1:00:05I don't even know where that currently stands, but that's exactly where I'm

1:00:08headed is basically, let's just get around any of those limitations and allow, for

1:00:13example, a use case where, you know, I might be in a local-first note taking app,

1:00:18and I might have written a note and I want to, you know, copy a piece of that note,

1:00:22and I want to send that out to one of my text messaging recipients or one of my

1:00:26chat recipients or whatever, so I can take that note and I can synchronize, I can

1:00:31share that information to this other app in a fully secure, end to end secured way.

1:00:36But it ends up in my other app, and that other app pops up, and there it is,

1:00:40in the exact same way that, you know, you can currently do sharing intents.

1:00:45Native apps have that, but the web has always been, you know, a third class

1:00:50citizen at best in that sort of cross app collaboration and in sharing story.

1:00:57And I think we can make it a fully first class story this way.

1:01:01And I think that also takes us in possibly even a step further that

1:01:05goes beyond today's conversation.

1:01:07so far we talked about identity and also a part of that identity is

1:01:12like authenticating as assuming that identity or being denied that identity.

1:01:17that's often abbreviated as Auth, but Auth can also mean another non abbreviated

1:01:24word, which is authorization, which I think this is not yet covering that,

1:01:29but there, I want to plug another very interesting project that is more around

1:01:34authorization, which is called Beehive.

1:01:37that's also been published on the Ink and Switch website.

1:01:41and there's currently, I think, not yet a full.

1:01:44Inc & Switch style essay about that, but there are some notes being taken on this.

1:01:50And so this is a project that, Brooklyn Zelenka and Alex Good is currently

1:01:54working on that is, also ongoing research in combination with AutoMerge.

1:02:00And Brooklyn has been exploring a lot of that, as her previous work On vision

1:02:05and related projects, so, and this is where, the authorization concepts to my

1:02:10understanding is sort of based around the ideas of capabilities and, that

1:02:17different users can basically, share capabilities, and privileges basically

1:02:22up to a level that they have themselves, whether it's read or write and so on.

1:02:27So I'm sure this is like an equally deep and challenging topic and, but they

1:02:32feel a little bit, complementary to me.

1:02:35So hopefully there's like some convergence here as all of

1:02:39those are like very deep topics.

1:02:41I did see that Beehive announcement just recently.

1:02:44I think that's great.

1:02:45I think we need a lot of different flowers blooming in this field to figure

1:02:49out and find the places where there's going to be overlap and collaboration.

1:02:53By the way, just as a little bit of a side note, I literally just yesterday.

1:02:57learned something that maybe everybody else listening has already known

1:03:00and I didn't know, but just for the benefit of the audience, the word

1:03:04auth is you, A U T H as you correctly point out, is a little too ambiguous.

1:03:08It's a little too shortened because we don't know, do you mean

1:03:11authentication or authorization

1:03:13but I saw somebody do auth Z for authorization versus

1:03:17auth n for authentication.

1:03:19So if we just add on that one extra letter to that shortened word auth,

1:03:23n or auth z then we know maybe better what we're talking about.

1:03:28So I learned that yesterday and I'm going to use that going forward.

1:03:32Amazing.

1:03:32I was not aware of that, what that little letter N in that context meant.

1:03:38there's also what you've mentioned, web auth N.

1:03:41Maybe that is what it's already using.

1:03:45Perfect.

1:03:45Well, today I learned, thank you for sharing that little learning.

1:03:49and kudos to everyone who was already aware of that.

Passkeys

1:03:53So I have not personally used passkeys yet as part of the applications

1:03:58I'm working on, but I am using applications that use passkeys.

1:04:03I'm like more and more like.

1:04:04One web service after another is like rolling out support

1:04:07for it, and I currently manage pass keys as part of 1Password.

1:04:12I'm giving 1Password the benefit of a doubt that they do manage

1:04:16all of that securely for me.

1:04:17maybe there's like at some point 1Password armageddon but hopefully not.

1:04:22knock on wood but, Using web keys for your own web applications or applications

1:04:28more generally, can you help me through, understanding that what that entails?

1:04:33Like, what are the boundaries of that?

1:04:34For example, if my, either one password manages my pass keys, or

1:04:40if my operating managers pass keys, what does that mean in terms of re

1:04:46authenticating on another device.

1:04:47So let's say I'm like, you've built this amazing note taking app.

1:04:52I'm starting to use it on my desktop computer.

1:04:56I have like gone through like some sort of initial setup process.

1:05:00I needed to like scan my finger.

1:05:02So the passkey was created.

1:05:04And now let's say on my tablet, I want to also work on the same notes.

1:05:10How does the setup process there look like?

1:05:12Do I use, for example, as I'm in the Apple ecosystem, do I trust

1:05:16Apple to synchronize pass keys?

1:05:19Is there like a more manual pairing step that I need to do?

1:05:22Similar to how, like in, WhatsApp, for example, there's the QR code scanning.

1:05:28What are the, are there different ways, how to do that?

1:05:30Is that just taken care of?

1:05:32Can you help me understand that?

1:05:34Yeah, absolutely.

1:05:35So, we need to be very clear that there's the standard way that almost all web

1:05:41apps, basically, practically all of them, are currently doing it, which

1:05:45involves a server, and then we need to distinguish that from what I'm proposing

1:05:49as is the future for local-first, which is servers become optional, and in

1:05:55many cases, don't exsist at all, right?

1:05:57That's the zero server world that I was pitching.

1:06:00So the way that things currently work and the way almost all web apps, you

1:06:04know, my bank uses biometrics, so let's just use them as an example.

1:06:08Right.

1:06:09So what my bank obviously has is a source of authority record about who I am, and

1:06:15they want to make sure that I'm the only one, no matter what device I come in from,

1:06:18I'm the only one who can access their source of authority for my banking info.

1:06:23the way that they do that is they have multiple authentication mechanisms

1:06:28attached to my account in their server.

1:06:31They have a username and password, of course, because you're going to

1:06:34have to access this from devices where that's the only option.

1:06:38But they also have Other records in, associated with my account that are the

1:06:44pass keys that I have registered when I was already authenticated with the

1:06:49bank account through some other means, including potentially another pass key.

1:06:53Anytime they have an inbound, here's a new pass key.

1:06:56They just associate that with my account as well.

1:06:59So I have like two or three different devices where I have pass key

1:07:02authenticated with my bank and their, I don't know their database structure,

1:07:06but a, Ostensibly, they have like a one to many relationship from my user

1:07:09account to all the various different ways that they know that it's me, right?

1:07:14So any inbound passkey that looks like this, it belongs to

1:07:19Kyle, show him his bank account.

1:07:21So the way that process works is that on the server, in a place that they fully

1:07:24control, as opposed to in the web or a client that they may not control, on the

1:07:29server, they generate a random challenge, which is just a random set of numbers.

1:07:34They sent that up to the device where the passkey is going to be presented.

1:07:39And that challenge is sent into.

1:07:42The device, and it is encryptically, it is digitally signed, doing

1:07:48a digital signature, which is different from encryption.

1:07:51They create a digital signature using the internal private key of your

1:07:56passkey that nobody has access to.

1:07:58It's stuck in the secure hardware.

1:08:00Nobody can get at it, right?

1:08:02They send that signature back out, and they send that signature along with

1:08:06the public key that you've already got.

1:08:08That's what you've stored, is you've stored the public key already.

1:08:11But they send that signature back to the server, and the server checks to make sure

1:08:15that it was able to create a signature that matches the public key that they

1:08:19already know is your passkey, right?

1:08:22So that's how they know that it was the same you on whichever device is if

1:08:27you were able to successfully sign the challenge and send it back to the server.

1:08:31What many of these services do is have that one to many relationship

1:08:38where you could have as many of these biometric keys as you want.

1:08:41Some of them are a little bit more naive or ignorant where they just

1:08:45literally have one, but the, Important thing from their perspective is

1:08:51that they have an identifier that they know is me, that my bank has

1:08:56an identifier that they know is me.

1:08:58I don't know what that is, but they have an identifier they know is me.

1:09:01And they either are going to stick that in the passkey, So that when

1:09:04that passkey comes back in, that they know it was me, or they're going to

1:09:08manually store that public key or both, but they're going to be able to

1:09:12match those things up and say, this challenge came from a device that Kyle

1:09:17owns and has previously told us is him.

1:09:22So we're going to let him have access to his bank.

1:09:24That's basically how passkeys work.

1:09:26Currently work.

1:09:27I've glossed over some details, but it's basically how passkeys currently work.

1:09:30And so you notice that the server is playing an important role here because

1:09:35the server ostensibly can't be compromised to generate a fake or replayed challenge.

1:09:43The server keeps track of every challenge that it's ever sent out, and it never

1:09:46sends out the same challenge twice, and all of these others, like, secure things.

1:09:51And also, the server, because it's going to be what's called FIDO2 compliant,

1:09:56this really complex specification, that basically does a, traversal of the public

1:10:03key certificates for the relying party to verify that it is in fact, I mean, for

1:10:09the authenticator to verify that it is in fact a valid authenticator and not some

1:10:14made up, you know, faked one or whatever.

1:10:16So FIDO2 servers do all of that complex stuff.

1:10:19some apps, I would imagine probably banks They really, really care about

1:10:23this stuff and they probably implement all of that complexity in the backend.

1:10:27I would wager to say that most apps do not verify the authenticity.

1:10:34They simply rely on, if you sent me a matching signature, I'm good with it.

1:10:39Even if it was a man in the middle, I don't care, whatever.

1:10:42A bank definitely cares if I've had a device that's been compromised and

1:10:46there's a man in the middle, that's, you know, taken over my authenticator.

1:10:49So they are probably going to keep running up the flagpole of the public

1:10:53key certificates, you know, all the way up to the root certificate or something.

1:10:57They're probably going to do that, but most apps are not.

1:11:00But that's why you have a FIDO2 servers, because you do not want

1:11:03to do that complexity yourself, and you definitely don't want to

1:11:06try to do that in the browser.

1:11:07Now, we move to this other way of thinking, which is that there is

1:11:12no central, decision of who I am.

1:11:16There's no like central source of authority for who I am.

1:11:19Who I am is just simply that I have chosen to collect a bunch of

1:11:23me's together into one identity.

1:11:26One me on my phone, one me on my laptop, one me on my tablet.

1:11:30That's me in an identity sense, right?

1:11:33It's not me in a humanness sense, but it is me in a digital identity sense.

1:11:37And, that's what the bank has done.

1:11:39You know, they've verified my humanness by make, you know, I

1:11:42couldn't open an account without a driver's license and other things.

1:11:45We're not dealing with that part of authentic, you know, of identity right

1:11:49now, we're just simply talking about digital identity is a collection of

1:11:53essentially these key pairs that I have said, these three key pairs constitute

1:11:59me across my different devices.

1:12:00When we start talking about how do I synchronize my passkeys, in that

1:12:05scenario I was describing before, you created a different passkey on each

1:12:09device, and that bank kept track of each of those different passkeys.

1:12:13But you notice that I said some, don't let you do multiple pass keys.

1:12:17They only let you do one.

1:12:19And that is why Google and Apple allow you now to both of them now

1:12:24support this Google just recently, but they now allow you to synchronize

1:12:28your pass keys between your devices, using your Google or Apple accounts.

1:12:32So I could literally have the same, you know, passkey on

1:12:37my phone and on my laptop.

1:12:39But something really important to note is, it's not actually the same

1:12:43passkey, because the device is still generating the secure key pair.

1:12:49What they synchronized was not the actual secure enclave key pair,

1:12:54because that's not even possible.

1:12:56The hardware is holding on to the key pair.

1:12:58What they're synchronizing is just the metadata in that user ID field and the

1:13:02user handle and all that other stuff.

1:13:04That's what's being synchronized so that that matches up.

1:13:07So my same ID shows up in Two different passkeys, but it looks

1:13:12to the bank as if it's one passkey.

1:13:17That's basically what that synchronization is happening.

1:13:21So.

1:13:22Rightly or wrongly, but I think rightly, people have complained that passkeys

1:13:27are definitely more user complex.

1:13:29People have to think about like, you know, all of this synchronization

1:13:32stuff, which is why nobody does that anymore with their usernames, passwords.

1:13:36Almost everybody's using a password manager.

1:13:39And it's why I'm arguing that since the world is using password managers, we

1:13:43can just have essentially a password manager that I'm going to call a Wallet

1:13:47that does the same stuff for you.

1:13:49You don't want to worry about, Synchronizing between

1:13:53all your different devices.

1:13:54That's crazy, right?

1:13:55So back to the local-first world.

1:13:58Since I'm simply saying that I'm going to create these identities on

1:14:03my different devices, and I'm going to kind of group them together,

1:14:06I'm going to decide when they sync.

1:14:08the Wallet can actually synchronize those key pairs between devices.

1:14:13So you could literally say, I want the exact same key pair on all of my devices.

1:14:18And then the way that you're authorizing, the way that a device is knowing that

1:14:22it's okay, we basically just flatten it out to, if you're able to decrypt

1:14:26the data, then you have the identity.

1:14:28And if you're not able to decrypt the data, then you don't have the identity.

1:14:31We've just basically simplified the whole thing.

1:14:34Now, I recognize that there are trade offs here.

1:14:36We don't have quite as strong of an assertion as we do in the bank account

1:14:41centralized server world, but I'm going to actually argue, not even on this

1:14:46podcast, but just as my continuing work, I'm going to argue that it's

1:14:51better for us to move in this direction.

1:14:53It's better for us to not have banks getting to have

1:14:56the say so about who we are.

1:14:58It's better for us to get to say that.

1:15:00So I'm going to argue that those trade offs.

1:15:02are actually an improvement, not a downside, but there are trade

1:15:06offs where we don't have quite the same level of central authority

1:15:10guaranteeing as somebody's humanness.

1:15:13So I appreciate you giving me a very deep introduction and beyond

1:15:18an introduction, quite the lecture in a positive sense on refreshing

1:15:23my own knowledge and understanding on like some cryptography aspects

1:15:27and how those things work together.

1:15:30And I think there is an interesting evolution that will probably, is

1:15:34already happening and will just continue to happen, where security

1:15:38is really, really difficult.

1:15:39Like, like you said, like a bank needs to go all the way, and there's like

1:15:43many pieces of our technology there that we're using, like a browser itself

1:15:48probably being one of them, where it needs to go really great extents to

1:15:53make everything as secure as possible.

1:15:55And while still trying to make us things as simple and easy for both

1:16:01users and developers as possible.

1:16:03And there's like this really interesting middle ground and where there's still

1:16:08this tension of like, okay, sure you can make it a tad easier for users.

1:16:12And that might come at the expense of security.

1:16:15But that boundary is also like shifting slightly.

1:16:18And I would say passkeys have actually been, both a step forward

1:16:22in terms of security for users.

1:16:24And also, things are moving in a direction where they also

1:16:27actually become easier for users.

1:16:30I think, yeah, I think we've got some growing pains where right

1:16:33now, at the immediate as we're having this conversation, it

1:16:36does feel harder to most people.

1:16:39But I think we, We have made a paradigm shift where we will absolutely

1:16:44achieve what you're talking about.

1:16:45Because If you just take a step back and you think about all the complexity that

1:16:50is currently around the username and password standard for authentication,

1:16:55which requires people to like pick new passwords for all their device, all their

1:17:00accounts, but nobody, most people don't.

1:17:02And then all the different requirements, like this site requires capital

1:17:06letters and this one requires numbers.

1:17:07And most people don't even manage that.

1:17:09Now they just let a password manager do it.

1:17:11And then all the complexity around what happens when my password gets known.

1:17:16And I did share it.

1:17:17And now that can be used, like all of that stuff completely goes away.

1:17:21And in replacement is my thumbprint or my face.

1:17:26Now I understand that getting to that point is definitely a bit

1:17:30of an uphill climb that we're getting closer to the top of.

1:17:33But once we are there, I cannot imagine that any user, even a completely non

1:17:38technical user is going to be like, wait a minute, I don't understand this thumbprint

1:17:42thing, but I was totally cool with all of these emails and password requirements

1:17:46and capital letters and all that stuff.

1:17:48Like nobody is going to say that eventually, eventually they are going

1:17:51to say pass keys are so much faster.

1:17:54So much more streamlined, so much more user experience optimized, but we are

1:17:58still in the process of getting there.

1:18:00And I know why people bristle at that claim right now today, there's

1:18:05rough edges now, it's getting better.

1:18:08And I think there is a second Category of those sort of uncanny valley symptoms,

1:18:14similar to how, like when web 2.

1:18:160 just started to become a thing and people started to figure out how do I

1:18:19do authentication, in the like web 2.

1:18:230 world.

1:18:24where, like, I remember the first PHP thing that I've built where

1:18:28I needed to authenticate users.

1:18:30I used good old, like, MD5 as, like, the password hash.

1:18:33Well, that very first system, I did not hash at all, and then I used a

1:18:37much more secure thing, MD5, and then I learned about Rainbow Tables, etc.

1:18:42And eventually, there's, like, things like Auth0, etc., and, like, single

1:18:47sign on, which took away quite a lot of that responsibility and that pain.

1:18:51But now as we're shifting to local-first, we're reopening then

1:18:56all of those cans of worms again with new security technologies, such as.

1:19:01Pass keys, et cetera.

1:19:02Things have moved on.

1:19:04now there are quantum computers possibly.

1:19:06So we need to rethink how we even encrypt things.

1:19:09so it's a moving target.

1:19:11And I think right now there's probably also the complexity an average app

1:19:15developer needs to think about in regards to, making their app secure and private

1:19:21for users is much higher than what I would say in five years from now, the

1:19:26local-first data frameworks that will be available in five years from now,

1:19:31most of them are already having this on the roadmap, but in five years, it's

1:19:35going to be, or even like in one year, three years in the future is going to

1:19:39be, Much less complexity that a app developer needs to think about today,

1:19:46we all appreciate and need to hear this sort of lecture on like how all of that

1:19:51works, because the technologies are not quite there yet, that I could just say.

1:19:57I pick my favorite local-first data stack, and they all implement the best practices.

1:20:02And all I need to look for is sort of like, Oh, the work with past keys is done.

1:20:06And I don't need to, as an app developer and as an app user, I don't

1:20:10need to do anything more right now.

1:20:12As an app developer, you need to know quite a bit about the moving pieces.

1:20:17And then each month and each year by year, We can forget about

1:20:21the underlying implementation details as all of that matures.

1:20:25So I just wanted to highlight that, and that is a bit of an uncanny valley, but

1:20:30things are moving in the right direction.

1:20:32Every one of them currently is inventing their own solution for identity in some ad

1:20:40hoc and informally specified way, right?

1:20:42They are all doing that right now.

1:20:45Of course as, as a human with an ego.

1:20:48I hope that they just see how amazing this Wallet is that I build.

1:20:53And they're like, let's stop doing that.

1:20:54Let's just use Wallet, right?

1:20:55Like I hope that's the case in reality.

1:20:58I think they'll pick something much lower level.

1:21:01And what I strongly assert they should do is base it on passkeys.

1:21:06And I hope that even if nothing else that I've done makes sense for your stack,

1:21:12the WebAuthn local client making it easy for you to deal with the passkey system

1:21:16without worrying about the servers and FIDO and all of that is, I think the way

1:21:20that local-first should go at a minimum.

1:21:23I hope that the other stuff I'm building is useful, but at a minimum, I really

1:21:26think building that on top of a passkey system, and I think a library like mine

1:21:31will make that much more approachable.

1:21:34I wanted to use passkeys, and I didn't want to build a library for it.

1:21:39But when I surveyed the landscape of those libraries, they were all server centric.

1:21:43And that's why I built one that can at least work for the cases

1:21:47where a server might be optional.

1:21:49So for whoever has made it through all the way to now and has like absorbed all of

1:21:55those details and hasn't had enough yet.

1:21:57I highly recommend you just check out those amazing projects

1:22:01that Kyle has been working on.

1:22:03Both try to build a little app with it.

1:22:06And if you're extra curious, also like look at the implementations.

1:22:10Actually not that much code in most places.

1:22:12And you get to see how the web APIs under the hood work in case

1:22:18you need to use something that's a little bit more low level than

1:22:21you've already seen a mechanism, a implementation, how this works.

1:22:25That's typically how I go about those sort of things.

1:22:28I try to see, can I use an existing thing?

1:22:30And if not, then I try to learn from the existing thing to build my own thing.

1:22:36And then this is sort of this dance back and forth.

1:22:38Later on, the existing thing is good enough and I throw

1:22:41away my own thing again.

1:22:42So try to learn from Kyle's implementations and try to

1:22:46use them in your own apps.

1:22:48Before wrapping up this already pretty long conversation, there was another

1:22:53project that I think you worked on before, and I'm not sure how mature it is or

1:22:58whether it was more of an experiment, but it did catch my attention because

1:23:02I thought it was, very interesting and had a bunch of like putting

1:23:06things together in a novel way to me.

1:23:09and so the project I'm referencing here is like the QR data sync project.

1:23:14Would you mind giving a overview what that was about and also how it came to be?

1:23:20So, first of all, status.

1:23:21QR Data Sync is absolutely a first class citizen in this same ecosystem

1:23:27and is absolutely going to be part of the Wallet app that I'm building because

1:23:31we need multiple transport mechanisms for data that go between devices.

1:23:37Obviously, a preference would be, make it just happen super seamlessly under

1:23:42the covers with something like the local peer to peer or another peer to

1:23:46peer protocol or Bluetooth or anything.

1:23:48It's like Any of those ways would be better, but there is always

1:23:52going to be a need for fallbacks.

1:23:54And one of the fallbacks is the QRDataSync.

1:23:58There's another one, which is not a library that I wrote,

1:24:00but I absolutely intend to use.

1:24:02It's called SilentJS.

1:24:03SilentJS actually transmits data between devices using supersonic sound waves.

1:24:09So it uses your microphone and your speaker between two devices

1:24:13and it transmits data that way.

1:24:15Fascinating stuff.

1:24:16I didn't write that library, but I think it's super awesome and that's

1:24:19going to be in the Wallet as an option if you are trying to synchronize.

1:24:23Very important to point out.

1:24:25Some of these fallbacks are going to be bandwidth limited and size limited.

1:24:29You're not going to synchronize a gigabyte of data through

1:24:32sound waves or through QR codes.

1:24:35Okay, so the bare minimum that you might do would be to synchronize

1:24:39your identity between those devices, which is very small, you know, A

1:24:44couple of hundred bits of data.

1:24:46And then once you have that, you now have established the ability

1:24:49to create a more secure tunnel through other mechanisms through

1:24:52the internet or something like that.

1:24:54So that's where I see things like QR data sync and silent JS being

1:24:58is kind of that lowest level.

1:25:00Let's synchronize my identities across devices, but then all that heavier

1:25:04data synchronization stuff that's going to happen, it should go through

1:25:07a more high throughput channel, like.

1:25:09You know, something that's or UDP based.

1:25:13Just briefly to touch on QR data sync, the way that library works is it creates

1:25:18what are called animated QR codes, not my original invention, but I saw

1:25:22it years and years ago, and then I didn't really see it ever go anywhere.

1:25:25And it just stuck in the back of my head.

1:25:27An animated QR code is nothing more complicated than a whole

1:25:32bunch of QR codes shown in rapid succession, like an animated frame.

1:25:37Each QR code can have a chunk of data in it.

1:25:39And so you take a big chunk of data, say like, you know, 10k of data.

1:25:44It's a string.

1:25:45You just break that up into a series of chunks, and then you do some

1:25:49padding so that you make sure that the QR codes are all uniformly sized.

1:25:52And then you just show those chunks in succession.

1:25:56My protocol in this library just has a very tiny little header on it that

1:26:00has the total number of frames that are going to be shown and what the

1:26:03frame index is that's being shown.

1:26:05So then you have a camera on a different device that is reading QR codes.

1:26:09And by the way, it's reading them very, very quickly.

1:26:11It reads them in like less than 15 milliseconds or something, but you

1:26:15just hold up your camera to a device that's displaying a set of animated

1:26:20codes and the camera is reading those.

1:26:22And it's just doing an infinite cycle, by the way, the sending is

1:26:26just sending them all in order because your camera might miss a few of them.

1:26:30And so it just holds in its memory, all the ones that it knows that

1:26:33it needs until it just keeps.

1:26:35keeps going until it has read all of the frames, and then it reconstitutes

1:26:40the data on the other side.

1:26:41So that's what QR Data Sync is.

1:26:43It is hopefully a fallback mechanism at best, but it's certainly

Outro

1:26:51I love this so much.

1:26:53This stimulates so many parts of like, what I like as a geek.

1:26:58particularly when some, Digitally tricky concepts become visually

1:27:04a little bit more tangible.

1:27:07And given that here with a QR data sync, the visible and visual component,

1:27:13but given that you've also mentioned the Salient project, which move

1:27:17that to another dimension, to the dimension of like hearing and sound.

1:27:21this sparks all sorts of like ideas in my head in the same way, where you

1:27:25can, somewhat style a QR code to look a little bit more like, brand related.

1:27:30I'm wondering, could I actually make the audio pairing, whether I

1:27:35can, manipulate that in a way to be related to what you're doing.

1:27:41In my head, there's sort of like those, those like old school modem sounds.

1:27:45So it's like back to the future in a way.

1:27:48so I'm, I'm very glad I asked about this project.

1:27:51and it's not just a very, curious and cool aspect of it, but I think

1:27:56it's also very practical and that's something that, people in the Web 2.

1:28:010 world are already quite familiar with.

1:28:03What I've mentioned before, whether you're pairing a, WhatsApp app from one

1:28:08device to another that is not animated.

1:28:11This is where a single static frame already is enough.

1:28:15But I think the patterns are already there, end users are familiar with

1:28:20them, and putting this all together in a pluggable way that allows for different

1:28:25options, all under this umbrella of your packages that you're working on.

1:28:30Super fascinating stuff.

1:28:32So Kyle, I think we're already running well on time here.

1:28:36but I really, really appreciate you coming on, sharing your background, sharing what

1:28:41led you to local-first and then sharing everything about your explorations and

1:28:46deep work and local-first identity, AuthN, local vault, all of those projects.

1:28:52Thank you so much for sharing all of that.

1:28:54Can I give one last little tidbit?

1:28:56The world, if we went back 10 years, and if you tried to convince people 10

1:29:01years ago, that the whole world needed to move away from usernames and passwords

1:29:07as the single factor for authentication and that the whole world was going to

1:29:12move to owning multiple devices and we were going to be able to like generate

1:29:16these numeric codes that were randomly changing in time and things like that.

1:29:20And if you told people 10 years ago that billions of people in the

1:29:24world would do that, most people would say that'll never happen.

1:29:28But if you fast forward 5 or 10 years, the vast majority of the world has upgraded

1:29:32to multi factor for authentication.

1:29:35We've still got a long way to go.

1:29:37I'm not saying that it's a fixed problem, but we have absolutely

1:29:41upgraded the world to understanding the concepts of multi factor.

1:29:45So what I'm suggesting in the move forward with going to a Wallet and going to this

1:29:50local-first identity is akin to that.

1:29:53Will it take a while and will it take users changing their mindset

1:29:58and will it take big players pushing it and requiring the adoption?

1:30:02Yeah, it absolutely will.

1:30:04It's a, it is a hill to climb, but I just wanted to point out that, concept of

1:30:10multi factor auth is not going to go away.

1:30:12It's just going to evolve in this app.

1:30:15So for example.

1:30:17This app is going to have a TOTP number generator, where you can use it as a

1:30:21second factor of auth, but instead of you having to look at your phone and then type

1:30:26in the numbers, if you have the Wallet app on your phone and on your laptop, and your

1:30:30laptop is challenging you for a second factor of auth, All you need to do is

1:30:34open up the Wallet app on your phone and say, give me a code and instantaneously

1:30:39that code can synchronize to the Wallet on your desktop and then paste from the

1:30:43Wallet on your desktop into the form.

1:30:46You don't need to sit here and type all of these numbers so we can have an

1:30:50upgraded view of what second and multi factor auth is if we go in this direction.

1:30:56And that's one of the things I'm most excited about because we should

1:30:58not be compromising on security.

1:31:00We should be upgrading security, but also, as you've said several times, putting the

1:31:05user experience first and foremost here.

1:31:08I think arguably a lot of the multi factor auth was pretty rough for users at first.

1:31:13SMS codes and all these other things, you know, waiting 10 minutes

1:31:16for a text message to come in.

1:31:18We still have a lot of that.

1:31:19There's still a long way to go.

1:31:20But because we've made so much progress there, I am very bullish on the fact

1:31:24that we can make the same kind of progress towards this web 2.5 where we

1:31:29own our data and we own our identities as we take them through different

1:31:33apps and through different devices.

1:31:36That's a wonderful summary.

1:31:37I'm very excited about that future.

1:31:39Kyle, thank you so much for sharing all of that with us today.

1:31:43Thank you for having me.

1:31:44It's been a thrill to dig into it.

1:31:47Thank you for listening to the Local First FM podcast.

1:31:50If you've enjoyed this episode and haven't done so already, please

1:31:53subscribe and leave a review.

1:31:55Please also share this episode with your friends and colleagues.

1:31:58Spreading the word about this podcast is a great way to support

1:32:01it and help me keep it going.

1:32:03A special thanks again to Rosicorp and PowerSync for supporting this podcast.

1:32:07I'll see you next time