In a way it depends on client adoption, but it's optional an...

inkan

npub16xnpfx85k8wzdhctang6860g3u64lds5kac73ddjwlg0lxdg9g3su56z6l

hex

20e4596c312793c3b201b0d8f6c8e73abd9ef4656505eac47da22b0eb2b5e926

nevent

nevent1qqszpezedscj0y7rkgqmpk8kernn40v773jk2p02c376y2cwk267jfsprpmhxue69uhhyetvv9ujuem4d36kwatvw5hx6mm9qgsdrfs5nr6trhpxmu97e5dra85g7d2lkc2twu0gkke8058lnx5z5gcteqlye

Kind-1 (TextNote)

2026-06-09T18:07:35Z

↳ Reply to Event not found

6973b175768e0ed830a4b6bf6f49876bef36a8b2c42cb22ec9e447a7d0be3e73...

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 https://www.inkan.cc .

I suppose Inkan does require some OTS infrastructure, which should probably live on relays. Here is the OTS-enabled relay it's currently using: https://gitlab.com/inkan_dev/ots-enabled-strfry . OTS actually feels like the "heaviest" part of it.

Raw JSON

{
  "kind": 1,
  "id": "20e4596c312793c3b201b0d8f6c8e73abd9ef4656505eac47da22b0eb2b5e926",
  "pubkey": "d1a61498f4b1dc26df0becd1a3e9e88f355fb614b771e8b5b277d0ff99a82a23",
  "created_at": 1781028455,
  "tags": [
    [
      "e",
      "dbe68638908a66bb601f681b5a92a41d9fd9683fb97330a1f6e7f8fe687b4277",
      "wss://nostr.wine/",
      "root",
      "d1a61498f4b1dc26df0becd1a3e9e88f355fb614b771e8b5b277d0ff99a82a23"
    ],
    [
      "e",
      "6973b175768e0ed830a4b6bf6f49876bef36a8b2c42cb22ec9e447a7d0be3e73",
      "wss://nos.lol/",
      "reply",
      "97c70a44366a6535c145b333f973ea86dfdc2d7a99da618c40c64705ad98e322"
    ],
    [
      "p",
      "97c70a44366a6535c145b333f973ea86dfdc2d7a99da618c40c64705ad98e322"
    ]
  ],
  "content": "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.\n\nFor 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 https://www.inkan.cc .\n\nI suppose Inkan does require some OTS infrastructure, which should probably live on relays. Here is the OTS-enabled relay it's currently using: https://gitlab.com/inkan_dev/ots-enabled-strfry . OTS actually feels like the \"heaviest\" part of it.",
  "sig": "8b980d120f25b4fc90b2d031d4e873baf3435d7096115fa08be16f6291269c6edfec1f4e8699ae641af83d3c78fb52aa4852b65ff698bb0914b5b17b688e6fa0"
}