Web3 Galaxy Brain 🌌🧠

Nicholas: Before we get started, I'm collecting listener testimonies for a new section on the website. If you love Web3 Galaxy Brain, please send me a tweet-length message saying why you listen and what makes the show special for you. DM me your testimony at Nicholas with four leading ends on Twitter or Telegram or at Nicholas on Warpcast. Thank you. Welcome to Web3 Galaxy Brain. My name is Nicholas. Each week, I sit down with some of the brightest people building Web3 to talk about what they're working on right now. My guests today are James McComish and Peter Ferguson, co-founders of Forum. Forum is an iPhone app where every group DM has its own shared wallet. James and Peter are among the most knowledgeable builders working with Web Authent and pass keys that I've encountered. On this episode, we discuss the ins and outs of Web Authent in production, including large blob, cross-origin domains, session keys, and the three versions of the spec to date. We also delve into the team's journey building Forum. It was a treat talking to James and Peter about their experiences building with pass keys and Web authentication. I hope you enjoy the show. While Forum is fundraising, as always, this show is provided as entertainment and does not constitute legal, financial, or tax advice or any form of endorsement or suggestion. Crypto has risks, and you alone are responsible for doing your research and making your own decisions. James, Peter, I'm so excited to talk to you. Thanks for coming on the show.

Peter Ferguson: Yeah, cool. Thanks for having us.

Nicholas: Absolutely. So actually, how did you two meet originally? And maybe you could tell me a little bit about the genesis of Forum.

James McComish: So we met a long, long time ago now, I guess. We were in the same class in like middle school. So we were there for like, yeah, like quite a few years. And then Forum obviously really didn't start for quite a while after that. But we sort of like we studied together for a few years of school and then went like our separate ways for uni. I was studying electronic engineering in London. I was there for four years before moving over to Barcelona, where I got a job in a startup over here as an employee number six, working as an automation engineer. Worked here for the first year and a half as an engineer, and then sort of moved into setting up and growing our managed operations department across the EU and US. Sort of towards the end of that, has gone home to Belfast. So that's where we were like originally from. I met up with Peter for a coffee and he basically showed me this very, very roughly hacked together app, which sort of let you execute trades from a group chat. It was cool enough that I quit my job and we've basically been building it since.

Nicholas: Awesome. And when about was that?

James McComish: Was it 2021?

Peter Ferguson: Yeah. So it started out as a Web 2 app. We actually hadn't really got into Web 3 yet. We were actually in a group chat trading stocks. We built that out for a bit before diving into Web 3 and really discovering sort of DAOs and multi-sigs and how all of the problems that we were facing and trying to resolve in Web 2 are already solved in Web 3. It's been a long journey to where we are now, but yeah, two years, roughly.

Nicholas: And Peter, what was your background before starting the project?

Peter Ferguson: Yeah, so I went to uni studying maths and theoretical physics. After that, I had a couple of PhD offers lined up in a bunch of different subjects, all sort of very mavsy, some in theoretical physics and one actually in maths with deep learning. And I decided to basically drop out of the PhD program and join a startup. And when I first started investing, I started group chat and thought that we should do this in a group chat. It's a fun thing. Everyone should sort of learn together just with my friends and stuff. So that's where I started hacking together that app that James told you about just because we really wanted to actually call stuff together in the chat and sort of execute things directly from there. And so that's how we basically started.

Nicholas: So very natural genesis from group chat to straight, let's just solve this problem for what we're doing right now already.

Peter Ferguson: Exactly. Yeah. So it was kind of just like it was a simple trading like Telegram bot. It was like a linked website where we did like new portfolio and stuff. And it was just a matter of like, why isn't this possible at the minute? Why can't you actually do this? This seems like a supernatural way to just sort of get into this. If you're 19, 20, or you have your first money coming in, with this sort of social site guys of Gen Z these days, people are just going to want to do it from where they're already chatting about these sort of things. With Wall Street Bets and everything sort of blowing up, everyone's talking about this sort of stuff in their group chat. And it just made sense to me at the time that this should be a product that people should just be able to execute directly from there together and cool and things and sort of have fun and play about with these assets online.

Nicholas: Great. So we're going to loop back at the end of the conversation and talk more in detail about the Forum product. But on the way there, I want to talk a lot about web authentication, pass keys, AA wallets. And I think basically the theme here is you're trying to solve for making the experience of participating in crypto more native to the kinds of experiences that people are spending all their day on like chat apps and Reddit and such. And pass keys and AA wallets and this new smart wallet stack seems like really one of the greatest ways to get there to make things purely native to the operating systems that people are already using and the browsers too. Is that how you perceive of the advantage of pass keys and AA wallets? And is that the sort of origin of your interest in that particular part of the stack?

Peter Ferguson: Yeah, James, do you want to sort of take how we got around to that?

James McComish: Yeah, sure. So pretty much, yeah, it came down to like ultimately just improving UX for people who were trying to get involved. Like our first sort of discovery of DAOs was just this sort of like realization that this is the perfect model for an internet native investment club. And, you know, as Peter had said before, we sort of seen that this is like almost a ready-made solution for doing like an investment club. And when we realized that it actually wasn't quite mature enough yet, we sort of asked, like we were sort of asking people why, like what were they struggling with when they were actually in DAOs and managing like a treasury online. And our first sort of product basically in Web3 was this like web-based way that you could manage an investment with some friends. We launched that on like Avex sort of like shortly after we got involved in Web3. And the feedback that we got from people was that, okay, like this is good, this is interesting. It was like sort of end of 2021 maybe. They wanted to invite their friends because apparently like everyone was still quite excited about crypto then and they had lots of good reasons to just try to link like all their friends into this group that they were investing with because it was like, you know, exciting things were happening. And they couldn't. So we had this sort of web-based group platform where the already encrypted people could manage but they couldn't get their friends in. And we sort of thought about this and we figured like, okay, like if there was a convenient way that we could onboard those friends as well without having to go through all the like setting up of an account and understanding like how the native tokens of Avex work, and then we would do that. And quite sort of like coincidentally almost that this was around the time when account abstraction in the form of ERC 4337 was sort of gaining traction and people were like discussing it a lot. And towards the end of that fall, so I think that was probably like summer 2022, and sort of like that fall Apple were releasing like Paskeys or like Intubing Paskeys into iOS 15. So we figured like, okay, this combination is quite perfect for these people who were sort of like never going to get involved otherwise. So we sort of like hacked those together into some sort of like Paskey controlled wallet. And we got that launched and that was sort of the start of our like exploration into like account abstraction.

Nicholas: Very cool. So right away, you really identified that this native affordance for public private key pairs in all the browsers and all the operating systems now adopted by iOS would be like a really great kind of signer on an AA wallet. Maybe I've done a couple episodes with other people on smart wallets and Paskeys and AA and such, but maybe do you want to give a quick definition of what Paskeys are and what the 4337 AA spec provides. that's interesting?

James McComish: Yeah, they don't really go Paskeys, so I'll go 437.

Peter Ferguson: Yeah, cool. So yeah, Paskeys are basically this sort of, it's almost like an extension of the original WebAuthn spec that allows for sharing of a WebAuthn keeper. I suppose I should also explain what WebAuthn is. WebAuthn is a sort of standard web API for authentication and across websites. So it's sort of intended to be a password replacement. And the idea is that you come to a website and you use some biometrics and if you're using your phone, then there's some Bluetooth involved to sort of build in this two-factor authentication method so we can get rid of passwords and one-time passcodes, etc. And so this is a standardized spec that has been being worked on, I think, since 2019 and sort of has had several iterations. So that was level one of the WebAuthn spec and we're now sort of progressing towards level three. And I think the latest draft was edited maybe three days ago or something. So it's very evolving. But what Paskeys did to that was basically weaken the security principles of it a little bit so that these could be shared and stored in iCloud and sort of progressively push the spec forward so that we could have these WebAuthn credentials shared across your iCloud.

Nicholas: The original spec didn't allow for the exfiltration of the Paskey at all.

Peter Ferguson: Exactly. Yeah. So it wouldn't even have been Paskeys then, it would have just been straight WebAuthn. And the idea of the Paskey came along, I think it was originally Apple that pushed this separation from the original WebAuthn spec to allow you to sort of extract it and share it across your iCloud. And if you dig back into the issues in the GitHub repo of the WebAuthn spec, you can see there's a lot of arguments about it, about whether it's something that's shopping or not.

Nicholas: This is why I'm really excited to talk to you guys, among other things, because I feel your team, you two are maybe the most informed of anyone I've seen talking about this stuff about the WebAuthn spec itself. So I feel like there's a lot of alpha that you can share here about really the ins and outs. It's fascinating to hear that Paskeys are kind of a little bit less secure version of the original WebAuthn spec. Is there anything else in WebAuthn aside from roughly what we might associate with a Paskey user experience? Is it an umbrella for anything in addition to that?

Peter Ferguson: It's becoming more and more exactly what you're talking about now. As you progress through the levels, it's becoming much more open to other applications. And actually, I think the current understanding of WebAuthn in crypto circles is sort of stuck in that L1 phase, whereas now we're in L3. Well, we're starting to get to L3. It seems that it's every two years they're releasing a level of the spec. And if you go by that rough calculus, it'll be a couple months before L3 is fully adopted. But what the levels and extensions provide is, so one example is LargeBlob and these other extensions, there are some for basically choosing which apps and stuff that you can authenticate with, adding in sort of cross origin WebAuthn credentials, which no one's really talking about in crypto circles, which is interesting. So yeah, there's quite a lot that actually is happening in WebAuthn that I don't really think and don't really hear people talking about in crypto circles.

Nicholas: Yeah, I want to get into all of it. So maybe before we jump into the extension stuff, first of all, are the levels like progressively added or are they like versions of the spec?

Peter Ferguson: Yeah, I think they're intended to be versions. So they sort of come out with a spec draft every seemingly two years and it's sort of updated and you can sort of keep track of it. on the GitHub issues. And yeah, basically we go for there. So the latest level, the last draft of the level three spec was edited two days ago. So it's very evolving.

Nicholas: Awesome. Okay, so let's spend some time on WebAuthn and we'll come back to the AA stuff. and James, you can touch on that later. But so Web authentication. for people who haven't really experienced it, what does it define really? What are the procedures that it specifies?

Peter Ferguson: So basically, it is a sort of, let's see, so there's sort of like three parties involved in a WebAuthn spec. So there's the user agents, and you can think of those as basically Google, Apple, etc, who are in charge of basically implementing this WebAuthn spec, which is an API that is supposed to allow the user to easily authenticate on the web. And they do that, well, the reason that they want to do this is they want to get rid of passwords and they do that by being more cryptographically secure. So they're trying to do it with generating private public key powers and really picking up the back of crypto and sort of realizing that this is a good way to actually authenticate people. And so the user agents that are involved in the WebAuthn spec, the first party, they are the people that are in charge of creating those credentials so that they match the WebAuthn spec, which basically is a certain specific way of generating these credentials and specific way of then authenticating with those credentials. Then the second party in the WebAuthn spec is the relaying party. And so if you take Forum as an example, we would be a relaying party. That is someone who is interfacing with the user and the user agent. And the whole idea is basically you have a website, you have an app, and you then through the user agent have access to these generated public key, private key powers that you can use for whatever generally is intended that you use it for authenticating users onto your website. But with crypto, we take that a bit further and actually control your keys with it and you use it to control your assets. And then the third party is of course the user. And what WebAuthn does for the user for the crypto context is basically that we get these nicely generated key pairs that are integrated directly into all of your normal software that you're using. So your iOS, your Google, Android, your Chrome, and Safari, et cetera.

Nicholas: It's really incredible that they pulled this off, frankly.

Peter Ferguson: Yeah, it's a pretty huge change to how people were doing it before. And from the upcoming things that I know that are in the spec, it's going to be pretty huge changes for crypto if we can actually figure out how to implement it properly. And one of the main interesting things about the level three spec for me is the cross origin. So it basically means that any website, as long as they know you have a passkey on a different website can call it. So for example, if I'm Uniswap, and I'm a user, I'm on Uniswap, and Uniswap knows that I have a passkey on form. And if Uniswap knows that, then they can actually call to my passkey, authenticate through form, and have access to the authenticated data then. And this is a pretty big part of the level three spec of WebAuthn. So there's a lot of cross party crypto stuff that can be developed.

Nicholas: My understanding of the level two spec that I'm familiar with is that you, as a Dapp or app or web app, PWA, whatever it might be, you have to put the user through one of two paths. Either they are creating a passkey or they are signing in with an existing passkey. But as the application, you're not aware of whether or not they have a passkey at that stage because it's the operating system or browser that's managing the passkeys. And they don't reveal, from what I understand, at least, under the level two spec, they don't reveal if the user even has a passkey that they generated on your own site. So level three maybe changes that so that it's possible to query and get some information about what the user might have.

Peter Ferguson: Yeah, so I'm not actually 100% sure about the discovery mechanism of the credential keys and of the credential ID, sorry. But yes, the idea of level two is basically, if I am a relay party, so I'm a Dapp, well, if I'm a relay party, so I'm a website, I would have no way of sort of discovering whether you have passkeys on, say, your wallet. And the only people who would know whether you have passkeys on a wallet would be the wallet that generated them because the credential ID isn't exposed. But the level three spec seems to be moving towards a cross origin model. And actually, with iOS 17 launch, and I've noticed in their docs, they actually now have a prop for cross origin on some of their passkey methods, but I haven't got around to playing with them yet. But just the idea is, basically, you generate a passkey on, say, a wallet app, there is some discovery mechanism and a slash list of parties that you can choose that are able to discover your key, your credential ID through your wallet app. So say you're in forum, if once we get the level three spec, you'll be able to create a passkey on forum and decide that you want Uniswap and OpenSea, and I don't know, Mint.com to be able to discover your credential. And then when you go on those websites, they'll be able to check what credentials does this person have and let's sign with them.

Nicholas: Is that something that you think will need to be presented to the user as a permission or it's something that the application that creates the passkey would be able to just define in software behind the scenes?

Peter Ferguson: What do you mean? Sorry, I don't really understand.

Nicholas: I mean, there's an infinite possible number of applications you might want to allow to discover in the past keys in the future. So I'm just wondering how, yeah, what kind of UX might we anticipate? Is it a list of every dapp in the world? or maybe the developer like forum could just set, yes, of course, Uniswap can access this key in the future.

Peter Ferguson: Yeah, so this is the thing with the strict web auth spec. And the way it works right now is if you authenticate with web auth in, you're basically will be presenting your key one way or another. So if you're going to use, well, there's two ways you can sort of store your keys in a web auth in credential. The first one is using large blob and storing your actual EOA K1 key in that blob, or you can just use the native K1 curve that is attached to your passkey. And so depending on which one of those you're using, there's different considerations that goes into allowing certain dapps to use it. So you say you're using a large blob, the way that would work, the way the large blob works is basically every time you authenticate, if you authenticate and request the large blob, you face ID on some dapp and that dapp is then given the blob. And if that blob is just your private key, so you can see the scenario where you absolutely do not want other websites having that key. But you might be okay with something like Uniswap doing it.

Nicholas: We should give a little context on large blob. So first of all, under the level two spec, am I correct in this? There's two kinds of flows and often the demo apps that I've seen will present sign in or create. because if you click sign in and you don't have a passkey yet, the application doesn't actually know yet. So you're presented with the, let's say for example, iOS dialog. However, if there's no passkey in your key chain, either locally or on iCloud, then you're presented with, I think usually a QR code. And the implication is that you must have a passkey on some other physical device that you can scan the QR code with to log in. But this is a really bad UX if you actually don't yet have a passkey anywhere, because if you scan that QR code with a regular phone camera or God forbid you're already on your only phone, it's not very clear what to do next. So you have to create the passkey first through a separate flow and then sign in with it. Is that basically the state of the art of the L2 UX or am I missing some piece there?

Peter Ferguson: No, yeah, I think that's exactly it. I think it's distinct in the crypto use case as well, because generally when you're signing into one of these dapps or even a wallet, you're going to want to choose a very specific passkey. And so the dapp or whoever is sort of initiating that interaction should be specifying I want Peter's, I don't know, certain wallet. Exactly, yeah, they want that specific key. And so in that case...

Nicholas: Right now that's not really a problem, right? Because you can have multiple passkeys under the current spec associated with a specific domain, but you can't have cross domain easily under level two, right? So if I go to forum and I click sign in, I'm only going to be presented with the passkeys under the current spec at least, that I previously created with the forum website or app.

Peter Ferguson: True, but you as the user can choose any one of those passkeys to sign with and that might not be what the app is trying to do. So the app could be trying to sign for your first wallet and you sign it with your third, it's going to fail. And so basically in the crypto use case, we always want to be defining this allow credentials parameter of the web off-inspect, which basically just means choose a single passkey. And if they don't have a show a QR code, so they must have it somewhere else that maybe it's a hardware, maybe it's on a hardware device or maybe it's on their phone. So I think that is a good thing rather than sort of not a good UX.

Nicholas: So there's one other detail before we get to the large blob stuff that's probably worth discussing, which is when you create the passkey, that is, at least from what I understand, under the level two spec, the only opportunity that the application has to grab the public key corresponding to the passkey. And they also get like a raw ID. Is that right? Like an identifier essentially?

Peter Ferguson: Yeah. So that's, I think that's actually the L1 spec. and with the L2, yeah, with the L2 spec, if you do it on a navigator, the navigator credential API, so basically if you do it through a website, if you don't do it through Apple, they actually now provide a get public key method on your return credentials. So you can actually call that and pull back the public key.

Nicholas: But iOS is stuck on level one for now.

Peter Ferguson: But iOS has, this is the thing with iOS, iOS pick and choose what they want to adopt and what they don't. And it's very clear if you go on the Apple forums, people are requesting that they support certain parts of the spec and some of the answers have been just because it's in the spec as a potential use case doesn't mean we see it as a use case. So yeah, the Apple choose what they want to do.

Nicholas: Do you have a sense like summarizing what their perspective seems to be on what's safe or what they're interested in implementing or it's we're still figuring it out?

Peter Ferguson: Yeah, I wish I knew. A couple months ago, I was on the Apple forums and I was asking specifically, please adopt large blob. And I got a response that was basically no. And then a couple months later, it's in there.

Nicholas: Yeah, exactly. So we discussed, so under level two, you said there's some changes. We have opportunities to query what pass keys exist. Is that what you were saying?

Peter Ferguson: No, you can get the, assuming you have already verified with a credential with a pass key, you can then get the public key, which wasn't the case before. You would have to have it on initial.

Nicholas: Okay. So if I drop into the forum app and forum forgot to store the public key at the key generation event, then forum can still pick it up once I'm face ID'd into the application.

Peter Ferguson: Exactly. Yeah, I can ask you, I can basically remove the allow credentials, ask you to sign in with one of your pass keys. You sign in with a pass key, then I can pull the public key, not the private key.

Nicholas: Got it. So just to keep the playing field level for everybody. So we're still talking about a pass key, which is on this SCCP256R1 curve, the R1 curve for short, or P256, I've heard Jose call it. So that's not the same curve as you alluded to earlier as is used in the EVM. So you can't directly sign transactions on Ethereum, be they AA or otherwise, with the pass key because we need some glue in the middle, something to allow us to, because WebAuthn essentially doesn't let you create a K1 curve. pass key, correct?

Peter Ferguson: Correct. Yeah.

Nicholas: So this is where large blob starts to come into the picture. So maybe could you explain a little large blob is?

Peter Ferguson: Yeah. First of all, I should also actually mention, there's nothing in the spec that excludes you from generating a K1 curve. They basically leave the curves open for what curves you want to use. But when I was talking about the three parties involved in the WebAuthn spec, the user agents, Google, Apple, those that control it, they have really only implemented R1, P256. So there could be a future where if the entire crypto community pushed those people to allow generation of K1 in the browser, that's possible. But I don't think it's actually possible in the secure market of iOS or those other devices. Right.

Nicholas: Well, while we're on the topic, do you have any skepticism about the R1 curve? Does it keep you up at night or you think it's a safe thing to use?

Peter Ferguson: No, I am not a conspiracy theorist, I would say.

Nicholas: Maybe you're working for a company.

Peter Ferguson: I think my take on it is basically users don't care. It's going to be a very rare case where the NSA is interested in your form of account, given your key, basically. Exactly. So even if there was a backdoor, it's probably not all that important.

Nicholas: We seem to be resolving, I mean, of course, we're kind of talking always amongst people who are interested in pass keys, which is a little bit of a self-selecting biased set. And I'm sure the Bitcoin maxis will be healthy skeptics regarding all this. But I think basically if you're the score seems to settle down to if you're planning on using a software wallet on your mobile device, then you've basically already bought into the security model of the mobile device. So the R1 is the least of your concerns. It's probably more the iOS or Android binary or Chrome or Safari, etc., that are a bigger surface area for risk than actually hacking the curve just to get your hot water. Yeah, exactly.

Peter Ferguson: If you're on iOS, then iCloud keychains, sort of key management infrastructure there is probably a bigger issue than the actual curve itself.

Nicholas: In passing, they do have a very cool set of options. And really, what super attracted me to pass keys, aside from the UX improvement, is if you do the, I think it's called advanced protection on iCloud, Apple essentially deletes their key so they can no longer recover your stuff for you if you lose your Apple ID password. And then there's an additional feature called recovery contacts, which is not quite the same as social recovery. But essentially, you can add anyone with iMessage to your account. And if they accept, they can recover to a device that was previously logged in with your Apple ID, they can recover for you should you lose your password and should Apple not have access to it because you enabled advanced protection. So the issue with it is that there's no threshold. So any individual recovery contact can recover your account as long as they have a physical device that was previously logged in. But it's a pretty compelling, I wouldn't call it cold storage, but it's a pretty good self-custody story because if you can trust Apple to actually throw away their key. when you turn on this advanced protection stuff, then you really do have an end-to-end encrypted keychain with your pass keys that are your logins for your crypto apps. So that's pretty cool.

Peter Ferguson: Yeah, exactly. I actually didn't know that about the advanced protection. I knew the sort of social recovery bit because that was one of the main things that we really liked about pass keys as well. Early in 4-3-7, social recovery was a big topic. And the fact that pass keys sort of have these built in was a major plus for us. And also now in the latest iOS, you can airdrop your pass keys as well. So if you have an old iOS device sitting about, you can drop it onto it and it's basically a hardware wallet sitting offline.

Nicholas: It's super cool. And the hubie key, or I guess hardware key, I don't know what the generic term is for hubie key, but the fact that you could plug a hubie key into your phone and use that to store the private key is pretty cool.

Peter Ferguson: Yeah, exactly. There's a lot of people interested in hubie keys and storing them offline. I haven't actually played with it much, but it's interesting.

Nicholas: I guess you can use NFC or nowadays with the new phones, even USB-C. So maybe a whole lot of other hardware key devices are compatible.

Peter Ferguson: Yeah, that's another interesting part of the updates to the spec as well. They're adding more and more transports. So you have smart card, etc. And that is actually being added on there. So you might in some time be able to add on a smart card or some other device that you can then store your keys on. Something like a credit card style key. Which is pretty cool.

Nicholas: Very neat. It feels like, yeah, things are really coming online for the UX of this stuff. So we alluded to this a second ago, but basically because the passkey is on a different curve, you can't verify the R1 signature easily inside of the EVM. There's no precompile, there's no opcode for doing that. You don't have this EC recover function that we use all over the place in smart contracts. So there's a few different solutions. We've talked about a couple of them on prior episodes. The main ones that are apparent to me are to use a smart contract that has written into the smart contract the logic for verifying R1 key. So then you sign a message, send it to the AA wallet, and then your AA wallet calls out to this other smart contract that you're using to check that the passkey signature is accurate. And that costs you some extra gas. And as far as I'm aware, it's about 70,000 gas for the best implementation of that in its own contract. There's also this 7212 EIP, which is proposing to incorporate such a capability into a precompile and make it cost about 3,400 gas, which is similar to the EC recover cost. And then the final solution, which actually I think in practice seems to be the most popular, is to use some kind of MPC solution, multi-party computation solution in between. So the passkey, instead of directly signing on the AA wallet, is signing on something like a lit protocol or turnkey or silence laboratories solution. And then whichever of those you've chosen does a distributed key generation, which is to say they kind of create an EOA synthetically between a bunch of different computers. The EOA private key doesn't exist on any one computer or in any one runtime, so nobody could steal it from memory anywhere. However, it's able to sign transactions and it's signing them with a K1 curve, so it can just be verified cheaply in regular signatures by the AA wallet. Is that a good summary of what the options are or are there things I'm missing there?

Peter Ferguson: Yeah, I think the only thing that's sort of missing is the introduction of Largebub as well. Those three are the options that you basically have today, but we actually just implemented Largebub into our app this week, so it's very new. But the idea of the Largebub is that in the L2 spec, they added the idea of an extension to WebAuthn and it allows you to define some standardised extra sort of functionality that people can adopt and provide. You can actually create your own extensions as well, but one of the main ones that people have asked for from the beginning is a Largebub and it's basically the ability to attach some data to your passkey that will then be encrypted and stored alongside your actual key. Anytime you do authenticate, the website or app that is actually doing the authentication can ask, provide me with the data that was stored on the passkey and basically give me access to it on encrypted, I suppose.

Nicholas: That Largebub data lives in the Secure Enclave, but if the user grants permission, then they would get access directly to the raw data.

Peter Ferguson: So Secure Enclave, yes, the story of Secure Enclave is interesting and always sort of obscure, but the idea is that it is encrypted and decrypted in the Secure Enclave. Would that be encrypted and decrypted in the Secure Enclave? I'm not actually 100% sure on where the Largebub is decrypted, but the idea is that it's generated, when it is generated, it's encrypted and attached and stored wherever your passkey is. So that could be the iCloud keychain, it could be if you have specified that it's a hardware device, then also on the hardware device and not on the iCloud keychain, because if you specify with WebAuthN that I want this key to specifically be a resident key or not a resident key, then it will be stored solely on the device. I'm not actually sure. And then it wouldn't be a passkey because it's not shared, it would just be a WebAuthN credential. But yes, so you have this Largebub, you have this attached and can be shared from the key itself when it is authenticated.

Nicholas: Resident key means that it's on device only?

Peter Ferguson: They've actually deprecated the term resident key. It's still in this fact.

Nicholas: Since the beginning of this conversation.

Peter Ferguson: Exactly, yeah. So they've actually started to move away from it. But as I understand it, if you're generating a passkey, you want that to be a resident key, which is sort of counterintuitive. And maybe that's one of the reasons that they've deprecated it. But yeah, so there's this idea of resident keys and it decides whether it stays on your device or whether it is shared. I don't remember the new name or what they're calling it. But yes, there's a distinction and some term that basically decides whether I want this on device only or shared to the cloud.

Nicholas: So whether it's Trad, WebAuthN or actually a passkey that's moving around.

Peter Ferguson: Pretty much, yeah.

Nicholas: And OK, so now we have Largebub. So how much storage can you fit into Largebub?

Peter Ferguson: There actually isn't anything in the spec and it sort of makes sense because it is sort of dependent on your user agent and what storage they're using for it. So like, for example, if you're going through Apple, their secure enclave is going to be different than what you're going to get through like Google Chrome or something like that. If you're doing it specifically just on your laptop or whether it's going through your laptop's secure enclave or not. So it's not actually specified. When I was implemented this week, I sort of wanted to play about and sort of see how much I could store in there. But I ended up storing just some sort of. So we also with Forum, we're very focused around chat as well and the XMTP as our main sort of chat backend. And so we actually store your private key and your chat bundle key within the Largebub. And so we can at least store that. and you're talking thousands of kilobytes, I think. No, not thousands, hundreds of kilobytes. Is that right? Sounds about right. But yeah, I'm not 100% sure.

Nicholas: Maybe one JPEG, not more.

Peter Ferguson: Yeah, you don't want to be storing a lot in there. I think very clear in the spec, don't be putting too much in here. The whole idea and the sort of major benefit is, yes, for crypto, it's good. Yes, we can store the key in private key, your EOA private key, so K1 generated keys. And that way, you can interact on-chain without going through the contract and incurring that massive difference in gas. But the original idea for the Largebub was, I'm a chat app, I'm Telegram or something like that. I want to authenticate my user with a passkey and store their end-to-end encrypted key on their passkey that they generated on their device so that when they come to my desktop app, and they authenticate with their passkey, I don't need to go anywhere else to get their keys. I have just basically can get it off the Largebub and have you authenticated all your chats, etc. So for us, we only have an iOS app right now. But when we get to it, if you have Android, if you have your Mac app, and we have desktop apps or websites, if you send them with your passkey that you generated on the form iOS app, you will automatically be sent in your XMTP account as well. There's no regeneration of the keys, there's no going to XMTP and saying, hey, give me the key that I need to interact as Peter on XMTP. It's just there on your passkey. So that's the idea.

Nicholas: So it's a little bit lower key than if it was a private key for like an actual EOA. It's more just a communications thing for XMTP. So it's maybe not as dangerous to have it in memory in these other applications when you log in with the same passkey.

Peter Ferguson: Yes, for the specific keys of the XMTP key, yes. But we do also store your private key there.

Nicholas: Do you worry about, I mean, I remember early days of Arweave and Tezos, but you know, just drag and drop your .json key store straight into the browser to log into an app. Is it a little bit feeling similar if accidentally face IDing, you could maybe just give the large blob private key to some app that you don't trust? Do you have any thoughts on that?

Peter Ferguson: Yeah, so someone actually asked a good question on Firecaster the other day, and they basically said, now that passkey support large blob, which do you prefer? Do you want the R1 curve? Or do you think that we should be still pushing 7212? Or can we just stick with the EOA K1 curve? And I think that's the exact issue right there. Cross origin large blob is not something I really want to be doing unless it's a uni swap or something, something very established. But yeah, even then I'm not really happy about just exposing my private key like that. And so that is the main reason that I sort of still, I'm a firm believer in the R1 on keying is the way forward for that.

Nicholas: Can you think of any other creative, and James, feel free to jump in if you have anything here, but can you think of any other creative uses of large blob or the primary uses like store some kind of private key in there and then get access to it when you ask for these kind of elevated large blob permissions when signing in in the future to different applications?

Peter Ferguson: Hmm, I haven't specifically thought about it in terms of other applications. The main thing that I've been thinking of is in terms of like. how can we move things across different clients and stuff like that. I know like Racer on Twitter the other day was asking, like was saying that one of the main problems that he's facing right now in consumer crypto is how do we get these keys across devices? because we want people to be able to seamlessly use it on web and on their device if their PWA is on the phone and then they want to use the website on their laptop or something. How do they get those keys across in a nice way? And I think that is the main use case for large blob as it exists. So I don't see a use case where there's large blob cross origin stuff happening. I don't think people will be happy to just be presenting their private key like that. But I think it is great for that exact use case that Racer mentioned. It's like we have this app, we are your wallet, we are say rainbow and I have my passkey large blob EOA in my rainbow wallet and I go to use the rainbow extension. Oh there it is, it's already there. I don't have to import my keys again or anything like that.

Nicholas: So essentially by controlling the same URL they would be able to restrict the domain access to the large blob to just other instances of the same application but on different platforms.

Peter Ferguson: Exactly.

Nicholas: Very cool.

Peter Ferguson: I think that's the main use case.

Nicholas: Could you expand a little bit on how domains work under the current regime in iOS and what we have to look forward to? because my understanding is that for now at least the passkeys that you've generated on iOS are associated like let's just say Frantech used passkeys or we could use Forum as an example. Forum had a website or I guess the app also. The passkeys that you generate inside the app or web app are restricted by iOS under the current system from what I understand to just being accessed again in that same app. Can you just specify a little bit about how like the different ways that maybe a little bit more detail on the permissions that you would grant once you're logged in to have this cross domain access or if there are other systems. I've also heard people working on things like associating the domain with the passkey generation not with the domain of the actual web app that you're using but like an underlying wallet provider SDK that's embedded inside of that application which then itself could give you access to that domain inside of other apps where they're using that same SDK. Maybe can you clarify just for people who are a little bit lost on how all this domain permissioning works?

Peter Ferguson: Yeah, I don't know about that second use case. I don't know if that's even possible. Basically when you're implementing passkeys for either Android or in an app in a mobile app when you're implementing it you have to sort of link your website to the app using like an apple call and apple app site association file. and android also have a similar file and it's your website exposes that. and then when you build your mobile app and ship it you have to have already specified the link between that mobile app and the website. and that's what creates that sort of relying party power between the website and the app that allows your app to say yes I am authenticated I am a part of this website and so pardon me. so yeah the any url that's specified in file that has been linked to the app can be used. so why I think it wouldn't work for the example that you're talking about is basically like if there was some other website that you're saying well I suppose maybe they could do. they could expose and you could basically ask that website to put in their exposed file your app name and then within your app you put their website url and then that creates the link. but yeah I suppose it would work. actually I take it back. I just don't know how there's an increased level of trust there. basically trust in the? yes exactly yeah. so if I'm an app um take say for example we exposed a on our website. we exposed a url in the file that said friend tech could use our passkey and domain and then friend tech in their app said okay we can use form and there's a there's a form and because ultimately then it is us that controls whether what and what is going through and what's being sent there. if you know what I mean like uh what's the weight? they could exactly yeah yeah so that you're you're you're outsourcing that to the other party and so there's a level of trust that sort of has to be had there.

Nicholas: so uh we talked a little bit about it but just want to get it super duper clear. so for this upcoming stuff around allowing others like allowing uniswap to access the forum wallet obviously the advantage is I generate a wallet for my user in my application and I want them to be able to do other stuff on the chain. I want some composability. um so maybe I don't just don't recall exactly what you said. but uh do you have a sense of how we're going to do this kind of permissioning? is it will it be something at the creation time or orchestrated by the dapp or something that's really presented to the user?

Peter Ferguson: yeah I'm I am not 100 either. um as I said like the the draft is sort of ongoing and the last draft was released two days ago and so it is sort of up in the air. but so basically we always talk about web off them. but there's actually a another extension uh that is being developed right now um called the secure payment confirmation and it's sort of an extension of web n but it actually goes further and defines a lot of other apis and the whole. the whole idea behind that and and why people are pushing it is to enable you to use web off end to confirm payments through your bank. so as this becomes more adopted what you're going to see more and more online is that I go to amazon. amazon presents me with something that looks like a web off end credential and in that web offing credential it says you agree to spend 50 on this exact item. I hit yes I use a web offing key to sort of sign that and then there is some relaying between amazon and my bank account where I have previously created this web offing credential and I if my authentication goes through on the amazon website my bank will get the metadata of what was being purchased how much for and whether the the authentication worked or not and they will then purchase it. and so the this new spec called secure payment confirmation was one of the main drivers for why web off end are opening up to cross origin. because again if you dive into the issues there's a lot of people vary against cross origin because they believe that it reduces the the sort of security model of web off end which I mean of course it does. if you are exposing your keys to or if you're exposing your keys or whatever it is your your uh yeah your web offing credential to other malicious websites.

Nicholas: that's obviously not good specifically the large blob. or because I mean sharing the public key is not I mean it's maybe not so private but there's not that much data there right.

Peter Ferguson: well yeah so the I haven't. actually I know there was a lot of uh back and forth about it but I haven't digged in specifically. but uh there are some people who know a lot more about cryptography than me that were basically very against cross origin in the current original suggested form and sort of. they've developed that over time so I don't know if those concerns have gone away or not but it has made it into the new spec anyway. um but yeah. so the whole the whole idea was that there is new payment um native payment layer on the web that is being developed through web off end. and yeah it's it's it's. what's crazy to me is that no one's talking about this in crypto and it's like we should. we should be all up in this. like if you look at the you look at the issues uh and look at the people who are developing this it's like a couple people from google no one on the crypto side and this could be transformative for crypto.

Nicholas: it's funny that you don't see more like. I would expect to see uni swap. you know some people from like an apple background or wherever else in fang.

Peter Ferguson: yeah coinbase coinbase should definitely be up in there. yeah. so I think I think there's the. the spec is still developing. so secure payment confirmation and I think it has been being developed for the past two years. but um all of the apis and stuff are like two months old. so I think there is definitely a lot of scope there to sort of dig in and see um whether there is some changes that need to be made for it to be applicable to a crypto context. but at the same time if we have r1 on chain we might not need any changes

Nicholas: and you want to specifically

Peter Ferguson: yeah yeah exactly if we can reduce if we can reduce gas where r1 is uh compatible or equivalent to sort of k1 and it doesn't matter um which curve you use it we might be able to just sort of co-opt the secure payment confirmation. uh for ourselves because it would just be a matter. it's basically. imagine uni swap was able to provide to your web offering credential here's the token I want to transact on here's the metadata about your slippage etc. how much it's going to cost you what you're expecting to pay in gas and that sort of normal on-chain normal data that you're expecting to sort of send through say walla connect and that they will be able to do that natively in the browser.

Nicholas: so you could just sign arbitrary data directly with a native api to whatever browser or uh or os you're on yep uh native api on uni swap uh with a discoverable credential of your wallet.

Peter Ferguson: so if i go to rainbow if i go to family i set up this pass key um with r1 at a reasonable gas price. or maybe you don't care about gas price if you're a wheel like that. but yeah so they will be able to sort of the user. the user authenticates on uni swap having been shown all this data. uh about what transaction they're. they're uh doing. and um uni swap will take your authentication and relay with family or rainbow or whatever or form and uh then they will confirm yes that was a challenge that was signed by you and they can just execute it straight away. so it would basically basically what i think. if this is being adopted nowadays and it is sort of applicable in the future where there is a cheap r1 i think uh walla connect and these embedded uh wallet companies should really uh maybe rethink their business models going forward. yes it's a huge change.

Nicholas: it does seem like um at the very least the wallet connected. anything that's connecting a separate software wallet to the context of the application dapp seems to be maybe a prosumer thing going forward if pass keys are gonna. i mean even in the worst case with the current pass key stuff. uh it still seems like a much better choice to use 7212 or or even an mpc solution or maybe some future mpc solution with less dependencies or even just straight putting the private key in large blob. a lot of options that make it so you don't need to wallet connect and don't need to bounce back and forth between apps. yeah. but what's interesting about what you're saying with the payment confirmation is that if the transaction data can be presented inside of the context of uni swap dot app or whatever the the url is then you don't need. you can have a cross. you might not need the separate wallet app but you also might not be stuck with um app specific wallets. you can start to get cross app wallets. uh with or without having an app outside of the original app that creates the pass key like you might not need rainbow either.

Peter Ferguson: yeah there's there's a huge design space there and basically the. the interesting thing about the the main interesting thing about the secure payment confirmation is that it actually enforces the merchant site so say uni swap to show the transaction details that are being that are being uh sent to the real importer. so that's one of the big issues that people have with past keys. it's like it just presents this sign in ui there's no sort of what. what am i signing the secure payment confirmation? in order for that to be relayed to the wallet you have to have shown the user this what the transaction metadata is and and so

Nicholas: and enforced by the us it's the authentic data they're going to sign

Peter Ferguson: exactly enforced by the user agents so enforced by apple except for they they won't. yeah exactly they won't let you sign unless it's been presented.

Nicholas: wow the dream. that's basically the dream exactly.

Peter Ferguson: yeah like there's tons of people working on this and work and i think well there are tons of people working on this in crypto and have been trying to develop this. and it's kind of funny to me that like just two guys from google who have no mention of crypto whatsoever in their in their uh specification or solving exactly what we've been trying to solve for crypto for a while a decade

Nicholas: and and the political sway somehow to get it through fighto too which is very cool. so okay we're gonna uh keep talking. i want to get to session keys. i want to get james back in here. we want to talk about aa stuff. uh but just before we do. uh it's time for the sponsor for this episode. today's episode is sponsored by my new project. i'm hiring a front-end dev with experience building high quality web3 apps in the evm ecosystem to contribute to an ambitious new consumer crypto app. if you're passionate about building popular self-custody crypto apps on decentralized blockchains for a new to crypto audience and you're looking for a job please dm me. it's nicholas with four n's on twitter. same thing on telegram. i look forward to talking to you and to talking about more smart wallet stuff and building stuff together. so tell me about session keys. what? what are the limitations on session keys?

Peter Ferguson: sounds like a question for james.

James McComish: yeah go on i can uh jump back in.

Nicholas: yeah what?

James McComish: what are an overview of past keys and all things? uh we have off the end though that was a nice one.

Nicholas: that was epic. thank you peter. that was dope. um yeah.

James McComish: so on the session key front like that was sort of one of the things that we thought was like very exciting from the very beginning of like you know getting involved with generally a kind of abstraction and the arc 4337 as well like a lot of our earliest users who were sort of like on this web web-based um data management piece that we had put up uh were actually interested in games right. so they were interested in actually like sort of teaming up together and managing some asset and just sort of moving quickly like throughout whatever they were playing and being able to swap things in a secure way and basically like the. i don't even think there was a single um sort of other option that they selected beyond just like sharing a private key. i mean like everyone we talked to just just shared a private key and it was just sort of. that's what worked at that moment and that's the best way that you could just sort of give control over the asset and let that sort of entity in the game play the game. um and it's just sort of crazy right. so it number one is um just like obviously very insecure and number two it sort of limits the the reach of these games as well like

Nicholas: i mean if

James McComish: if you're going to do this approach like you're only going to do it with the people that you really know and trust and it sort of like restricts the the sort of size of teams and things like this. so once we seen that um one of the sort of like selling points of 4337 was that you could like embed these session keys and let people sort of create. well not create. yes so sort of like create create um transactions based on some sort of predetermined criteria. uh we thought that was very cool and um. so the sort of the game fight use is the most like. maybe easy to picture but then you've also got other things if you just want to make like recurring transactions or um if you want to you know if you know like a certain amount of the treasury in the dow it is going to go on let's say like um bonuses to like key contributors and you trust like two or three people at like the management level of the dow to just make these decisions. and as they go then these are all the sort of like nice use cases where you can like perhaps have some session key control in some subset of the assets without the need to go through this whole like signature flow and like every time you want to do something because like as as Peter was saying like at the minute it's still still somewhat expensive um compared to like normal transactions. but in time if that comes down the signatures will go away. but it's still nice to just be able to like permission and sort of scope what people can do with with the dow.

Nicholas: so i guess there's two types of session keys. there's like I guess pass keys can have a kind of session that has like a duration where you only need to biometrically authenticate one time and have a period of like a session duration in that app. and then there's also sessions in the AA context which I think is what you're talking about. right like you can set up some different permissions that will allow certain types of transactions to go with a different threshold of signatures or something like that.

James McComish: yeah yeah exactly. so I was talking more about the on-chain one there and the the passkey one. I yeah I guess. so right you can sort of like authenticate in an app and then like the app remains open for some period of time. is that what you mean?

Nicholas: yeah Peter do you know any details on on that?

Peter Ferguson: I um I would only think that it would be possible with large blob. but uh because basically the way we use pass keys well actually maybe one of those npc uh versions could do it. but basically the way we use pass keys right now is we use the r1 curve to verify any user operation or whatever you want to do in the challenge of that. so you would have to sign in every time and but maybe one of these uh npc versions allows you to have uh access to the ea for an extended amount of time.

Nicholas: oh that might be. I was talking to um Vivian Fung from Snowball and she mentioned that it is possible to do this kind of like friend tech like experience for signing but uh which is to say no biometric authentication at every user op. but maybe it is actually being done at the lit uh level or whatever the npc level is. I'll have to ask her for follow-up. yeah yeah so so uh. so James tell me more about uh. so I guess one question is do you think we should jump into the session key piece also? but what do you think of the overall design of 4337? is it a good design? I've heard some people are a little bit critical of like paymasters or I'm not sure exactly what they're critical of. how do you think about the design? do you think it's a final good good good choice for us?

Peter Ferguson: yeah I think it does.

James McComish: uh it definitely does draw like some criticism but I think for what it's trying to do like it's trying to replicate sort of quite a lot of behavior overall. um and it sort of justifies like a lot of the complexity that that is there. like when you when you think about like account abstraction is like at a certain level it's uh like obviously extracting away like what an ethereum account is today. so that's like a. you know it's some like address on chain. it's got like a public key private key pair that that private key is what you do your sign in with and the address itself has like a. you know it's got like a nonce a balance and um it's got like no code right. and then what the sort of most primitive level of what you describe a is is sort of like let's not give it that private key let's give it some code and then

Peter Ferguson: that code

James McComish: can sort of be configured to to do sort of like smarter things and like sort of. this is the the idea of the smart account. and when you actually try to take a look at four three three seven it's not just replicating what happens on the account itself it's actually sort of replicating what happens on the entire transaction flow of ethereum right. so whenever you've got like a the the sort of current status quo is is you've got like a client. so it's going to be a like a wallet or adapt they're. they're going to um like format some some data get a signature from the user and then they're going to send that over some protocol at the minute like JSON RPC uh to some node basically like a sort of like rough rough overview and then that node is obviously going to um sort of execute this like check what gases gas needs to be used and then sort of like adapt the balances and update state. and when you think about what four three three seven is trying to emulate is actually that whole thing like it's the whole flow. it's not just the sort of. it's not just putting code onto some account and at the minute it sort of sits like the the wallet adapt is the same thing. but instead of getting that signature from from the private key like as you know peter described earlier we're not going to do that with some sort of like pass key credential um or just any other cryptography like anything at all. really like works at that point and and then when you're sending that like over the protocol it's no longer going to be like just RPC with like you know all the methods on that. it's basically going to be emulated by like the user up the user up or maybe like you could consider it like the the interface of the uh like standard drc4337 account. so you're you're now sort of like packaging up all of your intent and your your signature and like what you what you want to happen into this user up and sending it across um and then the node itself like the is as close to like a description as you can go. for like the analogy is probably just like the entry point right. so the entry point will then do the execution and it will deal with like refunded any gases and and sending the gas to whoever relayed this call uh like into the mempool and to put it on chains. so it's sort of like trying to replicate that same those three steps of the lower structure which is like very like native to ethereum on the application layer. and the only way you can really do that is to do like quite a complicated like uh complicated set of like contracts right. so it's not really like it's. it's not only our not only our see that you can just sort of glance in in one pass and just sort of be like yeah okay this makes sense you know like erc like um like 20 and 721 and stuff you just like you can look at and very easily be like. okay like this is obvious and you can implement it quite quite easily too. but with with 4337 it's like there are just a lot of different moving parts. um it's quite clunky and it kind of has to be because because of what it's trying to emulate. and um whether it's like well designed or not um i think yeah like it really it does what it has to and like as few as few steps as it can. you know there are a lot of uh like moving parts in there to do with like whether you're going to like deploy the account uh whether you're going to like get root through like response to the transaction with like a paymaster or you're going to like who you're going to pay back uh like based on the bundle and stuff like that. but i think overall it is is quite well put together and you know obviously the people working on it and thinking about it now are like brilliant devs as well. so it is sort of going the right way towards implementing a kind of abstraction in the like the reality that we live right. um so it deserves a lot of credit for that. there was obviously a lot of comparisons early on with like 3074 and whether or not this could have just been done at the at the protocol level um to to sort of implement like native uh kind of abstraction. and i think in that world like you know people wouldn't be complaining so much um about gas like there would be a lot less gas overhead if you were going to be sending transactions through that flow. but i think long term like the effects of going down to the 4337 route are probably going to be beneficial to to the industry like overall it has sort of you know like spawned basically like a like a sort of like industry of its own right. um you sort of get that with some with some ercs like they're. they're just like a sort of standard like um api basically to like interact with like the lower levels of of the blockchain itself. and like you get erc20 you have sort of like created uh like deks and stuff like this like 721 and 1155 with like marketplaces for sort of art um. and then maybe like 137 for like i think it's 137 say ens. um you know like these are all sort of like industries of their own and then not that many really get to the point where they have that impact. and i think 4337 really like it has because uh you know you've got like pimlico and candid and stack up and stuff here and i built in like quite cool infrastructure to support this and it's sort of like making people's lives in reality like quite a bit easier. so um i think that yeah there's always going to be criticism for something that is um you know trying to do so much um but overall definitely like. i think it's a good approach and probably not not permanent but like you know for for the foreseeable years like it's definitely the way it had to be done and i think there's a there's a lot of uh benefit to to continue to build on it.

Nicholas: yeah i guess one thing that i've been thinking about in terms of adopting aa in my project is that because you can send multiple you can construct a kind of more complex transaction that has multiple steps and different interactions with different contracts. you will be able to migrate people especially on an l2 or something where gas is not as expensive. uh if people if you do decide that you want a different implementation for the aa wallet and even so much so that you can't just uh swap out the proxy like the beacon or however you're implementing it you could just move everyone you know move a whole set of assets to a completely different implementation with a single operation but would still cost a lot of gas potentially. but you're not limited by the like say nft migration. today it's quite painful from an eoa to go from one eoa to another.

James McComish: yeah yeah definitely so. like the the the the recommended way of like sort of managing this for the first you know like year or so was always just to have it in like an upgradeable proxy. and um you know if the entry point was to change you could just sort of like quite quite easily um switch out the implementation that you're pointing to. and obviously you know some people don't want that they don't want any sort of upgradability. they're happy to just as you say uh take the hit and just sort of do a migration uh to a new wallet setup whenever it's done and which you know is is fine in itself maybe even like the the sort of um like feature set that you want in in your account at some point and i think that there's a lot of work being done on us at the minute can actually just be built in to to the initial design. you know there's this sort of push towards like modular accounts at the minute. um like six six nine zero zero is sort the the main example. um they're sort of coming out of like alchemy and it's sort of the image to make any account like extendable with some methods that you want to plug into it if you decide later on so you don't have to maybe do this like um switched on unless it's like some sort of major you know like security issue that you really want to just jump ship and go take your assets elsewhere. but there is like potentially a future where it's um you can just sort of extend your original uh account in a nice way that you don't need to to really do this obviously like safe and stuff and and argent had thought about like previous version of this with our sort of like module setup and where you can always plug in modules for for extended features. but it's it's sort of like the in in progress. basically what what way it's going to look like in future whether uh six nine zero zero sort of works and is a nice way to extend accounts or whether it gets like too complicated and people lose track of you know like what what their account can do. but i'm sure like um apps and stuff will will be able to manage that pretty well.

Nicholas: interesting i hadn't i hadn't heard of the six nine zero zero is that? uh do you think it's uh getting traction a little bit? or or it's very preliminary?

James McComish: i think it's still quite early on? um i first heard of it our first sort of like interactive with it maybe in like may maybe like april may um. and there were like previous versions of it like before then like where it was like very early on. but i think it is getting traction like. there's a lot of work being done from like a lot of different sides as well like uh rhinestone or a team that are very well involved um like obviously like sift. or they're from like the the beginning for this sort of like modular account structure that they've sort of always been been pushing but in a slightly different way. and and then um obviously with uh alchemy isn't it? yeah alchemy sort of like our their names are sort of on the the the author of it. so i think yeah it definitely has a lot of potential to continue getting traction and it does sort of solve uh a pain point that hasn't so much existed before like now that more and more smart accounts are coming through it makes sense that that we're trying these sorts of things to to extend the functionality without you know as you say having to do a huge migration.

Nicholas: yeah one other thing we didn't mention is uh key rotation is so much i mean it's just viable with a smart wallet in a way that it's not if you have a direct eoa so great if you are even if you're not directly compromised. but you're concerned you might have been just rotate the keys without moving any of the assets. it's not that complicated but super effective.

James McComish: exactly. yeah like um sort of like pass keys like different pass keys can be you know signers on your account um and like we started with like you can sort of scope certain things like maybe one one one pass key can provide signatures for one type of interaction if you want to limit like maybe the dot that you know created that pass key for for any reason. um which yeah it just sort of has some some added benefits too.

Nicholas: yeah i've heard actually that's one other justification people give for using npc i say in the middle but i'm sure they wouldn't appreciate that. but uh you can do permissions on the npc and it's gasless. uh because it's all being. i mean of course you've taken on this additional dependency but uh you don't need to do that computation on chain. i'm curious. you're clearly thinking about permissions and we can all imagine scenarios where you might want to have certain pass keys have certain permissions and maybe a threshold of them to do larger transactions or interact with other applications on blockchain. how are you thinking about permissions? do you think that it'll be mostly happening on the aa wallet or do you think something else?

James McComish: yeah i guess it really depends like if it is going to be like if you're going to be using it mostly as your own like private um account. i guess you're just going to want to to have as few as possible. you know if you just want to keep it simple you want to be in control of it and you want to be able to sign but also like keep it open for like some sort of like guardian recovery if you want to give people permission to do that. on the npc front i'm not too sure. i thought about it so much. we kind of looked at we. we looked at like an npc solution before we really dove into like 4337 like maybe a year ago ish but yeah i'm not too sure about it.

Peter Ferguson: from from that point of view i think uh oh i think all that. i think the permissions like the permission side of what you would be doing on chain is very small right like the gas cost wouldn't be that much of difference. so like pushing that it's a it's great to have this off chain because it's less gas like i mean you're. you're going to be storing a couple more keys and some metadata about what these keys can do on the contract. so it's not massive difference really anyway. and then what you send to the contract is sort of uh which key and what was signed sort of just falls through and that. so i'm not i'm not bullish on the npc.

Nicholas: yeah one thing that uh jose aguinaga mentioned on an episode a week or two ago is um which is actually a great episode for anyone interested in this subject we go very very deep is that you and maybe even other other guests mentioned this also. but essentially you have a state problem where if you're changing the signers or adding permissions on one chain you need to propagate those to other chains as well if you're planning to have a multi-chain wallet and especially if your signatures are domain restricted then you really get into this kind of exponential problem. i think maybe it was the obvious people also speaking about this. so that is one scenario where it seems like oh you know you don't want to have some straggling aa wallet that doesn't have the updated signers or or or even that. maybe like you know if there's i think i heard there's 900 evm chains now or something crazy like that. you can imagine the pain of signing for all of them.

James McComish: yeah cross chain like cross chain aa is definitely like one of the big uh like question marks. that sort of is outstanding. uh as opposed to like eos like it it makes um it makes life a lot easier when it's just like this keeper. um and that sort of cryptography works on both chains and that's fine. um when you're doing like sort of permission things like you've got like you know this this particular assignment can do this particular action. um yes obviously like if you're gonna want to do the same thing across chain then you're gonna have to deploy that to both. um there are sort of like pretty pretty like. well test. well yeah pretty pretty like widely known uh ways of doing it. you know like layer zero is it's around. there's like chain link as well um where you can sort of like relay these things. you can set up like your own sort of like uh contract and then you can sort of like relay that between the chains. but there's always like that sort of layer of trust in between and there's also just the inconvenience of you know having to fund this transaction to to go across multiple chains. but i think it really um it really applies more to the group accounts like a sort of large scale down like for the individual. it's probably less of an issue like yes you probably have to deploy the account itself across chain but the the actions that you're actually going to be taking on one chain on another might be very different like maybe predominantly like by nfts on one chain and the other is more for defi and one's is more for like voting and like sort of like fun governance style things and safe have sort of uh given this some thought as well. like they they wrote i forget i forgot the name um of the article but it was basically about like why they they don't really make a big effort to to match contract addresses across chain and it's basically just that there are too many variables. like it gets complicated to try to to try to do a smart contract account which has the same address and the exact same state and the exact same like permissions and signers and stuff across chain. at that point like you just have to consider that the the the accountant and the wallet is sort of like an underlying like sort of structure that all the rest of the user experience is built on top of. so it's more on the app. at that point like the app will just sort of display things in a convenient way it will uh start to manage like what assets are on what chain in a nicer way and someone posted recently on on twitter about this too like the i think it was maybe someone from paradigm and that just it's. it's such an ugly pattern to to like open like open an app and just see like 10 assets and it's the same asset but it's just on 10 different chains and it's just like. it's not like the best case scenario for cross chain. um like smart accounts isn't even good at the minute. so like i think they're just bigger. they're just bigger things to be concerned with sort of like in the reality that we live in for smart accounts.

Nicholas: yeah yeah there's that georgios tweet. that's uh that's worth looking at although it's challenging because they have different risk profiles. you know usdc on avax is not the same right. uh usdc on finance or whatnot?

James McComish: yeah yeah nice thought.

Nicholas: i'm curious. uh we're gonna get back to forum in a second. you've been very gracious both of you sharing all this uh knowledge. it's extremely helpful. i'm sure the listeners are really going to appreciate it. uh one last question on aa in general. do you think that there's something? uh that somehow there will be consolidation between paymasters and sequencers? can you foresee that maybe instead of paying i don't know i guess by conomy or gelato or two popular options for paymasters right now that we might go direct to base or whichever chains sequencer we're on?

James McComish: possibly right. i think it makes sense from like a technical standpoint that they're just like. there are maybe more more layers to go through than needed at the minute. um but whether or not like there's a there's a consolidation right right down to that layer or if there's some sort of like other marketplace above that where people can can interact and sort of like improve these things and possibly but at the minute there's sort of like so many popping up like every every sort of wallet provider almost is sort of like building their own like um building their own like infrastructure from from scratch almost and so i guess good for like decentralization at that point. but um how it will consolidate and like where it will go to um not really 100 sure but it's definitely a good question to follow.

Nicholas: peter any thoughts on uh how the players will shake out in?

Peter Ferguson: uh in the contract part of the aap's the the suppliers honestly not much more than james i think uh pretty much the scene have the same thoughts to be seen.

Nicholas: yeah exactly okay uh. so okay. so tell me more about forum. what are you building at forum? what are you currently excited about? what's the current version or what's coming up?

James McComish: yes so a bit about um. but we've kind of covered i guess at the beginning like background it was sort of it was initially an internet native way that we could actually manage like an investment club. um and then we sort of discovered dows and it was obvious that this is already a thing you know like early on. like they they provided us in a good way. but and we at that point kind of thought like okay right this has been done let's just use it. but in reality obviously there was still a lot of pain points there and it wasn't really working in the best possible way. so we iterated away sort um as i said like the web-based version to manage dao. and then you had like this sort of way you could crowdfund like an nft with some friends and and then actually managing as a dao just to sort of incentivize some people to to get involved and and then sort of like through the course of the last like seven months as we sort of dove deeper into kind of traction we we put together this sort of group wallet basically like this group ascii wallet. we were sort of first to get that launched on onto a mainnet. we got on polygon like earlier this year and at that point you know we kind of thought okay problem solved like that's it we're done. we haven't fixed accounts and everything's gonna be easy. and obviously that didn't happen. like people weren't? people weren't? uh like onboarding their friends all that much like there was a pretty big uh were you guys using it?

Nicholas: were you finding it useful?

James McComish: yeah i mean like the the past game was definitely useful. like we we had signed up we got like other people in the groups with us like it was a nice flow and like we were sort of chatting away like we still had the group chats in there and like the transaction flow for like proposing voting and sort of uh executing all in the chat like made sense. but at that point like group investing wasn't like at the top of everyone's minds like the people were sort of like calmed down with the investing front and we had sort of at that point realized as well that there's a much bigger like space that we can build into here. it's just about like investing like putting funds together and buying assets. there's actually just this uh this need to build on top of existing like multiplayer crypto experiences that are out there. you know like see if uh you could consider it. it's like a a way for people to get together and manage treasury. there's like partying party down stuff. um it's just like fun way to get together and like flip nfts. and there's sort of like different different. um if you go to the ui of party like you will notice that they are a world apart. right they're completely completely uh experience like it's conceptually a similar thing but it's completely different experience. and like if you're going to try to get someone in like the crypto for the first time or someone who's not

Nicholas: all that like

James McComish: if you're basically really involved in crypto the minute you're probably already like a complete DJ right so you're not always going to appeal to someone to try to like mentally grasp how these different things work. so we really thought about it and it kind of confirmed like our original thesis that building building sort of any uh like coordination experience into the group chat itself makes sense. like if you remove like you can change the safe ui as much as it takes to get to the party ui. but the underlying like principle is that these people probably still have like group chats right they probably still talk somewhere and they probably want to discuss things. and even if it's just share some memes and like sort of chat about these things it made sense to do it from the group chat. so we've kind of kept that aspect of things. so we really do want to build this up from the group chat. we want to let people discover and sort of join any sort of multiplayer crypto experience and manage it from like these soon to be xmtp group chats and and yeah i think like sort of summary of it is just to become like the home of multiplayer crypto so a place where you can discover any sort of multiplayer experience. you can connect with your web3 socials. you can discover like sort of what your like friends are ready to get involved with. you can easily get involved with them like just joining a group chat is like the equivalent of now like joining a dow or a party and and yeah just sort of build it on top of these existing web3 protocols and instead of trying to you know throw our like hat in the with another like multi-sig which

Nicholas: i'm very careful. let's say we were in a say for a party together in a forum chat and i am actually very tempted to try this. first of all it's a ios app.

James McComish: you said yeah and you know kind of like like very early alpha in in test.

Nicholas: right okay okay. so so you haven't run into the app store rules yet. no good good good i hear good things for for some people are very very bullish that 2024 eu is gonna jailbreak ios. so here's hoping. so let's say we were to create a party or a safe inside of or participate in one inside of the forum

Peter Ferguson: chat

Nicholas: would we be like each of our pass keys would correspond to a signer on a single aa wallet or we would each have our own aa wallets and each of them would be participants in the party or safe

James McComish: right? yes this this is sort of the the fork basically in the ux. yes it's a good point. it's anyone who is interested in this today has a new way right? it's kind of our it's kind of our take on it and i think it makes sense. like anyone who's going to be doing these things for the foreseeable like weeks the months has an e-away. so we've kind of uh we've kind of um like become more lenient on that. so you can actually like import you can import your e-away and sort of manage that like. that can be your account. so it's sort of like normal in that sense. and then for new users so like if a new user comes to the app then they get the option to like create this account and then at that point once we sort of start pushing into like a wider ecosystem that's that's when it will be passkey plans. so they would create a passkey and advice we would sort of set up a contract for them and then when they make their first transaction that would be deployed on change and they could then to sort of. that's their smart account even when they you know interact beyond form like they can. they can manage.

Nicholas: that got it okay very cool.

Peter Ferguson: just also central to that sort of translation as well is is our thesis on large blob too. so this week we uh we developed large blob directly into the app so that you can actually import your private key into the large blob stored on your passkey or just directly create a passkey with it and attach the e-away on the device. so if you have someone who's slightly interested in what's going on in crypto i don't know. maybe they're into trading cards and they want to get into some real world assets. you can sort of invite them into a forum group chat. uh with only face id this will uh create them a large lobby away account. they can create signatures on a safe and you can sort of dgen into some real world asset trading cards on chain together that sort of thing.

Nicholas: and so yeah extremely cool extremely cool. i i have to ask because i'm sure the audience is asking themselves if we want in on this test flight what do we have to do?

James McComish: yeah check out um i it's checked through into one of our uh one of our clients. um we will have forum linked. uh you can just go to the website. uh there's a there's a sign up there and so you can just like uh you can sign up and get on the wait list and there's a like couple of questions which you're like wanting to answer. just just give us a perspective of sort of like what multiplayer crypto you're currently using. so we just want to get a get a feel for like you know who's there and like who we can get on board first. um so yeah just just uh head through one of our profiles jump onto forum and uh you can check out the website to sign up.

Peter Ferguson: extremely just for clarification the website is forum.os.com. so that's forum as in a chat forum.os.com.

Nicholas: awesome uh and i assume it's mainnet only so far.

Peter Ferguson: well the advantage of large blob and being eos is you basically choose your uh chain and whatever you want to sort of interact with. but yeah basically right now as it stands we mainly do things through mainnet.

Nicholas: yeah i guess some of these players that you're aggregating like party are only on mainnet right now but safe is everywhere. so so maybe uh something to look forward to. i would love to play with something like this on base or on a cheaper chain would be a lot of fun to just i don't know mess around exactly.

Peter Ferguson: yeah i've seen john palmer tweet uh during the week that the party will be on base within three weeks.

Nicholas: so yeah oh really very interesting.

Peter Ferguson: oh that's exciting times.

Nicholas: yeah i think a lot of these multiplayer applications make a lot more sense. i mean really every application except for the most security demanding ones just makes so much more sense. you can be so much more frivolous on these other chains. and i think it was gammy um from nouns community out in australia who was uh talking about sort of the frivolity and playing on zora and minting things and and doing sort of sketch work and just having more light low-key experimental uh experiences that are not so deeply tied to like speculation on highly valuable assets feels feels like a really good fit for l2.

James McComish: yeah 100%.

Nicholas: so we talked a little bit about forum. is anything else that you'd like to tell people about forum or uh or what your ambitions are or where you think we're going? uh before we we call it today.

James McComish: um i think that's probably most of it like the current positioning of just like building on top of these protocols and trying to make like a fun multiplayer experience that that's sort of you know can exist today and based on like the sort of the protocols that are there. so if anyone um if anyone is building something that you know they think uh could benefit from being on forum uh let us know drop us a message and we're happy to talk about sort of like integrations and stuff like that. plan for the next sort of like set of weeks is really just to build that build out the safe integration first and let people manage a safe. so if you're if you are sort of like you know split between some apps talking in telegram voting and safe like signing in in like rainbow like let us know as well you're probably the person that we want to onboard to get some feedback from. so um yeah whether you're a protocol who you want like sort of to be built on bios or if you are a user of like a multiplayer experience and you want like an easier flow uh in either case just drop drop one of us a message and and we can talk

Nicholas: very cool. and does it make sense to play like single-player games directly through forum or do we always need some intermediary like say for party.

James McComish: um good question for future. i guess i mean you just sort of you just sort of at the minute connect your account. so it's sort of like an open space that you can always connect like your forecaster and discover other users like individually and maybe start chats with them. and but in terms of like individual like actual um interactions you can do with with other protocols like that's that's pretty limited. at the minute we're just sort of focused on on safe and then soon to be party and things like that. but definitely in future it makes sense that you can actually do things as an individual and discover things. uh as groups

Peter Ferguson: i suppose if you really wanted to try out some large blob stuff you could uh spin up a forum account have your large blob and then spin up a safe or something like that or a party by yourself and so yeah manage it with one key. but yeah it's not exactly what we're focusing on right now. i have a solo chat.

Nicholas: yeah i guess i was. i was thinking even on base for example like could i play friend tech as a forum? could you know without an intermediary safe or or a party? but i guess the answer is use safe. is the answer today?

Peter Ferguson: yeah pretty much and i seen recently enough that some i think it was uh ross from lexdown god what is it like? so it was yeah yeah he put out the other day uh a multi-sig that lets you buy friend tech shares as a group and so maybe we can integrate that and then you could sort of play about with with uh friend textures from a group chat.

Nicholas: very cool. i love how fast uh you two move. uh before we call it i wanted to ask you are you in belfast now? are you in ireland and if so or or even if not what is the scene like in ireland? is there a crypto scene?

Peter Ferguson: uh i'm currently in belfast. james lives in b Barcelona but yeah we we had uh east dublin a couple months ago. uh i wouldn't say it was huge. uh it was uh maybe a hundred couple hundred people maybe 150. i'm pushing it a bit. but yeah it's not it's not huge and i think there is a sort. there's a. let's just say we all fit in one group chat one forum for the country. i love it. yeah exactly yeah awesome.

Nicholas: so if people want to check it out it's forumdows.com. is that right yeah and uh i guess you're on twitter. also anywhere else people should check it out or docs or anything like that.

Peter Ferguson: we're it's mostly through the website right now and we talk a lot more on warpcast than we do on twitter. i would say so find us on farcaster too and a lot more details to the call there.

Nicholas: really awesome you want to shout out your uh your usernames on uh on warpcast or farcaster?

Peter Ferguson: yeah so it's just my dottie so it's peter ferguson dotties and on warpcast i am james dash forumdows.

Nicholas: awesome. uh guys this was a super amazing call. i'm extremely grateful for you sharing all this incredible alpha about web authentication and aa and everything. this is a great conversation.

James McComish: great thanks very much.

Peter Ferguson: yeah thanks very much super super enjoyable absolutely uh.

Nicholas: for all the listeners thank you for coming through and listening. uh later today i'm going to be talking to ria myers very famous blockchain artist and one of the ogest of og's in making art on the blockchain. was doing counterparty art back in 2014 maybe even before that. so if you're interested in crypto art uh come back again a little bit later today. all right james peter thanks so much.

Peter Ferguson: thanks thanks all see you all right.

Nicholas: hey thanks for listening to this episode of web3 galaxy brain. to keep up with everything web3. follow me on twitter at nicholas with four leading ends. you can find links to the topics discussed on today's episode in the show notes. podcast feed links are available at web3 galaxy brain dot com. web3 galaxy brain airs live most friday afternoons at 5 p.m. eastern time 2200 utc on twitter spaces. i look forward to seeing you there.