This sounds like NIP 26 but with blockchain. Blockchain is important for ordering and completeness, but is a heavy dependency, making it harder for clients to adopt. And this depends on client adoption to work, correct?
Login to reply
Replies (1)
In a way it depends on client adoption, but it's optional and additive. Inkan runs as an identity layer on top of the regular Nostr protocol, and there is no need for any existing clients to be reformed. It does not require users to adopt any infrastructure that won't work with existing clients.
For example, the key I'm using right now is part of an Inkan identity. I can use it just like any regular pubkey across Nostr. But if I want to see and interact with the identity of which it is a part, I need to go to 
.
I suppose Inkan does require some OTS infrastructure, which should probably live on relays. Here is the OTS-enabled relay it's currently using: 
. OTS actually feels like the "heaviest" part of it.
Inkan
Inkan web client
GitLab
inkan / Ots Enabled Strfry · GitLab
GitLab.com