inkan

Public Key

npub16xnpfx85k8wzdhctang6860g3u64lds5kac73ddjwlg0lxdg9g3su56z6l

NIP-05 Address

Profile Code

nprofile1qqsdrfs5nr6trhpxmu97e5dra85g7d2lkc2twu0gkke8058lnx5z5gcpz3mhxue69uhhyetvv9ujuerpd46hxtnfduq3gamnwvaz7tmjv4kxz7fwd9hxkctw9e3kxfm7mst

Publishing to

relay.damus.io

relay.inkan.cc

Author Public Key

npub16xnpfx85k8wzdhctang6860g3u64lds5kac73ddjwlg0lxdg9g3su56z6l

Show more details

Last Notes

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 10:59:58 CEST

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 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 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 15:40:05 CEST

- 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 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 13:57:05 CEST

- reply

Happily my client had this. Turned it on for the first time today.

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:55:24 CEST

- 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 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 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-25 09:30:08 CEST

- reply

Oh, as it happens I've also been investigating DMs over the last couple of days.
It seems like Nostr should be able to handle a double ratchet. If one can get comfortable with the initial handshake 's potentially taking some time (depending on the parties' response time to the each required step), it seems that the channel can be established without leaking a lot of information. All that needs to become public is that someone anonymous requested establishing a channel with the recipient. With the right sort of design, even if the recipient's privkey is later compromised, the identity of the requester will nonetheless stay private.
I may try to prototype something along these lines.

2026-08-24 12:14:35 CEST

- reply

I love writing with AI because it's so smart, you just have to keep in mind that it doesn't make for good ad copy. To sell something you'll want to strip out the em-dashes, add typos, and whatever puts a human face on things. It's like "Tito's Handmade Vodka" or the Quaker Oats logo, brands have been doing this for centuries.

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-19 17:36:39 CEST

- reply

I think that's most likely the issue I pointed out in the note below.
You have probably been posting from a client other than https://www.inkan.cc, which means that you didn't automatically publish 31045 OTS timestamps for your events to the Inkan relay (only the Inkan client takes care of this automatic publication). This means that Inkan now cannot find these timestamps for your events on the relay and thus treats your events as invalid.
You should be able to correct this by logging into the Inkan client and making sure that your signer extension approves the signing of 31045 events. You should then probably stay logged in for some time since the client's catching up on the publication of the missing events might take a while. The timestamps for your events exist on the timestamping server, your Inkan client just needs to catch up with publishing them to the relay as 31045 events.
#nevent1q…w0fn

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.

2026-08-18 12:37:20 CEST

- reply

Ok, your identity should be on-chain now.
The following is your signer pubkey (i.e. put the privkey that is associated with this pubkey into the NIP-07 browser extension before logging in):
199f12c94fe6a2903908c46efcb91190d9993b7380886c98321b59c513dca973
And this should be your identity-securing pubkey (keep the privkey that is associated with this pubkey completely airgapped):
e28ef176cd7618a8cc0147570d88ff76bb252bbdd2252f99eda3fe019f673730
After logging in with the signer pubkey through NIP-7, there should be a welcome wizard.
Be sure to create distinct profiles with different profile pictures for (i) the signer pubkey and (ii) the identity securing pubkey.
You'll want to be able to tell these two profiles apart.
If you get stuck anywhere, let me know.

2026-08-18 12:14:13 CEST

- reply

It works best on a laptop / desktop with NIP-7 browser extension. NIP-46 seems to work as well, but I haven't tested extensively. It's not optimized for mobile. Feel free to ask any questions anytime.

2026-08-18 11:59:05 CEST

- reply

You may be interested in this discussion with @npub1t6j…ksrw. He pointed out that verification of OTS proofs can be very fast, which turned out to be true.👇
#nevent1q…5n9v

2026-08-18 11:35:22 CEST

- reply

I'm not really an expert on crypto, I just used blockchains for this project. That said, the self-custody / sovereignty portions of the document make sense to me. For some of the claims, I'm not familiar enough with the particular properties of Bitcoin in particular to fully evaluate these claims, although they seem plausible to me at first glance. The document does read overwritten in the way AI slop often is, which doesn't necessarily make it incorrect.

2026-08-18 10:28:53 CEST

- reply

Agreed. If you're interested, please feel free to try it out and play around with it, for example by making a throw-away "toy identity" on the homepage. I'm happy to sponsor the tiny bit of gas fees for the identity creation for people who'd like to give it a try. Also always happy to answer questions.

2026-08-17 13:09:53 CEST

- reply

This is it. I'm seeing it only on nos.lol - can you see it?
#nevent1q…63ey

2026-08-17 09:21:58 CEST

- reply

AT Proto の方は詳しくないので踏み込みませんが、「こうなると Nostr でアカウントの秘密鍵が漏洩した場合と変わらない」と書かれていた点、まさにそこを Inkan で解決しようとしています。
アイデンティティと署名用キーを分けて、マスターキーはコールドストレージに置いたまま、普段は署名用キーを使います。署名用キーが漏れたり失われたりしても、取り消して新しいキーに委任できます。アイデンティティとフォロワーはそのまま。
#nevent1q…r4gy

2026-08-17 08:21:47 CEST

- reply

It's delegation, but it's quite different from NIP-26.
Here is an explanation of how it works:
#nevent1q…2h4t

2026-08-17 08:08:13 CEST

- reply

Nostr identity is already being fixed👇
#nevent1q…x5u8

2026-08-17 08:00:52 CEST

- reply

FYI, what you are asking for exists. Unfortunately mainstream Nostr developers are actively ignoring it, so there is no adoption and almost no discussion:
#nevent1q…x5u8

2026-08-17 07:00:58 CEST

- reply

Now👇
#nevent1q…x5u8

2026-08-17 06:50:18 CEST

- reply

Wait, I've been doing delegated signing with Inkan for months now. It's entirely practical, and I wouldn't want to use Nostr without it.
Setting up the initial delegations in an airgapped environment takes some ceremony, but once that's done it's really easy to use.
I've also added a"Toy identity" option for people who want to create a quick throw-away identity in their browser, just to try it out.
See below 👇
#nevent1q…x5u8

2026-08-17 06:24:56 CEST

- reply

A bit late to respond, but here is a working key delegation system👇
#nevent1q…jke9

2026-08-17 05:38:09 CEST

- reply

Take a look at this 👇
#nevent1q…jke9

2026-08-17 05:18:08 CEST

Inkan separates your identity from your signing key.
If the signing key is leaked or lost, revoke it. Switch to a new one. Same identity. Same followers. New signing key.
The prototype is here:
https://www.inkan.cc
https://image.nostr.build/608f4ae4b060e62ec87b46ef2848e6928df23993805b81e9f37c461e5a18c4a0.jpg
Let me know any questions.

2026-08-17 05:05:28 CEST

- reply

"Your nsec is doing two jobs it should never do simultaneously: it is your permanent identity and your active signing key at the same time, stored in one place, with no separation between them."
That is exactly right. And separating those two is *precisely* what Inkan does: your identity stays in a cold storage master key, and you get a separate signing key can be revoked and replaced. 👇
#nevent1q…jke9

2026-08-17 00:45:37 CEST

- reply

There is no nip, but I wrote up this explanation of how it works 👇
#nevent1q…2h4t

2026-08-16 13:33:40 CEST

- reply

I think this is relevant 👇
#nevent1q…r4gy

2026-08-16 13:12:10 CEST

- reply

Just came across this thread. I've been using a key delegation / rotation system at Inkan for a few months.
It requires a bespoke client that can reconstruct the delegation graph from on-chain declarations. Relays don't need any delegation / permission logic. The only relay-side change is a small addition, namely the ability to return OTS proofs along with the events so client can verify Bitcoin timestamps.
It's all implemented and working pretty well on Inkan today. I usually use it with NIP-7, but NIP-46 / Amber also seems to work fine.
#nevent1q…x5u8

2026-08-16 12:22:01 CEST

- reply

はい、そうなんです。委任ネットワークへの展開はクライアント側の実装が必要で、今のところ対応しているのは inkan.cc（Jumble のフォーク）だけです。

2026-08-16 12:10:30 CEST

- reply

「委任ネットワーク（delegation network）」というのがあって、あるpubkeyが署名権限を別のキーに委任したり、あとでそれを失効（取り消し）したりすると、その宣言が Ethereum のコントラクトに記録されます。クライアントはその宣言から委任ネットワークを再構築するんです。
で、REQ を送る前に authors フィルタをそのネットワークの全キーに自動展開するので、署名キーが変わってもイベントは漏れなく取れます。

2026-08-16 11:37:41 CEST

- reply

あります👇
#nevent1q…r4gy

2026-08-16 11:19:09 CEST

- reply

「nsec を無くしたら終わり、漏らしても終わり」というの、Inkanでは当てはまらなくなります。
アイデンティティと署名用キーを分けていて、マスターキーはコールドストレージに保管したまま、普段は署名用キーを使います。署名用キーを失くしたり漏らしたりしても、取り消して新しいキーに委任できます。アイデンティティもフォロワーもそのままです。
#nevent1q…r4gy

2026-08-16 10:59:55 CEST

- reply

There's NIP-26, which doesn't work at all.
However, I've prototyped a key rotation system with Inkan. A master key is kept in cold storage and delegates signing authority down to an everyday signing key. If that signing key leaks or is lost, you revoke it and re-delegate to a new one, keeping the same identity and followers. I've been using Inkan for several months and it's working well.
See below for more explanation.
#nevent1q…x5u8
#nevent1q…2h4t

2026-08-16 10:23:04 CEST

- reply

まさにそのためのプロトタイプを作っています。
Inkanでは、マスターキーをコールドストレージに置いたまま、普段は別の署名用キーを使えます。署名用キーが漏れたり失われたりしても、取り消して新しいキーに委任できます。
アイデンティティとフォロワーはそのまま。
#nevent1q…r4gy

2026-08-15 12:13:16 CEST

- reply

Thanks for organizing!

2026-07-30 10:53:44 CEST

- reply

I took a look and decided that I don't want to generate the quantum-proof key pairs on a networked machine. It looks like there is an offline path available in principle, but it seems like the key generation functionality is currently a bit entangled with the Nostr event signing functionality.
It would be nice if the key generation could be done airgapped, the unsigned Nostr event then transported to a networked device, and the event then be signed as usual (e.g. with nak or a browser extension).
I was facing a somewhat similar situation with Inkan and started using the following de-networked version of Tails for key pair generation. As a word of caution, this is just a working proof of concept and it has not been audited or anything like that, but it may be useful as a model:
https://gitlab.com/inkan_dev/inkan-offline-live

2026-07-30 10:02:02 CEST

- reply

This is interesting. I think I may want to combine this with the Inkan key rotation / replacement system, which incidentally also records identity-defining declarations on-chain and provides similar OTS timestamping for all of a user's regular Nostr events.
I guess that, for quantum-proof key pairs to get associated with an Inkan identity, it's enough if the current signer key pair signs the quantum pubkeys. Through delegation, the quantum keys will then be automatically attributed to the master key that secures the Inkan identity, and can then be interpreted as a continuation of that master key.
Let me take a closer look at this, it seems to be a nice fit for getting Inkan identities prepared for a potential post-quantum scenario.

2026-07-29 16:41:06 CEST

- reply

Thanks, that's good to hear. I was most likely going to see it anyway.

2026-07-29 12:15:55 CEST

- reply

I'm assuming it's a bad movie? I was bored out of my mind by Oppenheimer.

2026-07-29 06:55:31 CEST

- reply

observers are sceptical ...

2026-07-29 05:47:12 CEST

- reply

"I understand, but you run into the same issue the moment your master key is compromised."
If you pay attention to the handling of the master key, it's quite unlikely that it will get compromised. You can create it on an airgapped system and then store multiple encrypted copies on, for example, 5 (or more) USB drives. You can store these USB drives in different secure locations, like a bank deposit box, a personal safe, or somewhere in your basement. You don't have to keep the master key close at hand since you will most likely never have to access it again after its creation (replacement of signing keys can be done using intermediary keys in the delegation chain, so you don't need to access the master key to perform signing key rotations).
"... intepertation complexity/demands."
The "interpretation complexity" can mostly be automated away. The Inkan client represents a prototype for how to do this. For the most part, the complexity has to be dealt with by the developer, not the end user. There is some residual complexity that the end user has to handle, mostly relating to the key creation and key replacement ceremonies. Basically, end users must learn to set aside 30 minutes to focus on the steps for key creation and replacement, and to use an airgapped device for that. This will feel like a huge bother and annoyance to people who are not used to it and where there is not yet social proof for the practice. But it is in itself easier to get used to than, say, driving a car, doing long division, or going to the gym.
When people complain about "complexity", one should distinguish "This looks like a headache to implement" from "This will be a headache to use". The first may be true to some extent, but it just reflects developer laziness ("I don't want to have to code this" is not really a convincing argument against a perfectly feasible protocol, and lots of commercially successful software implements far more complex methods). The headache-to-use point isn't actually true and it's being conflated with "I'm currently not accustomed to this and why should I be doing it when noone else is?" Again, I think the main challenge here is to get social proof for the practice and, and once that's been done, people will be less prone to confuse "I'm not currently used to this" with "This is difficult to use."
"... a president or something ..."
Nah, this feels like saying that only the clergy needs to learn how to read, what use could a peasant have for such skills. And this is much easier than reading.
"1: don't believe there will be one scheme that manages universal addoption. ... i deem 1 to be self-explanatory"
This isn't self-explanatory at all, in fact I think it's probably false. The reason it currently *feels* self-explanatory is, I think, again that there is not yet social proof for the practice. It's a bit like saying in the late 1970s that, at some point, there will be a personal computer in every home.
"... all (rigid formal) defenses like this that you implement turn against you and benefit the attacker the moment an attacker succeeds in penetrating them. If the running assumption is 'this master key is truth/my guiding star the moment there is appearent chaos', and that assumption is invalid, you just increased the problem."
I think it's preferable to put up better defenses rather than worse ones, especially if it's easy to do so. I wouldn't say that the master key is a "guiding star." But having a master key that you can expect with some confidence to keep over the long term may incentivize some people to invest more seriously in building online personas with large followings (e.g. 1 million followers) that attach to that key. The key will make these followers portable across the internet. Of course, there is still a risk of loss either due to compromise of the offline master key, or due to flaws in the implementation or in the underlying cryptographic algorithms. But this risk will be smaller than it is with the available alternatives, and that differential may persuade people that investing in an online persona is worth their time.
"If all you can do is extend what is ultimately the same problem ..."
It's not an extension of the same problem. The difference is that you can reasonably have *far* greater confidence in the integrity of a key that has never touched a networked computer. With proper precautions, you can have a very high degree of confidence that the device you used for key creation could not connect to the internet, and that the key you created has therefore not been leaked. You cannot, as a matter of principle, have any comparable amount of confidence that keys which sit "hot" on an internet-connected device have not been leaked. In other words, "ensuring that device X is properly airgapped and cannot connect to the internet" is a very different type of problem than "ensuring that key X, which sits hot on my laptop in a browser extension, doesn't get compromised." You have a great deal of control over the former, and relatively little control over the latter.
"... don't let me discourage you"
Can't be discouraged as long as the underlying math holds up. As long as there's asymmetric public key cryptography + blockchain timestamping, this type of permanent decentralized identity is far too intriguing as something that should be added to the internet's infrastructure. It sort of refocuses thinking about the internet, which is currently still conceptualized as a collection of "websites" on which users rent space and identity from platforms, to a collection of user identities that avail themselves at their own discretion of the communication infrastructure that the internet furnishes to them.