Trust is a function. It is more than just a feeling. In a world of infinite noise,
the only signal that matters is the one you verify. We are here to map the graph,
order the protocol, and build the immune system for the decentralized web.
Welcome to the signal processing layer.
This is Say What?
Welcome to the second episode of Say What?
Today we're debugging the intersection of AI and the web of trust with the architect Jesus.
We're tracing his build history through the protocol, from projects like DVM-CP and ContextVM to his latest one, Relator.
This is a technical deep dive into how machine intelligence can be engineered to serve human reputation rather than capture it.
A quick protocol reminder before we execute.
There are no corporate sponsors in this bunker.
This frequency is strictly peer-to-peer.
If you extract actionable signal from this conversation, consider returning the value.
Boosts, zaps, and streaming sats are the only proof of work that keep this node running.
You can also commit to the signal by locking in a subscription to PlepChain Radio on Fountain.
Let's get into the code.
Jesus, welcome to Say What.
hey thank you for having me here yes thank you for being here uh jesus i've uh i came across
i've obviously seen your name on nostril i've been on nostril for three years and it's come up in on
the timeline uh but i think i started paying attention around a year or so ago or it might
have been even less than a year when I saw something you posted about DVMCP.
And then after that, that sort of morphed into ContextVM.
And now here we are with your latest project, Relator.
But before we get into all of that, maybe let's just talk about your build history on
Nostro.
When did you join and what was your first project?
Nice.
Yes.
so I joined Nosser for a first time
three years ago as well
something around that
the first time that I heard something
about Nosser was
from a podcast
of a Spanish podcaster
he's a good friend
and he did a
shout out Luna, he's a good friend too
yeah
so he did a podcast with
Kameri
three years ago
something like that
and that was the first time that I heard about Nocer and yeah, my head exploded at that time
and I started to think about that more and more and at that time I was working for a company of a
friend where we were doing open source software and consultancy. Then I discovered Nocer and I
I started to put more time and effort into basically learning everything around it.
You know, everything related to how keepers work.
And, you know, identifying the relation between Nocer, Bitcoin.
And, you know, I had this aha moment after working in my first project in Nocer.
that was basically a little key storage CLI
that I call Nozzle Starter.
I created that because at that time
in Nozzle we didn't have too many clients
and the one that I used the most at that time
was one called Nozzle Console
which was a CLI client
created by Vichel, I think that is the name.
It's a developer that is not currently in Nosr, I don't see him very actively active lately.
But I started with that, I started with a key storage solution because in order to log in to Nosr console
you had to basically copy and paste the NSEC in the terminal.
And you know, bash and the terminal have a history, so it felt a bit insecure to let that private key float in plain text on the history of my terminal.
so yeah
so then I created this
little case storage basically
to load NOSER
console without
letting a trace of
the private key in the
history of the terminal
yeah that was it
that was my first exploration of NOSER
by the way
can I just
the key sort of floating around in plain
text. This is not as
uncommon even today.
There are some setups that
I've, you know,
so this stream now
is being live streamed, our conversation
on zap.stream, and
it's on my personal
server.
So I run my own instance of
zap.stream, and in the initial
setup,
it required me to
paste my raw NSEC
into the config file
obviously that's not the case anymore but it's it just goes to show that even today
your nsec floating around uh in in plain text is uh is a fairly is not that uncommon
no definitely not um i think that that is uh one of the most kind of tricky points of
nocer of the user experience
because, you know, it's a new
paradigm. Basically, you have keys
and the user is responsible
for managing those keys.
And right now, we have very good solutions
like things
like Amber and Remote Sign-In
that I think that is
the good, the best
UX for
key management. But
it's true. Like today, we're still
having private keys
in plain text floating around.
Yeah.
It's a task to educate the user
and everyone to
use the tools.
Yeah.
So carry on, Jesus.
So once you did that key storage
for the command line tool that you were
working on, what was...
Yeah.
Yeah, I started with that.
After that, I was
creating Nostry.
Nostry with
basically was
an alternative to Linktree
which I assume
you already know
this service to publish a list
of links for your
socials and
websites and anything
is very
used a lot in
the music industry by
groups and so on
basically to share links for their work
and
I created this nostril
was my first social client in Nosser.
Yeah, that was well received.
People are still using it today.
I'm a bit ashamed that I haven't
did any maintenance on it for some time,
quite a long time.
But I really need to revive it
because there is a lot of value there
and people are still using it, even if I'm not maintaining it too much,
which is a good sign because everything is still working and nothing broke.
But definitely it deserves a maintenance.
Can I, you know, something very useful, and I don't know if Nostry, I've seen Nostry,
I haven't used it extensively, but what would be super useful is if someone creates a Nostry,
and then they're at a meetup or a conference or something,
and they want to exchange contact info,
and they pull up a QR code,
and that takes them to their nostril.
And then there should be an export feature
that's able to export all of that into a contact link on their phone.
And I don't know how standardized that is.
I mean, this is not an area I'm particularly familiar with,
the contact data standard,
but whether it's portable across iOS, Android, Graphene, and so on.
But that would be kind of a cool thing.
You have your Nostri, it's a QR code that takes you there,
and then there's a button that allows you to export it directly into contacts.
Yeah, yeah, indeed that would be nice.
I don't know how it would work the support function in the different platforms,
but definitely it will work.
But yeah, Nostri was something good.
still something very valuable, I think
it's a good tool
and I have a bunch of ideas
because, you know
ahead from Nostry
I have been exploring the
contact
apps of Nostry
I, during
an edition of Cyberding and Generating, I was
working on an unreleased
app that
probably Gigi
will
shame me for
for that because I never released it.
I'm still there in the vault.
But I was creating an app called Colorillo.
Basically, creating...
What was the name of it?
Sorry.
Colorillo.
Colorillo, like a color in Spanish.
Colorillo, okay.
Yeah.
But the idea behind that app was basically to create a contact list application for you.
So you have all the details of your contacts, you can navigate them by a system of colors.
That's basically why the name, because at the time I was exploring the, you know,
extracting an X color string from the first six characters of the X public key.
and basically with that
representing all the contacts
in a palette of colors
basically to
have a way to navigate the contacts
without needing to search
I was exploring basically the relation
between the colors and the contacts
in some way to understand
if that
was a good system to remember
what contacts
belong to what color and easily or quickly navigate them.
And also that app, the goal or the vision behind that app
was to help you clean the contact list
because, you know, I'm sure that,
I don't know how is your contact list,
but mine is full of dead people, dead endpaps,
because, you know, my public is very old,
It's three years old.
There is a lot of people that I have been following that they are not in NOSR anymore.
I have thousands of contacts.
That's ensure that I'm putting a lot of pressure in social clients because every time I enter in a social client, they have to pull all the information from that.
And there are thousands of users of MPUBs.
my contact list so the idea behind colorillo was create a tool to help you navigate that contact
list and clean clean clean it up from all contacts from your own criteria like you use
the idea that is that you was able to
select or create your criteria to determine what are dead endpaps and whatnot and filter them out
easily.
So yeah,
I think that I'm going to
mix both. I'm going to mix
Nostry and the idea behind
Colorillo and extend
it through Web of Trust.
That is something that I'm working on.
So that was,
I was actually going to say, when we get to the Web of
Trust part, this to
me sounds like a pretty good use case, actually.
But also, do you
know the Daniel on Nostry?
Yeah.
He I think created an app a couple of months back called Something Zombies right And the idea is very similar Yeah yeah yeah I really like the idea
I think that's Zombies versus, I don't know.
I don't remember the name exactly.
I don't want to be wrong.
But yeah, I know what app you're talking about.
It's very fun.
And I really like it.
So yeah, it's a very similar concept.
I don't know exactly what is the criteria behind.
the Daniels app, but it's similar.
It's basically helping you to clean the contact list.
And that's an important point for a lot of non-technical users
to be aware of, which is every time your contact,
and you mentioned this, right?
Well, first of all, it's nice to have a clean contact list.
Why do you want to have dead zombie endpubs in there,
like people who abandoned the protocol and have disappeared.
But the other thing is you put a load on a relay every single time.
That thing loads, right?
Yeah.
Oh, yeah.
And it's also a kind of a fingerprint, you know.
Your social graph is somehow a fingerprint of yours,
a social fingerprint.
That can be some privacy concerns there as well.
But yeah, the main case for me to clean your contact list is to keep it healthy, because
the contact list is in Noster now more than else with the, you know, web of trust and
rankings and trust desertions and so on.
That contact list is being used for different stuff.
it clean is basically helped Nasser to be more healthy to have better
calculations or things because that data is used as a source of
truth for these computations so it really makes sense to have it clean so
having tools to clean it to clean that is something important in my
point of view.
So, Coloreo is
waiting for web of trust
integration.
So, we'll get to that when we talk about Relator
and the work you're doing there.
So, what happened after Coloreo?
I mean,
a lot of things happened
after and before
Coloreo. But
at that time, I was already participating
in sovereign engineering.
and I was part of the first, the participants of the first cohort, was lucky enough to be part of
that and it was magical to be honest, kind of turning point to meet all that talented people
and share a space with them and share discussions and ponchas of course.
so yeah I have been working
a lot in Nosser
in different projects
all of them are public and open source
I have been
helping and
contributing to different projects
in the Nosser ecosystem
I was working
for
I was working with
guys from Preveo Markets at some point
also
with other people.
Now I'm
contributing to Marmot ES
as well. There is
Marmot protocol,
MLS and white noise.
We are doing
this TypeScript
implementation of Marmot
protocol, which is
very cool.
Soon we'll flourish.
Excellent.
I think a lot of us
are waiting with bated breath for Marmot to manifest itself
so that it can finally stop using Signal and Telegram
and move to something Nostro native.
Yeah, it's coming along pretty nicely.
We already have working demos for basically a chat application,
everything running in the browser,
implemented with our Marmot TS implementation.
it's pretty nice to see
to be honest
I think that that will unlock
a lot of things
So let me
I should probably get Jeff G at some point
to talk to him about this
but from your understanding
obviously White Noise is
a reference implementation of the Mahmoud
protocol but there will be others
like the TypeScript one that you're working on
or maybe you're working on libraries
someone's going to take your TypeScript libraries
and actually build another reference app on the Marmot protocol, right?
Will messages across these implementations of Marmot be interoperable
or will they be siloed?
Yeah, yeah, they will be interoperable totally.
I mean, they should be, definitely.
MLS is a quite complex protocol.
It's very cool, but quite complex.
and this complexity means that there are subtle details that you need to take care about
to basically be interpretable
and those little nuances are the things that are difficult to manage
or to get fully because the RFC of MLS is a very long document
and very difficult to transverse.
But it's a common protocol.
If we get it right,
and I think that we are doing it right,
definitely it should be interoperable.
It will be interoperable, yes.
And I understand it in theory, right, Jesus?
But the reason I'm asking is,
DMing is so broken on NOSTA right now.
And I'm not just talking about NIPO 4.
right is there's there's some clients that implement gift wrap their nip 17 the multi
malmi uh bless him is working on on double ratchet for iris yeah and now there's going to be these
marmot clients so like so someone obviously so for folks i'm sure everyone knows as well just
it's worth saying if you're using a nostra client that only supports nip or four and someone sends
you a nip 17 dm you're not going to see it right and the other way around i mean typically
yes, a lot of the NIP 17 clients have just said, you know what, I'm not even going to deal with
NIP 4. So if you, there's no communication. So if some, for example, someone's iOS user and you're
using Nostor, I believe Nostor has moved almost fully to NIP 17. I don't know if they've still,
Fabian has still kept the support for NIP 4. But let's just say they've moved fully to NIP 17.
If I send them a NIPA 4 DM from Primal or from Darmus,
they're not going to see it, right?
So it's just so broken.
There's no interoperability in DMs.
And there are all of these different implementations coming out.
So that's kind of where my question is coming from,
given how complex Marmot is, or the MLS is, rather, right?
So I think if someone can solve that problem properly and cleanly,
it'll be amazing.
yeah yeah definitely um you know i have a very controversial opinion about dm and on nocer
because definitely nipo 4 is something very bad for your privacy but it's the the communication
channel of last resort because everyone is going to be able to see it and even if even if you are
and someone could carry your message to the receiver.
Even that, you have very bad privacy, but it works reliably.
It's something that we should not use for regular communication,
but I think that is a very interesting perspective to have about Nipo4
that is the last resort communication.
It's very simple.
It works.
It leaks metadata, for sure.
But it works.
But ahead of that controversial take,
what we are doing in Marmot at the end
is creating high-level libraries.
So developers doesn't need to worry about
the low-level details of the protocol of MLS.
That is very complex.
They can use built on top of the high level libraries that they care about, or the lower level details.
I hope that someday we have a consistent environment for the DMs of Nosr,
because I think that there is a very good use case.
I don't know if the answer is to put things on relays, because that intrinsically means that the data in some way is public.
So maybe the solution is to, I don't know, use ephemeral events, use relays as a transport, but not relying on them for storage.
and in some way
MLS or Marmot
it's like that
because a lot of the thing
that allows users to use
MLS or Marmot
protocol happens client
side
what
is transmitted by relays are
very cryptic
blocks of encrypted
data
which doesn't mean nothing if the client
if the user client doesn't have the correct data.
So there is a lot going on client-side.
What happens on the relays is very cryptic.
So yeah, I don't know.
Definitely it's a good solution.
But yeah, let's see how it plays out.
Yeah.
All right, so let's get to, let's fast forward.
You were part of the first Sorbonne Engineering Cohort.
So when was that?
Like late 2023, early 2024?
I think that was the one that you had that huge presentation
at Bitcoin Atlantis, right?
Like it was supposed to be half an hour, one hour presentation
and it ended up being like four hours or something.
Yeah, yeah, yeah.
That was really fun.
That room was, I tried to get in.
I couldn't get in because there was like people spilling out of that room.
Nice.
Yeah, yeah, yeah.
That was really good.
I mean, the experience in sovereign engineering, the first one and the rest of them,
I have been participating on almost all of them.
But the first one was kind of special because of the Bitcoin Atlantis happening just straight after the cohort.
so it was
really magical
to basically end the cohort
with a bunch of
new ideas, with a bunch of
new friends
and be able
to present all of that
in front of people that
cares about the thing that you are
building
and yeah that was really nice
I will have good
experiences about
Sovereign and Geren
and recommend everyone to
I mean every engineer
interested in us to participate there
because it's a good experience
And we're only seeing the benefits
of some of the work that went
there now, when I say we
I mean as just regular users
the people, right, like stuff like Blossom
came out of, it might have come out of the first one
right Jesus, or was it the second
Yeah
Yeah, yeah, first one
Yeah, so Blossom came out of that
other things which I'm forgetting right now.
And we're beginning to experience the benefits now
of all of those things a year and a half later.
So that's really cool stuff.
For sure, people should check out Sovereign Engineering.
Shout out Andre Loja as well from Free Madeira, Bitcoin Atlantis.
He's one of the unspoken heroes of that, of Sovereign Engineering.
Yeah, yeah, yeah.
I mean everything happens in his co-work. He's a very nice guy. Yeah, I mean he's really nice.
Free Madeira is a very cool group of people and they do meetups. There is also the people
from the bitcoin work there in madeira which is really nice there is a good community there Yeah for sure
Let's fast forward a little bit by a few months.
Bitcoin Atlantis was March of 2024.
Let's get to September, October of 2024,
when really, to me,
a lot of the AI acceleration became apparent to people.
Before that, people were using ChatGPT for silly things.
But then the reasoning models came out.
Then MCP servers came out.
All of that was happening in late 2024, right?
So I think early 2025, you launched DVMCP, correct?
Yeah.
I think that's a week or two before servering Engineering 3.
because I remember to
to see
the specification of MCP
because
that came out as you said
late 2024
the first specification of MCP
and then I
got it
used earlier
2025
and started with the specification
and that was used
some weeks before
Sovereign Engineering 3 start.
I was reading the spec, you know,
and I was realizing, okay, this is JSON RPC.
All the communication is JSON RPC.
Everything is JSON.
JSON schemas.
Wait a second.
I know a protocol that is JSON-based
and is transmitted by the race.
And, you know, then I have that spark in my head
and I said, okay, this is an interesting way to,
it's something interesting to bridge,
basically, NCP and Nasser.
And yeah, I started to work.
First iteration was called DBNCP.
Yeah, then I moved to Context VM,
the rebranding for different reasons.
We can talk about that.
But yeah, that was more or less a timeline.
And maybe let's talk about ContextVM, and then we'll get to Relator right after that, Jesus.
For someone who's listening, and maybe they've seen some of your posts, but they haven't actually sat down and used ContextVM,
what exactly is it? How can, well, first of all, is it a tool for regular users, or do you need to be a technical person to use it?
I mean, context-vm itself is a protocol, basically put together in OCR and MCP.
A bit of history about this and why I moved from dbmcp to context-vm is that at the beginning
when MCP was something unexplored,
I wanted to learn about the protocol,
you know, about the insights of the protocol,
about the weeds, getting to the weeds of it.
And I developed DB MCP as a kind of following
a kitchen sink approach, you know,
like re-implementing big parts of everything
in order to learn.
then
after working with
MCP
for quite a while in DBNCP
I realized that
you know
the best place for no service
is to sit at the transport
level of MCP
and just worry
about carrying messages
through the channel
to the transport layer
which in this case is relays
and it used basically a public key cryptography
of Nocer for authentication, authorization.
And basically, when I realized that,
when I realized what is the best design
or the better design for this,
I moved to ContextVM.
I rebranded to ContextVM.
That was one of the reasons.
other of the reasons that dbmcp started following a more dbm-ish approach or you know where dbms
have this job kinds for for sending requests a different job kind for for receiving the request
and another kind for feedback.
So you have three kinds for a normal operation
and you also have segregated kinds for jobs.
So for example, if you want algorithmic feeds,
you have a kind, but if you want a translation,
you have a different kind for the job that you are requesting.
So when I was developing the BNCP, I followed that pattern.
And then moving forward to Context BN, when I realized the best place for NOSER in the MCP ecosystem,
which is sitting at the transport level, I moved also to a more minimalistic approach,
where I moved to ephemeral events,
which are events that are not supposed to be stored in relays.
And also I started to use one kind,
one single kind for all the communications,
for requests, responses, everything in the middle.
So basically I was treating that kind as a kind of socket,
as a kind of pipe with relays.
And all of that seemed enough reasons to move and to rebrand the project.
And also, at that time, there was a project called DB-MCP as well in the MCP world
that stands for Damn Vulnerable MCP.
which was a kind of hack-the-box MCP
basically to discover and to explore the security model of MCP.
I didn't want it to be related with that.
And different things, so I decided to move forward
and to rebrand it as Context VM.
And I think that was a good decision, to be honest.
So if I wanted to use Context VM today, and let's just say I'm a semi-technical user, what type of use case could I use it for and what would my steps be?
I mean, the cool part of this is that you can do anything you want using this server client architecture.
because one thing that I haven't mentioned yet is that, you know, everyone,
and this is one of the questions that I received the most, one of the most common doops,
is that, okay, MCP is something related with IA.
So I don't want this to play with LLMs or nothing like that.
and I mean the thing to understand here is that MCP is a protocol for communicating
and it has a client-server topology
and it uses JSON-RPC as the underlying schema or shapes of the messages
so it's really a protocol to connect things
you know uh it used that it was created specifically for for lms uh to connect with
external tools but what it really is is a protocol to connect tools you know or external things
between between client and server um this is what this is why you can why it got so so hyped
because basically everyone was able to connect their Gmail account
to their LNMs or their calendars or their databases or...
File system, which is a big one.
Yeah, their file system, exactly, or domotics, you know, through NCP.
And that really pumped the protocol
because it was the first standard way to provide these tools to LLMs.
Before that, we had a tool calling or function calling
that is something similar to NCP,
but in a more lowest-level approach.
But yeah, basically, NCP is a protocol to connect things,
to connect clients and servers to perform this communication.
It's used that it's designed for LLens, which is something interesting because it comes with different fields in the schemas of tools and the server, which are thought basically to put natural language there.
So you can put titles for the tools, descriptions.
You have a field that is called instructions for the server.
So it's really a mix of natural language and JSON schema for defining the shapes and the types and so on.
which is very interesting because it creates a self-describing server
or a self-describing service that doesn't require a standard source of documentation
to understand how it works or what each tool does
because it already comes with a natural language description.
So it's very interesting.
um yeah so has this let me ask you this uh just a specific question about this
was one and you know when mcps came came out it was over a year ago right late 2024
yeah the cool thing was you could then use your uh cursor or uh or even visual studio right if you
visual studio code if you if you use some a plugin like cline you add your mcp servers then you can
point it to a folder or a directory on your computer.
It can look at an Excel file.
It can do stuff for you.
You write it in natural language, and then all of these cool things are happening, right?
You can aggregate receipts and all of that stuff.
One thing I haven't found, and maybe this is just I haven't searched properly,
or I just have had bad luck in finding it, is when you're building an app,
Vibe Coding an app, let's just say, and you deploy it somewhere,
is there an MCP server
or can I use context VM
that allows me to plug directly
into the browser console
and look at the errors that come there?
Because that's kind of a big deal, right?
There's a lot of these vibe-coded apps
when you deploy them
like you've got to go through
the way I do it is I go to the console
I copy the error
I put it back in the LLM
and the LLM has to interpret
and it's a complete nuisance.
is there a way of automating that?
Yeah, there are different MCP servers
that give you that
I think that the first option
that we had for that
was the Playwright MCP
Playwright is a kind of framework
to do browser automation
through scripting.
Basically, you can use that to
automate your browser
and, you know, get all the details
from executing or from loading
a page or an address.
And that's already something that you can use for that
to basically debug web applications.
So yeah, there are solutions already.
You don't need a context VM for that.
The use case for context VM is basically to have a remote service or things that are running elsewhere
and to be able to connect like you are connecting to a local server.
Because even if it's remote, you can connect to it without any hassle or any difficult configuration.
because everything works over Nocer and use relays as a message buses.
So you don't need to worry about IP addresses, DNS, firewalls or nothing like that.
You could basically spin up a context VM server from a coffee shop or something and it will
be reachable instantly through Nocer This is quite powerful and I think that there have been a lot of different and crazy experiments around that Pete Wien that is a good friend and I also a big fan of ContextVM he did an experiment
on basically running a ContextVM server over the WiFi of a plane.
He was able to receive a request during the flight.
It's pretty crazy to think about.
Mile-high club for ContextVM.
What's that?
Now, the mile-high in the air
and you're receiving ContextVM requests.
But yeah, that's pretty cool.
Yeah.
I mean, you can run it in a server in your phone as well.
You can run it in a Raspberry Pi.
The possibilities that come with basically putting a service online without any hassle
I think that are quite interesting
There are different people working on projects apart of me
that are really creating some really cool stuff
But yeah, I don't know if I explain this properly
please just ask if you think that I can explain it better.
No, that's great. That's super helpful.
So, Jesus, let's move to Relator.
And I think that's the one,
that's the Web of Trust solution that you rolled out.
That was, what, a month or two ago?
Right? Relator is pretty new, isn't it?
Yeah.
Yeah, I think something like that.
I don't remember the exact dates, but yeah, a month or two.
Yeah, Relator was the result of different conversations that we had during Sovereign Engineering 5,
especially around conversations with Gigi and some of them with Hazard as well.
you know, it came from
a natural frustration
because
in Nosser, currently
we don't have an open source
solution to do
what Vertex
started to do, basically.
And the frustration was to
basically have something open source
that you can run and that you can understand
and reason about
that everyone can run
or anyone can run.
and it offers
same kind of service
that Vertex
which is a pretty good service
shout out to Pip
but yeah
it's something close
and the idea
was basically put together
something open source
fully self-hostable
with the idea of
that it could run anywhere in the computer of a pleb.
You don't need a very expensive machine to run this,
but you can run it in a Raspberry Pi even if you want.
I mean, the public instance of Relator that we are running
which receives a lot of requests
because I integrated with Waterlight.
There's another project that came from this exploration.
But basically, my instance of Relator is receiving a lot of requests
and it's running in a very cheap $2 VPS.
It's still performing very well because, you know,
it has response times of 50 milliseconds or 40 milliseconds for search.
it's behaving pretty well,
it's quite performant and efficient.
So it can be run anywhere.
That was the idea behind Redator, create this.
So actually, let's talk about that,
the compute requirement, right?
So you mentioned Vertex, which uses personalized page rank,
which is like a take on Google's original search algorithm,
right page rank the other web of trust service provider is uh is brainstorm which which is
nosfabrica is developing that one uh it looks at follows meets today anyway it's extensible but
today just looks at follows meets and reports you can obviously add other signals like zaps and so
on if you want to looks at those it comes up with scores completely personalized and then publishes
them using trusted assertions and then there's relator what is the algorithm so well actually
before you answer that both in the case of personalized page rank and in the case of
brainstorm which is which produces grape rank you know it's computationally incredibly intensive
because you have to go through this entire graph database right and crunch through all of these
numbers and it's
tricky to run those computations
on a Raspberry Pi for instance
so what is the algorithm
in the case of
Relator and how are you able to get it to
run
in a low compute
environment
yes so
basically
yeah I think that
the algorithm behind Relator is
very close in the spirit
to grape rank
because both
basically use different
signals to compose
the thrust or the score
but the
algorithm is basically
a weight formula
of different components
that at the end are
crystallized
and zoomed in a
number between
1 and 0
You know, everything is a floating point, a floating point number, a float.
And basically, it takes different signals or different validators, validation signals,
and the perspective of a source pubkey, which basically is used as a kind of rule of thumb
to have a component in this formula
that weighs 50%
in the case of the instance of Relator that we are running.
Because the cool part of this is that
by running Relator, anyone can tune that,
can tune the algorithm,
and can tune the weights that compose the algorithm.
So basically, you have this component
that is the primary component, which is the social graph distance between the source public key
and the target public key that you are attempting to perform the calculation.
And the distance between the source and the target is then translated to a float,
basically using a decay function. So for example, if the source pub key and the target pub key
they are one of distance, the output is one, okay, the result of that component. Then if the
if the distance is two,
the decay function basically map that
to a float number as well.
In the case of the data...
Sorry, just so I understand the concept of distance,
you mean hops, right?
So if you're following someone,
distance is one,
a follow of a follow is a distance of two, correct?
Okay.
Yeah, exactly.
Basically, distance one
is what the source path key follows.
And distance two is what the follows of the source follows.
So, yeah, hops, basically.
Yeah.
Yeah, so basically, as I was saying,
we have a decay function that basically maps the distance
to a floating point, to a float.
so if you are at distance 1
you have 1, if you are at distance 2
you have
0.85
or something around that
if you are at distance 3
you have 0.7
or something like that
and then
Is this some Fibonacci decay
or something?
1 to 0.0
Not exactly
I mean I tried to
model the curve of the decay function to basically decay harder when the distance is more than
three. So ahead from three, the result of that component is bigger, start to be more
pronunciated
and the
6 that is out of the graph
and this is based on different
studies and different papers
So you've put
together this decay function
and it sounds like some kind of
I don't think it sounds like some kind of stepwise
function right like
if you're saying after 3 it's more
than it's before 3
so it's not some kind of
existing
curve, right? You've looked at different studies and you've sort of pieced it together.
No, I try to basically collapse
there, different things about social dynamics and things
that we can extract from the graph and map that to
a number, to a float from 0 to 1.
Basically because
if you are starting to be, if you have a target pub key that is
up to four hops
that means that
a lot of people
in your graph
in your social graph
is not following it
because for example
if the source pub key
and the target pub key
are at one
distance one
the source pub key
can control that distance
so if the source pub key
unfollows you, you are going to be at distance 2.
Okay? But if you are at distance 2,
then it's much harder to go
from 2 to 3. Because to go from
2 to 3, all the follows of the
source path key should unfollow you at the same time.
And to go from 3 to 4,
the same but exponentially
in the hub
then from 4 to 5
more exponential and 6
is out of the graph
is all of Noster
yeah exactly
yeah because
this is basically
the rule of thumb
in related
because
basically this
weighted formula
take these components as a 50% of the final scoring or the final number and
the other 50% are these trust signals that users or operators of Relator can
modify. Basically those signals are like if the user... in the case of the
main relator or the public relator instance that we are running. The components of the
signals that we are taking there to do the computation is basically if the user have a
published relay list, if the user have a valid NIPO5, if the user have reciprocity with the
the source pub key.
Yeah, if it has a lightning address set up in its profile.
And yeah, that's it.
So those signals are also mapped to a float number.
And together with the components, the other 50% components are zoomed up
and the result is the final score.
So that makes complete sense, right?
In some sense, when you map those, whatever signals you take, right?
Like you said, the existence of a lightning address, NIPO5,
and you could do anything, how many times they zapped.
You can pick anything as a signal, for example.
Yeah, you can count GNs, you know, if you want.
That could be a good trust signal.
Sure.
So those have weights of their own, and for today you assign those weights, right, to these signals?
Okay, and then those weights get multiplied with the distance weights, and it collapses into one score per relationship, right?
So I want to make sure I understand.
So if I'm the one who's requesting the scores,
I have, let's say, 300 people at distance one,
maybe 20,000 people at distance two,
like whatever, 300,000 people at distance three.
If I request a score, I need to get all 300,000 scores, right?
And those scores get calculated
by doing this weighted average across distances
and signal weights as well.
Yes, exactly.
So this is what I mean.
This is like a very complicated computation.
How are you able to get it?
Because what is this magic that you're able to get it to do on a Raspberry Pi?
Yeah, I mean, I think it's not that complex at the end.
If you are able to organize and to have a clear life cycle of the whole process and model the whole process in a way that is conservative with the resources that it consumes, the computation that it needs to develop in order to have all the computation done.
you can get it to work
well and perform
well in resource
constrained
environments
because
basically
Relator is not doing
real-time computations all the time
like for every request
you have a TTL
time to leave
for the
score and the result of the validations.
That TTL determines the freshness of the output.
So from time to time there is a
schedule job that
basically refresh the stale
computations. And it does that
in a conservative way so it really doesn't put a lot of pressure on the machine.
The other part is the stack that I choose for this which is specifically designed for
work on resource-constrained environments which is basically DACDB which is an embedded
database for all app in process for specifically design for analytics that it performs really well
on the edge you know and is embedded embedded means that you don't need to run a separate
service a site so everything is contained in the same program the database is a file
you can copy that file
you can download that file
you can transmit that file
it's a file
it's not like a Postgres database
or a Neo4j database
or a Redis
or nothing like that
it's embedded
indeed
DACDB is a very interesting database
for this kind of things
because they take seriously
these things about
because
DuckDB is a single node
engine which means that
it's supposed not to be shared
it's just to be run
in the same thing, single node
and they run very crazy
benchmarks on phones
with huge data sets and
sorting that stuff and doing
different operations
they are
very cool, they are really cool, they are fully
open source as well
So I'm very careful with the stack that issues for Relator and Context VM because one of the things that open source developers tend to forget is that the license of the libraries that you use determines the final license that your software can have.
All the software that I'm using, all the libraries and everything, I'm very careful with that because I really want the stack to be fully open source.
but yeah that is the magic behind
Relator and why
it works well
in this kind of environment
magic is .db
it sounds like and a few other things
so
I mean I can
if you are interested I think that
I can just give a previous
historic
timeline of how
Relator was developed because
at the beginning I didn't start
with TagTV.
I started with SQLite
and
Martin Malmi's
Nocell Social Graph library
which
in Spirit is the same that
a library that I created for
Relator that is called Nocell Social
DAC which is
the same that Martin Malmi's
do but
instead of loading
everything on memory
just use
DACDB as the engine for
the graph computations
you know
everything in Related started
well with the Martis
libraries
and SQLite database
but
it started to show
the cracks
very quickly because
you know search
Search is a heavy topic.
You know, it's a very difficult task indeed
to basically have a huge data set of metadata
and just perform a search that supposedly is going to return to you
the most relevant results from that huge set of data.
and when I was the first iterations of Relator when it used the the Martis
Marmies library and SQLite I had a very huge bottleneck there because basically
in order to perform a search I had to first go to SQLite and do a full-text
search in the database in the in the table of the metadata then get an
an arbitrary number of candidates,
then those candidates resolve the score for all of them,
sort the results, and then slice it
to basically respect the limit of the filter.
That was painful because, you know,
you never was sure about the number of candidates
to take from the database.
because maybe you take a hundred but you know the the most relevant result is
101 you know is at 101 so it's quite arbitrary and that was creating a bad experience and a huge
performance bottleneck because every time you have to compute trust or the scores scores for
a random number or an arbitrary number of candidates
hoping to have the best or the most relevant results
in that candidate, which is arbitrary.
So then I moved to Nocell Social DAC.
That is the same concept that the Nocell Social Graph library
from Martin Malmys, but everything is in DACDB.
so I moved from SQLite
plus Martins Malme
library to
use DAGDB
and everything there
so it allowed me to
do joins
and perform everything
in SQL
to perform searches
and that really
improved the experience by a lot
and the performance because
now instead of
do the candidate things,
I could basically get the most relevant results
from the database straight out of the database
without needing to do all the score computation
after getting the candidates.
So yeah, all of that are the engineering decisions
and all of them was in order to accomplish
accomplish the vision behind it later of being able to run everywhere on any device.
That's great.
So we have, as of today, there's three Web of Trust service providers
that essentially you can, as a user, can request the scores, I guess,
for your Web of Trust, for your entire network.
Now, I think Vertex works a little differently.
it's an API call and I don't think
they put a number on a person.
I should talk to,
should have Pip on the show just so that he does
a deep dive on Vertex.
But in your case,
do you support
an API call or have you gone straight to
trusted assertions?
No, no, no. I mean, the first,
the main API of
Relator is ContextVM.
Everything, that was
the first
the first API, now I integrated with Trusted Assertions,
which basically publish events on relays above the ranks.
So yeah these two interfaces are complementary because you know Context VM gives you a request pattern similar to the VMs or RPC systems and that is necessary for things like a search
I cannot rely on a produce-consumer approach, which is basically what is NOS or the trusted
assertions approach to perform search because you need to basically publish all the events
with all the possible searches that someone could do, which is impossible and doesn't
make sense.
So for that, the request response pattern is necessary.
but the other
the produce consumer pattern
that fits more
naturally in Nosser
the concept behind
the trusted assertions
is complementary because
it allows
a much easier integration
in any client because
clients can use
create filters
as they create for
render a fit
but instead of getting the feed
they can just get the trusted assertions
events
but yeah
both interfaces are present in Reader
you can request ranks
or you can fetch ranks from relays
yeah
it contains both APIs
and you're right
it's different use cases
different complementary use cases
let's talk about the spam mitigation one
which I think trusted assertions are probably better suited for.
And I'll lay it out here, right?
So let's say I'm a user and I want to calculate the web of trust scores for my network
because I'm seeing a lot of junk on my, you know, just bots shilling, you know, crypto stuff.
They're shilling some pills, this and that, right?
So I'm like, I don't want to see any of this stuff.
Why are they getting into my comments?
So I go to Relator.
I choose Relator as my service provider
and I get my scores calculated
and let's just say I'm an Amethyst user.
Relator blasts out the trusted assertions
and then I go to Amethyst
and I choose Relator as my service provider.
That's how the flow works, right?
More or less.
The way that Amethyst is implemented
the user doesn't need to configure nothing on Amethyst.
the user can go to
brainstorm for example
that is
one or the other
service of Web of Trust
that we talk about
or relator
XYZ
and
indeed I'm not sure if in brainstorm
you can
I think that you can
but basically edit
your list of
trusted providers
and you can do that in Relator XC for sure. You can just go there and select or add to your list
of trusted providers the pub key of the Relator server and Amethyst will just pick that up and
render things, render numbers on your screen and use that for the Web of Trust stuff. So yeah,
you don't really need to modify or to edit nothing in Ametiz.
Everything happens elsewhere.
I don't know if Vitor will implement something
to allow, modify the list of trusted providers.
But yeah, in any case, the flow is that.
The flow is that the user find a provider.
The provider publish these events, these trusted assertions.
and then the user have to
publish another event that
is a list of the
trust sets providers
and yeah that's all
and then
so then I go back to Amethyst and
I don't know if VTOR
has implemented the filtering yet
right now it's just I can see
when I see a comment
I'll still see the comment but I'll see a number
on top of that of whoever that
pub key is that npub is
right
but presumably he can add an option in settings
where I can go and say,
don't show me comments for anyone whose score is below 20
because they're probably bots or something like that.
Yes.
Yeah, exactly.
Let's talk about...
Sorry, go ahead.
Finish your thought, Jesus.
Sorry, no.
I don't know if you were going to jump from the spam prevention topic,
but I can share another thing that I'm working on that is related to the water lie.
And water lie is an experiment of a relay that is moderated by the social dynamics of these scores and these web of trust things.
Because basically, I picked the example of Pip from the relay framework that he had for creating relays.
And he had an example there.
And that is basically a bucket algorithm for spam prevention and rate limiting.
then I took that example
I refactored it to work with later
and then what I got is a relay
that doesn't declare or set very hard rules
or specific rules for who can publish or what not
and it is moderated by the social dynamics that are expressed as numbers or ranks
that comes from relator in this case.
So the bucket algorithm is basically imagine that you have a bucket
and the capacity of the bucket is the capacity that you have to publish in this case in the relay.
You have a refill rate.
okay and that refill rate if you for example spend all the capacity of your
bucket it will be refilled at a constant rate so what this relay is doing the
water relay that I'm running a public instance at water.relator.hyc
What it's doing is that when you send an event, the relay is contacting with the relator, getting the score or the rank for that pubkey and determining the size of the bucket.
so if you are a reputable
pubkey
with a high score
you're going to get a big
bucket, let's say
thousands of posts a day
and
if you are a non-reputable
or a pubkey
with a very low rank
you will have
less capacity to
chat
or to publish
but, for part
and if you have a zero rank you're still allowed to publish just that you are restricted to kind
ones and kind ones without links in this case because I noticed that this is one of the the
shape of the spans of the spam in Nocer is kind ones with with loads of links and things or
photographs or images or media. Basically, pubkeys with rank zero are still able to publish
just to allow new people to solve the bootstrapping problem, where a new pubkey that doesn't
have a sociograph or someone that doesn't have any of these components that no one knows
can just publish a GM, for example, or any kind of node
and start to create connections.
You know, as that unknown pubkey start to create connections
and start to follow people and people start to follow that pubkey,
the rank will evolve
and the size of the bucket will evolve as well.
So the publish capacity will evolve with that.
that is the concept
the experiment behind the
waterline which is
this
moderation by social
dynamics basically
and this logic
lives on the relay
for, ok
that's interesting
yeah it's a very decoupled
architecture because you have the relay
in one side
which is just cares
about Relay stuff.
And in the other side, you have Relator
that is running as a separate service
through ContextVM.
And the Relay can basically,
when it have to request
a new rank computation or something,
it use ContextVM,
gets the rank,
and use that rank for this bucket algorithm.
So they are very decoupled things.
And for example,
if you want to run
a relator instance
and you run a waterline instance,
you can connect both
or do any kind of combination
in that sense.
Yeah.
Yeah, that's super interesting, Jesus.
So let's actually,
so that ties into
the question I was about to ask you
before you talked about this,
which is,
you know, this is,
people can say,
now this might not be true But the perception of something like this is you doing some kind of rationing right This bucket size based on score Similarly on Amethyst if you put a number on someone face it not very nice right
It's like this is a social credit score.
And I think, you know, a lot of us who are working in this world, we know that it's not, it's all personalized, right?
So all of these scores are calculated from a point of view of the individual who's requesting the scores.
It's not being assigned.
Amethyst is not giving you a score.
Relator is not giving you a score.
Relator is just providing the mathematical framework for a user to calculate a score from their perspective.
Yeah, and it's transparent.
The algorithm is transparent.
And the components that compose that rank, final rank, is transparent.
Right.
Right. But what, you know, we can explain that.
But like to an average user, non-technical user, they come in and let's say they're new to Nostra.
And they're like, well, your bucket is really small because no one knows you.
And I'm like, my God, I'm being rationed.
Then they go to Amethyst. Sorry about that. That's my dog.
Then they go to Amethyst and they see a number on their face or on people's faces.
And like, what is this? It's like social credit score. I'm being rationed here.
How would you sort of talk to a non-technical new user and just maybe, you know, help them through the sphere?
Yeah. So I think that my rationale here is, you know, trust is a scaling solution.
Thanks to trust, we can go further scale system, especially decentralized systems, right?
Because if you have a centralized platform that manages that for you and is totally opaque,
yeah, I mean, that is a very dark pattern, right?
but we have to recognize that trust is a scaling solution
to basically perform actions between individuals
ahead from its own trust
or its own vision of the world
it allows me to collaborate with you for example
I don't know you personally
but I know people that are my friends that trust you
so that trust that my friend has
for you allows me to trust you.
So it's just my trust has scale
and we can collaborate without friction
or knowing that we want to collaborate
with the person that we want to collaborate
and thanks to this trust.
This is especially true, I think,
for, you know, protocol like NOSER
where everything is scattered,
it's centralized, there is no central authorities.
If we don't have this,
or if we don't have a way to express this,
to express this trust,
we can't escape relations between people
and everything feels death in that sense.
Because you can't solve the problem.
It's a chicken and egg problem, right?
You first have to interact, people have to see you.
Thanks to trust, we can create staff that are more advanced
and can surpass the limits of the decentralized environments like this.
Like Nasser.
Especially, it's true because...
No, no, go ahead. Go ahead, Jesus.
no it's just that
you know
a rank a number can be scary
and can feel like a social credit
but I think that the important
part here is to understand
that
if that rank is produced
by the perspective
of someone that is
an individual as well
as you and it has its own
criteria to determine what
it wants to trust and what not
and all of that is
transparent in the sense that
you understand what is behind that
number or what components
have been taken
into account to basically
get that output
that
from my point of view that is
much less scary and not
scary at all because it's
basically
something natural and organic
in human relations
like my perspective is something relative to me
if I choose how to model that
it's my decision
and you can see that
you can agree with that
or not
there is no problem
you can run your own
there is nothing imposed top down
and everything is transparent
and I think that is the important thing
to educate someone who might be new to this,
who might have seen how centralized systems impose these cores
or manifest these cores.
Completely agree there on the education part.
And also agree with your earlier point,
which is I think that the user experience on NOSTA
has been suffering from spam and just poor discovery
and poor curation.
because these trust-based solutions, personalized trust-based solutions, have not existed.
Which leads me to, I guess, a follow-on question, which is,
you've been here three years, I've been here three years.
You know, a lot of us have been here for that long.
Why has it taken this long for this realization to come that,
look, we need this layer of trust to actually make NOSTA meaningful and usable for most people?
I think that is the uniqueness of the challenge, you know.
Before Nosher, the most similar thing we had is PGP, right?
And PGP in spirit is very similar to Nosher.
And they were the ones that came up with this concept of Web of Trust.
And Web of Trust for them was basically key parties where people in real life, in mid-space, show up with the fingerprint of their public keys, basically to allow their peers to establish a relation between the key and the person that is behind that.
That was called Web of Trust and came from that epoch, from that time.
That was a unique challenge and I think that we are reviving that in Nozer with even more uniqueness because we surpassed some of the limitations that PGP had.
because basically to use PGP you have to use a medium to transmit an encrypted message.
I think that the most popular medium was email, basically to encrypt the emails between people.
but Noceris is a
decentralized
protocol
where people
run on mpups that are just numbers
that anyone can generate for free
can just take
and sign messages
and publish them in relays
and
I think that the trust
problem is
such unique or have present unique challenges for an environment like Nosser.
And I think that there is a lot there because the why behind this taking so long.
Because we need to realize things before and also we need data basically to have to compute things.
Because it's also a chicken and egg problem.
but now we have all this history behind
and people can find different ways to represent trust
and the data wasn't present before.
So the uniqueness of the challenge
and the amount of data present,
I think that is the reason why this took so long.
Yeah, I think you hit the nail on the head, Jesus.
I think it took this long for people to actually realize how to solve it.
And even if they had realized this two years ago, right, how best to approach this, the data wasn't there.
So I think it's a nice confluence of these two things that are happening, which is people have given it some thought over the last three years.
And I think people, as you can see, like with Relator and Brainstorm, it's kind of converging on a similar type thing.
personalized scores using an extensible set of signals, fully transparent.
You apply a weight based on distance, based on the type of signal.
Again, the weights are transparent.
You can, and I'm sure with Relator, you can change the weights if you wanted to, right,
on each of these signals.
I think that, so, you know, you're seeing that happening with Relator.
You're seeing that happening with Brainstorm.
I'm sure the next one, that next provider comes out will, you know, have a, you know,
that approach to transparency and portability,
composability, and so on, extensibility.
So I think that realization,
it's almost a collective realization that's happening now.
It's taken three years, and then we have the data to act on it.
Yeah, yeah, exactly.
Exactly.
I really believe that was one of the main reasons.
Also because you know exactly for the same reason of the uniqueness of the challenge Nostar itself is something new it just has four years something very young very young protocol and it really presents challenges in its topology and how it works and so on
So I think that it's a combination of all of that, but principally the trust, how to express it, we are understanding that now, and also the data, the amount of data that was there.
talking about something that really excites me that is coming to Relator is basically a new
system that I'm creating for plugins or for these two sorry so basically to configure what are the
signals that you take to for the for the computations because currently Relator allows you to
to modify what are the signals that you take for the computation,
the signal that we talked about before,
that currently by default are if the user has a relay list,
if the user has a lining address set in their profiles,
if the ones that we talked about before.
And developers could modify and add new validations,
but in the current version of Relator that would mean to modify the source code of Relator
which nowadays is fairly easy with LLMs but still presenting friction
I'm very excited for a plugin system that I'm developing for Relator
which is based on an expression language that is called ELO or ELO
and it basically allows me to design a system where these signals can be expressed in very concise expressions
that can be bundled as NOSER events.
So basically the idea is that anyone can create these programs for signals,
publish them on Nozir
and people can use them
in their relator instances
so if I'm a relator operator
starting to decide
what trust means for me
or what the rank
that a relator is outputting
what that means
I will be able to go to Nozir
in a marketplace manner
and see what validators or what things are there,
what people have been created,
just with the ease of a click
or configure the algorithm
and set the weights for all those signals.
So this effectively creates a marketplace of these signals
and it allows people to create, to curate, to share, to use.
This excites me a lot because I think that this is the materialization of the vision behind Relator
and with a good experience for the user
because you will be able to determine, tune, and understand why the rank
or what is the rank that is coming out from Relator.
So for example, if I'm publishing a signal or an expression
that measures the amount of GMs or the amount of subs that a user received,
I can just pick those, configure them in Relator,
because they are no-serie events,
and Relator can just fetch them from Relator,
and use them for the computations.
I think that's really cool.
Is this feature out yet?
No.
No, I was trying to put it together for this podcast,
but I was thrilled by different things, by work.
Also, yesterday we released a new CLI for a set of skills for ContextVM,
for developing things on ContextVM.
This new feature for Relator needs a bit more of polishing.
It's basically to provide... It's working already.
It's totally feasible.
I have tests and indeed makes Relator even more efficient and performance.
But it's not released yet.
I need to polish the user experience in the sense of publishing
and setting up these signals from Nocer.
But it's coming along nicely.
Nice. Yeah, certainly something to look forward to.
Jesus
this has been great
great conversation
thank you for educating us
the audience about Relator
and all the work that you've done
on NOSTA
with Context VM, DVM-CP
maybe one day we'll see
Coloria
I think that
it's going to be
everything part of NOSTA
and when I
revive NOSTA
it's going to come with these features.
So, yeah.
Relator scores, kill the zombies with all the relator scores,
and that's going to be great.
Yeah, exactly.
I mean, Nosser is very fun, definitely.
If I can say something from this time working on Nosser,
it is very fun to develop on Nosser.
it's also quite frustrating
sometimes
because the challenges
that it presents
how standards
are standardized
talking about MIPS
and so on
so sometimes it's very frustrating
very frustrating
but very fun as well
so it's a balance
no for sure
it's the emergent and messy
consensus of being part of
a decentralized
group.
Look, I think people have the right attitude
here, because there's two ways of looking
at it. You can have a decentralized
mob, and it's complete
chaos, or you can
have a decentralized mob, and it's only a little
bit of chaos, but mostly fun,
which thankfully, at least
until now, that's what Nostro has been.
Yeah.
My only critic
for Nostro is
that the governance or at least the standards are not easy to navigate.
If you are someone new, like a new developer,
trying to figure out how to develop something on Nocer,
it's going to have a hard time trying to navigate Nibs
and to understand how to do things.
I have expertise now after three years working on that,
working on this, and I understand how things work and so on.
But yeah, someone new wanting to develop something in Nozir,
it's going to you see a lot of mess.
And that presents a lot of friction.
Yeah, also I wrote an article some time ago,
I think during Sovereign Engineering 5,
that is called Enemies of Nozir.
It's a reflection about open source protocols.
and how they get captured,
and how the same history can repeat on Nostra.
So I don't know if you read that, but...
I remember seeing it.
It was a while back, right?
Yeah, some months ago, yeah.
I'll tell you what, Jesus,
I will put all of those links in the show notes,
and I'll certainly read it as well,
The Enemies of Nostra.
I'll link that, I'll link ContextVM,
I'll link Relator, Nostri, anything else you want me to link.
I'll put all of that in the show notes
so that our audience can check it out as well.
No, that sounds good.
Awesome.
All right, Jesus, again, thank you.
Great conversation, very educational.
Thank you for everything you do to make Nostri a better place,
make it more fun despite the challenges.
Thank you for being patient.
and not running away and going crazy.
It's worth it.
It's worth it because we are leaning towards
a very scary thing.
But yeah, thank you so much.
I appreciate it so much, your words.
Yeah, let's continue building.
Let's continue building indeed.
Thank you to our live stream audience for listening.
Thank you for the zaps.
If you are listening to this recording,
I hope you're doing so on a modern Podcasting 2.0 app
such as Fountain.
If you found value in this conversation,
if it gave you a new mental model,
a moment of clarity,
or just a respite from the noise,
then please consider returning the value.
You can stream sats as you listen on Fountain
or another Podcasting 2.0 app,
or you could become a monthly subscriber
to keep the signal strong.
Thank you, folks.
See you next time.