I think it's different with a chain, you can verify that nothing was omitted. For example the note below has a screenshot of a table showing a complete key delegation history that a client has read off a blockchain:

Yes, but an attacker will also be able to decrypt messages encrypted to the old key. Also, the old 10044 is validly signed forever, so an attacker can actively seed these announcements in any place that hasn't received the update. Inkan fixes that as a by-product of its key rotation system, which records revocations on-chain. I may try to add DMs, right now I'm exploring if a double ratchet is feasible.

Thanks, this looks great! I'm also learning DM right now. Serving 1059s only to intended recipients and permitting recipients to delete 1059s seems like the right way to do it. I'll put it on my list of things to try out.

This is *not* skipping Inkan identities! For example, here is https://brainstorm.world/p/

I think it's at least as safe as normal NIP-46 remote signing *if* you yourself retain a shard of the key under your exclusive control (and require *all* shards for a signature). If you don't retain a shard, it seems conceivable that your friends may have worse security practices than you yourself would have had, and that they could all be vulnerable to the same type of attack. So I guess I'd use the method as long as I myself keep exclusive control over a sufficient number of shards to give me a veto.🤷‍♂

If you have relay that's pre-configured / optimized for this purpose and can be installed easily, let me know.

The risk is if your friends collaborate to put enough pieces of your key back together, or if a third party in the future steals a sufficient number of pieces from your friends. If you spread around key material, you lose control over how it's stored, duplicated, not deleted, etc.

Congrats on shipping this. One thought on "NIP-4e, which separates encryption keys from identity keys" The hard part is how senders know which encryption key is currently yours, especially how they can know when an old encryption key stopped being yours. Just announcing this through a 10044 doesn't do the trick, since senders can never know if they've received the latest announcement and thus can't be sure that they aren't sending their messages to a compromised encryption key. Inkan solves this by recording key delegation and revocation declarations on-chain. The mechanism doesn't care what the key is used for, so it could be used under a 4E announcement. I actually started experimenting with double ratchet, because Inkan makes it easy for an identity to assign (and revoke / rotate) device-bound keys.

That's going to be hard to vibecode, but FYI I just updated the draft NIP for this, in case you're interested in how key rotation works 👇

A few weeks ago there was a spam wave from primal. That was the first time I turned on trust score filters based on fayan. I set the filter to 5% and that took care of it. I also added a setting for giving people whose fayan score is too low the option of providing PoW as a fallback. I think that sort of combination might work well.

The experiment deleted the networking kernel module trees among other things. If you're curious, the result is here: https://gitlab.com/inkan_dev/inkan-offline-live I'll take a look at SeedSigner OS.

That's great. It might be nice to have a relay that works out of the box for this purpose, and which users can easily build and install pre-configured on their VPS if they want to.