inkan

Public Key

npub16xnpfx85k8wzdhctang6860g3u64lds5kac73ddjwlg0lxdg9g3su56z6l

NIP-05 Address

Profile Code

nprofile1qqsdrfs5nr6trhpxmu97e5dra85g7d2lkc2twu0gkke8058lnx5z5gcpzpmhxue69uhkummnw3ezuamfdejsz9rhwden5te0wfjkccte9ejxzmt4wvhxjmczptt69

Publishing to

nostr.wine

relay.damus.io

Author Public Key

npub16xnpfx85k8wzdhctang6860g3u64lds5kac73ddjwlg0lxdg9g3su56z6l

Show more details

Last Notes

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

- 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 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 11:57:05 UTC

- reply

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

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:45:36 UTC

- reply

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

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

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

- 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 18:19:22 UTC

- reply

I updated the client a few minutes ago. You may want to log out, do ctrl+shift+R (or the equivalent for your device) to load the new version, and log in again.
You might also want to check, under "Settings > Inkan Settings > Delegation & Timestamping", that the first five toggles are set to "Running" (the last toggle "Apply timestamp filter to all pubeys ..." should be set to "Stopped").
You can also go to "Explore" and make sure that "Tracking Delegations" is enabled for your master pubkey.
If none of this helps, I wonder what type of device you are using? Are you using NIP-7 or NIP-46? Are you maybe using your browser in "Private Mode" (Inkan doesn't work well in that case).
FYI, I can see the events in your delegator profile page on my side.

2026-08-30 17:42:19 UTC

Made an update to the client that allows you to see master identities without logging in at all. Just go to https://www.inkan.cc and click "Explore" to view a list of them. This should be especially helpful for anyone without a browser extension or remote signer.

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 11:04:04 UTC

- reply

Yes, I should add that regular uploads from the inkan client to nostr.build already work well (extremely grateful for that!). Further "supporting" it would mean to make nostr.build itself delegation-aware.

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

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

- reply

Thanks.

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-26 09:40:54 UTC

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

2026-08-25 07:30:08 UTC

- 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-25 05:53:39 UTC

Curious what it feels like to use a Nostr identity that survives a leaked key?
https://image.nostr.build/b2dc58bddf9a5364af7bf471b68250a449185eb2a9630be52901f2d269c4095e.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-24 10:45:19 UTC

- reply

So authentic.

2026-08-24 10:31:42 UTC

- reply

See, that's good ad copy.

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-24 10:14:35 UTC

- 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-22 02:05:02 UTC

- reply

Thanks, good to know. I'd been using nak, which is great but not the most convenient for this, especially since you have to specify the relays manually.

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

- reply

I had dabbled with making something similar to ColdIron as an airgapped place to create Nostr identities and sign key delegation and revocation transactions.
I didn't go about it as thoroughly as you seem to have done. I basically started with Tails OS, asked an AI to strip out network functionality, and added the Inkan Management Utility, resulting in this:
https://gitlab.com/inkan_dev/inkan-offline-live
I wonder whether the Management Utility would run inside ColdIron. I may take a closer look.

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-19 15:36:39 UTC

- 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 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 12:26:05 UTC

- 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 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:12:06 UTC

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

2026-08-18 11:03:42 UTC

- 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 10:57:27 UTC

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

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

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

- 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 10:14:13 UTC

- 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 09:59:05 UTC

- 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 09:35:22 UTC

- 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 08:28:53 UTC

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

- reply

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

2026-08-17 07:21:58 UTC

- reply

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

2026-08-17 06:21:47 UTC

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

- reply

Nostr identity is already being fixed👇
#nevent1q…x5u8

2026-08-17 06:00:52 UTC

- 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 05:00:58 UTC

- reply

Now👇
#nevent1q…x5u8

2026-08-17 04:50:18 UTC

- 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 04:24:56 UTC

- reply

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

2026-08-17 03:38:09 UTC

- reply

Take a look at this 👇
#nevent1q…jke9

2026-08-17 03:18:08 UTC

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 03:05:28 UTC

- 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-16 22:45:37 UTC

- reply

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

2026-08-16 11:33:40 UTC

- reply

I think this is relevant 👇
#nevent1q…r4gy

2026-08-16 11:12:10 UTC

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

- reply

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

2026-08-16 10:10:30 UTC

- reply

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

2026-08-16 09:37:41 UTC

- reply

あります👇
#nevent1q…r4gy

2026-08-16 09:19:09 UTC

- reply

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

2026-08-16 08:59:55 UTC

- 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 08:23:04 UTC

- reply

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