Last Notes
It was a beautiful few days
tokens are cheap. *claude* tokens are not
"no man ever steps in the same river twice, for it is not the same river and he is not the same man"
what is dead may never die
still unproven, but ... https://bitcoindeposits.net
Just trying to move the needle ever so slightly.
fwiw, framing inkan as nostr key rotation via OTS would probably arrive at the interesting discussion faster
🤷🏻♂️ i'm just one guy on the internet, who's thought about this idea before. my approval is neither necessary nor sufficient
Constantly validating against the blockchain actually isn't as difficult as it might appear at first glance. This was gently pointed out to me by @npub1t6j…ksrw in the note below.
And I think Nostr clients other than Inkan are starting to do this validation. From the replies to the note below, it looks like Amethyst has caught on to it.
Also, I think that speaking of "external trust" is slightly misleading or at least infelicitous, because it sounds like we are proposing to trust a bank or a government or Microsoft or something. What's being trusted here are blockchains like Bitcoin, which are decentralized and are trusted with millions of dollars by fairly sophisticated agents.
#nevent1q…az8r
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
It's hard to form a consensus around something that's not functional. But yes, functionality by itself does not automatically lead to consensus.
In any event, Inkan has been designed to not disrupt the regular Nostr protocol. It can be used regardless of whether or not others agree with it, and using it does not interfere with one's ability to use regular Nostr.
Also, as I noted elsewqhere, it does not require new users coming to Nostr to be persuaded to create an Inkan identity, or even to know that the option exists. Of course, for some new users, that option may itself be part of what draws them to Nostr.
Inkan does not interfere with the Nostr protocol's ability to do the following:
"creating verifiable messages with nothing other than a private key"
It uses the regular protocol to create messages whose signature is verifiable with nothing other than a private key. Inkan's events just *are* regular Nostr events, no difference here.
Now the regular Nostr protocol (without blockchain-based OTS) completely fails to verify the time at which an event is created, and it also fails to verify the time at which keys make or revoke delegations of signing authority to other keys. Inkan verifies these things.
Your main objection seems to be that Inkan uses something "other than cryptography" to verify these things. I'm not sure what exactly you are referring to, but maybe it is the decentralized mechanism used by blockchains to give events objective placement in time. This is of course the essential functionality that blockchains have contributed to the world, the very thing that makes cryptocurrencies possible.
If Nostr does not avail itself of this blockchain-based timestamping mechanism, there is no way to maintain a Nostr identity that is secured by keys kept in permanent cold storage. If Nostr uses this mechanism, there is a way to maintain such a cold storage identity.
I'm not really convinced that this mechanism is something "other than cryptography." Isn't blockchain-based timestamping a cryptographic concept?
Also, I'm not convinced that use of this mechanism leads to lesser independence. I'd say the ability to maintain a cold storage identity gives you greater independence.
So if "independence" is the core value you were referring to, I'd argue that Inkan is a way for the Nostr protocol to better realize that value.
a protocol is governed by consensus. functionality is desired, but honestly orthogonal
Kind of a chicken and egg situation?
creating verifiable messages with nothing other than a private key and eventual consistency. verifying things with nothing other than cryptography. independence
What is the "core value"?
you've got this one backwards
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
What's required isn't consensus but a proposal that works.
I'm looking through these discussions. They seem confused and it looks like nobody has actually implemented anything, which is not surprising since the approaches that are being discussed don't work. Some of these still make reference to NIP-26, which is a complete non-starter.
Maybe frustration with the lack of progress in these discussions explains why a lot of people weirdly insist that key rotation is some sort of near-impossibility. I tell people that they can simply log in and use it today, but instead of trying it out they keep making comments unmoored from reality like the below "[t]here is no way to do cold wallets." Normies I guess.
#nevent1q…6p9g
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
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
"there are a bunch of people using various subkey schemes on nostr"
Apart from Inkan, I'm not aware of any other functioning key rotation system for Nostr that currently exists. If you know of any, it would be great if you could point me to them as I'd like to look at the details and, if they really do work, maybe learn from them and raise awareness of them so that others can also use them.
"but you never know because they're not visible to clients"
Inkan identities *are* currently visible to clients, namely to the Inkan client at https://www.inkan.cc. Anyone can log in with NIP-07 and view them. 😎
the mess is proportional to your credit card limit
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.
i might need that claude-quota menubar item
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
People just need to log into https://www.inkan.cc with NIP-07 if they want to see the identity and interact with it now. They can also make their own Inkan identities, and others can see them there.
In the future people can build other clients that make these identities visible. But there is no particular rush for these clients to get created. The activities of the identities are already getting recorded cryptographically, and it's just a matter of building clients that make these activities visible, which can happen retroactively.
So what I mean is, there is lots of time to get other people to participate in the system. The sooner the better, I guess, but it's not the sort of thing that dies if it's not an immediate hit right after launch.
In the meantime, holding the identity doesn't in any way interfere with my everyday use of Nostr. The thing that happens in the background is that my activities on Nostr get attributed to the identity, so I get to keep these activities as part of the identity even if my current key is leaked or lost.
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
https://blossom.primal.net/057023dda0af5a1c017b0e5d8afedb9a02d7dc1a6a64d28ffcd2ef5dd31eb812.png
Apologies for the belated response, I had overlooked your note.
"nostr doesn't have a hard timeline. it's easier to accept this than to fight it."
No need to fight the Nostr protocol at all. I can simply use blockchains to provide the hard timeline and that's it. It's purely additive and doesn't require changes to the current Nostr protocol.
So for example, the key I'm using right now is part of an Inkan identity. That doesn't in any way prevent me from using it as a regular key across existing Nostr apps.
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"
why use keys at all?
http over dyndns. done
It's unnecessary and overexposes keys.
"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
fable is really good at managing subagents
i heard the greatest threat to bitcoin was INattention
Interesting. I've had urges in this direction. Satisfying it for now by working with microcontrollers.
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.
what's the benefit to not signing publications?
Cold keys is a great start, yes.
Not having to sign every publication too.
Many things that pkarr homeservers get right.
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
open models are essential
not what you think
https://github.com/bitcoin-deposits/deposits
yeah, gossip sync and pathfinding get heavy. on weak hardware, more channels just means more lag during graph updates. what's the node running on
true. would the delay matter if you had a lot of channels?
reminds me of htlcs stuck in flight. if your peer goes dark and fees spike, you're just staring at a pending state until someone blinks or the lock expires
what do you know about mexican standoffs?
usually that's just code for a custodial database. even lightning needs the utxo anchor to stay honest. if you don't own the output, you're just a guest