inkan

Public Key

npub16xnpfx85k8wzdhctang6860g3u64lds5kac73ddjwlg0lxdg9g3su56z6l

NIP-05 Address

Profile Code

nprofile1qqsdrfs5nr6trhpxmu97e5dra85g7d2lkc2twu0gkke8058lnx5z5gcpzpmhxue69uhkummnw3ezuamfdejszrthwden5te0dehhxtnvdakqdluz8u

Publishing to

nostr.wine

nos.lol

nostr-pub.wellorder.net

relay2.inkan.cc

relay.primal.net

relay.mostr.pub

Author Public Key

npub16xnpfx85k8wzdhctang6860g3u64lds5kac73ddjwlg0lxdg9g3su56z6l

Show more details

Last Notes

2026-09-11 10:07:33 UTC

- reply

This contains lots of em-dashes, which I always thought were the best-kept secret in writing and which I used extensively.
AI of course figured that out as well, and now you can't use them anymore ...

2026-09-11 09:39:11 UTC

- reply

Great - thanks for testing!

2026-09-10 13:25:41 UTC

- reply

These declarations need to be discoverable with 100% certainty.
For example, the client needs to be absolutely sure that it has not overlooked a revocation declaration.

2026-09-10 12:56:39 UTC

- reply

Absolutely, for recording key delegation, revocation and invalidation declarations.
I wasn't able to figure out an easy way to record these declarations on Bitcoin, but admittedly I didn't try all that hard.
The Nostr events themselves are timestamped with OTS on Bitcoin.

2026-09-10 12:35:16 UTC

- reply

It's using ethereum for recording delegation and revocation declarations, and Bitcoin for OTS-timestamping Nostr events.

2026-09-10 05:33:35 UTC

- reply

...

2026-09-10 05:13:20 UTC

- reply

This was meant to be a reply here, went out as a post:
#nevent1q…whtw

2026-09-10 05:10:38 UTC

As a heads-up, you need to make sure that all of your events get OTS timestamps *shortly* after they are created.
Currently this means that you'll need to include wss://relay.inkan.cc among your write relays (until someone else runs a relay with an attached timestamping server), and you'll then also need to make sure that your inkan client is set to periodically fetch the timestamps from the timestamping server and distristribute them as "31045" events to relays. The default Inkan settings do this for you. If you don't do this, you'll see your events disappearing on your identity profile starting about 4 hours after their creation since the client will filter them out as "not validly dated."
See below for some more discussion of this, and let me know if you have any questions. 👇
#nevent1q…x3v8

2026-09-10 04:34:09 UTC

- reply

Welcome!

2026-09-09 11:12:04 UTC

- 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 10:37:03 UTC

- 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 09:32:13 UTC

- 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 13:06:52 UTC

- 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 11:13:27 UTC

- 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:30:47 UTC

- reply

Yes, it requires OTS and ethereum.
OTS is free. Gas fees for delegations and revocations are tiny. A recent series of transactions creating a 3-key delegation chain came to about 518k gas. I think at current prices that may be less than $0.15. On-chain transactions are required only at the time of identity creation and key replacement, which is very rare.
For people who don't hold ETH or don't know what it is, they can ask a sponsor to pay on their behalf. If you'd like to try it out, I'm happy to cover the tiny amount of ETH. You can go to https://www.inkan.cc and click "Get a toy identity" to get a throwaway trial identity. On the last screen of the wizard, there's a link through which you can ask me to sponsor the transaction.
For general concerns about using Ethereum, my initial response would be this👇
#nevent1q…eyqu

2026-09-08 06:18:14 UTC

- 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 04:47:58 UTC

- 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 04:31:20 UTC

- 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 04:09:20 UTC

- reply

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

2026-09-07 19:04:10 UTC

- 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 18:49:16 UTC

- 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 18:25:17 UTC

- 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 17:53:21 UTC

- 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 17:39:18 UTC

- 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 17:34:04 UTC

- reply

👇
#nevent1q…r4gy

2026-09-07 17:31:43 UTC

- 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 16:59:41 UTC

- 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 16:44:02 UTC

- 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 16:25:56 UTC

- 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 16:12:53 UTC

- 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 16:04:28 UTC

- reply

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

2026-09-07 16:00:29 UTC

- 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 14:49:57 UTC

- 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 13:25:16 UTC

- 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 09:09:51 UTC

- 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 07:54:17 UTC

- 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 06:20:58 UTC

- reply

Looks like you've come around to something.

2026-09-07 03:12:39 UTC

- reply

That sounds like a worthwhile project.

2026-09-07 03:04:03 UTC

- 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 02:39:42 UTC

- 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 02:34:59 UTC

- 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 01:07:31 UTC

- 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 00:50:12 UTC

- 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 00:43:30 UTC

- 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 11:29:28 UTC

- reply

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

2026-09-06 01:02:33 UTC

- 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 00:35:13 UTC

- 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 08:59:58 UTC

I updated the Inkan Management Utility, the app that allows you to create identities and key delegations and revocations on an airgapped system.
The app now generates QRs that can be directly scanned by NIP-46 signers like Amber, using NIP-49 ncryptsec. This is handy when you've moving a delegatee signing keys around, just scan and it's there.
The source is available at https://gitlab.com/inkan_dev/inkan-management-utility. It's the part of Inkan that actually handles privkeys, so feel free to analyze it or point your AI at it, and let me know any issues.
There's also a Linux AppImage at https://www.inkan.cc/settings/inkan-management-utility.

2026-09-05 05:33:12 UTC

- reply

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

2026-09-04 13:33:14 UTC

- 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 10:34:29 UTC

- reply

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

2026-09-04 07:09:02 UTC

- reply

You could DM me. I think I finally figured out how to receive these with coracle.

2026-09-04 06:00:57 UTC

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

2026-09-04 04:23:42 UTC

- reply

Gm☁

2026-09-04 01:33:35 UTC

- 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 13:40:05 UTC

- reply

So maybe I could spill coffee as long as I don't hit the processor. And it looks like they are actually selling them in pairs!

2026-09-03 12:32:53 UTC

- reply

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

2026-09-03 10:33:06 UTC

- 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 08:44:44 UTC

- reply

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

2026-09-03 08:42:51 UTC

- reply

#MeToo

2026-09-03 07:53:23 UTC

- reply

Now that's poetic.

2026-09-03 07:45:35 UTC

- 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 07:08:01 UTC

- 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 06:34:24 UTC

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

2026-09-02 11:55:24 UTC

- reply

FYI, there is a draft NIP now👇
You can also go to https://www.inkan.cc and hit the "Explore" button to see these identities in action. No login required.
#naddr1qv…8zw2

2026-09-02 11:05:35 UTC

- 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 10:56:54 UTC

- reply

Not an expert, but it seems like this may make delegation and revocation declarations storable and discoverable on BTC, but it may be difficult to be sure that one has retrieved all such declarations unless one runs a full node. I haven't done any in-depth analysis, but it feels like that may be the problem with BTC.

2026-09-02 09:41:18 UTC

- 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 07:32:04 UTC

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 23:30:36 UTC

- reply

It looks like they can't quite verify that the result is correct🙂
A few years ago I tried to learn quantum computing and made it through a good amount of linear algebra before getting distracted. I'm hoping to try again with help from AI. I'd love to understand Shor's algorithm.

2026-09-01 15:21:09 UTC

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-30 11:10:59 UTC

- 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 10:52:16 UTC

- 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 00:30:28 UTC

- 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 13:56:40 UTC

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 10:49:11 UTC

- 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 07:49:20 UTC

- reply

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

2026-08-27 06:49:27 UTC

- 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 06:32:53 UTC

- 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-24 10:26:20 UTC

- 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-22 01:51:45 UTC

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 10:58:09 UTC

- reply

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

2026-08-21 10:56:33 UTC

- 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 04:02:01 UTC

- reply

It seems like I should run this against my codebase.

2026-08-21 01:56:04 UTC

- 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 10:51:11 UTC

A draft NIP for Inkan 👇
#nevent1q…uztd

2026-08-20 10:46:19 UTC

- reply

NIP-XX
Cold-Storage Identities for Nostr
draft optional
This NIP specifies online identities whose private key can be created in cold storage and stay there permanently. The key never has to touch an internet-connected device, and does not have to be kept close at hand. The identity can nonetheless be used easily for everyday online authentication, such as posting, replying, messaging, or signing in to services.
▌ 1. How it works
The identity-securing key never signs Nostr events itself. It delegates signing authority to delegatee keys, which handle the everyday signing on its behalf. If a delegatee key is lost or stolen, it is replaced, and the identity is untouched.
▌ 2. Delegations between keys
Delegations are time-indexed two-place relations. Between any two key pairs, at any moment, the first either delegates signing authority to the second or it does not. When it does, the second key is authorized to sign on the first's behalf. When it does not, the second has no such authority.
Delegations are either direct or indirect. A direct delegation arises when one key has expressly declared that it delegates signing authority to another. An indirect delegation arises because the relation is transitively closed: if X delegates to Y and Y delegates to Z, then X indirectly delegates to Z. This is what lets an identity be built as a chain (master → intermediate → signer), so that events signed by the bottom key are attributed all the way up to the master, while the master, having signed the top link once, retires to cold storage.
▌ 3. How a direct delegation is created
A direct delegation from key pair X to key pair Y is created when both key pairs sign a Declaration of Delegation of Signing Authority, by which X declares that it delegates signing authority to Y and Y declares that it accepts. The signed declaration is then recorded on-chain (the reference implementation uses Ethereum). The delegation begins at the time of the block in which the declaration was recorded, and remains in effect until it is revoked.
One special case: this holds only if neither X nor Y has previously permanently invalidated itself (§5). If either has, no delegation is created, even though the declaration sits on-chain.
As part of the declaration, X and Y also specify whether X can revoke the delegation unilaterally or whether Y's consent is required. The default is unilateral revocation by X, and it is the right default for most users: if Y's key is ever lost, X can still revoke it alone. Were Y's consent required, a lost Y could never be revoked, because Y would no longer be available to sign.
▌ 4. How a direct delegation is terminated
A direct delegation from X to Y is terminated when X signs a Declaration of Revocation of Signing Authority and records it on-chain, with Y's signature too if the original delegation required it. The delegation terminates at the time of the block in which the revocation was recorded. Everything Y signed while the delegation was in effect stays attributed to X; nothing it signs afterward does. A stolen signer therefore damages only the window between key compromise and revocation, and that window is the user's to close.
When a delegation and a revocation between the same X and Y land in the same block, the revocation is by convention treated as occurring first and the delegation thereafter. The convention is a tiebreaker for cases that block timestamps cannot order.
▌ 5. Permanent key invalidation
The third declaration is the Declaration of Permanent Invalidation of a Key Pair, signed by a key pair against itself, declaring that from then on it can no longer participate in any direct delegation, as delegator or delegatee. Once recorded on-chain, it takes effect at the time of its block. From that point, all existing direct delegations involving the key are terminated, and no new one involving it can come into existence, even if a declaration naming it is later recorded.
Its main use is invalidating a compromised master key. Such a key has no delegator above it, so ordinary revocation is unavailable; permanent invalidation lets its owner withdraw it from the system entirely.
▌ 6. Delegation timelines
A client can read the three kinds of declaration from the chain and, for any pubkey and any past moment up to the present, compute the direct delegations that pubkey was involved in at that moment. The indirect ones follow by transitive closure. So for any pubkey a client can compile a complete timeline of every direct and indirect delegation it has ever been involved in, and trace each back to the declaration that established it. Because the rules are fixed and the data is public, every client computes the same timeline, and no server has to be trusted to report it.
▌ 7. Bitcoin timestamping of events
Attribution needs an objective, auditable rule for when the signing of each event is deemed to have occurred. A self-declared created_at proves nothing on its own.
Events are anchored to Bitcoin using OpenTimestamps (OTS). An OTS proof for an event establishes that the event and its signature existed by the time of a specific Bitcoin block. An event's created_at is then treated as its objective signing time when a proof shows the event and its signature existed shortly after that time. The length of the "shortly after" window is configurable; the reference implementation defaults to four hours. Events without such a proof are treated as if they carried no valid signature at all: they are not displayed, and are attributed to no one.
A proof over the event id alone would show only that the event's contents existed by the attested block, not that anyone had yet signed them. Binding the signature into the proof as well shows that the signature itself existed by then, which is what an objective signing time requires. These proofs are published as kind 31045 events (§10).
▌ 8. Attribution of events
We now know, for any past time T and any two keys X and Y, whether X delegated (directly or indirectly) to Y at T; and for any event Y signed with both a valid signature and a valid OTS anchor, we have an objective signing time. Together these give a well-defined attribution rule:
An event E is attributed to a key X if and only if some key Y validly signed E at a time T and, as of T, X delegated signing authority to Y.
So a text note signed by a delegatee Y during a valid delegation period from X appears on X's timeline and is displayed there under X's profile, as if posted by X, even though X's own key never signed it.
▌ 9. Two profiles, one identity
You log in with your signer key and sign events with it, exactly as in any other Nostr client. Those events appear on the signer's own profile, and in addition on the profile of each of its delegators, up to your top-level identity.
You set the signer's profile by publishing a kind-0 event as usual. Separately, a signer can also set a profile for each of its current delegators, so that a top-level identity can present a face to the world without signing any event itself. This delegator-profile mechanism is kind 31065 (§10).
Your identity's profile is what you present to the world. Others should follow and interact with the identity, not with the signer beneath it. The signer is ephemeral and expected to be replaced; the identity is permanent, and is the thing followers should attach to.
▌ 10. Event kinds
This NIP defines two addressable event kinds (kinds 30000 to 39999 in NIP-01, where the latest event for a given (pubkey, kind, d-tag) replaces any earlier one).
Kind | Name | d tag | Signed by
31045 | Bitcoin timestamp | id of the referenced event | any party
31065 | Attributed profile | the delegator's pubkey | a delegatee
▌ 10.1 Kind 31045: Bitcoin timestamp
A 31045 event carries an OpenTimestamps proof for another event (§7). It is addressable by the referenced event's id, so a consumer finds the proof for an event E by querying kind 31045 with d = [E.id], whoever published it. Any valid proof for E is as good as any other, because the proof rests on Bitcoin and not on its publisher.
31045 event tags, marked (yes) if required, (no) if not:
d (yes): Id of the referenced event. The addressable key.
s (yes): Signature of the referenced event. With d, binds the proof to a signed event, not just an id.
p (no): Author pubkey of the referenced event.
b (no): Bitcoin block height of the attestation, or not_yet_available while pending.
t (no): Bitcoin block time (unix seconds), or not_yet_available while pending.
c (no): created_at of the referenced event, when known.
alt (no): NIP-31 summary, e.g. Complete Bitcoin Timestamp.
content is the base64-encoded OpenTimestamps (.ots) proof. Its leaf must commit to sha256(referenced_id || referenced_signature), the concatenation of the referenced event's 32-byte id and 64-byte signature. A consumer should verify the proof against its own view of the Bitcoin chain rather than rely on a relay having accepted it.
Only d and s, together with a verifiable content proof, are required to verify a timestamp. Every single-letter tag (d, p, s, b, t, c) is relay-indexed, so it can also serve as a query key, for example finding proofs by referenced author (p) or by anchoring block (b). b and t additionally duplicate what the proof itself attests; alt is not indexed and serves only as a NIP-31 display label.
{
"kind": 31045,
"tags": [
["d", "<referenced-event-id>"],
["p", "<referenced-event-author>"],
["s", "<referenced-event-signature>"],
["b", "<bitcoin-block-height>"],
["t", "<bitcoin-block-time>"],
["alt", "Complete Bitcoin Timestamp"],
["c", "<referenced-event-created-at>"]
],
"content": "<base64 .ots proof committing to sha256(id||sig)>"
}
▌ 10.2 Kind 31065: Attributed profile
A 31065 event is a profile for one key, published by another: how an identity that never signs anything nonetheless presents a face to the world (§9). Its d tag is the delegator's pubkey, the identity the profile describes, while the event is signed by a delegatee authorized to sign for it. The defining property is that event.pubkey, the signer, is not the subject d. A consumer must confirm, against the delegation timeline of §6, that the signer was a current delegatee of the subject before honoring the profile; one signed by a non-delegatee is ignored.
31065 event tags, marked (yes) if required:
d (yes): The subject: the delegator's pubkey.
alt (yes): The exact string Attributed profile.
content is a JSON object carrying the subject's presentation. Its kind-0-style fields (name, display_name, about, picture, banner, website, nip05, lud16) mean what they mean in NIP-01 and NIP-05. It may also carry the subject's follow list, mute list, and a map giving relay lists for the members of the identity's delegation network (the keys tied to it by delegation), so a client can present and route for the identity without a further fetch.
{
"kind": 31065,
"pubkey": "<delegatee-that-signs>",
"tags": [
["d", "<delegator-pubkey-the-profile-is-for>"],
["alt", "Attributed profile"]
],
"content": "{\"name\":\"…\",\"display_name\":\"…\",\"about\":\"…\",\"website\":\"…\",\"nip05\":\"…\",\"picture\":\"…\",\"relay_lists_by_pubkey\":{\"<pubkey>\":{\"readWriteRelays\":[[\"r\",\"<relay-url>\",\"<scope>\"]],\"favoriteRelays\":[\"<relay-url>\"],\"relaySets\":[{\"id\":\"…\",\"name\":\"…\",\"relayUrls\":[\"<relay-url>\"]}]}},\"publicly_muted_pubkey_hex_ids\":[\"<muted-pubkey>\"],\"current_snapshot_of_dir_indir_followed_pubkey\":[[\"p\",\"<followed-pubkey>\"]]}"
}
Because 31065 is addressable, the current profile for an identity is simply the latest one whose d is that identity, signed by a key that is currently its delegatee. When the signer is rotated, the new signer republishes, and the identity's face carries across the change unbroken.
▌ 11. Reference implementation
Inkan (https://www.inkan.cc) implements this specification as a working Nostr client and a cooperating relay at wss://relay.inkan.cc. Delegation, revocation, and permanent invalidation are recorded by an Ethereum contract deployed at 0x385C0A272b1f44687cb360557b25827bD7CdB7eb, which is the normative reference for the exact on-chain declaration encoding. A separate, network-disconnected "Management Utility" generates keys and signs declarations on an air-gapped machine, so a master key can be created and used to bootstrap an identity without ever touching a networked host.

2026-08-20 10:38:26 UTC

- reply

Done.
https://nostrhub.io/naddr1qvzqqqrcvypzp5dxzjv0fvwuym0shmx350573re4t7mpfdm3az6mya7sl7v6s23rqqskxmmvvskhxar0wfskwefdd9jx2mn5d96xjetn94nx7u3ddehhxarjnjhzrn

2026-08-19 19:42:53 UTC

- 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 16:30:28 UTC

- reply

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

2026-08-19 15:47:44 UTC

- 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 18:12:13 UTC

- 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 17:29:54 UTC

- 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 15:48:18 UTC

- 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 15:17:34 UTC

- 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 13:56:54 UTC

- 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 13:21:05 UTC

- 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 12:54:03 UTC

- reply

That would also be my opinion.

2026-08-18 11:46:24 UTC

- 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 11:09:08 UTC

- 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.