inkan

Also talked to my LLM, and I think the issue with rootstock "confirmations" is that they consist of merge-mined work which is produced by bitcoin miners at zero marginal cost. So there is little that bitcoin miners would lose if they attacked rootstock. And the preventive measures you mention seem to be about detection and halting the chain, but that would give attackers the ability to, well, halt the chain, at no marginal cost to them. And then there would have to be social recovery.
For inkan, the worst thing that could happen is not for RBTC to become unpegged from BTC. It's rather that rootstock gets reorganized, which could rewrite the delegation / revocation history, which would be catastrophic for inkan identities. The integrity of the history is precisely what inkan depends on.

2026-10-14 07:52:09 UTC

- reply

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.

2026-10-13 23:14:29 UTC

- reply

I haven't used anything FROST-based, but I think I would if I could do it in a way that seems more secure than regular NIP-46, and convenient to use.
For it to be more secure than regular NIP-46, I would want to require all shards for signing and keep exclusive control over at least one shard myself. If there isn't anything in the cryptography underlying FROST which makes it inherently less secure than using an unsharded key, it seems that this way of using it would be at least as secure as regular NIP-46.
And then on the convenience side, the actual signing would ideally be controlled through an app that sits on my phone and feels generally like Amber, and that app should probably hold one of the shards over which I have exclusive control.
I've only taken a cursory glance at FROST, but if there is something that provides this kind of experience or something equivalent, I think I'd try it.

2026-10-13 17:38:26 UTC

- reply

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.

2026-10-13 16:38:31 UTC

- reply

thanks, let me know any questions any time.

2026-10-13 13:18:52 UTC

- reply

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.

2026-10-13 12:59:05 UTC

- reply

"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

2026-10-13 12:37:55 UTC

- reply

See?

2026-10-13 12:18:23 UTC

- reply

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

2026-10-12 20:39:57 UTC

- reply

Actually you can simply keep using your current nostr keypair and make it the signer for a cold storage identity, this just came up in another conversation 👇
#nevent1q…hmyc

2026-10-12 19:32:15 UTC

- reply

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.

2026-10-12 19:08:51 UTC

- reply

That seems right, I also just responded with the same reference to the NIP draft.

2026-10-12 19:07:26 UTC

- reply

You need a blockchain with certain completeness properties. It's just a technical requirement, not some partiality towards Ethereum in particular.
The gas fees required for an identity creation are tiny, I think it was maybe $0.20 or so the last time I did it.
I'm happy to take care of the tiny gas payment if you don't hold Ether. There's an option at the end of the toy identity wizard to send me the transaction file that was created and I can record it on-chain.
FYI, the technical specs (which among other things explain why a blockchain is needed) are here 👇
#naddr1qv…vwq8

2026-10-12 18:54:18 UTC

- reply

You can keep using your current npub and delegate down to it.
For example, the npub I'm using right now does double duty as the signer key for a cold storage identity. The profile page of that identity is here:
https://www.inkan.cc/users/npub10ukg94kvrvk4qqr3482zdekfsuaw2x56wa899mnpkxqwfxl6dlkqrux0x9
People who are currently following the signer key can continue to do so for as long as they like, although I'd hope that they'll eventually get around to directly following the identity key (since the identity key will survive if / when the signer key gets compromised).

2026-10-12 18:44:37 UTC

- reply

Sorry I've been sleeping through this discussion.
So it's like you say, you don't have to abandon your current npub if you don't want to. You can create a new master key and delegate down from it, through a delegation chain, to the npub you already use on nostr.
You then keep posting with your current npub exactly as before. After the delegation this npub doubles as your inkan signing key, so everything you create with it from then on gets attributed to the new master key. If your current npub is ever compromised, the master key can then revoke it and delegate to a new one. The identity attached to the master key survives the compromise.
Full disclosure, this construction needs to be done with the Inkan Management Utility (https://www.inkan.cc/settings/inkan-management-utility), and it takes a bit more care than just creating a completely new identity from scratch. You basically prepare a small text file with your current private key in hex and feed it to the utility, and ideally you do all of this on an airgapped system, since you're handling private key material. If you want to try it, let me know and I'm happy to write up the exact steps, including the format that's required for the input file.
And if you'd first just like to get a better idea of how inkan works before connecting it to your current npub, you can create a throwaway toy identity on inkan's homepage. Recording it on Ethereum costs a small gas fee, and the wizard has a menu where you can ask me to sponsor that tiny amount, which I'm usually happy to do for people who don't hold any Ether (and seem reasonably good-natured, at least as far as posting to the inkan relay goes). Creating one happens right in the browser and takes about five minutes, and the result is the same cryptographic object the Management Utility would produce, just made in an insecure location rather than on an airgapped machine.

2026-10-12 14:56:55 UTC

- reply

The other thingy is fun as well.

2026-10-12 06:08:39 UTC

- reply

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.

2026-10-11 19:58:11 UTC

- reply

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.

2026-10-11 19:41:49 UTC

pubkeys that have recently applied for AI search should have access now 🧞‍♀

2026-10-11 19:05:21 UTC

- reply

The concept is not going away for as long as there is asymmetric cryptography.🤷‍♂

2026-10-11 18:34:21 UTC

- reply

Don't trust, verify.

2026-10-11 18:21:39 UTC

- reply

I bet you can get all sorts of descriptions out of it if you just tweak the prompt. It's available under "Assay" in the nav bar at https://www.inkan.cc. If you'd like to try it out it first asks you to sign the Terms, once I have these I'm happy to switch it on for your pubkey.

2026-10-11 17:53:52 UTC

- reply

this is kind of relevant broadly speaking, for the nostr case 👇
#nevent1q…uw9c

2026-10-11 17:49:05 UTC

- reply

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.

2026-10-11 16:17:32 UTC

- reply

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

2026-10-11 15:03:51 UTC

- reply

Once you get used to managing your regular key pair, you may at some point become interested in replaceable keys, i.e. keys that you you can revoke if they are ever lost or stolen and replace with new ones.
I implemented a system for doing this at https://www.inkan.cc. Other nostr users tell me that the system is too complicated, especially for people who are just getting started with nostr. I don't really think so, but I guess it depends on one's preferences. In any event, I wanted to let you know that there's a way of doing this if you are, or ever become, interested. See below for a bit more info and some screenshots. 👇
#nevent1q…uw9c

2026-10-05 00:53:22 UTC

- reply

Wow.

2026-10-04 22:40:31 UTC

- reply

Thanks, I'll take a look at their repo to see how they are doing it. What I was thinking was to let the AI search page talk to any server that speaks the standard chat API. You'd run a local gateway with your provider key in its config, and paste its localhost address into a field on the search page, or something like that.
I hadn't heard of buzz. It's really interesting to me as it seems to be about AI agent identity. This is something I've thinking a lot about in connection with inkan, because inkan provides the ability not just to give AI agents identity, but also to make it durable, and to make AI identities accountable to identities of human principals.
I asked my AI search whether buzz has a nostr handle, but other than a bot nothing came up ...

2026-10-04 16:39:13 UTC

For the AI search, I could try to add a "connect your own model" feature.
The idea would be that you run a local gateway (e.g. LiteLLM) on your laptop with your own model provider account behind it , like DeepSeek or Anthropic or whatever. The AI search page then talks to that instead of the AI that inkan is using.
Should I add such a feature? Would anyone want to use it?
#nevent1q…ehda

2026-10-04 15:57:43 UTC

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.

2026-10-04 07:35:08 UTC

- reply

"meeting analogically" is a great phrase, I'll remember that.🙂

2026-10-04 02:48:56 UTC

- reply

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.

2026-10-03 04:03:58 UTC

- reply

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.

2026-10-03 03:31:50 UTC

- reply

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

2026-10-03 03:14:37 UTC

- reply

"Your nsec is still your identity"
FYI, here is a system where your nsec is no longer your identity. If you go to the Explore page at https://www.inkan.cc, you can interact with Nostr identities that have never signed a Nostr event themselves. You can also create your own toy identity on the homepage.👇
#nevent1q…qdtx

2026-09-21 05:49:20 UTC

So there's this nostr paradox, why would a community obsessed with crypto and key security refuse to even test working key rotation?
Because you can't tell working from broken without spending your own time on it.
After enough broken NIPs and abandoned apps, you learn to price every new thing as a lemon and assume broken. The good leaves the market with the bad. 👇
https://en.wikipedia.org/wiki/The_Market_for_Lemons