Okay, so welcome to our next talk by Water, who's going to talk us about Nostro notes
and other stuff transmitted by Relays, please help me give them a warm welcome.
Thank you everybody, thank you for being here.
I'm going to talk about Nostro.
This is, I think the first time somebody's talking about Nostro, like on a stage, outside
of our little Nostro bubble, we have our little Nostro events and conferences and stuff,
but this time it's like for general audience and open source developers at that, so that's pretty cool.
I'm going to be standing mostly behind my laptop, unfortunately, because I'm going to be
spate running through my slides. You can basically ignore the slides, just listen to my talk.
I'm going to do that in order to make sure that I'm keeping on track and on pace, so I keep
time to answer a bunch of questions. So please keep your questions in mind, come up with
questions and we'll have a bit of a discussion afterwards.
So because this is like Nostro outside of its own little environment, I'm going to do the
obligatory show of hands thing. So please raise your hand if you've heard of Nostro before.
All right, and keep your hand up if and only if you've used Nostro before.
Okay, and you can keep your hand up if you think you understand Nostro.
All right, perfect. Very quickly about me, about the customs.
I love Starker, brute war, and if you wonder why on the guy that's standing here, that's
hardly the reason, and for all the rest that just just go with it.
Okay, let's go. So this presentation, I'm mostly going to be talking about three things like the
story has like three parts. First, I'm going to be focusing on this paradigm shift.
From that, we're going to flow into Nostro, and then I'm going to try to argue why I think this is actually going to work.
There was a part before this that I mostly just cut out in the interest of time that I'm shortly going to address right now,
or not right now, we're just going to talk about Nostro.
So Nostro notes and other stuff transmitted by Relays was invented by some guy at the end of 2019,
and the opening statement pretty much sums it up, which is it's the simplest open protocol that is able to create
a censorship-resistant global social network once and for all.
It doesn't rely on trusted central servers, hence it is resilient.
It is based on cryptographic keys and signatures, so it is temporary proof.
It does not rely on peer-to-peer techniques, therefore it works.
So briefly, I'm going to talk about platforms because it's the social media thing,
and the reason I cut it out is because all the problems with social media and the central platforms
are pretty much top of mind, and I guess with this audience, most people understand what's going on.
So, why do we use these platforms in the first place,
well, apparently, because hosting websites too hard, right?
We could have all just hosted our own personal website and do stuff by that way.
We didn't, we all went to one particular website, they Facebook or whatever,
and started to make pages there.
So, what do these platforms actually do?
In general, they do three main things.
They manage identity and networks, right?
So, this is your account and the people you follow and people following you.
They host data, so this is your physical infrastructure,
for making sure that people get the pictures and videos and whatever.
And the last part I call indexing, so this is your search.
These are your suggestion algorithms and your feed, all that type of stuff.
So, what is the result of the fact that we're all using these platforms?
Is that they've captured network effect, right?
That's where the value is, everybody's there, because everybody's there.
But we also incur this censorship risk, right?
We're at the behest of these central platforms, and they can kick us off,
so our identity and our network and our data, et cetera.
All right, so let's go into this paradigm shift.
And talking about this paradigm shift, I'm talking about names, right?
So, the core of the paradigm shift is use of asymmetric cryptography or public key pairs.
And the thing is about names.
So, there is this notion of a Zuko's triangle.
It's a deal where there are three aspects you can only pick to.
It's about, you have one is human meaningful, right?
So, this is a name that you can understand.
For instance, Bob, Bob is a very understandable name.
You have this notion of the bottom left that's decentralized.
This basically means that you're able to create the name yourself,
instead of getting the name assigned by some central authority.
And the last part at the bottom right is secure.
And this means basically that the name is unique, right?
But if you interact with that particular name,
you're sure that you're actually interacting with that particular person and not somebody else.
So, because this is a game of you can only pick to.
We get like these options.
So, we have human meaningful and secure.
So, that's a top one.
It's like official, official seal of approval.
So, this is the one and only Bob, right?
There's no other Bob, this is Bob.
We have human meaningful and decentralized that results in others.
A little quirk in this line.
But it results in Bob, Bob, and another Bob, right?
So, there are Bob's everywhere.
It's very human meaningful.
It's also very decentralized, but not very secure.
And lastly, we have decentralized and secure.
So, this is based on these key pairs.
And that just creates this random string.
Now, if we are trying to solve central platforms,
we want something that is decentralized.
And we also want something that is secure.
So, just by sharing of elimination, we're kind of coming out at the bottom, right?
So, if you want to do an English scheme, we have to have to do it this way.
The thing is that public private key pairs suck.
They are absolutely terrible.
You shouldn't use them.
We're going to use them.
You shouldn't use them.
And why?
Because the problem is that you have this private key.
This is a secret.
And the thing is that you have to keep the secret super duper safe.
And now, the other hand, we're trying to use it in our protocol or in our system.
So, you also have to use it all the time.
And these two things are in conflict, because if you want to keep something safe,
you want to restrict access.
And if you want to use it all the time, you want to optimize for accessibility.
So, now, we want to optimize for accessibility and we want to minimize accessibility.
And these two things are in conflict, obviously.
So, we have to manage that.
And we have to manage that.
And the context that we're dealing with something that is not made for humans is made for machines.
So, there are a lot of mitigating factors to this.
And the interest of time, I'm not going to go into this into this now.
If you have questions about it, shoot.
We can talk about it.
Let me take a sip of water.
Now, we actually gain a bunch of this by using this system.
And what we get is temper-proofing.
So, when we use these cryptographic keys, we sign things,
and by the fact that they're signed, we can now verify that things are actually true.
And as a result, we're no longer trusting middleman.
So, it doesn't matter where data comes from, if data is signed,
because data is signed at the source,
and can be verified at the endpoint.
So, the steps that in between or where data comes from,
who is carrying the data, they cannot temper with the data anymore,
because otherwise it becomes invalid.
And this means that it now, the data has its carrying its own context.
It becomes its own little thing.
And when I mean by this, I can illustrate by this how the situation works now,
which is that we're kind of stuck in place in time with the question of what is an Instagram post.
So, I can assure you that this is not an Instagram post.
This is a picture that supposedly is an Instagram post.
What makes an Instagram post an Instagram post is the fact that it came from Instagram.com.
And that's the only way you can make sure that an Instagram post is an Instagram post
is that it came from Instagram.com.
And that that username is actually a valid username that's Instagram.com
telling you that is that username.
So, we're stuck in this place called Instagram.com.
And we're also stuck in time, because you have this time window,
up until that Instagram.com actually exists.
The moment an Instagram.com doesn't exist anymore,
your time window to verify that some Instagram post actually was authentic is over, right?
Because the authority is dead.
So, at that stage, you're lost.
Now, let's get going to Noster.
So, what is Noster?
Noster is signed JSON over websites and of presentation.
So, this is it.
For the most part, we gave people papers.
This also contains this thing and like a bunch of other stuff.
So, this is Noster.
So, this is a bunch of JSON.
And we'll let's go over it.
So, let's start at the second thing, which is the pub key.
Right?
So, these are your key pair.
So, this is the pub key.
And this represents the author of the event.
We call these JSON things.
We call them events.
And the second one is the created ads.
So, this is a timestamp where supposedly this event is created.
The kind, the third one.
The fourth one is that the kind.
It's a number.
It's just a way to specify what type of event it is.
Events can be all kinds of things.
And this is like a simple number system to reference what it's supposed to be.
And then we have like the actual meat of the event like what's going on.
That's separated in two parts.
We have tags and we have content.
Just think of tags as like structure data of men for machines.
And the content like stuff that is actually men for humans.
And then we go to the top.
We have the ID.
So, this is the event ID.
And that's just basically the name of the event of the reference number for the event.
Created by Hashing.
Oh, we've had before.
And at the bottom we have the signature.
So, we take our private key.
And we sign the hash.
And that way, we ensure that actually we are the author that is specified in the public key.
And that way, the outside world can actually verify that this event.
These loss or event is authentic.
All right.
Now, in terms of like a protocol, you can look at the sheet.
There's a bunch of things there.
But for the most part, this is it.
And I kind of want to go into like, is this an invention or is this a discovery?
So, technically, I'm not going to do the technical argument.
It is an invention.
But I'm kind of arguing here that it's a discovery.
For the reason that I'm started out saying, like, there's a paradigm shift.
And we start this paradigm shift because we are beginning with using public private keys.
And from using these public private keys, there is this logic unfolding.
And the only little hurdle that we're going to have to set is that, okay, we're going to have to set it.
Standard for a data format.
We're going to have to set a standard for the cryptography.
And we're going to have some standard for data exchange.
And it just so happens to be JSON.
It's a JSON chart of 56 from Schnor, and web sockets.
I guess the point is that it could have been something else.
It isn't, right?
The point is also that it isn't.
The point is that it is JSON.
It is a chart of 56 from Schnor, because otherwise it's not a standard, right?
So, it could have been something else.
It isn't.
Deal with it.
If you dislike the fact that it's JSON, I'm very sorry.
It's not going to change.
Just do with it.
I mean, the thing is, it's not that important, right?
It could have been something else.
It's fine.
Now, you probably think to yourself, if this is the entire protocol,
and people want to build like social media out of it,
or other types of applications.
How do you do whatever?
Like, the nuss of protocol is going to respond.
It's like, I don't care how you're going to do things.
You'll figure it out.
The protocol as such doesn't specify a whole lot of things.
That's great, because it gives you room to figure out those things for yourself.
I'm going to help you, because we're going to figure out.
This thing has existed for a couple of years now.
We figured a bunch of things out.
So, let's go back to the platform thing and there are three functions, right?
We have the identity in the network.
We have hosting.
We have indexing.
And we, with now, we're using these public private keys.
We basically covered two already.
We cover the first one, which is identity in network.
So, that's your public private keys, right?
So, I can create my own identity.
That's my own identity.
And then I can just follow these other public keys.
And that way I can maintain my own network.
So, I don't need the accounting of a platform anymore for that.
And because, as I explained, these nuss of events are their own self-containting.
They're not location dependent anymore.
We also kind of fix this hosting.
In terms of let it's not centralized anymore.
We can actually decentralize and distribute this hosting problem.
Because it doesn't matter where stuff is hosted.
It can be hosted anywhere.
And then the last part in terms of the indexing, so this is your search.
And your suggestion algorithms and all this type of stuff, your feed.
Well, let's go into that.
How do we gonna fix that?
Well, first, we have like a fundamental question, right?
How do we find anything, really?
Especially if there's nothing specified about it.
So, the safe and gray is about using these public private keys.
And hashing stuff is that we're using with unique identifiers.
So, we have unique identifiers for the events.
We have unique names in terms of using public keys.
So, because they're unique, you know what you're actually looking for.
And you also recognize once you've found it, right?
Because you can verify the thing.
And this is very important because, let's say you have nothing to go off.
This is, at least something you have, you can go off on.
Is that once you've found it, you at least know that you've found it.
And then we can build on top of that, we can just simply say,
Well, I can just tell you where you can find my stuff.
And I can sign that message and that way you can know that it's authentic.
And that way you're not being fooled.
So, the fact that things are signed, it's like, you're a different way to differentiate between
SQL and noise, right?
So, now we can just, I can just tell you where I can find my stuff or where you can find my stuff.
And I can put that, for example, in like a public repository.
Where everybody else is like a convention that everybody just puts this type of information,
where you can find their stuff, onto this public repository.
And now we're probably like covered 90% of the problem of where, where can you find my stuff.
So, this is the basic, basic thing.
We're, we're not, we don't have to create all these difficult or complex things
to try to get like the 99th percentile of the problem of finding things.
No, this very simple basic thing will probably cover like the most of it.
And then maybe for that last part, you'll either do more effort,
or we'll make more complex things, but we'll see later.
So, as a small aside, well, we're talking about Nasser and Nasser is like this,
Jason events, it's a bunch of text, right?
But there are also other things out there in the world, like pictures and videos and files and programs and whatever.
We're kind of like, in hindsight, I'm basically figured that we can do the same for that.
You just hash the thing, that was a unique identifier.
Therefore, it doesn't matter where it's hosted anymore.
And we'll just use the same logic of giving you hints as to where you can find it.
And the moment the link breaks, we'll just, we'll just re-host it somewhere else.
And now we'll update the hint list and hopefully the link is healed again.
So, we're not just about the location restriction, that's something I want to mention.
It's also that this time dimension, right?
Like I said, from Instagram.com, your stuck on Instagram.com,
but also you have this time frame, the moment Instagram.com is down,
your moment of verifying things, your moment, your possibility of verifying things is over.
And with using this schema, that's not the case.
Things can go down, things can be unhosted, and then suddenly pop up again,
and you can just verify them all the same.
You can put them in a clay tablet, you can put it in the ground.
People in a thousand years can dig it out of the ground.
They just have to type in the numbers, run the math.
And if the cryptographic computation gives true, it's all fine.
So, we're not restricted by this time element anymore as well.
All right.
So, imagine, I want you to imagine that there is this anywhere,
like these non-survents can be hosted anywhere,
and there is a little bunch of them, so it's other chaos.
So, we're going to have like science structured data,
in like this chaotic construction, it's just stuff out there.
It's this mist of, of, of, sign JSON events.
How are we going to make sense out of this?
And I guess the basic method of doing that,
in like an abstract where boils down to, is by applying these lenses.
And these lenses, like the simplest lens is basically saying,
I have a list of followers, a list of people that I follow.
It says endpuff, which stands for Nuster Public Key,
just to, to make it clear.
So, this, so I have a list of people that I follow,
and I use this lens to, to look through, to look at this,
this, this mist of sign, sign JSON.
And excuse me for using the, the old fallacy of,
that vision is a projection of the eye.
This is the case in my, my metaphor.
And once you apply that, you can now filter out a whole bunch of stuff,
and you only get the, the things that you actually were looking for.
And you can, what this stuff represents, right?
What these, these, the ulcer events, what this sign JSON,
what this represents, can be all kinds of things.
So, they, they can be tweets.
They can be blog posts.
They can be pictures.
They can be recipes.
They can be applications.
They can be climbing rough.
It doesn't matter.
It can be all kinds of things.
And the, the beauty is that you can leverage,
you're a network, these lenses, to, to figure out for all these different domains.
Right? So, if I'm very vested, I find like a very good network of all kinds of chefs.
Right? So, I have a good, constructive lens of,
I'm following all these chefs.
So, I have a good way of,
engaging the chaos that is recipes.
I can subsequently also use these people for,
when I'm doing climbing routes.
Now, they're probably not as useful in the climbing routes situation,
but they're still there, right?
And that's, that's basically the beauty that we're now also starting to leverage our networks for all their applications.
And that's something that I'm going to,
essentially later on as well.
Now, we're, we're kind of going to navigate, right?
We're used to serve the web.
I don't know how many serve people serve the web these days.
But you kind of want to be able to do that.
So, they're, they're basically two modes of,
modes of doing this.
One is end pop centric and the other is relay centric.
And the thing is, I kind of already explained the first one.
And because the first one was never specified anywhere,
the, the creator of the protocol just assumed that, you know,
this is, this is the logical way of doing things, right?
Obviously.
Hopefully, he's, obviously, that, as I explained them to you earlier.
But apparently, it wasn't that obvious, so it had to be, like,
made explicit, so now it has a name.
And the name is outbox model.
And it's very simple.
It's just that you declare where you host your stuff, right?
So in loss, so we have these, these servers we call the relays.
And basically, on the left is the person who's publishing,
on the right, there's the person who's following the,
Pamela, and in between are the relays.
And there's this whole dynamic going on with these,
this relay hosting things and then subsequently banning them.
And the whole thing of not being able to stock in a certain location,
like not being location dependent, is that you can switch
relays all the time.
So the moment you get banned somewhere,
someplace you can move to another place, you just update
the, your list of where you host your stuff.
And then the people following you can follow along with that list
and keep track of you, right?
They're basically don't even notice.
If you automate this stuff, they basically don't even notice
that there are relays banning you in this entire process.
And the other way of going through things is using relay feeds.
So now these servers, they can say, okay,
I'm just only gonna host particular kinds of data, right?
I'm only gonna host recipes.
I'm only gonna host pictures.
I'm only gonna host tweets.
I'm only gonna host whatever type of thing.
And the point is that they can use any metrics.
They can also say, I can only, I'm only gonna host stuff
by these people.
So for example, only accredited academics, right?
Only accredited academics can post to my server.
Or they can only post stuff about astronomy.
Or any combination of whatever you can imagine.
They can create their own environment,
basically like a website with a forum.
And that becomes a method for you as a user
to filter out things and get a feed.
The beauty is that basically,
Nasser is a protocol with like the whole point of
his censorship resistance, but it's pro censorship.
And what I mean by that is that because the user
is themselves our censorship resistant,
that allows relays like these hosting servers
to censor and moderate in whatever way they please, right?
You're not in each other's way anymore,
because you're not always stuck on the central platform
where you have to battle it out
in order to what the policy is gonna be.
Are we gonna do fact checking?
Are we not gonna do fact checking?
Oh, this is all this type of stuff.
It doesn't matter anymore.
People can just pick their own,
these really can really,
can pick their own policy because the users
at the other hand are like flexible
in how they move around, right?
So now we're gonna have what we get as a result
is freedom of association.
Because the whole point is that when let's say
I'm having an astronomy relay.
And I'm looking at an astronomy relay
and I see a very interesting astronomer there.
I start to follow that astronomer.
The moment I follow that astronomer,
it's not that I'm relying on that relay anymore.
I'm not relying on this little astronomy platform anymore.
I now have this direct relationship
with that astronomer.
I have his list where he posts his stuff, right?
So the moment he gets banned from the astronomer form
because he has controversial opinions,
I didn't lose sight of this astronomer.
So this allows this puts a lot of a way
of a lot of friction that we're currently involved with.
There are a whole bunch of other
challenges when you're trying to build a web
and you're trying to build social media
and you're trying to do all kinds of other things.
And I guess basically the main point is that
there are different places where you can tackle things.
So you can tackle them client side.
You can tweak things with the lenses.
You can create filters locally.
You can fix things on the relay side
or a combination of the two.
And the thing is with the client side,
it doesn't necessarily have to be like the client,
the user is using.
You can also outsource it.
And that's what we call DVM.
It's data vending machines.
It's basically a client somewhere else
that you can ask to do a job, right?
So we can imagine these lenses.
You can do, let's imagine,
constructing a very complicated lens where we say,
okay, this is the list of people about our follow.
Let's do a cluster analysis on those people
in terms of how they interact with each other.
And then we focus on that cluster.
And then we do an association for everybody
who's associated with the cluster.
And then that's how we built this complicated lens
right into projecting all these non-series.
Let's say that's far too complicated to do on iPhone.
So this is just something that I'm outsourcing to the DVM.
Or I can just outsource the entire thing
and just ask some other clients
like give me a list of events that I can look at.
So we have a lot of room in how we want to tackle things.
Let's talk about clients,
because we haven't talked about clients just yet.
And let's do a stupid statement.
Where I'm going to say that nuster is more like cloud computing
than cloud computing ever was.
So what do I mean by this?
Let's go over what the basic procedure of any nuster client actually is.
If I can get that kind of.
Let's assume we bought a new phone, right?
Fresh out of the box.
And we take this phone and we download a new client
or app on this phone.
Right?
So new phone, new app.
What we do is we basically insert our private key
and we're returning the key, right?
We're booting up the application.
And the application starts working.
What does the application do?
It receives these keys.
It sees the key.
This is the public key that is associated with this key pair.
Let me start looking for what can I find about this public key.
So it starts to find like profile data.
So this is the profile picture.
And this is the bio.
And this is the people that he follows.
And apparently he also has like there's also like an event
with general app settings where it states that he prefers dark mode.
So let's put myself into dark mode automatically.
There's only things that this starts to gather all these things
basically to initialize himself or initialize itself
into the context of the key pair that it just received.
And then it can start to run its operations.
So maybe it's a cooking app, right?
Or a recipe app.
It starts to gather the people, the chefs that you follow.
And then subsequently starts to turn out a feed of recipes that you like.
Or any other application.
And I guess we can do we have time?
Yeah, we have time.
We can go for like another example.
One that I'm very much like because most of the nostrils that you're going to use right now
are probably like Twitter types app, Twitter type apps like micro blogging.
But there's also an app store, right?
So you have like this nostril app store where you put in your keys.
And then let's imagine you have like nostril steam.
It doesn't exist yet.
But let's imagine you have like nostril steam.
You have your existing network, right?
You have your friends.
And just based on that, the client is immediately able to just look
like, okay, what type of games are not going to recommend to this person to download or play.
Based on what his network is playing.
So the point of it is that you're, because in the example that I gave is like it's a new phone,
it's a new app, right?
You're not restricted.
We were not restricted to time.
We were not restricted to location in terms of where it's hosted.
But we're also not restricted to a machine or we're also not restricted to a particular client.
Like switching to a different client is frictionless.
And that's the whole point of nostril.
So what's the result of this like a result of proper nosturing?
Is that we can actually leverage platforms for what they're good for, right?
Because the platforms were really good in the indexing part and gathering specific types of information.
And but we cannot get cut off from our following or the people that I follow.
And I can switch between apps without friction, right?
So that I'm stuck with like the Twitter app.
I can just use other apps.
And I can leverage my network throughout different applications.
And that's something I'm going to go into in just a bit.
And this result is of basically what we've done.
What we said out was to see if we can fix this problem where we have both network effect.
And because currently we have network effect in these platforms.
But we run censorship risk.
So can we actually solve this?
Well, the point is of my story here is that we actually solve this that we maintain network effect.
And that we've gained censorship persistence, right?
So we've solved our problem.
So how we're going to actually win.
Because, you know, these in common systems, they still have the network effect, right?
So my point here is that you're not going to win against X.
And this is why I hate the fact that Twitter is called X now.
Because I'm actually mean it as a variable, not as the.
So you're not going to win against Instagram on the merit of being a better Instagram.
Or you're not going to win against booking.com of being a better booking, et cetera, right?
Don't compete head on.
The way we're actually winning is by the fact that we're capturing network.
Because they got the network effects on the vertical, right?
They chose the specific domain.
Be it pictures or micro blogging or whatever.
Or cars like taxi driving.
They capture their vertical.
What we are able to do is like capture the entire horizon.
Because what we're able to do is keep maintaining this network effect over all these different applications.
So we're going to conquer the margin and from the margin we're going to take the sensor.
So we're going to have a marginal Twitter app.
And we're going to have a marginal Instagram.
And we're going to have a marginal recipe app.
And we're going to have a marginal booking.
And we're going to have all these marginal shitty apps that barely went anyone uses.
But the point is that the added value of the network effect of the.
These this interoperability between all these all these apps.
And the network that I can maintain through all these apps.
Or and through all these different applications.
Is that the added value is going to be higher than that it is than the individual network effects that I'm going to experience in these large centers.
And that's ultimately the the tipping point that we can achieve is that because we conquered all these edges.
At some point it just flips where now that that network effect of all these marginal applications is higher than.
The network effect individually captured into into these silos.
So we're going to have a small developer a denim here.
And that's because I'm going to try not to shit on the on the other projects just too much.
But I basically the point of Nasser is that like simplicity lowers the barrier of entry right.
The the protocol that you that we handed out this piece of paper the nipple one thing.
It's very simple and it's it's so simple it doesn't it's like minimal viable for nothing right.
Actually do seriously a built like build a serious application with just that standard you need other standards on top of it.
And this is what we call a nips nasser implementation possibilities.
But the point is is that basically the nipple one thing is that.
It's minimal viable for its own development.
It's all we actually need and then for whatever application or that we were trying to develop for we can introduce other standards build things on top of it that's fine.
But you can you can start out and think and say it's like okay when we want to make.
So for media so we have to take moderation into account and you know these these cryptography key pairs are really difficult so we need like an identity server and you you create this very complex stack.
And if I'm here saying well I just want to build a weather app I don't care about all that stuff I just want to build a weather app so if you're going to put all that stuff at the basis.
Now everybody that wants to build a simple weather app or simple agenda app now has to do with all that crap as well right so this this basically the point is like.
Sure if you want to create all these more complicated applications you need all the complicated stuff that's fine but it doesn't they that doesn't have to be at the base protocol that's basically the point.
Yes, I guess I'm going to I'm going to leave it at that and I hope I'm going to be able to ask or answer a lot of questions. Thank you.
Okay so I'll just repeat the question how do I deal with compromised credentials.
Cry.
I bought a forest for this purpose.
I can cry cry cry alone.
Don't be bothered.
I'll just or I'll just point in the you.
You.
So.
Your question is about like.
The your data being hosted and and if you're so the example that you gave is.
I I've created my profile like the existed for 10 years.
I've done a whole bunch of stuff in that 10 years.
I don't the existed on this one particular relay now that relay shuts down is by stuff gone.
Yes.
We're not in the business of selling magic.
We're we're not actually in the business of selling anything there's nothing to sell it's an open protocol.
But yes, there there's no magic the point is is then you're flexible so you can actually just.
You can host it redundantly on another relay you can.
You can you can save a copy so let's let's take this so you use a relay right out in the open a more public relay.
But you can save all these files if you save them locally on your computer and now that relay is gone you can just re upload everything on another relay.
Because you're like like I said you're not time-constricted anymore so if it's like if there's 10 days in between it there's a thousand years in between it doesn't matter.
But yeah, it's not where we're not in the business of selling magic data has to be hosted it has to be on a drive somewhere.
That is connected to the internet.
I've been given a mic.
I'm perfect.
Yes, that's better.
I hope this isn't repeating the first question but.
So because the identity is your public key the public key is your identity then.
That presumably there's no mechanism for key rotation and therefore if you lose your key or it's compromised.
That's it you just have to scrap it and start a little over from scratch is that right and if like isn't there any kind of key rotation mechanism that you could kind of build in wouldn't that be nice.
So the thing basically what you're asking for is that you're not solving the problem you're just moving the problem one step forward.
The thing is is that the answer is you can do whatever you can you can create a key rotation standard and you can implement that and you can start using it.
It's just going to be you're adding complexity that you cannot be assured that the rest of the network's actually going to.
The only thing that you can assure that everybody else can follow is this do or die key right now I'm not going to hold leave you dead in the water right there completely.
So one of the things that I got out of the cut out of the presentation will just address now before we get like ten other key management questions is the first thing is that.
This is a public private case for the masses didn't really happen for a very long time it's been used for a very long time we have PGP keys and the only people using PGP keys are like the crazy people sitting in this room right.
Nobody's mom ever used PGP keys now the the thing is that with the at kind of Bitcoin basically and this forced or introduced basically a larger industry of managing these public private keys where now millions of people actually do.
You manage these public private keys for their money right it's there's there's serious value going on and apparently it's good enough for them to manage money so now the our question here is is it also good enough for identity.
And if it's just shit posting online it's fine right if it's very very super duper serious and we're the president of some country maybe we can consider some key rotation scheme right but there's also like a spectrum of application going on here.
And also coming on with that fact is that because we're now because we have an industry that is trying to service key management for the masses.
There are also trying to develop best practices and hardware laws all that's type of stuff and also actual cryptographic cryptographic research so because we're using cryptography at the core we can actually start using these cryptographic magic schemes.
And we actually have it implemented so if you go to star dot and jump dot me you have a nice onboarding sequence and in that onboarding sequence it gives you the option to split up your key basically.
You get a link and now you can use this link instead of using your private key directly.
I'm not going to go into explaining that completely but these are like mitigating factors the last one is that there's a generational component to this right.
If you've grown up with this stuff it's a lot easier than if you're like an old fart already and have to be and have to change everything you do or change the way you think and start to managing these keys.
So it's also a matter of time so a lot more people are more comfortable in dealing with this stuff.
All right next question.
Yeah I just want one to say because I never heard of your thing you know what protocol.
I want to say it's really great because it's a big fight.
No for the freedom and you know to put down this big tech.
You know those that hold the Twitter Facebook and things so it should be free and it should be for everyone.
So I'm just wanted to say that and I will try to use it and to build some apps using your things so it looks really good.
Yeah it's just Jason you'll figure it out.
But it's really really cool and it smells like a bit pointing like a chain things like like you spread all around the web.
Things but it's really good.
I really think that there's no one place where you keep and sell stuff.
It's just everywhere so.
Right.
Very cool yeah thank you.
Yeah you said that you don't have to trust related and so whoever gives you the data you only check the signature and you rely on that.
Yeah either something that prevents me from other relay providing fake data to make people lose time until they verify the signature.
Either either with a huge amount of data and if you have no way to discriminate relays from one another.
You do have ways of discriminating relays of one and another.
Because they're just different servers right.
So you you make an explicit website connection to one particular relay and if you if you're getting just consistently get junk.
I guess you're just stop using that really.
As a client you can you can specifically include or exclude some delays.
Yeah yes very much so yeah to some extent you kind of have to to some extent you depending on what kind of application use so it's.
For instance it's very similar to if you think of these relay feeds like if you think it from the perspective of relay feeds and not what the the end problem.
It's following people and picking whatever relay that they use but specifically following a relay it becomes very much like RSS right.
But the instead it's very much like RSS but now all the stuff is signed.
Thanks for your talk.
Yeah.
Thank you.
Is there a economic incentive for running a relay?
So there can be an economic incentive by simply having a paywall for your like asking payment for your relay I use a paid paid relay.
Because the incentive for me is that I it gives me a certain amount of trust that they're going to be there next year.
Also if you it can also be people run servers or businesses run servers and they're not directly being paid for running those servers.
It's just part of their business right and they actually get paid for something else but they need to fact that they but they need a running a server.
Also it's like it depends on what you're doing running a server like running a web server basically is not necessarily a whole much of a costing.
Like unless you're YouTube right if you're YouTube it's like different but you know YouTube is like the hardest problem out there basically.
But there are a lot of simpler things maybe as a weather app I don't know how happy it's going to be as a weather app to to run that service.
But maybe you just sell your weather subscriptions and you you pay for the relay just basically affected your running a business.
But I have no specific answer to that question.
It's 2025 the internet is assisted for a long time now and servers are actually running and in a lot of cases nobody's directly paying for much of anything so.
I don't know hopefully we'll figure it out.
There is a versioning story such as if the encryption needs to be updated the algorithms need to be updated or anything like that.
I'm like my answer is basically just to like the same thing if you your keys or compromise is cry if if nor is compromised I guess we'll also have to well just have to cry.
Like implicit like I'd say in terms of like is there is it implemented in the protocol I don't think so no just as users if crypto is like if the crypto is broken we're going to have to use different crypto.
Hopefully we can settle on a new crypto at that stage.
So what you're saying is that you could just run a version number on things.
I guess the thing is you're you're basically running.
I guess you can specify you it could have been specified in the kind already right you can just use a different kind number.
If you're if you're saying okay we're using different events on the different standard you'll just give it another kind.
That's that's another way of of tackling the problem as well any other questions.
Oh yeah you to to paraphrase you said that the because it was too complicated for normies to set up a website perhaps mirror them they were driven into techno feudalism.
What is this soul for that.
How does it make things less complicated.
The thing is is that we can you can shop you can shop for your landlord I guess that's the point right the the thing with the technical feudalism is then.
And this is the point about local the being stuck to a location is that they they own the territory the thing with the internet is that in the internet we're not actually bound by by space.
But it's only because we're going to these specific platforms where now are bound by space they meet the space of their server.
And the whole thing is is that you can always just put us next server next to it.
And now we've created a whole bunch of new space right so the way you the way you solve the problem that you're you're depositing here is the technical feudalism is not we're not space constructed anymore you can just put another server next to it and now we've created more land.
You could always do that it was just complex to set up many mirrors to have proxies and relays and all sorts of things.
The whole point is that you're the reason people didn't do that was they were then driven to the central landlord and said they get it.
Yes, but the problem is this soul for that simplicity because mother going to use this.
Yes, so that was the whole central thesis of the presentation is that you are now stuck in this vertical.
With no sir you solve for it is that you're now we've now got network effect over all these servers.
So you're not you're not you're the network effect is not captured in the server anymore.
So you can so I get where you're saying is like okay it's you get let's assume that it doesn't relieve any complexity I mean running a relay can be as simple as just running a Raspberry Pi
But let's assume that it's that it's not and still got to be five servers the whole point of the protocol is that you're now you're network.
Your identity and your network is not stuck on one of each of these five servers or six servers.
I don't have a I don't have six separate accounts by at Facebook Instagram and these places I just have one profile that functions over all these six places.
So that's how that's how it solves for like let's assume that it does that still to complex and it's only going to be six servers and it's still better than what we have now.
And on top of that it's it's probably a lot easier to do self host at least for your own stuff.
Hi, let's say this protocol blows up to the size of Facebook Instagram Twitter et cetera.
How would this decentralized relay system hold a performance wise because the traffic can be really an equal or like where it's the space globally like how how does it hold up.
So I guess.
In terms of I guess my answer is going to be like a spectrum and there's going to be probably probably is going to be a power law.
And it's basically a tie into the to the to the answer I just get to the other question.
It's fine if there is like a large chunky server for a particular use case in order to do especially this it's also.
I have the two modes right.
The the relay centric thing and the the M pop centric thing.
So when we think about when we think about when when we think about a use case.
From this the empire.
Oh, I'm not sharing whatever when when we think about the use case from the the M pop centric stuff where we're just following people.
And I'm just trying to figure out where I can find stuff that they're posting their stuff is probably distributed over a whole bunch of relays right so in that in this case it's not that there is outside pressure.
From a whole bunch of people on one particular relay.
Because everybody is using the same relay it's a whole bunch of people are using a whole bunch of different relays so we got a distribution of load in that case.
It's more what more happens in the problem more arises on the relay centric mode of operating where we have like a very popular relay because they're like let's say the astronomy we have a very very very popular astronomy relay that the entire world that billions of users on the astronomy relay.
Then it's just it's just the same way of managing the infrastructure of web hosting than it is today.
Correct.
Yes, so and and the so like I mentioned is that we're we are able to leverage platforms because we can still use these platforms the problem the problem arises that the moment we have a platform that's very popular has a lot of users we run the censorship risk right.
But we actually solve for this censorship because okay you can be kicked off of this big platform but you don't you lose all your followers because you don't follow the people you follow through the relay you follow the people you follow for the fact that you know where to find their stuff.
Does that make sense?
Okay, so basically.
Basically your question is like what what prevents like an application or let's say a client what what prevents from a client that you're using or your phone to create a special relation to a relay and basically create proprietary.
A relationship between a client and a relay when it becomes very popular and basically start to undermine the the standard of the protocol because it now becomes it's its own dominant standard of the protocol.
The unfortunate answer is nothing except for our own vigilance.
Hopefully we can hopefully like hopefully we can bootstrap this thing fast enough and create enough network effect among all these marginal applications.
In a way that that it always outsizes this newcomer that tries to get wants to get big on its own right.
Because basically he starts to compete in exactly the same way that we are competing with the central platforms right now.
So the more we win against the central platforms it's very unlikely that the that we we're going to have to suffer this type of attack again.
Please don't speak without a microphone it's a bit disrespectful thank you.
We have time for more questions.
Last one.
Okay.
So you started out but problem with the verification and if one platform goes down and you can't verify anymore but.
I don't really see the nice thing is that you tie everything in the message so the message is standing on itself but the verification does not you do need to have somewhere where that public key is tied to the profile.
There is an authority that you can ensure like okay someone did not create a different duplicate profile with just a new signature and then it seems to be.
With my face on it or yours.
So how do you then still solve that problem that.
As the relays are multiple but then you still aren't tied to a single authority that needs to exist otherwise you can't verify anymore.
No so it's the I understand your question.
The the thing is is that.
You don't need a central authority to do this.
The basic the basic way to approach is is that we're face to face now we can exchange keys.
And as long as those keys are not compromised right that's always the basic assumption of this stuff but.
The most of these those keys are not compromised I don't I don't need an authority to know that that you are you right and that if you say that you're using these keys that I can identify you based on that on that basis.
And then if you know we have a bunch of people in common we now have like a web of trust type of thing where I mean maybe even.
Trust your extended network as well and when we have a bunch of extended networks we are very quickly start to.
Together like a hard large part of the population and maybe even everybody.
So that that's the web of trust is basically the the base of the answer.
Thank you.
I'm out of time so I'm thank you a lot for all the questions and see you on Austin.
There's always the whole of tracks.