Epicenter - Learn about Crypto, Blockchain, Ethereum, Bitcoin and Distributed Technologies - Stani Kulechov: Lens Protocol – Decentralised Social Media Primitive

Episode Date: September 8, 2023

Social media revolves around content creation, and while the content itself could be tokenised through NFTs, SocialFi aims to take it a step further. The recently released friend.tech app went to show that users might be interested in something more than just content - creator shares. This implicitly links back to handles and profiles, and we can slowly start to unveil the primitives of social media. Lens Protocol predates the friend.tech venture, in both timeline, as well as scope. While social media became synonymous with monopolistic central entities, Lens Protocol aims to build the decentralised bedrock for Web3’s social layer. These primitives would not only be interoperable with any Web3 application, but they would redefine content creation, feed generation and monetisation.We were joined by Stani Kulechov, founder of Lens Protocol & Aave, to discuss decentralised social graphs and how to leverage smart contracts to build the primitives for Web3's social layer.Topics covered in this episode:The vision behind LensLens V2 and smart contract capabilitiesSocial media development platformDefining the Web3 social media primitiveFeed generation algorithm on LensIntegrating on-chain and off-chain infrastructureThe tragedy of the commons in decentralised social mediaCan a public good architecture also accommodate private goods?Growth model, sponsored transactions and monetisationGovernance and decentralised social mediaEpisode links: Stani Kulechov on TwitterLens Protocol on TwitterAave on TwitterThis episode is hosted by Friederike Ernst & Meher Roy. Show notes and listening options: epicenter.tv/512

This is Epicenter, episode 512, with guest Sani Kulekov. Welcome to Epicenter, the show which talks about the technologies, projects, and people driving decentralization in the blockchain revolution. I'm Friedrich Erns, and I'm here with Meheroy. Today we're speaking with Stani, who is the founder of Aver companies, the company unsurprisingly behind Aver, which we covered a while back, and also social network lens, which we will speak about today. Stani, welcome back.

Thanks for having me here again, Frederick. It's always great to be here. Cool. We had you on not so long ago. Then we spoke about Ava V3. Very tangentially, I think we mentioned Lens. But today we're here to kind of make up for that shortcoming. So, Soni, in a nutshell, what is Lens?

Tell us about the origin story and what it set out to do. I remember something very vaguely about you applying to be kind of the Twitter CEO. Yeah. That was becoming a self-claimed Twitter as CEO while there was a big chaos going on everywhere. Obviously, that was a joke, but somehow people really thought about that that's actually happening, which I couldn't imagine being a CEO of Twitter. But yeah, that was fun. And Lenz itself is a set of smart contracts and and tools that allow you to build WebTree social applications or make your application

Web3 social. And what it means that you can create things like Web3-powered handles, profiles, ability to collect content as well and make content available in the future. So something that's missing now in all this kind of like an internet social application is that these platforms are run by businesses, you know, and they can go down at some point. And we, we the people, we create a lot of these internet artifacts. And if these platforms are going down, we lose all those interesting, culturally relevant artifacts that we create online. So in a nutshell, it's basically a set of different tools that solve different challenges,

owning your audience, having ownership for that, having ability to store your content in a decentralized storage, and other kind of other primitives we call. So it doesn't solve one particular challenge that someone might have or want to use WebtreSocial, but actually solves multiple of those things. And it really depends of what the developers are building. So what of those primitives they actually want to use to solve their problem? So it can be as simple as adding a collect button into a blog post, you know, pored by lens, or adding profiles or a follow graph to your existing Web3 application or even traditional application. Okay, kind of I see why there are some aspects of social networks

where you feel uncomfortable with them being owned by companies. So tell us how LENDS functions. So you said it's a set of smart contracts, but who's written those smart contracts? Are they upgradable? Who has admin rights? So do they effectively belong to someone? Yeah, it's a good question.

So obviously at this stage Lens Protocol, I mean, we hit a couple of months ago a milestone of being one year online actually. So we've been building for two years now, one year live and still beta. So basically we're launching a V2, which is an improvement of what we had a first vision of what lens could actually be

and bringing more flexibility into what could be built. In terms of the smart contract itself, there's different things that actually provide immutability, for example, the ownership of your profile, so that always belongs to you. But certain features are still under upgradeability and mainly because it's very early, there is kind of like a soft governance at this point.

So we introduced two months ago, LIBS, short for Lens Improvement Proposals, and they're there for actually soft polling for the developer community and in overall the Lens community, how the protocol could be evolved, different kinds of improvements that could be made. But it's part of the whole process

of progressively decentralizing as the protocol gets more mature. And what ownership actually means is I want to pinpoint that is we have this concept about crypto in general that once you have your keys, you own the assets that are on that key. So we simply extend that idea not only covering, let's say, your crypto assets, but also the profile that you're using ongoing basis to communicate with other people and establish connections over Lens Protocol or wherever you are integrating Lens.

Stani, is it correct to view Lens as a developer platform for social media applications, meaning? meaning that Lens itself is not thinking of the sort of end user interface or the end user format in which content might be delivered. But rather it seeks to be one layer below where it provides a lot of primitives through which people could build, I don't know, Twitter Night Clown or any clone essentially of a social media application or an entire link. new social media application? Yeah, I mean, in the beginning, what we wanted to establish, our very early vision was that we have quite a good conviction of, let's say, what social media builders need to build and what could be built on with lens, actually. In a very beginning, there was a lot of discussion for the past couple of years about

the existing platforms and the lack of all. of user ownership, things like, for example, owning your handle or owning the relationships that you create with your audience, for example, from greater perspective or any user perspective. And also the idea that's how we can avoid, for example, censoring in certain scenarios. So how we can build more equitable social media networking behavior. So in that sense, we noticed that a lot of the applications were tuning into rhythm-based content. So if you look at the currency lens ecosystem, most of the applications are heavily relying on written text.

You also have some applications that are focusing also on audio and video, but they really are trying to solve existing kind of applications and making them just more Web3 power. And I think that's fine. But for what we think it's exciting is a fee kind of width lens enable the new experiences. So what if because of lens, it's more easier to build WebG social, meaning that as a developer or social media founder, you don't need to focus necessarily on rebuilding a network, but you could actually tap into a shared network. or have the flexibility to also create a new network if that's what you see as valuable. So the way I like to compare Lens protocol and the vision is similar to something like

Ethereum and many of the protocols in Dify that, or maybe on the underlying networks where you provide infrastructure for and design space for developers, creators and everyone to innovate. And the more you have that design space, you will see that innovation coming. So we basically have taken a couple of steps forward and trying to guide and think what kind of things could be build a lens. And today we have taken like 180 degrees back and thinking like how we can actually be less involved and how we actually can create more space for developers to build those new experiences and make the protocol less and less opinionated and more and more open.

And that's, for example, some of the features that are coming in the Lens V2 actually opens a new surface for compatibility. So Lens protocol, Lens publications talking to or interacting with the other protocols built on the same network. I'd like to take the analogy of Lens protocol being an Ethereum light. substrate on which lots of different social media applications can flower a little bit further. So I was around in crypto when the Ethereum white paper came out in 2030. And to me, like, White Alex genius was he saw a lot of different things that people were trying to build like MasterCoyne, Counterparty. Counterparty wasn't there yet. Mastercoin was the main thing.

Colored coins and Mastercoin and other applications that people were imagining. And he was able to come up with a primitive, gas-consuming virtual machine, the Ethereum virtual machine, during complete gas-consuming virtual machine, the Ethereum-Virchun machine, as a technical solution saying, if we had this primitive, all of these, application developers would be enabled at once. So you had to build just one thing and it would enable a huge diverse group of developers. When I hear about lens, and I hear about your vision,

it's almost like my skeptical mind says, I don't think there is something like a Turing complete virtual machine equivalent for social media that if I build this primitive, it's going to satisfy, a wide range of social media application developers. In my mind, it feels every social media application developers needs then be quite different, quite heterogeneous, and one primitive at the infrastructure level or two primitives at the infrastructure level

won't be able to hit diverse needs. So convince me otherwise that actually something like that is possible. Yeah, that's actually quite fascinating because that's exactly where we've come along. So we started in a way where we're thinking that each and every social media application has this particular set of features or behavior. So we basically can offer this as a protocol. And something that we learned why it's even just by building and developing and getting feedback from different developers and watching the user behavior and how these applications are built is that this social media landscape is very wide.

And offering a kind of like a protocol wide solution is always going to be quite difficult because it comes as a package. And what we noticed is that certain social media applications in most cases, they might have similar features. So they might have, for example, profiles, follow graphs, but then when you go to text-based applications, then you have publications, and publication you might have soft features as well.

And then a bunch of other things that might different. And that's the beauty of social. So the more wider the spaces, the more innovation we can see. And what we realized is that offering more of like a package protocol is actually quite difficult. And what actually works better is that we basically slice up the protocol and all the primitives that we have. So the things, how humans behave socially. So what are those things that we do not only on the Internet, but outside of the Internet? How do we form social capital or, let's say, relationships?

how do we produce content, how do we distribute content as well, and putting those into separate categories and offering them as primitives. And the key here is that a developer can actually choose what you need from that primitive stack that is Web Tree powered, because some of the elements of your social application doesn't need to be on the blockchain or doesn't need to serve required. data availability, but some do, depending on what is the use case. And I think that's the kind of like important thing there. So we have to figure out the existing primitives. And I think we kind of know them. We kind of see that, you know, here's the different primitives that social media applications are

using. But I think there's even like a bigger area to learn of what we can actually do with, Web 3 because we're, for example, using the blockchain, the ability to create digital scarcity or using the timestamp machine, and how do we kind of create new primitives? And I think that's the most exciting part of my work where we're looking kind of like more in the future and trying things out and seeing what are these primitives that could actually be very empowering for builders to create new applications. can you walk us through these primitives? So I mean the obvious first example would kind of be like a trust graph. Yes. And that's kind of the thing that probably definitely should be on Jane if anything is

going to be on Shane. And then kind of walk us through the other things that kind of you have identified as social primitives. I think the trust graph were social graph is an excellent example. So one of one interesting idea about the trust graph, for it. example, is that you normally when you build a social media application, you use a database and you usually have your user base. And those users aren't publicly visible where the users, right? But when you're using Web 3-powered social graph, that user base is actually public. And what's interesting there is that you can tap into that public in shared user graph as well. And for example, that if you create a new experience and you want to get everyone on lens to use it,

it's quite simple to enable a sign in with lens, meaning that you log into that application. And if you have a lens profile, as a builder, you can invite those users. So that mitigates the idea of cold start problem. And then there's kind of a layers of social graph and also layers of interest graphs. So you could look into the blockchain and see that, okay, what are people doing there? What are the social behavior or ownership factors that could actually be beneficial for my use case? And you can invite someone who has a lens profile, but also have specific categories of NFTs as well, because that might flag the interest that you have on chain verified data

and to use your application. So I find this part of social graph fascinating because it brings a new concept for users, for builders especially that haven't used to a shared graph or like a public social graph. Then there is a concept of profiles, and in V1, you have a handle in a profile that are combined together.

So each profile has a handle, but on V2, they're separated. So there's a profile NFT that give access to your profile in a handle, an FD that is basically a handle. And you can use also a ENS handle if you already own that. So handles are a way of identify who you as a user are and signal that out. But a profile is a fascinating primitive

because profiles can follow each other, meaning that you can form relationships on chain, meaning that you can actually create an audience. And once you have that audience, you can add programmability. So for example, let's say we have a user that has 100,000 followers. So you can actually share content and amplify content to your own user base, and you can monetize that amplification as well. So a creator, for example, can share content of favorite brands and also get automatically monetized.

So I would say that one of the key, even like, I would not even say a primitive, but maybe like a wider building function, is that you have with WebStreet to programmability, but also the build-in monetization as well. And then there is more, the tree native kind of primitives like collect. So if you want to add a collect button into your blog post or you want to make your piece of content, whether that's music or audio or video,

a tokenized asset and make it memorable and collectible, you can still do that as well. And with V2, obviously there's plenty of features, but the idea of open actions, it basically opens up to create any kind of a primitive to work with Lens Protocol so you could create a post that appears in your followers feed and it describes a DAO, for example,

you recently joined and you can ask other people to join the same DAO and instead of seeing a like button or a collect button, you might see a joined down button instead. That happens completely on chain. So basically what's fascinating here is that these primitives, they don't need to work in silo, but they can actually work together with other protocols and primitives that are already built and designed in WebTry on the same network, or cross-chain with oracles.

Is feed generation something that you think of a primitive? So basically, when I think of Twitter, which is kind of the main social network that I use, You kind of, you have two views to kind of see your feed, right? The for you, so basically where it's kind of somehow, where posters somehow prioritized, but you don't know how. And then basically the thing that just shows you everything in order. And both of them are kind of crappy. So kind of, I think, at least for me, I would actually be willing to kind of pay for more diversity in feed generation.

Is this something that could be implemented on top of Lens? Yeah, so obviously this is something that can be solved with the application level or services layer. There's one application that is, it's an open source front end for the Lens protocol, which is LensR. It's built in a hackathon in two weeks, but progressively has become kind of a place to see integrations between, Lens and other WebJ primitives. And something interesting is that there's a company called Karmau Tree Labs, and they're actually doing algorithms. And those algorithms are available on the Lensar feed.

And I'm pretty sure all the other applications they're implementing their own algorithms where you will start seeing actually service providers coming and building those Algos similar to the Karmatree Labs. And what is fascinating is that you can just select an algorithm and basically based on that, you will see the content. So what is mind-blowing here is that normally as an internet user, you're always forced into some particular experience. And this is also related not to social media,

but pretty much anything that is on internet. And obviously, D5 changed that a bit because you can move your liquidity easily, exchange your experience to something else. But when it comes to social, being able to actually use third-party algorithms seems kind of a cool idea and gives the user choice. So in some ways, I think even those algorithms are in some ways primitives or some sort of components that are built on top that could be reusable as well. or they can be even private.

But the biggest difference here is that because the way lens is built, the user has the choice. So you can make that availability for user to choose what algorithms you want to use. And if that experience isn't satisfying, the user can go to another application where there is that more, better experience. So we've kind of talked about things that should be on chain. I am sure there's many parts that are kind of by default off chain. Can you talk about those and how they are handled?

I think also we have one kind of like a layer between on-chain. So just to give an example, how the on-chain part works, is that you can transact on-chain. So you can collect, for example, content as an artist. That will be a on-chain transaction. but the actual content is reflected to a decentralized storage or data availability layer like RV for IPFS. And then if you don't want to do an on-chain transaction,

which is most of the cases. So if you have a funny comment that you want to add to a post, but you don't see the value of actually tokenizing that and make it more memorable, you could actually use a service we created, which is called Momoka. So Momoka basically allows to take content and create it and submit it into data availability layers. And what it means is that when we think about blockchain, the way it's built today, it has execution, it has a state, and data availability.

And what in some cases you need for content is only the data availability, but you don't need necessarily like the execution board. So you just want to ensure that the content is stored as an internet artifact for longer period of time. It's something we don't think about often, but like, let's say, if a popular blogging platform goes down today, what happens to all the artifacts that we all created that are very important today for us? So you can use data availability transactions, and then the off-chain piece usually is something that is built on an application layer. layer. So currently there are likes, but you can build, for example, privacy, private posts, and all the things that you actually don't need on chain infrastructure and the programmability and that verification that it brings. And it really depends on the use case, what we talked earlier.

So if you're building a publication application, maybe you use some of these primitives like, let's say, profiles, handles, then you're using Momoka transactions to store the content. Maybe you add a collect button as well to later being able to bring that content on chain as well if you want the users to do so. But it really depends on the exact use case. And that's why building a pre-social is very different from anything else I've built before because you really have to bring that optionality for the builders

and they essentially choose from what they actually want to use to succeed in their use case. What I'm curious about in technical architecture is, is there a tragedy of the commons problem in Web3 social? What I mean is this. So we have some, let's say,

have some primitives and some kind of social graph on a blockchain. And then there is a data availability solution which I think in Nensis cases is an air three where I think the data can be published. And anyone can come and build a user interface to all of one of this data. And as Figuereke mentioned, have basically their own curation algorithms, decide what to show. show to a user and attract users. And there's a competition between user interfaces to attract users. And hopefully that goes in a direction

where more users are satisfied. When I imagine this interaction as a builder of an UI, let's say like, OK, I start a company with two co-founders. We're going to build a UI on top of Netflix or all. I imagine myself in the beginning, building like code curation, but algorithms to filter data well. But as soon as kind of like the first level succeeds,

my incentive is to have some feature in which there is locking for the users. For example, if the users want to do a direct message to each other and that direct messaging system may not naturally fit a blockchain, my incentive is to build like a private data messaging, private DM layer in my user interface and have users message each other in my private DM system so that those users damn get locked in into my user interface as opposed to other people's user interface.

So in a sense, my selfish incentive is to break interoperability, ship that incremental feature which is not shared or the public graph because it is by having that extra intimate private feature that I lock users onto my user interface and develop a business model by selling attention or something like that. And so in a sense

and if you imagine me as one developer and there are 10 developers if the race to the incentive race behaves like that then actually none of us in the end are incentivized to

bury the public code which is like this public data and the of social data. So, another analogy you can take off it is there's this famous goat-herd pasture or the

tragedy of the common's problem, which is I have my set of goats and another quoted as a set of goats. Maybe they're 10 of us. There's public pasture where the goats can go and grace. But we want to do limited grazing on the public pasture. Because if you do too much grazing, then the glass dies out, the pasture becomes useless.

But my selfish incentive is to graze as much as possible because that's my optimal strategy. And when everybody follows their optimal strategy, nobody maintains the public pasture. So do you think there's a problem like that for social media where, the UI Bender's incentives will always go towards these private features and your data lake will in the end end up becoming a weak data. I love that you're already thinking of building something or less. But I do think that it's a very, very fascinating topic to think about because it really isn't

only like kind of like a talking point on the pre-social because well obviously I think that end of the day it really depends on what kind of network effects there exists right so so effectively for new application builders they might want to go with a let's say public shared social graph and get the value out of there and then build a delta on top because I personally think that the aspect of decentralization should exist where you create guarantees for the users or for the developers on some sort of objective. So for example, I will be very fun if less protocol is decentralized, but let's say there's maybe five of API services that are making sense of all the data and brings to the users or applications. As long as there is that endpoint where you can

always revert that, hey, I own my profile and, you know, we have a risk of the system not working. And that's kind of like removal of the root key is where the decentralization comes in. And for when you think about like new builders, for some might actually be that they want their own graph. So they look at the kind of like a public graph and try to make sense of it and think that this is good, but what we are aiming for, we want to do it in a different way. We want to create completely separate graph, for example, and maybe not making it shareable. And that's fine, because I do think there should be a public good layer that exists, and then there should be incentive for that, but there also should be incentives to building even layers

that might be more private, but they have the use case. As long as there's, that's, that that functional public good layer that works. So the same question comes in also in regarding, let's say, Ethereum, why people choose to build on Ethereum today, for example? Why don't just go and build on a completely new network that empowers on the third users? And a more simple argument now is that, you know, you can always build your layer two,

where we saw recently with MakerDAO, for example, looking at Solana's cold base and thinking of using that to build their own network. And there's a question like, okay, why we have kind of like a similar challenge. And then Lido is another example where, you know, there's a discussions where there's discussions of thinking of how these validators, staking pool validators could actually self-limit themselves. And I think these limitations really isn't servicing because I think that if a centralization is a challenge,

we have to innovate in a way where there's enough competition to build towards. In other words, for example, when we go back to the question of the shared social graph, the value there is obviously the data and what you could do with the data. in the user base. So this is the reason why, for example, a new developer wants to build on, let's say, Ethereum, even if the gas costs is a bit higher, because let's say there's a certain amount of users,

a network effect, based on those users, we can quantify, what are their data? So what kind of holdings they are, what kind of behavior in that creates network effects. So in some ways, I think what might happen regardless of flight plans and regarding even like

Ethereum and similar situations is that you will see traction of people coming and building on the same graph and that just empowers the graph and obviously makes it better so there's incentives as long as the graph

draws but there's also incentives to build something separate and less shareable as well and they might have those two different use cases. And I do believe, for example, like a public draft, shareable works pretty well when you're building applications that are all kind of like a public town squares, where you can use that public data, public discussions. You want to have data availability there. But then you might want to create an application that is some sort of members club, I don't know, for people who have kids, you know, and you have some sort of verification process there.

and you want to build on a separate graph. So that's possible to. So I think that problem exists everywhere, but I think something that really is tied to that is that liquidity in the data or what are the data is liquidity, but basically that's the reason why, for example, if people would choose to build on lens or build an overall build on Ethereum as well,

when gas was might be cheaper somewhere else. So I do think the problem exists everywhere, and it's some sort of balancing aspect of incentives that actually get people to build. I hope that's an answer that makes sense. Yeah, yeah, definitely. So I'm actually curious what the technical architecture looks like for these kind of public goods parts of the lens protocol,

and then the extension of the question would be, okay, if I wanted to build sort of a private group, which is a private DM or a group chat, private group chat, how would people build on top of it? What's the overall technical architecture of the Lens system? Yeah, I mean, the protocol itself is public good. So basically you will decide what elements you want to use from Lens. So for example, maybe the only thing you care about is handles.

profiles and then you basically build a database on top for private messages. And then you have encryption as well. And that's actually a good example of a good Web3 social application because WebExit social, it doesn't need to be Web3 social from head to the toes. I mean, in terms of like every single thing we have to solve with some sort of decentralization aspect because decentralization comes with a cost and where there's a cost there has to be some sort of other incentive value to do that. Handles make sense because you can trade handles,

profiles as well, because you can secure an audience. Maybe some of them become brands and they can be also tradable and you can also share revenue split, revenue between different applications, between different users as well. So I think we will see in the future very simple technical products built on lens or with lens, where you use maybe like one or two primitives, you even use a lens SDKK so you don't interact with the much of actual smart contract codebase, but through an SDK.

And then you add the things that you don't need the web trip part and the experience. And that's about it. I think it's fascinating because in most of the interesting things that you can do with social media applications, you have to do it very fast. So you want to build something in a month or two. And whatever you build, necessarily won't last long. So we probably will see applications getting a lot of user acquisition, but then you have very low retention. And I think that's okay. I mean, a social application might become like something compared to seeing, let's say, moving.

or other type of content where you do it once or twice or maybe three times and that's it. And we've seen this also outside of Web3 social. So for example, treads achieved 100 million signups very quickly because they did it on a shared network within their own platform and went down to 10 to 8 million and still is decreasing. So we do see this kind of like a challenge and it's just a new way of building. I think in this space. And maybe that eight or 10th application that you build and experience, that might have a better retention curve

and actually start having more stickiness. But if Lentz can make that process 10 times easier and reactivating already users that are on board and their friends, I think then we're in a very nice path. How many people have profiles on NENS to DEMS to? Yes, 120,000 profiles. It's really not a big KPI for us because the access is still in beta. So anyone who wants a profile, you can shoot me a DM, for example, we're at Twitter.

And I can let you in, especially if you're looking to build something. And down the line, I think profiles isn't really the best way to measure, even when we're in a permissional state, because the actual usage depends on the use cases. So I think it goes to the application level. I think we will measure more of some sort of monetization and how it empowers the actual developers as well. And maybe even the users, I think.

That might be our approach. So we're still working with the ideas of what we actually should follow, because it's very early. Yeah, absolutely. So, I mean, one of the reasons why you're in beta and you kind of need an invite to join is that your costs per active user are actually pretty high.

I read somewhere that it's around 400 US dollars per year. And I think kind of the monetization that we skirted like a couple of times now, that's kind of one of the parts that can address that. So how do you see this develop in the future? So the interesting way is that users always when they interact with the blockchain, obviously there's gas fees. If the network is on layer 2s or let's say something like Polygon, those costs are much lower. And the way we actually did the use, the way we built the experience across all the lens ecosystem is that as a user, you don't really sign for transactions and you don't pay for transactions.

So they're sponsored transactions. On a layer two, for example, the costs are much lower. So you could put them as a developer, you basically put those costs into something like your operation costs of like AWS and whatnot. But more recently, a few months ago, when we released Momoka, basically being able to do data availability transactions, I think we hit in total 640,000 transactions. with the total cost of $200 for all those transactions.

So what it means is that instead of doing an on-chain comment or even an on-chain post, we simply submit those transactions into data availability layer. And why this is radically innovative is that basically when you do social media interactions, you don't really need, in most cases, execution state, together with the data availability and you can reduce your cost significantly. So the user costs kind of are in the level

where the applications can even start sponsoring as long as they cover those costs somehow or they figure a way of either sponsoring or baking into their fees when someone wants to make the content on-chain. So that's kind of like a big improvement there in terms of the cost associated. And this is mainly because also social media data comes in balks.

And what I mean that is that the way the blockchain works is that you have a block time and a certain amount of space you can fill a block. And when it comes social media execution, your data is bigger than those blocks. So it's necessarily like you can't really feed a blockchain in the way it works. But you want to use it, for example, when you start creating handles and profiles and securing a follow graph, for example. So it's more about the design choices we made to create an architecture where these costs are mitigated, and you still have the features you need for the right primitives and then the use cases. So what would be the updated cost?

So basically, if 400 was the cost before Momoka? what's the cost per user now? So basically it's 0.003 cents per transaction. So it's quite, can compare to something like AWS, very much. Okay, yeah, that's, I mean, that's basically negligible. So why haven't you opened it up to the wider public? I was always at the end of the impression that kind of the cost is the largest reason here. Cost isn't the largest.

Yes, for us now we are currently focusing on shipping the version 2, which is already going to DevNet, and what it means is that you can start integrating Lens V2, already into existing applications, and start testing out. And then obviously the main net will follow once things are looking good on that side. So maybe then, I mean, we can open up, I think. Cool. So there's one more topic that I'd kind of like to cover, and that's governance.

You already kind of talked about the lens improvement proposals a bit ago. And I think this also addresses like part of Meher's question about kind of Eva Reaching this kind of lock-in application on top of lens. I mean, it's pretty clear that as a protocol, you need to be agile enough to kind of react to threats like that. So obviously you need some sort of upgradeability. How does governance work then? Yeah. Currently the governance is basically more of self-governance where you have builders coming and raising, for example, ideas

that maybe this particular way could be done. And differently or even from our team. So maybe we realize that something needs to be changed. A very recent improvement, for example, that we noticed that over social media, there's a lot of fishing attempts. And actually, there's increased amount of fishing cases where the users are clicking some sort of a link,

give away, and they signed a permit transaction, and what happens is that their NFTs are moving out. And this is basically the whole kind of like a WebTree user base that is affected. It's not lens related. But what we notice is that to mitigate this issue, we wanted to create a profile guardian. It means that the profiles are non-transferable

until you unlock this profile guardian. And what it actually allowed to do is that we saw a case where one user actually was a victim of a fishing attempt, but the profile guardian saved that lens profile but all the other NFDs were gone. So it's an interesting innovation that we basically did, and we proposed to the community, and there was a discussion about, you know,

how it can affect, and then it was voted in. But down the line, what's important is that as the protocol gets so-called like protocol markets fit, so we're still talking about a protocol that is zero to one, so it's not AVE protocol. You know, it has its market share, and that's a different story.

But once there's enough actually traction and it becomes important for developers to see it being updated constantly and it has traction, that's where kind of like the progressive governance kick in. So what will be the next step to decentralize the governance and what will be the step and how it involved the community? And based on my experience with Ava, it's quite lengthy process for sure. How do you see the current decentralized social ecosystem? So I mean, we saw friend.com emerge like two weeks ago or so and kind of quickly find its place somewhere.

Then we have Farcaster, Noster, Mastodon, and so on. How do you view that space? I do think like all these initiatives, apps and protocols, they don't really have yet a product market fit. But I do think all these. teams are working hard to get something. Some are more protocols like let's say Lens is a protocol that you can build those

experiences. Some are more of those end user experiences. And you can see even in the social media applications that have integrated Lens like orb or butterfly, they're constantly coming with new features and trying to kind of like find what might be exciting for

their existing users. I do think it's quite early. And I think we aren't in a state yet where kind of like decent social has a good product market fit. But I do think we do have those ingredients there that we can test. And our goal is that we want to provide the flexibility for developers to actually try new things, create new primitives, and see how that actually helps them. to get that product market fit and also at the same time be a bit of a bridge

and get new users that are not, for example, in the ecosystem yet because I think that's the bigger goal here. So if we're able to capture new users into Web 3 to new social experiences, that will be amazing because you can come into the space without doing a financial transaction and that will be

quite big paradigm. shift for our space. Cool. Thank you so much for joining us, Donnie. Where can people learn more about Lens and where do they shoot you a DM to kind of get an invite? Yeah, you can go Lens.X, Y,C, and you can join the wait list. That's the most fastest.

You can also try and send me a DM in on Twitter. If you're already a Lens user, you can follow me StoneyDup Lens across all the applications that are integrated Lens. Yeah, and be excited to see this podcast also on Lens and being able to comment there as well and my additional thoughts as well. Yeah, absolutely. I personally am on Lens.

It's my last name dot Lens, but I'm not very active yet, so we'll have to get better here. Thank you so much. Thank you for joining us on this week's episode. We release new episodes every week. You can find and subscribe to the show on iTunes, Spotify, YouTube, SoundCloud, or wherever you listen to podcasts. And if you have a Google Home or Alexa device, you can tell it to listen to the latest episode of the Epicenter podcast. Go to epicenter.tv slash subscribe for a full list of places where you can watch and listen.

And while you're there, be sure to sign up for the newsletter, so you get new episodes in your inbox as they're released. If you want to interact with us, guests or other podcast listeners, you can follow us on Twitter. And please leave us a review on iTunes. It helps people find the show, and we're always happy to read them. So thanks so much,

and we look forward to being back next week.