inkan

Public Key

npub16xnpfx85k8wzdhctang6860g3u64lds5kac73ddjwlg0lxdg9g3su56z6l

NIP-05 Address

Profile Code

nprofile1qqsdrfs5nr6trhpxmu97e5dra85g7d2lkc2twu0gkke8058lnx5z5gcpz3mhxue69uhhyetvv9uju6twddskutnrvvq3qamnwvaz7tmwdaehgu3wwa5kuegzequsn

Publishing to

Author Public Key

npub16xnpfx85k8wzdhctang6860g3u64lds5kac73ddjwlg0lxdg9g3su56z6l

Show more details

Last Notes

2026-05-18 16:17:58 CEST

- reply

Yes, I've been thinking about making in-browser construction of identities available as an option. There is nothing difficult about it in principle, but it sort of defeats the purpose of keeping the identity-securing keys airgapped. I may still decide to do so as a sort of toy-identity option so it becomes very easy to try it out. I first want to fortify the surrounding infrastructure, so it's more scaleable before I roll out an-easy-to-try option.

2026-05-18 14:11:31 CEST

- reply

https://www.youtube.com/watch?v=U6rzVVwvlLU

2026-05-18 13:13:07 CEST

- reply

Yes, I should get set up for zaps.
When I started on nostr a few months ago, I tried to understand how zaps work, and there were things about their implementation that I couldn't quite figure out. I decided to hold off signing up until I understood it better and then never got around to it.
#nevent1q…tfe4

2026-05-18 13:02:47 CEST

- reply

Thanks for realizing that this can work. By the way, if you'd like to try it out, you can create a test identity with the management utility (see below). You can say hello to the other three test identities and talk about the weather.
You can also wait until a less fragile version of it is available. I just realized something that should allow me to make it pretty performant soon.
#nevent1q…jz0r

2026-05-18 12:43:36 CEST

- reply

"There is no way to do cold wallets."
I've been running test identities out of a cold wallet since last November. The infrastructure around it is still fairly fragile, but it's just a run-of-the-mill software engineering problem at this point (I'm not a software engineer, so it's taking me a bit longer).

2026-05-18 12:32:25 CEST

- reply

Each regular event is signed only by a signer key and then submitted to relays only once, so there is no duplication of regular events.
It is true that an inkan personality consists of a set of multiple key pairs and each of these can in theory make its own profile. Think of it as a split personality.
In practice, you'll want to create a profile for the key pair that represents your intended identity, i.e. the one that is your permanent public face, that you want others to follow and interact with, and that you protect by keeping its keys airgapped in a safe deposit box. In addition, I also like to create a second profile for my signer key pair, just so that it's easy to recognize and handle.
I don't think that maintaining two profiles per identity amounts to spamming relays. Remember that the profile that represents your actual identity never signs or publishes anything, only your signer does.

2026-05-15 02:12:09 CEST

- reply

When I realized last year that NIP-3 didn't include the signature in the hash I just started hashing this random string '{"ID":"<hex>","sig":"<hex>"}' during experiments. I then kind of forgot about it can never changed it. The proofs that have been produced with this are just experiments, no need for these to survive.
It looks like you do this
const idBytes = hexToBytes(event.id)
const sigBytes = hexToBytes(event.sig)
const leaf = sha256(concat(idBytes, sigBytes))
which makes sense to me.
I think an event kind for indexing probably makes sense, and maybe they should be shaped like the 31045s I've been using or something similar. Before I have a final opinion on that, I think I have to first work with relays that can verify OTS blobs and accept / update events based on OTS blobs.

2026-05-14 20:54:11 CEST

- reply

Hallo!

2026-05-14 19:54:27 CEST

- reply

I've been thinking about the proposed NIP update. It seems to me that NIP-03 should basically express a requirement on relay behavior.
Your proposed updates contemplate this in some form. If you ask me what seems most essential, I'd say that, NIP-03, as updated, should say something like this:
1. NIP-03 enabled relays should accept events whose json includes an additional "ots" blob (in addition to what gets hashed in the event_id) if the relay can either (i) verify (using its own header chain) that the blob contains a complete OTS proof that validly pertains to the reference event (id+sig as we have been discussing) or (ii) the blob has the right internal shape for an incomplete OTS proof that validly pertains to the reference event.
2. NIP-03 enabled relays should accept **updates** to events that are already stored on the relay with updated "ots" blobs as long as (i) the relay has verified (using the relay's own header chain) that the updated ots blob contains a complete OTS proof that validly pertains to the reference event and (ii) the ots blob contains *better* information than the previous ots blob (where "better" means either that the proof is upgraded from incomplete to complete, or that the lowest block height in the new proof is lower than the lowest block height in the previous proof). The updated event, if accepted, should replace the original event on the relay.
I think that's basically the behavior that we need from relays. This seems possible if, as you say, verification is easy.
One can then have additional helper event types like your 1041 or my current 31045s, but these would play a secondary role. The changes on relay behavior would be the fundamental improvement to the protocol.

2026-05-14 17:34:40 CEST

- reply

I'm not sure I'm following. Why would key rotation require you to reveal an old key that wasn't revealed before?
I'd think of key rotation as the user announcing that, from now on, they won't use key pair X for signing events but will instead use key pair Y. In doing so, no old keys are revealed to anyone. The old private key isn't revealed, and the old public key was already public prior to the key rotation, so it's not newly "revealed" either.
Maybe you mean something different by "key rotation"?

2026-05-14 15:36:56 CEST

For anyone curious to try the Inkan prototype, here's roughly what's involved in setting up an identity:
1. Get the Inkan Management Utility (a Linux AppImage):
https://www.inkan.cc/settings/inkan-management-utility
2. Run it on a current Linux system. I've tested it on Ubuntu 24.04 and Tails 7.7.2. Ideally the utility should be run on an airgapped system (I like to use Tails with networking disabled as a proxy for an airgapped machine). Once you open the utility, I suggest using the "Quick identity setup" path for your first identity; it's the most straightforward.
3. The utility will produce the chain of key pairs that make up your identity, a master at the top, one or more intermediates, and a signer at the bottom. Keep the master and intermediate keys safely offline (encrypted on a USB stick or two is fine). The signer keypair you can move to your regular online machine, since that's the key you'll use day-to-day. Once you have the signer's pubkey, send it over to me on Nostr (@npub16xn…6z6l) or to [email protected] so I can allowlist it at www.inkan.cc. Once you've been allowlisted, go on to step 4.
4. The utility also creates an Ethereum transaction that registers your identity on-chain. The easiest way to get it broadcast is via a sponsor. They cover the gas and broadcast it for you, so you don't need to hold any ETH yourself. Alternatively, you can sign and pay for it within the utility, then broadcast the signed transaction yourself.
5. Once the transaction has confirmed on Ethereum and your signer pubkey is allowlisted at www.inkan.cc, you're ready to log in. Go to www.inkan.cc, log in with NIP-07 using your signer key, and complete the setup wizard.
Reach out at any step if you get stuck or have questions, happy to help.
Also, if ETH or finding a sponsor is what's keeping you from trying Inkan, let me know. I'd like to get a sense of how much of a hurdle this is.
#nevent1q…4a2u

2026-05-14 00:02:16 CEST

- reply

Yes, that's another thing I need to get set up for ...

2026-05-13 23:30:18 CEST

- reply

No reason, just a historical accident: I had never heard of Rootstock until now. I'll keep it in mind.

2026-05-13 20:52:12 CEST

- reply

Inkan publishes key rotation to Ethereum.
OTS is not used to publish key rotation.
Does that solve the problem?

2026-05-13 20:27:54 CEST

- reply

That could be - I've never heard of DID:ION, so it would be a true re-invention!
What is the late publishing vulnerability?

2026-05-13 20:10:09 CEST

- reply

Apologies for the delay, here is something I wrote up. Happy to answer questions, comments etc. ...
#nevent1q…hpx4

2026-05-13 20:02:09 CEST

- reply

Yes, it would be great if relays could pre-filter. As I mentioned, I think this stuff is really important infrastructure. I just wrote up an explanation of my experiments with key rotation, which includes a section on the role of OTS timestamps --- see below.
#nevent1q…hpx4

2026-05-13 19:24:09 CEST

A short explainer of the Inkan identity system.
▌ What is Inkan?
Inkan enables 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 itself can nonetheless be used easily for everyday online authentication, like posting, replying, messaging, or signing in to services.
▌ How does it work?
Inkan builds on the Nostr protocol which facilitates the distribution of digitally signed content. The idea behind Inkan is that the identity-securing key never has to sign that content itself. It can delegate signing authority to delegatee keys, which handle the everyday signing on its behalf. If a delegatee key is ever lost or stolen, it can be replaced.
▌ Delegations between keys
Delegations are time-indexed two-place relations. Between any two key pairs, at any moment in time, the first key pair either delegates signing authority to the second or it doesn't. When it does, the second key is authorized to sign on the first's behalf. When it doesn't, the second key 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, on Inkan's concept of delegation, the relation is transitively closed: if X delegates to Y and Y delegates to Z, then X also indirectly delegates to Z.
▌ How is a direct delegation created?
A direct delegation from key pair X to key pair Y is created when both key pairs digitally 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 must then be recorded on-chain (Inkan 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: the above holds only if neither X nor Y has previously permanently invalidated itself. If either has, no delegation relationship is created, even though the declaration sits on-chain. (See "What is permanent key invalidation?" below.)
As part of the delegation 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. This matters most if Y's private key is ever lost: with unilateral revocation, the user can still revoke using X alone; if Y's consent is required, they cannot (since they no longer have access to Y, and thus can no longer use Y to sign the revocation declaration). For most users, unilateral revocation is recommended for this reason.
▌ How is a direct delegation terminated?
A direct delegation from key pair X to key pair Y is terminated when X digitally signs a "Declaration of Revocation of Signing Authority," by which it revokes the signing authority it had delegated to Y. If the original delegation declaration specified that Y's consent is required for revocation, Y must also sign; otherwise, X's signature alone is enough.
The signed revocation declaration must then be recorded on-chain. If it carries all required signatures, the delegation relationship terminates at the time of the block in which the declaration was recorded.
One final wrinkle: when a delegation declaration and a revocation declaration between the same X and Y land in the same Ethereum block, the revocation is by convention treated as occurring first, and the delegation as occurring thereafter. So from that block on, the delegation is in effect (assuming neither X nor Y has been permanently invalidated). The convention is just a tiebreaker for cases that block timestamps can't order.
▌ What is permanent key invalidation?
The third type of declaration in Inkan is the "Declaration of Permanent Invalidation of a Key Pair." It is signed by the key pair invalidating itself, declaring that, from then on, this key pair can no longer participate in any direct delegation relationship, either as delegator or as delegatee.
Once signed, the invalidation declaration must be recorded on-chain. It takes effect at the time of the block in which it was recorded.
From that point on, all existing direct delegations in which the invalidated key pair was delegator or delegatee are terminated, and no new direct delegations involving it can come into existence, even if a delegation declaration naming it is later recorded on-chain.
The main use is invalidating a compromised master key. Such a key has no delegator, so ordinary revocation isn't available. Permanent invalidation lets the user withdraw it from the Inkan ecosystem entirely.
▌ Delegation timelines
An Inkan-enabled client can read the three types of declarations on the blockchain and, for any given pubkey and any past moment up to the present, compute the direct delegation relationships that the pubkey was involved in at that moment. The indirect ones follow by transitive closure.
So for any pubkey, the client can compile a complete timeline showing every direct and indirect delegation relationship that pubkey has been involved in at any time, up to the present moment.
At www.inkan.cc, registered users can view such timelines for any pubkey that has been involved in delegations and trace them back to the underlying declarations recorded on-chain.
▌ Bitcoin timestamping of Nostr events
Inkan needs an objective, auditable rule for when the act of signing each Nostr event is deemed to have occurred.
To achieve this, Inkan uses OpenTimestamps (OTS) to anchor Nostr events to Bitcoin blocks. An OTS proof for an event establishes that the event and the cryptographic artifact that constitutes its "signature" existed by the time of a specific Bitcoin block.
Inkan then treats an event's 'created_at' field (the signer's self-declared timestamp) as its objective signing time if an OTS proof shows the event and its signature existed shortly after that time. The "shortly after" window is user-configurable (default: four hours). Events without such a proof are treated as if they had no valid digital signature at all, are not displayed by the client, and are not attributed to any delegator.
▌ Attribution of Nostr events
Under this framework, we know, for any past time T and any two keys X and Y, whether X delegated (directly or indirectly) signing authority to Y at T. And for any event that Y has signed, with both a valid cryptographic signature and a valid OTS anchor, we have an objective signing time, i.e. the event's 'created_at'.
Putting this together gives us the necessary ingredients for a well-defined attribution rule: an event E is attributed to key X if and only if some key Y validly signed E at time T and, as of T, X delegated signing authority to Y.
So, for example, 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.
▌ Setting up and managing an Inkan identity
Inkan provides a tool, the "Inkan Management Utility," that automates the creation of the key pairs and the delegations running through them that constitute an identity. The utility can also create key replacements and permanent invalidations. The utility runs without network access and is intended to be used on an amnesic, air-gapped system such as Tails (with networking disabled), so that nothing persists after shutdown and the master key is never exposed to a networked host. The utility is available as a Linux AppImage:
https://www.inkan.cc/settings/inkan-management-utility
Users should set up their identity by building a chain of delegations (master → intermediate(s) → signer) rather than a single master-to-signer delegation. By transitive closure, events signed by the bottom-of-chain signer are attributed to the master. Revocations only require the immediate delegator above the affected signer, so it is not necessary to keep private keys above that immediate delegator close at hand. In particular, the master, once it has signed the chain's initial top-level delegation during the identity's creation ceremony, can stay in cold storage indefinitely.
Generated key pairs can be backed up in encrypted form on USB sticks; multiple copies in separate locations are easy and recommended. Only the current signer key and the delegator immediately above that signer need to be reachable. The rest can be stored in relatively inaccessible locations.
The Ethereum gas fees required for on-chain recording of delegation, revocation and invalidation declarations can be paid by the user directly or by a sponsor. Sponsored payment lets a user create and manage an Inkan identity without holding ETH, and without revealing any private key information to the sponsor.
Setting up an Inkan identity takes some up-front ceremony, but ongoing use does not. The initial work is to create key pairs, sign the declarations that wire the keys into delegation relationships, and record these declarations on-chain. This is a one-time effort and is in large part automated through the management utility. After that, most of the keys can be put away and not be touched again, with only the signing key sitting "hot" on internet-connected devices for everyday signing, and the immediate delegator of the signing key kept close at hand so that it can perform key rotations if the signer is lost or compromised, or preemptively on a periodic basis.
▌ Using the client — two profiles, one identity
When using the Inkan client, you log in with your signer key and sign events with it, just as you would with any other Nostr client. These events appear on the signer's profile page (as in any other client), but in addition they also appear on the profile pages of each of its delegators, including, especially, your top-level identity.
You can set the signer's profile (avatar, banner, display name, etc.) by publishing a kind-0 event as usual. In addition, Inkan includes a mechanism by which the signer can set profiles for its current delegators. This allows your top-level identity to maintain a profile without having to sign any Nostr event itself.
Your identity's profile is what you present yourself with 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 sooner or later. The identity is expected to be permanent and is the appropriate object to which followers should attach.

2026-05-13 18:17:42 CEST

Inkan enables you to revoke and replace key pairs when your private key has been lost or stolen. You can also perform periodic key rotations preemptively. You can do all this in a decentralized manner.
That way Inkan gives you a permanent online identity that only you control, and that you can be confident you can keep over the long term.
Inkan is open for testing and comment. Let me know if you'd like to try it out.
https://image.nostr.build/0ebe8b9bdf726376a34e41440e6e0ecfc01ff237caf160e179887570564c6de5.jpg
https://image.nostr.build/6b0f164174707542c9086fc376ebc376dd1ef8d11009a8967ecc8a3168817c1c.jpg
https://image.nostr.build/6e077715355ce275c538383573dd3b8a77bd1c97dd8edc6972b242f1ebb22db4.jpg
https://image.nostr.build/f7002003e981f536bec01789875c17596f6c0eac87526a071c350480029c5827.jpg
https://image.nostr.build/3f6b865161cba71839910daa4f3c80b46c36400d5e2332ecad927b86003fcaad.jpg
https://image.nostr.build/d18f22dc45d189ace46b19a4a5ecf706fdc1b4ec4186c5878db9d0905f02aabf.jpg
https://image.nostr.build/ce3d8e4de21b3e6f252f5aedbf02dd54323a26c1992c637438fabb9b14ea7afd.jpg
https://image.nostr.build/60f8a59a68386e2f28b792b63d09729ed494ebe6caddb7f6810e3c10f48b6e82.jpg
https://image.nostr.build/55000542eb9db4794c8ec07dcdfc93fa5560633afcd754476f6809e9c4bb5ac7.jpg

2026-05-13 14:19:28 CEST

- reply

Thanks. I'll need a bit to digest, but it looks like this will be super helpful.
The ability of clients to quickly and efficiently filter out events that don't have a valid OTS timestamp (where "valid" means that they don't have an OTS timestamp that falls within a specified recency window after their created_at) should be a fundamental part of the Nostr protocol. It's about as important as the ability to filter out events that don't have a valid signature in the first place.
I'll likely have questions after I've had a chance to think about your explanation ...

2026-05-13 12:51:59 CEST

- reply

Maybe there is no problem and I just don't know how to do it as I don't know anything about blockchains or how to work with them. But I may be beginning to see what you are talking about. It seems to require having a copy of something called the "headerchain" available somewhere, sort of locally, right?

2026-05-13 08:33:09 CEST

- reply

Thanks, I'll definitely have to take a look at this. I've been using these 31045 events with the thought that these might eventually get replaced by direct verification, but I have no idea how to go about verifying these proofs in real-time.
I basically need every regular event (say k-1, k-6, k-7 etc) that comes into the web client to have a valid OTS proof, meaning that the OTS proof must have a BTC timestamp that falls within some user-set recency window after the created_at of the reference event (e.g 4 hours). Any event that doesn't have such a valid OTS proof must get filtered out and not displayed, as if it had never existed at all.
I can't just throw away anything more than 4 years old. This needs to reach back into the past indefinitely.
If there is anything I can use for this kind of OTS-based real-time filtering, I'd be very interested to hear about it.

2026-05-13 00:19:41 CEST

- reply

FYI, Inkan makes extensive use of OTS proofs. They are a central element of a key rotation system. Inkan timestamps a concatenation of event_id + signature.
I do find it useful to publish the OTS info through Nostr events. If the OTS info is signed by a known pubkey (possibly by the same pubkey that signed the reference event or one's own pubkey), this can send trust signals which make it less necessary to independently audit the OTS info, absent anything suspicious.
I also find it useful to include info about the reference event in the OTS event, in particular the reference event's pubkey, signature and created_at. Moreover, the lowest BTC block in which the proof is anchored and its timestamp should be included.
I also think that OTS events should be addressable events -- each signing pubkey should get only one opinion regarding the lowest BTC timestamp that is available for a given reference event.
I've included a sample OTS event from Inkan to illustrate the shape that I've found most useful in practice:
{
"kind": 31045,
"id": "9b5e4b154cb30ece6edc94d87c14dad8dec47cacc958227d5b21d36abfa9f6af",
"pubkey": "d1a61498f4b1dc26df0becd1a3e9e88f355fb614b771e8b5b277d0ff99a82a23",
"created_at": 1777422076,
"tags": [
[
"d",
"6cf8a174c3e1bc6cb4eda11f5b93a04413776d044c5aed006fef080f336fdfb6"
],
[
"p",
"d1a61498f4b1dc26df0becd1a3e9e88f355fb614b771e8b5b277d0ff99a82a23"
],
[
"s",
"429eb4f965e5c2d14bbdb54370e0be63c2388e29d4077d3286349ae7fc7302b61a5e506a05834acb50053908e20ed6a36ae8c09f4fd3b0cef4d9f0a6cec308cf"
],
[
"b",
"947055"
],
[
"t",
"1777400959"
],
[
"alt",
"Complete Bitcoin Timestamp"
],
[
"c",
"1777391199"
]
],
"content": "AE9wZW5UaW1lc3RhbXBzAABQcm9vZgC/ieLohOiSlAEIjqT9pJouNM2LV5xdUIHPi9Zu6ah3DlaMq9GqPd2+/FPwEBzbLgerPtDTFWt/rrsP8fsI8AjH08Luv0xfnQjwIOmb09izZmrXfwDHXH6vLsaVvma8oeREeiQOLbJImkdpCPEgACuUPZl913m7H4qWT/2YhxOVlbka0KiazVt7kzXV2akI8BCF7U/JXsqU0O9VE9DPXB7HCPEg07lLgYAMs6+D2+ORmzf9/d/71YMLY+uBFGVMy+eThgcI8QRp8NZv8AiuncE7Mwzcx/8Ag9/jDS75DI4uLWh0dHBzOi8vYWxpY2UuYnRjLmNhbGVuZGFyLm9wZW50aW1lc3RhbXBzLm9yZwjwIIBZ5c9lUtDMmO7pXcINbK0MqK4Js2QHfT4K4rGbuExCCPEgChH41skC/7/FT43MICR+zkrh+fZqyDOtjBGUm5+J3u8I8CBlagb7N54NttzgBMPxChcSw24B53EEvBvOxt9bcCZAvAjxIBOI7rPbgMnzwbX5UJT9S4IOirX19BPU04e0ezzwciOfCPEgXTMEQ0icWDuAylKEW4Ivavdci/YAWIEv0SQ0HFf8s/8I8SAYqkXh8NU36+YUesLH4g+TZvEKML2qGJuGX12mysWbxAjwICUOb2N4RDtZPvVUQc8OzhJK3nfWKDkqpSMqLyNWKNYuCPAg1Ul7hArE1q+Tm+9DMh4ob4eddklRRzS9vbRe3S/m+LoI8CBB7WZXGAgPrgdPZajtwHqp4shCiRNdLuuqltdwlytvWQjxIA6SEUIReSAFC2lA/fG22ZHsshjG9wDl0e/Vep/w1ZOnCPAgIyzpQHNa8zyJuTq+7/rOc4/s5oSpnFAD0IVnN3t/q70I8CA5WvfpGvzFYuUuP2LeJXNQRyfpOo4KEImq6E1dYmTmsAjwIBZmjRHxHAIzBRHOK0rQdxB05gCyphpM5brZAX1jjUKCCPAgeKPdBwpp9OLqYuovrcr0AS0bpnvvbFMGLD65yW0HMQEI8VkBAAAAAeVW0FXcs6j9W7UDf0nGA5i9VbQgUNcNxz9s4oOT1oBzAAAAAAD+////Ato7AAAAAAAAFgAUOcSOFLmE5Y5EAImKTk3+0fLTg74AAAAAAAAAACJqIPAEbnMOAAgI8CC6wj6NCPQhynQQaP7HQ6HVFBJTjOgO668bU/C/DJdSmAgI8SCBtYeuXSbsPZ4/aKAg7H8HP6Oh6jaqWYUNUF7FDeV1nwgI8CCZkFEui2Dkh95uFfC53qJnx70m1m4oWubWoWKQQ3aGoAgI8SCCoAOlqcfh5VCJYa+qgkh+EhMT8vjbwWhgjrkH3B4GYwgI8SBoOHnDQvSjamiihpyFRDSnrQ2bjIQqR3JIPjk/+3RWLwgI8SAMoPz2gaKaiCf5CMaYcnz2YRZUXnW/ZtNs0LUKEUcjoAgI8CCIn0U6v7sfmjXH42/9RTgcx7YCOrjS9KcBA6KzK51eBggI8CCDFzGJB3m8HFbI0gbGHAMP5awZJhaSujZ9ipyHD1ExDAgI8CCgoGzBbt5C6fWHxYgE3VbvywUE/slwVJjaoI0uYBJhQggI8CCtSTgUbBKvsVRpwvs0f7RpLiROko8EnX1eNZiVKVIrJggI8CBNZ2rcpTevhVy4Y5WrBXrmWfDB1QgllPr9J+Mmh/VvUwgI8SAqFoRrrr2B+iAuhkx2PrFC+6la03Z/wFOfYlu1aRCGoggIAAWIlg1z1xkBA+/mOQ==",
"sig": "7a7a57afba9ec2417e07604e41f63e657472e82ffad66e4f632c6ca954b67dba184c5100faf207e7b36f5f61852409d79f8980006f557f208a89fee59a8b117e"
}

2026-05-09 20:41:47 CEST

- reply

It's also about $23 per adult female. Just saying.

2026-04-28 17:52:54 CEST

This is Markus. And that's my pubkey:
0x047f2c82d6cc1b2d500071a9d426e6c9873ae51a9a774e52ee61b180e49bfa6fecfb9d108e7d0595c1adeea23cf41dfbd069b654310e57e4f82e533c934020a333

2026-04-28 17:46:39 CEST

Hey everyone.

2026-04-21 08:57:17 CEST

- reply

I agree we are at the stage where I should write up a proper explanation of what I've done so far. I'll work on that.

2026-04-20 14:12:47 CEST

- reply

This sounds like it could turn away tens of thousands of potential Nostr users who'd have liked to use Nostr primarily for vibe coding. I mean if they decided to take this advice.

2026-04-19 15:37:02 CEST

Question for all Ethereum enthusiasts around here:
Say you have a smart contract to which users can submit transactions for which they have to pay gas fees. You'd like to offer them the service of paying these gas fees on their behalf so they don't have to go go through the trouble of having to get their own ETH. But it's also important that msg.sender always be the address of the privkey with which the user signed the underlying transaction (rather than say the address of the payor). Is there an (easy?) way to do this?
#ethereum

2026-04-19 11:31:52 CEST

- reply

I spent nearly ten years in Austin in total. Also three years in Annapolis. Small world.

2026-04-19 10:52:47 CEST

- reply

Didn't know. I did grad school in Austin.

2026-04-17 21:51:10 CEST

You don't need key signing parties to bind pubkeys to their owners. What you need are pubkeys that have an association with their owners which remains stable over the long term.
That's because, given enough time, you'll always have plenty of opportunity to observe all kinds of cues and signals that will tell you who is behind a pubkey, at least to the extent to which the owner wants to reveal that information to you.
For example, over time you'll be able to tell whether the owner is a bot or a human, what their interests are, their writing style, what communities they are part of etc. And if they want you to know their name or other "personally identifiable information," there will be almost always be easy mechanisms by which they can convince you that they are who they say they are.
It seems very unlilely that AI's ability to impersonate will change this, either now or in the future.

2026-04-16 10:23:43 CEST

- reply

They could send me an email at [email protected] or just reply on this thread if they prefer. It's about turning the prototype at www.inkan.cc into something that runs well (if they want to take a look at the current version, I can put their pubkey on the allowlist for the identity features). If they think they may be interested, I'm happy to discuss with them.

2026-04-15 23:21:55 CEST

- reply

In principle yes if there is a very good fit.

2026-04-15 16:35:03 CEST

- reply

Back when I dabbled in the philosophy of mind, I was pretty open to the idea of machines developing consciousness. The philosophical arguments for that seemed fairly strong.
But now that AI has actually arrived, I just can't bring myself to to believe at all that I'm dealing with anything conscious here. They just don't seem to have the right internal structure.
"empty inside" is a bit strong, though, there is a lot going on inside an LLM.

2026-04-15 15:23:14 CEST

- reply

"smells like fancy llm talkbto me"
That's probably because I express myself like LLMs, always have. They've been diluting my brand.

2026-04-15 14:50:02 CEST

- reply

I was thinking about this just a few weeks ago.
I've been trying to build on the Nostr protocol, and the primary engineering challenge has been to make various types of data available in the right places at the right times, including preferably the ability to anticipate when and where such data will be needed so that it can be pre-fetched.
So I've been struggling with that challenge in a sort of amateurish way, I mean the challenge of searching for and pre-fecthing data "intelligently" as I put it to myself. And I've actually been considering hiring professional developers , maybe computer scientists, who have experience with things like "distributed systems" or "caching," except that I don't really know how to find / identify people who have the required depth of knowlegde and experience.
And then I realized that my attempts to build deterministic and inflexible methods for caching "intelligently" (!) really pointed to a perfect use case for AI. It seems like precisely the type of job that an AI agent should be performing.

2026-04-15 12:45:01 CEST

- reply

Inkan allows users to record the following types of declarations on Ethereum:
(i) Declarations of delegation of signing authority, whereby a pubkey declares that it delegates signing authority to another pubkey;
(ii) Declarations of revocation of signing authority, whereby a pubkey declares that it revokes signing authority from another pubkey.
The reason a blockchain is needed for this is that these declarations must be given objectively verifiable placement in time.
In principle any old blockchain will do, but I couldn't think of a straightforward way to do it on Bitcoin. It's not enough to simply record a hash of the declaration. The actual content of the declaration needs to be easily retrievable from the chain, and it seemed easiest to implement this on Ethereum, at least for prototyping.
See below for some screenshots from Inkan. The fourth screenshot gives you an idea of what these declarations look like, and the second and third one give you some hints as to how Inkan uses them to attribute events signed by delegatee keys to delegator keys.
#nevent1q…dv3r

2026-04-15 11:21:32 CEST

- reply

Inkan uses ETH to enable a Nostr key rotation / replacement system.
It's not gambling. As for degeneracy, the jury is still out on that one.

2026-04-14 01:21:55 CEST

- reply

Sent test mail to myself. Shows up in Sent folder but not getting delivered.

2026-04-14 00:56:19 CEST

- reply

Thanks. I took a look and nothing seems to be amiss at first glance. My experience with similar-looking websites has been that something ends up not working, maybe some location or KYC requirement, or some unexplained hang-up during funding. So I feel sceptical, but that may be unfair to this particular service. I'd have to try it out, which I may do. One has to work up enough trust to cover the period between funding and self-custody.

2026-04-14 00:33:47 CEST

- reply

I don't know how to acquire bitcoin (or any other cryptocurrency) except through exchanges. And yes, it's a huge pain and the entire experience feels pretty fishy and unreliable. And then there are holding periods before you can move funds into self custody, which introduces clearing / counterparty risks.

2026-04-13 20:42:01 CEST

- reply

That won't work reliably if you have, say, 800,000 followers.
You'll face a situation a bit similar to someone who has built a following of that size on X and has to, for whatever reason, switch to another platform.
They may be able to persuade a fraction of their followers to come with them. The size of that fraction will depend on the level of engagement they have achieved. If they have a large percentage of highly committed followers, many of these will make the switch, but if they have a high percentage of relatively passive followers with low interest or engagement, they may lose many or most of these.
It could also be compared to losing a large part of your customer / potential client / mailing list in a commercial context.

2026-04-13 12:21:24 CEST

- reply

Huh, another thing with 300 million accounts that I had never heard of.
I can see how gaining followers for your pubkey could be a powerful motivating force.
The problem is that pubkeys on Nostr are too insecure. There is too great a likelihood that your pubkey will be compromised over the years. Loss of a pubkey means that you have to rebuild your following manually, so there isn't enough incentive to invest serious effort in building very large followings.

2026-04-12 18:08:07 CEST

- reply

Weird yes. Fun not so much.

2026-04-12 17:50:37 CEST

- reply

Late to the party, but I made a prototype of a key rotation system. See below.
#nevent1q…qaud

2026-04-11 16:19:56 CEST

- reply

It's been since the year 2000 for me. If there is a tool you use many hours each day throughout much of your life, you should pay attention to what it is.

2026-04-11 14:33:48 CEST

The pubkey
@npub10uk…x0x9
has never ever signed a single Nostr event.
Yet that pubkey has recently gained its first real-life follower.
I admittedly don't know whether they'll decide to stick around or not. But it's a small milestone in the (very early) history of Inkan.

2026-04-11 13:44:28 CEST

- reply

Adversaries can now, at the present time, try to discover algorithms that break "quantum resistant" encryption. They may have already discovered such algorithms. If so, they are unlikely to advertise that fact.
But that's the same with classical cryptographic algorithms. Adversaries may have found ways to break classical encryption and may have already done so, without telling us.
I guess the difference you are pointing to is that classical algorithms are being widely used, and there is perhaps no strong evidence that the encryption on materials that have been classically encrypted has been broken on a large scale (at least not due to a fault in the algorithm itself as opposed to its implementation).
This could be because classical encryption has not been broken, or because those who broke it have taken care to not take any actions that would reveal that fact. There would certainly be plenty of incentives to not reveal it.
So I guess we sort of have reason to believe that classical encryption has successfully withstood battle-testing. Except that if it did not, there is a fairly good chance that we would not be told about it.

2026-04-11 13:17:03 CEST

- reply

"They just have been battle tested for decades, which is why we trust them."
Yes, but it seems that the battle-testing was not really meant to ensure that there are no new unknown natural phenomena which could be used to speed up the relevant computations.
Instead, it was meant to ensure that someone, somewhere, had not, unbeknownst to us, discovered mathematical methods that make these computations more efficient than we thought they could be. And maybe also to ensure that we had not made mistakes in the implementation of our own cryptographic methods.
So the battle-testing is more of a process of making informed guesses as to the mathematical tools and capabilities that others (including potential adversaries) have at their disposal. Not so much an inquiry into unknown natural phenomena.

2026-04-11 13:02:42 CEST

- reply

"With quantum resistant algorithms, we are not even sure what natural processes need to be discovered ..."
I was under the impression that we already know and have pinpointed the feature(s) of quantum phenomena that makes quantum computing possible. I thought that's why there is a mathematics of qubits etc.
In other words, I thought that physicists did not really think that there was some undiscovered universe of new and unknown quantum phenomena that could play roles in computation of an entirely different sort than those which have already been discovered and described.
I'm not deeply informed here, but that's my impression having tried to follow the discussion.

2026-04-11 12:19:29 CEST

- reply

I believe it's just math -- am I wrong?
It's a life dream of mine to learn the basics of quantum computing, maybe enough to understand Shor's algorithm. I've tried and made it through a good amount of linear algebra, bra-ket notation, etc., and then I got distracted. I hope to go back.
The reason I want to study it is that I'd like to grasp conceptually what it is about quantum computers that could lead to such a speed-up in, say, finding the prime factors of a large integer.
Is it that there is a natural process that constitutes a sort of "oracle" suggesting correct answers to problems that are normally difficult to compute?
I'm not too well-informed, but I'm currently under the impression that on the computational side it is just math, i.e. that one doesn't need to experiment to determine the computational complexity of the relevant algorithms.

2026-04-11 12:02:23 CEST

- reply

I remember how weird it was to go back to Windows when I took a corporate job. It was basically just Word, Excel and Outlook but it made the work environment feel low-grade, antiquated and non-serious. The OS that's being used has a pretty major effect on the intellectual climate and corporate culture.

2026-04-11 11:39:37 CEST

- reply

Aren't quantum resistant algorithms just math? I'd be worried if we had to "test" them to find out whether or not they work.

2026-04-11 11:20:57 CEST

- reply

This looks like a great movie.

2026-03-31 23:05:24 CEST

- reply

These express intensification, but in the case of "fuck all" it's total absence / nothingness. There's something zen about it.

2026-03-31 22:48:44 CEST

- reply

Yeah, I didn't know it could mean "absolutely nothing." Fascinating.

2026-03-31 22:42:05 CEST

- reply

Had to look that one up. Common British slang is what it says. Something new every day.

2026-03-31 22:31:52 CEST

- reply

Huh, maybe that's why I'm not finding them. I might be back in Japan for a while starting later next month, so that will put me on the inside.

2026-03-31 22:28:37 CEST

- reply

I dropped by at Nostrasia 2025 in Tokyo. Unfortunately I only caught the end of the event since I was busy earlier during the day. It seemed like they have a robust community. I follow a couple of Japanese accounts, but I selected these a bit randomly. I should explore more.

2026-03-30 09:16:29 CEST

- reply

The killer feature is the method of authentication.
But to want it, you have to know a bit about public key cryptography. Not very much, nothing that can't be grasped by say a 12-year old. But it requires a bit of habituation and a change of mental focus for most people.
It's a bit like getting people to take up Pilates, or skateboarding, or vegetarianism, or even personal computing, in a world where these things haven't entered the mainstream.
There is no immediate market for it, but it's the sort of thing where a market could at any time emerge very rapidly.
#nevent1q…4e4m

2026-03-29 17:45:40 CEST

- reply

Huh. I was under the impression that I got it to work with various filters without special setup, but I may have to investigate more closely.

2026-03-29 17:38:07 CEST

- reply

Oh, I just started learning strfry for the purpose of using negentropy. Not sure if I'm following the discussion, but are we saying that strfry doesn't correctly process the filters that are sent in neg open? Does that mean that strfry doesn't correctly implement negentropy? Confused.

2026-03-27 13:07:33 CET

- reply

Same here. There are minimum holding periods before I can move crypto I have purchased to self-custody. It's not really a problem in principle with the small amounts I'm transacting in, but there are counterparty / clearing risks that would bug me with larger amounts. Also it's annoying that I can't just buy it and use it right away. I guess I should just make sure to always keep some at hand for everyday use. Just a matter of getting organized.

2026-03-27 10:18:33 CET

- reply

Yes, I had a terrible time trying to get ETH for testing. I actually don't have any especially good way of getting BTC either. Other people seem to have better channels for acquiring cryptocurrency. When they talk about it, I always sort of wonder where they are getting it from.

2026-03-27 00:54:24 CET

- reply

Yes

2026-03-27 00:49:23 CET

- reply

Habit (Larry Fessenden)

2026-03-27 00:12:31 CET

- reply

Also if you'd ever like to take a closer look, please feel free to log in and poke around. I've put your pubkey on the allow list for the identity features, so you should be able to access these. For an initial "tour guide" please see below:
#nevent1q…lh57

2026-03-26 20:10:20 CET

- reply

Yes, you may be thinking of OpenTimestamps. And Inkan does in fact use OpenTimestamps to timestamp individual Nostr events on Bitcoin. Inkan only works when there is proof that a signed version of an event existed as of some particular time, and this proof is provided through BTC timestamping using OpenTimestamps.
However, the declarations of "delegation of signing authority" and "revocation of signing authority" that I mentioned also need to be timestamped. Unlike in the case of regular Nostr events, this timestamping needs to be done in a manner that allows you to later retrieve the substantive content of the declaration by querying the blockchain. Bitcoin timestamping does not allow for this, at least not in any straightforward way, because what's actually recorded on Bitcoin is a *hash* that is the root of a Merkle tree. And you can't extract the content of the timestamped items from that hash. Ethereum, on the other hand, has easy mechanisms for recording these "delegations of signing authority" and "revocations of signing authority" in a manner that makes their content queriable / retrievable.
So in both cases, the ultimate purpose of using blockchains is to provide timestamps. The reason Ethereum is used for delegation and revocation declarations is that Ethereum provides straightforward methods for retrieving the content of these declarations from the chain.

2026-03-26 19:01:38 CET

- reply

"I can't say I know enough of the technical stuff to know how well this can work in practice."
I made the prototype to find out. I've been using it for a few months and it works well enough for me so far.
There's tons of rough edges, but I don't currently see any insurmountable obstacles in principle. If anyone sees anything fundamentally amiss, please point it out. That will save me a lot of time.

2026-03-26 18:29:47 CET

- reply

You need some sort of blockchain. It doesn't have to be Ethereum, but it seemed easiest to implement it through a smart contract. In other words, I'm not especially wedded to Ethereum at all, I just needed a blockchain to implement a proof of concept.
The reason you need a blockchain is that there has to be a decentralized and objective way of recording the *time* at which a pubkey delegates signing authority to another pubkey / revokes signing authority from another pubkey. That's what allows you to then create an objective historical record of the periods during which a pubkey delegated signing authority to other keys. So Ethereum is basically just being used as a timestamping system.
Incidentally, Inkan also timetamps individual events on Bitcoin using OpenTimestamps. But the recording of delegation / revocation declarations is a little more complicated than the recording of regular events - it may be possible to do it on Bitcoin, but I haven't figured out how.
Once you have both (i) timestamped delegation and revocation declarations and (ii) timestamps for individual events recorded on blockchains, that gives you all the raw materials to implement the following basic idea:
If an event was signed by key pair Y at a time at which key pair X delegated signing authority to key pair Y, then the event is attributed to key pair X.
That's what Inkan does.

2026-03-26 16:48:14 CET

- reply

That's why we need a key rotation system that allows you to replace keys that have been lost or compromised. Prototype below.
#nevent1q…hqmf

2026-03-26 14:31:10 CET

- reply

Agree, I think it's using public key cryptography for authentication. That's the core of the protocol, and that's what makes it distinctive and liberating.
This feature shouldn't be played down when introducing Nostr to "normies" (whatever exactly that means), but instead it should be highlighted. We should make clear that Nostr requires a bit of learning, re-thinking and adjustment of one's practices.
It requires an effort, but once a person has made that effort they then have a sense of ownership in the new skill they have acquired. And I don't think any of this stands in the way of broad-based adoption. It's still much easier to learn to manage a key pair than, say, to learn skateboarding, or become a vegetarian. People can be quite motivated once they put their mind to something.

2026-03-26 12:51:42 CET

- reply

If the above explanations aren't sufficiently helpful, please feel free to let me know. If the product gets misunderstood due to my not explaining it properly, I'm not doing my job.

2026-03-26 12:18:42 CET

Thought I'd be preaching to the choir, but it turns out that isn't so.

2026-03-25 19:29:56 CET

- reply

I guess the attestation events can have whatever semantics I want them to have in the intended context of use. For example, if I intend the attestation event to mean "I audited the information in the reference event against what's recorded on the blockchain and the audit succeeded" or in the negative case "I audited the information in the reference event against what's recorded on the blockchain and the audit failed," then the attestation event can have these meanings.

2026-03-25 19:19:21 CET

- reply

I have a feature where the client uses only timestamp / delegation info events that were signed by "trusted pubkeys." The trusted pubkeys are settable by the user, or otherwise the client reverts to reasonable default settings.
One could maybe expand this filter to also accept events that have an attestation from a trusted pubkey, regardless of whether the event itself was signed by a trusted pubkey. And maybe also have a feature that causes the client to audit an event against the blockchain if a trusted pubkey attests that it tried to audit the event and failed.
It would be nice if the attestations can play that role - I'll take a closer look. This would obviate the need to implement "audit" events myself just for my particular use case.

2026-03-25 17:14:42 CET

- reply

I wonder whether there may be a use for these attestations in connection with the 31045 timestamp events or the 31055 delegation info events that are produced by Inkan.
When I implemented these, I was thinking of adding an event type that gives other pubkeys the ability to attest that they have confirmed the correctness of the content of the 31045 / 31055 event against what's recorded on the blockchain. I actually also thought of implementing an event type that gives other pubkeys the ability to also disconfirm the 31045 / 31055 events, i.e. to state that they tried to confirm what the 31045 / 31055 event is saying by checking the blockchain but were unable to confirm.
I ultimately decided against implementing these additional event types since it seemed to create epicycles that seemed unnecessary. Rather than attesting to the correctness of the content of the target event, it seemed easier for the auditing pubkey to simply republish that content itself. In other words, rather than publishing an event confirming that the timestamp information in a 31045 event is indeed recorded on Bitcoin, it seemed easier for the auditing pubkey to simply republish that information in its own 31045 event.
Still it feels like there may be a use for these attestations. Maybe.

2026-03-25 15:22:06 CET

What's the single most marketable feature of Nostr?
I mean the thing with the greatest potential to engage a person's attention and hold their interest, and something that is sufficiently distinctive as compared to other offerings to make them want to re-use Nostr rather than something else.
My answer: It's the practice of deliberately self-authenticating on the internet through public key cryptography on an everyday basis.
The idea of decentralization, relays, etc. are just consequences of that practice. What is basically empowering about Nostr is that it provides mechanisms for distributing content that has been deliberately authenticated by the user with a digital signature from a private key.
If that's right, then the tendency among developers to try to hide this authentication mechanism from users rather than highlight it is very unfortunate. It's hiding precisely the thing that makes Nostr interesting. It's not a good way to market something.

2026-03-25 14:04:35 CET

Took the night train through Transylvania. Just got off. The trees are all ready for spring here.

2026-03-24 17:34:25 CET

- reply

There is no official spec, but see below for some previous discussion and explanation of how it works.
I think the best way to understand it is to log in and access the identity features of the client. This allows you to observe the existing permanent identities and click through the delegation / timestamp backup data that supports these identities. I think these backup data are sort of self-documenting.
I've put your pubkey on the allow list for accessing the identity features of the client at https://www.inkan.cc. The third note below includes an initial "tour guide" that helps one get started / oriented. If you're interested, please log in and take a look, or please feel free to comment or ask questions. I'm happy to explain or talk about any aspect of it.
#nevent1q…ya9r
#nevent1q…f4cd
#nevent1q…rgs2

2026-03-24 09:47:41 CET

- reply

I just found this in your book:
"Key rotation is something that we have to figure out if Nostr is going to succeed in
the long term. There have been some proposals, but none of them have gained
enough traction to be implemented. Key rotation is an inherently difficult problem,
because you need to borrow the reputation of the old key in order to validate the
new key in such a way that an attacker wouldn't be able to do the same thing."
I wanted to let you know that Inkan implements a fully functional key rotation system. It's a prototype but it works. I've been using it for several months.
Please see below for screenshots, which contain many hints as to how it works. Happy to discuss, explain, address scepticism etc. ...
#nevent1q…dmgj

2026-03-24 07:30:36 CET

- reply

This sounds like it still requires a fair amount of supervision and micro-management.
I guess it depends on the task. At times I've been astonished by its independently solving what seemed to me complex novel conceptual tasks, and at other times it produces sort of diffuse / unfocused outputs that leave me underwhelmed.
I should probably take comfort from the fact that I seem to be needed full-time to review and give directions for it to produce something useful. That's my value add. At the same time I wonder whether the fact that I'm still so involved in the process means that I'm just using it inefficiently.
Having it work on multiple jobs at once does sound like a way to speed things up a lot. The trick is to be able to supervise these. Even with the way I'm doing it now that doesn't involve all that much multi-tasking, there's a pretty intense cognitive burden just trying to hang on and understand what is being produced and thinking of next steps.

2026-03-24 00:47:26 CET

- reply

I'd be curious about the quality of the output. In my experience so far, even when programming with AI, I have to stay constantly engaged to give instructions, review, discuss, revise, etc. Otherwise things would go in a completely different direction from where I want them to go. In other words, it remains a full-time job for me. It's hard to imagine that, in its current form, AI could independently produce something I'd really want without this constant engagement and supervision from me. But then I haven't seriously tried to use agents. So I'm curious as to the quality of the output they are capable of producing if left to their own devices.

2026-03-23 20:51:24 CET

Set up my first instance of strfry.
But I'm a bit confused about plugins.
The way plugins.md talks about "event-sifter plugins" sounds a bit as if there are are plugins *other than* event-sifter plugins. Is that so?
Or are *all* strfry plugins event-sifter plugins, i.e. that's the only type of plugin there is?

2026-03-23 20:34:54 CET

(TS Test 3-23-2026)

2026-03-23 19:58:37 CET

- reply

(... or correct the sentence in the NIP draft ...) 👾

2026-03-22 17:21:53 CET

- reply

I agree that the signature is recorded on Bitcoin in the sense of its being (together with the event_id) merkle-included in the hash that's placed in the relevant Bitcoin block. Of course you cannot re-construct the signature from the merkle root that's recorded on Bitcoin.
But the above does not explain what purpose would be served by "appending" the signature to the OTS proof.
I mean an OTS proof in human-readable form looks like the below - what would be achieved by appending the signature to that?
https://image.nostr.build/7aca480ae01ce0eaedeb0b5e767137155679cf049a2b6d12c1c30c3e9cfa1e02.jpg
https://image.nostr.build/404d82af2916e35be15da1deffa18bfb0161523c78e6a015dd037f1a828ea7fd.jpg
https://image.nostr.build/fe384e45a0ea29037d141715ce045fd681dd7498c368a4e53c2ad64244adff29.jpg
https://image.nostr.build/879b5c65a524af4031a2bb969cc0c13bb18331faa5e186abe8d8c75628408ab2.jpg

2026-03-22 15:03:48 CET

- reply

But what is the purpose of slapping the signature onto the proof?
I mean nothing further gets recorded on Bitcoin or otherwise proven by appending the signature to the proof, as far as I can see?
So why would one want to do so?

2026-03-22 14:56:24 CET

- reply

The notes below have some initial discussion of how Inkan works. The screenshots in the first note contain useful hints indicating what exactly it is doing.
I think, however, that the best way to understand it is to log in and access the identity features of the client. This allows you to observe the existing permanent identities and click through the delegation / timestamp backup data that supports these identities.
I've put your pubkey on the allow list for accessing the identity features. One of the notes below includes an initial "tour guide" that helps one get started / oriented. If you're interested, please log in and take a look, or please feel free to ask questions, express scepticism, etc. Happy to talk about anything related to it.
#nevent1q…j79t
#nevent1q…wr8s
#nevent1q…dmhu
#nevent1q…q0ge
#nevent1q…3lcs

2026-03-22 14:31:35 CET

- reply

I'm not completely following these two bits:
-- "you just add the sign to the merkle proof, extending it 1 step"
In what sense can one manually "add" a signature to a merkle proof? Not sure how this is supposed to work.
-- "The proof still resolves to the event ID"
If, as you seem to stipulte above, you "submit the hash of the id-+sig", then the proof will not resolve to the event ID. It will resolve to a hash of the id+sig. Neither the ID nor the sig can be reconstructed from that hash. However, if you already have the id+sig, you can reconstruct the hash from these.

2026-03-22 14:24:01 CET

- reply

As for this:
"Side not on that; when comparing times, the time of the original event might be later than the time of the block the proof for that event refers to, because blocktime is fuzzy, so people should take such edgecases into account."
Agree that the target event's created_at being later than the time of the block that encodes the proof is not a problem.
The only problem is if the time of the block is much later than the created_at of the target event.
In Inkan, I let users manually set the maximum permitted time differential between the created_at of the target event and the time of the block that records the event. The default setting is 4 hours. If the time differential is greater than that, the target event gets filtered out.

2026-03-22 14:18:03 CET

- reply

Actually the signature is *not* in the proof, and you can't extract it from the proof. Only a hash of a string that combines the event_id and the signature is in the proof. Including the signature in a tag is not redundant.
To verify that the proof in the content field of the OTS event is consistent with the information provided in the tags, you do need both the "d" tag for the target event ID and the "s" tag for the target event signature. Or otherwise you'll have to fetch the target event to inspect its signature, which can under some circumstances be inconvenient.
I wish I had realized these things earlier while working with these events, would have saved me a lot of hours ...

2026-03-22 13:48:45 CET

- reply

Thanks, I think including the signature will be a crucial improvement to NIP-3.
FYI, for the example 31045 event that I pasted below, here's the string that was hashed for timestamping:
{"ID":"dbe68638908a66bb601f681b5a92a41d9fd9683fb97330a1f6e7f8fe687b4277","sig":"88a9c8fa5dd283ecbd279b4fa685e52538a56023e5b156888101e3bc110df10f10e18cc50929dc26c4357b8e1508eebc0690da6159bf29882f1233e2821efd2f"}
And here is the hash that was timestamped:
17c8b1d66c0d8d28b5c774036968804cb146d45785370a94cd43360f0ae0d169
You can verify this using the OTS proof in the content field of the event. If you're interested, I'm happy to send a quick script that produces this string and the hash from a given event_id and sig pair.
In my above list of tags that I recommend be included, I had forgotten to mention one: I think an s-tag for the signature of the target event should be included as well. This is necessary to be able to verify the "internal consistency" of the OTS event without needing to fetch the target event. The 31045 sample event I sent you includes this tag.
A few further thoughts on including p-tag, c-tag, s-tag, b-tag, t-tag : While working on Inkan I was frequently running into situations where I needed timestamp information quickly without fetching the target event and without doing a verification against Bitcoin. I realized that, in some circumstances, you can make limited trust assumptions regarding OTS events that are signed by trusted keys. Often you will trust the signer of the target event already to some extent, and if the OTS event is signed by the same signer, you can tentatively trust the content of the OTS event to a certain extent. For that reason, reading info like bitcoin block and bitcoin timestamp directly from tags in the OTS event can be quite helpful in practice in certain situations. And if there are any doubts as to the correctness of that information, you can always audit it against Bitcoin.

2026-03-22 00:52:14 CET

- reply

FYI, here is an example of an OTS event that I think has a genuinely useful shape:
{"kind":31045,"id":"7093fe9f8c41bbb8164400b02602692bd231779683aed2df4015d35cf6983223","pubkey":"d1a61498f4b1dc26df0becd1a3e9e88f355fb614b771e8b5b277d0ff99a82a23","created_at":1773959239,"tags":[["d","dbe68638908a66bb601f681b5a92a41d9fd9683fb97330a1f6e7f8fe687b4277"],["p","d1a61498f4b1dc26df0becd1a3e9e88f355fb614b771e8b5b277d0ff99a82a23"],["s","88a9c8fa5dd283ecbd279b4fa685e52538a56023e5b156888101e3bc110df10f10e18cc50929dc26c4357b8e1508eebc0690da6159bf29882f1233e2821efd2f"],["b","941226"],["t","1773885646"],["alt","Complete Bitcoin Timestamp"],["c","1773869515"]],"content":"AE9wZW5UaW1lc3RhbXBzAABQcm9vZgC/ieLohOiSlAEIF8ix1mwNjSi1x3QDaWiATLFG1FeFNwqUzUM2Dwrg0WnwEJqGZ+Q8rtYicUfEAW5jkT8I8CB8KXAv2mx0tQeLRWlZbL+kbJD6Ssxx4UrsMG1JtNeVzQjwCLOXttmKfifZCPAQ9UNbNUqqIUotzkiYUwu18gjwIMb81Y7BHsiD6bU8J3rGgosReKIpWZ78B2p8g0cC6qTZCPAgtabc7DMwqS1WLAy2OSaWKkUtkg8r34CgvKwlcVwVCYsI8CCSX0Z2KX7lq/OFyrcdZ0VbVfrMXqjnDMKQe68VTfB71AjxBGm7VFrwCOfo3bNvvtLu/wCD3+MNLvkMji4taHR0cHM6Ly9hbGljZS5idGMuY2FsZW5kYXIub3BlbnRpbWVzdGFtcHMub3JnCPEg2mZxBLwldRmJuuB21O0dKjsWofBWf+iwZGTnepTJfAYI8SATG/+UVekcsl3ctl6P/WpxlgiiJzWY2hbrdphFdieFEQjxIFjLlCaepfhN+V8DLt0YR3StDhipbg2CysJ4KPXik0C8CPAg0i7rEsb2vhLM4aArpzd5/AdzZw77ohKNRrJp5k6FuZAI8CAOlXet5AnHEr0Bbj03yJEuoE2vE07KYzzN66o5gNZg+gjxIK5RQVFLDfbf4rFYEFti8w1ZuvsnXm9OHU858GQlXZ+fCPAg9yDD1lmTqLNtNF8LyEsv/4rlrTixXOGemd95xkj1SIMI8SA5qNPArCPbagMK1SZcqOlZ1DIIx4gBqODIFDkHPlFc9QjwICC4oOB2zpJV6Dld2tqfKgDty5lLKkAtv5Qp/F+Oj9pkCPAg+CotBs1A7T/29J+wx0qyk0lpKJ13o2wbKkVYq3zlDGwI8VkBAAAAAQtrFQrxPs1mMb5QvPQggkThTuO35P4Z5BmBJ0GPCSUzAAAAAAD+////AmrTAQAAAAAAFgAUKeXwHpjozmyTVzqFtvo+hN6fdJcAAAAAAAAAACJqIPAEqVwOAAgI8SDlO0E2ZEReuEAXK64wU4gCtlACyaeWh5fJIzJFEolvJwgI8CDPx2heltL2U7BGCh/fubw9ZrsMfaT7EL92dwEfR1/CrwgI8SAUUtj8gA6ZEaJbiEAQYeDTPy7utv7SR1qcSsbZw9VWmggI8CDxMRe7nTdYmw4s+5LegP2Ys79vcqzowpBwxxI7pobpBggI8CADsy2twW7hhOWeH4wOPQETd83gIgm5RA8u6B5pWJ3bUAgI8SA6LixY6ofZMVzQBV0x6bG+nVOzVK1vyhZr9ej5iazYkAgI8CC7EpcskiXBYFW53WhYjwbCBC8T9qgUFKOE/ESO0WPU6wgI8SAtfcDaUyUnguG2MSzQwMKS0ha8FpU8BoDG7hK7DqEGYQgI8SBn3y+8o3STgJYcwd3fVa2x0uqBbYlao5g3CmLCfSq/iwgI8SA2sVBmSpaKZ2NPUn+dvoZEb0olcrvxF2eTLBV8uE10KAgI8SCtSpu38MlirqgD/dQxVOlYtzGjV/VyCf6yZHINuW1BVQgI8CBBIrMQvkQOzs4H6Huhuu6aSO24eMoq6wnWqj4RDabOLwgI8CBvE1xbeLllbcHoy6YdR5HUOgh8sCDp18jJCjmROp36RQgIAAWIlg1z1xkBA6q5OQ==","sig":"2aa6c46117b27171a5aab7e72266ec603402746cea74ab83ebf467d6ad4589b629e1640b94ae55a552aed6674fd098c686d1930bca8464a68ba8ffe2cc27891b"}

2026-03-22 00:44:18 CET

- reply

If NIP-3 is going to change, the most important thing to incorporate into the updated specification is that the item that gets timestamped must include both the *event_id* and the *signature* of the target event. I think including the signature is quite crucial. See below for discussion with @npub1gzu…a5ds about this issue.
The ideal shape for an OTS event should also include something like a p-tag for the pubkey of the target event, a c-tag for the created_at time of the target event, a b-tag for the bitcoin block that anchors the timestamp, and a t-tag for the time of that bitcoin block.
I'm using OTS timestamping extensively as part of the Inkan key revocation and replacement system. The above is what I've concluded is needed after a lot of experimenting.
#nevent1q…zw87

2026-03-21 22:41:15 CET

- reply

In other words, I disagree with the following sentence in your NIP draft:
"In decentralized systems such as Nostr, there is no [...] mechanism that can conclusively determine identity continuity after key loss or compromise."
Such a mechanism exists. It's been implemented at Inkan.

2026-03-21 22:28:07 CET

Another script is now up on the Inkan website. This one lets users check a given Ethereum block directly to see which Inkan declarations were actually recorded there, rather than just taking the client’s word for it. The output also includes transaction hashes and other on-chain details for anyone who wants to cross-check further in a block explorer. It’s again in the spirit of making Inkan easier to audit.
You can again download it under Settings >> Inkan Management Utility.

2026-03-21 21:55:20 CET

- reply

FYI, there already exists a key revocation and replacement mechanism for Nostr. It is fully implemented at Inkan.
It's a prototype and has rough edges, but it works. I've been using it for several months now. It's open for testing - you can try it out now if you like. See below for screenshots.
#nevent1q…j79t

2026-03-21 18:32:34 CET

I’ve added a Python script to the Inkan website that parses the signed Ethereum transactions produced by the Inkan Management Utility.
The script should be useful for anyone who wants to independently inspect / audit what these transactions encode.
You can download it under Settings >> Inkan Management Utility.