ExploreTrendingAnalytics
Nostr Archives
ExploreTrendingAnalytics
fiatjaf6d ago
Thank you for explaining. I think the introduction of Ethereum (or any blockchain) plus some server that has to do the Ethereum dance on your behalf plus whatever computation and extra fetching has to be done on the client side because of this are the exact problems I was mentioning before (complexity + centralization), so I don't think it's the way forward. Anyway, I think this is a sane protocol still much better than Farcaster or Bluesky for what is worth, so anyone who thinks key delegation is important should probably use the Inkan approach, not the Bluesky or Farcaster approach (Farcaster is dead, I'll stop mentioning it). Who is paying the Ethereum fees, by the way?
💬 1 replies

Thread context

Root: 0000c130b638…

Replying to: 5315a42a66a8…

Replies (1)

inkan6d ago
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.
0000 sats