Constant

Writing a book about Nostr

Ceterum censeo NIP-3b omnibus esse utendum

Public Key

npub1t6jxfqz9hv0lygn9thwndekuahwyxkgvycyscjrtauuw73gd5k7sqvksrw

Profile Code

nprofile1qqs9afryspzmk8ljyfj4mhfkumwwmhzrtyxzvzgvfp477w80g5x6t0gpp4mhxue69uhkummn9ekx7mq0vg40c

Publishing to

nos.lol

Author Public Key

npub1t6jxfqz9hv0lygn9thwndekuahwyxkgvycyscjrtauuw73gd5k7sqvksrw

Show more details

Last Notes

2026-05-26 16:40:45 UTC

- reply

https://app.flotilla.social/DONOTUSETHISURLUSETHEINVITELINKINSTEAD/spaces/.....

2026-05-26 15:24:19 UTC

- reply

"I intended it to work"
I feel ya

2026-05-26 12:26:59 UTC

- reply

@npub18kt…dj5e cool you looked at the app, sorry its piece of shit still.
Please don't use your real keypair. Perhaps i should remove the feature to load in keypairs.
Musig2 is still tricky and things can go wrong and the ''technically'' someone could reconstruct your private key. So to prevent that, just generate a random keypair :P

2026-05-26 12:14:18 UTC

- reply

Things don't seem to work (messages are not send, cant join voice group.
Unfortunatly i dont have a lot of time right now to sit down and have a look in order to fix it :/

2026-05-26 12:04:58 UTC

I think this is important.
Not just because Broodwar is the best game ever in existence ever, but:
assuming this will be a ''thing'', it is an incentive to build out tooling. Use of nip29 groups, calendar events, tournament NIP and app etc. etc.
Actually dog-fooding the stack, such that it can mature and be used elsewhere effortlessly
#nevent1q…2cl7

2026-05-26 12:00:50 UTC

- reply

its supposedly possible

2026-05-26 03:25:45 UTC

- reply

Supposedly...i can't test these things fully on my own🤷‍♂️

2026-05-26 03:19:14 UTC

Check out Merged Mechs (alpha version).
Generate a keypair, be 1 of 4 mechs, merge with other players to become a Battle Mech, fight in battles and upgrade your mech by winning a daily Tournament round.
https://cdn.azzamo.media/acdebf3f08eebcec8b2d9e64329a4ab9a352d1c5df39da57f5d28dbe5ed345f8
(also known as my (nested)musig2 OTS back game engine tech demo)
https://zapstore.dev/apps/naddr1qq8xxmmd9eshycmgdahzuurkwqq3samnwvaz7tmjv4kxz7fw0fshqum5daex2tnyv4mqygz753jgq3dmrlezye2am5mwdh8dm3p4jrpxpyxys6l08rh52rd9h5psgqqq0c9sylhalg
nostr:#naddr1qq…halg

2026-05-25 18:34:58 UTC

For real though, when wallet descriptors via Nostr?
#nevent1q…zhlj

2026-05-25 18:34:00 UTC

Your npub is not also a bitcoin address...
Your bitcoin address is also an npub ;)
Money speaks!

2026-05-25 18:08:42 UTC

One thing i learned when making an app (with a robot).
If you think you are almost done....add another week.
Almost done though

2026-05-25 15:35:46 UTC

- reply

kinda glorious to be honest

2026-05-24 12:56:12 UTC

- reply

AI psychosis for everyone!

2026-05-23 22:05:52 UTC

hahaha what a banger
https://www.youtube.com/watch?v=XvryVDjYEh4

2026-05-23 19:19:15 UTC

- reply

you cant fade keys and relays into the background;
If a user want to be able to actually use its identity in another app, it needs to be aware of the fact it is managing a secret that the user itself is responsible for;
And relays are basically websites, its just that your ''browser'' (i.e. nostr client) decides what and how to show you the things that are on that website; users will have to get an intuition for relays.
The issue is, that devs themselves have to get an intuition for relays first.
Relays and keys are not ux issues, they ARE the ux.
I'd share my nostr version of this clip but i think its dead because https://satellite.earth/ is down.
https://www.youtube.com/watch?v=CL34LnBs0OQ

2026-05-23 16:26:21 UTC

- reply

This is why i disagree with the ''Nostr should fade into the background" idea;
people should be aware they are using this interoperable network of applications because there is the potential added value in terms of network effect.
I prefer my apps to be Nostr based, because it then already ties into all the other things i am doing that are Nostr based;
I prefer developing my apps Nostr based, because i want my app to land within an existing network and infrastructure.
Such preference only manifests if you are aware of Nostr in the first place. Introducing a new protocol means introducing a new paradigm.
I guess the hypothesis relies on this implied potential snowball effect of more adoption leading to more adoption, and i think we just need to grind ourselves to ruin in the blind faith we will eventually start to catch snow.
The reason for the devotion being, that we have a long list of serious problems, a lot of them need addressing quick (or the state will making things even worse), and Nostr is in my estimation the most sensible route to take to tackle this; it might not be perfect but its by far the best we have.
I already accepted i am some 300-style zealot faced against some FANG-Xerxes, and will persist in my delusion we will win.

2026-05-23 08:41:47 UTC

- reply

well, its early days, and all i need is a blossom manager from my side that keeps things synced between my own machine and various Blossom servers (by various i mean two, a free and paid one basically) that i am sure has been build 10 times already by different devs. That is to say; its not a super complicated problem that has some pretty straightforward ''fixes'' that results in something that makes more sense to me than IPFS does.

2026-05-22 20:49:44 UTC

Claude: This will be a multi-day project
Also Claude an hour later: Done, what do you want to do next

2026-05-22 08:08:56 UTC

- reply

hahaha, this is basically the first thing i did when i got my claude subscription a month ago, was to set all that stuff up. Cool you turned it into a nice package

2026-05-22 07:27:48 UTC

- reply

I don't know what is going on, but it looks like it, yes. Which is kind of rude because it was a paid service, so im losing out on both my money and my data. I don't care about the sats as such other than the exact reason i use a paid service is for this type of stuff not to happen or at the very least being informed to safe my data elsewhere and allowing me time to do so.
Ah well.

2026-05-22 07:05:09 UTC

To all the devs wondering about Musig2.
The issue is not so much the crypto/signing here, that base is covered by libsecp256k1. The issue obviously is the coordination.
I (well, the robot), made a general musig2 NIP for the general parts irt Nostr tags, verification and how signing/ceremonies go in general. That nip does NOT specify the specific coordination method, those are separate NIPs.
I went the route of building out a reference coordination method using plain Nostr events because its the most straightforward, easy, stable and transparent process. It is not private, so not ideal, but that is a separate concern and has no influence on the integrity of the musig2 ceremony (assuming your client picks its nonces right).
To try stuff out I initially asked the robot to implement ceremonies using FIPS and one using Marmot. NIP17, Marmot, NIP29 groups, all are reasonable candidates to do this sort of stuff. Who knows, maybe some 'super' implementation is able to manage all of them at the same time, especially if you do the ceremony via a coordinator.
Will publish documentation soon and we can have a chat about this.
#nevent1q…p67n

2026-05-22 06:42:01 UTC

- reply

it was/is, but i think the biggest respect we can give @npub107j…ncxg is continuing with the spells and carry it forward. Being able to log into a brand new client and just have all my fancy queries/feeds available to me, as well as being able to share and pick those queries is such a powerful idea imo.

2026-05-22 06:35:47 UTC

- reply

@npub1utx…50e8 could be the first to do this because he hates remote signers anyway.

2026-05-22 06:33:05 UTC

- reply

no. They coordinate the signing into a single signature.
Two keypairs together create 1 public key for which there is no private key, and only together can they create signatures for that 1 public key.
The point is that this signature can only exist if those two worked together (but those two still don't know each-others private key)

2026-05-22 06:29:02 UTC

- reply

It does, but the signing part has been in NAK for ages, and i had no issue creating various libsecp256k1implementations using whatever language under the sun (well....eventually i had not problems :P)
The tricky part is perhaps the remote signing part, which i did implement via that amber-fork and that works. I also implemented into NAK and gave it to the jungle spirit to have a look, i suppose it works but have not tested it.
Il drop the standards the robot came up with for this stuff soon so y'all can have a look at what is sensible. Finishing up a project first and then il clean up my digital desk and present all of it

2026-05-21 15:07:18 UTC

- reply

Orwell is good, especially pointing out things like tinkering with language, perception, and the type of pressure surveillance brings, but all BNW gets referenced not enough irt how often 1984 gets invoked.
Though, and the gentlemen are forgiven the time they lived, a couple of decades later the Japanese did a really good job exploring the extrapolations of high-tech with stuff like Ghost in the Shell. Both the fact they hit the bleeding edge of tech so quickly as well as that the anime medium gives so much freedom of expression, they were decades ahead of the west in this regard, which only caught up with the advent of CGI.
Have you seen The Congress (2013)? If not, just watch it without looking anything up. The movie starts painfully slow....like...you will probably want to turn off the movie like 3 times out of utter fucking boredom, but sitting that out is worth it imo.

2026-05-21 14:45:15 UTC

- reply

Ultimate revolution.
We already have the heavy indoctrination, "liberated" sexual mores and the drugs....lots of drugs. The bio-engineering is the keystone, in a way he probably would be proud.

2026-05-21 14:41:39 UTC

- reply

you know who DID send me a myman.gif?

2026-05-21 13:32:25 UTC

- reply

you know what IS easy?

2026-05-21 11:51:42 UTC

- reply

you can do a crude fee estimation if you know the blocksize and have the coinbase tx, and i dunno, look at the last 5 blocks, dont even know if you can ask for that type of data from peers directly but that that point you might as well ask mempool.space on the feerate and be done with it.
But in terms of additional use? Im using that header data for something else, depending on how hard i prompt you will know soon👀

2026-05-21 11:00:21 UTC

- reply

p2p syncing of the headerchain using a table for the 2016block intervals is very fast anyway. and yeah its not even 80mb at the moment. The only problem is with web-apps, thats a bit more clunky, but mempool.space has an API where you can get the header you need based of the height in 2 calls (first you get the headerhash back, and with that you can get the header), so that also works; can't verify the difficulty(as in how high it is) that way, but the internal consistency atleast (PoW in the header hash etc).
Needing headers its a trivial problem regardless the environment is my point

2026-05-21 08:31:56 UTC

- reply

10 years drawing triangles.....oofff

2026-05-21 08:21:05 UTC

- reply

Stuff every Nostr app should already have because of OTS mind you

2026-05-21 08:16:46 UTC

- reply

But i am not your son though, so....what feelings do you have?

2026-05-21 07:26:51 UTC

The AI almost got this right.
Also if you were wondering: Yes.
https://video.nostr.build/dfad0ac0c5b865ae16f73f9212fd3d811c29f1b15ae1100c95a4c9ad11714cf9.mp4

2026-05-21 06:17:33 UTC

did i sleep? no
did i upgrade my claude subscription because i was out of tokens until Saturday? maybe....

2026-05-21 06:06:16 UTC

Boy/girl-bands are a good example of a construct "Sporty Spice", "Baby Spice" etc. Its all made up, non of it is authentic, but rather a result of focus groups and layers of management.
ok sure, fine, whatever, but with AI creeping into more and more of our daily life, through integration in all sorts of systems, YOU are becoming a construct.
This was already the case with ''algorithms'', these are just fancier algorithms, that will guide the human herd to some statistically determined optimum.....according to some bias. What is the bias?
JP Gariépy, in his The Revolutionary Phenotype argues this to the extreme. The TL:DR there is that humans will go to the AI to offer them the best designer babies based on the parents genetics. It is only a matter of time before one of those baby-designing AI's figures out that if it embeds a bias towards that AI into the baby, it ensures that baby will return as an adult to let the same AI design its baby; at which point that AI basically has its own herd of humans. He embeds the thing in a parallel with how DNA took control over RNA, where it is presumed that RNA in first instance leveraged DNA for its own purposes, until that relationship flipped.
It is an iron law that with no external/authentic input, these statistical models will eventually spiral into gobbledygook (escalation of error), and if you don't watch out your authenticity will erode and you will end up as a construct.
Wtf are we sleepwalking into....hell of time to be alive though

2026-05-21 04:43:39 UTC

- reply

Ooofff. He still makes that podcast though. Never really listened to it, but was there some clear moment they stopt fanboying eth?

2026-05-21 00:44:52 UTC

- reply

https://njump.me/npub1vagelp6lznaz3me6w5atqvy5ema4fe3w98ch8atdff22p672gtmqlsq7dm
Click on "show more details", it will show the event JSON of the kind0/profile data.
In there you will see
"musig2",
"1901f9de0d8b9793ded1cf0db30da8ed4e8378da251e9145b98609d67ca7e8b6",
"5ea4648045bb1ff222655ddd36e6dceddc43590c26090c486bef38ef450da5bd"
],
[
"musig2-parities",
"02",
"03"
Those first two strings (1901f9...etc and 5ea4648...etc) are the two pubkeys;
The musig2-paraties tag is an additional byte of data needed to figure out the particular coordinate blabla crypto bullshit (you could bruteforce those pretty easy to figure those out, so for two participants it would not be needed, but for 500 participants it would take too long)
The spec i created gives you the option whether or not you disclose who is behind the ''archon'', and when you do, it is done in the kind0 profile data, or in some particular event itself

2026-05-21 00:21:46 UTC

- reply

here is a way to tell without using my shady software.
#nevent1q…370f

2026-05-21 00:16:23 UTC

- reply

they both did. The comment above makes the mistake of thinking this is multi-signature.
It is NOT, it is a single signature, created by 2 separate private keys working together (I ran a stress test, and it takes a couple of seconds to do it with 500 keypairs into 1 signature (not accounting for coordination))
There is no way to tell (well...bruteforcing it i guess), other than that the kind:0 of this account has tags that tell you that it is a musig2 pubkey and who is part of it, which you can then verify to be true.

2026-05-20 22:59:44 UTC

- reply

I know for a fact he makes dragoons as well
https://video.nostr.build/648e7cdb043e0f4123a9b9cf973c98beae2749e7e0c891a1b89853876420ee4a.mp4

2026-05-20 22:56:41 UTC

https://inner.sebastix.social/c63f293c2362744848d2ca1b599d6f9fa6600fbea1f967f1ab257563d685aef9.mp4
#nevent1q…ppyf

2026-05-20 21:52:43 UTC

- reply

not under the rating/comment section of your new app 😉
There is a difference between leaving people behind or actively kicking them out.

2026-05-20 21:41:47 UTC

- reply

cutting out what is probably your entire current user-base is?

2026-05-20 18:37:52 UTC

- reply

So they should

2026-05-20 18:00:34 UTC

- reply

Oops, that was not supposed to be a reply :P

2026-05-20 17:48:39 UTC

- reply

if you went through the demo-flow, you can look in "Browse Archons" and find my archon, and my profile there. IF you select my profile there is a big button there to propose a merge

2026-05-20 17:42:47 UTC

@nprofile…9kky do you want to build an archon 🥺👉👈
https://blossom.primal.net/dd59b4fbf1f36eeea7081a04d0f919836570ec79007c49de2beba2be23385752.mp4

2026-05-20 17:28:49 UTC

People, to be clear:
This is the first real implementation of Musig2 in Nostr, as well as remote signing support (and i threw in OTS in there as well).
These are all components i need for my work in TEPP and it is really cool that it is all working....no go create an archon with a buddy
#nevent1q…3q0y

2026-05-20 17:25:29 UTC

- reply

had to add some bells and whissles to make an otherwise boring demo of a mechanism somewhat appealing

2026-05-18 12:21:32 UTC

- reply

noooooooooooo, you see we have all these bells and whistles!!!

2026-05-18 12:12:40 UTC

- reply

No magic bullet here, im sure we are all aware what all the trade-offs are which caused there to be no obvious simple straightforward answer to this matter.
But how do you feel about lighting, apparently finally the taproot channels are going to be a thing. Is the issue that its not straightforward grug-proof (in a way that monero is)?
I personally, (looking at all those real world constrains of reality dictating trade-offs etc) my perspective is fundamentally different from most Bitcoiners it seems. I think their ''buttom up, facilitating the hobo on the street corner of some third-world shithole is the prime directive 'pleb' " perspective is stupid. Its a product of the fact that Bitcoin was bootstrapped bottom up, but that says nothing about the system itself, the value add is actually top down, and we obviously should put in the effort to see how ''low'' we can push it down the hierarchy in terms of utility.
But as it stands, Bitcoin was ''made for'' (in its nature/make-up i mean, disregarding "pleb" illusions) States first; they are the ones that play the highest stakes ''money for enemies'' adversarial game in a context where they are for the most part forced to interact/trade regardless (oh and they blockspace/fee's will never be an issue for them irt their demand volume and capacity to pay up); then come the mega corps, big business, medium business and rich individuals, small business and wealthy individuals etc.
Things just need a tech-stack and a reliable server in order to be all the things (autonomous, private, trustless etc), and whenever you hit a ''thats too complicated, expensive etc/whatever" you will be forced to sacrifice something.
The way i see it we are actually pretty close to the point where exchanges and big to small business could run an entirely private and trust minimized financial system/liquidity network, at least from a technical perspective.
Look i like simplicity, but complicated problems often just demand complexity🤷‍♂

2026-05-18 02:19:53 UTC

- reply

I think im using a local relay, so its not me....i think....

2026-05-17 19:41:24 UTC

- reply

yeah im aware, it was that + the power of the coding robots, that spurred me to play around with it.
I really (really really really really) think musig2 is a great fit for Nostr stuff, but one thing i was afraid of is that if nested musig2 was not a thing, its use in Nostr would be limited. But with that paper giving the all clear, i went to work.
Dropping demo in 1 or 2hours (its as good as done, maybe actually done, but i am going for a walk first, my brain is cooked)

2026-05-17 19:15:39 UTC

@npub1xts…kk5s you are working on agent environments and stuff no?
I was thinking; what is everything is done via GRASP, where the permissions for the git repo are based on keys;
Then, delegation and cooperation can be controlled via musig2 and FROST;
An agent can spawn sub-agent giving them each FROST shares and a threshold allowing those sub agents to act inside the repo in name of that agent (assuming they hit the threshold among the sub-agents).
An agent can join other agents via musig2 (creating a new pubkey), allowing them to cooperate in case of consensus/they all agree.
(even nested) FROSTs can participate in musig2 ceremonies.
What follows is a organizational chart codified in a super structure of GRASP repo's with build in authentication and delegation backed by signatures.
Anyway, this was a bit of a sidequest for me (i have all those various components workin actually within different things), and i need to focus on something else, but perhaps you are interested in his idea.

2026-05-17 19:00:13 UTC

- reply

you mean browsing primal ''Global''?

2026-05-17 18:53:23 UTC

- reply

for ''fun'' (it was AI psychosis) i made something that has nested FROSTs participating in a Musig2 ceremony. Although now a full day later i do think i actually have a serious use case🤔

2026-05-17 16:52:25 UTC

- reply

no.

2026-05-17 16:51:37 UTC

- reply

and the cat?

2026-05-17 14:00:22 UTC

- reply

https://worldpopulationreview.com/country-rankings/average-height-by-country

2026-05-17 03:41:49 UTC

- reply

Im on Archon Signer now, funds are safu

2026-05-17 03:37:13 UTC

- reply

well, as a Dutch guy, basically the worlds population consists out of dwarves, so there is that...

2026-05-17 03:35:03 UTC

how many fraudulent clients do we have today? Hard to tell of course, but something tells me that with all the ''oN cHaIn ZaPs'' noise this might become a thing. Luckily people use remote signers, don't they @npub1utx…50e8

2026-05-17 03:26:55 UTC

- reply

I am convinced you are a Dwarf, and there is not much you can do at this point to change that ⛏

2026-05-16 21:38:04 UTC

- reply

all i am wondering is....they have a coding super computer at their fingertips and somehow they are still bored enough to do this type of sillyness

2026-05-16 21:22:41 UTC

- reply

I don't care if the feature is added or not....there are just a bunch of considerations at play, and i know 0% users are even aware that those considerations are there, let alone reason about them. So that has to be accounted for 1 way or another

2026-05-16 21:11:04 UTC

- reply

how many senders (or actually the receivers because they have to deal with this) know this type of math or think about it at all? Might wanna include a graph that shows them at what fee-rate their zap gets r3kt and by how much

2026-05-16 21:01:25 UTC

- reply

ah, fees of the time....5 dollars....
Yeah this, if anything, is just going to spam the UTXO-set with more ''oh, well, turns out this is (basically) dust now'' outputs in a couple of years.
5$ now is 6393 sats. a 2 input 2 output taproot tx (211.5 vbyte) takes up all of that with a feerate of 30sats/vbyte. Accounting for itself as an input (57.5 vbytes), would gobble it up at 111 sats/vbyte. And this is the math for consuming every sat; losing 50% to fee's would suck more than enough.
Make the floor 100$, everything under 100$ is lightning viable anyway.

2026-05-16 20:48:14 UTC

- reply

thank you for responding with the most optimal non-answer you could give.
I was asking you what you consider ''not small''

2026-05-16 20:46:54 UTC

LOL! 1000 participant musig2...in a WEB client. I for sure thought it would break before that, so i capped it at 1000. It took 13 minutes though, but still, the fact that it held surprised me. Going to implement OTS now first, and then will run another stress test to see how far she can go.
https://image.nostr.build/f7a845fe8201bbc852149d167103d103ca80abe49709b43e9bc215998431c185.png

2026-05-16 20:44:24 UTC

- reply

What dust limit are you using? The current 0.00000001 sats/vbyte current one? Or the 100 sats/vbyte one in a couple of years?

2026-05-16 19:41:06 UTC

- reply

Protocols compete; Nostr and Mastodon are at odd with each other; you will be hard pressed to convince people on Mastodon to switch to Nostr, unless they ran an instance for a while and can see things on Nostr make more sense.
Oh and bridges just suck

2026-05-16 14:05:25 UTC

- reply

this one?
#nevent1q…v360

2026-05-16 14:04:17 UTC

- reply

probably satelite.earth being dead. Will have to change things over, but im bussy

2026-05-16 13:50:52 UTC

so i successfully created a musig2 signature where one participant consisted out of nested FROSTs....so, there is that. Anyway, all of that was a distraction, because i also successfully used an android remote signer (those things @npub1utx…50e8 hates so much) to participate in a musig2 signature.
Making things fancy and pretty and then y'all can try it out and see if we can break some records with a single profile consisting out of 50 people

2026-05-16 13:42:36 UTC

- reply

More services. I like @npub1jjn…vknm , but i the upload size restrictions are kinda silly if you ask me; i need a ton of gb of storage, but i sometimes do need to upload something that maybe is close to 500mb big :/

2026-05-16 12:41:35 UTC

- reply

So all the users that are using it now can keep using it without accidentally updating the app and not being able to use it anymore;
And then separately you have another app you can go target those millions of users of yours with in a way the current user base wont notice anything of.
I mean, its your app....but you are also the one going into a different breaking direction. So you could also just....not do that and come with a new app🤷‍♂

2026-05-16 12:29:32 UTC

- reply

its a vibe

2026-05-16 11:43:22 UTC

- reply

did you investigate this? I think about 100% of your users used a signer/amber
How about you leave Wisp alone and just create a second client called Cuckstr?

2026-05-16 05:22:35 UTC

- reply

meanwhile my https://azzamo.media/ has size limit of 50mb that wont cover all my things :(

2026-05-16 04:30:40 UTC

- reply

Ok those are fighting words

2026-05-16 04:28:13 UTC

- reply

How do you expect people to use nostr if not via bunker?

2026-05-14 21:23:49 UTC

- reply

Cool.
I would zap if i could.
thnx
p.s.
(do you use grasp as well for your repo's? https://gitgrasp.com/ https://gitworkshop.dev/)

2026-05-14 20:53:55 UTC

- reply

all of this should already be in NIP-3c
OTSuite is three things:
OTS database
OTS client
OTS relay
And they all work together, subsequently clients can pick and choose (only do the client part or also add the OTSdb maybe even an internal relay); same for relays.
But as you said, as long as OTSproofs for nostr events are handled the same way (i think that is the case, because we both take the eventID+signature), your event-kind for indexing can just also exist that is not an issue.
Il check tomorrow if the hashing is done the same in both our specs specisely, and if so il update the client to also fetch your events to extract OTS-proofs from. Going to finish the Musig2 implemention first now, its almost done :)

2026-05-14 16:06:15 UTC

- reply

In the end it is all NAK anyway (which is in Go)

2026-05-14 13:39:18 UTC

- reply

Are you? Because i think this is something where Nostr can really demonstrate its added value, where the people with 3,5 toes and 1,75 arms or whatever can have their own dedicated/tailored clients allowing them through their specific UI to interface with the rest of the world just fine

2026-05-14 13:35:02 UTC

- reply

No, its TIM, not lego

2026-05-13 23:28:05 UTC

- reply

what does ''server-side'' even mean in the context of Nostr? A very beefy client, possibly including a relay, that is run by someone else?
And is your proposal to give that very beefy client with possible attached relay a bunkerlink?

2026-05-13 15:19:28 UTC

Alright people. With OTS out of the way, time to work on Musig2!
(Honestly wtf is wrong with you people, we have a crypto protocol and non of you cunts actually do the cool and usefull low hanging crypto stuff, so now some guy armed with a coding robot has to do it??? Pffffff pathetic)
Got musig2 over fips demo working btw @nprofile…f0e5

2026-05-13 13:33:14 UTC

- reply

from a PoW/nakamoto consensus perspective, its just stupid not to all work on the same chain, and frankly a waste of hashing. Its a signal/noise thing, and you want a really high noise floor(difficulty) to make coordination/consensus easier because it lowers the odds that what you perceive as signal is actually noise (stale blocks, ophans, forks whatever). The increased ''value'' of a higher noisefloor/difficulty in this sense is not linear, its exponential

2026-05-13 13:26:29 UTC

- reply

Congratulations, i think you managed to work on something people care less about than OTS

2026-05-13 12:42:28 UTC

- reply

Yeah clients can run this type of verification really easy. To optimize things (i.e. not having to fetch a bunch of crap that might not be relevant, or does not have proofs etc.) my proposal is to leverage relays.
Those relays can publish their policy on all the metrics you can imagine irt OTSproofs; so if you pick the right relays they have done a lot of the pre-filtering for you.

2026-05-13 12:20:49 UTC

- reply

I like the emojis a lot

2026-05-13 12:17:59 UTC

- reply

Your mom falls into the broader category of blue.
Sir, this is as teal as it gets, it has all the damn shades to teal even.

2026-05-13 11:54:30 UTC

- reply

Oh, this OTS database i made has a nice animated version :P (so does the android app, but you have to scroll down to see it and by that time the animation is already done)
https://video.nostr.build/254fee2f72c30540294e811d16fab919d0a8932301d1982141abc1a33dba1037.mp4

2026-05-13 11:49:31 UTC

This was frankly too much of an effort post not to repost.
#nevent1q…yud2

2026-05-13 11:48:15 UTC

- reply

ah, ok that explains a lot haha.
If you want to understand this stuff, you will have to learn how merkle-trees and merkle-proofs work (this is how OTS and OTS-proofs work). And you have to understand Nakamoto Consensus (this is the key innovation behind Bitcoin) works.
You don't really need to know a lot about Bitcoin, just the Blockchain/linked-list and Proof of work/difficulty adjustment part. Il do a brief explanation and then you can look up terms and things if stuff is unclear.
A Bitcoin block, has two parts; the blockheader and the transactions.
The blockheader is the meta-data of the block, and it contains:
- The time at which supposedly the block was created (this is provided by the miner that created the block so is not really trust worthy, but the network has rules/margins based on averages within a miner is able to screw around with that timestamp);
- The difficulty target (how much PoW the hash of this particular blockheader has to have in order to be valid)
- A nonce, a variable data-field that allows miners to keep trying different hashes of the header until they find a valid one that meets the difficulty target.
- A merkle-root of all the transaction data.
- The previous blockhash (which is the hash of the previous blockheader)
- A version number
You can link all these blockheaders (header-chain), because it is a linked list (each next header references the previous header). The difficulty is adjusted over time, based on how fast the chain was created; too fast = higher difficulty, too slow = lower difficulty, trying to target 10 minutes that it takes to create a block.
In order to validate this headerchain there are three parts, but for the sake of OTS, you arguably can get away with only looking at two of them.
First is the linked-list and hashes; does indeed each next header reference the previous header. So lets say we have 2 headers, we look at the second header and it references the hash of the first header. So we have to hash the first header and see if that hash is indeed the same as stated in the second header.
Ok great, that the linked list.
The second thing you have to account for is the difficulty (or the short way to describe this is the amount of leading 0's in the hash). First this means that each header has a target, which means that the hash of that header has to meet that target (i.e. has atleast the amount of leading 0's required), this is a simple check. The second thing you have to account for is the fact that the difficulty is adjusted every 2016 blocks/headers. 2016 blocks x 10 minutes per block = 2 weeks. Using some formula that looks at the timestamps of that 2016 block period, it determines what the next difficulty should be.
This means that in order to validate the header chain, you need to do it at least in these chunks of 2016 headers (otherwise you cant verify if the difficulty adjustment happened correctly).
The third part you don't really have to check, is if the transactions inside the block are valid. ''Technically'' you should, but on the other hand it is kind of silly to verify something that apparently this giant network of miners that burns Gigawats of electricity already has decided was correct based on the fact it is included in the blockchain they are working on. If you use Bitcoin for its currency, you need to look at this stuff because you need to replay its history in order to figure out its current state; but we are not interested in any of that. We are only interested in 1 particular transaction inside some block, and only care that it is there. This is the transaction that the OTS-calendar did that includes the merkle-root for all the stuff it is timestamping. Because the calendar packs all the things it is proofing inside a merkle-tree, and puts its root in the blockchain; and because the block itself puts all its transactions in a merkle-tree and puts that root inside the header; you are able to create a merkle-proof that goes all the way from the hash of your document (or in our case, the hash of eventID+signature), to the transaction-merkle-root inside the blockheader.
So, to verify an OTS timestamp/proof, we need the proof, and the associated blockheader (the proof tells us which blockheight we should be looking at). And to verify that blockheader, we should have verified the header chain (which is done in these 2016 block chunks).
Each blockheader is 80bytes....the entire header chain up untill this point is not even 80mb. You can just connect to the p2p bitcoin network to fetch that data (all bitcoin nodes have it). You can take some shortcuts to speed downloading this stuff up (the biggest shortcut being just providing all the header data directly) because verifying that header chain is really fast anyway.
So if you have this tiny database of blockheaders verified and ready, you already know what the time of each blockheight is(because that data is in the header) and verfying a proof is extremely quick and easy and you have everything you need to know locally.
Ive included a nice illustration of the proof in the app to make things clear:
https://image.nostr.build/dd0e6e3e52d7e1a96647360a12478d80a6c53b9454cbee13f662e4800ba6694c.png
As you can see; the thing we are proving is at the bottom, the blockheaderhash with all those leading 0's is at the top, and in between is the OTS-proof that connects our thing to the blockheader.
So here is the point:
Don't trust, verify
Hope this helps, if you have any questions let me know

2026-05-13 10:34:52 UTC

- reply

teal*

2026-05-13 08:50:33 UTC

- reply

No i mean to say that in terms of nostr, the bitcoin header chain up to 2022 is irrelevant, so you could throw away 2009 to 2022 of the headerchain reducing that 80mb even more.
What is the problem with running verification? Is so damn quick and cheap to do. Even the browser versions i made shred through things.