This is Epicenter Episode 512 with guest Stani Kulikov. Welcome to Epicenter, the show which talks about the technologies, projects and people driving decentralization, the blockchain revolution. I'm Frederica Ans and I'm here with Meher Roy. Today we're speaking with Stani, who is the founder of Arva Companies, the company the company unsurprisingly behind Arva, 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. This is. It's always great to be here. Cool. We had you on not so long ago. Then we spoke about ARVA V3 very tangentially. I think we mentioned Lens, but today we're here to kind of make up for that shoot coming. So sunny. 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 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 Lens itself is a set of smart contracts and tools that allow you to build the three social applications or make your application the three social and what it means that you can create things like.
Web chip forward 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 applications is that these platforms are run by businesses, you know and they can go down at some point and we keep be the people we. Create a lot of these Internet artifacts and and if these platforms are going down, we'll lose all those interesting, culturally relevant artifacts
that we create online. So in in a nutshell, it's basically a set of different tools that solve different challenges. Owning your audience, having the ownership for that, Having ability to store your content in a decentralized storage. And other kind of other primitives we we call. So it doesn't solve one particular challenge that someone might have or want to use the pre social. But actually solves multiple of those things and it really depends of what 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 bottom into a blog post. You know, port by lens were adding profiles or a follower graph to your existing web tree 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 lens functions. So you said it's a set of smart contracts, but kind of who's written those smart contracts? Are they upgradeable? Who has admin rights? So who 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 smartphone check itself. There's different things that actually provide immutability, for example, the ownership of your profile. So that's always belongs to you. But certain features are still under upgradeability and made it 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 therefore 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 are using ongoing basis to. Communicate with other people and establish connections over Lens protocol or wherever you are integrating Lens Stanley, is it correct to view Lens as a developer platform for social media applications?
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's it seeks to be one layer below where. It provides a lot of primitives through which people could build, I don't know, Twitter, like clone or or any any clone essentially of a social media application or an entirely 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 on on with Lens. Actually, in the very beginning that there was a lot of discussion for the past couple of years about the existing platforms and the lack of user
ownership. Things like for example owning your handle or. Owning the relationships that you create with your audience, for example from creator 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 kind of we noticed that a lot of the applications were tuning into written based content, so.
If you look at the car ZD lens ecosystem, most of the applications are heavily relying on written text. We 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 virtually powered and I think that's fine, but for what it what it what we think is. Exciting is a fee can with 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 and define that.
Or maybe on the underlying networks where you provide infrastructure for and design space for developers, traders 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 and think what kind of things could be built on 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 LSV 2 actually opens a new surface for composability. So lens protocol, lens applications 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 like substrate on which lots of different social media applications can flower a little
bit. So I was around in crypto when the Ethereum white paper came out in 2030 and to me like Vitalics, Vitalics genius was he saw a lot of different things that people were trying to build like master coin, counterparty. Quarter party wasn't there yet. Master coin was the main thing. Colored coins and master coin and other applications that
people were imagining. And he was able to come up with a primitive, a gas consuming virtual machine, the Ethereum Virtual Machine during complete gas consuming virtual machine. The Ethereum Virtual Machine has a technical solution saying if we had this primitive. All of these application developers would be enabled at once, so you have 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 pay 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. It's 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, you know, 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 quite. Even even just by building and developing and getting feedback from different developers and watching the the user behavior and and how these applications are built is that this social media landscape is 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 might have sub features as well and then bunch of other things that might different so. 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 we 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 virtually powered because some of the elements of your social application doesn't need to be on the blockchain or doesn't need to require 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 is even like a bigger area to learn of what we can actually do with Web Tree because we're, for example, using the blockchain, the ability to create digital scarcity or using the time stamp 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 and seeing what are these primitives that could actually be very empowering for builders to create new, new applications. Can you walk us through these primitives? So I mean the obvious kind of 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 chain if anything is going to be on chain. And then kind of walk us through the other things that kind of you have identified as social primitives. I think the trust graph where social graph is an excellent
example. So one of one interesting idea about the trust graph for 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 the three powered social graph, that user base is actually public and what's interesting there is that you can tap into that public and 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 assigning with lens, meaning that you log into that application and if you have a less profile you can as a builder you can invite those users. So that mitigates the idea of cold start problem. And then there is kind of a layers of social graph and also layers of interest graphs, so. You could look into the
blockchain and see that's 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 a specific categories of Nft's 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 new concept for users, for builders especially that are haven't used to a shared graph or like a public social graph. Then there's 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 in FT.
That give access to your profile and a handle, and 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 1000 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's one of the key event like I would not even say a primitive but maybe like a wider building function is that you you have with web St. programmability but also the the building monetization as well. And then there is more that three 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 a Dow for example, you recently joined and you can ask other people to join the same Dow and instead of seeing a like button or a collect button, you might see a
join Dow button instead. That happens completely on chain so. 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. In web tree 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 for you. So basically where it's kind of somehow where posts are somehow. Prioritize, 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's the can be solved on 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 lenser. It's built in a hackathon in two weeks, but progressively has become kind of a place to see integrations between lens and other web trip primitives.
And something interesting is that there's a company called Karma Tree Labs and they're actually doing algorithms and those algorithms are available on on the Lenser 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 algorithms similar to to to the Karma Tree 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 know 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 if I 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? Data handled, I think that's what 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 FTS that will be a on chain transaction, but the actual content is reflected to a decentralized storage or the data availability layer like RBF
or IPFS. And then if you don't want to do that on chain transaction, which is most of the cases. So if you have a funny comment that you want to add to a pause 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's in some cases you need for content is only the data availability, but you don't need necessarily like the execution part. So you just want to ensure that the content is stored as an Internet artifact for a 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 level 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 chaining infrastructure and the provability 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 normal 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 up three 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 Web 3 social? What I mean is like what I mean is this. So we have like some, let's say we have some primitives and some kind of social graph on a blockchain and then there is a data availability solution which I think in Nance's case is at head three where I think the data can be published and anyone can come and build a user interface to all of this data.
And as Figurika mentioned, have basically their own curation algorithms decide what to show to a user and attract users and is 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 a UI, let's say like, OK, I start a company with two Co founders, we're going to build a UI on top of network
call. I imagine myself in the beginning building like good curation, good 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 lock in 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 TM 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 my user interface as opposed to
other people's user interfaces. 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, I don't know, 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 incentivize to build the public good which is like this public data lake of of social data. So anyone other analogy you can take off it is there's this famous goat herd pasture or tragedy of the Commons problem which is I have my set of goats other people and other quote
herd as a set of goats. Maybe there's ten of us. There's public pasture where the goats can go and graze, but we want to do limited grazing on the public pasture, because if you do too much grazing that the grass dies out, the pasture becomes useless. But my selfish incentive is to graze as much as possible because sort of that's my optimal strategy. And when everybody follows their optimal strategy, well, nobody maintains the public pasture.
So do you think there's a problem like that for for social media where the UI bin does incentives it always go towards these private features and your data link will in the end end
becoming a weak data. I love that you're already thinking of building something or less with the but I do think that's it's a very very fascinating topic to to to think about because it really isn't only like kind of like talking point on the pre social because well obviously I I I think that end of the day it it's 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 and get the value out of there and then build a delta on top. Because I present think that the aspect of this centralization should exist where you create guarantees for the users or for the developers on some sort of
objective. So for example, like I will be very fine if this 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 end point where you can always revert that, hey you know, I own my profile and you know we have a risk of the system not working.
And that's kind of like a 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 the kind of like a public graph and try to make sense of it and 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's also should be incentives to building given layers that might be more private, but they have to use case as long as there's that functional public good layer
that works. So the same question comes in also in regarding let's say Ethyrium, why people choose to build on Ethyrium today, for example, why they don't just go and build on a completely new network that empowers on their
users. And a more simple argument now is that you know you can always build your layer 2 where we saw recently with make it out for example, looking at Solana's code base and thinking of using that to to build their own network and and and and there's a question like okay, why like 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 for validators could actually self limit themselves. And I think these limitations really isn't servicing because I I think that if a centralization is a challenge, we have to innovate in a way where there's enough competition to to to build towards.
In other words, for example, when we go back to the question of a shared social graph, the value there is obviously the data, what you could do with the data and 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 cost is a bit higher because let's say there's 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 and that creates network effects.
So in some ways I think what might happen regardless of flight plans and regarding event like Ethereum and similar situations is that you will see traction of people coming and building on the same draft and that just empowers the draft and and obviously makes it better. So there's there's incentives as long as the draft draws, but there's also incentives to 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 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 know you want to
build on a separate drive. So that's possible to. So I think that problem exists everywhere, but I think something that's really is tied to that is that like liquidity in the data or whatever data is like what it did. But basically that's why that's the reason why for some people choose to build a 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 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 OK if I wanted to build sort of a private good, which is a private DM or a group group chat, private group chat, how would people build on top of it? What what's the tech portal and technical architecture of the lens system? Yeah, I mean the the protocol itself is is public good. So basically you will decide, you will decide what elements you want to use from lens.
So for example, maybe the only thing you care about is handles and profiles and then you basically build a database on top for private messages and then you have encryption as well. And that's actually good example of a good web free social application because web free social, it doesn't need to be web free 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 cost, there has to be some sort of other incentive value to do that. Handles make sense because we 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 like 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 SDK so you don't interact with the much of of actually smart contract code base but through an SDK. And then you add the things that you don't need the the part and and the experience and and that's about it.
I 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 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 compared to seeing let's say movies or other type of content where you know you do it once or twice or maybe three times and that's it. And we've seen this also outside of that tree social. So for example Threads achieves 100 million sign up sign ups very quickly because they did it on a shared network within their own platform and went down to 10 to 8 million and and still is
decreasing. So we do see this kind of like a a challenge and it's just a new way of building I think in in this space and and maybe that 8 or 10 application that you build an experience that might have a better retention curve and actually starts having more stickiness. But if Lens can make that process 10 times easier and 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 Lens today?
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 know, you can shoot me, shoot me a DM for example, where Twitter and I can let you in, especially if you're looking to build something. And then down the line, I think profiles is essentially the best way to measure even when we're in a permission state because the actual. 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 a monetization and how it empowers the the, the, the actual developers as well and maybe even the users. I think that might be our approach. So we still aren't working with the ideas of like 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 U.S. dollars per year. And I think kind of the monetization that we scattered 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? They did. So the interesting way is that users always when they interact with the box and obviously there is gas fees if the network is on layer twos 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 2, for example. The costs are much lower. So you could put them as a as a developer, you basically put those costs into something like your operation cost of like a WS
and and whatnot. But more recently, a few months ago when we released Momocca, 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 of 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 and 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 make the content on
chain. So that's a kind of like a big improvement there in terms of the cost associated. And this is mainly because also social media data comes in bulks. And what I mean that is that the way the blockchain works is that you have a block time, 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 this is really like you can't really feed a blockchain in a 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've 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 Momoca, what's the
cost per user now? So basically it's 0.0003 cents per transaction. So it's quite compared to something like AWS pretty 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 largest for us now.
We are currently focusing on shipping the version 2 which is already going to dev net 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 Maher's question about kind of even Maher creating 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 kind of you need some sort of upgradability. How does, 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 realized that something needs to be changed, a very recent improvement parts for example that we noticed that over social media there's a lot of phishing attempts and actually there's increased amount of phishing 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 Nfds are moving out and this is basically the whole kind of like a web tree user base that that is affected.
It's not less related, but what we notice is that to mitigate this issue we wanted to create a profile. Guardian 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 phishing attempt but the profile guardian saved that lens profile but all the other Nfds were gone.
So it's an interesting innovation to be basically fit and we we proposed to the community and there was a discussion about you know how it's going to affect and 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 1. So it's not Ave. Ave. protocol, you know it 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 it kind of like the the progressive governance kicking. So what will be the next step to decentralized the governance and what with the step and how it involved the community? And based on my experience with Alba, it's it's quite lengthy process for sure. How do you see the current
decentralized social ecosystem? So I mean we saw friend tech emerge like 2 weeks ago or so and kind of quickly find its place somewhere then we have far caster master mastered on 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 excellence protocol that you can build those experiences, some are more of those end user experiences. So and you can see even in the social media applications that are have integrated lens like Orb or butterfly, they're constantly coming with 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 in a state yet where kind of like decentral social is 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 create, to get that
product market fit. And also at the same time be a bit of 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 three 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, Danny.
Where can people learn more about Lens and where do they shoot you a DM to kind of get an invite? Yeah you can. You can call lens dot XYZ and you can join the wait list that's 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 a standard up lens across all the applications that are integrated Lens. Yeah, and be excited to see this podcast also on Lens and and being able to comment there as well.
And then 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, 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 guest 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. I want it.