Let's go all the way. I like it. We're live, basically. I mean, not live, but you know.
I'm not brave enough yet to live stream it.
But that was one of the things you showed was a live stream applet, right?
Yeah, yeah.
So that's basically doing the same thing that zapstream is doing, but just in a napplet.
Exactly. It's just pulling in the streaming events.
We should explain what applets are.
We had the most successful workshop ever in the world today.
A dozen people at least created applets and all this kind of stuff.
And yeah, it's really fucking cool. So first of all, congrats on that.
Yeah, thanks.
And after we hit the party music, I think we'll just lean in and explain.
Yeah, sounds good.
But first of all, how did you come up with the idea for it?
What was the motivation behind building it up?
It's always been on my mind.
When I saw early Nostr, the clients weren't really that interesting to me.
That's why I didn't really work on any.
It seemed like the way that Nostr is designed and architected, or the lack of it,
it demands maximum flexibility.
A standard client is very restrictive and everything is isolated, which is the opposite of what the protocol is.
Restrictive in what way?
Well, because you have a team of people or a single developer building their one thing.
And just to get it functional takes a lot of work.
And all these people are working in a silo.
And there's no way that even a large team could develop everything that you could possibly develop.
So it just made sense to me that every functionality should be atomic.
It should be switchable between one client and another.
You should be able to compose your clients.
I see. So in terms of complexity, you mean taking care of the keys, taking care of the signing,
taking care of the relay connections, taking care of caching, taking care of outbox.
So all the things that...
I mean, that's why we have a library layer now, basically.
We have NDK, we have Applesauce, we have other things.
But your approach with the Nostr applets is quite different.
It's on a different layer.
So how did you end up with this design decision, basically?
Well, it took some time to actually get to the point where I understood what I was thinking.
Or what I was envisioning when I first got introduced to Nostr.
What was the first version? If it took some time and it took some iterations,
what did you learn along the way and how did the first version look like?
The first version was at my friend's house in Sacramento.
And I was getting into vibe coding a little bit.
And I think he was really into Claude and he was like, you have to use Claude.
So I was like, all right, I'll try Claude for you.
So that was one and a half years ago or so, something like that?
No, it was like... because I was using other things.
He was really into Anthropic, I hadn't used Anthropic yet.
It was in July, a year ago.
And I was sitting in his living room and I was like, you know,
like Insights had just come out and I knew there was something there,
that there's something special with Insights.
And so I thought of like...
Also, I had recently gotten into the Hyperland compositor.
So I was kind of inspired by that new fresh look at what a desktop could be.
And I built a prototype of what I showed you today.
How come you got into Hyperland?
Is it where you're always a Wayland kind of guy?
No, I mean...
I don't want to get in the tribal fights between X11 and Wayland.
Why not?
No, it was more of just like, well, I should at least try it.
So why I got into it was I was looking for a new desktop environment
and I didn't want a desktop environment.
I was sick of the bloat.
I was sick of the opinionation.
I just wanted to build my own thing.
Sick of the opinionation, so I'm going to build my own thing.
Exactly.
Well, other people's opinionation, right?
And having to live through it.
I just tested it out.
I was just going to rise it up and see what it was about.
So you were in that kind of mindset when you started hacking on what is now Atlas.
Yeah.
And I just saw that...
I was making a lot of end sites too.
End sites barely worked.
And I was finding that I was spending a lot of time
building a lot of things over and over and over and over, right?
I think MakeStack was just around the corner.
But even that, you have to maintain it after you've implemented it.
So...
Yeah, I just built a prototype.
And then I saw, I was like, wait.
First of all, it's really hard to manage the memory in this
because everything's in the main thread.
And then I started breaking them into iframes.
And at that point, I realized that in order to do it correctly,
I would have to really step back from this prototype idea,
this vision I have, and then actually figure out
what it actually looks like to do this well.
I found a lot of different security problems with my prototype and all this stuff.
Iframes, just hearing iframes...
I know, it sounds so funny.
It sounded funny to me too.
Did it work at all with iframes?
Yes, but everything was, the lines were blurred.
So because there was...
The line between container and applet.
Yeah, because the applet could do whatever the runtime could do.
And so we could do things without the runtime knowing,
without the user knowing, and it couldn't be possible
to sort of restrict what the app was doing, right?
At this time, it was actually called Naps.
Okay.
Yeah, which is kind of funny.
Which is fitting.
Apps can do more than applets.
Yeah, so I moved into a Tori app.
Nsight.run actually.
Or no, it was Nap.run.
And I built that pretty quick,
but it hit the ceiling really quickly as well,
because I couldn't, there was a bunch of stuff I couldn't do.
And then I immediately went into forking Thorium,
which is like a slimmed down chromium,
but the build chain for that was insane.
It took a huge amount of space to run the CI,
and I just was like, I can't do this right now.
So I stepped back further,
and I just started with a single frame,
and I started attacking the runtime
from inside of the iframe.
And progressively, I removed more and more and more features
of what the iframe was allowed to do,
until it got to the point where it could basically do nothing,
except for talk over postMessage.
Okay.
And I wasn't very hopeful.
I didn't think it would work,
because to redefine,
I found myself redefining Nostr
inside of the sub-protocol that it has now become.
And it took a few months,
like four or five, six months,
before I understood that I was approaching it entirely wrong.
And I identified that the person making the application
doesn't need to know as much as I originally thought.
They don't need to know that they're uploading to Blossom.
They don't need to know where they're uploading.
They don't need to know about relays.
They don't need to know about keys.
They need to know a little bit.
They need to understand that there are relays.
And so once I got the security posture where it was,
and I played with the API enough,
I realized there was really two sets of API services
that the run time, or sorry,
that the NAPLIT should have,
which is sort of like a high-level,
helper kind of style API.
And then escape hatches,
so that flexibility isn't compromised,
because if you try to do everything through helpers,
you sort of constrain the potential experiences
that you could create.
What's an escape hatch in that context?
Outbox would be the easiest way to retrieve notes,
because you basically delegate the outbox context
to the run time.
But the escape hatch is a relay interface
that allows you to have lower-level access
to the protocol, if you need it.
Okay, okay, okay.
So in case something doesn't work right,
you use the escape hatch and try to do things more directly.
Exactly, exactly.
Okay, I get it. I see.
The next challenge was getting NAPLITs
to talk to one another.
That was very difficult.
Actually, we only settled on it last night,
how to fix that.
Who is we?
Hazard and I. We were talking about it.
It's goddamn Hazard.
He has his fingers in everything.
Yeah, it took me a while to get him on board.
Yeah, you mentioned that briefly today.
You tried to explain it to me.
And
you built this awesome workshop tutorial page that I was able to point my agent to and just
everything worked basically. I was able to build the first applet in five minutes or so.
Yeah, it was like five or six minutes and deployed in six minutes.
Yeah, so if someone's curious, I'll definitely link that and then you can just, you know.
I'm going to make some improvements to it because some people had some issues.
Yeah, I mean, you have to understand what's going on on the underlying side and it helps
to have a proper setup. You know, like I was lucky that I just, I have Amber on my phone
and can set up the signing for the publication flow and all this kind of stuff. And I have,
you know, like also a proper Nostr setup and a proper signing setup on my laptop,
on my development machine. That makes everything easier. But if you have that,
if you do a little bit of prep work, then pointing an agent at this tutorial will just work.
Yeah, that's awesome.
That was the idea. And fortunately too, it's not like a lot of this, while everything is
agent assisted, there's a lot of experience that went into it. Like it wasn't designed by AI.
If it was designed by AI, I don't think it would work.
It's amazing how well it works, by the way.
Yeah, it's surprising to me too.
But talk to me more about kind of the level of abstraction that you landed on,
iterating on it for like almost a year. Because it's, you also mentioned briefly,
VHF kind of hates it in the sense that it doesn't use kinds as a messaging bus and so on.
So you chose a different level of abstraction. So explain that some more.
Well, I wouldn't say he hates it because it inspired him when I showed him
an early demonstration, I just sent him a screenshot and said, this can open that.
And he was like, well, that would be a paradigm change. And it did inspire him to actually revisit
one of his old projects that was very similar to this. But some of the design decisions I've made,
he has been disagreeing with.
I mean, to be fair, VHF basically hates everything on first sight.
Of course.
That's just how it goes.
It's almost like a stamp of approval.
Yeah, actually, you're probably right.
Because if he wouldn't say he hates it, then he would just be indifferent to it and wouldn't say
anything.
Exactly. Yeah.
So yeah, it took a lot of different iterations. I mean, it started with the shell, which is what
mediates every request from like over the bus, right? Being a relay. And then the napplets were
sending Nostr messages using NIP one. And then I was going to extend new messages. But this
created a bunch of a huge convoluted mess because you had to arbitrarily assign a key pair from the
runtime to the napplet, right? And this was just completely unnecessary because the runtime already
had full control over the napplet already. So it doesn't need it to confirm it.
And then otherwise, then you'd be sending unsigned events, which then was weird,
because you did want to know sort of where the events were when they're being routed.
One of the benefits the first design had was that you could tell where the event came from
at any point in the runtime. You could always tell, oh, it came from this napplet.
But every napplet had a key as well. That's something you mentioned, right?
Yeah, yeah. So it did simplify certain things, but it made pretty much everything else complicated.
And then I think I figured out, there was an aha moment when I did resource, because trying to
load, it created a unique problem where you want to load bytes, but you can't fetch them because
the napplet doesn't have any access to the network. And you have to stream the bytes over the bus.
And then I'm like, okay, so how do I do YouTube videos? How do I do streams? And then it clicked
because this is the same problem that operating systems face, and they have a media API. And so
I just basically copied Linux, and it worked pretty much first try. And when that happened,
I just realized I didn't have to reinvent anything. You just have to rebuild an operating
system in a browser window, basically. Sure, yeah. And you didn't even see all of it.
So walk me through what happens if you use the example before uploading something to a Blossom
server. Let's say we have a napplet, very simple drag and drop upload to the user's Blossom servers,
and then let's do the same for download. What happens on the napplet shell level,
like on the container level? So the napplet would just, you'd probably have a drop zone.
Maybe it would be have a listener for paste and an upload button, obviously. You'd upload the image,
it would be in memory. You showed that today, by the way, right? You right-click copied an image,
and you went to another napplet, and then you just pasted it, and it did an upload. So the paste
will, of course, drop the bytes, stream the bytes into the thing. And how does it work? How does it
figure out which Blossom server to upload and all those kinds of things? Absolutely. So it actually,
the interface is just upload. And then the runtime is what decides what that means. And the
runtime's target market also decides what that means. So you could have a runtime that supports,
say, Blossom, Hashtree, let's say IPFS, just for fun. And maybe, like, let's just even say Google
Drive. I would never do it, but you could, right? And the user has none configured, and they
initiate an upload. The runtime detects, hey, I support these things, but none of them are
configured. You do not have a server list for Blossom. It would then prompt them to configure
it. If they did have one of them already configured, if they had one, maybe it would just
automatically upload it to that source. Or if they had maybe two configured, it would ask if they
wanted to upload to one or the other or both. Now on read, you would just pass the Blossom hash
or whatever the resource is. So the resource, because the runtime's mediating everything,
it knows where it's uploading. And so when you pass a resource, it knows where to look.
Yeah. Because the runtime is mediating everything. There are obviously some gaps here.
So for example, if you have notes on Nostr that are IPFS and the runtime doesn't support IPFS,
then it won't work, right? There's all sorts of gaps like that. And there is ways to deal with
that. You could just detect that in the NAPLIT, like when a resource isn't returned, you could
do something so that it's not a bad user experience. But yeah, that's a pretty straightforward
solution. And in terms of signing events and all those kinds of things, how does it work?
What kind of interface do you have and how does the app itself that contains
the applet kind of- The host.
Yeah. The host.
You could call it a host application. People resonate with that.
And just to maybe mention that, you mentioned Amethyst already supports
an earlier version. And Nostr will also support it. And so this is already working right now. And
then you have a little applet thing, whatever, in your Nostr client, in your Nostr environment.
And the signing, and like you said, what is my Blossom server list, for example, this is all
handled by the host application. And so how does this get triggered and passed on? And let's say,
you just want to post an event or even for a Blossom upload, you have to sign something.
What happens there?
So the signature always occurs in, by the shell. So beyond the shell, we could call it,
we'll just use the word host. I prefer runtime for technical reasons, but I think host makes
the most sense for people who are being introduced to it. So the host application for the applets
is responsible for all encryption, decryption, and over the shell is always clear text.
So if it receives encrypted text over the shell, it must reject it. That's part of the rule.
If you're publishing, you're doing a publish, or you can do publish encrypted.
And if you're decrypting, you can just do decrypt.
Explain that some more with the one rule you just mentioned, that over the shell,
it's always plain text. I don't think I understand.
So there's a number of attacks that you can do because in order for this to work,
Napplets have to be safe to use even when they're malicious. So like the user can't
have to second guess the napplet, otherwise it will never work.
There's a number of side channel attacks. So for example, you can do a sort of storage of
decrypted data, or sorry, encrypted data. And then you can also do like heuristics in the napplet
and store stuff in storage scopes, and then send it in an encrypted message back to yourself as the
napplet author. So everything is required to be plain text over the message bus. Okay, okay.
Yeah, that way the runtime can tell the user what the napplet is doing, it can log it appropriately.
Yeah, and you as the user can be sure, have a reasonable assurance that no funny business is
going on, right? You can inspect everything that goes back and forth. Exactly. Yeah, I see. Okay.
And the runtime cannot protect the user from something it doesn't know about. So that's
really important. Yeah. Yeah. Okay. Okay. I see. I see. Yeah. Fancy stuff. So there's
quite a bit of thought. Yeah, quite a bit of thought went into that. Oh, yeah. A lot of testing.
How did you how did you build it out in terms of, you know, like, you have quite a sophisticated
development setup, and those kind of things and some ideas around how to
use agents properly? Like, what did you use to build out? Yeah, the whole applet engine and everything.
I think both. Well, they I went through phases. And I may have done a rewrite, I did a rewrite on
NAPLIT on the NAPLIT dev tooling. And when I read did the rewrite, I use GSD. And same with KEDO,
which is the runtime packages. So GSD is gadget done? Yeah, or it was they they had to rebrand.
Yeah, let's let's stick with let's get it. Yeah, good name.
And KEDO you mentioned? Yeah, it's like, it's so the name, it's actually Finnish. And there's
actually no real reason for that. I was just looking for five letter words that hadn't been
used on any project. Okay, and it was the only one that when translated made sense. It's Finnish for
crib, or cradle. Okay, which kind of made sense, because it's sort of, you know, cradles NAPLIT.
Yeah, protects the I guess the users the baby. Yeah. Yeah. And then the development runtime
is Paja, which I just learned how to pronounce it today from my roommate.
And that is workbench. Okay. And finish as well.
That is can be used to build runtimes. So that includes a shell, an ACL,
a firewall, which really only behaves like a rate limiter right now,
to relieve pressure from the runtime. It includes services, stubs for services like notifications,
relay pools, storage, KB storage, media handler,
and a few other things. The NAPLIT dev tooling is about conformance. It has the shim,
which might actually be moved to Keto because it's injected by Keto.
It includes a SDK, some types, a boilerplate and skills and a few others.
These are pretty tightly like the architecture of these was pretty heavily considered because
they, first of all, there's no dependencies in any of them.
They're lightweight by using them. No dependencies on any other NOS stuff,
or what do you mean by no dependencies? Like it's vanilla JavaScript, except for maybe like
the skills and the dev tooling, like the bundlers and stuff. But other than that, it is
the without dependencies. Yeah, they're celebrating the launch of many, many NAPLITs today.
Okay, that's quite something. No dependencies. Like that's a very pure approach. Well, it's
intentional too. It's because... Was it security considerations? Yeah, it was. Okay.
Yeah, it was. And also just simplicity of maintenance, because you don't need these
packages. I mean, there's a protocol, right? So you could build all of this without any of the
packages for sure. It would be really hard to sell anyone on it in 2026, but yeah, you could
do it without any of the packages and create a runtime and NAPLITs without using my packages.
Yeah, yeah. I see. I see. One of the interesting things about it is NAPLITs are single file.
So every NAPLIT is one file. And an NAPLIT is an application that does one thing really well
and is served by a host application as opposed to being like a standalone application.
And by making it a single file, you sort of implicitly
force people to sort of conform to that philosophy. Yeah, yeah, yeah. It has to be
small. Yeah, yeah. It's quite interesting also to look at, because
widgets were a big thing in a different era, like also operating OS level widgets,
both on any operating system, basically. Like on the Linux side, on the Windows side,
it was a big thing where just you have your desktop and you have all these widgets that
you can compose and so on. And even in the early kind of Web 2.0 days, there were also
some landing pages that were insanely widget heavy. And so it's kind of cool and kind of
interesting to see this emerge on Nostr. And before we go deeper into the basically
operating system you've built for it, you mentioned also that there are some
competing projects or projects that had the same idea. Fiat Jeff had one of them.
Yeah. Like talk me through the other projects that kind of try to do this.
Some of them are still going. Yeah, yeah, yeah. Yeah, but just it's kind of as a comparison and
just that, you know, like not everyone knows all this stuff. And as you know,
philosophically, I was always a big believer and a fan of HyperNode, what Paul came up with.
Oh, yeah. And it's kind of, it's very similar in style in some sense. Very different execution,
very different execution, but very similar, like spiritually. So talk me through kind of the other
projects that have been trying to do similar things. So I think if I do it in order, I guess
it would be Fiat Jeff, which I really don't know much about. He started it before the whole Jax
wave things in late 2022. Right. So I've only been working on Nostr. Ancient, ancient idea.
Yes, ancient idea. And I think probably too early, you know, for that kind of idea. But clearly this
was in his head. The next one that I'm aware of, because there could be others, that didn't
Yaki Hone have something like a view or something? Potentially. Yes, they had some. I'm not a Yaki
Hone user, so I don't know. Yeah, but I believe they had something similar, but it was very,
it's very simple, which isn't a bad thing. And then I believe Soapbox has Tiles,
which is slightly different. It's made for native. It's Lua based, which is cool.
I've been talking to that guy a lot, and that's a really cool project. Balazs and Fiat Jeff have
been, my project's a little bit inspired Fiat Jeff to revisit his original idea.
So he's working with Balazs, who is, they're working on Nostr apps or Naps.
So that's called Nostr apps, the project. Okay. Because I have to look it up later and link to it.
That one is good. It reminds me, if I look at the commit history,
it basically looks like my thinking from about a year ago. So, yeah, they're kind of solving
problems in a similar order, and maybe they'll come to a different conclusion.
That would be interesting. There's a lot of unique problems to solve, you know.
Like, you used the operating system briefly. It was pretty fast, right?
Yeah, it's fast. It was surprisingly fast and also surprisingly intuitive. And yeah,
it also looks very good. Like, I like that style of window management.
Yeah, me too. And doing things, so.
So a lot of that is because of how it's designed. It's the security posture.
Because of how it's designed. It's the security posture. It's the fact that they don't have web
APIs. And it's also that, you know, the main thread is kept, really, it's solely reserved
for rendering the DOM in the parent frame and routing messages. Pretty much everything else
occurs in Web Workers. I see.
And without that, CSP...
and sandboxing iframes. It's pretty much impossible to do that. You could just
have a napplet start calling every relay on Nostr and then no other napplet
works and then the parent frame crashes. I see. Right, and there's no way for
the there's no way for the parent frame to regulate the pressure of each napplet
and control it. So that's the primary difference between some of the
other existing projects and napplets as it is right now. Maybe that will
change. But that's the actually the only difference right now between Nostr apps
and napplets. Okay. They have different APIs and they have a different
philosophy as well. What made you choose the browser as an environment to build
all that stuff out as opposed to just doing a native desktop app or whatever?
Because as you mentioned, the napplet system is a protocol specification like
there's no need to do all this in the browser. You can write native code,
whatever, like you can use Swift and build an applet browser for iOS
and just do everything natively. So what made you do it in the
browser? Because the OS you showed off just works in the browser.
Yeah, which I think it's awesome. It's like it felt kind of magical to use it.
If you go full screen you wouldn't even notice. Exactly, exactly. So a few reasons.
So the first one is practical and also more like release strategy. The user
doesn't have to install anything. So you can give someone a link and they can use
it in seconds. They don't have to, like even anonymous user, the
onboarding could include just an anonymous user. You browse as Jack and
you're in. And just to give people an idea, that might be a good, like a lot of
people maybe know the Synology interface for Synology NAS devices and they
basically have their own OS, their own window manager and so on and it all runs
in the browser as well and you can, you know, drag your windows around and just,
you know, like right-click on stuff and the context window will pop up and so on.
And so very similar to what you've built and from the kind of just to get
people, to give people an idea of like what it looks. Yeah, how it looks and
feels basically. Yeah, exactly. So the other reason too is that it's sort of
permissionless because the runtime doesn't have any gateways like
Insight. It resolves, the runtime resolves everything and does all the
blob hash validation and so everything... Oh, that's an interesting thing that I
didn't think about yet. Okay. It can be deployed as an Insight. Yeah, yeah, yeah.
The shell basically runs locally and the bits and pieces are collected from
whatever, like Relays, Plasma Servers, IPFS, Torrent, whatever. Exactly.
That's very interesting, yeah. And so that... You don't need an initial
delivery in some sense. Yeah. Okay, yeah, yeah. And I see it, so it's not the
furthest edge, like I guess the furthest edge would be some microcontroller or
something with like a screen and like... Yeah, sure. I mean, it literally acts like an
operating system. Yeah. And you can boot it up and if you're, if let's say you're
offline and it's just empty, you just can't get stuff from outside, but it still
works. Exactly. That's how it's, yeah. Yeah, that's how it's... Yeah, interesting. Yeah, yeah,
that's a beautiful bug. Yeah, that's very old bugs. No, no need to fix this one. So
like, like it also sort of proves something. So it's on an edge that you
think this wouldn't work in. So if it can work on this edge and then you, you push
it all the way to another edge and you can get it, the protocol to work on that
edge, that's not web, then theoretically it should work everywhere in between.
Right? Okay. So yeah, the idea, the thinking was I do it in the browser, which
should be impossible. Then the next logical step is a browser or a native
app. Now, next logical step is a native app, then a browser, then an operating
system. And then like... By browser you mean an applet explorer. Let's walk up here.
We will be a little bit, you know, sweating and puffing and puffing, but
it's worth it. It's a good, good spot. The next step after that would probably be
like a custom kernel, like a microkernel, like a cyberdeck type thing, which is
really where we should be heading. A lot of the hardware is, you know, very well
guarded by, by the people who own them and like produce these. The hardware we
take for granted every day. So by... Oh, yeah. So I produced a RISC-V
microkernel that implemented some of the basic interfaces of NIP 5e.
I didn't realize that was an applet related. I felt it was a completely
different project. And I just implemented it to see if there was any like hiccups
in something, a completely different environment. The harder ones like
resource, outbox, and I implemented KB storage and one other one that's not
coming to me right now. And I was able to get that working with the 2e that was
in a moderately sandboxed environment. And once I could see that working, in
theory, I went full force on the website just to get it to the public. Yeah, I see,
I see. Yeah, no, it looks, it looks, it looks and feels really, really well. And
yeah, it was kind of magical to see all the, like, I don't know, the hit rate was
probably two-thirds or so of the cohort managed to create an applet. More. Oh, the
whole cohort, yeah, two-thirds. Of the people that were at the workshop, it was
probably like 80%. And you could just load these applets in your OS and it
would just pop up and would just work. You could load it in a strudel, it would
work. Yeah. Paya, it might work. There was a bug there. Amethyst. Yeah, Amethyst.
So, yeah, I still, I still don't really know how to load them properly or how to
view them all. But, you know, we had, we had some successes. Yeah, there were some.
The more simple ones loaded. He hasn't chased the spec. I don't blame him. Yeah,
you mentioned it's still evolving, right? Yeah, exactly. I'll probably have to open
some PRs. Or it would even be better if someone from the co-work, you know, from
the cohort opened an issue and everyone else put some thumbs up on it. We can
do those Amethysts, no problem. Yeah.
All right, that's the turnaround point.
It's nice though, right? You've been here before, right? Yeah, yeah, I believe so.
It looks familiar. My explicit goal, you see the dancing lights up there, the green and blue
lights, there seems to be a party. That's a really nice house with like a glass,
like glass window front. And it's right on top of the cliff and it goes straight down.
Oh, that's beautiful. My goal in Madeira is to get to know the guy and just, you know,
have coffee there and look down. That's one of my goals, why I'm here. I want to know who owns
this place and just come swing by for a coffee. Look straight down like 300 meters or something,
like it's an insane cliff. And the building goes like right over the cliff. Like it's literally,
if you're in front of the glass, like it will feel like you're floating. Is it like that bar
at Ponte de Sol? Oh, I don't think so. Yeah, there's like a bar and it's right over the cliff
when you come into the city and then you turn right before you hit this tunnel. There's this
bar on the cliff. All right, I'll have to check that out. Yeah, it's really pretty. Yeah, that's
good. Yeah, good place, good place. All right, so we have the, or you have the basically OS in the
browser. Yeah. In pretty good shape, I would say. What's still missing? Like what are the
bits and pieces that you still want to implement? You know, some polish, the onboarding.
There's still some bugs. You mentioned notifications that you mentioned. Notifications
are not done. Inter applet communication. Tell me a little bit about that. Like,
how are you thinking about like one applet spawning an action or spawning something in
another app? It's a scheme. So it's like NAPLIT colon archetype slash intent parameters. So that's
similar to like you open a deep link and an app pops up on Android or iOS and it does like,
I don't know, like everyone kind of knows this. If you, I don't know, like you have a video or
whatever and you go like share as a new post on Amethyst and then it will pop up and do the thing
and so on. So similar idea. Yeah.
And this is how the intents and all those kind of things, this is how this works as well.
Because I found that the semantics of data alone is really hard.
Let's go the other way, then we have a little bit of a loop going, we don't go the same
direction, I'm just saying, switch a route.
Alright so polish, and then you mentioned the next step would be...
So the insert and applet communication, right.
Oh yeah, sorry.
It's very late, and that was a long day.
I got to keep you on track.
So yes, it's similar to Android and many operating systems, the semantics of the data were too
constraining.
So the way they're defined, so this is very experimental, this could very well not work
at all.
But the way we're thinking of it is that if you're going to open a profile, you're probably
going to pass an npub or an mprofile, and we don't think that the developer that makes
the app that talks to profile needs any specification to do that.
We are kind of betting that people can sort of figure it out, because it's implicit, it's
like, what else are you going to pass to a profile intent, or archetype, right?
If it's like profile slash open, then you're going to be passing an npub, an mprofile,
maybe a hex, if you're mean.
Maybe an info5.
Yeah.
And, yeah, exactly.
And we're going to specify this in a repo somewhere, I really don't think so, and there's
probably, if this is successful, there will be hundreds of thousands of potential like
wire formats.
And we think we're going to try to figure that out later, because that is way too much
overhead at this point, to try to design some system to manage these messages that we don't
even know if this will exist.
So right now they're ad hoc.
So far it's working, Balazs made a profile in Applet today, and it worked.
It opened.
Yeah.
The feed, I believe.
Yeah.
I think at the point where we're at, the most important thing kind of is, can your agent
make sense of it?
It's less than, like, is everything perfectly specified, or whatever, like for humans?
It's just like, is it in the state so that it makes sense to the LLM?
Yeah, exactly.
And then also there's something magical about two developers being in two different locations,
never talking, and just sort of being like, hey, we agree, it works.
Or like developer A just figuring it out, like he's using developer B's Applet, and
he's like, how do I talk to this, figures it out.
And then he's just like, I'm going to use that.
That makes sense.
Yeah.
I don't think we need to specify everything.
Yeah, I think in the LLM world, in the agent world, over-specification is sometimes a burden.
So under-specifying oftentimes just works better, and they'll figure it out.
Yeah.
Okay.
So, no.
Oh, yeah, that's cool.
So that's next as well, right?
Like you said, you're still working on that, and the inter-Applet communication isn't where
it needs to be yet.
No.
Okay.
No, it's experimental.
We'll see what happens.
But you mentioned probably a desktop shell, and yeah, after that, the more esoteric things
that you just went through before.
So how can we best help?
If someone is excited about this, what's the best way to contribute and test it out and
help you move things along?
Well, I mean, the dev tooling needs polish, needs work.
Use cases need to be explored, and questions need to be asked and answered.
There is a danger in that, though, because it is a little bit jarring for most Nostr
developers to understand where the boundary of the shell, like the seam between the shell
and the Napplet is.
And so there's this tendency...
So it might be better if you're coming fresh?
A little bit, yeah.
So like a Nostr developer or anyone with a client can implement a runtime like right
now.
It's just a translation layer between the shell and their existing business logic.
How long did it take Hazard to implement the shell in Nostr?
I think it was working really fast, like kind of working in a few hours to a day.
I think he still has work to do on it, but it doesn't have that many capabilities yet.
But I think it was like two days or three days until stable, but I don't want to speak
for him.
Yeah, yeah.
No, but that's awesome.
At least it's not weeks, you know?
No, I think Vitor did it in like a day.
Yeah.
But he also had a very limited subset of capabilities.
Any developer can make Napplets because they have very little Nostr domain knowledge requirements.
You don't need to, like, they don't need to think about anything.
You don't need to like deeply understand how Nostr works and need to know all the kinds
and need to know all the, you know, intricate details of how the WebSocket connections work
and like all this kind of stuff, right?
Like that's the main benefit.
You can just, you can just do stuff more easily.
You can just build things.
Yeah.
That's awesome.
And you leave the security and the optimization to the runtime people.
Awesome.
Another cool opportunity is runtimes because I showed you like a pretty powerful runtime,
but they don't all have to be like that.
And they can be many different things.
So what you're saying is a runtime can be very slim.
Oh, yeah.
And very minimal.
It could also have nothing to do with social.
So I have a game from Sec 1.
It was pubkey land, but I changed it to npubland for obvious reasons.
And that uses Naplitz.
That's a runtime.
And you can use Naplitz as a mod system for the game.
Permissionless.
Huh.
Interesting.
So in that, in that context, you can like place items on the user's land.
And then when they go near it, you know, it pops up a Naplitz.
That can be one of many things.
Okay.
Then there's also global Naplitz.
So you could have like a radio station playing from like your own radio.
Yeah.
That's awesome.
Right.
It's a small, that's like a really small example.
Another thing would be something, nothing related to social at all, or like very loosely
related like music collaboration or video editing collaboration.
That's all possible as well.
You could have plugin systems.
You could use Naplitz as a plugin for that application.
And it doesn't necessarily need to be social, social Naplitz at all.
It could be very limited capabilities.
Yeah.
So you don't need to make use of the social aspect of Nostr.
Yeah.
You can just have the identities for the purpose of like sessions.
Yeah.
Basically.
Yeah.
I see.
I mean, one of the demos we saw today is the paint Naplint that Hazard I think built, right?
Yeah.
And so you, you literally have like this paint style mini app as a Naplint and like, yeah,
you can just load that everywhere and just do your thing.
Yeah.
You can load that in any client and you know, it can be used for whatever.
Like you could mark up images.
A client can say, okay, cool.
I want, I don't know if it has this capability right now, but you can say, Hey, load the
image into here and then from somewhere else, yeah.
Mark it up and then post it as a comment.
It's a very interesting way of like decomposing.
Let's take Amethyst as the kitchen sink, everything client, like no offense to Vitor, but everyone
knows that it's just like, whatever is out there, Vitor will put into Amethyst.
It's a good thing.
It's a sandbox.
Yeah.
It's fun.
And so kind of with the Naplint line of thinking, it's basically every, almost every feature
of Amethyst or every, every screen in some sense and those kinds of things can be done
as an applet and can then be recomposed in one of the shells.
Like again, like it, it, it looks and feels like an operating system and it just like
pull out these widgets and place them where you want to have them or like arrange them
however you see fit.
And they're very loosely coupled, like the paint application we just mentioned that we
saw today.
Like you paint the picture, whatever, like paint or annotate something and so on.
And then it's literally like right click, copy image, and then you go to your like whatever
send tweet, send post kind of thing or to your long form applet and you just paste it.
And you know, we're back in the good old days where everything was very simple.
So that's really cool.
It's really exciting.
It's fun to see what people come up with.
It's amazing how well it works.
Like I was blown away today how well it works and how fast everything is and kind of, again,
like just deploying, deploying an applet, it's basically you have this one file and
you sign it and you push it to a relay and then it's just out there and you just like
I basically created a mini-app in like five minutes on my machine, pushed it out,
like published it to nowhere. Like you compared it to ZapStore as well,
right? Like with ZapStore as well, where you just push it to your
relays, it's out there, and your operating system basically immediately
saw it, you immediately drag and drop the thing onto your desktop, and it was there.
It's amazing. Yeah, it really is. It was fantastic to see how well it
works and how everything plays together. And how many different napplets
came out, too. Almost everyone produced a napplet. There was a chess game that
works, multiplayer, although you can make, as the player, you can make
both moves. Yeah, Kaviadapter, you know, like, absolutely everything is alpha, including the applets.
Yeah, of course, of course. And it's also nice to see it like go into that exact
same napplet, go into another runtime, and it does the exact same thing. Yeah, yeah,
yeah, really cool, really cool. Yeah, yeah, awesome. And so you got sidetracked by
that, basically, and the whole napplet idea swallowed you whole the last 12
months or so? Well, I wasn't working full-time on it. Yeah, I didn't have
the energy or resources. Because you've been involved in quite some
projects, you know, like lots of stuff on the relay side and those kind of
things. You mentioned you had this idea very early on. Was it helpful to,
like, talk to me a little bit about the Nostr journey you went through
in terms of development? Because pre-napplets, I feel like you occupied
yourself with very different ideas. Yeah, I mean, you could say
that. It actually all builds up to this, if you look at it, right? So, like, and
also I want to sort of correct a previous statement. I didn't
have an exact idea of this, but it was like a feeling that I didn't really have
words for. And I just knew that it was on the horizon, but I also knew it couldn't
be done right then, like when I first found Nostr. I mean, my journey started
because I was on a self-funded sabbatical in 2022 and I was kind of
miserable. Many such cases. Yeah, and I was getting off of it and I was like,
okay, what am I gonna do? Am I gonna go get a contract? Am I gonna get a job? And
I was like, no, I'm gonna, like, play around a little bit. I'm tired of that
scene. And so, I launched the Lightning Node and I installed, I was playing
around with various open-source software. I think it was LNDG and then there was a,
right, there was an input for a Nostr notification. I'm like, what the hell is
Nostr? This must be related to Bitcoin. And then I clicked on it. The repo was
already starred. A friend of mine later reminded me that we ran into it in 2020
when all the censorship stuff was going on, but it was just like a repo. And then
we were actually looking for something to use. We weren't looking
for something to build at the time. But I had started, I was looking around, I
started playing with Astral Ninja. I saw that it had activity, you know, maybe
like the same 10 people over and over. And then I kind of just wanted to learn
more because it seemed very interesting the way that it was laid out. I read NIP
1 and it kind of immediately something happened in my head and it just felt
like an explosion. Like, I don't know, it's hard to explain. Like, the whole mind
blown. Immediately made sense. Yeah, like in a weird way. And not everything made
sense perfectly, but something very deep lured me in. Yeah, let's maybe have a
sip of water before we collapse and also get a bit of distance. Yeah, that would be a good idea to
those. Yeah, you know, usually after an hour it's like your brain needs a little
bit of water. Yeah, and like very little sleep as well. On a hot day. It was a long,
long day. It was a long day, yeah. There you go. Yeah, it's very late. It's, you
know, well. Oh, come on, 10-17. I've had later nights with it. You know, but I, you know, like I'm an old man, I go to
sleep with the kids usually. This is two hours past my bedtime. All right, yeah, I
have some more before, like, you know, stay hydrated. Where's my, where's my
hydrometer? Yeah, I could lower my heartbeat a little bit. So I was looking for something to do
because the, I was just curious, okay, what relays are out there? And then there was
Nostr Relay Registry, I think it was Fiat Jaffs, maybe not, I don't remember.
But I forked it, and then I was just, also the other thing is, is that I hadn't
been working at a low level, as a low-level developer for many years. Like
I'm a developer, but I was doing higher level things, and so I also sort of
wanted to sort of reacclimate to, to development, and also I, it had been even
longer since I was doing front-end development. So picking up the, a fork of
Nostr Relay Registry, which was sort of hurting and barely worked. And that
became Nostr Watch. And that became Nostr Watch. And then like I got sick, I
got the flu, and I remember I was on my couch, I was like bedridden for three
days, and my phone just kept vibrating, like over and over for like, for like
hours. And eventually I could like, look at the phone, because you know, I was very
light sensitive at the time, with the flu. And, and I'm like, it was like, like 50
pull requests, and I'm like, what the fuck? So I like go, and I'm like, okay, people are
adding relays. I'm like, wow, that's a lot of relays. Like this, there was I think six
relays online, when I started the thing. And it took me about a day to figure out
that Jack had posted it, and then other people were sending people there to add
their relays, so that other people could find it. That became a whole thing. It's
a, that's a mess. But I mean, it's the thing is... I still use Nostr Watch. I know, I know, I know. A lot of
people do. It, it just, it took a lot out of me. And a lot of things happened to,
like that year, in 2023. And it was just a pretty hard year. So yeah, a lot of those
memories are tied in with that sort of experience. Yeah, I see, I see. And also, you know... Having a side project that kind of, you know... Like sucks it out, like you're just being basically insulted every day. It's not always good. Not, not, not, not, not every phase of your life is side project friendly. Exactly, exactly. It's, it's
really stable now. I never touch it. I mean, there was a cross-site scripting attack a
couple weeks ago, and I had to do an update. But other than that, it runs itself.
It's very cheap. It's fast-ish. I mean, the client kind of sucks, but the, the infrastructure is solid. No, I still use it. I use it all the time, mostly to find like NIM50 relays and like to just kind of, you know, health check my own stuff and all kinds of things. I think it's, it's, it's very, very useful. Yeah, thanks for building that as well. Yeah, that's great. I appreciate it. I don't get, I think I've gotten more thanks recently for it. But up until a few, maybe like six months ago, it
was definitely, I got more crap for it than, than thanks. I mean, that's always kind of disproportional. Unfortunately, on the internet, like it's, it's, if something annoys you, it's very easy to scream at the guy and like, whatever, and shit on stuff. And, and, and most of the people that are super happy with, with things are just silent. Like there's a silent majority that just, you won't hear from. That's just how it goes. But yeah, you, you ran into Ensight early on as well. And you build
Ensight.run as well.
Yep. Yep. Well, both Ensight.runs.
Yeah. Fair enough. Yeah. Ensight is such a weird project. Because, you know, the guy, when was it? Was it the second, second cohort?
Yeah, Sec2.
And, and like the original author of Ensight, like, didn't really understand what he had with Ensight.
Yeah.
And so other people had to pick up the pieces and move it forward. And you were one of them and Hazard was one of them as well.
Hazard was the big piece of it. Yeah. He took over the spec.
Yeah. Yeah. And so, so now, now it's definitely a thing. And like, you know, half the demos we see, and like from SCC 03, 04 onward, like half the demos were deployed as Ensight.
So that's, that's quite something.
That's really great to see.
So what, what made you, what made you excited about Ensight? What made you build Ensight.run at all?
Actually, nothing to do with Ensight. To be honest, the first, I didn't have high hopes for Ensight. I mean, obviously, it's interesting to me. The reason why I did it is because I really love CLI interfaces and TUIs. And I wanted to build a TUI. And I couldn't, and Florian did a great job at doing the first, the first CLI for Ensight. But I really, I like automation. And I didn't want to put my private key in some secrets field on some random website.
So I needed NIP 46. And so I needed a more sophisticated key management system. And I was like, I want to build a, I haven't built a beautiful CLI in over a decade. So I like, that's, that's the main reason I did it.
That's awesome.
And I didn't expect that when I released it, that was the first time that a lot of people.
knew it existed. And then that kicked off people launching
gateways and making their own CLIs and all this stuff, right?
And people tried to use it. The first version didn't work very
well. So I started the other end site, the end site with the
that's spelled correctly dot runs to sort of coalesce people
around the specification. And then over the next year, I
think it was, Hazard slowly developed the specification,
identified things that were wrong. I think at one point, he
was willing to give up on it. But he pushed forward, and he
pushed a new spec, I believe it was December of
2025. He finally like we landed somewhere after some contention
about how it should actually work. And nobody updated
anything. And so I was kind of getting pissed off and fed up
with master to be honest. And I was like, I need to take a break
from this. But I remember like, yeah, I told you to go into the
woods and stay there for a couple months or like, you know,
going to so like, you didn't listen. No, I didn't. And so I
was like, well, before I do this, this end site thing is
pissing me off. No one's updated their stack. So I sort of just
learned from the first time that it's just if you do it, then
other people will follow. So I built out I basically just
chased the spec everywhere. So I released an insight be to
gateway blossom server for it. Not that it matters, but in a
relay that only accepts inside events, and then I updated the
CLI. And then I added a web deployer, so you wouldn't have
to download anything. And you could just drop an aesthetic
site onto the deployer. And it's actually the it was made really
funny too, because the infrastructure is it's all edge
scripting on bunny.net. Okay, everything, the relay, blossom
server, like it's there's it's completely serverless and like
has very tight constraints. That was kind of a fun problem to
solve. And it barely works, but it's very cheap to run. And that
was actually not intended for long term infrastructure. It was
just to get people to update their their stack. Yeah. I'm
actually going to take it down soon. So push that out, you
know, made I think I shared something I pushed that out, it
got some traction. And then I made a novel sort of proposed a
novel idea about how you can use insights with like stealing them.
And like, Oh, yeah, steal this insight. But and that and that
had like a virality to it. And then that gave me the leverage
to then like tag everyone who has infrastructure and say
update your shit. Yeah. And then it got updated. And a week later
it was merged. Yeah. So awesome. And you mentioned like all these
little parts of your journey. Like, like, everything that you
just mentioned, led to the napplet idea in some way. Yeah,
kind of. Yeah, it did. So relays too. So hard coded relays really
bother me. I mean, you're always going to have a bootstrap.
That's always going to be a part. Yeah, I mean, yeah. But
there are all there's so many different varieties of relays
that you start to hard code relays and everything and to
have a truly like, dynamic system. Yeah, I need to have a
way to find them. Yeah, we need we need relay discovery. And I
mean, that's why Pablo has been harping on, you know, outbox for
such a long time. Because otherwise Nostr is kind of
like, yeah, useless. Yeah. If we don't have that everything will
centralize about one around one or two big relays. Yeah. And
outbox solves most of it, but it doesn't solve every problem.
Yeah. So talk to me about NIP 66. And you're Oh, gee, are you
sure? Are you sure your audience wants to hear anything about
NIP 66? Because it's related to all of your audience. I mean,
I'm pretty sure they all just turned it off.
Like, you just have to be like, we're not doing this for the
audience. I'm doing this to pick your brain. And you just have to
be okay, like the way it goes is like we start to walk. Yeah, we
have like, maybe five people listening, you know, right. And
then like, after 20 minutes, maybe it's down to three people
after an hour, and we're an hour in now. After an hour, it's like
one guy with half a brain listening, maybe, you know,
sleep. Yeah, it's probably Pablo is asleep.
Like, that's, that's how he goes. So, so, yeah, talk to me a
little bit about, you know, like, how you think about
outbox and and really discovery and talk to me about NIP 66 as
well. I want to hear it all.
Yeah. So like, so so NIP 66 is really interesting to me because
it it it's a state is using Nostr as a state machine. And
it's fuzzy, it's not a global state, it's relative to what the
user trusts. The end pubs like a monitor, an observer is just an
end pub publishing that some information about a, about a
relay. And that can just be someone you follow, or that
could be your web of trust, that could be anything. It's a base,
it at first glance, it seems very arbitrary and useless
until you actually understand the domain of relays on Nostr.
It's actually really freaking complicated, because they're
just fuzzy strings, they're, they're, they're not guaranteed
unique. NIP one up until recently, didn't specify any
rules around how relays should handle their segments or paths.
And so damas like relay dot damas.io is the same as relay
dot damas.io slash GG, both will respond as a relay. This
creates all sorts of optimization problems for
clients. And so and so this is just an example of one of the
complexities, there's a lot of them. Most of it is garbage. I
mean, there's like, probably like 15,000, if not 20,000
unique strings that are relays, but most of them are either
online, or it's just garbage. You know, some client bug seven
months ago that still exists somewhere. Okay, interesting.
Yeah. So that's like one problem. The other one is, is
that, like, if you want to find out a band relay, so you want to
find, for example, like you're saying, NIP 50, doing that in a
web of trust will probably be difficult. There's no way to
say, hey, I want all the NIP 50 relays in my web of trust without
hitting every one of their NIP 11. Yeah, deduplicate,
deduplicating the relays on client side. And you can do this
over time, actually pretty efficiently. And, etc. But it's
not only just discovery, because you can build data on top of it.
So there is a NIP called trusted relay assertions.
Yeah, I saw that recently. I still haven't wrapped my head
around the trusted assertions.
But yeah, it's so trusted relay assertions are the same idea as
trusted assertions, but for relays. And that's someone
building data on top of the liveness data. So they know
what, because what the liveness data does is it reduces the
amount of work someone else has to do to build on top of that,
right? And now you can sort relays based on these, you know,
subjective trust scores. Yeah. And there could be many of those
and you could pick which one you support. Yeah. Okay. So then how
does this help anything?
Yeah. Ping, reachability, liveness, is it in your web of
trust, all those kind of things.
Exactly. Yeah. So then like, there's a lot of uses for this
and some of it is contentious. And there's been some people
that have chimed in and said that they don't like the trust
model. But you can use this data in order to optimize your outbox
connections to prioritize as a second layer of prioritization
after web of trust grouping. So like you need to group the
relays by how many of your followers are on a specific
relay so that you get as many notes as quickly as possible,
right? Yeah. But you can do a secondary pass on speed, you can
do it on trust, you can do it on decentralization, you can do it
on specific NIP support if you're looking for specific types
of notes. Yeah. And this makes the client more responsive. I
actually use the first thing I did in hyper in the in the
operating system is to implement NIP 66. And it's used very
exclusively in outbox optimizations. And to help with
also like auto complete throughout the entire
application and any NAPLIT really. And I found it to speed
things up quite a bit. There has been research by someone that
has been contentious in the past. But my findings have
mirrored what he found as well.
We're not gonna name names. No, it's okay. You don't have to.
No, I like him. He's a friend of mine. But he caused some
problems in your repo at one point. And, and there we go.
Identified.
It's okay. It's okay. It's okay. He's a really nice guy. One of
the one of the sweetest people I know. So yeah, I mean, it's,
you know, adding the ability to discover relays might seem
arbitrary. I mean, it kind of is. There's not that many right
now. If you include Tor and I2P, it's like 1500 after the
duplication. There's some margin of error because I mean,
that's more relays than users. Yeah, pretty much. Yeah. And so
there is a lot of relays. Yeah, yeah. What the fuck?
That's a bird. Oh, wow.
That was the weirdest sound I've heard in a long time. I thought it was like a drone.
Yeah, me too. I was like, where is G? Me too. That was super weird. Like that was a very weird
sounding bird. Yeah. See? Night active birds. I really hope the microphones pick that up.
That's so weird. That's the weirdest sound I've heard in a while.
Holy shit. Squeaky, random squeaky bird.
Anyways, I could go on for hours about the intricacies of relays. It's not that interesting.
I think it's more interesting to me.
The fact that you mentioned that you created a relay that exclusively accepts,
in what context was it? I'm blanking now. Nsight. Nsight events. That's fascinating to me. I always
loved Pablo's idea. Holy shit. What kind of bird is that? I think it's an alien. So strange. Anyway,
so he did purple pages, of course. Yeah, of course. Early. Very early. Very early. Yeah.
I'm very tempted to kind of go hard on my relays. I have a couple of relays,
mostly Web of Trust and just Haven. I use a lot for basically personal use and backups and so on.
And I want to do my own instance of purple pages just for profile lookups. And I want to do one,
I want to rebuild Boris, my highlight app. And I just want to do one for highlights and long
form stuff and so on. I really want to lean into the specialization you've hinted at.
So how do you think about going forward, the evolution of relays and relay discovery and
relay specialization and all those kind of things? Yeah. So Hazard and I have been bouncing
off each other for a year and a half, I think. And we were talking in Costa Rica
like eight months ago or so. And we settled on relay attributes. So you can add attributes to
your NIP 11 up to nine pascal case. There's a reason for that.
We anyone who aggregates them should truncate anything after nine.
And that allows them to be found based on self-descriptive words about the relay,
not technical implementations, but subjective decisions made by the relay operator or developer
that resulted in the way the relay behaves. So an example would be like pubkey indexer,
which would be purple pages. But we're not trying to atomize them at all. We don't want to. We think
that people can just coalesce around words and form their own words. And it'll be messy.
Yeah. Like hashtag clouds, whatever. Exactly. And that would allow relays to be found
based on what they do. And in this case, like highlights, you could come up with some
terminology and coalesce around a term with similar relays. So that is sort of the endgame
because at that point you don't need to hard code all these relays. You can actually even allow
users to fix it themselves. And it's intuitive. Yeah. Yeah. I think also in terms of, I think
tagging kind of is the right approach because it's not only what kind of data do you allow?
It's way more than that. It's like, what capabilities do you offer? Like you might
support search NIP 50 or you don't. It might be a web of trust gated or it isn't. It might be paid
or it's free and all those kinds of things. You have all these dimensions of relay specialization
and yeah, or you just whatever. Geoblock, like the Japanese relays. It's like,
if you're not from Japan, like go fuck yourself. And yeah, no. Okay. All that's fascinating.
You can already right now without the attributes, you can already do payment filtering. So it's just
capital R tag and then payment. And then if you want it free, like no payment, it's
exclamation point payment due to the limitations in NIP 1. And then also the same for restricted
rights. And then also for proof of work. So you can find proof of work, relays. You can find paid
relays, public relays. You can find ClearNet, TorNet or Tor, I2P, soon FIPS. If someone does it,
I'm waiting for someone else to do it. I could easily do it, but I can't do everything. It's
like someone else needs to find the need and do it. We'll nerd snipe someone with the FIPS stuff.
I think it'll be more important in the future. I'm being honest. And maybe there'll be a better
way to do it in the future. It may have been a waste of time, but maybe not.
Yeah. Last thing, last 20 minutes. That will be 20 minutes to the tunneling, something like that.
Um, your development setup, um, that has been happening since basically SCC03 or something.
Like when, when, when vibe coding came around, you were one of the first people that I know
that went like, okay, like, let's just do waterfall. Like the agents are really good at waterfall. So
write the specification, like everything that's like 30 years old is perfect. Like it's, it's,
the LLMs have gobbled it up and internalized it and so on. And, and, um, yeah, I, I want to hear
more about your vibe coding journey and like how it evolved and how you started. And you,
you talked about it a little bit when you mentioned that your friend, you know, like he,
you weren't using anything from the anthropic side and he made you like look into that and so on.
And, um, yeah, you, you showed some of the things of today in the first workshop,
workshop session as well with like, uh, GSD, uh, gadget done and so on. So, so, so talk to me about
not only the evolution of your tool set, but also how you think about basically how to,
how to properly build production ready stuff. Yeah. In the gigantic world, because I think
you're exceptionally good at that. Like you're, we talked about the distinction today between
prototyping and building something that's production ready and like, you know, explain
where you're at and, and, and a little bit, talk, talk me through your journey.
Sure. Uh, it started really early. I mean, basically right when LLMs came out, a bunch of
nerds, you know, the first thing they try to do is make an agent. That's the very first thing. It's
like, uh, you had two, two big projects, um, uh, auto GPT and baby AGI. Um, neither of them really
worked. Right. I could, I could get agents to go in loops and have turns and sort of go in some
direction. But like, imagine, you know, like when you get angry at your agent, imagine it's like
points were like a hundred points lower. That's what it was like. Like you get angry at it for
like writing comments somewhere and leaving a stub or to do like this thing would like write
the same file over and over like a hundred times, like right next to each other. And then like, go
to your root folder and just start, you know? Yeah. Um, uh, but that's where it started. Um,
and then I tried, cause I have an experience, you know, I've, I've worked with teams. I've
ran teams. I've been doing it since I was pretty young. Like some of my earliest projects were me
hiring people in Eastern Europe to do projects for me. And I would learn from, you know, working
with them, how to do things. And it was a great education, um, better than any university
experience. So you were, you were agent babysitting before it was cool. They all had a
Russian accent. Yeah. Usually, usually Ukrainian or Romanian. Same, same, all the same. Um,
so I have some experience and so I would try to apply that because it seems obvious you have these,
these beings that are non-sentient, um, but you can give them instructions and they do things.
These entities that produce code. Yeah, exactly. So it seems obvious to me that, you know,
this is where it was going. And every few months I would always try,
like, see where it was at, see where it was at. And at some point in 2024, it became obvious to
me. I think it was actually Fiat Jaff asked me about it. He's like, so how's AI doing? I'm like,
I think we're getting close. Um, I said like a year or something. I think I was right.
I don't remember the timeframe though. Um, and I, when was the first time I had success? It
was the end of 2024. I was a reasoning model. I think it was the end of 2024. It could be wrong,
but I think there were some reasoning models that finally came out and that obviously they're not
actually reasoning, but for the first time, let's build up some space for the first time.
I was able to give an agent and instruction and it would start to
inflect on its decisions. And when that happened, I noticed the abrupt change in its ability for me
to delegate something to it and for it to come back to me with something of value. Um, and so
then I started trying this more often instead of every three months, it was like every couple of
days. And I tried different, uh, SDLCs. So I tried agile. I tried various forms of waterfall. I tried
um, like just like general iterative development. I tried to do like extract characteristics of
agile that didn't suck and use that. I, but every time I hit waterfall, it worked really well. So
I would just define a high-level document, I would work with an agent, well really I would start
myself writing out a spec, I would sort of expand that with an agent, then compress it a little bit,
get rid of things that didn't make sense, and then when I could read it and when the shape
of the document looked right, I would feel confident and I would break that into low-level
design documents, and those were little chunks of context that were very specialized to a specific
part of the stack, and I could give that to an agent and it would come back and give it to me
exactly as I'd asked for. And I may have skipped some parts in there, there was definitely struggle,
but I don't remember all of it. What kind of models did you use where you had this success?
I think it was around GPT 5.0, because that's when, if I remember correctly, that's when
things started to make sense. I could be wrong about the exact version,
but it was chat GPT. It was pro. I got pro and it was able to do things correctly,
do research. So GPT 4.0 or 5.0, that era. Yeah, late 4.0s, early 5.0.
I don't remember the years of any of this stuff, it's all a blur kind of. Yeah, yeah, I mean
definitely. I mean we're still in the it's all a blur stage kind of as far as I'm concerned.
Yeah, so that was like the first successful thing where I could plan something out, I could feed it
into this manually, by the way. There was no looping or like there was no context injection.
I didn't have my own agent or my own harness. This was all just manual and it was working
pretty consistently. And then at this point, now there's like tools everywhere. You have like
Rue code and you have all these other tools that are just kind of doing the same idea. So I started
playing around basically with everything. I found some success and honestly pretty much
all of the tooling I think is good for someone. But I never didn't really run into anything that
worked great for me until GSD. Like that was the first one where I could, it worked exactly
with how I thought. And I was able to very clearly define a project scope and iterate through
milestones and capture things and bring them up to the surface. And so this became what I'm doing
now. And I've been on that for seven, eight months, I think. Okay, interesting. Seven, eight months and
with little change from your approach. No, it's changed. But your GSD stack grew in some sense.
A little bit, yeah. And I have been doing loop engineering as well, which has replaced a bit of
it. And I do anticipate that I'm nearing the end of that with GSD. Things are just going much
faster now. I'm probably going to outgrow it very soon, if not already. Like I'm just waiting for
something like GSD to come again. I anticipate I'm going to replace it. Okay, so next iteration
of GSD, whatever that will be. Because like loop engineering is, like GSD is basically loop
engineering, right? So it's like a template for it. It's a very specific workflow. And it works
really well. But yeah, there's something on the horizon. I don't know what it is. But you're right,
there are cockroaches. It's just like dancing, too. It's weird. Yeah. The yeah, there's more
things in the future. I'm not stuck on it because I do test other things all the time.
Uh, Fran shared something a few weeks ago, I tested it for a couple days. It's very lightweight. I
think it's open spec. I think that's what it's called. Really, it's actually quite good.
If you're someone that doesn't like the heaviness of GSD, I'm almost certain it's open spec. So I'm
I hope that's what it is. Yeah. Then that is really quite a good starting point because you
could build on that to create something like GSD without all the heaviness. For me, the heaviness
is good. Okay, so my my flow now is, it's really a back and forth. So I when I start a project,
I have like a agents.md template that's very small, it just has some basic policy things
that they change around what the project around some of the constraints or parameters,
language of the project. And I will start a new project in GSD, I will have a pretty good
conversation, produce a series of documents, GSD does like research, right when you start a
project to understand the domain, so that it can make more informed decisions. And it's really
important that you, especially if the domain you're in is novel or experimental, that you
check those documents like Nostr. Although models are getting really good with Nostr. Yeah, yeah.
Before they used to hate it. They're like, what the heck? Yeah, now it's a thing. And it's part
of the training data. And they're not as confused about it. But in the beginning was, oh, it was
terrible. We were always fighting the model. So they were always trying to do client server,
rest interface, kind of like everything, username, password kind of stuff. Right. And, and it was
painful. It was so painful. But the building up context for a new thing. Yeah, that's one thing
I forgot to mention today, when I showed off my stuff. It's a very small thing. But the way I do
it, like, I do very primitive context engineering. And I use the Socratic method, basically
exclusively. So when I start a greenfield project, very new thing, I just the first 10 prompts will
be questions. Yeah, like, what's out there? Like, what's, what do you know about this, all those
kinds of things. And from that, I'll land on the design document that you mentioned. That's actually
what the the the new project, and the planners use the Socratic method. So it will ask questions
to you. So instead of you asking questions, okay, it will ask questions to you. And then use that
input as a question for how it approaches the research. Yeah. So I always do it just to be sure
like, like I showed off today, every, every one of my projects has an NPUP and I use NIP17 to
communicate with the project. And let's say I want to add a search keyword to ants to the
Nostr search I've built. And then I would go like, like, I already know what I want to build.
But I'm not going to hit it with that. I'm going to go like, what are the search keywords that we
have? Yeah, you know, and it already builds up context. Okay, so these are search keywords. And
I go like, would it make sense to add this one? Yeah. And it would go like, yeah, that makes
sense. And we could do this and that. And it's like, okay, like, you know, like, give me like,
how would you implement it? You know, and then it would we iterate a little bit and so on. And then
once I'm happy, I'm like, okay, go, let's implement it. So just Socratic method through and
through. Yeah. And then I pull the trigger and then it's basically done. Nice. And I also always
end I mean, I mentioned this today. I always end like I use the same development workflow I've
always used to feature branches and so on. And I always end with like, what's the top five
things we could improve on this feature branch? Yeah, like before, before I merge and so on.
And so so like, oftentimes, one or two things are okay. And then I ask again,
and if all top five are complete bullshit, then I know I'm done.
Yeah, exactly. Exactly. I do the same thing. Yeah, yeah. It's a similar workflow. Yeah,
it's a slightly different approach. It's a little yours. Yours is yours is probably more automated
and more more structured a little bit. Yeah, mine is very kind of Yeah, I use like automated agents
for issues. And my agents are very like under a very strict policy for how they interface and
interact with other repos. Yeah. And how they interact with issues and pull requests. Yeah.
And then I have automated agents that go through and look for sloppy issues.
Yeah. likely posted by me, and then they contextualize them and put in like basically
do the planning for the next agent. And then there's a the development team will then come
in and look for issues. Yeah, cron, right? Yeah, same thing. Yep. And then it'll address them open
a PR and then I have a review team. Yeah, come in and review them. And then I do the final review.
And if something's wrong, it means I fucked up somewhere. Yeah. And I don't blame the agents.
Yeah. I haven't gotten angry at agents in a long time. Yeah. I never did. I never I never
believe eight months. No, there's there's never believed in screaming at them. Dude, they have
done some things. Sometimes like Claude and like a year ago, it would just do things where you just
thought it was trying to fuck with you. Seriously, I mean, maybe you may lie to you. Oh, no, no,
I think that I think that you go into the code. And it's like, like, yeah, I can't fix. Yeah,
tell operator it's fixed or something. The gaslighting the gaslighting. That's for sure.
But it's funny how we are rebuilding the same structures that we landed on in regular software
development. Yeah. But now instead of humans, we have agents, but we still have specialization.
We still have communication. We still have issue tracking. We still have milestones. We still have
specifications, all those kind of things. And I think that's why you're especially good at all
this stuff, because like you said, you started at a very early age working with teams and working
with teams that come from other cultures, speaking other languages and so on. And then you have to do
all this stuff properly. Like you have to specify all the things properly. You have to test stuff
properly. You have to do all the other things. Absolutely. I was pretty bad at testing, though,
until like the late 2010s. Yeah, I hated doing it. There's a there's a time and a place for
everything. I still for my vibe coded slop. I still don't test anything because I feel like
it pollutes the context and pollutes everything. And I just like no tests. It's one of the rules
I have like never write tests ever. That's hilarious. I prefer. Well, it depends on what
I'm working on. Right. If it's UX or interface, none of my stuff is important. That's why I can't
get away with it. But but speaking of that, you mentioned one thing that you gate using
LLM slop detection. Oh, yeah. So talk to me about that. That's pretty simple. I mean,
it was like a couple months ago, a library got popular called AI slop scan.
And it works pretty well. And that one's built only for JavaScript. I found the one I was talking
about for Rust that was on crates, and I shared it in the gist, but I don't remember it right now.
I use that in my agents.md. I use that in my CI, and it basically prevents...
Ah, nice. In the CI, that's awesome. So pull request won't go green until it passes the slot.
Yeah, that's awesome. That's great. I'll add that.
Yes, you need to. It makes a world of difference, because every time you add slop,
you're adding context poison. Yeah, forever, basically.
Yeah, and until you spend three days getting rid of it. There is nothing more difficult
than renaming a term in a code base. The agents will come back to you and be like,
okay, yeah, the term doesn't exist anywhere. And then a week later, it pops up again,
and you're like, wait, we did this. It's like, oh, wait, no, no, the function signatures still
have it. Oh, okay, okay. Go through all the signatures of the functions and the properties
and every parameter of everything you can find and get rid of it. And then it's like,
cool, I got rid of it. And then a week later, it pops right back up.
Naming is still one of the main problems when it comes to development.
God, it's the worst. The worst, man.
The more things change, the more they stay the same.
And that word could just, its meaning could screw you. It's like context poison.
Yeah, the slop scan, that has been a game changer for sure. That makes reviews easier.
The code quality stays more consistent because the code becomes the context at a certain point
in the project. And it defines the patterns that every agent uses. And when there's good patterns
already in the code, it produces good code. Also behavioral, test-driven development,
behavior-driven development. I've been doing that a lot. And that also works really,
really, really well. Not at the beginning of the project though, but at a certain point,
it starts to create certainty behind every single action. They don't fake the tests.
When they write the tests after the functionality, they fake the tests.
I'm a big believer in opponent processing. You want to have a specialized tester,
and you want to have a specialized implementation guy, and they must not be the same guys.
Yeah, absolutely. They have to be different. And even different models,
some diversity in the way they approach the problem is really helpful.
Yeah, 100%. No, I love that everyone is figuring out similar patterns and
and the same way of getting shit done.
Last question from my side. How do you think about running stuff on bare metal,
buying lots of hardware to run models, all those kind of things? Because I'm very close
to just saying fuck it and buying a bunch of shit.
Yeah, just dropping 50 to 100 grand.
Instead of buying a new car, you might as well.
Um, yeah, I think we need to do it. I mean, I think we should squeeze as much as we can out
of the subsidized models and services. I mean, the subsidy era will end.
Yes. And that's why I'm thinking about it. And when it ends, the prices are going to go up.
Yeah. Yeah. So, yeah, I think we should all be doing it.
Yeah. You explored any of that stuff?
Oh, god. Yeah. Oh, yeah. Yeah. Yeah. RTX 6000 Pro, Blackwell, that seems to be the route right now.
The only limitation is, like, SPI. I met someone in Oslo who was working on getting SPI working
on the Blackwell cards, the 6000s. And he says that basically it has all of the chips it needs,
but something's not connected. And last time I talked to him, he mentioned that,
or when I actually, like, how many layers of tinfoil do I need?
I assume it's like a jumper, basically.
How deep does the conspiracy go for that?
Well, I mean, it's NVIDIA. They're known to do this.
They arbitrarily limit encodes and decodes on their GTX cards to, like, four.
But they can totally handle, a 1050 Ti can do, like, 12 or something, but they just limit it
to four. So when they introduced this limitation, it was because they wanted to sell enterprise
cards at, you know, 10 times the cost. And someone released a bash script that removes
the limitation. You just run it when your system starts, and then it removes it, and you're good
to go. It's like chip tuning your car.
It's just called NVIDIA patch, I think, if I remember correctly.
So, yeah, I think everyone should do it. I have explored. I have some hardware waiting for me,
and I can't wait to get a hold of it.
Hardware waiting for you at home?
In the US, yeah.
So after the court, you'll go do an unboxing video and set stuff up?
Yeah.
All right.
Yeah, I think everyone should. But at the same time, it's sort of like Bitcoin mining,
or mining in general. It's a massive investment. You can't get attached to it. You have to watch
the market. You have to cycle your equipment. Otherwise, you're going to lose money. Because
it's like cost per watt is what you're really looking at, right?
So, yeah. But to me, it's like, it is going to be a timing issue, because we're still living
in the subsidy era. It's like, Pablo figured out this hack, how you can use unlimited compute,
thanks to JetGPT.com. You know, like he built an MCP wrapper on JetGPT. And you can just,
like for example, analyzing code and so on. He will pipe all his repos through JetGPT.com,
and it doesn't go towards your plan or anything. And we're still living in crazy times. It's
because of people like Pablo that do this shit. The AI bubble will pop, you know, like incurring
costs of like 50k USD per week or something. And there's nothing anyone can do about it. And so
this can't go on forever. Yeah, token use will have to get economical.
It does. Yeah, we got to optimize. Everyone's just leaning on compute right now.
Eventually, I mean, it's already happening that people are optimizing. They're squeezing every
last bit of power out of small models. That's going to get more and more intense. Things are
going to get more performant. It will hit a point where these models we're using now are going to
look ridiculous. It'll be like a mainframe, right? We'll look at it as like the old days.
You mentioned Oslo. Austin from Austin, he did some research on local models and basically how
fast they're catching up to the frontier models. And basically what he found is like they're
getting smaller and cheaper and more competitive faster than anyone basically thinks. Exactly.
That's what has me buying hardware, basically. I'm very close to pulling the trigger. But
yeah, no, very exciting times. So yeah, thanks for indulging me.
What felt like a three hour walk. It's been such a long day.
I'm so tired. I feel sorry for anyone who had to listen.
Any last words or we're just gonna end it here? You're excited for Friday? You know what you're
going to show off? Yeah, I got some ideas. You got some ideas. Yeah, we'll see. We'll see. Me
not. I'll go sleep. I hope that my subconscious will do the work and something pops up.
All right. Fantastic.