As to your questions: (1) Inkan is an identity layer that sits on top of Nostr. It's accurate to describe it as Nostr + Delegation. (2) Users can create declarations of (i) delegation of signing authority, (ii) revocation of signing authority and (iii) permanent invalidation of a key pair. These declarations are then recorded by the user on Ethereum. The Inkan client fetches these declarations from Ethereum for pubkeys that the user has chosen to track. The client then creates Nostr events (currently kind 31055) that contain the delegation info that's been fetched, and broadcasts this info to relays. Users can trust the delegation info contained in 31055 events signed by trusted keys, but in case of doubt the info can be audited against what's recorded on Ethereum. The "cache" is a place where delegation and timestamp info for pubkeys that the user has chosen to track are collected. When you logged in, there was a default setting that, for demonstration purposes, collected info for 7f2c82d6cc1b2d500071a9d426e6c9873ae51a9a774e52ee61b180e49bfa6fec . (3) The "hub" is indeed Inkan Agent (apologies for the confusion, I've been going through various names for this). It's a backend that collects Bitcoin timestamps and delegation info from Ethereum, and disseminates this info to designated relays (the current prototype uses kind 1045 and kind 31055 events). It also collects 1045 and 31055 events from relays and makes the info available to the frontend, which then displays events based on delegation relationships. (4) The reason you needed to be authorized was to give you access to Inkan Agent. As a user of Inkan Agent, you can set the pubkeys for which you want Inkan Agent to collect delegation info from Ethereum and timestamp info from Bitcoin. Inkan Agent then broadcasts this info to relays. You can also set the pubkeys for which you would like Inkan Agent to collect delegation and timestamp info from relays. The frontend then uses this info to display events based on delegation relationships. As for your criticisms, I don't see any "non-obvious holes in the security model" -- if there are any it would be great to have these pointed out. I suppose people might not like the use of Ethereum. It may be possible to use other blockchains. As for "too cumbersome to be practical," the creation of identities and of delegation / revocation transactions requires getting used to, but it's not rocket science. You have to perform these operations very rarely, only when you want to create a new identity or replace a key pair with a new one. It's kind of fun once you are used to it. There is complexity. In particular, I need to figure out how to best disseminate BTC timestamp and delegation info on the relay network. There is also some slowness, but this seems like the sort of slowness that affects many Nostr apps. I will need to address it. Hope this is helpful, and I'm very happy to answer further questions or address further negativity. Thanks for taking a look!