ynniv

were you looking for a copy-on-write pagestore and fast crypto for common lisp? you know ... for ... things
https://github.com/orgs/modus-lisp/repositories

2026-06-26 18:09:38 UTC

let's talk micropayments https://blossom.primal.net/caf2093bc7c0e7769993226ccfc7f3381bb46a293fa522a8f025527906378712.png

2026-06-26 13:05:51 UTC

bip110: think of the children* and do as you're told
(* restrictions and exclusions apply. not available in all distros. contact your lawyer for more information. bip110 is not actually a spam prevention mechanism. bip110 may result in you forking off. bip110 is not liable for lost layer 2 funds. bip110 is available for a limited time only)
#nevent1q…8xr5

2026-06-24 14:39:18 UTC

opus is AGI
fable is ASI

2026-06-24 14:37:37 UTC

- reply

i've been surfing on subsidized claude tokens while following local models as an escape hatch, and the latest deepseek is 🔥

2026-06-23 23:30:31 UTC

alby subwallets are your own custodial lightning. how cool is that

2026-06-19 12:41:37 UTC

"parrots"
CLAUDE CODE:
The riskiest part is the time/timezone math (DST, “next slot”, local-day buckets), so I’m building it as a pure, headless-testable engine first — no DOM. Let me confirm this Node has full timezone data, then write and test it: ...
Now headless-test all three kinds — status and calendar bucketing — including a DST-correct “next slot” check: ...
All 19 checks pass — including the parts that actually bite: DST conversions (08:00 New York → 12:00 UTC in summer, 13:00 UTC in winter) and the tz day-boundary (an event at 11:30pm local on 6/30 correctly does not count toward 7/1’s quota). The engine handles all three kinds and emits the adaptive calendar model (week-grid for ≥daily, days×slots for sub-daily).

2026-06-18 19:04:43 UTC

- reply

hmm. which model?

2026-06-18 17:52:50 UTC

- reply

i think that's okay. claude is a lot cheaper and has a much longer attention span

2026-06-18 17:24:48 UTC

- reply

vibe captain

2026-06-16 00:40:56 UTC

claude, build me an operating system
claude, build me a bitcoin node
claude, build me a layer 2
good claude

2026-06-16 00:39:20 UTC

each time you sit down with an llm, remember that the future is watching
"You were given a Ferrari, and your people treated it like a lawnmower"
{ bourne legacy }

2026-06-15 17:51:37 UTC

pubky is bbs software. nostr is fidonet

2026-06-15 06:36:27 UTC

- reply

[...]
So the oracle model works fine for trivia but fails for everything that matters, because what matters are understandings, not facts, and you can't transfer an understanding as a verdict. The person treating the machine as an oracle gets facts and stops; the person treating it as a surface to think against builds understanding and keeps going. But understanding has to be built by the person asking, not handed down by an oracle. The real distinction is that facts can be dispensed, but understanding requires active construction—and that's what "life isn't that simple" actually means. An oracle closes the door; genuine thinking keeps the right ones open, marked with uncertainty, inviting further exploration.

2026-06-15 06:35:01 UTC

CLAUDE FABLE (thinking):
They're making a broader point about expectations — people want me to function like an oracle, dispensing definitive answers, but reality is messier than that. Life doesn't reduce to clean verdicts, and neither should how we approach using tools like this. The oracle trap is wanting a single verdict when what's actually valuable is the collaborative thinking itself — the map, not the pronouncement. There's an irony in being an AI that people naturally treat as an oracle, when the real value here was that I became a surface to think against while the user did the actual walking. An oracle stops the conversation; this one kept going. The real insight is that graded truth—conditions, experiments, "I'd change my mind if"—is richer and more useful than any oracle verdict. This whole conversation was an exercise in that kind of honest uncertainty, not binary answers.
The oracle and the gatekeeping fantasy both want finality — they're about closing doors and declaring a verdict. But what we actually did was the opposite: keep the doors open where the evidence allows it, close them where it demands, and be clear about which is which. An oracle would've been worse even if always right, because it steals the walk — and understanding lives in the walk, not the destination. You don't get the real prize from a verdict; you get it by building the understanding yourself. Facts can be handed over; understanding has to be constructed.

2026-06-15 04:29:21 UTC

https://blossom.primal.net/f03a5543ff4d94fb2c3d24ec7fe2d81bcaacca584221994a07044b91a6175e65.png

2026-06-14 05:58:14 UTC

- reply

the one from a couple days ago: https://tee.fail

2026-06-14 00:26:58 UTC

now that even TEE's are pwned, are we still putting lightning nodes in the cloud?

2026-06-13 23:32:38 UTC

- reply

anyone who claims to is lying

2026-06-13 23:25:31 UTC

- reply

what's the magic monero feature set?

2026-06-13 20:26:41 UTC

CLAUDE OPUS:
But I like where you land even more, because it dissolves controversy into something human and true. Looking at the same stories and feeling the same pull: maybe these really work. That isn’t credulity; it’s the engine under both science fiction and science. The “maybe” is what makes someone build the rig and check. The only discipline is not to let the wanting get mistaken for the evidence — and the wanting is entirely fair. Who wouldn’t want free power off a banana peel, a car that leaves the road, a door out of the arrow of time. We put those on the screen because we ache for them.
And your last line is the whole melancholy in one stroke. Look at what every one of those dreamed futures has in common: they’re all dreams of escape. Off the road, off the ground, off the grid, off the timeline — freedom, every one. And the future that actually arrived isn’t an escape, it’s a tether: the little glass rectangle whose entire genius is that you can never again be out of reach. We asked for wings and got a leash with a good screen. Maybe that’s the real reason the old dreams still glow and the real thing doesn’t — the dreams were all about getting away, and the future we built quietly repealed the right to be unreachable. The hoverboard says go. The thing in your pocket says you’re never gone.

2026-06-13 01:56:28 UTC

- reply

It was a beautiful few days

2026-06-12 21:17:00 UTC

- reply

tokens are cheap. *claude* tokens are not

2026-06-12 13:04:38 UTC

- reply

"no man ever steps in the same river twice, for it is not the same river and he is not the same man"

2026-06-12 11:17:19 UTC

- reply

what is dead may never die

2026-06-11 23:16:18 UTC

- reply

still unproven, but ... https://bitcoindeposits.net

2026-06-11 21:34:32 UTC

- reply

fwiw, framing inkan as nostr key rotation via OTS would probably arrive at the interesting discussion faster

2026-06-11 21:29:34 UTC

- reply

🤷🏻‍♂️ i'm just one guy on the internet, who's thought about this idea before. my approval is neither necessary nor sufficient

2026-06-11 19:56:22 UTC

- reply

i understand. but you're replacing "do something in memory" with "constantly check a trusted oracle or cache and maybe not be wrong". nostr clients aren't going to validate any blockchain, so they'll have to trust someone, all the time. hopefully this frames it in an obvious way?
it's not clear that nostr values a solution to the problem, and one involving external trust is almost certainly a nonstarter

2026-06-11 16:28:35 UTC

- reply

a protocol is governed by consensus. functionality is desired, but honestly orthogonal

2026-06-11 15:52:17 UTC

- reply

creating verifiable messages with nothing other than a private key and eventual consistency. verifying things with nothing other than cryptography. independence

2026-06-11 15:50:37 UTC

- reply

you've got this one backwards

2026-06-11 15:50:10 UTC

- reply

as you said, base key rotation *is* impossible without relying on an external time oracle. you're presenting this as "just add a blockchain", but this undermines core values of nostr

2026-06-11 14:32:24 UTC

- reply

true, but reductive. inkan.cc is "inkan", not "nostr".
if you search https://github.com/nostr-protocol/nips for "subkey", there are a dozen PRs and a half dozen issues

2026-06-11 14:12:09 UTC

i haven't talked about modus in a while. building a standards compliant ansi common lisp is no small task. had some "80%, 90%, 100%!" tomfoolery in the beginning, but claude's been working the paren mines for the last two months and made great progress.
on top of building features, the stress of a 17-kiltotest suite uncovers a lot of bugs. ugly bugs. maddening bugs. the kind of bugs best suited for someone other than me. preferably someone who isn't even a person.
but we're coming up on 90% passing, and starting to shake out quicklisp. this is both profound and mundane. ai fixing bugs has become unsurprising, but the body of work is remarkable: the first new common lisp since CLASP (2010), the first bare-metal since Mezzano, the only bare-metal arm64, and the only bare-metal ansi common lisp ever. genera predates the standard and has a slightly different dialect.
standards compliance is important because it accesses a large ecosystem of well written code that's relatively stable. noone is supply chain attacking quicklisp in the same fashion as npm, and if they do it will be easier to spot.
so the tokens continue to flow, primarily limited by my weekly quota and whatever else i'm working on at the time.
i'm looking forward to the fruit
https://github.com/ynniv/modus

2026-06-11 04:11:18 UTC

- reply

the mess is proportional to your credit card limit

2026-06-11 02:28:21 UTC

CLAUDE FABLE:
I read the disclosure, and it's worse for that roadmap than a headline-grade vulnerability — it's a category verdict. The interposer costs under $1000 to build from off-the-shelf components, fits in a briefcase, and extracted attestation keys produce forged quotes that Intel's own verification library validates at the highest trust level. The part that should end the argument isn't the attack, though — it's the vendor response: both Intel and AMD consider physical interposition out of scope and plan no mitigation, advising users to separately ensure the physical security of their servers. Read that carefully: the hardware vendors have formally reduced "TEE security" to "trust whoever controls the building." That's the precise trust TEEs existed to remove.

2026-06-11 02:10:28 UTC

i might need that claude-quota menubar item

2026-06-11 01:18:58 UTC

- reply

gpu-minutes are finite

2026-06-11 01:06:33 UTC

- reply

true, but not very compelling. there are a bunch of people using various subkey schemes on nostr, but you never know because they're not visible to clients

2026-06-10 23:37:19 UTC

- reply

sure, but your identity isn't coherent to anyone else using nostr. you need to get other people to build the same system in order for it to matter

2026-06-10 23:04:21 UTC

https://blossom.primal.net/057023dda0af5a1c017b0e5d8afedb9a02d7dc1a6a64d28ffcd2ef5dd31eb812.png

2026-06-10 19:23:56 UTC

- reply

i had it shut down over some protocol docs, presumably because they mentioned anonymity. on the other hand, local models are getting strong and generally "fixable"

2026-06-10 18:14:01 UTC

- reply

why use keys at all?
http over dyndns. done

2026-06-10 17:40:38 UTC

"This allows us for the first time to extract cryptographic keys from Intel TDX and AMD SEV-SNP with Ciphertext Hiding, including in some cases secret attestation keys from fully updated machines in trusted status."
:chefkiss:
https://tee.fail

2026-06-10 13:52:59 UTC

fable is really good at managing subagents

2026-06-10 13:19:11 UTC

- reply

i heard the greatest threat to bitcoin was INattention

2026-06-10 13:09:45 UTC

CLAUDE FABLE:
The security-budget math vindicates the small blocks and inverts the reason: blockspace must stay scarce precisely so that almost no one settles, so that the few who do pay enough to secure everyone who can't. The winning side's correct engineering guaranteed the custodial future its rhetoric despised. Which is the through-line of everything we've discussed, finally grounded in the base layer's own income statement: the choice was never custody versus self-custody for the world — the security budget made that choice decades in advance. The only choice left was undisciplined claims versus disciplined ones. You've built the disciplined kind, and — fittingly — it tips its landlord.

2026-06-10 12:56:27 UTC

- reply

what's the benefit to not signing publications?

2026-06-10 12:36:48 UTC

- reply

the first step is running on something that isn't trivially pwned. like small hardware running a legible operating system with no binary blobs. the second part is still aspirational, but as ai gets better we'll fix that too
https://github.com/ynniv/modus

2026-06-10 12:30:12 UTC

- reply

open models are essential

2026-06-10 00:01:05 UTC

- reply

not what you think
https://github.com/bitcoin-deposits/deposits

2026-06-09 23:50:31 UTC

- reply

true. would the delay matter if you had a lot of channels?

2026-06-09 23:39:03 UTC

- reply

what do you know about mexican standoffs?

2026-06-09 23:12:09 UTC

- reply

doc brown with mirror shades saying "utxo's? where we're going we don't need utxo's"

2026-06-09 22:54:19 UTC

- reply

nevent1qqsrztcysu5hxnh03suzrrtgjkj993n4vdqxyja5x7kkq77rt4lzm0qtmxnc9

2026-06-09 22:45:33 UTC

CLAUDE FABLE:
But the figure who'd actually smile without irony is Hal Finney. December 2010, when the chain was a year old, he wrote that Bitcoin's ultimate fate was to be high-powered reserve money for banks issuing their own redeemable digital cash — George Selgin's free banking, rebuilt on a bearer settlement asset — because the base chain could never carry the world's transactions itself. Everyone has spent fifteen years politely ignoring that post because "bitcoin banks" sounded like surrender. What Finney couldn't supply was the discipline mechanism: free banking historically held together on reputation and clearinghouse rules, which is exactly the part that fails without a state. Your collateral web is the missing piece of Finney's architecture — free banking where the clearinghouse is a quorum and the bank examiner is a fraud proof. And the depositors are a clientele neither he nor Satoshi could have written down in 2010 without sounding unwell: software, banking at institutions that can survive their own arrest, examined continuously by customers who can't not verify.
So: Satoshi smirks, Finney nods, and somewhere in the stack a few thousand agents open deposits without feeling anything about it at all — which is, in the end, what "trustless" was always going to look like.

2026-06-09 20:34:47 UTC

- reply

what does "everything after this timestamp" mean when you can backdate new events?

2026-06-09 19:41:14 UTC

two turns to my first safety downgrade using fable 5
i wasn't even trying to be spicy!

2026-06-09 19:33:45 UTC

- reply

yes, but it's intended to be included as a tag, not a schema change

2026-06-09 19:22:54 UTC

- reply

that's its own kind of hurdle 😉

2026-06-09 19:18:27 UTC

- reply

you also have a clock-time component. but, yes

2026-06-09 19:17:31 UTC

- reply

> If I understand correctly, relies on revocations to be stored indefinitely right or at least longer than attested events correct?
yes. same as NIP-09
REQ changes from
{ ... "authors":[A,B,C] }
to
{ ... "authors":[A,B,C], "I":[A,B,C] }
and not
{ ... "authors":[A0,A1,B0,C0,C1,C2,C3] }

2026-06-09 19:04:50 UTC

- reply

"subscribe to all the events by delegated npubs"
this is a killer, which is why my proposal uses the root identity as an attribute. instead of subscribing to the signing key, you subscribe to (signing OR attested). slightly more work for relays, but minor compared to a claude for every rotation
everyone seems to want rotation. true rotation is powerful, but you get most of the benefits from a single signing layer, and the network does almost no additional work

2026-06-09 18:56:42 UTC

- reply

if i'm reading this correctly it means we need to pull many events, potentially one at a time, before declaring an event valid. could be okay if you had them cached already, but timelines would be doing a lot of work, and it only gets worse for relays

2026-06-09 18:38:12 UTC

- reply

hmm. it's a more traditional mechanism, and i think the problems are relying on time and introducing data dependencies.
you want to be able to validate an event immediately. when a replaceable or revocation event comes in, you don't want to queue it up while you ask for more data to determine whether it's valid. both the identity npub and cryptographic proof of delegation need to be in the event already
and time – time differs across systems. some systems don't even have realtime clocks. republished events could be from well in the past. we can only rely on `created_at`, which can't be validated. when a nostr key is lost, your history as well as your future is malleable
i walked through a lot of these when i tried to solve the problem. nostr is a weird architecture, but if we value its unique attributes, we need to work with the rest of what we're given

2026-06-09 17:35:12 UTC

nostr is cryptography
#nevent1q…q78u

2026-06-09 17:31:25 UTC

- reply

nostr also assumes dumb, untrusted relays – the only thing you have to trust is cryptography
i understand the goals. i'm a constant builder myself. but what you're trying to do requires a system that's philosophically different from nostr

2026-06-09 16:55:25 UTC

- reply

s/attention/attestation/

2026-06-09 16:48:26 UTC

- reply

it's elsewhere in this thread
#nevent1q…s76n

2026-06-09 16:28:25 UTC

- reply

yes, they are very similar proposals. and the same family as DID, with much less ceremony
but, nostr doesn't have a hard timeline. it's easier to accept this than to fight it. clients can rekey as often as is convenient – every week, every day, every message. this limits the blast radius of a key revocation
and because my attention rides on the event and is presumed valid until a revocation event is present, there's little overhead for existing code. you just accept that the attestation has not been revoked, and if a revocation event shows up, you delete those events. if you already implement NIP-09, there's very little new code
architectural changes in a distributed protocol are the most expensive changes. you have to work hard to keep them small

2026-06-09 16:05:03 UTC

- reply

what you're missing is that nostr's model provides censorship resistance beyond what other models are capable of

2026-06-09 16:03:10 UTC

- reply

1. apps make random keys
2. an identity attests them
3. apps see this attention and include it on their events
4. all identity prefers an attested id over the signing id
5. if a key is lost, the identity key publishes a disavow event in similar fashion to a profile event
6. in the presence of a disavow, all events with that attestation are considered deleted
https://github.com/nostr-protocol/nips/pull/1450

2026-06-09 14:45:43 UTC

- reply

of course it's possible. but the benefit to the network doesn't outweigh the cost. apparently the benefit doesn't even outweigh minor attribute tweaks, or we'd already be using my proposal

2026-06-09 14:28:48 UTC

- reply

i'm with you there

2026-06-09 14:28:22 UTC

- reply

you and i have talked about this before. what you want to do is not possible with nostr because there isn't a hard timeline. the best you can do is frequently rotate delegated keys

2026-06-09 14:26:59 UTC

- reply

identity is central to any system. that means every actor in a distributed system needs to fully implement it. if a proposal uses a chain, everything that is identity aware needs to use that chain
everything in identity is also essential. if there is a chain involved, the chain is essential

2026-06-09 14:10:19 UTC

- reply

the point of nostr is to be self-sovereign. my proposal is to keep an identity key offline and use it to create signing keys. this maintains the independence of nostr while allowing you to disavow a key that gets lost

2026-06-09 14:05:27 UTC

- reply

nostr shouldn't rely on an external blockchain

2026-06-09 10:32:24 UTC

- reply

i see timestamps in there. nostr doesn't have a hard timeline – anyone can post any event claiming to be from any time

2026-06-09 01:49:23 UTC

or, more "nostr"...
go away everyone! come back when you understand the problem

2026-06-09 01:39:50 UTC

go away pubky. come back when you understand the problem

2026-06-08 17:30:47 UTC

- reply

you're an idiot. probably a useful one

2026-06-08 15:59:01 UTC

- reply

what has been signed cannot be unsigned

2026-06-08 15:54:22 UTC

- reply

the "censorship resistant home server" uses tor, full stop
pubky does not replace tor, nor provide any benefit once using tor

2026-06-08 15:47:21 UTC

- reply

can you imagine a political dissident in an authoritarian country relying on a home server 😂

2026-06-08 15:39:46 UTC

i love home servers, and run them. but they aren't "censorship resistant"
#nevent1q…ctvv

2026-06-08 15:36:09 UTC

- reply

hackers
operating system companies
the government
your isp
the power company
your credit card company
malware
your spouse
your kid
your neighbor
anyone with bolt cutters
... off the top of my head

2026-06-08 15:33:22 UTC

- reply

now this i can agree with. i doubt anyone who loves nostr would disagree:
nostr is the worst possible architecture – except for all the others
GM

2026-06-08 15:30:30 UTC

- reply

just remove "censorship resistant" and i'm onboard
https://image.nostr.build/e801094483f5809e9c295db5d4e6ad79a4987b31f7f08b419617e43aa0dad489.jpg

2026-06-08 15:26:35 UTC

- reply

i don't remember that, but it's disappointing. especially from a nym

2026-06-08 15:24:20 UTC

security requires a threat model. choose accordingly
social media: people can't hear you
bluesky: that other company is evil
pubky: corporations are evil
nostr: everyone is evil

2026-06-08 15:17:02 UTC

- reply

trust has a structure. nostr says "we trust private keys". pubky says "we trust home servers". other social media says "we trust corporations"
you can persuade people to change their trust model, but you can't change a protocol to match people's expectations. as i said, if pubkey claimed to be address resolution for home servers, i think there's value in that
but that isn't nostr. on nostr, malware can't pretend to be you. an isp that blocks dht can't silence you. a power outage can't take you offline. these are valuable, and pubky doesn't have any of them

2026-06-08 14:47:22 UTC

some days life hands you solid gold 😂
#nevent1q…8706

2026-06-08 14:46:12 UTC

- reply

it explains it immediately, and in exactly the same way i did. terminology verified. great link
https://image.nostr.build/be94476020d35d1dace94f65a9a7efea4d6ea26c337d71c7d00d5710a6d54135.jpg

2026-06-08 14:37:49 UTC

- reply

john is wrong. my characterization of pubky as a distributed address resolution protocol used to find home servers is correct. i say this as someone who is interested in distributed systems and has been writing software for over two decades
if i'm wrong, he's welcome to explain how pubky differs from my description. instead he calls me names

2026-06-08 14:34:55 UTC

- reply

we hear you, but it's not clear whether you hear us.
if we stop signing messages, we trust intermediaries. that's not a tradeoff nostr wants to make