Thanks for taking a look. And negativity *after* having looked at it is absolutely fair. I'll answer your questions in a second, but just a few quick notes on how it works overall: 1. Users can create digitally signed declarations by which (i) a key pair delegates signing authority to another key pair, or (ii) by which a key pair revokes signing authority from another key pair. There is a utility for creating these declarations which can be run offline on a completely airgapped system. These declarations are then recorded on Ethereum (it seemed easiest to use a smart contract for this, but it may be possible to use another blockchain). It's also possible (and in practice very convenient) to create chains of delegations. 2. Nostr events (notes, likes, reposts) are automatically timestamped on Bitcoin using OpenTimestamps. Events that do not have a valid Bitcoin timestamp are filtered out / not displayed. 3. Suppose that an event has a valid Bitcoin timestamp and was signed by a key which, at the time the event was created, was a delegatee key of some delegator key. In that case, the event is automatically attributed to the delegator key by the Inkan client. Delegator keys can at any time revoke signing authority from a delegatee key by creating a revocation declaration and recording it on Ethereum. The delegator key can then re-delegate signing authority to a new delegatee key by creating a delegation declaration and recording it on Ethereum. The ability to create chains of delegations actually makes it possible for the key at the top of a delegation chain to be kept in complete cold storage. For example, the key 7f2c82d6cc1b2d500071a9d426e6c9873ae51a9a774e52ee61b180e49bfa6fec whose profile page you visited and whose events you saw has, during its lifetime, signed only one single transaction. That transaction was signed on an airgapped system. Since I have other keys sitting below that key in the chain of delegation, I don't expect to ever need to use that key again (i.e. I can keep it in a safe deposit box without ever accessing it). Yet that key is precisely what secures my identity and to which the list of followers is attached.

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!