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.