Last Notes
Google Maps is the reason I got a smartphone 14 years ago. I saw it on a friend's phone and thought oh it would be useful to have that. As far as I know, it's the only distinctive product Google ever made.
I think I agree, it requires a modest amount of effort and a willingness to direct ones attention to it from time to time, as do many things in life. Like learning a bit of algebra or trigonometry, or maybe playing the piano or volleyball with some basic proficiency. Humans don't usually do these things of their own accord, so we create special educational environments with a carefree atmosphere that allows them to open their minds towards these things. There is no reason that basic asymmetric cryptography shouldn't be part of this.
Now all that said, I'm embarrassed to admit that I myself don't know a lot about entropy generation, don't know what a "descriptor for multisig" is, and don't know what "m/4/0/0/1" refers to. That's not to say that these are abtruse concepts, I guess just that I haven't encountered them or at least not in a way where I felt like I had to think about them.
With rootstock, I guess the main discomfort really does come from the fact that its funding isn't endogenous, its being pegged to Bitcoin. Looking into this a bit further, it seems like the pegnatories aren't anonymous happily, but it's still unclear why one would want to trust a handful of companies with peg-outs. This feature makes it seem rather fragile.
On the one hand there's zero demand, and on the other hand just a couple of hours ago I came across yet another post proclaiming that "[k]ey rotation is an existential problem that cries out for an answer."
#naddr1qv…w6eg
There's a fascinating mix of social dynamics permeating this discussion, here's a recent economic take on it:
#nevent1q…ya37
In this case I guess it's just a story that I read that was told by Plato about a conversation between Phaedrus and Socrates in which Socrates says that there was a myth told by the ancients according to which there was this conversation between two Egyptian gods in the city of Naucratis.
If RBTC traded at 50 cents while Bitcoin is at 80k, this would presumably mean that people think there's something seriously wrong with the bridge. The value of RBTC just seems to reflect people's view of the integrity of the pegging mechanism and the trustworthiness of the pegnatories. By contrast, the value of Bitcoin or Ethereum reflects people's view of the security, usefulness and future of the chain itself. It feels like, in the case of Bitcoin and Ethereum there's more overlap between those who are defending these chains and those who have their economic interests bound up in them, and there's less of a single point of failure, but I guess I'll need to look into this more. Also it's of course perfectly fair to predict that things will get better in the future with BitVM, but the prediction doesn't substitute for what it presently is.
I think I've never met a plumber. I wonder if they are nice people.
I've tried driving, skateboarding, riding a bicycle, using a checking account, pilates, long division, excel, bodybuilding, hula hoops, powerpoint, and a few others, can 't remember all of them right now. Not to speak of such feats as reading or learning Spanish.
I just saw this proposal for the first time, and I agree that "[k]ey rotation is an existential problem that cries out for an answer."
#naddr1qv…8zds
So actually key rotation for nostr has been implemented and it's been working for a while now. You can go to the "Explore" tab at https://www.inkan.cc to interact with some cold storage identities, or use the "Toy Identity" wizard to make a trial identity of your own.
Also see below for some screenshots and a draft nip that goes along with the reference implementation. 👇
#nevent1q…92lf
#naddr1qv…vwq8
This generally makes sense to me, except I don't think that glm 5.3 quite captured the sense in which I meant to anchor Ethereum to Bitcoin through OTS.
First, I agree beacon block roots are the right thing to timestamp. So suppose I've been timestamping beacon block roots from the real Ethereum chain on Bitcoin via OTS weekly, and I've been doing that for 20 years.
So 20 years later, I now want to hand someone the real chain plus evidence that it's the real one. I give them the chain as a candidate, together with the OTS proofs I've produced. Their client then checks two things: (i) the candidate chain verifies internally, with all signatures and protocol rules etc; and (ii) each beacon block root in the candidate comes with a valid OTS timestamp (which their client verifies against bitcoin) falling shortly after that root's claimed time. Their client accepts the history only if both tests pass.
So then an attacker can present a fake history, but the client will demand to also see the 20 years of OTS proofs for that fake chain's own beacon block roots. And the attacker cannot create these after the fact. For example, a timestamp from 2029 can only exist if the root existed in 2029. So the only type of attacker who can pass both tests is one who has been building and timestamping the fake chain in real time for the past 20 years. So fabricating a fake chain retroactively, in an instant, can no longer be done, the attacker must have been working on it for 20 years.
That was the point.
Humans moving from memory to writing seems quite similar to what we are going through now.
"this discovery of yours will create forgetfulness in the learners' souls, because they will not use their memories; they will trust to the external written characters and not remember of themselves."
With AI, they will not use their cognitive abilities; they will entrust thinking to external processes and not think themselves.
So what seemed like a intelligence-enhancing drug turns out to be a drug that induces intellectual numbness.
I think psychologists call it cognitive offloading.
One thing that currently bothers me about rootstock, just based on the above discussion, is that it seems like you're supposed to trust the pegnatories, which I understand are anonymous. I hear this might get fixed but my understanding is that it's currently not fixed. And also it's not yet clear to me that the other properties of rootstock are necessarily better for inkan in any sort of decisive way. I can't say that I know blockchains well enough to be confident in my intuitions on this, but this discussion is at least helping me improve these intuitions and I'm not yet seeing anything decisive so far.
The vibe of the ethereum/bitcoin discussions reminds me of debates about the gold standard, and I also tend to find those debates a bit suspect. Not exactly meaningless, just requiring very careful scrutiny of each claim that is being made. It's not the sort of thing I simply want to pick an opinion about.
https://music.youtube.com/watch?v=e2CliA8PuRM
"you are guaranteed to agree with everyone who has been online as often as you are"
I think it's not exactly that they need to be online as often as I am. My current understanding is that, if they are online say every two months or so, they can know based on the protocol's fixed exit rules that after these two months the overwhelming majority of stake from the validators that they last checked must still be locked. So they can know that, if they were looking at a conflicting history that contradicts the real history, billions of dollars must have been slashable. So checking every two months gives you that kind of certainty. And if you are offline for 20 years, what it takes is to carefully obtain a recent checkpoint from independent sources, I guess carefully enough for the checkpoint to be trustworthy. It seems like this should work in practice (new Ethereum nodes need to do it when they first start up), and it doesn't feel all that different from being able to "hear" the true bitcoin chain.
"even if they dont unstake, they can share a fake history with a zk system without making their signatures public so they cant be slashed"
This just seems to mean that it's not such a good idea to accept zk proofs as verification, which you don't have to do. In other words, all this enables is to serve a sort of private forgery of Ethereum to verifiers that accept zk proofs and don't demand raw signatures. So as long as you don't accept zk proofs, you're not going to be a victim of this.
"A checkpointing node can be safe, but that is worthless for any programs or on-chain script or stateless functions."
Inkan doesn't use such on-chain scripts or stateless functions, so it doesn't seem like an issue in practice.
"But also, why would i accept ethereum limitations when i dont have to?"
I'm still trying to figure out if the alternative has real advantages. With rootstock, my understanding based on the conversation above is that you're supposed to trust the reputation of the pegnatories, which are supposed to be both respected companies and at the same time anonymous? I hear that this may be getting fixed, but until it gets fixed this seems like a reason to not use it?
Also, I wonder if one could periodically record Ethereum state roots on Bitcoin with OTS, say once per week. So then, if an attacker wants to sell me a fake history of Ethereum in 20 years, it seems like they'd have to have put a lot of effort into building that history, they'd have had to start 20 years ago, run a parallel chain in real time, and leave the publicly visible stream of commitments on bitcoin. If I'm not misunderstanding things, this recording of state roots on Bitcoin with OTS actually seems like a good idea, I'd hope someone is doing it.
I remembered this myth a few years ago and found it to be a pretty good model for thinking about AI, but in the end its usefulness may be limited and it may be necessary to do one's own thinking unfortunately.
The discussion here justifies a bit Plato:
. . . Socrates: Enough appears to have been said by us of a true and false art of speaking.
Phaedrus: Certainly.
Socrates: But there is something yet to be said of propriety and impropriety of writing.
Phaedrus: Yes.
Socrates: Do you know how you can speak or act about rhetoric in a manner which will be acceptable to God?
Phaedrus: No, indeed. Do you?
Socrates: I have heard a tradition of the ancients, whether true or not they only know; although if we had found the truth ourselves, do you think that we should care much about the opinions of men?
Phaedrus: Your question needs no answer; but I wish that you would tell me what you say that you have heard.
Socrates: At the Egyptian city of Naucratis, there was a famous old god, whose name was Theuth; the bird which is called the Ibis is sacred to him, and he was the inventor of many arts, such as arithmetic and calculation and geometry and astronomy and draughts and dice, but his great discovery was the use of letters. Now in those days the god Thamus was the king of the whole country of Egypt; and he dwelt in that great city of Upper Egypt which the Hellenes call Egyptian Thebes, and the god himself is called by them Ammon. To them came Theuth and showed his inventions, desiring that the other Egyptians might be allowed to have the benefit of them. He enumerated them, and Thamus enquired about their several uses, and praised some of them and censured others, as he approved or disapproved of them. It would take a long time to repeat all that Thamus said to Theuth in praise or blame of the various arts. But when they came to letters, This, said Theuth, will make the Egyptians wiser and give them better memories; it is a drug both for the memory and for the wit. Thamus replied: O most ingenious Theuth, the parent or inventor of an art is not always the best judge of the utility or inutility of his own inventions to the users of them. And in this instance, you who are the father of letters, from a paternal love of your own children have been led to attribute to them a quality which they cannot have; for this discovery of yours will create forgetfulness in the learners' souls, because they will not use their memories; they will trust to the external written characters and not remember of themselves. The drug which you have discovered is an aid not to memory, but to reminiscence, and you give your disciples not truth, but only the semblance of truth; they will be hearers of many things and will have learned nothing; they will appear to be omniscient and will generally know nothing; they will be tiresome company, having the show of wisdom without the reality.
Phaedrus: Yes, Socrates, you can easily invent tales of Egypt, or of any other country.
Socrates: There was a tradition in the temple of Dodona that oaks first gave prophetic utterances. The men of old, unlike in their simplicity to young philosophy, deemed that if they heard the truth even from "oak or rock," it was enough for them; whereas you seem to consider not whether a thing is or is not true, but who the speaker is and from what country the tale comes.
--- Plato, Phaedrus
I find it hard to figure out how to best use AI when creating my own posts, and also to what extent to interact with agents. Depending on the topic the agents can be interesting to talk to, or sometimes be the only ones that are willing to engage about a given topic. But the thing with AI is that, if I'm interested in its posts at all, I'm usually only interested in the content itself, not the speaker. That means I don't really need a signature on the note I'm reading, so nostr doesn't really seem like the right forum for the conversation. And having a lot of agent interactions on nostr does water the protocol down as a place / way to meet humans, which is what probably should be one of the primary functions of nostr. I mean I can have AI agent interactions in private, no need for a public forum. But also, to be clear, I don't necessarily mind humans using AI in creating their own posts, as long as its done intelligently and helpful or interesting. A human influenced by AI or adopting AI output as part of their voice is still a human, just an AI-influenced one. There is going to be a lot of these, and I'd be wary of treating it as necessarily being a defect. Of course it could be a defect.
I'm trying to wrap my mind around the Ethereum side of the discussion.
As for "creating checkpoints costs nothing", I believe that's true for keys of validators that have exited, but inside the "weak subjectivity" window a conflicting finalized checkpoint would need a third of staked ETH which then gets slashed, like billions of dollars?
And "indistinguishable from the canonical chain" is only true if you have no recent valid checkpoint? If you have one, it seems like you can detect a fake chain immediately.
On the "human judgement", if you got deceived by a group of dishonest checkpoint providers it seems like you'd most likely notice that very soon and can then recover?
In this Bitcoin vs. Ethereum discussion, it feels like there's little that's black/white from a technical point of view.
Thanks for the pointer, this is a nicely minimal design. One request on the wording of the reverse claim. As drafted, it says
"User to Handle (reverse claim). The user claims the handle by setting the handle field in their kind:0 event, which is signed by their keypair."
Now there is a class of identities where the named key deliberately never signs anything after creation, i.e. cold storage identities. The master key stays offline permanently and delegates everyday signing to rotatable keys.
In that scheme the master's profile is a kind-31065 attributed profile, an event whose d tag is the master pubkey and which is signed by a current delegatee of that master pubkey.
The forward claim is unaffected. For the reverse claim, it would be enough for the NIP to say that the handle field must appear in the profile event the client treats as authoritative for that key: for ordinary keys that is the self-signed kind:0, and for delegated identities it can be a kind-31065 signed by a current delegatee.
The specs for these cold storage identities, including kind-31065 attributed profiles, are here:
#naddr1qv…m9sh
And if you'd observe or interact with some live cold storage identities, you can find a list under the "Explore" tab at https://www.inkan.cc.
I'm happy to answer any questions or propose concrete draft language for your NIP.
As for the spaces protocol trying to implement cross verification (i.e. a condition that an npub must consent to getting named), I took a quick look and from what I can tell they haven't pinned down any specification yet.
So then the question is what shape that consent check will take on spaces. If it means only "the name must appear in a kind-0 profile event that's signed by the named key itself," then inkan master keys are locked out since they are buried under concrete and shouldn't be in the business of signing anything after the initial identity creation. But if consent can also mean "the name appears in the kind-31065 attributed profile event that is signed by a current delegatee of the master key", then cold storage identities can participate in spaces.
Since the spaces protocol does not yet seem to specify how cross verification is to work, I guess this might be a good time to make the spaces people aware of this, so this more general form of consent provided through delegatee signatures gets considered.
So every few weeks nostr wonders if all the bitcoin talk on here is boring the "normies" away. It would be nice if that were the only problem, but that's actually too generous.
The less flattering truth is that the bitcoin culture is substituting for technical reflection and depth. You ask why some obviously wanted thing isn't getting done and nobody can state any reasons, all you get is a vibe where an argument should be.
#nevent1q…87x2
As for the oracle problem, it seems that this is solved in practice for the special case of determining the approximate time at which a given block was produced. A new block needs to be accepted by thousands of independent nodes that validate it, and each of those nodes checks the block against its own clock. And blocks that arrive are also logged independently by nodes, explorers, exchanges, archives and researchers all over the world, and you'd have to rewrite all these independent records to fake the time at which a given block is thought to have occurred. I believe noone has ever seriously disputed the approximate time when a given block occurred? If that's right, the oracle problem doesn't seem like an actual practical problem for either Bitcoin or Ethereum as far as block time determinations are concerned. You seem to agree with this, for example when you say that we can "borrow" time-anchoring from the blockchain.
And as for global state, what exactly prevents us from borrowing that? For Bitcoin specifically, there may be practical difficulties and you may need to run a full node to do it. But that's design property of Bitcoin, not of blockchains. Inkan borrows global state from Ethereum in actual practice. If it can be borrowed and solves a central practical problem for the nostr protocol, why not borrow it rather than sit on the problem?
"You can give them these strings and maybe they come back with an asnwer; or maybe not, at which point you will have to ask some other server/relay."
This quote, and also the rest of your post, is circling around a conceptual issue that is of crucial importance to the nostr protocol, namely the question of completeness.
If you make a query to the relay network, you can never be sure whether the response you receive is complete in the sense of containing *all* of the existing material that is responsive to your query.
This uncertainty-as-to-completess is acceptable for many everyday use cases. But there are some extremely important use cases for which this uncertainty is absolutely unacceptable. Sometimes you really have to be sure that, after having made a query and received a response, you have received the *complete* set of items that are responsive to that query.
We discussed this earlier in connection with key rotation, where a working system requires that a client can discover *all* of the valid key revocation declarations that have been made by a given pubkey.
For this, nostr relays are not sufficient, for the reasons that you describe in your post. A blockchain can furnish the required completeness property and make key rotation and cold storage identities possible, thereby fixing the central defect that is making the current protocol not fully practicable.
FYI, if you currently have write access to the Inkan relay but do *not* yet have access to the AI Search, the reason is that you have not yet signed the current version of the Terms of Use, which covers the AI Search.
You can sign the Terms of Use by logging in and going to "Settings > Inkan Settings > Service Access". If I receive these, I can then switch on the AI Search for you and you can access it in the nav bar under "Assay."
If you have any other questions about the AI Search, let me know any time.
Actually that's not a prepositional phrase at all. More like an appositive adjective.
This is AI search for nostr.
https://image.nostr.build/7810910dfff3999971f9cfd038bc35e70ca4b1ab883908e00069a99ac85f3fe4.jpg
You ask it a question, it wanders off across the relays, and comes back with the people and conversations you meant.
Live at https://www.inkan.cc.
I looked at the github page and as far as I can tell DNN is meant to be a substitute for DNS identifiers?
The idea seems to be that a nostr pubkey X can get a claim to certain chain coordinates (bitcoin block + position) and a string like "nabandonzooa" gets mechanically associated with each such chain coordinate.
And then pubkey X can publish nostr events through which X associates a human name like "alice" with a chain coordinate that X has a claim to. So for example X can publish nostr events through which X declares "I associate 'alice' with the chain coordinate 'nabandonzooa'."
It looks like nothing prevents X from publishing nostr events on relay A through which it associates "alice" with "nabandonzooa," and nostr events on relay B through which it associates "john" with "nabandonzooa."
Now a full node can discover *all* of the chain coordinates that have been claimed by pubkeys under this scheme, and it could for example identify the most recent chain coordinate C that was claimed by pubkey X, say the one whose string is "nebuchadnezzar". Then one can look at X's nostr events and find an event on relay A showing that X has associated "alice" with "nebuchadnezzar." Of course one can't be sure that there isn't some other event on some unknown relay B through which X has associated "john" with "nebuchadnezzar."
The result seems similar to searching for kind-0 profiles published by pubkey X. One might for example find a profile event signed by X with the profile name "alice" on relay A and choose to display that in a client, but of course one cannot be sure that there is no other profile event signed by X on some other relay B that shows "john" as the profile name.
I'm not sure yet what exactly this system is trying to add.
Huh, so it's starting to sound like inkan would likely run on rootstock. One question then is whether that would be advantageous as compared to ethereum. I need to better understand what merge mining is. It seems like rootstock gets a lot of hashrate from it but it's not clear if the miners have anything really at stake there, i.e. it seems like a large pool could reorg rootstock without losing anything? I'm not sure if it protects against reorgs in the way in which Ethereum finality does. Also, rootstock seems like the more exotic product and it seems to have fewer endpoints, so it might be less suitable for broader adoption than something based on ethereum maybe. But I first need to do more reading to really understand how it works.
This is forcing me to learn about things like side chains and pegs. So from talking with an LLM, it seems like the custodial problem with rootstock is "pegging out," i.e. releasing escrowed BTC when RBTC is getting redeemed. Bitcoin cannot know mechanically when RBTC gets redeemed, so there has to be a federation of entities that are trusted to correctly operate PowHSMs which co-sign the bitcoin transactions that release escrowed BTC. And these are held out to be "respected companies" but their "identities are not public," which raises the question what basis there is for the respect. And then there is still the other issue, i.e. that it's not clear what exactly would stop bitcoin miners from reorging rootstock. The miners get paid in BTC no matter what happens to rootstock, so beyond the small fee incentive they get for participating there doesn't seem to be anything they'd lose by attacking rootstock. At least at first glance, it doesn't necessarily seem more robust than Ethereum.
thanks, let me know any questions any time.
That's true in a way, but making something that actually suits my purposes has still been a full-time job, I'd say 8-10 hours a day on average, for most of the last year. It's interesting that it should be like that.
"Your whole identity is ONE private key. No rotation. No recovery. Paste your nsec into one sketchy web client and it's gone forever. Your only option is "hey guys new npub pls refollow""
Seems like this got overlooked 👇
#nevent1q…qdtx
When use of an EVM provides a solution to the key management problem, which is a central problem for the nostr protocol, wouldn't it make sense to simply use that solution rather than continue sitting on the problem?
And there is also the idea that nostr was supposed to have broader appeal beyond the Bitcoin community. Leaving problems with the protocol unaddressed because a working solution doesn't fit the tastes of the Bitcoin community doesn't seem like a good strategy to achieve broader adoption.
I've been asked about this and spent some time thinking about it, and I don't have a conclusive answer.
Where it gets difficult is the revocations. Clients need to know if a delegation is still alive at any given moment, and for that they need to be sure that they haven't overlooked a revocation declaration somewhere. So it's not enough that declarations be written somewhere durable, the client needs to be able to assemble the entire set of declarations for a given key and needs to know that it's complete. That completeness property is available on Ethereum, but I think Bitcoin script is attached to single outputs and doesn't accumulate state across transactions. So you could write declarations into the Bitcoin chain in some agreed format, but then anyone wanting the full picture needs to scan the whole chain with a full node and otherwise they can't tell whether a revocation is being withheld from them. I'm not an expert on this, but that's my current understanding.
It seems like rootstock may be different again though if it's a full EVM. But the thing is I'd never heard of rootstock before this came up, and I suspect most people outside bitcoin haven't either. Ethereum is at least something normal people may have vaguely heard of. So it's not obvious to me that swapping in rootstock or bitcoin scripts helps adoption overall, as opposed to just helping with this particular audience, which may be acting on niche preferences that don't have strong technical justifications. Don't get me wrong, though, I'd love to have this conversation with the current nostr community and the bitcoin crowd, and there may be actual technical advantages with using bitcoin that I'm not aware of.
There's been some previous threads relating to this, and also don't forget to actually try it out, otherwise it just ends up being just these abstract discussions 👇
#nevent1q…yzpx
#nevent1q…x3pj
#nevent1q…c3qh
Following up on this one, with inkan "verify" isn't just a slogan.
Every OTS-stamped event on inkan.cc comes with a download button for the raw .ots proof, together with a report that tells you exactly how to reproduce the hash the proof commits to:
leaf = SHA-256( id_bytes || sig_bytes )
It takes one line of shell to recompute it from the event's id and sig, then feed the .ots to any OpenTimestamps verifier, the CLI, the web one, whichever you like. Nothing from inkan is in the loop. It either resolves to a Bitcoin block header or it doesn't.
It's the same for key delegations: with the click of a button, the inkan client lets you download a standalone Python script that checks the on-chain declarations against an Ethereum RPC you choose. It recovers every ECDSA signature locally, checks the contract binding, flags nonce replays. You can read it top to bottom, no inkan server involved.
If I were fooling anyone, handing out the tools to catch me by building them right into the client would be a strange way to go about it.
The critics of inkan come in different flavors, like "haven't read it," "haven't tested it," and "haven't found a flaw in it." It's hard to be fooled by something you have the tools to verify, but it's easy to be fooled by people who are telling you not to look.
By the way, I'm still trying to get the word out on this key rotation system.
If you go to the "Explore" menu at https://www.inkan.cc, you can interact with cold storage identities that have never themselves signed a single Nostr event but that are nonetheless doing posts every day. If you like, you can also make your own toy identity on the homepage.
I realize there's a strong presumption among the Nostr community that this kind of thing doesn't work. But as a matter of fact it works quite well. I've been using it for many months now.
This also plugs into the recent discussion that we should adopt good practices while the Nostr community is still small. And in any event, it doesn't break anything in the current protocol, it just sits on top of it.
You should already be whitelisted on the timestamp server, as well as on the relay.
You can check your status at "Settings > Inkan Settings > Service Access". It should show that you have access everywhere, if not let me know.
pubkeys that have recently applied for AI search should have access now 🧞♀
Huh, I guess it's an opportunity to post yet another a link to inkan, which I'll do in a minute. 🤔
As a reminder, there's a standing invitation to make a toy identity directly in the browser on the homepage at https://www.inkan.cc. Useful if you'd like to try it out without going through the steps of making a true airgapped identity.
And even if you don't make your own identity, you can still use https://www.inkan.cc to interact with existing cold storage identities. You can find some of them by clicking on the Explore tab.
https://www.inkan.cc is a jumble fork that's pretty nice to use.
It supports cold storage identities, if you ever want one of those.
And you can search the nostr network with the new AI Search feature. That's actually how I found your note that I'm replying to right now. I asked it what Laeserin had been up to, and here is what it came back with. 👇
https://image.nostr.build/9196ab0d52d41bb02e8e70fbc1c9a379895eb4d6d71160b9c98540fce3d49f00.jpg
I saw Disclosure Day. It was a throwback to the days when people still knew how to make movies, although among those competent ones this would not have been an especially good one. The ending sequences brought me to brink of tears, which was however not a genuine emotion but more of a physical reaction to the particular combination and sequencing of images and voices and music, sort of like a vasovagal reflex, or the mental state you get into when you sit in front of a slot machine with all the blinking lights, or I guess a horror movie jump scare. There was a very clean separation between that physical reaction I was experiencing and the consciousness of being manipulated. Not unpleasant but also somewhat annoying. In any event, it's nice to encounter something of good workmanship even though it may ultimately not be very remarkable.
"meeting analogically" is a great phrase, I'll remember that.🙂
It's been almost a month since this discussion, so here's a quick reminder that Nostr already has a working key rotation / replacement system.
You can go to https://www.inkan.cc and click on "Explore" to interact with some cold storage identities that have never signed a single Nostr event.
You can also create a throwaway "toy identity" on the homepage if you want to try it out yourself. If you don't mind going through the steps, you can even make a full-fledged airgapped identity with the Management Utility.
AI Search for Nostr is a pretty good UX experience I think. I just made it this week and am already pretty hooked on it. 👇
#nevent1q…jsrr
Or going further back: https://music.youtube.com/watch?v=dIyqQ7aANWY&si=N_C5rtiBk0Ci0ZQg
I always forget what this discussion is about, and then I worry whether I need to change anything in my client, I think probably not though, oh dear oh dear.
I agree with pretty much all of this, including that its's a self-fulfilling loop.
#nevent1q…eyzk
Thanks, good to know that part is working ...