Web3 Galaxy Brain 🌌🧠

Nicholas: Welcome to Web3 Galaxy Brain. My name is Nicholas. At the end of each week, I sit down for a Friday afternoon conversation with some of the brightest people building Web3. In this episode, I'm joined by David Silverman, project manager at Lens Protocol and Aave. Lens Protocol is a set of social publishing primitives built for the EVM and currently deployed on the Polygon network. David and I discuss the motivations for building Lens, its essential architecture and data structures, and the design decisions his team made when building this first iteration of the protocol. We chat about the power of data portability, the tension between social graph infrastructure and algorithmic discovery, and whether we would see front-end re-centralization atop Lens should the protocol gain traction. I learned a lot in this episode and came away very excited about the extensibility Lens provides to its users. I hope you enjoy the show. Hi, David. Thanks for joining me on Web3 Galaxy Brain. Welcome to the show.

David Silverman: Thank you for having me here. Excited to dive in.

Nicholas: Yeah, so today we're going to be talking all about Lens Protocol, which you're working on right now. Before we get into that, I thought we could talk a little bit about what your background is, what you were doing before crypto, what got you into crypto, and what your earlier work was before getting involved in Lens.

David Silverman: Yeah, so I got into crypto very early. I was in high school. I taught myself to code, and nobody was hiring engineers of that age, and DAOs didn't really exist yet. And a classmate of mine, Willie Papper, actually sent me the Bitcoin white paper. I got hooked, started mining, and playing around with that. Did a couple experiments with an older standard called colored coins, which were ERC-20s before Ethereum. Kind of faded around in and out, and then picked it back up again in the Ethereum days. Once Ethereum was out, 2017-18, building a few different things under a few different anons. Started really doing a bit more investing in business development, primarily working with Index Cooperative last, and their business development team. I was a PM at a WebT firm called Catchpoint for a while, and then I jumped over to Aave to lead their social products division, which includes Lens Protocol, the Lens API, and a bunch of other things that we have coming this year.

Nicholas: Awesome. Wow, you've really been around for a long time, and been involved in so many cool projects. That's really cool. If you had to put a year on it, when did you start working in crypto?

David Silverman: So working, I would say full time in crypto wasn't until about 2019, was doing it really while I was doing my other job, PM by day, really doing a ton of crypto by night.

Nicholas: I see.

David Silverman: But I would say I've been definitely always up to date and doing a ton of research in it pretty much regularly since about 2016.

Nicholas: I'm actually kind of curious about the colored coins era. That's like so far before I got involved in, really I got serious in 2020. Yeah. I don't know if you have any lessons from that era.

David Silverman: The idea, I mean, it was really trying to build the idea of tokens on top of Bitcoin. And so you had the idea of let's take these, let's take Satoshis and kind of color them individually and try to track them as they moved around the ledger and have that kind of be a proxy representation for some other token. That was kind of that. There was a lot of interesting stuff in early Bitcoin that eventually led to things like Ethereum and a lot of the stuff we see today.

Nicholas: Did the people who you were working with at that time transition into working in Ethereum or other Turing complete chains or not really?

David Silverman: I fell out of touch with most of them. We all kind of changed around identities a bunch. And so I believe a few of them are still working in the Ethereum world. I would assume almost all of them are in the blockchain today.

Nicholas: Crazy. And when you mentioned Willie Papper, is that the Will Papper of Syndicate?

David Silverman: That is Will Papper of Syndicate. I actually give him all of the credit for killing me all those years ago.

Nicholas: Crazy. Also creator of AGLD, some people might know. It's so interesting to me to see people who meet at different points in the history of this growing, I feel even calling it an industry, it's kind of underselling it. But this whole social thing that's happening in crypto, it's cool that he both killed you and then now you're both doing such cool projects that are so relevant to me, someone who's relatively new to the scene. It's very cool. So I guess let's get right into Lens. People want to know, WTF is Lens Protocol. What's the point? What is it?

David Silverman: Yeah. So Lens Protocol is a brand new decentralized social graph protocol from the Aave companies. The way I like to describe it is a social graph is kind of this database that powers social networks and other experiences that depend on this data structure. The closest example we have to Lens ironically is Facebook to a degree. Meta owns Facebook, Instagram, and WhatsApp. And each of those applications, I almost call it, they're like a read-write client for this kind of underlying common database, the Facebook social graph. And so when I'm connected to Instagram, when I'm using Instagram, that application Instagram still knows everything about me and all of the data that, you know, Meta has across all of its applications on me, but it's choosing to use a, to display a moderated experience of just images and videos. And the same thing when I go to WhatsApp, it's a moderated view of just messages and, you know, same thing for Messenger and for Facebook proper, it's a moderated view of kind of all sorts of content. But the application itself has access to everything. And because of that, there's some benefits. I can post once to Instagram and Facebook. They really try to prompt you to use that a lot. Messenger is interoperable with Instagram DMs and WhatsApp as well. And there's certain benefits to being on this kind of same unified system. But the downside is Facebook actually is in control over my data and it's not interoperable outside of that kind of realm. And the idea with Lens is we can kind of replicate this idea of Facebook's kind of global storage base, but we can change the rules a little bit. We can make it so that it's a user owned graph. The actual points, my profile, my followers, my content, live as NFTs in my wallet. And so I have to present them to an application via signing with Ethereum or Connect Wallet for that application to know who I am and what data I have. And so it can generate an experience. But fundamentally, I am the one who has that data. I keep it, you know, I don't like to call it a wallet, even though it's what we kind of call our accounts. I almost think about it like a backpack. I take my bag of data to the application to render the view. Additionally, because it's not owned by one company, owned by users, any application can be built on top of this social graph. We've seen a lot of really great innovation in the social space get stunted or companies kind of die out because they weren't able to have the network effect only to see their innovations put in these larger companies. We're talking here on Twitter spaces. Clubhouse was really kind of first to the format. Meerkat was one of the first to do live streaming. And yet we ended up really with Twitch and YouTube. And so I think that there's a lot of really great things you can do with Lend. And the benefit. again, it's all on chain using all of the kind of the really great tooling. And that makes it interoperable with existing DeFi, NFTs and other Web3 tooling.

Nicholas: - Okay. I want to get into like how the actual mechanism works. I know there's these profile NFTs. Maybe one quick question up front on that. Basically, you must sign with the wallet that owns or created that profile NFT in order to sort of attach more content to that NFT. Is that the basic architecture?

David Silverman: - So the architecture is you have a profile NFT. And for those who have developed a bit, it's very similar to ENS. I have a handle. For me, I'm @DavidEV.Lend. I have an area where I can put metadata. So I could say that my website, DavidEvanSilverman.com. My job is PM@Aave. My location is The Metaverse. I could also say my Ethereum address is whatever. But the kind of two interesting things is we have an array that is append only called publications. And that is where publication objects, which is content I produce, is stored. And I have a pointer to a function called follow module. And a follow module is a function that runs and it gives me a Boolean answer, true or false, and it decides whether or not a follow NFT is minted to the person trying to follow me. And multiple profile NFTs can live in one wallet in the same way that I have DavidEV.Eth, the account I'm talking to you now from as my kind of more public facing account. I have a few other accounts that I like to ship posts from. And so that allows me to have optionality of which account I actually bring to the application. I don't have a default account.

Nicholas: - I just wanted to jump in. When you say there's this append only array of publications, where does that live?

David Silverman: - So that lives inside the profile NFT. So yeah, the profile NFT actually contains the publications in an array structure.

Nicholas: - So the publications are actually being written to the chain and to give context, it's deployed to Polygon currently.

David Silverman: - So yeah, we're on Polygon POS. The publication object is actually really just a bunch of pointers. It's got an ID. It has a reference back to me as the originating creator. It has arbitrary metadata I can fill. And it also has a content URI. And that content URI actually tells you where the content lives. We don't enforce in Lens Protocol. One of the key design principles we chose was being as agnostic as possible and allowing everything to really be future-proofed. And so Lens Protocol does not actually enforce any storage mechanism. You could have that content URI point to IPFS, ARWeave, Ceramic. You could even point it to an S3 link if you want to have the ability to really easily delete the blob over there. And so Lens is really just a system of pointers that kind of define how social data needs to be structured and kind of relational on-chain.

Nicholas: - If people want to play with this while we're talking, can they claim handles yet or it's sort of in private beta currently? It's not something anybody can play with.

David Silverman: - Well, you can play with it on testnet. If you go to doc.lens.xyz, we have all of the testnet deployments over there. You can also go to testnet.lenster.xyz, which is a community-run front end that is fully integrated with the LongLive testnet. And anyone can mint on Polygon testnet. For mainnet, we are doing a slow rollout. And so currently people who signed our open letter before May 5th should be eligible to mint as well as anyone who participated in any of the hackathons we hosted with our great friends at ETH Global and I think all of our early partner projects and actually the top 250 projects that received the Gitcoin grants from round nine through 14 also received the ability to mint profiles. We will be expanding that list very soon and we hope to go full permissionless minting shortly. We're just waiting for a contract upgrade that's currently about to go into audit.

Nicholas: - Okay, so people can play with it on testnet if they're interested. I played with Lenster a little bit before. So one of the basic consequences of the architecture you're describing is that you can have multiple interfaces for the same underlying data, which in some sense belongs to the creators of the content, the owners of the NFTs. So I played with Lenster, which is one such interface and the experience, I think it would be fair to say it's quite like Twitter in terms of UI, except when you go to post, you're asked to sign a message in Metamask or whatever wallet you happen to be using and you need to be on the Polygon network. So I guess there's like a domain or something in that signature also likely. So when I sign that signature, I'm not actually, or I don't believe, I hope I'm not spending any Matic as far as I know. So is the Lens protocol sort of backing that piece of it for now and putting those signatures on chain?

David Silverman: - Yeah, so a key thing we thought a lot about is part of our design, another one of our design principles, mission of being agnostic is we try to do user, you really think user centric. Consumers of Lens protocol are applications, but applications obviously have users. Anyone can go and call the contract today and you would get a standard Metamask pop-up and pay for gas, et cetera. But we also built in a couple of different levels of gas lists that each kind of have their own security considerations. The first one being everything supports meta transactions. We have these with SIG functions that allow you to exactly as you've experienced with Lens. there, I sign and in the signature, it has all the data required to do the transaction. It gets passed off to a relayer that actually pays for the transaction to go on chain. And there is a censorship concern there. The relayer can decide not to post a chain, but the trade-off is you're not paying for gas. The other thing that is currently in the contracts that I don't think any of the apps are taking advantage of yet is dispatcher. And so similar to, I would say like ERC20 approve or 721 kind of has that approved? where you give OpenSea the ability to manage your NFT. With dispatcher, you can specify another address to pay actions on behalf of your profile, but not transfer it. So they can post on your behalf, they can follow on your behalf, anything that doesn't require the actual transfer of funds. So you can't collect and you can't do follow modules that require payment.

Nicholas: - Very cool, okay. So the first natural idea would be like multi-user account, a social account that multiple people can post to. I imagine there's lots of other things you could do giving that permission to bots and things given that there's this safety measure that they can't bend money or interact with modules that have payment function. That's pretty interesting.

David Silverman: - Exactly, it's a big thing we've looked at and I don't think it actually hasn't, you know, the community has really actually built further than that. These are profile NFTs, these NFTs can live in any address, not just EOAs. and we've seen in the repo some people have built, you know, almost a Gnosis-esque structure called shared account that you have an admin and you can delegate out people to post with varying levels of permission or queue posts that require a moderator to approve. and we're starting to see kind of the fundamental creation of almost like DAO native accounts. One of the biggest risks for a DAO is if I give you access to the DAO's Twitter, you can kind of just walk off with it. Twitter doesn't really have this kind of great mechanism for return and we can now kind of treat DAOs and organizations as first class entities with these kind of smart contract permissions.

Nicholas: - So you mentioned earlier this idea about, one of the things that Lens reminds me a lot of is in the early days of Twitter, there was a sense that Twitter could become almost like, if you imagined it, the API, if they had, rather than closing down their API, instead opened it up to the developer community that was pretty excited about using it for all kinds of use cases, including bot activity, which is now marked and distinguished in some cases in the interface. However, they chose to close things down. They made like. Tweetbot was a great superior iOS app for a long time and they basically made their lives impossible by limiting how many tweets they could, you know, they basically couldn't implement a search function because of the limitations of the API. They had trouble onboarding new users, et cetera, caused by these limitations of the API. But I don't know if I have a great mental model for a social protocol as opposed to a social platform. Obviously, there are things like email and different kinds of chat protocols and things. I used to use Adium back in the day, which was a Jabber app for Mac, I think, which maybe has some similarity, some echoes reverberating in Lens. Given the rise of like current social network, like let's say TikTok, it sort of doesn't matter whether it runs, Trump made them run on Oracle or whatever. It doesn't really matter what the backend is as long as that algorithm and that interface and control of that relationship with the user through the interface, that's really where the power of TikTok is, it feels like. So I wonder what the dynamics are like when the interfaces are separated from the backend infrastructure in the way that Lens is proposing. Do you have any thoughts on that?

David Silverman: - Totally. And as somebody who has tried building with the Twitter API back in the day, it was very frustrating, especially as they locked it down and forced that upgrade. I would say the mental model I kind of use is that all of the features in Lens, right? Lens is just kind of, it defines how the data lives and how it is relational. And it's really the consumers of. it are really applications. We've mentioned Lensster, there's the other ones live today are Temper Messenger by Iris, Favor, which I can see is actually listening in right now, Clip2, which is a non-chain cameo and a few others. They can implement whichever features they want, whichever experience they want, whatever algorithm they want. They can choose to make things gasless or not. They can monetize how they see fit. The key thing I kind of think back to is they are beholden to users and the users have the ability to move that around. Social apps fundamentally are distribution platforms for creators and ways for users to exchange content. If we think about TikTok, the example you gave, I can see Bradley, our growth manager, he's in the space right now. When he worked at TikTok, the number one question he got was how do you get my video posted back up? Or how do you get my account unbanned? And that's not something with Lens. The data lives in the chain. I could go to another application and my content is there. It is content and data that I'm bringing to the application. And so I think the market dynamics are going to push these applications to be more interoperable and to respect users' decisions and provide more optionality. They don't have to, but that functionality is there and I believe the market forces will push that to happen. It's Twitter if the firehose was turned on. I think many of the complaints we have with modern-day social networks is the fact that they are both the database, this kind of backend protocol, and the app layer. That's really the issue. We don't see a lot of people complaining about email because we know that we could relatively easily, if you're on a custom domain, switch accounts and use a different provider. I don't have to stay locked into Gmail. I can move over to Outlook. I can move over to Yahoo Mail. I can go to anywhere else. I can run my own mail server. I think that's the optionality Lens gives. As a creator, I can use a platform that's really tuned towards creator tools. It's an interface that is really great for allowing me to perfectly edit my content and add in monetization. As a user, I can consume from an entirely different interface. Maybe one that's optimized to how I like to consume content or one that's designed to give limits that doesn't have those positive feedback loops that trap me for hours. I can still interact with my creators regardless of what platform I'm on and my creators can reach me regardless of what platform I'm on.

Nicholas: This is very interesting because I want to cut it this two ways. One way is, I mean, take the Gmail example, for instance, the protocol is interface agnostic, application layer agnostic, but if you actually want to escape the watchful eye of Alphabet, you really can't because so many addresses are Gmail at this point that even if you run your own server, your emails are being tracked as soon as you send them to anybody just about they're being caught by the web of surveillance. So if Lens, let's say Lens were email protocol or Gmail was built on top of Lens, there could still be like centralizing platform dynamic atop. One way you could put it is like whether or not AWS, it's actually a centralized thing, but like nobody cares what the underlying infrastructure is because we're trapped in the additional data that's piled atop the default features provided by something like AWS. Do you think Lens have, I don't know if that's something you can even defend against really like the application layer privatizing something that was like a public good or non-existent on the protocol layer?

David Silverman: I mean, I think that's a risk in any of these systems, right? We've seen it with Ethereum almost that anyone can run a node, but I guarantee everyone here is probably using MetaMask stock. So you're using Infura as your access or you're running an alchemy. Very few of us probably run our own nodes and there's a centralizing agent that way. If all of a sudden Infura decided to censor my app, it just wouldn't transfer anything touching my smart contract. I'm going to have a very bad day. And so I think it's very hard to protect against that. I think though that again, market forces are going to require it. And I think we've made certain decisions inside of Lens that have also could kind of defend against it. By default, everything in Lens is public. I think you may have noticed that and I think it's actually kind of caused an interesting dynamic with early posts. There's no delete function. I said that the array was append only. Part of that was a few reasons. First off, we don't want to force a certain type of privacy. That's going to require I don't want to pick the encryption scheme for somebody or what encryption algorithm is safe that we will even letting the application layer dictate that. And we've already seen various different options. So we didn't want to force storage. We've seen people integrate with lit protocol, unlock protocol and several others. And we think that's we're going to see some of that where again, there's going to be market demand for applications to be interoperable. And there's going to be different privacy standards and encryption standards that are set. I think if anything, lens will drive kind of more consortium as opposed to kind of single centralization. At least that's my view. I think it's very hard for a protocol if it wants to be open to protect against centralization.

Nicholas: Yeah, I agree. It's a difficult problem. As soon as you're open, you do naturally open yourself up to the existence of value add features that have different politics about their execution and availability. And if the underlying infrastructure is good, it will both be proved out by interfaces that have potentially and likely, in this case, have a network effect around their interface. that would be, I would think the primary motivation for people doing a professional front end would be in order to attempt at some form of centralization where they can extract value. Obviously, there will be purely open source and other cool interfaces too. But the team of people who are financially motivated and have a growth dynamic around financing their operations will naturally want to capture some value somewhere. It doesn't have to be negative, but actually, that's interesting. Do you think of things like, say, crowdfunding? Is that something that would happen on top of Lens or more integrated with other contracts on the underlying EVM chain?

David Silverman: It can be both. I think Lenster actually does support crowdfunding now. The Lens contracts are super flexible and through CollectLogic, which is adding monetization to publications, I could do a post out here that was just like, "Hey, I am Nicholas, and I want to fund this galaxy-breaking podcast. Here's the publication. You can collect it for 2matic, and you're going to get this kind of receipt NFT, the Collect NFT.". That may or may not give you things down the line, almost Patreon-esque, but there's built-in monetization that way, and that could be used for crowdfunding. Again, these structures, the Lens graph, it's slightly structured data. It is up to an application layer to interpret that data. I think the same thing with even regular contracts. We could build a system that defines crowdfunding, but without a UI, it doesn't really mean anything. I think UIs give a lot of context and actually how users really interact with stuff. Whether it's Lens or something else, I think you said at the start, I don't really know if an app or care if an app is built with AWS or Google Cloud Compute. What really matters to me as a user is what's the interface and what are the feature set being brought forward.

Nicholas: Do you think of Lens protocol as a pure public good and whatever happens on top of it happens on top of it, or is part of the goal to, well, is there any sense of value capture at the Lens protocol level, for one, and for two, is there a sense that it's important that the design and execution of applications on top be sort of guided towards felicitous public goods models?

David Silverman: I think the felicitous public goods, that's kind of the philosophy of it. That exists on the social layer. Again, I always go back to Ethereum proper. We are very, very lucky that Prism is a team dedicated to public goods. They did a user-first design and built a staking interface with a web client, and that was why they were the dominant staking software for the longest period of time on the consensus layer because they went with user-first design principles. Now, we are lucky that they shared the social principles of, we believe, in decentralization, and I would say I hope that Lens becomes the backbone of all of Web 3.0 social, and that is my philosophy and that it becomes this kind of public good for everyone to build on top of, but my philosophy is not what may end up. I would also say there is value capture options. I think it's similar to the Uniswap model. There are the ability for fees to be accrued to a treasury, but those are all off by default, so there's a fee that can be charged. if you're monetizing your follow, and if you're monetizing content, there are treasury fees, and I believe there's a cap. I don't have the documentation in front of me, but it is all well-documented, and in the mainnet deployment, all fees are set to zero. That is for a future governance to determine later on.

Nicholas: and when you say mainnet, you mean the Polygon deploy?

David Silverman: Polygon mainnet, sorry. We were on Mumbai testnet, so testnet mainnet, yeah.

Nicholas: Totally, totally. The other way that I wanted to cut to this question was perhaps it's opposite or complementary, which is like, do you think that the, there seems to be a premise here, which is like data sovereignty means not being, a lighter version is the Facebook example you gave of? only Facebook is able to build products like Instagram and WhatsApp on top of the Facebook data, and really that data should belong in the hands of the people creating it who can then be allowed to migrate from interface to interface and open up a renaissance of social interfaces atop the same protocol that don't have lock-in. The other question I asked is kind of like, okay, but can they not establish lock-in? And I think the answer we've come to is like, well, better to try, and maybe they can than not to try at all. But at the same time, is the data structure of the protocol itself not perhaps the true lock-in? What makes the design choices that you made, in your mind, the appropriate ones for the future of this kind of protocol versus like those choices also being the exact coordinates of the forms of mental model that are embedded in the protocol itself that are inescapable to developers atop it?

David Silverman: That's a great question and something I know we struggled a lot with was, to give transparency on a roadmap, Stani said this and we've said it, that Aave is building a front end that will live on top of Lens. It is a very opinionated implementation. We have our own API that many developers, including, we know Lensster, I believe, favor uses as well as does Iris, Messenger, and that takes in a slightly more opinionated approach and enforces a metadata standard upon a lot of the kind of unstructured data to allow for things to be indexed and processed easily. But I would say we tried to be, again, put as minimal and really be as agnostic as possible. If we think about what the primitives are, we tried to be as open as possible. There is a profile. The profile has one thing this kind of unique ID and a handle. And even that handle, the characters that can be in it and the max length are all fully configurable via upgradability of the contracts. The entire actual implementation, we're using proxy patterns for everything. The implementations can be upgraded at a later point. It has unlimited metadata and the only thing we require is follow logic. That follow logic can be anything. It literally is any arbitrary logic and I really mean arbitrary. that results in a Boolean value. There's no more simple function signature than that. And the follow NFT that is issued, it is a unidirectional follow. Twitter-esque. It's not the bidirectional like Facebook. I can build bidirectional follows with unidirectional follows. We said, "Let's take the base case.". Same thing for the collect NFT. We're actually going to be upgrading that and we've done it in conjunction with the developer community to allow the collect logic, the monetization logic to have full control of what the resulting receipt is. And again, the collect function is arbitrary logic with a Boolean result, the simplest function signature. And so I think we've really tried to say what's the simplest possible structure? Have that be what is open. And we've revised it. We went through four test nets taking tons of developer feedback. I think we had over 150 developers and designers give feedback to the structure of the protocol. Before we did main net, we went through three different audits, one of which being C4, which had a ton of participation, Coderina. We built it as open as possible and we know we might not have it perfect. And so we've kept up Upgradability. I know that the controversial opinion in the community, you want some things to be immutable. Like Uniswap, it can never be touched or upgraded without doing a whole new version. I think that responsible upgradability like Aave currently does and many other protocols do is a pattern to allow these things to evolve. And we may need more functionality down the line and we're very open to it. We've already got a roadmap we're working with the community on to add more functionality, to add more flexibility. But I think that there is a bit of lock in, but I don't think the lock in is that drastic on the protocol side.

Nicholas: I think I totally agree with you in terms of upgradability. Look, if the thing is so new and it's not the type of infrastructure like a version of Uniswap that can just live on and become less used over time, if there's a major problem with your social network, you really need to be a fix that. It is interesting because it also indicates something about the nature of attention. Like somehow in the liquidity pools model, there's the opportunity for oh yeah, there's still going to be V2 pools and maybe nobody uses V1 anymore, but there will be V3 and V2 coexistence at least for a period of time. Maybe there's some applications that are better on different protocols, different versions of the protocol, but in Lens there's something about the way that attention functions. that means that it would be. you don't want to lose the history, I suppose. You don't want to just fork and create a new thing every time you have some significant upgrade to the protocol. Do you have a thought on why it's different than the Uniswap in practice?

David Silverman: Yeah, I think it's different. I think it's weird. the question of like a canon. So for on-chain sleuths, the version of Lens that is mainnet is actually the second deployment. We did one for testing on Polygon mainnet to make sure our deployment was going to work functionally fine. There is no difference on a code level between those two deployments. It's just that all content, friendships, and information lives in that second graph, the one that we collectively call mainnet. The same thing for Ethereum. The only thing that binds us all to Ethereum, chain ID one, with this specific sequence of forks and everything, is that we've collectively agreed that this is the canonical chain. And when we had a disagreement, that was how we had Ethereum Classic. And I think it's the question of like, well, what if I forked CryptoPunks and I said that they're now going to be in this new contract? Well, there was some people who stayed behind in the old one. And I think for a social network where those connections really matter, the data store needs to be unified to a degree. It's made thinking even about, you know, talking about architecture decisions, it has made us thinking about multi-chain be very, very hard because what does it mean now if the data store is split across a bunch of chains? That's not easy and we lose some composability, about it very carefully and we're working with a lot of things and we said, this is something we want to think about for a future upgrade. Let's stick with a more simplistic design and go from there. So I think that's why I don't think we'll see as much splinter and I think that's why we'll see kind of one standard proliferate for Web3 Social on the protocol layer, not necessarily on the application layer, mainly because, you know, it means something for your data to be together. And it's something we've missed in Web2 because our data is not together. It's in all these different fiefdoms. and why it feels very wrong when your tweet gets taken down or your content gets taken down or you're left off a platform, it feels wrong because you visualize it together. It's part of your collective identity. I use the definition of the metaverse that the metaverse is the sum of all of your digital data, your digital information and history and that's why I think it feels different. Why social information feels different and needs to be kind of collectively together. So that's one of our guiding principles too.

Nicholas: Obviously, the metaverse term has become, has come to mean its exact opposite as terms tend to do. So I'm curious about, you mentioned that everything is public only. So let's say we were going to try to reimplement existing social protocols. It seems like something like Twitter, pretty natural fit. Something like TikTok, also potentially okay fit. If people were given the interface and that interface happened to rely on lenses, its underlying data storage and identity model, then there's no reason you couldn't index through those algorithmically using whatever kind of machine learning you want. Something that really hasn't touched a lot of like web 3 interfaces so far. Not a lot, doesn't feel like to me at least. So that would definitely be interesting. But the obvious thing that you couldn't do so easily is private information. Is there like a fundamental difference between like a true social network being something that's public and whatever Snapchat is or Twitter DMs which are actually not the same kind of thing?

David Silverman: So I actually, you can build those primitives on top of Lens. And we've actually seen some teams start to do it. The first one, the one I want to point to is one of our main launch partners is Iris. I think it's @irisappxyz. And they came out of ETH Global. They first built a Twitter-esque implementation and then the second project they built over at ETH Amsterdam was the Tempra Messenger. And this essentially is Telegram but entirely on chain. So it is on chain private DMs with read receipts using Lens as kind of the scaffolding. And I can kind of walk through how it works in the contracts. So I have a user. I'll be @David and in this case I'll pick another one of our team members. We have @keeks in the audience another one of the PMs at Aave. If I want to send them a private message I would do a publication. so I'm going to add a new piece of content to my array. The content URI is going to point to some data stored in Ceramic somewhere or stored in IPFS. And it's encrypted using let's say Lit Protocol. Another one of our great protocol partners we work closely with. And in Lit Protocol I can set access control. And I would set the access control to be possession of this. collect NFT. And in the publication itself I set the collect logic to be only keeks can collect this or only the holder of the @keeks profile NFT can collect this and he can only collect it once. And once keeks then calls the collect function he's now in possession of the NFT. Lit Protocol allows him to decrypt the message. And if I'm a passive observer who doesn't who's just looking at the chain I see some nonsensical piece of data blob in David's publication and I can just see that there was an NFT minted to keeks and so I can see that he's in possession of the read receipt. And that's it. That's all that the public observer would see but the private observers have been able to have this kind of experience. And if the application on top that's assisting with this functionality it can then present this messaging. And I can even expand that collect logic how I issue these receipts to different people in conjunction with Lit's access control logic. now I can do things like private groups or communities a social graph. the graph structure doesn't have to be completely connected. you know we can have a disconnected graph and we can have these kind of private circle areas regions of the graph instead of the larger structure.

Nicholas: So basically maybe you could tell me a little bit more about Lit Protocol. It sounds like it's enabling this kind of encrypted on-chain message passing.

David Silverman: Not an expert in their architecture so definitely David Schrafer from their team is a great person to reach out to and I think there's a bunch of different protocols that we work really closely with and collaborate with. We're in the interest of building things that want wide adoption. of different teams from Lit Protocol to Live Peer to Disco and a bunch of others Ceramic, IPFS and a bunch of other teams we've worked really closely with to make sure that we're all speaking the same language. So you know definitely if you want to go more into Web3 Social. I would say talk to some of those projects as well. Lit Protocol on a high level uses threshold keys so that they have a node network and you kind of present them with a challenge to say do you fill the access control logic? and if a sufficient number of nodes say you do then you can assemble the key and decrypt content that way. Yeah.

Nicholas: Got it. Okay very cool. So basically private social media slash messaging apps. totally doable. Maybe the obvious question that I think anybody would have on their mind is like but does it scale? Does it make sense to store things as NFTs in an infinitely append only array on a blockchain?

David Silverman: Yeah. I think that's a great question and it's a thing we've thought a lot about. On our launch day alone we were using I think at peak 5% of all of Polygon's gas. I've liked it to 650 guay. I like to wear that as a badge of honor but like you know that definitely made me ask the same question. I think scalability is something that everyone across the entire Web3 ecosystem and all of the core teams are working on. We've seen tremendous progress from optimistic rollups and VK rollups are coming very close to being fully generalized. There's obviously side chains and commit chains like Polygon POS. We chose Polygon so I think it's the most scalable solution now. that has all of the tooling that we need including OpenSea support and so it's where we are very comfortable. We feel they have the capacity for the types of applications that we need right now. If you ask me where Lens is I'd say it's in this kind of beta mode. We haven't opened it up to everyone. Even the tooling still needs to get there. You mentioned you have to sign a MetaMask signature for every message. This is definitely still the experimentation phase and we need to figure out how to build this stuff before we're ready to present it to a mainstream audience. And the bet I think that us and the team and all of our application partners are making is that by the time that's ready in the next 6 to 8 to 12 months Ethereum is going to be much more scaled or the Ethereum family of solutions is going to be much more scaled where we can start designing products for systems like Lens that are kind of assume a almost post-gas world. So I would say that's a little bit of how we think about the problem. But we love Polygon as a partner. They've got a ton of different ZKs in development. Polygon POS has a ton of capacity and even at 640 GWE that's what? A cent to transact? For a standard social application that's a very cheap to subsidize. that is a very cheap cost of a user acquisition well within standard marketing spend.

Nicholas: Totally. I guess the one challenge would be if it were completely open. so long as the users are paying their own gas then there's no spam problem because go for it. But I guess as long as you're doing the metatransactions at a point if people were using Lens' metatransactions to store arbitrary data for their own purposes instead of Firebase or something it might become a problem eventually. but I suppose you just deal with that on the front end. that's like signing or doing the actual metatransaction.

David Silverman: Exactly. So I can dive a bit into our API. We have an endpoint again. we really think about end users and application developers are some of our users. the Lens API. it functions exactly like Twitter's API or Facebook's API. It's GraphQL. it exposes the entire social graph. you can do things like get followers don't need to know solidity. The big thing is on the right side you don't have to worry about like weird EIP. 712 signatures kind of makes the formatting nice. We have with SIG built in and then there's a secondary function called broadcast. you can kind of take that signed message send it right back to the Lens API and Aave runs a relayer that will automatically post it on chain. And some of these apps have accounts with us where they can go fully gasless almost like here. set your limits. this is how much a single user can spend in a day and here is the global amount I'm willing to spend on a per hour or per day basis. Here's a credit card charge me at the end of the month. If you think about a developer experience I want developers choosing Web 3 not because of it's gimmicky but because of the real features and composability that comes with it. I want users using Web 3 apps not because of just decentralization for decentralization sake but for everything else that comes alongside of it all the really great composability interoperability and also the censorship resistance. And I think that we need to build better tooling to support that on both the developer side and the user side.

Nicholas: Yeah, I think there's clearly great political reason for being upset that there is one 30 something year old American man who controls the board of the social interfaces that something like 4 billion people are looking at every day or 3 billion whatever it is is well over 2 billion. I actually find that layer is of great concern and very concerning but also even just in terms of if you're not interested in the political discussion like what Apple did to the app store basically makes it impossible to be something like an indie game dev unless you're going to be building freemium games that are manipulating the behavioral psychology of your gambling addicted users in order to achieve viability. It's like that's pretty sad but that's where we're at.

David Silverman: I think this goes back to the question you asked earlier about like. do you foresee one big platform and it's not going to act in good faith versus the open source argument. I would say like open source I don't think it makes you necessarily socialist. like. there's probably going to be a couple of big winners but if they make decisions down the road that users don't like right users reserve the right to go elsewhere and I think that incentive is very important. I mentioned earlier like. imagine if Clubhouse which kind of invented the concept of what this conversation we're having now had access to the exact same user base that Facebook did and all of that data I would say the outcome would be different. I think the same thing for Twitter. right Twitter has copied a lot of features from a bunch of other protocols. The same thing for Facebook and Snapchat and Instagram especially. You know Stories was not on Instagram. that doesn't Snapchat innovation. and if they had the ability to scale there's probably tons of different entrepreneurs and founders in the crowd and listening to this if you had the choice between building and knowing that if you don't scale the size in three to six months you are going to get copied. the internal question of VC asks what's stopping Google from doing this? you know with Lens you kind of have a little bit of insurance because the social graph is there. you have the ability to kind of everyone has accessibility to your app. it's turning this zero sum game of scaling and of creating this social graph itself into a collaborative someone. Lens doesn't need to have just one app that gets big in order for it to win. I think it's going to have multiple apps that slowly build this kind of database and as soon as that global combined database of data generated from all of the apps starts to surpass let's say some of the minor social networks I think you're going to see more and more developers want to build using this tooling and once it surpasses a big network. that's where the questions are really going to start to come. and for full transparency we know that there's engineers at Snapchat at Twitter and the big companies that are looking at it and they're actively reaching out in our Discord and to the team on Telegram and we're happy to talk alongside them. if Twitter wanted to you know come over to Lens or use a version of Lens as its data store and became more open source I think that'd be a win for everyone. if Snapchat wanted to do that that'd be a win for everyone because it means you as a dev would go back to that day when Twitter's fire hose was open. and so you know I'm not a maximalist by any means. I know the desired outcome I would like to have but I think you know any little bit of more openness we have. that's really a win for users at the end of the day of the consumers of these platforms.

Nicholas: It's very interesting what you say. it reminds me of when Apple Facebook had sort of won the social graph wars of desktop web and then these mobile devices came out and Apple started giving SDK access to the address book and so Facebook's huge lead in having the social graph of everybody on the platform was suddenly eroded pretty significantly because actually a bunch of people that people maybe didn't even have as Facebook friends but who were their actual phone contacts were suddenly available to any app on the app store with like two taps in port which I think led to things like Snapchat succeeding and all these apps desperately begging for your phone number or not even giving you an account forcing you to use a phone number as an account in order to legitimize asking subsequently for your contact book. but I do wonder if let's play this out a little bit. so okay so there's like Lensster. there's a few other things. there's like maybe Telegram clone in the works things like this Twitter clone kind of thing. obviously they will diverge from their original inspiration. there will also. I think what will be very cool to see is if there are new things. I think it's difficult initially to convince people to switch from Twitter to Lensster for instance but if there's some hot new CT obsession that is actually built on Lens protocol and you might find the link on Twitter but then are having some social experience on their own website directly on Lens I could see that sort of causing the attraction to claim the accounts people join up. they play with this whatever Tinder for memes or whatever it is and then ultimately land on Lensster or something like that because actually we do need some basic infrastructure like this kind of Twitter thing. if Lensster let's say were to grow to be the size of Twitter let's say Twitter itself were built on Lens and something like Clubhouse came along developing a new format. in one way Clubhouse would be able to have access to all the users of this Twitter or future Lensster with a billion users but at the same time Twitter would have or Lensster would have no problem imitating the interface or the collect module or collect function etc. in order to imitate the kind of functionality that the new offering is coming up with. so maybe again becomes a question of is the interface lock-in sufficient with something built on top of Lens that other projects that are also built on top of Lens will have still be too much friction to get you to sign up for them? do you think is there something that I'm not seeing about? how it'll be easier if everything is built on Lens to move between them?

David Silverman: so I think the motion comes on the data layer. I think there's between the data layer and the interface layer. yes both apps will have access to each other's data but when we talk about interface that's a little bit different. I think I could very well be proven wrong. the interface is not necessarily necessarily just fully baked into the collect logic. you know for example we have Favor here. Favor's a Lens project. they have an iPhone app. they're a web 3 integrated in an iPhone app. Lensster is just you know browser not iOS app store. you know they've done tricky things with their web 3 wallet to allow for creators to post to web 2 socials and web 3 socials simultaneously. interesting management and that's done on a layer outside of Lens protocol directly. but if all of a sudden for some reason which I would hope never came the day because we love the Favor team but somebody decided to go a creator wanted to go build on I don't know Nicholas's creator tool their data's importable. the tricky stuff that you could be doing with a wallet or with an interface is different and yes it doesn't perfectly remove the. can Google clone me? can Apple clone me tomorrow? that thread is never going to be removed just due to the way that money allows you to buy a ton of resources and devs and devs can go do things. we can never get rid of that risk entirely. I think what is really the push of web 3 which is going from don't be evil to can't be evil where you know if all of a sudden someone tried to be evil they're very forkable. I think that's really what it is building a forkability less so than trying to prevent trying to allow for people to kind of have defensible. it's a weird tension between those two things. if I want somebody to be very easily forkable any really new innovation they create is going to be forkable and so I think it really requires you to be truly innovative as a team. the most innovative will succeed and you've got to stay innovative over the long term and that's been very very hard.

Nicholas: so like a perfect example would be let's say Twitter was built on Lens and then Twitter.com and Twitter. the app started centering posts that I felt should not be censored. I would have the data portability in order to log into a different interface. that wasn't doing that regime of censorship and other people's data would be there populated already because the data layer was portable and didn't belong to the interface in the first place. obviously however Twitter could copy new entrants that are trying to use that in the building of their interface. but there's another piece that's interesting to me. maybe I'd like to understand the collect piece a little bit better. can you explain again technically how collect works?

David Silverman: Yeah yeah yeah. so we skipped a bit of the technical description. publication which is the structure of where content lives. there's three types of publications. you have the post which has a content URI metadata and then two modules which we'll get to later. you have a comment which has a reference to another publication as well as all the same fields as a publication which is like a content URI metadata in these two functions and the last one is a mirror which is a pure reference. so we think of the Venn diagram. we have reference and we have content URI. post is just content mirror is just reference. comment is the same as the two and a nice little like a data structures lesson quote tweet and comment are actually represented the exact same way in the Twitter database which is a single flag to say actually this is a quote tweet not a comment.

Nicholas: cool.

David Silverman: so the two functions are there's a reference module and a collect module. the reference module. it dictates who can reference your contents. when you think back to that structure it says I can't comment on your piece of content unless you pass through this function and the function can get arbitrary logic resulting in a Boolean value either you can reference or you can't reference. simple thing we have today you can only comment on this if you are a follower of mine or you can only comment on this if you hold a bored ape. you can only comment on this or you can only retweet this or mirror. we call mirror. sorry you can only mirror this piece of content if you follow Bradley. that's reference that's distribution. and then collect is monetization. those are the two key things of derivative rights. monetization says that you can create what's called a collect NFT. this is an NFT that today perfectly mirrors the content URI. coming in the future the collect module will have full control over the resulting collect NFT. let's say I have a great photo of a bunch of us on the Aave team at permissionless. I can post that as a publication and I can collect logic. that says hey if you fit this criteria if you hold a David follow NFT if you are a follower of mine and you pay me five matic. the first 10 people who do that can mint this as an NFT and actually kicker because it's arbitrary logic. I can do a defy hook and say that five matic I receive automatically deposit it into Aave or 0x swap it into euros. I'm out in Europe and I want some spending cash that allows for arbitrary monetization or just a really powerful NFT engine if we think of what it is. Profile is hi I'm Aave event and the collect is here's your ticket to Aave because you can do read and write across any chain and combine with things like Metatransact. I think you'll see this new model where from a user I have a sign in key. I think you need to have at least the pointers the references to show that the action was taken place. just an event emission from running a note. I'm not see that not all apps are pick up on that. it's the optimistic case of somebody's listening. no one's running the roll up and validating. it happens somebody can do something bad if all we're doing is trusting that somebody's listening to the event update state. the fact that it's in the actual state itself is very important as we get to things like data availability layers and all kinds of other things that allow us to scale to have this state in a distributed really good way. I think we will see more things come on chain. I think the reason things are not on chain right now is because it's expensive and I don't think that's always the best argument.

Nicholas: >> It seems like the roll up tech is going to make storing data and proof on chain make scale feasible.

David Silverman: >> I'm hopeful on zk but I think other tech coming from One of the validators, Texas Fault, they throw it into roll-up mode. I think stuff like that is really interesting, these kind of hybrid mode chains, and there's a ton of really, really great research, and I'm not nearly giga-brained enough for that. So I say follow a ton of people who can do that. DC Builder's one of my go-to sources. I'm excited for what's coming in the scaling space, and on the App Layer kind of design side, we can start to, thanks to all the great work they've been doing for years, we can start to design for the kind of post-gas, not post-gas, 'cause gas always needs to be there, but these kind of cheap state, cheap gas kinds of world. And that's really what I'm looking forward to, is this is the first draft we've done of Lens, of a protocol that's doing that. I can't wait to see what happens in DeFi, what happens in NFT, what happens in gaming, these applications that require really cheap compute and storage. I'm excited to see what's gonna come of it, if Lens is just the tip of the iceberg, in my opinion.

Nicholas: - Given that you're storing the data kind of in a really simple, straightforward way, does the API offer tools that will make it easier to traverse that data, if you're looking for only some specific subset, for instance?

David Silverman: - Yeah, I suggest you go to, people who want more about the API, docs.lens.xyz. The API was written by an awesome team. I wanna shout out the devs who did it, Dev Josh Stevens and Daniel Marans. They're killer, wrote a crazy good API, I think it's fielded like 15 million requests since launch. It's had three errors, which is a crazy, crazy uptime. I used to do SRE and saw those numbers and thought they were lying. It really is a Web2 style API. You can query and just say, "I wanna see the number of followers. "I wanna see the specific post from this person.". It feels really much like I was back working with the old Twitter API. The fire hose is back. And ask any of the devs who were building on it during the hackathon, you want a new endpoint, ask, they're probably gonna build it in about six minutes. And yeah, I would say that we're working with a ton of other great projects building on top of it. I wanna shout out STEMDAO, which does music NFTs in a collaborative style on chain. They said, "Hey, we have this metadata, "the standard that defines a music NFT. "It's stuck in the metadata. "Can we get that? "If we give you the schema, "can you unwrap it and allow us to query it?". And we're trying to build in that type of functionality. We're able to build in the gases functionality. And the idea is let's give these developers, there's so many more Web2 developers than Web3 developers. We all need as much help as we can building the Web3 future. Let's give them development tools and systems they are familiar with. That everyone who's learning how to code in school right now is familiar with. So we don't need to, solidity is a decent language. I don't think it's a great language. Ethereum tooling is rough. Let's try to ease that environment.

Nicholas: - Yeah, definitely. It's interesting to think of Lens as an alternative to, I don't know, Firebase, these other kinds of infrastructure options. I mean, I guess at present and for the foreseeable future, it'll require you have a wallet. So there is some limitation to just like using Lens instead of some other drop-in backend solution. But you could imagine people trying it as potentially having an audience of people who are more interested in and open to trying new applications if possible.

David Silverman: - It is. I would say that we're not optimized to be infrastructure. There's tons of really great solutions. I think there's like Filebase, which uses IPFS and it looks like exactly like Firebase, right? Like, I think you should be doing the storage of video content through like things like Livepeer. Like there's a ton of specialized protocols for different types of content. And Lens is optimized for that social relationship. And that's why I said, I think we're working with a lot of these different providers and these different protocols to make sure we're all speaking the same language because we expect apps are gonna use tooling. That's aware of it all. I think there's gonna be this kind of like a lot of different companies coming up that are gonna be middleware that build on top of all these different protocols and build nice, really good SDKs for people to build in. So I think there will be that infrastructure layer and I think we're gonna be part of it but I don't think we are the whole story. I hope we're not the whole story. - And the wallet side you touched on, I think that the wallets we have right now, I hate the term wallet. I think we're gonna see a revert back to what they're actually, you know, it's the externally owned account. And I think that's, you know, look at it in a non-financial context. I think maybe you even put it in one of your Lenster posts. You're like, I am terrified that all of these are tied to the same thing that has financial history. I think that like, we're gonna see seed phrases allow for the creations of unlimited accounts. I think we're gonna see a lot of more single purpose addresses and UIs that do, you know, I give Formatic a ton of credit. I think they're definitely ahead of the curve with the idea of let me sign in with username and password or an email address to access Web3. Not a massive fan of their exact implementation of it but I think you're gonna see a lot of that coming soon. Next six to 12 months of these next generation wallets that are gonna look and feel like smart contract wallets but will be EOAs. And then after account abstraction is on the EVM, really we're gonna see some really crazy stuff and more people will have a wallet than have actual wallets.

Nicholas: - Can you jump in a little bit into the account abstraction stuff? What makes that so cool and powerful?

David Silverman: a lot of things right now require an EOA because contracts don't have private keys. We treat EOAs as first class citizens in Ethereum. We don't treat contracts that way. And so I think account abstraction, again, I'm not kinky brained enough to go super in depth on it. I wish I could. It's a topic I keep meaning to dive into. It allows for contract addresses to initiate transactions the same way that an EOA does. Keepers are pretty much this kind of off-chain concept we had to add to allow for smart contract logic to kind of be automated through an EOA. If we think about like how hard it is to use certain apps with nothethink or Argent or other like smart contract wallets that have these really cool built-in features that we want to put into a rainbow, into a Metamax, but can't. That's part of it. I wish I had multi-signature protection on my ledger and still had the ability to use dApps as they normally do. Or say, hey, only if my transaction's over 15,000 do I want to have multi-signature functionality. Otherwise I am an EOA because EOAs are special. Getting rid of that requirement, which is to the best of my knowledge what the account abstraction EIP is going to do is great. But until then app devs are going to be app devs or app level devs are going to be app level devs. And I think we're going to see some really cool innovations out of a few different companies with solutions getting around this and really trying to think of, again, user-focused design, how do we build a good wallet? How do we make public private key accounts, accounts of the first class citizen available for the next billion users?

Nicholas: - Yeah, I need to jump into account abstraction a little bit more too, but definitely hear everything you're saying. It's the UX of wallets. today is probably not going to be the same in a year or two years for sure. It's going to be exciting. I know we've gone a little bit over time. Do you have a few more minutes?

David Silverman: - I can keep going. I'm happy to keep going.

Nicholas: - Yeah, great, okay. I have a couple other questions. Yeah, me too. I'm really grilling you. I have a couple more questions lined up, but if anybody in the audience wants to come up and throw out a question, feel free to request. I'll let you up. So you mentioned games a minute ago. Have there been any experiments making games on top of Lens yet?

David Silverman: - I think it's early. I know a few games that are looking to integrate. I don't want to name names because I don't know how much I can actually say. I would say that games are looking at this of on the smart contract level or the UI level. Again, I like to always think about who the end user is. On a UI, a key part of games is chat. And I think that Lens does enable itself to chat very well. And the idea of having friends that I can ping 'cause I want to do multiplayer. Avogadro is doing something. I want to remind my friend and I can do a notification. So I think Lens does make itself useful for aspects of a gaming experience, but Lens itself is not a gaming protocol. And that's really, again, the thesis I have that there's going to be this middleware that gives devs an SDK to use a ton of these protocols to build great holistic experiences. We're one part of that. We're not all of it.

Nicholas: - For sure, it makes sense as a part of the social chat infrastructure inside of a broader game. But the collect modules actually has me thinking that Lens itself pretty well to viral social dynamics and NFT. you can only get by interacting with this publication and having some other kind of credential. or maybe the dice are rolled or whatever the case might be. It seems like there's opportunities. I always think of a casino as like the forbidden fruit that would power popular social networks. Like the opportunity to gamble just seems to attract people. So I wonder if it's possible to do something in that direction, like, I don't know, gotchas or I'm not even sure.

David Silverman: - While we were all internally super excited for Mainnet and honestly, even tests on Unveil, I mentioned we've been working on this for over a year. What devs have been able to build with this and what the community has been able to build with this have blown us away immediately. And I wouldn't be shocked to see what games are coming. We've seen even like media companies, like. I'm super excited to see what like we saw different media companies could use as the future of publishing, different publishing models. Hey, this news story, the first 50 people who collect get access to it. And then after that, there's a 30 minute timer and then it's available to everyone else. I'm just spitballing. We could even see Web2 firms try to move some of their data on chain. We haven't spoke about regulation at all, but this kind of provides a solution. Another weird reason why Snapchat or Twitter want to move on is that GDPR does not protect against data that you've actually decided to make public yourself. And if they're not in possession of the data and the data lives on chain, there's no possession that way. So there's definitely a lot of other weird incentives for building on, you know, blockchain, but thinking of the gaming stuff, I'm super excited to see. I think gaming on blockchain is so early. It just requires an actually like good game to be built, not to throw any shade at any of the existing games. I just haven't been super impressed. And part of that is just a function of, we don't have the storage and the compute necessary yet.

Nicholas: - Yeah, for sure. Also, there's a lot of skeuomorphic design going on in on-chain games. I spoke recently with winter.eth, who made the button.lol site a couple of weeks ago, which is just a button that you can press every six hours to collect a token on, actually it was originally on Optimism, but now it's all over on all the networks. I don't know that it's so successful. I haven't kept up with it since it dropped, but I found it amusing to like reduce a game to its minimum score, keeping a score and having some kind of constraint around how you can increase that score. Seemed to me like a more interesting meditation on gaming on blockchains than whatever, a 3D world, blah, blah, blah, blah, blah, like some social place nobody wants to go. And it sounds like Lens. actually, the collect module could be a very cool opportunity for creating games because it's so easy to create for. You don't need to build the whole contract. You're just building what this collect module is.

David Silverman: - Totally. I also want to give a shout out to David Phelps at Divine Economy. He has this great thesis that like ERC-20s and 721s can also almost act as like API keys to a degree. And I actually kind of like that concept a bit as a way of thinking at it, where the game itself might not actually be on-chain, the logic isn't on-chain, but some of the stuff required to use it, again, receipts end up on-chain. So I think that's been a useful lens in which to look things. That's when I talk a lot about it, like for privacy, really what is that? collect NFT, but a receipt, but an API key to unlock the content. I've found that kind of mental model very useful and something that I think that type of thinking can allow for the creation of a really interesting stuff of, hey, the blockchain is just, again, for this kind of proof that something's occurred as opposed to the actual interactions itself.

Nicholas: - Yeah, totally. I had Sean McCaffrey, who's building out Jokedow with Phelps on the show, and he I think really came up with this brilliant idea that just like thinking towards the disposability of tokens that you don't need to imagine your token as persistently accruing value, but instead the way I put it, I think around the same time was we're just leaving breadcrumbs on the blockchain and those can be picked up later by ourselves or by others in order to do airdrops or permission actions on-chain or off-chain. There's like a whole range of things that you can do, but the real key is, I think about it for this show actually, that I've been meaning to do POAPs, but it's a little bit annoying because it's a permission system. You have to plan like at least 24 hours in advance, et cetera, but to just release tokens to people who are in the live audience. And I don't know what it's for, but it makes it very easy to find you in the future. So maybe I'm wondering if that would make sense to do that on Lens. I had previously been thinking about doing just like some soulbound NFTs on Polygon or something like that.

David Silverman: - I'm currently very bearish on soulbound NFTs. - Okay. - Evan from Disco has a great quote for them where she calls them the herpes of web three. And I definitely do feel that unless you provide burn or transfer, again, I'm a big believer in this kind of sense of like, we're going to have a lot of disposable addresses and that the real primitive is going to be the seed phrase almost. And I know that there's a ton of identity solutions, you know, ZK identity solutions. I think WorldCoin operates in this way, where it's, you know, we have some kind of proof of humanity, but it's not actually tied to a specific address. I think that's kind of important.

Nicholas: - I definitely agree. I think I said something about it on Twitter the other day, but I am eventually going to move what address my ENS is pointing at. And if people are not paying attention, or if people also maybe aren't even indexing the prior history before that changed, then they're really going to be missing a big part. I know Brian Flynn from Rabbit Hole talks about, used to at least talk about the address as the resume or the CV, but I really disagree, or at least in the sense that I have to stick with that address, I can't abide. It's not possible that in 10 years, I'm going to be using the same address as the technology will have changed enough. I'll want to reset my private key security undoubtedly and other things. For hot wallets also, like I don't want to have all the history of all whatever computers they've been on. - It's unlikely that I'm going to stick with those wallets.

David Silverman: - I rotate my hot wallets frequently and suggest that everyone in the audience and listening does as well. Let's practice good OPSEC and not get wrecked like board app holders. I think that the resume is important. And today that's what it is. Eventually it might be just, I'm applying and here is some proof that shows I control these array of addresses. It's selective presentation of data. I think that fits very well into the lens model of when I present an application, my profile NFP, if we assume a lot of that data is encrypted, I have to also kind of give each app the permissions that I want to give it. And I think that's where we're doing it on a single address for now, but in the future could be, hey, here's a proof that I have some data stored in this other profile or this other address as well. So I don't know. I'm excited to see as this ecosystem and design space continues to expand what we do.

Nicholas: - Yeah, it does make you want to see, given Brian's idea, it's sort of like a resume. You can imagine a web app that's just like a cool meter for how cool this address is that you're inspecting. But if such an interface were to exist, you would kind of hope that it goes and checks, like, let's say I punch in an ENS, that it goes and checks what other addresses have been associated with that as their primary ENS and for what durations and associate all of that data across all of those different addresses rather than just the one that it's currently set to until since that one was created.

David Silverman: - Yeah, I mean, there's DGEN Score, which I love. And I know there's a few different products that have used DGEN Score as a way to gate keep early access to some DeFi primitives, which I think is super cool, analyzing an address and seeing if you've been wrecked and other things like that. I think that's super cool and a nice way to do it. Another interesting thing is something that we've looked at. I mentioned Obvious Building, so in front end I can give a little alpha leak.

Nicholas: - Let's go, let's go.

David Silverman: - Twitter allows us to add NFTs as our profile pictures, but we have to sign from that one address. We understand that your social, that the profile NFT you hold, you're probably gonna want that on a hot wallet where you can sign quite frequently. You're not gonna necessarily want that over on a ledger, but you're probably gonna want the profile NFT or you're probably gonna keep your NFTs on your ledger, at least your valuable ones that you wanna display. And so building in this concept, at least our front end of, hey, I can sign to prove I own these other addresses in order for the verified NFT, I'm a verified NFT holder, even though it's not the same address my profile lives on, providing proof that way.

Nicholas: - Exactly to the point of that Lens publication you referenced earlier of mine. Every time I'm signing a transaction in order, or signing a message in order to post, if it is a wallet that contains something of value, you really need to be a little bit careful about signing those messages. So the ability to have a second wallet that doesn't contain anything valuable, but is permitted to post, for instance, makes a lot of sense.

David Silverman: - Even doing the recent distribution of names, it was definitely frustrating having to tell partners, EOA, please, EOA, please, and make it something that's a hot wallet you're willing to sign a bunch. 'Cause if you've been through this, the claim flow, and if you haven't, some of our team members are taking snapshots of some of the people who have ENSs in their name, and we're gonna try to whitelist a few of you. You sign a lot, 'cause that's how things have to be gasless. And we really do believe in on-chain of record. Yeah, I can also alpha leak a little bit on where we're going with Lens, what the next one to two month roadmap looks like on the upgrades and kind of what we view. So the first thing is we have a big kind of upgrade called Profiles v2, which is taking the profile NFT and the system around it and bringing it to a new level. The first thing is allowing permissionless minting. Lens right now, you mint your profile, and you have to be a whitelisted to be a minter. So somebody has to mint for you, and it has to be an approved address from governance. Right now, the only one that can do that is the Genesys address. that's controlling the distribution. That's the only address. Part of it is because we don't want it to be abused. We don't want to pollute the whole namespace. We're on Polygon. This is an ENS where there's Ethereum gas to contend with, and there's a bit of a delay. The names are currently permanent. So Profiles v2 is a system of three things. First off, it builds this primitive of wrapped profiles, profile that lives inside of a smart contract that issues you a wrapped version of that profile. In the same way that we have ETH and wrapped ETH, we have a profile NFT and a wrapped profile NFT. And the idea is that I can pull, under certain conditions, I can rescind access to the profile. For example, let's say that FWB wanted to build a private social network only for its users on Lens. I could be, and I'm not a member, but I could be @david.fwb. But if I, for some reason, either I went below 32 FWB or lost, or the community didn't want me in anymore, they would have some ability through the wrapper to rescind my profile. The second thing it allows is the ability to change your handle. So I'm currently davidv.lens. Maybe I want to go down to just david.lens. And so the way that works is I pass in a new minter. And lastly, because we have this concept of wrapped profiles and the ability to change addresses, we can tie the minting of profiles to possession of external objects, whether it be an NFT or any other kind of arbitrary function. And so that means I could have a situation where I could be @davidv.eth, and me maintaining that handle is conditioned on me maintaining possession of davidv.eth, thus linking my ENS and my Lens handle. And if I sell my ENS down the line, let's say I send it to Miguel, one of my friends in the audience, Miguel can go to that same minter and say, "Hey, I'm the new owner.". It takes my profile, archives it, and he becomes the new @davidv.eth because he's in possession of the NFT. And so we can have Lens profiles become almost like subservient to some other object, some other logic. Lens is not trying to be an identity solution. There's a ton of others out there. And again, we're trying to be really maximally compatible with all of these other great systems. Polygon's got an ID, WorldCoin's got ID, ENS obviously has an ID, Stoppable has an ID. There's a ton of these systems, and Lens, we want to plug and play with everyone as nicely as we can.

Nicholas: - Yeah, that's interesting. One of the questions I was meaning to ask you was why not just use the ENS.eth as the core unit?

David Silverman: - I have davidv.lens, and you see my handle, I'm still davidv.eth, I'm an ENS maxi. Unfortunately, they have not really expanded to other chains, and I fully understand why they're going through the EIP process. that's on the way. I think there's a bunch of teams, ourselves included, that is working on trying to do access. It wasn't super hard to get a Chainlink Oracle spun up that could report ownership of an ENS name to Polygon, but that hasn't been built yet. That would be really helpful for a lot of developers, a lot of app devs who care about having that data on chain so contracts can access it. I think at times we see a lot of teams that just are led by engineers who are really good protocol engineers, but not necessarily thinking a lot about the app layer. And so I know for us, it's something we want to build, and we're working with the ENS team and tons of other teams, again, to be compatible with a bunch of identity solutions. I don't want to promise features. Also, now the project's open source, the community can build what it wants to build, but we want to work with and integrate ENS. They just didn't have a solution that was going to be ready for the timeline, and I know it's something that we have profiles V2 to allow ownership over this other thing, right? Our profile entity had to be different from the ENS spec because it has functionality that's not built into ENS, and that kind of a cross-chain relationship. They're not on any other chain. They're not, you know, haven't proven to be interested in having the root name live on any other chain. Even their current multi-chain solution says only subdomains can be built on other chains, and that's a really hard design space to work within, especially if we believe in the thesis that we are going to be in a multi-chain future where execution and storage lives everywhere. There are teams that are building that. There's, you know, everyone has their own kind of a roadmap, but I know that we are working closely to have profiles V2 as specification that will be compatible with ENS, and I know that there's plenty of people working with Chainlink, a bunch of Polygon projects working with Chainlink to get an Oracle that will allow me on-chain to look up ownership of an ENS name, something that probably should have been built a long time ago, and we're happy to have that built on Polygon and hope to see it also on other chains so ENS can proliferate across other chains. Again, the simple read. I think writing is a very complicated thing, but read is really important. I know a bunch of devs, especially in the audience, have looked up tons of different ways of how can I read data across chain. We're all really waiting patiently for CCIP. Chainlink really teased us. Layer Zero has been teasing us with cross-chain write. It's coming soon, and I can't wait to see what's really gonna happen when, again, that kind of barrier of what chain your data is on becomes less and less important.

Nicholas: - Does it not? I mean, obviously it's wonderful, and for sure, read is absolutely necessary. Thinking about the Jokedow example from before, which is one that really taught me something about cross-chain or multi-chain meme communities. It's like the Jokedow contest runs every Friday, and who can vote is based on who has participated in prior contests, as represented by ERC-20s, I believe exclusively on Polygon for now, but they might as well be on any chain because the next contest could be run on any other chain, and so really Layer Zero is controlling which contest is the legitimate one that we're interested in, and that one can be set up to reference data on whichever chain they choose for that week. But if you are doing something that's a little bit less hands-on, controlled by the Layer Zero, is there not a danger of doing cross-chain writes or even granting access to functionality on the basis of cross-chain reads for all the reasons of chains being paused and things like this, for instance?

David Silverman: - Totally, totally, and I think that's something that each system has to take into account, and that's why I said I like that wrapped model, which is why we said we really wanted to think about Profiles v2, what are things we can do. In Profiles v2, we're making sure that every single wrapper that is compliant, or at least that is a minter, has a governance function where governance can say, "Hey, we're going to now burn everything inside the wrapper. "This area of the namespace has been compromised.". There's also the ability to say, "Hey, even larger DAOs, Aave, "Aave has a cross-chain governance bridge. "that controls the Polygon deployment.". There is a trust assumption that the Polygon bridge functions, otherwise the Aave market can get compromised that way. They're being very careful. We haven't seen the other markets come under control because Aave governance hasn't found a bridging solution that it feels comfortable with as a community. We know that Yearn is working very closely with Multicall, which is AnySwaps, as their messaging solution, but if that gets compromised, then Curve has its own problems on its hand, and you have to think about, that is the risk tolerance of the community and the risk tolerance of the software, and maybe we have to wait for these solutions to mature, and I totally agree that for something like ENS, Write is really sensitive, especially on the root. I get their model, the root needs to live on Ethereum and only Ethereum because that's where we view the most security, and you can always fix a compromised subdomain by going back to the root. That makes sense, but I think that for Read, if I'm an application reading, I am the one taking on that trust assumption of the Read, whether it comes from CCIP, honestly, if Chainlink's compromised, we have much bigger problems than @david.eth is compromised on Lens, just due to how Chainlink is so well-integrated everywhere. Same thing, probably, if layer zero gets compromised, the total, they do become kind of centralization points. Maybe we'll see bridge aggregators in the future, like messaging aggregators that rely on some threshold, a solution to combine security models. I don't know what the answer is, but it's up for each community to take its risk tolerance, and I think Read is obviously a much less sensitive than Write, yeah.

Nicholas: - Yeah, absolutely. Two more questions. One, if I did want to do some kind of airdrop for the audience of the podcast via Lens, I guess the first thing would be I'd have to wait until more addresses are whitelisted or the protocol is fully open to people, but presuming that were the case- - You don't,

David Silverman: actually.

Nicholas: - I don't? Can anybody claim even without having an account?

David Silverman: - Anybody can collect and anybody can follow, assuming that the logic in the collect and follow module allow you. So even if you don't have a Lens profile today, you can go to several of the Lens-supported apps, depending how they're architected, and you can actually read and even follow. So I know LensFriends, L-E-N-S-F-R-E-N-S, obviously, .xyz, which is an app built by the Aave team. You can go browse different Lens accounts and follow them. You can follow them today if their follow module allows it. David Hoffman from BankList did his Mint Live with us at Permissionless, and he set his follow logic to be anyone can follow him. So even if you don't have a Lens handle, you can have David Hoffman's Lens NFT. You'll follow NFT at trustlessstate.lens. And actually, a nice little hack our front-end devs did, if you render that in OpenSea, it will actually show you his most recent publication, kind of constantly updating. So if you wanted to do a drop, you could. Your collect logic would have to. probably you can only mint on secret phrase, and the secret phrase is something you presumably say on the podcast. Very similar to how one of my good friends, Diana Chen, did a podcast with PoP God, and they did a verbal proof of podcast listing. But again, you have to set that up ahead of time. PoP is awesome. I wish they were a bit quicker. You had that kind of turnkey solution, but I know that, again, reducing spam is kind of critical. We're not gasless yet.

Nicholas: - For sure, yeah. Okay, that's very cool. And the final thing I wanted to ask you about was, do you think about,

David Silverman: I mean,

Nicholas: I know the term is a little bit meaningless at a point, but do you think Lens has anything in particular to say to DAOs, or maybe more broadly, just people organizing on blockchain?

David Silverman: - For DAOs, hi. We treat DAOs as first-class citizens. Remove trust assumptions. You can actually have a multi-fig-owned social account. Delegated access can be built in. Actually, we even have the ability that all the follow NFTs have built-in governance. You can build a brand new type of social DAO and define your governance threshold as they've done this amount of posting or they've engaged in certain ways, and you can write that logic. I'd love to see some cool integrations with Orca protocol. In that regard, it's fully compatible with Snapshot, Compound, Governor, and Aave governance modules. So here's a cool new building block. Here's a new way to allow people to communicate socially in a Web3-compatible way. I don't know what DAOs are gonna come up with, but here's a primitive that allows them to be first-class citizens in a social way and in a distribution means, right? What is a DAO? but a creator of some means? Lens is designed to empower creators. Hi DAOs, if you have ideas, I'd love to talk to you. DM me or go to docs.lens.dev or drop in the Discord and ask us questions. We're here to brainstorm and build alongside you.

Nicholas: - Yeah, it makes me think about doing some kind of crowdfunding mechanism. Imagine if Twitter let you embed arbitrary on-chain functions. I mean, it would be pretty cool if you could just ship something that people could be immediately interacting with through that collect button. Do interfaces like Lenster and Favor right now support data input when you click the collect button?

David Silverman: - What do you mean by data input? You can set your own collect logic or?

Nicholas: - Yeah, I guess, is it possible, or maybe it's not actually possible. Collect just a no-arguments-passed kind of function, or is it possible to pass arguments too?

David Silverman: - You can pass arguments. Paid collect, I have to specify what amount I'm paying. So when I set up the post, I'm gonna say this costs five matic, or I think it's in review, but a Dutch auction one. So I have to specify what's the total number that's being minted and what's the price curves and all that types of stuff. So that's all, you can pass arguments into the collect function. The collect function is an arbitrary logic. The output has to just be a Boolean value. That's the only thing we enforce is the output's a Boolean. But you can, I guess, add more outputs by calling other contracts that just do more logic.

Nicholas: - So you can imagine DAOs using that functionality in order to enable something a little more interactive than just like we're moving our social from Discord to Lens, but instead it's a serious upgrade. We're getting actual functionality on our publications. - Totally, totally.

David Silverman: Also, I mean, if you're other ideas with tokenomics, et cetera, like I mentioned that we have that kind of DeFi enabled NFTs, let's say I'm a DAO that creates art collaboratively. We know the entire art market is, the NFT market is pretty much denominated in ETH and USDC. I can still sell on those two currencies, but using the Lens DeFi integration, zero X swap into my governance token to do buybacks or burns. So there's a ton of really cool functionality. For DAOs, I'd say now is the time to experiment. I wouldn't say we're leaving Discord just yet. I really want to leave Discord. I know we're all sick of the spam. This is the time to experiment. And we want to experiment alongside you guys. This is just a great thing. I love, I know someone at Aave said it, which is when you build, you're not building yourself. And Web3, you're building as an ecosystem and a community. And Lens Community has been great for building, and we want to keep working alongside you.

Nicholas: - Awesome. Well, on that, David, this has been really educational and interesting. Oh, actually I think Miguel is up here. I don't know if Miguel wanted to toss in any ideas before we go.

David Silverman: - Yeah, no, I just got brought in, so I went up, but I don't really have anything to say.

Nicholas: (laughing) - Well, it's nice to hear from you.

David Silverman: - Hey, Miguel.

Nicholas: - I saw something on Lenster, actually. You had added some functionality to Lenster recently. What did you build?

David Silverman: - Yeah, I was just like looking at the code, having a little fun, and I noticed that when you shared Lenster link to set up Lenster, you didn't really get any information of the content. So it just like said Lenster, and that's it. So I made a PR, so that now it actually includes information. Like it says, "Who posted this?" They include the title, include some information. If you go now ahead and like tweet any Lenster profile or posts on Twitter or Telegram or anywhere, you'll see that it now attaches the information, which I thought was helpful.

Nicholas: - Very cool. And are you excited about building on Lens? - Is there any ideas you've got?

David Silverman: - I have a big list of like ideas, both for Lenster and for like building on top of Lens in particular that I'm really excited about. But I'll save those for when I actually make them.

Nicholas: - Yes. Okay, great. - Well, yeah, go for it.

David Silverman: - I would say having been fortunate enough to have gotten to work alongside Miguel, I can't wait to see what you code up both on Lenster and on Lens on top and happy to have you in the builder community.

Nicholas: - Yeah, thank you. - Awesome. Well, I've learned a lot about Lens today. I hope everyone listening has got something out of this show too. Super interesting and very cool to see the dynamics. It's not just on chain Twitter, and it's not even just abstract form of that. It really is enabling interaction between these social kind of publications and the rest of everything that's on the EVM. So extremely cool, especially to think about some of those cross-chain implications that are just mind blowing. David, thank you for coming through. Miguel also, thank you for coming through.

David Silverman: - Of course, thanks for having me.

Nicholas: - Absolutely. And for everybody in the audience, I'm gonna share a very ad hoc Google form, which won't require a sign in. So if you put your address in there, maybe you'll receive an airdrop on a chain to be announced in the future. And I'll be tweeting that out in just a minute. Thanks everybody for coming through and see you next week at the same time, probably five o'clock Friday. Thanks everybody. Hey, thanks for listening to this episode of Web3 Galaxy Brain. To keep up with everything Web3, follow me on Twitter @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 web3galaxybrain.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.