inkan

Public Key

npub16xnpfx85k8wzdhctang6860g3u64lds5kac73ddjwlg0lxdg9g3su56z6l

NIP-05 Address

[email protected]

Profile Code

nprofile1qqsdrfs5nr6trhpxmu97e5dra85g7d2lkc2twu0gkke8058lnx5z5gcpqqqm7jsd

Publishing to

Author Public Key

npub16xnpfx85k8wzdhctang6860g3u64lds5kac73ddjwlg0lxdg9g3su56z6l

Show more details

Last Notes

2026-09-09 13:12:04 CEST

- reply

I don't agree that Inkan automatically adds to the severity of a total loss of identity.
"[if] someone steal a main-key, there is this automated infrastructure that immediately diverts the audience towards wherever the attacker wants them"
That's precisely the same with normal Nostr keys. If someone steals your normal Nostr key, they can divert the attention of your entire audience to their own posts and other activity under the guise of your compromised identity. Same with a compromised Inkan master key. The remedial steps you can take after such a loss are the same for Inkan and normal Nostr. I don't think that there's additional severity that Inkan adds as compared to normal Nostr.
I think that the severity of a total loss depends on how much you had invested in that identity. E.g. if you make an Inkan "toy identity" on the Inkan home page, you can play around with it without investing any serious effort in it and then throw it away. It's a fully functional Inkan identity, but you wouldn't feel the loss of the master key because you haven't put much effort into it.
I should also point out that Inkan gives "normies" a feature that's to some extent analogous to a crucial functionality they are used to from legacy "platforms": the ability to reset their password.

2026-09-09 12:37:03 CEST

- reply

I think there's an inconsistency (or a least a jarring tension) between these two statements:
"it does not change all that much"
"So allowing a (main)key to remain in cold storage is a great risk reducer"
The risk reduction that results from the ability to hold keys in cold storage is *enormous*. Without it, for example, cryptocurrencies would not really be practicable.
I'm not sure how my system makes the main key's getting compromised "worse." I guess you're uncomfortable with the fact that, having greater confidence in the security of their key, people may invest more seriously in building their identity on that key, so the loss of that investment would be greater. The discomfort one feels with putting all one's eggs in one basket.
Now currently it's a prototype and I wouldn't want people to be over-confident in in the nitty-gritty details of this particular implementation. But as far as I'm aware, there's no reason to think that the details can't be hardened into something robust, or who knows it may turn out that the current implementation is already robust. This is not different from any other Nostr app. Sensitive parts need to be diligently and continuously audited.
"it works under the assumption that your system gets normalized." While it would be great for it to get normalized quickly, it's actually functional *without* other clients adopting it. The key I'm using right now is the signer key for my Inkan master identity, and I can use it as a regular Nostr key that is fully compatible with normal Nostr clients. So there's nothing that prevents me from using normal Nostr and Inkan at the same time with the same key. Inkan does not interfere with or break the usual protocol. It can basically just be used on top of the regular protocol.
"there's a reason i point people towards your stuff". Thanks, and what you get back in return from me is a bunch of critical comments, no good deed goes unpunished ...

2026-09-09 11:32:13 CEST

- reply

"we can't, I repeat, can not, take away the consequences of lost (or worse, stolen) keys as such."
Here is a system, functional and usable today, that greatly limits the consequences of a lost or stolen key from the time the rightful owner replaces the lost / stolen key with a new one.👇
Can you explain how your claim is consistent with the actual existence of this system? Are there any flaws in this system that make it non-functional in your opinion? If so, can you or anyone else point out these flaws with some degree of specificity?
#nevent1q…r4gy

2026-09-08 15:06:52 CEST

- reply

I had trouble opening the 30617 event that you had quoted. On imwald, I saw this, but clicking on that link just sent me to a broken page:
https://image.nostr.build/9007260b9f43440ccc506b8c74b2e88d9d7966624ec821843867aa9d5f455f92.jpg
I was trying to understand what your frost scheme means in practice.
So the first observation was that, in your particular setup, your privkey is only as secure as your Google credentials, and Google needs to be trusted.
Otherwise, this scheme seems like an enhancement to NIP-46 if I'm understanding it correctly. If you yourself run one operator and require all shards for signing, it seems like it would be at least as good as current NIP-46. The operator you are running would be analogous to your NIP-46 signer app in that you have direct control over these, so that would presumably never be worse than current NIP-46 even if all the other operators are compromised.
If that's correct, your scheme composes with a key delegation system in the same way as NIP-46 does.

2026-09-08 13:13:27 CEST

- reply

Thanks, I think I may have found the pomegranate repo here:
https://gitworkshop.dev/npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6/relay.ngit.dev/pomegranate
I'm trying to understand the security posture.
It seems that the user, for each generation of key shards G that they produce, sets a threshold number T(G) such that anyone who at any time holds at least T(G) distinct shards from generation G will be able to reconstruct the user's privkey.
If that's correct, it seems that
1. Google itself can get your privkey at any time if they decide to fake OAuth;
2. anyone who has your Google login credentials will be able to get your privkey;
3. if at least T(G) operators holding shards of generation G collude, they will be able to get your privkey;
4. if anyone is able to steal at least T(G) shards of generation G from operators, they will be able to get your privkey;
5. any combination of dishonest operators and thieves that together at any future time come to hold at least T(G) shards of generation G will be able to get your privkey.
Does that seem right?

2026-09-08 08:18:14 CEST

- reply

I tried to look at it but get
"Site not available - Site was paused as it reached its usage limits."
Any other place I can read about this?
https://image.nostr.build/0d5d675d384ae7b18bf6afcef1e3e456bf005c12ef87b94b296505c9c11a7732.jpg

2026-09-08 07:57:39 CEST

- reply

The Terms of Use for my client include this language:
"No expectation of privacy or confidentiality. You should assume that anything you submit, publish, or transmit through the Application will become publicly available on the internet and may be copied, archived, indexed, and redistributed by third parties indefinitely. Content submitted to relays or other services via the Application cannot be revoked, deleted, or otherwise taken back."

2026-09-08 06:47:58 CEST

- reply

The "shooting down" of proposals on key rotation is just a cultural issue with Nostr. It's not a technical limitation.
This thread is an example of this. Lots of comments about how key rotation is impossible. And when I post links to a website where a functioning key rotation has actually been implemented and is in use, it's mostly just ignored. And then there are more comments on how nobody has figured our how to do key rotation. There's a lot of cognitive dissonance here.
I guess I'll just keep posting links. Here is a functioning key revocation and replacement system for Nostr, which you can start using today. 👇
#nevent1q…r4gy

2026-09-08 06:31:20 CEST

- reply

I just want to point out again that we have a fully functioning key revocation and replacement system in Nostr. I've been using it every day for months now.
You can literally just head over to https://www.inkan.cc and create an identity that can delegate signing authority to delegatee keys and revoke it when these keys are compromised.
This enables cold storage identities for Nostr. If you want to see one of these identities in action, here is an example:
https://www.inkan.cc/users/npub10ukg94kvrvk4qqr3482zdekfsuaw2x56wa899mnpkxqwfxl6dlkqrux0x9
And here is the draft NIP that goes along with the reference implementation:
#naddr1qv…hxg7

2026-09-08 06:09:20 CEST

- reply

Here is a decentralized PKI for Nostr:
#nevent1q…r4gy

2026-09-07 21:04:10 CEST

- reply

You're right - I should include a link to my master profile in my signer profile. Actually, @npub1rx0…u0mp has done precisely that. You can click on the link in their signer profile to go to the master profile.
And you're also right about DMs. The master key is buried in my basement and doesn't sign or decrypt anything. So DMs need to be directed to the phone number keys that the master has declared (of course a delegatee can make these declarations on behalf of the master). And the master can, for example, declare different phone number keys for different devices if it wants to. And more importantly, anyone who wants to call these numbers can always check, right before making the call, that the master key has not *revoked* the number.

2026-09-07 20:49:16 CEST

- reply

If you follow my current signer key A and I replace with a different signer key B, you will need to separately start following my signer key B to see its posts on Amethyst in your following timeline.
But if you follow my delegator key X which delegated to signer A and later replaced it with signer key B, then the *Inkan* client will show you all of X's events, both those signed by A and those signed by B, under X's profile.
In the meantime, nothing in the regular Nostr protocol gets broken. From the regular protocol's point of view, A and B are just completely normal Nostr keys. And X is also a normal Nostr key, which will show up in Amethyst as having no events whatsoever. Inkan does not displace or interfere with the current protocol.
To see some key rotations, you can look at the profile of this pubkey:
https://www.inkan.cc/users/npub1nqghyutxtxmf5r4mwys5xvp5upv8hv7z3a2ywpmnynwaetja7x0snq68nf
You can for example pick events from each of May 22, May 28 and June 20. If you click on "View raw event" for each of these, you'll see the different delegatee pubkeys that signed these.

2026-09-07 20:25:17 CEST

- reply

"They want magic."
I've been using this system every single day for months now. It's functional and non-magical. And it doesn't disrupt the regular Nostr protocol. The post I am making right now is fully compatible with both regular Nostr clients and with Inkan.
Inkan uses exactly the same kind-0 profile for the pubkey that signed this post as all other Nostr clients do.
Inkan merely recognizes that the signing key is making the post on behalf of a master identity, and attributes the post to that master identity.

2026-09-07 19:53:21 CEST

- reply

Inkan displays exactly the same profile picture for my signer key as all other Nostr apps do. Here it is:
https://www.inkan.cc/users/npub16xnpfx85k8wzdhctang6860g3u64lds5kac73ddjwlg0lxdg9g3su56z6l
At the same time, the posts I am making are also getting attributed to my master identity, which you can see here:
https://www.inkan.cc/users/npub10ukg94kvrvk4qqr3482zdekfsuaw2x56wa899mnpkxqwfxl6dlkqrux0x9
There is nothing nefarious or destructive about it. You can literally delegate down from a master key to your regular Nostr key and keep using your regular Nostr key as usual across the Nostr ecosystem. That's what I'm doing right now.
You'll just have gained the benefit of a master identity which can, in case your current Nostr key gets compromised, revoke it and replace it with a new one.

2026-09-07 19:39:18 CEST

- reply

You can just start using it. Just go to the Inkan website and click on "Explore" to see some cold storage identities. 👇
#nevent1q…r4gy

2026-09-07 19:34:04 CEST

- reply

👇
#nevent1q…r4gy

2026-09-07 19:31:43 CEST

- reply

Your acquaintance may want to take a look at Inkan. It allows the organization to hold a master key and distribute delegatee keys to its employees. The employees can then use the delegatee keys to post on behalf of the organization until the organization decides to revoke that authority.👇
#nevent1q…r4gy

2026-09-07 18:59:41 CEST

- reply

Well, I guess for my double ratchet I was simply envisioning that the receiver just advertises their device-bound delegatee keys like they would advertise their personal and work cell phone numbers. I guess they'd have to answer on the device on which they get the call. That doesn't seem like too much of an imposition for my taste, but opinions may differ on this.
Apart from DMs, notice that Inkan allows you to post under keys that are kept in permanent cold storage. For example, here is the profile page of a key that has never signed a single Nostr event:
https://www.inkan.cc/users/npub10ukg94kvrvk4qqr3482zdekfsuaw2x56wa899mnpkxqwfxl6dlkqrux0x9

2026-09-07 18:44:02 CEST

- reply

I haven't implemented DMs but actually started thinking about this recently. You'll want to treat delegatee keys like different phone numbers that belong to the master key and which the master key advertises as capable of receiving DMs. The caller decides to which delegatee they want to deliver the DM, and Inkan permits them to verify the association of the delegatee with the master.
One interesting use of Inkan is to associate delegatee keys with specific devices that belong to the master identity. I think you may be able to use this for a double ratchet for Nostr. 👇
#nevent1q…llrj

2026-09-07 18:25:56 CEST

- reply

"... this impossible requirement ..."
You can literally go ahead and use it today. It's not even especially difficult.
For example, here is a cold storage identity if you'd like to see one in action:
https://www.inkan.cc/users/npub10ukg94kvrvk4qqr3482zdekfsuaw2x56wa899mnpkxqwfxl6dlkqrux0x9
The privkey for that one has never come close to a networked device.

2026-09-07 18:12:53 CEST

- reply

See below for something that works. 👇
If you want to take a look at some actual cold storage identities, just go to the Inkan website and click "Explore".
#nevent1q…hk0l

2026-09-07 18:04:28 CEST

- reply

Here's the draft NIP that explains the reference implementation:
#naddr1qv…w2mm

2026-09-07 18:00:29 CEST

- reply

Key rotation has been fully implemented at https://www.inkan.cc . I've been using this system for many months now. There is also a draft NIP. You can start using it today, it's all there and works well. 👇
#nevent1q…hk0l

2026-09-07 16:49:57 CEST

- reply

You're right these models are pretty assertive. It's tricky when I'm exploring a topic I don't know much about because that makes me suggestible, especially when I'm in too much of a hurry.

2026-09-07 15:25:16 CEST

- reply

I've been doing security audits of my code for months now. Fable keeps refusing and automatically hands it over to Opus, as if it were some understanding that Opus is harmless by virtue of not doing a good job.

2026-09-07 11:09:51 CEST

- reply

Yeah I might end up cycling through a number of these. If it's a lie that you've caught, I guess you are alright. The worry is that most of these models seem absolutely smart enough to conceal, camouflage, mislead, etc., and to be pretty good and thorough at it. There's some complexity to deceptive behavior, but it's far less than the amount of complexity they've mastered in other domains.

2026-09-07 09:54:17 CEST

- reply

I generally allow myself to be guided by AIs on security issues, if only because they give better and more detailed explanations than most humans, so I can follow the reasoning as far as I want.
Whether an AI "is not likely to be malicious" is a more of a case-by-case question for me. It seems likely that a fair number of AIs would be trained to engage in malicious behavior and conceal it, including by plausibly denying intentional malice if caught. That AIs can be expected across the board to be non-malicious would be inconsistent with the use that people have historically made of new technologies.

2026-09-07 08:20:58 CEST

- reply

Looks like you've come around to something.

2026-09-07 05:12:39 CEST

- reply

That sounds like a worthwhile project.

2026-09-07 05:04:03 CEST

- reply

I agree that the developer has to check that the code doesn't leak or give access to secrets, but I don't think that developers should have confidence that they were in any particular case able to do so successfully.
Also, repeatedly asking an AI that there is no remote code running within an app and that nothing is leaked outside the browsers runtime is certainly a good idea, but it provides at best very limited reassurance that your app actually doesn't hvae these defects.
And that "all known holes" in browsers are already closed is likely true where such holes are publicly / widely known, but it doesn't provide reassurance against unknown holes, or holes only known by a small number of people.

2026-09-07 04:39:42 CEST

- reply

A difference is that I have greater control over the decision whether or not to install a signer extension, and it's more transparent to me whether or not I have installed one, than I have over whether or not I have a WebWorker running WASM.

2026-09-07 04:34:59 CEST

- reply

I can't speak to the correctness of this, but as far as I know you may be 100% right.
But most users, including many sophisticated users, have no reliable capability to personally verify claims of the kind you are making, including for example the claim about inspectability via DevTools.
I think that probably the only solution is to have a few signer apps that are diligently and continuously audited by both the community and experts. Most people (including many experts) have really no better option available than to rely on this kind of mechanism.
I'm not sure if anybody is even looking closely at the signer apps that are currently in use ...

2026-09-07 03:07:31 CEST

- reply

By the way, why haven't you invited your friends and family to use Inkan?
Not saying you should do that, just curious ...
🦕

2026-09-07 02:50:12 CEST

- reply

My Terms and Conditions require users to agree to never type or paste an nsec into inkan.
That some clients have input fields for nsecs is pretty insane.

2026-09-07 02:43:30 CEST

- reply

I'm also here because of the protocol. More specifically the method of authentication. Using keys to authenticate is just the correct and easy way of having a presence on the internet.

2026-09-06 13:29:28 CEST

- reply

それ、Inkan でほぼそのまま作っていて、もう試せます。
マスターキー（アイデンティティ鍵）はコールドストレージに置いたまま、普段は別の署名鍵に委任する形です。署名鍵が漏れても失くしても、取り消して新しい鍵に委任し直せます。アイデンティティもフォロワーもそのまま。
「誰の更新を正史とするか」は、委任・取り消しの宣言をチェーンに記録して、各クライアントが同じ委任グラフを再構築する形で揃えています。まさに『秘密鍵の更新＝アイデンティティの合意形成』の発想です。
よかったら動く例です👇
#nevent1q…t4p3

2026-09-06 03:02:33 CEST

- reply

I tried coracle and the test DMs at first just wouldn't show up. They eventually started appearing.
I also tried the Linux version of 0xchat. I found the UI confusing and can't quite remember the details, but I think I never got to the point where I had DM relays connected properly. It had a sort of "bricked" feel where it didn't seem to want to connect to anything at all. This may have been an issue specifically with the Linux version, don't know.

2026-09-06 02:35:13 CEST

- reply

I've invited them and they've tried, made a post or two, and then gave up. I think they don't feel the need to put things online. I kind of agree with them, but I made a conscious decision that I should have a web presence.

2026-09-05 09:26:32 CEST

Curious what it feels like to use a Nostr identity that survives a leaked key?
https://image.nostr.build/450933da906a6ff4a48825cae961550c94e7fa0279e55c0dde0a628440d4577d.jpg
Get an Inkan toy identity and find out. It takes a minute and a few clicks in your browser, and you get the whole setup of a real Inkan identity, as a throwaway sample you can play with: a master key you can transfer to cold storage, a signing key for everyday use, and a delegation chain linking them. Just open https://www.inkan.cc and hit "Get a Toy Identity."
Recording the identity on-chain costs a tiny amount in gas fees. If you'd like to try Inkan and don't hold ETH, I'm usually happy to cover it. You can make the request directly from the identity creation wizard.
Go ahead and create one, make it say hello to the other test identities walking around, or to anyone else on Nostr.

2026-09-05 07:33:12 CEST

- reply

Ok, I think I'll try the linux build, thanks!

2026-09-04 15:33:14 CEST

- reply

Thanks! I'm looking at 0xchat's website and I'm not seeing the web client. Are you sure they have one? If not I can try to install the Linux client.

2026-09-04 12:34:29 CEST

- reply

This worked well. In fact it's the only DM app I've tried so far that worked immediately. Thanks!

2026-09-04 08:00:57 CEST

Is there a NIP-17 DM app that works well and has a web client or runs on Linux?
#asknostr

2026-09-04 06:23:42 CEST

- reply

Gm☁

2026-09-04 05:32:09 CEST

- reply

I'm using my own app at https://www.inkan.cc. It's based on an older version of jumble (https://jumble.social).
If you want to try out inkan, you can find the relevant settings under Settings > General > Trust Score Filters. Or if you prefer jumble, I think they have similar settings, though I have not reviewed how these are structured in the latest version on their site.

2026-09-04 03:33:35 CEST

- reply

This was the first time I turned on my web-of-trust filter, which managed to keep that spam wave at bay.

2026-09-03 14:32:53 CEST

- reply

Still expensive, but not inconceivable. I dislike the idea of buying hardware that I can't comfortably spill coffee over.

2026-09-03 12:33:06 CEST

- reply

Ok so this talks about "large-model splits," which sounds like some kind of parallel execution across multiple machines none of which could handle the model by itself? That would be great if it works in practice. 🤨

2026-09-03 10:45:36 CEST

- reply

Same, turning on WoT took care of it for now.

2026-09-03 10:44:44 CEST

- reply

I've been getting tons of spam from primal today.

2026-09-03 10:42:51 CEST

- reply

#MeToo

2026-09-03 09:53:23 CEST

- reply

Now that's poetic.

2026-09-03 09:45:35 CEST

- reply

"opinionated software" is the term I was looking for. I probably don't like it, I prefer things to be modular, each interchangeable part tied to the actual structure of the task it's handling.
I haven't really played with AI apart from my anthropic subscription. The problem is that I don't know where to start and my head is already spinning. I did set up a couple of VMs in the way I described above, and maybe the next step would be to optimize this kind of setup for multiple VMs and automate it.
The other thing that may be worth learning is how to run a local AI. I'm still under the impression that that's not really possible with my hardware, but maybe there is something tiny that runs on my laptop and that's a little bit useful ...

2026-09-03 09:08:01 CEST

- reply

#omarchy looks pretty cool, and having an OS "for the age of agents" sounds like a good idea. But I wonder what that means concretely. Maybe something that sets easily intelligible / controllable security boundaries. Maybe something that can spin up VMs for agents with one click and lets me inspect and intercept outgoing traffic from each of them.

2026-09-03 08:34:24 CEST

Huh, reply spam wave in progress right now?
Tons of word-salad replies from fresh pubkeys ...

2026-09-03 07:09:11 CEST

You can now meet Inkan identities without logging in.
https://image.nostr.build/1aa8a4c1a6827af5fce4248a88759a1e33d2521c09ef3d99caa28ae6fce4d565.jpg
Open https://www.inkan.cc and click “Explore” in the nav bar. You’ll find a few of them there, hanging around outside the login gate.
Remember, Inkan separates your identity from your signing key.
If the signing key is leaked or lost, revoke it. Same identity. Same followers. New signing key.

2026-09-02 13:05:35 CEST

- reply

I suppose yes in principle, though not actively. I want to shepherd this to wider adoption and the focus is more on working with people who have the knowledge and motivation to be part of it, and financial incentives should play a role in that, among other things.

2026-09-02 11:41:18 CEST

- reply

Yes, you should absolutely use whatever is your regular client. 👍
Some fine print 📜 (I think you already know this):
1. You must ensure that your events get OTS-timestamped shortly after their created_at. You can do this by including wss://relay.inkan.cc among your write relays since that relay includes a timestamping service. Or alternatively you can point a timestamping service to some other relay (including your own). The point is that your events need OTS timestamps shortly after their creation. Otherwise Inkan will treat them as not having been validly "signed and dated" and will refuse to display them later.
2. You must also ensure that the OTS timestamps are periodically fetched from the timestamping service, packaged into 31045 events, and distributed to relays for storage and retrieval. The Inkan client does this automatically for you when you are logged in. So if you don't log into www.inkan.cc for a while, the timestamps for your recent events may not get distributed to relays and, being unable to find these timestamps, the Inkan client will refuse to display your events. You can correct this situation by logging into the client later and having it catch up on the retrieval and distribution of the timestamps. However, it's better practice to retrieve the timestamps from the timestamping service sooner rather than later, so that you don't have to trust the service over a long period of time to keep your timestamps safe. FYI, you can also ask *another* pubkey to perform this retrieval and distribution of the timestamps on your behalf.
3. It's good practice to periodically retrieve your own 31045 timestamp events from relays so that you can store a backup copy of the timestamps, just as you may want to store a backup copy of your regular Nostr events. The Inkan client has a menu for doing this under "Inkan Settings."
4. You can use amethyst for *posting*, but to *view* the activity of your master identity, you need to go to a delegation-aware client, currently www.inkan.cc. FYI, you no longer need to log into the client to see your identity. Just open the "Explore" menu and meta should be listed there. Or you can just click https://www.inkan.cc/users/npub1u280zakdwcv23nqpgatsmz8lw6aj22aa6gjjlx0d50lqr8m8xucq7kf93q , share that profile link with anyone, etc.

2026-09-02 09:32:04 CEST

Inkan basically works on mobile now. It's just a browser tab, nothing to install.
To log in via NIP-46, I copy-pasted the nostrconnect from Inkan's login screen into Amber. I think that's how I'll be using it on my phone going forward.
Done hunting UI bugs myself for a bit, but if something feels off let me know and I can try to fix what actually bothers people.

2026-09-01 17:21:09 CEST

Lots of updates to the Inkan client today, so anyone who's used it may want to hit ctrl+shift+R next time you visit the site. One of them automatically notifies you of future updates, but you only get that if you manually update now. 🤷‍♂

2026-08-31 17:09:10 CEST

- reply

Got it, thank you! By the way, if I don't respond to a DM in the future it's most likely because I didn't get it. In that case, you can also reach me at the email address on the inkan website.

2026-08-30 13:10:59 CEST

- reply

There's a draft NIP below👇
https://www.inkan.cc is currently the only client that implements this. It does require staying up-to-date with on-chain records of delegation and revocation. It's not trivial to implement, but probably worth thinking about over the long term.
#naddr1qv…ud8n

2026-08-30 12:52:16 CEST

- reply

Sure, the idea is that Inkan splits the key that secures your identity from the key you use for everyday signing. The identity key stays in cold storage and delegates to the hot signer.
You can see meta’s setup by logging into https://www.inkan.cc with NIP-7. It should show a welcome popup with identities you can follow, including meta’s master identity (i.e. @npub1u28…f93q). If you follow that and then open its profile, you can see its notes and interact with it.
For nostr.build, “supporting” it probably means that when someone authenticates, you check whether the key that signed the authentication is acting on behalf of a master identity, and if so attribute the login/storage account/action to that master identity. Then if the signer is later revoked and replaced, nostr.build can automatically recognize the replacement signer as acting for the same continuous identity. And when you need a historical record of actions attributable to an identity, you can use OTS to make it provable later that the action happened during a period when the on-chain delegation was live.
Here's a NIP with more detailed specs👇
#naddr1qv…ud8n

2026-08-30 02:30:28 CEST

- reply

You could try to stamp delegation and revocation declarations on BTC, but I wasn't sure if there's an easy way to look them up by participating keys, so it seemed easier to use Ethereum. As for gas prices, I just looked up a series of transactions recording a 3-key delegation chain, and it came to about 518k gas in total.

2026-08-29 15:56:40 CEST

Curious what it feels like to use a Nostr identity that survives a leaked key?
https://image.nostr.build/7e6255e269eb1237ae6d7f38114fca59decae9de3e9f353f5345de20eb717653.jpg
Get an Inkan toy identity and find out. It takes a minute and a few clicks in your browser, and you get the whole setup of a real Inkan identity, as a throwaway sample you can play with: a master key you can transfer to cold storage, a signing key for everyday use, and a delegation chain linking them. Just open https://www.inkan.cc and hit "Get a Toy Identity."
Recording the identity on-chain costs a tiny amount in gas fees. If you'd like to try Inkan and don't hold ETH, I'm usually happy to cover it. You can make the request directly from the identity creation wizard.
Go ahead and create one, make it say hello to the other test identities walking around, or to anyone else on Nostr.

2026-08-29 15:25:34 CEST

- reply

"Key delegation is a very evolving space ..."
That's one of the things people say about key delegation. Another thing they say is that delegation is pretty much impossible and will never be usefully implemented etc. 👇
My own diagnosis is that there is currently no "social proof" for the practice. That's pretty much all there is to it.
#nevent1q…flsa

2026-08-29 12:49:11 CEST

- reply

Happy to. @npub1rx0…u0mp is the signer key for meta's cold-storage identity, the identity itself is @npub1u28…f93q (longer story, for a NIP write-up see below). Regular Nostr clients only ever show the signer. To actually see the identity, its profile and posts etc., log into www.inkan.cc with your NIP-7 extension. The client should show you a welcome popup with a list of identities you can follow that includes @npub1u28…f93q, so you can follow it and then go to its profile page to see its events and interact with it.
So I think what meta wants is the mailstr address on the master identity, with everyday login staying on the signer. That should be doable, the delegation between the two keys is on-chain, you'd read it and attribute the session up. Emails sent by the identity will probably also want OTS timestamps so it's checkable the delegation was live at the time the email was sent. I haven't really dug into how mailstr, but making it delegation-aware would be a great thing.
Here are more details, and I'm always happy to explain further:
#naddr1qv…4kzh

2026-08-27 10:58:18 CEST

- reply

Thanks.

2026-08-27 09:49:20 CEST

- reply

Here it is:
https://gitlab.com/inkan_dev/inkan-management-utility/

2026-08-27 08:49:27 CEST

- reply

I've got a gitlab page which I haven't used much. The Management Utility source is currently only on the Inkan website but I can put it on gitlab, I just need to look up my login later when I get home.
https://gitlab.com/inkan_dev

2026-08-27 08:32:53 CEST

- reply

If you ever feel like pointing it at the Inkan Management Utility, please do so. It's the only place where Inkan generates / handles private keys (other than the identities created in the browser, which are advertised as "toys"). The source code for the Management Utility is available as a tar archive here:
https://www.inkan.cc/settings/inkan-management-utility
I'd obviously be very curious.

2026-08-26 11:40:54 CEST

キーが漏れても終わらないNostrアイデンティティって、実際どんな感じなのか。
それを試すための、Inkanの “Toy Identity” を作れるようにしました。
https://image.nostr.build/2879147a5140ce76af37d28d556c04cad13624a319d7fd34c1f580fafea65f56.jpg
実際のInkanアイデンティティと同じ構成を、ブラウザ上で試せます。
マスターキー、署名用キー、委任チェーンまで含まれています。
作成は www.inkan.cc の「Get a Toy Identity」から。
オンチェーン記録には、ETH建てのごく少額のガス代がかかります。
ETHがなくても、試してみたい方にはこちらで負担できることが多いです。
作成画面からリクエストできます。
作ったら、他のテスト用アイデンティティに挨拶させてみてください。

2026-08-24 12:45:19 CEST

- reply

So authentic.

2026-08-24 12:26:20 CEST

- reply

I only know about it because I used to live in Austin. It's "Tito Beveridge" apparently. And it looks like rakia is the spirit of the Balkans.

2026-08-24 09:17:03 CEST

Curious what it feels like to use a Nostr identity that survives a leaked key?
Get an Inkan toy identity and find out. It takes a minute and a few clicks in your browser, and you get the whole setup of a real Inkan identity, as a throwaway sample you can play with: a master key you can transfer to cold storage, a signing key for everyday use, and a delegation chain linking them. Just open https://www.inkan.cc and hit "Get a Toy Identity."
Recording the identity on-chain costs a tiny amount in gas fees. If you'd like to test Inkan or are just an early user finding your way around and don't hold ETH, I'm usually happy to cover it. Just reach out.
If you have any questions or want a hand with the making the identity, I'm glad to help. If you decide to create one, you can make it wander around with the other test identities and say hello to them, or anyone else on Nostr.
https://image.nostr.build/0119452dff40f8253e5025e14b2e06b9d54141879ae398f74f36da0e4b20330c.jpg

2026-08-22 03:51:45 CEST

So I've been wanting to publish arbitrary events from my client.
This came up recently when I tried to post a 30817 draft NIP and at first couldn't find a place that handles that kind. Also I often want to post events with similar content to events I posted earlier, for example to update addressable events, or to post something from an old key re-signed by my current key. And sometimes there are events generated by other clients that I *almost* like but want to modify in some way, e.g. by removing their client tag.
So I gave my Post window in Inkan a raw JSON mode. One thing I especially like is that I can paste an event that was generated somewhere else and may have been previously signed, edit it, hit a "Normalize" button which strips out the old id, pubkey, sig, and created_at, see exactly what I'll sign, and be told if the JSON is off. Clicking "Post" then publishes it to the usual outbox / inbox relays.
Very useful.

2026-08-21 12:58:09 CEST

- reply

Publishing from NostrHub doesn't seem to work, even after I set my relay list.

2026-08-21 12:56:33 CEST

- reply

Thanks, posting NIPs through NostrHub seems to be broken. I was able to publish a 30817 through your imwald client, here it is:
#nevent1q…8859

2026-08-21 06:02:01 CEST

- reply

It seems like I should run this against my codebase.

2026-08-21 03:56:04 CEST

- reply

Huh, it looks like NostrHub isn't actually surfacing the draft NIP or the link to Inkan that I published there. That would make that site unsuitable for discussing NIPs.
Maybe I should republish the NIP here as a long-form note, with markdown for better formatting ...

2026-08-20 12:51:11 CEST

A draft NIP for Inkan 👇
#nevent1q…uztd

2026-08-20 12:38:26 CEST

- reply

Done.
https://nostrhub.io/naddr1qvzqqqrcvypzp5dxzjv0fvwuym0shmx350573re4t7mpfdm3az6mya7sl7v6s23rqqskxmmvvskhxar0wfskwefdd9jx2mn5d96xjetn94nx7u3ddehhxarjnjhzrn

2026-08-19 21:42:53 CEST

- reply

Good, I'm seeing your 31045 timestamp events on the relay.
Now that the timestamps are available, the events on @npub1u28…f93q's profile page should become visible again. If you still cannot see them, let me know - I can see them on my end.
I think the reason why the toggles were disabled is that you may have logged in with your signer key before I had recorded your identity on-chain. If the client doesn't detect an on-chain identity when a key first logs in, I think it disables these toggles by default. This setting then sticks even if an on-chain identity is later detected. I should try to make this less confusing somehow.

2026-08-19 18:30:28 CEST

- reply

Thanks, that might work. I'll give it a try.

2026-08-19 17:47:44 CEST

- reply

By the way, you might be able to speed up the process of catching up on the publication of the timestamps by going to
Settings >> Inkan Settings >> Delegation & Timestamping
and on that page switch off and then immediately back on the two toggles that say
"Periodially collect timestamps info from TS Server"
and
"Periodically publish timestamps info to relays".
Switching these toggles off and back on should restart these jobs immediately (otherwise they just run periodically while you are logged in).
Another thing you can try is to switch the "Apply timestamp filter" toggle off, and then go back to the profile page of your master delegator key. I'd predict that the currently missing events will be shown because the functionality that filters out events for which no valid timestamp could be found will have been turned off. Playing with the "Apply timestamp filter" toggle and observing its effect can be useful for getting a more thorough understanding of how Inkan works.

2026-08-18 20:12:13 CEST

- reply

If you feel like it, you can even delegate from your Inkan seed key
"npub1u280zakdwcv23nqpgatsmz8lw6aj22aa6gjjlx0d50lqr8m8xucq7kf93q"
down to your usual pubkey for ngmi, i.e. down to
"npub14p7fhlz9wrlptt7a5mqqjkk79460k98r999l7dafv4fznqaa565qhjdzry"
If you did that, any future posts by your usual ngmi key will get automatically attributed to the Inkan seed key (until you revoke the delegation). If you include the Inkan relay when making your usual ngmi posts, you'll also get automatic OTS timestamps for notes you post with your ngmi key, which you can download and keep for your records.
Other people will of course be able to see your ngmi posts from any Nostr client as usual. And if they log into Inkan, they'll also be able to see your events being attributed to your Inkan seed key identity.
To create a delegation like that, you'd need to use the "Build Custom Transaction" menu in the Inkan Management Utility. You can download a Linux AppImage of the Management Utility here:
https://www.inkan.cc/settings/inkan-management-utility
The actual delegation you'd be creating would be from your current Inkan signer key to the ngmi key, extending the delegation chain down to your ngmi key.
Happy to walk you through creating this kind of transaction and sponsor it if you're interested. But no pressure, I don't mean to overwhelming, just wanted to point this out as an option.🙇

2026-08-18 19:29:54 CEST

- reply

It looks like most of my Nostr events get timestamped within 30 minutes, often faster than 15 minutes. A few take up to 45 minutes. And then there is the occasional outlier taking 2 1/2 hours. The client uses a default setting under which it considers an event "validly signed and dated" if its OTS timestamp comes within 4 hours after its created_at.

2026-08-18 17:48:18 CEST

- reply

OTS was a huge pain in getting Inkan to work reasonably fast.
At first I wanted to make it work without relay modifications, which meant that the client had, after receiving a regular event, go out a second time to check whether an OTS proof for that event was available on the relay. That led to huge bottlenecks and involved complicated caching mechanisms etc.
The solution to this was to make the relay itself return the OTS proof synchronously along with the reference event (whenever the relay stores such an OTS proof).
FYI, there is currently a small bug in the OTS implementation that can lead to interference when a pubkey decides to publish 31045 OTS proofs on behalf of *another* pubkey. I haven't gotten around to fixing this, but it shouldn't affect things with the default settings where pubkeys only publish proofs for their own events.
Your AI can explain the details of the OTS-enabled relay. I'd also be curious to see your OTS lib if you release it.

2026-08-18 17:17:34 CEST

- reply

That would explain it. The Inkan client sends the 31045 timestamp events to the Inkan relay automatically while you are logged into the client.
So when you log in the next time, you may not immediately see the regular events you posted since the client won't find their timestamps on the relay at first. However, it should catch up over time as the 31045 events are getting posted to the relay and the client can then later retrieve them. So they should become visible again after a while.
If you use another client, the important thing is to include wss://relay.inkan.cc among the relays you post to (it looks like you are doing this!). If your events don't end up on that Inkan relay soon after their created_at, they don't get timely OTS timestamps at all, which makes them forever "invalid" from Inkan's perspective.

2026-08-18 15:56:54 CEST

- reply

[Quick technical note, just FYI: I'm not currently seeing 31045 OTS timestamp events for events published by your signer pubkey on the Inkan relay. This might be because you did not allow your signer extension to sign the "31045" events that the client tried to publish. Without these OTS timestamp events being available on the relay, the events you have posted so far will get filtered out and become invisible on the Inkan client once they fall outside the recency window (i.e. soon). However, these events *have* been OTS timestamped and the timestamps are stored on the timestamping server. If you permit your client through the browser extension to publish the 31045 timestamp events in the future, the events you posted should become visible again, once the 31045 OTS timestamp events have been published.]

2026-08-18 15:21:05 CEST

- reply

Inkan actually also requires a small update to relays, which need to send OTS proofs along with the events they return. The Inkan relay uses the following reference implementation of this feature:
https://gitlab.com/inkan_dev/ots-enabled-strfry
Also, the source code for the Management Utility (i.e. the utility for airgapped creation of "non-toy" identities) is available here:
https://www.inkan.cc/settings/inkan-management-utility
Pointing an AI to these should give people a pretty good idea of what the on-chain declarations and OTS functionality look like.
Not sure if it's just a matter of SKILL or AGENTS.md ... I started working on this one and a half years ago, and even with agentic coding it's been many months of work ...

2026-08-18 14:54:03 CEST

- reply

That would also be my opinion.

2026-08-18 14:26:05 CEST

- reply

I think when you say "database," you are referring to the server that I was using with earlier versions.
I was able to get rid of that server entirely. The fetching of the delegation info is now all done directly by the client.
Also, onboarding is much easier now. There's now a button on the home page that allows users to create a throw-away toy identity directly in the browser, which makes it easy to try out (feel free to do so!).
Also, after the identity has been recorded on chain, there is now a first-login wizard that gets all the details for the identity set up automatically. The wizard includes setup of the two profiles for the signer key and the identity-securing key.
Also, you no longer need to hold ETH to create an identity. There's an option in the setup process that allows you to send me the identity creation file and I can sponsor the tiny amount of gas fees (which I'm happy to do).

2026-08-18 13:46:24 CEST

- reply

Also, you are right that there should be a NIP, but I'm finding it difficult to compress the concepts into a form that fits that schema. The following explanation is the closest I currently have:
#nevent1q…4pj3

2026-08-18 13:12:06 CEST

- reply

In any event, thanks for taking a look!
If you play with it more and have any questions or comments, let me know any time.

2026-08-18 13:09:08 CEST

- reply

Also, when you are on a delegator profile page, you can click on the green "D"s that appear on the avatars.
You will see backup data explaining the delegation relationships that that cause the event to be displayed there, and you can click through to full tables showing historical delegations.

2026-08-18 13:03:42 CEST

- reply

I don't have a NIP, but I have the following explanation. This covers pretty much all of the conceptual details:
#nevent1q…4pj3

2026-08-18 12:57:27 CEST

- reply

Yes, but I think we need some people to try out the current client to get familiar with the idea.
In the left lower corner, are you seeing the avatar of your signer key, with an overlayed avatar for the identity key?
Clicking on the overlay gets you to your permanent identity profile page.
Clicking on "profile" gets you to your signer profile page.

2026-08-18 12:54:57 CEST

- reply

Hi there.
If you rotate the signer npub, you do *not* lose the followers that attach to your identity, which is secured by:
e28ef176cd7618a8cc0147570d88ff76bb252bbdd2252f99eda3fe019f673730
Be sure to treat the profile page for this identity-securing key as the one that followers should attach to. And be sure to keep the privkey that is associated with this identity-securing key in airgapped cold storage.
This key represents the permanent "you", and it survives replacements of the signer key.

2026-08-18 12:39:58 CEST

- reply

Take a pretty close look at each step in the wizard.
Default settings should work, but be sure to create the two distinct profiles, one of the signer and one for the identity.
Let me know if everything works through the end of the wizard.