The Delphi Podcast Host and GP of Delphi Ventures Tom Shaughnessy sits down with Gregory Rocco and Wayne Chang, Co-founders of Spruce, an ecosystem of open source tools to enable user-controlled identity anywhere. In this episode, they discuss the importance of decentralized identities, how Sign-in With Ethereum works, the use-cases of cross-chain reputations, and much more.
- Spruce Website
- Spruce Github
- Sign-in With Ethereum and the Dangers of Big Login
- Thread on Single Sign-On
- Our Video interviews Can Be Viewed Here: https://www.youtube.com/channel/UC9Yy99ZlQIX9-PdG_xHj43Q
- Access Delphi’s Research Here: http://members.delphidigital.io/
Hey, everyone. Welcome back to the podcast. I’m your host, Tom Shaughnessy. Today, I’m thrilled to have on Rocco and Wayne from Spruce ID. I’m sure some of our vets will recognize Rocco, he’s been on a couple times. I think this is Wayne’s first appearance. How’s it going guys?
It’s going really well.
Going well and happy to be back for the 20th time on the Delphi Podcast.
You’re basically a cohost at this point. I think after five.
It’s going to be identity segment with Rocco.
Yeah. Delphi Podcast is going to be renamed Rocco’s Podcast by the end of this round.
Guys, you are leading Spruce ID. For those who don’t know, let’s do quick backgrounds. I guess we’ll just go on screen order. We’ll do Rocco then Wayne, maybe quick 30-second backgrounds, and then we’ll dive into decentralized identity.
Sure. Hey, everyone. My name is Rocco. I have a background in both communications and product. Worked for a couple of companies in the space, most notably the last one Wayne and I worked that was over at ConsenSys and now co-founded Spruce with Wayne here.
My background’s software and startups. Before this company and working for ConsenSys, I built a health tech company. I was the CTO and security officer there, so… And I saw a lot of real world institutions and how they connected and awesome having the chance to reinvent a lot of that.
You guys are Gs, you guys worked together at ConsenSys?
Yeah, we got started, I think like 2017, 2018 at ConsenSys is where we first met on a team over there, actually working on token economics at the time.
Yeah. [crosstalk 00:01:42] So in the graveyard of MATLAB models that didn’t quite pan out, we wanted to figure out what was causing a lot of failures. There were a bunch of things, scalability was one on the compute and storage side, but the problem that really fascinated us was identity. The canonical example I like to use is, if you have decentralized Uber, how do you know who you’re going to get into the car… How do you know before you get into someone’s car that the next 20 minutes of your life are going to be okay?
Kind of want a bit more assurance than a text, look and an address from a transaction or something. And figuring out how to understand that that person indeed has a clean driving record, has insurance, good reputation on the network. Those are the kinds of things that give people trust that they can step in. And once we have that, we can move towards a world where you don’t need an intermediary taking 25% of every transaction, but instead, you pay the gas cost for the network computation and you’re on your way.
Our takeaway was that in order for commerce to move decentralized, data also move decentralized. So we were spending the better part of our time at ConsenSys on that problem there, and now we kind of started Spruce to solve the same problem.
It’s pretty cool. Did you guys think about identity back in 2017? Like if someone’s going to solve this in the next year or two, it’s not going to be 2021, that we’re working on it from the start or what are your thoughts on it?
No, definitely. That’s exactly what it was. Identity is a very much a timing problem and the thing is, as we mentioned before, when you get to that decentralized Uber example, that’s like the golden goose. You want it to get there that we’re at this point where we have decentralized Uber. But in 2017, we weren’t even getting off the ground. In 2017, it was a contract address on a website that said, “Send some meat here and we’ll give you some tokens.” That was the extent of the space.
No, in this case now it’s a picture of penguin.
Hey man, don’t knock the huddle, man.
I’m a big fan of the puddies. But at this point, the thing is now that we’ve seen for the last couple of years, everything’s evolved. We have that demand side, we have a lot of users here, and we have users doing more complex transactions than just, let me make this one exchange. Now it’s like as deep as like, do these three things and then get rewarded with this. We’re starting to get more complex transactions, deeper transactions, deeper modes of interaction. That’s where the identity problem became useful.
The more you add identity to that situation, the more context you have about an individual, the more you can offer them in a service like this. It’s not just that public key anymore, now it’s a user. But back then like we’re were talking about in 2017, it’s like the most simple building blocks were just getting in place, but it was very, very important that a lot of teams were working on the problem at the time, like the uPort team, for example at ConsenSys that pioneered a lot of the really early efforts on decentralized identity.
It’s kind of crazy. The only way, I guess we touch it is, the way I’m seeing it is it’s like after the fact. We’re taking people’s degen score, which is the culmination of all of their work on MetaMask and all their on-chain transactions and the depth they go to, to give us a score on like how much of a degen they are. It’s like after the fact. What you guys are approaching is the flip side of that, you guys want to give people identity from the get-go?
How should we think about what you’re trying to provide versus something that people are familiar with, like degen score or something like that?
We want to give maximum user control. We’re user control maximumlists, and if it’s your data, you should be able to do whatever you want with it, including delete it in some cases, if you’re able to. Basically, instead of just rolling around on the public blockchains and that is your identity, your fingerprint of sorts, your actions on public maintenance, what if you could have more control over how you express yourself? Maybe you hold the cards, only you can see it and you give out the cards as you need to.
Getting the right kind of privacy elements so that you can build up the right identity per interaction. Maybe you want… A lot of people already have a primitive version of this. People will have public Ethereum addresses that they’re happy to attach to their Twitter accounts either through their PFP, they’re doxing themselves intentionally as like bragging rights or they are associating with an ENS domain.
And they manage this address very differently than a bunch of other more private addresses they have that they’d rather keep it a bit more private because it’s more like some of their financials instead of something that they want to socially interact with for us.
Go ahead. Sorry. I was going to say, for us part of that too is, a lot of the infrastructure or pieces we’re working on is like you’re saying that degen score, how do we take that degen score and make it portable across any chain? That someone could hold that degen score with them, present it at any time they wish. This is where we’re seeing modes of interaction going with like cross chain things. It’s not just like, “Come to my farm, get 10000% APY,” but rather you’ve had to do X, Y, and Z and demonstrate that even if it was on another chain to get 10000% APY.
These credentials are portable now, not just saying, “You could use it on this chain,” but rather it’s a cross chain context now is where we’re thinking with it.
Basically, you’re able to take all your degen score activities and you have a Degen Passport now that you can take to these various farms and get stamps at. And those can be used in a way that you’re able to be in charge of.
And from our end, it’s like the infrastructure side. It’s not necessarily, we’re doing kind of the, “Oh, this is what you need to pass, these requirements.” But rather we’re building infrastructure to make that possible and that’s where we sit in the stack of everything.
It’s pretty cool. What do you guys feel about… Before we go on to the technicals of Spruce, do you guys feel that the lack of identity is holding back, I don’t know, DAO movement itself? Think about it. Like when I joined a DAO, whether it be like, I don’t know, Squiggle DAO or what have you, people have power based on their social name. I think the way you guys are hopefully enabling this is that when people log on with their, I don’t know whether it’s a Spruce ID, I’ll leave the naming to you guys.
But when people carry that from project to project, that’s going to carry weight as if it were human level or? It’s hard to contextualize what decentralized identity looks like when you’re interacting with DAOs because it’s just so human and social right now.
DAOs are a great example of where if you had more sophisticated ways of managing identity, you’d be able to do a lot more. If you have, for example, like a worker DAO where people actually get delegated tasks and compensated for it, how do you know that someone’s qualified to be a scrum master or just keep the trends running on time? There are certifications that people take and there are other projects they complete around the ecosystem that indicate their ability to be a good project manager.
Same thing with developers, we see like developers successfully receiving Bitcoin grants and things of that nature. There are aspects of the identity that can be consolidated and then presented as almost like a job application to a DAO like, “Look at me, I was able to project manage this project for this similar DAO. You should consider me for this position.” So the more we move towards that, the easier it will be for DAOs to be able to delegate, to be able to have more complex structures.
Even in investment DAOs, how do you know someone’s good at technical diligence? There are probably some markers that they can use even from the Web2 world, GitHub history or things of that nature that prove the reputation.
And at the root of it all as a public key, is how do you tie this information efficiently to a public key? And in what context? So, as I mentioned before, Squiggle DAO might be a certain set of circumstances, how wavy are you? But in the case of like an investment DAO, it’s going to have certain requirements that are way different and certain like a trust framework that’s way different than like an artist skill, for example. Someone who’s writing content versus someone who’s evaluating an investment.
They’re going to need different credentials for different tasks, and the other thing about it is that we can tie just enough information to a public key to make that person qualified for the job. And in the case, that person’s not oversharing who they are. When you have to do diligence on me, do you really need all my government documents to give you more than what you need? Or do you need to know a certain set of facts about me to just say, “Yep, he’s qualified for the job”?
That’s good context. Just rounding out the discussion on the state of identities today, I think we see people use their… Some people are just straight up open, they’ll use their name, whatever. Some people use NFTs like, “Hey, I’m this Punk, I’m this Penguin,” whatever. Why isn’t that enough to you guys? Why isn’t, I’m Punk number 200, everyone knows me on Twitter, why isn’t that enough from an identity standpoint do you guys think?
It all depends on the use case that you want, because that’s going to affect the requirements for what you need to know about this person. Just because someone holds a Punk doesn’t mean that you necessarily think that they are a good person to work as an escrow, for example, or like what’s your fear about this situation and what information would you need to make you feel more of comfortable with that? One way that we like to phrase it is that there are transaction costs associated with any kind of transaction.
I’m not talking about like blockchain transactions, but striking a deal on something or agreeing into a business agreement, there’s always a trust portion of it. You find that when you have more trust in someone than… It gets a lot easier to do business with them. Same kind of thing, how do we mitigate the trust portion of the transaction cost so a whole new class of transactions are now possible? That is very bespoke to every particular use case.
It’s different in the Uber use case, it’s different in like letting someone be your escrow use case, a lot of things.
And the case of the PFP as well, what it does is it opens up a lot of users to the idea of an identifier, is that I am this Punk, I am this Penguin, I am this creature. It’s a good hook, especially for us that we’re in this weird space of decentralized identity, where for years we’ve been working on the problem and it’s just getting… the space is just getting the traction it needs to really make this an effective solution. When people look at these NFTs are like, “Okay, I am this Punk,” and that’s where it starts, “I own this Punk, therefore I am this Punk.”
Then we started to get credentials on top of that, and that’s like, okay. That’s the rabbit hole, so speak is that we start with this, even if it’s an ENS, for example as also a form of an NFT. That’s the first step in all of this that eventually leads to how do we go even deeper? I could be Punk number 6,000, but what else am I? And how do I get those credentials?
It’s also pretty messed up like somebody trades that Punk. If you build your whole identity around something and then I just buy it, that doesn’t mean I’m that person.
Yeah. Or if someone loses their keys in a boating accident and can’t access it anymore, then that’s really difficult for them and it’s a big part of it. Key recovery will be an important consideration too, but if you have another identifier, there could be a way to assemble credentials from a bunch of different places to target that new identifier, instead of the Ethereum address you can no longer access. So there are more sophisticated workflows possible once you can have something that says that I’ve done these things, or my reputation on this other network is this.
No, I’m totally with you. And just to round out the identity context a bit before we go on, because this is really helpful. Let’s go over to the centralized side. You guys linked me an article before the podcast just called Saving us from the dangers of big-login. How do you guys view the issues around Google sign in, Facebook, stuff like this when you’re thinking about decentralized identity as a comparison.
First I want to say that big-login has done an excellent job of basically providing login experiences for users. There is for about password buttons, many cases, it works for a lot of people, millions of people and you can’t deny that. But at the same time, there are people who just to be able to take more responsibility over their own digital selves. And we think that there should be an option for those users evolving, not your keys, not your crypto to not your keys, not your identity or your data.
And here’s the thought experiment if you were to lose like your Gmail account, how much access would you lose? It’s not just Google properties, it’s anything you use your Gmail account as an identifier for that would be very difficult for you to recover and re-identify yourself and gain access to that account again. Basically this is at the behest of another entity that may or may not be incentive-aligned with you all the time, but if it’s based on your keys instead, and you are adept at key management or you have a key management system, then there are a lot of directions you can take this. And that’s exactly what we’re working on with the Sign in with Ethereum project.
Yeah. Not a big [crosstalk 00:14:46]… Yeah I know.
Something I definitely want to echo too is like-
Rocco, go for it. Shoot.
It’s something I want to echo too, where that… I am probably also a big fan of [Vlof 00:14:56], I sign in with Google all the time even as someone who controls my own keys. I do want that forgot password button, I do want a phone number on the contact page to tell someone, “Hey, I’ve lost this.” Or, “How do I do this?” And that’s a great thing, but it’s that optionality is at the core of our philosophy, where it’s like a user can do this if they wish. They can take full control if they wish.
I think that’s at the core of it too, even with this space, it’s like, you can use centralized intermediaries and that’s totally fine because they provide great services and they take a fee for doing so because they’re providing a service. But at the end of the day, being able to take it in control in your own hands, that’s at the core of this, even with identity as well.
Do you guys view it just as like a security risk with… I love big-login, it just reminds me of big-lock for some reason. But when you’re thinking about big-login, is it just a security risk from your guys’ standpoint or is there also an argument here where it just doesn’t work with the Web3 world. I don’t want to log into a DeFi project with my Facebook login or with my email. I don’t want SMS or even if I take Google to the next level and I get tighten keys with advanced security, that just doesn’t work with crypto and DeFi.
Is there like an argument for you guys that it’s not just a security standpoint, but it’s just where we are and what we’re interacting with?
This is exactly why we’re focused so much on the Web3 ecosystem because really the UX is better for people who already have wallets. What happens if you want to access a file or something and you have a MetaMask wallet? Well, do you have to sign up with your email and password and then link it somehow and then figure out some workflow? Or can you just sign a statement that gets you access to a file with the same keys? And that is better UX in many circumstances for users.
Basically this is, we’re taking a big bet with Spruce on that the world is shifting into a public/private key world where everyone will have keys and be able to use them. And that part is a little controversial because key management is not solved yet, but it’s the same direction for a lot of Web3 projects and we think that’s the trend. Basically all our stuff works perfectly with public/private key pairs and we figure out ways to make the UX better for people who don’t have those, but we are betting on the ecosystem to help solve those problems as well.
That’s super cool, guys. We got to dive into Sign in with Ethereum because I have too many questions here. I don’t know who wants to give the overview or if you want to start with Spruce ID. I’ll let you guys take this one.
And a bunch of proposals were submitted, we were lucky to be selected as the winner, and we’ve been working on that for a few weeks now. Basically the problem that we’re trying to solve with Sign in with Ethereum is standardizing all the different ways that people are producing Web2 sessions with Ethereum addresses. For example, when you go to OpenSea and you go to your profile page, you can update your alias. Instead of displaying your Ethereum address, you might be able to an alias and a profile picture as part of your OpenSea account that lives on the OpenSea server.
But we don’t want just anyone to be able to modify your alias, anyone who connects with the wallet. We want only the people who prove that they have their private key behind that address to be able to update those data. So they make you sign a challenge request that says, “You’re signing into OpenSea. Here’s our terms of services and here’s a notice to prevent a replay attack.” More of a technical detail.
And then you’ll sign it and they’ll verify that you signed it and therefore you hold the key. And they’ll give you a cookie-based web session where you are allowed to update the alias and profile pictures and other preferences in your account that’s stored in OpenSea servers. This workflow is already pretty prevalent in a lot of, we call them Web 2.5 apps that strike the balance between a traditional one and really bases you on public/private key pairs first. So it’s already happening.
Our job is to basically coordinate the community and standardize what this looks like. Hopefully everyone on the application layer will adopt this when establishing sessions for their users. And a really powerful knock on effect is that we hope that wallet vendors will be able to point to that and say, “Oh, it’s stabilized to that.” We can support a better UX, so the user can really feel like logging in when we see this kind of message.
Because we have a very rigid technical description for what that message looks like for security reasons, for best practices, and also to give the wallet vendors something really easy to integrate. And we think that this is going to improve the fidelity of experience for the users who are logging with their wallets. And hopefully it’ll become an option like we were saying where you can sign in with Google, sign in with Facebook, but also sign in with the Ethereum if you want with your Ethereum address for the people who do want that level of responsibility.
And fortunately, the last thing I’ll add to this before handing over to Rocco, we are really focused right now on serving the crypto ecosystem, and that is really beneficial to our work because it makes the problem from extremely, extremely difficult to tractable. Because one big issue is if you’re trying to go mainstream with this is identifier reuse. If you use the same address everywhere, then people will correlate your activity and you might reveal things about yourself that you don’t want to.
Whereas a lot of crypto ecosystem use cases, people want to re-identify as that identifier because that’s how they present themselves socially, and they actually prefer that in many use case. Another important thing is key management is really difficult for people who aren’t crypto-native, but because we’re serving the crypto ecosystem, people have already figured out MetaMask, how to use ledger with MetaMask, all these other things. So we’re lucky to start with this tractable size problem, solve it really well there, and then figure out how to solve other challenges with respect to privacy, usability and things like that.
Yeah, I just want to add to the distinction there, maybe talk about web 2.5 and we think of Web3, it’s, I connect my wallet, I make this transaction, I leave. There is no additional information about that user, no need to collect information about that user, no need to establish a session. We talk Web 2.5, we have the OpenSeas, we have Gitcoins, we have Audius. We have something like Tally, we have… Anything that goes beyond just connect and make a transaction.
And like Wayne said, every one of these services is doing this in a different way. For OpenSea, it’s the term to service for like one inch exchange, they have the whole freaking disclaimer in the signature window. For Audius, it’s like an ID, for Showtime, it’s an ID. And first standardizing here is how we get started with all the public/private key pair users and these services that are already establishing sessions with users. And then the next hill to conquer is Web2, is traditional services. I want to add, this as an option.
The Sign in with Ethereum initiative is less focused on out of the Web3, like a Uniswap, for example, and more focused on the services that turn a public/private key there into a user of that service, and then they establish more information on themselves. Goes beyond just, I want to come here, make this transaction and leave. I want to land, I want to leave. I want to swap, I want to leave. It’s everything beyond that. Once we start getting into these richer applications in the space that are still decentralizing in different ways.
The content’s decentralized, streaming is decentralized, the downies are decentralized, that’s that kind of user that’s being targeted here because these services still have to establish a session to give them features beyond just come in with a public key and make the transaction.
Now, that’s a hell of an overview, guys. Sign in with Ethereum sounds super cool. Frankly, I just think it’s really cool from a UX perspective, just forgetting your password sucks. Like if I’m to sign in into my MetaMask wallet and I could just basically hit one click and log in without ever entering a password, from a dumb user perspective, it just seems so easy.
Yeah. And I think one more thing I’ll add is, ideally the world we want to move towards is one where you can make a new identifier per interaction that’s not correlated with any of the other identifiers that you’ve used before. You spawn a brand new one just for that interaction, and as Rocco was saying earlier, you fill it with just the information you need. That’s more, let’s call it the canonical definition of zero-knowledge, whether or not you use zero-knowledge proofs, you achieve perfect privacy for that transaction, then you move on.
And we think that’s the most respectful workflow for users that we would like to enable. In fact, Brave, the browser had a really good piece of research recently where they modified MetaMask so that when you click connect wallet, it would just generate a new identifier. And they did a bunch of hacks to make it display the right balances and everything, and lo and behold, it would be signed by your real key at the end of the day. But that way, you wouldn’t have Google analytics or anything tracking you as you are using a dApp as some dApps have deployed.
I guess when you hit… If somebody signs in with Ethereum, let’s say I’m on… I don’t know what the best example. I know Rocco, you mentioned maybe more social type apps. If I’m logging in with Ethereum, when I log in to Facebook, I use Gmail, I use my password and then Facebook stores all my data and gives me access to it. How does the technical model here work? Because I’m getting access with my Ethereum wallet, but the data is linked to… I’m just not sure where the data is stored and how my log in with Ethereum grants me access to that.
Usually how it would work in a traditional login system is that if you log in with an email, whether or not it’s email and password, or the email is forwarded to you from Google or some other service, the application will have like a database entry that has the user ID that’s yours, your email, and then your other stuff and maybe some other tables that are related full of your information.
But with log in with Ethereum, instead, what you could have is you would have an Ethereum address there instead of an email and your information would be tied to that instead. That would be the basis identifier for your login and that would be… You could add an email to that or phone number to that if you want for that service, but that’s all you start with in the beginning.
That’s fair. Rocco, you mentioned that it’ll be for more… What are the target apps are you guys seeing would be early adopters?
We’ve… Go ahead.
No, no. I was going to say, some of the early adopters we see, like I mentioned earlier, we’re talking with folks at Tally, talking with folks at Boardroom, Gitcoin, OpenSea, we’ve started those discussions as well to see if they’ll adopt the standard. Audius, we started those discussions. Everything right now that has a user base in that Web 2.5 category are the folks we want to talk to and talk about standardizing this with them in a collaborative effort. That’s where we want to get started.
The feedback’s been really good too. A lot of the engineers we talked to are like, “Oh yeah, we were thinking about better ways to do this, it just hasn’t been a priority for us. It’s great that y’all are doing this work because it’s really bringing a lot of the best practices from a security standpoint and also being able to be extensible to a degree such as adding more resources to the session.”
For example, if you wanted to actually link to the PFP you wanted to use for that session, for that service, we have a resources section where you can specify that.
That makes sense. I’ll ask a dumb question. Please don’t hate me, Rocco or Wayne, but just around this out like if a project launches and they say, “Hey, we’re just going to let people sign in with their public address,” or something like that. How dumb is my comment versus the complexity of what you guys are building? There’s obviously a big disconnect in that because I’m sure projects can’t just automatically implement something like this very easily.
What am I missing, I guess from the technical side there? I’m not sure if that’s a great question, but.
I think you’re pretty on the money though, you can implement pretty easily assigning request and check that the user did it and let them log in from that. The hard part is getting like 20 plus entities to agree on what that format exactly is and how to interpret it, including wallets that would want to make better interfaces off of it. Everyone has different needs and now it becomes a more complicated problem.
Yeah. That’s one thing I think I tweeted the other day. I was literally like, “Yeah, all the problems in the space are human coordination problems.” Wayne and I could have built this in a silo and been like, “Yep, here it is.” But it’s making sure that everyone’s going to play ball and it fits everyone’s needs, this specification we’re working on to push it forward. Because the implementation side, as soon as you have reference implementation and spec, it’s quite easy to implement.
It’s a matter of what’s going to be fitting everyone’s needs in the space? It’s all human coordination problems at the end of the day that we have on Zoom, Discord, all the decentralized services to coordinate and on these decentralized problems. But yeah, it comes down to literally, will you adopt it and does it fit your needs? Because if you’re evolving the way you establish a session with a user, let’s see if this will work for you.
No, that makes sense, Rocco. One thing I’m still a little confused on, and I know you guys spend all day here, so it’s probably table stakes, but Sign in with Ethereum makes a lot of sense from a UI/UX perspective. The identity component, I guess, is something I’m missing. If I’m signing in with Ethereum, I’m interacting with apps, I’m building up history, data points, trends, DeFi, what have you, how does that feed into an identity that either I can share or people can ping or test against or view? What’s the differentiation there?
With some of the work we’ve done on the product side, we figured out how to have Ethereum addresses make statements about reality like, “That’s also my Ethereum address,” or, “That’s my account on Solana over there.” Signed by the Ethereum address in a standard global format called a verifiable credential. When you access these different services, you tend to have very different perspectives or different identities used online. Like your Facebook identity is going to be different than how you behave on LinkedIn, it’s going to be different than how you behave on a Uniswap.
So a lot of the identities have your own silos and most people want this. But when you can have your different identifiers connect to each other selectively through these signed statements, you’re able to have more control over that data and just take all your data and focus it on just a point that you want, revealing nothing more than you want to. And being able to combine that is a lot of the goal for other projects that are open source.
Rocco mentioned earlier like the ability to share what you want to share, and Wayne, you just close out your example with that. I think that’s always been like the poster child for ZK examples. Like the ability to tell a cop that you’re over 21 without showing your identity and your address and everything like that. What does that look like from a UX/UI perspective? Is somebody going to be able to see the data points they’re sharing before they share it? Or how does that all work?
Yeah, that’s that’s the plan, and I think what a lot of companies in the emerging decentralized identity world are thinking of where it’s like… Again, it’s like a hand in poker where you see all the cards that you have and you can selectively disclose the pieces that you want to. It’s a combination of just not sending people information if you don’t want them to have it. And also you can use things zero-knowledge proofs to basically remix a set of information that has been signed into a smaller set just for that interaction.
That’s a lot of what we’re seeing, and I imagine that we’ll see interfaces for this and wallets that will support it in the coming future.
And that’s how we see it too on the UX side. It’s not going to be this separate wallet like, “Here are my digital assets, here’s my identity.” It’s going to be using that same wallet that you’re able to reveal this information like your hand. It’s going to be through a MetaMask signature that you’re going to say, “Yep, they’re requesting this, I’m all allowing them to see this information.”
That’s one of the core things that has evolved over time in the space is that the experience has to still live with the user in that one place, the keys that they control, that wallet that they’re very used to using. That’s not going to be this mobile, separate wallet that they have for this, but rather a blended experience. And these modes of operation that they’re already using in the space are going to be the same for doing this kind of data revealing, that they going to sign off on this.
And to tie it back to like use cases, we think this is how marketing is going to move to in Web3. Right now, all the liquidity providers and the pool get similar rewards and the pool will taper over time. And we think that there are more sophisticated ways of doing that. If you’re a really good LP on one platform and you can prove that, even on another blockchain or something, they should want to give you better rewards, if you are consistently in LP on that platform. That is just more efficient spending of funds to attract people to pull their liquidity there. And I think that we’re going to see a movement towards that.
No, no, that’s fair, Wayne and it’s a great answer, Rocco. And just to circle back, just to make sure I fully understand it, when you’re doing all the interactions with DeFi though, how does that link to the identity again? If I’m a power user in Uniswap V3 and I’m the most efficient person at doing it, how do I prove that to somebody who wants me to market make with all of their money? How does that work?
In the Uniswap example, you’re already creating all these breadcrumbs on-chain, that is your on-chain identity. You’ll see dApps like Zapper Fi be able to demonstrate that to you right away. And you would just have to demonstrate to someone that you actually hold the key for that account and they might be convinced that, oh, that is you. But if it’s another chain or another service or something, that’s much harder to check via smart contract or something. You might need to hold that in a trusted form from witnesses who signed off on it. That’s where off-chain credentials come into play.
Also if you have other aspects of your identity that are not purely on-chain, like we see a lot of airdrops now and we’re seeing the civil attacks on them. We’re seeing that on-chain activity maybe isn’t enough to make sure that we’re doing a good airdrop. Are there other forms of credentials that we can use that it’s not the same as asking a user just to fork over their passport, but something else to convince us that they’re a good actor and they’re going to be faithful to the ecosystem? Those are exactly the kinds of use cases that I think would benefit a lot.
To get philosophical for a second, a lot of people are pretty tribal in crypto. I think maybe less so now because you have like the reality of multi-chain future, it’s not like the Bitcoin versus youth days like Rocco and we used to have you on with that back when. It sounds like if you have a portable identity, you’re less tied into one community, because you’re not socially… Right now people are socially-tied into communities, but the way you guys are describing Spruce, it sounds like I could pretty much bring my history and my life to chain and basically start building.
That’s exactly what happens.
Yeah, that’s what we mean when we say user control Maxis. You should be able to do that, if you want to.
You should be able to bring basically as you want and as you want to show all your activity from all the chains you’ve used because let’s be honest, everyone’s starting to experiment with other chains, even with they’re EVM-based. Hey, I’m going to type in this different RPC, access this cool farm on Arbitrum with the pop-tart cat, because they got sick yields there. And it’s like, you want to consolidate all that, you can and combine that also with additional off-chain data.
It’s not just here’s my activity on Uniswap, here’s my activity on Serum and Raydium, here’s my PFPs on Solana and Ethereum, it’s also here’s my Twitter account, and pulling all that together, consolidating all of that together for different experiences. So it’s not just the on-chain activity, it’s the off-chain activity, but also tying together cross chain without some weird wacky bridging. More so, being able to attest from both trains that the activity is real.
And in our view, it should be one place that the user controls, even though it’s being consolidated, it’s not with a third-party service that can then use it for their own purposes, but rather the user that has ultimate incentive compatibility there.
Yeah, part of that too-
I’m sorry, Rocco.
No, no worries. I was going to say, part of that too, is you choosing your own identifier. So you want that base identity to be like your Ethereum account, sure. If you want it to be your Solana account, sure. Just using those as two different examples, but it’s up to you, what you want that kind of base identifier would be that you tie things to.
The base identifier I should think of is not one’s public address, but really one’s seed phrase you guys mentioned earlier or? That would seem-
It could be seed phrase, it could be someone’s public address, all those are possible. We write a lot of software to be able to bridge these together. Basically, we have this one open-source project called [Did Kit 00:37:06] where we’re able to represent a lot of the different blockchain addresses, as so-called decentralized identifiers. This is a new standard out of W3C. And you can basically represent accounts on Ethereum or EVM-based, you can represent them on Solana and a bunch of others.
And they can all be used in these digital identity workflows, where they’re assigning attestations, where the attestations are about them. And this is really useful because it doesn’t really matter what your identifier is, so as long as you wield a private key of some kind, figure out how to connect it really well to all the other things out there.
I guess the next question is, is there any way to change that down the road? Like, hey, my wallet gets hacked or I want to change it for X, Y reason.” Can I change by identifier or?
Yeah, this is going to continue to be a big problem, not just for identity, but also just the underlying asset management too on these blockchains. The direction that we think is very promising is multisigs, where you can start moving your identity or even your assets to a multisig and then you can start rotating out keys as you need to. A lot of the blockchains or all the blockchains we’ve seen don’t have key rotation, which was, I think a feature more than a bug because it really made the addresses easy to use.
But now that we have more sophisticated use cases, people are like, “How do we change out the keys from the down member change?” So there are use cases are starting to ask for right now.
That’s pretty cool. I’ve been thinking personally the whole time, but if Delphi wanted our own identity with Spruce ID, we could basically just use a multisig with some of the partners and drive our identity to that address, I guess.
Yeah. And I’ll mention that, Sign in with Ethereum works with a contract-based account, meaning a multisig. So you can actually sign in with a multisig theoretically and that would be fine if you rotate out the keys.
No, that’s really cool. Can you guys walk me through how the cross-chain works a bit? I know you guys just mentioned that the identifier could be on one chain like Ethereum, but how does it work if I want to use my identity on Solana or Polygon or Tezos or something like that?
Well, you might actually be useful to go over the Degen Passport that we may just to show how we use the tool like-
Oh, yeah. Absolutely.
… the Spruce ID tooling.
Yeah. With the Degen Passport that we built as basically a browser extension, proof of concept, we were able to link together three different blockchains and your attestation’s there, like you are a good LP and Uniswap, you control this Ethereum address, you’re a good LP on Serum or Raydium, and you’re able to just present this wherever you want. At the root of it, it’s a lot like transferring assets cross chain because you do need something like a witness network like most of the bridges have or something more clever than that.
Because you need people to be able to witness those events and it would be good if there were consequences if they lied. So that witness structure is actually a pretty important still. And the witnesses could all sign off on this credential for you. You could take it and present it, and the counterparty would be convinced that, oh, I trust this witness network. They just looked at the chain, saw that you had a certain activity, gave you the stamp about it, and you’re showing me that stamp right now. Okay. And that’s the trust model there.
I’m going over the example too, it’s like you choose what chain you wanted is that base identifier. In this case, I think for the Degen Passport example, you used like Tezos and we first approved through MetaMask. We talk about these blockchain accounts, issuing these statements about reality. Through MetaMask, we said, “Yeah, this is my Ethereum address. It’s the same as this Tezos address. Sign off on that to prove that using the MetaMask wallet.” And then for the Uniswap evidence, we used something like the Uniswap Subgraph to pull, “Yep, they have this trading history.”
And we prove that. We actually built for Sollet at the time, the Solana wallet, a same kind of signature method to say, “Yep, this is my Solana address and it’s the same as this Tezos address. Sign by that Solana wallet with the Tezos address in that signature of saying, ‘Yep, there it is over there. That signed statement issued as a credential.” Same thing with the Serum credential saying, “You have the Serum trading history.” We use Diffuse’s indexer at the time to pull that data and say, “Yeah, this was the trading history of this account on Serum.”
Same thing, sign using the wallet to issue that, say, “Yep, it’s also tied to the Solana address,” and that Solana address we’ve already made the statement that it’s tied to that Tezos account. Thereby tying all these chains together through these signed statements for these wallets. And that’s what the tooling did for us, is making the signed statements from these wallets because only that Ethereum key can sign off on the statement that, yeah, I own this Ethereum wallet. And in that message saying, “Yep, it’s also the same as this other account.”
Now that’s super cool. It’s also nice to know Degen Passport’s a real thing. I thought it was just example we opened with.
No, we ended up naming it that. There’s a couple other folks working on the same problem. And I know Kerman is working on the DeFi Passport with credit scoring and there was the Degen Score. This was just something we showed as a proof of concept, but it showed how you can tie three accounts together in history on different chains to one wallet and one identifier using these signature suites that we built.
I’m sorry [crosstalk 00:42:33]
Where things are really going to get exciting though, is you have these off-chain stop sign statements, and then you can stamp them on-chain for use in smart contracts. So if you’re like the member of a real world club or something and then you can stamp your membership next to your address in a registry on-chain somewhere, then you can have all this DeFi functionality or DAO membership functionality and anything else. I think that’s going to really increase the amount of Lego blocks that people have access to.
And one more thing I’ll just say on the last topic is that I think a lot of wallets are starting to look at cross chain. I think Phantom is, I think Tally caches, and a bunch of others.
XDefi, bunch of others.
Yeah. And they’re going to have to figure out this UX problem because it’s not very good UX when you have to click like I’m going to go from one chain to a different chain and everything changes. People want to see all their assets in one place, their balances and everything and be able to move them around and manage the risks that way. So in order to actually make a strong tie in to all these different accounts and also be able to just one seed phrase can load a bunch of them.
We think that these credentials that are sign attestations, two-way sign attestations, that’s my Ethereum account, that’s my Solana account. That’s going to really help build a graph of your accounts that only you can access and no one else. And it’s going to give you the UX that you need to use the wallet really well.
Yeah. And we say credentials, we mean like files. They’re like these tests on files. We’ve thrown around the word credentials a lot, but these credentials exist as these tests on files.
No, no. It’s interesting. What are the alternative realities where Spruce doesn’t exist? Is there like a dumb default option for identity that crypto might rally around that you guys would hate to see? I feel like sometimes there’s these cases where there’s this default thing that’s not that great, but people just run with it because it’s used. And I don’t know what that is with identity, I’m very, very far from an expert. I think this is my first identity podcast ever. But what do you guys think about that? I guess [crosstalk 00:44:46] alternatives?
I think one thing that would be pretty horrible to see is people putting personal identifiable information in troves on the public mainnet blockchain-
… which is everyone’s go-to. Like, “Oh, you need like a proof of phone number, publish a hash of your phone number and then a stamp next to it. The search space for phone numbers is not that big and you can instantly crack most of the hashes even if you solve them.” That is a horrible approach, I think for many reasons and I would not want to see that one. I think another approach is like bespoke data models for just the industry itself. It’s like limited to being able to delegate that, “Oh, that’s also my wallet.” A JSON file that only we can say that.
Meanwhile, we’re looking at global data standards that MIT, Berkeley, Harvard at the Digital Credentials Consortium are considering for use as how you represent educational diploma. We’re looking at the same standards that the WHO has recommended for COVID vaccination records. However, you feel about that, but they can be done in a privacy preserving way. There’s a lot of buy-in globally that this is a potentially a great direction forward to represent sign attestations. And we can connect that to blockchain accounts. Then there’s a whole universe of opportunities that open up and we want to see that grow.
No, putting KYC on a blockchain is so dumb. I don’t know why anyone would do that. But the other thing I want to talk to you guys about, and we touched on it a bit, is just the reputation via identities for DeFi and DAO seems like super interesting to me. Getting lower collateralization ratios or getting access to private pools that are whitelisted, or frankly, just getting rewarded in a DAO for the work that I’ve done without sharing who I am publicly is probably super important. How does Spruce play into those things?
We write a lot of the software that allows you to sign those kinds of attestations or even stamp those on-chain. One of the use cases that I think will just come up is compliant DeFi. However, people feel about that, in the U.S. at least, the regulators are taking a big eye over what’s happening in DeFi and there will be these, as you mentioned, pools with allow lists. You have to go through some process to participate. We think that some of the most privacy preserving way that you could do that is if you have a registry of address and basically a value stamped by someone who is responsible for doing the process.
No PI on-chain, just, did you go through the process? If you triggered AML or something, then they can subpoena that entity to give up the data or not. And hopefully, they’re very ardent supporters of the users. We think that might be one of the most privacy preserving flows for that. And basically, we would want anything involved with that to be open sourced and inspectable by the user.
No, that’s fair. I’m frankly more excited about reputation within DAOs and DeFi than I am with gated access. But frankly, we might end up in a world where that’s a reality, given where regulations are going, but I’m not sure yet.
Yeah. I’m more excited about those two personally, especially like cross cross game identities as well. We’re seeing a lot of intersection between gaming and also NFTs and DAOs. And if you get to a certain level in one game, how do you start out with more benefits than other game, especially if you were like a big spender? And being able to transfer that and have the right kind of formats be portable, that’s really what we’re trying to enable in more of our focus point.
That’s like the software side where the game signs and issues that adds attestations to that user, which is identifier. That’s what a software is enabling there, where the game saying, “Yep, this user was level 100 in this game sign and issue to this public key.” And that’s you at the end of that. You are able to then present that to the next game. This game said I’m at level 100 there, this signed statement by that game. And then they’re able to receive rewards based on verifying that claim that they’ve showed.
That’s actually pretty cool. The only real way today is to go on PlayStation or Xbox and throwing your bio, the ranking that you were and hope people agree with you. There’s no real way of doing it today, I guess, other than if people individually check your gamer ID per platform, but.
Yep. And this all comes back to that human coordination problem. It’s the largest problem for the identity spaces agreeing on the sign-chaired statements of a reality of these issuers in the equation and those who want to accept those as a valid form of identity at the end of the tunnel. And getting folks to coordinate say, “Yep, if you do, I agree. If you do have this level in this game, we’ll give you the reward,” but also having that game be the issuer saying, “Yep, this person is level 100.” And getting them to coordinate or finding ways around it.
But that’s like the hardest part about the identity space in general is that coordination aspect. We have to get issuers to issue these credentials because, Tom, I could say you’re the king of France, but it doesn’t make you the king of France. Sorry, but you need the issuers, the trusted issuers in this case, the issuer to sign statements and verifiers to say, “Yes, I accept this as a valid form, is a valid credential for this reward to be able to do this thing,” whatever it is. And that’s the crux of all this.
Is there like immutability with the issuer side? Like Call of Duty says, “You’re level 100,” that World at War, whatever. You issue that attestation is linked to my account. If they come out next week and say, “Oh, Rocco screw you. We hate you.” Is there any way for them to take that back or no? Are you not-
It depends on the issuance model. The model we like is you sign something and give it to the user, and the user can just take it wherever they want. And we actually built a storage system for this called Kepler, and Kepler lets you basically use your MetaMask or any Web3 wallet to sign off on these statements to write to your personal storage or not. And then you can also delegate access to readers to it.
We think that that’s the best way to have storage controlled by the user. And we call it Self-Sovereign Storage, the chicky term is the New S3, but the idea is that let’s let the governance happen in a smart contract where the user control’s a smart contract that has a list of hosts that are allowed to replicate the data. And as Spruce, we’re going for high security and being the first host in the user system, but we want at any time the user to be able to spin up their own instance of Kepler and add themselves to the list, make sure there’s a full replication, and then kick us out.
And then per the terms of agreement, we’ll have to delete all their data that’s perhaps encrypted anyway, so we can’t even access it. That’s how we want to see a user storage to be driven and the key being that you can use a Web3 wallet to access everything. The user would be able to control their credentials in one place and other things too, and be able to share however they want, instead of it being stuck with issuer.
That’s user deletion side. That’s like how the user can say, “Yep, I don’t want these credentials associated with this account anymore. I can delete these credentials from my storage using my wallet.” In the case of Call of Duty, they could even attach an expiration to that credential if they want it to. Say like, this expires a month from now, but for user side.
I should have asked you guys about Kepler earlier. I was totally wondering where people were actually storing their private files or sensitive media, that stuff. I should have ask about that earlier. That’s one of my questions, actually.
I was going to say it too, a lot of what we’ve seen over time working on these identity engagements is that identity has a different shape and size for every organization and company. For the NFT space, it’s greater authenticity. It’s how do I tie these social accounts to my public key for DAOs like we were talking about. It’s like, how do you do reputation? How do you know someone’s a scrum master? It is literally different and different contexts for everything. And that’s why this is also extensible. You see some patterns, but all of it is non-repeatable.
However, the one part about credentials that remains unbiased and unassuming is the storage of these credentials. They all got to go to one place at the end of the day, even if it’s your Twitter credential, even if it’s your scrum master certification represented as credential, they all arrive in the same place that just stores them as files. And that’s where that data lives, but like I said earlier, it’s all about context when it comes to identity, that one service can have one identity need that’s totally different from another. I’m talking like completely different.
We just work on the standard ways to issue these signed statements about reality, and then where to store them at the end of the day and where not.
Can people pick with Kepler? Is it IPFS or Filecoin or are we… Did you guys build this out yourself or?
Yeah. We use pieces of IPFS and the infrastructure actually. We use the content hashes and a bunch of things, we’re going to contribute some changes upstream over to the folks maintaining the rust’s implementation of IPFS. But you can think of it as your own personal IPFS cluster. It’s optional if you want to store it to Filecoin or Arweave, but those are like different data story. We want to let people eventually store health records in Kepler and feel confident about it. So it will rest on a cloud provider for now that we have a legal agreement with that they have to treat the data certain way and we have the same kind of agreement with the user that we’re going to treat their data certain way.
And if the user wants to open that up and replicate it to Filecoin or Arweave or Sia or any services out there, they’re free to and they can do that. But by default it starts like a private IPFS network, where they can confidently delete stuff from. When you share stuff on IPFS, it just gets replicated at infinitum to whatever IPFS node as asking for the data, that’s how it works because IPFS is the world InterPlanetary File System, it’s all one big file system.
But we’re trying to basically for the user, create that volt for them, so it’s not haplessly replicated, it’s replicated under the rules that they set and shared how they want, or even [crosstalk 00:55:04]
No, that’s really cool. I’ve spent a past life looking at AWS and Azure and stuff, and I’ve been years in crypto just waiting to find an alternative. Arweave has obviously done well, Filecoin’s done okay, but having like… Competing with AWS is just hard at scale, even the centralized compute side. So I think what I’m gaining for you guys is that you can still store it on the cloud, but obviously the user’s the only one that has access to that, whereas on Web2, it’s the application that has access to it. Is that good explanation?
Yeah. And we define all the authorizations around that data as well, so if the user wants to kick us out, for example, from being a host, they can and just point everything at a server in their basement and say, “Just replicate it there and call it a day.” But at the end of the day, the user is choosing where they want that data hosted, who could read, who could write, and all the authorizations around that data.
I always think about economic attack factors, but for you guys, if somebody were to hack or if somebody were to attempt to hack a Web3 social media platform or something, they wouldn’t be able to get our data? Because our data is individually stored by us on Kepler?
Yep, that’s the model that we would prefer, although the site might have their own Kepler Orbit. Orbit is the name for the Data Vault and store some shared resources there, but the idea is that, you’re pulling it just for the session every time and it’s stored with the respective owners. We use the smart contracts for governance, so who the boss for this data vault and that’s the root of trust, a smart contract that is controlled by the user and they can switch clouds if they want, switch providers, run their own, that’s the point.
That’s really cool. And I guess to close out the conversation on Spruce, how are you guys thinking about getting that more, getting that virality around it? You mentioned earlier that you want to get issuers… Or sorry, you want to get like projects to issue assentations, but how do you get this snowball turning here? Who do you have to convince?
For us we see a swarth of issues and we found the tools-based approach the best way to get adoption. Giving people the ability to easily issue credentials for their use cases and having excellent developer documentation. That’s how we’ve been gaining traction, really focusing at the infrastructure level. That we actually see as a loss leader for Kepler because people will have to store them somewhere, and we hope they pick Kepler, but it can be anywhere.
And if they’re already in a public/private key world, then it’s really easy for them to be able to store it there. That’s how we’re looking at use cases. Also, we’re about to shift the bones of Kepler very soon, open source happening in the open, but we’re thinking of things like save to Kepler buttons. What if you can save a video file to Kepler from something that you’d like to watch again. But services commonly take them down, could you save it to Kepler? And we would just charge for storage or you can also run your own server and replicate.
So there are a lot of experiments here to gain more traction. We’ve seen a lot of excitement. Rocco, you have something to add?
Yeah, I was going to say that that’s the two sides of Spruce. The Spruce ID set of tools for the signing and sharing of data, it’s everything around identity. And no matter what shape or size you want, that tooling is open source. You can create these ecosystems of identity where someone’s issuing these statements and is verifying these statements, augment whatever services in any way they want. And then the sharing and storage portion, where do those credentials sleep at night is kind of where the Kepler piece of the equation comes in. And those are kind of the two sides of Spruce.
And we’ve seen over like 10,000 orbits created by people who want to manage their credentials, mapping their social media accounts, DNS tech records, even GitHubs to their blockchain addresses. So we’re looking at these use cases and trying to build the best developer tools.
That makes a lot of sense, guys. That’s super cool. Frankly, just to round this out, the single sign-on or sorry, the Sign in with Ethereum, which basically is single sign-on is just so cool. Never going to have to redo a password, once I have my wallet open, I’m good to go. And frankly, people are securing their private keys, they understand how valuable they are because people are already cognizant of how much value is locked in there.
Now, they’ll be able to just reuse that to secure their obviously super important identity. So it just makes so much sense and it just clicks.
You know what? I never thought we would see someone with a picture of a cartoon monkey tweet out about the importance of using a hardware key storage device. Like 10 years ago, it’d be like, wow, that is the top most advice that a security professional would just hope people would understand, but they themselves wouldn’t think that people would actually understand that. But that adoption has been really, really great to see.
And just to echo that, yeah, you’re due to checking like saying the Squiggle DAO, just telling your average person on the street, “Yeah, the Squiggle DAO members are really into hard key management, these hardware devices that lock their keys and sign statements about reality just like…” That whole line… That’s why I love the space, it’s like, we could talk about this and we know there’s a lot of depth and breadth of what we’re saying.
And then as soon as we talk to outsiders and they’re like, “Whoa, what are they talking about?” But then they get a taste of it and then slowly fall in.
I think what you guys are doing is super cool because you can’t have like people half in. Somebody can’t use Coinbase, but have a Spruce ID. You have to have your own wallet, you have to be in crypto, you have to get it to really be able to interact with this stuff. And that’s big. It shows people that if they want a real decentralized identity, they can’t have asset basically.
That’s a good to point.
It’s kind of where we’re at now, is like that diagnose, that’s the conviction area is that you want the decentralized identity, you got to prove it.
But there be [crosstalk 01:01:07] and there will be more bridges, so they’ll be okay.
Yeah, no. And I’m assuming, since we have mobile wallets, people could interact with Web3 apps on mobile, right?
Yeah, absolutely. And even to the point about adoption, one interesting project’s called MagicLinks. We know Sean who runs Magic and he’s doing some great work of, if you log in with the MagicLinks account, you get a key that you can use. That’s a really interesting way to onboard. [Toas 01:01:39] also has a really interesting way to onboard users from their Web2 accounts, so the backwards of signing with Ethereum, sign into Ethereum with your Google account or a combination of your Google and your Facebook account, and you have like a multisig going on.
So you need three cloud giants in perpetual competition with each other to be certain that it’s decentralized for you. That’s another way to achieve it, which I think is pretty interesting.
That’s I went around it out to what I mentioned earlier, is that it’s about the optionality, so that we could have these two modes of operation. And that’s the offer is that you can continue to live and enjoy the services, which are great in my opinion that kind of take care of you. But you should always have the option to eject from everything and own and control everything where it’s like this philosophy of your keys with data. And that’s at the core of it, is that we can continue to have these modes of operation, but the optionality is what’s important that a user can have the self-sovereign mode of operation.
I know. It changes the way people or developers have to think about building apps. You have mercenary users, it makes it very easy for people to leave and bring their data and bring their identity to other projects. You literally have to build for the user because if not they will leave.
Data liberation front.
Yeah. It’s like a… What was more locked out when you leave? A Regclip?
A Regclip. Yeah, rage clip.
That’s fun. Oh guys, how can people get involved in Spruce ID? And I’ll ask you from a couple of different mediums. One, the investors of the room who want to learn more about Spruce and the tacticals, and then I guess, two the users, and then three, hopefully, the projects to implement.
We’re always talking to investors because they see a lot of projects and it’s really interesting to see the trends. So reach out to us [email protected], we’d love to chat with you. People who want to get more involved with the product or even give us feedback, the Discord is really active, so we’ll drop a Discord link. But all the Sign in with Ethereum work is happening there. If you want to have a conversation about our DevTools or use cases, we’re happy to go there. We have a GM channel so that you can say GM to us there. Those are all the ways that you can get involved.
I’m down to say GM on the channel. I wake up and just fire off a bunch of those. I need a bot for that, I’m sure it’s out there.
They was like an app that someone made where it crashed because there were like 10,000 requests at once to say, “Good morning.” It was literally just a feed of GMs the entire time.
Yeah. It’s like waking up every morning in crypto, it’s like 90% of exing out your notifications, just GMs at this point, but I like it. Wayne and Rocco, thanks so much for coming on, guys. Sign in with Ethereum is super cool. The fact that you guys are building both soft-sovereign identity and soft-sovereign storage at the same time is super cool, especially that you could bring a cross chain. You’re letting people carry this where they want to go and you’re really allowing developers to interact with people in a new way.
Definitely beyond my knowledge technical-wise, but I’m excited to read into what you guys have this weekend and check out more. And I definitely think other people should do.
Thanks for having us on. We appreciate it.
Of course. Thanks guys.
(00:00:00) – Introduction.
(00:00:39) – Guests’ backgrounds.
(00:02:55) – The identity problem.
(00:05:04) – The goal of Spruce.
(00:07:26) – The effects of identities on DAOs.
(00:10:08) – Why NFTs are not sufficient forms of decentralized identities.
(00:13:08) – The issues with centralized logins.
(00:17:16) – Overview of Sign-in With Ethereum.
(00:24:28) – The data management process of Sign-in With Ethereum.
(00:25:56) – Target adopters for Sign-in With Ethereum.
(00:27:10) – Technical integration difficulties.
(00:29:04) – What ownership of your digital identity and data looks like.
(00:34:40) – The portability of identities.
(00:39:08) – The mechanics of cross-chain identities.
(00:44:20) – Poor identity standards.
(00:46:23) – Reputation identities for DAOs and DeFi.
(00:50:20) – Immutability of the data.
(00:52:32) – How the data is stored with Kepler.
(00:56:54) – SpruceID’s moat.
(00:59:14) – Final thoughts on decentralized identities.
(01:03:08) – How people can get involved with Spruce.