Ethereum fees are paid by the user. The transactions are not expensive. I think it was somewhere between $0.40 and $0.80 per delegation / revocation. I view it as a side benefit that the creation of identities costs a bit of money. It's a signal of the "quality" of an identity, like NIP-5. Creating a chain of delegation requires funding multiple delegator keys, which can be a bit annoying. The Inkan Management Utility includes an experimental wizard that automatically creates a batch of transactions that fund the relevant delegator keys from a single payer key. See attached screenshots. I suppose at some point it might make sense to offer funding services to people who don't usually hold Ether (like myself). But it's not the highest priority at this stage. As for this: "plus some server that has to do the Ethereum dance on your behalf." Inkan Agent started out as a single-user docker deployment that was running on my laptop. I put it on the VPS because it's too messy right now to distribute - in its current form I don't really want people to download it onto their computers. Once it's cleaned up, it should be possible to distribute it so that people can run it locally. That should then make everything decentralized. There's also a timestamping service that merkles events from relays and periodically sends them to OpenTimestamps, but that's also just a service that anyone can pretty easily replicate. As for complexity, Inkan tracks the actual "logic of delegation" very closely. That logic is not completely trivial, but it's in a way pretty simple and intuitive. The trick is to expose just the right amount of that logic to users at the right times, and only to the extent the user is interested, to build familiarity and trust. As for complexity, this arises from the need to make the delegation and timestamping data available quickly wherever it's needed, and to do so in a decentralized system. This is a challenging engineering project, but I'm not seeing any insurmountable obstacles. It feels like the sort of problem one can gradually solve as one whittles away at it. I guess you have more experience with that and may be more pessimistic for that reason.

Quick update is warranted here: 1. I've managed to get rid of the server. It provided important scaffolding for a while but wasn't ultimately necessary. You can now log into

Inkan

Inkan web client

with NIP-7 and interact with the existing inkan identities without any further registration. 2. Ethereum gas fees can now be paid by a sponsor if you don't hold ETH yourself. You just send the identity creation transaction to the sponsor and they can get your identity recorded on-chain. 3. I've added a wizard for creating a "toy identity" directly in the browser at

Inkan

Inkan web client

. This is obviously not very secure and inkan identities should really be created on an airgapped system using the Management Utility. But in-browser creation is effortless and it's a nice way to try out an inkan identity. 4. To fully use your own inkan identity, you currently still need access to the inkan relay (happy to allow-list anyone who wants to try). This is just because your events need OTS timestamping and the inkan relay splices suitably formatted timestamps into the events it returns. I'll try to make some relay code available soon, so people can run their own OTS-enabled relays rather than having to use the inkan relay. I think inkan is now pretty functional as a way to use Nostr with a true cold storage identity.