Having had a few converations about Inkan here on Nostr, I think there may be a worry in some quarters that key rotation proposals represent a distraction from the work of growing adoption of Nostr and building a community. I'd like to address that worry using Inkan as a case in point, because I think that this worry may be inhibiting further conversations that it would be useful to have.
Inkan is a system for binding an online identity to keys that are held in cold storage. For those who'd like to have such an identity, it provides a way to create one. It does not require new users coming to Nostr to be persuaded to create an Inkan identity, or even to know that the option exists. Of course, for some new users, that option may itself be part of what draws them to Nostr.
Inkan is built on top of Nostr and does not replace it. Having an Inkan identity does not conflict with having a regular Nostr identity. In fact, the signing key inside an Inkan identity is just an ordinary Nostr key. It can be used as any other Nostr key would be, with no Inkan infrastructure involved, and other Nostr software treats it as perfectly normal. So holding an Inkan identity and holding a regular Nostr key are not mutually exclusive alternatives that one is forced to choose from. An Inkan identity *contains* a regular Nostr key as a part of it, and that key can be used indepently of Inkan. In fact, any currently existing Nostr key can be made part of an Inkan identity without any disruption to the key's functionality.
Now I hope people realize that providing a cold storage identity for online authentication is, at least in principle, a fairly fundemantal piece of infrastructure. It can be debated in what places and to what extent such infrastructure should be used, or whether Inkan is a good implementation of it. But it is less debatable that such infrastructure has important uses, and there is something not quite credible about a stance that dismisses the underlying approach out of hand. My guess is that a dismissive attitude just reflects the worry I mentioned above, namely that a discussion of key rotation would be a distraction from the broader project of growing Nostr. As I said, I think this worry is misplaced, and it prevents a conversation about decentralized public key infrastructure which the Nostr community is well-placed to have. Noone outside Nostr is going to have this conversation.
inkan
dv@www.inkan.cc
npub16xnp...6z6l
I made an OTS-enabled version of the strfry relay.
The relay collects timestamp proofs from clients, verifies these proofs against BTC headers, picks the best verified proof for each reference event, and splices it into the event's JSON when a client retrieves the reference event over REQ.
So as a result, when a client requests an event, the BTC timestamp (if available) arrives with it, in the same response.
#nostrdev #OTS

GitLab
inkan / Ots Enabled Strfry · GitLab
GitLab.com
I'm trying to make available a bit of code modifying a relay to do OTS-related stuff.
I think Nostr has github / gitlab alternatives? Is there anything that works well enough?
#nostrdev
Inkan is now in open alpha, which means I'm officially looking for testers. If you're curious about it, it's not a bad time to try it out.
You'd create a "toy identity", which you can do in your browser at
. You'd then send me the registration file and I'd record that on-chain and give you access to the Inkan relay so your test events can be timestamped. (You can also do the on-chain recording yourself if you hold some ETH to pay the gas fees.)
If you'd like to give it a try, let me know.

Inkan
Inkan web client
Inkan identities can now be created right in the browser.
That's obviously not very secure, but it's an easy way to play with Inkan: Spin up a toy identity, look at the files it outputs and, if you're so inclined, register it on-chain and use it for actual posting.
Should be nice way to try Inkan with minimal effort.


Inkan
Inkan web client
The way it usually goes, your online identity is your private key. If the key is compromised, there goes your identity. Inkan fixes that.
You keep a master key in cold storage and a signing key for everyday use. If the signing key ever leaks or gets lost, the master revokes it and delegates to a new one. Same identity, same followers, fresh signing key.
If you'd like to take a look at the prototype:
Log in with your NIP-07 extension and say hi to the test identities already walking around. Or make one of your own.


Inkan
Inkan web client

We need relays to have the ability to (i) verify OTS proofs, (ii) pick the best OTS proof they know about for a given reference event and (iii) splice that OTS proof into the reference event's json when returning the reference event.
This is a crucial piece of Nostr infrastructure. Delivery of events with both "created_at" and "ots" should be a standard option.
Here's an example of the shape, created by an experimental OTS-enabled relay:
{
"content": "Hey everyone.",
"created_at": 1779496582,
"id": "df2ab2b13de7b5c3b2b19c5f2d9a1a62bdd21187bab80ae9ca714657072514c5",
"kind": 1,
"pubkey": "d1a61498f4b1dc26df0becd1a3e9e88f355fb614b771e8b5b277d0ff99a82a23",
"sig": "136fa9ba91cc6353272a61c68b31dc32b66a3feeaf59e2b30d0c65231f62da8e62e4b2c471ef7716d94dbf2b96298922d94b6c6e54ae9d0e666d67c8bfdee8d5",
"tags": [],
"ots": {
"h": 950594,
"p": "AE9wZW5UaW1lc3RhbXBzAABQcm9vZgC/ieLohOiSlAEIWtcyBdiiH7GgEGoVRJIPc8DNzH7Z7RGtcg6/WpOJu1XwEA9v9HhTutucWA7w/ZGI2rcI8SAkKVNfWvH7gSKhnU/4vWIcLP2W6btnzaa3T0wET85tRAjwCASjHfEtZbrRCPAgkYRpMxK4g+/ZR2JyajbUpE/bsnvbL0xtp6yrjfIYQ+wI8BDAkdv1ZGZ+GAUJTUZ4qMRGCPAgS+QKBUJvUlLdCyvzMjLIqvLBBD3IoepiUmesn0mCNBMI8SAvI0Tf0k7vqLFDvIpe/UxZnQ7A5gwRkBUrF4ADZXiSNwjxBGoQ99zwCKolI080wUr+/wCD3+MNLvkMji4taHR0cHM6Ly9hbGljZS5idGMuY2FsZW5kYXIub3BlbnRpbWVzdGFtcHMub3JnCPEg/LQtTT8/+hqvCjHDGJ0mGXUyc8LrZgX9mlcbYpCE+kEI8SCtEFZWx6cNO0PhjLt+BhP5DqidihwBVhC3OYnWlE+GPwjwIEgz2gko9lK+h0ZnoKuCjME/UHskf9lSUD/X6vjqRXv7CPAgrRZwdXUYkcyXDJMPNrCXJUWOoOQrMtpls/k1N3oxp94I8CCfrdfZIQzyMswLsgUsUt6QAVIcLik8C6yBM9fMzj1i/QjxINlK6TBQpbHnLv2HjII4Xdnd7k44/spKcEozde0v/N22CPEguvGUeBCbEZi5mNym3ZBoMLYASs/qCTVzLzlt1lNgrEwI8SDFnrOH6S4wgampdkN+e/Nz68PkJiK4JKFEGhLnLlwOaQjxWQEAAAABd4ZxqpDBqGv1QVKo6a4h5OXyPsPZ+D7weiCvVQ8v1XsAAAAAAP7///8Cqm4AAAAAAAAWABTaRzyppy+5BvgYq1tTpSQA8+AUvwAAAAAAAAAAImog8ARBgQ4ACAjxIHUy9sLWy1kmFI7f6BIR8BC7vnr/z4BEVkfH0muJfJ2uCAjwIICmK+vIFKKIy/Hg8JOW/lQypJKJHwucYcNbr1JgSJydCAjwIId1d0xIdJa1a0zF9jMhDIghiov/957z7joB1Ml50J6rCAjwIEg363fprj/h/lBFOAu+oS5co1kmG+Vhj573jQznGTyZCAjxIIJTlHqo80FnmaYF3Jqe5wH5kkj8Q/kKTLn6xpB1wIO3CAjwINnw6Re4rCLlpKqDUfTci5q6gaxab3speYUOx3k1VqRMCAjwINT6RN9HA26lxlNWJqROea01L446Q6gN3G4Uj39/5E0iCAjxIHRcQlP6ix2DkV1BGcNNTiaqFWpJAp33gPBaNS/HrVzMCAjxIFtlzHfZmba11h0sqrDNmDAdUBJtXi/6A2pCzlprbuTJCAjwIGC3ZjfSFYdOHLbvI31/Qs88VqeAdbUxh4PR/T+I6MujCAjwIGu1SRrtLU+7cE79nEUkriJIvmaPV5gxkJIf5J9BribNCAjwIEAgQnKgE8QemGxL7IGZpLFXhGEFEMpv4fmmxvbFprUkCAjwICURMvkug3WVivpumgXFYGpLZnECEFmRm+DQsV9W8Ac1CAgABYiWDXPXGQEDwoI6",
"st": "complete",
"v": 3
}
#nostrdev
#ots
#opentimestamps
Nostr is a protocol for distributing digitally signed content.
The primitives on which it is build closely trace the elements of public key cryptography. It's unlikely that these are going to change.
So Nostr is not just some fad or fashion. Whether it's popular or a lot of people use it is in a way secondary. It's the correct way to authenticate on the internet, and that's all that matters to my decision to use it.