v1rtl on Warpcast

Content pfp

https://warpcast.com/~/channel/walletbeat

0 reply

0 recast

0 reaction

polymutex pfp

Like app frontends, Walletbeat ought to walk the talk of decentralization and censorship resistance. Will move from Vertex to IPFS + ENS. Perhaps an ERC-6860 version down the line too? Work-in-progress version: https://dev.walletbeat.eth.limo/beta/

4 replies

2 recasts

14 reactions

v1rtl pfp

you might want to use Blumen you could replicate the IPFS deployment on multiple services and use Safe to manage the website https://blumen.stauro.dev/

1 reply

0 recast

1 reaction

polymutex pfp

This looks interesting, but seems like high overhead (and gas fees) for every update. Ideally I'd like something more like Fleek where it runs as part of a CI pipeline and updates an IPNS CID (that I'm comfortable having the private key of in the CI pipeline), and then point a self-custodied ENS domain at that IPNS.

1 reply

0 recast

0 reaction

v1rtl pfp

IPNS has a few problems 1) you have to store the keys somewhere and hope that they don't get leaked or lost 2) IPNS itself is very centralized, very few pinning services support pinning/replicating it 3) IPNS is super slow, compared to DNSLink for example

1 reply

0 recast

1 reaction

polymutex pfp

Fair enough, but perhaps what I'm getting it is that it's useful to have two levels of indirection: ENS →‬ [thing], [thing] →‬ IPFS CID. This way the "[thing] →‬ IPFS CID" mapping to be cheap and easy to update as part of CI, while maintaining secure ownership of the ENS domain by a Safe multisig.

2 replies

0 recast

0 reaction

Joel pfp

I'm in deep disagreement about this. One of the main value props of ENS + IPFS combo is that you get a permanent record of changes over time. If you use IPNS you actually remove the main benefit and devs can easily rugpull users, without any on-chain security measures. Might as well use a normal https server imo.

1 reply

0 recast

1 reaction

polymutex pfp

I don't think we disagree; rather I think what you're pointing out is a flaw in IPNS: lack of auditable history. My goal is to have a layer of indirection for CI to have "redirect" powers and no more. I'd be happy with any solution, and if it's auditable, that's even better. IPCM and ERC-6860 would both fulfill this.

2 replies

0 recast

2 reactions

Joel pfp

Yes, and adding immutable history to IPNS would essentially make it in to a blockchain. I think that implementing custom contracts (like IPCM) to do what ENS already does is the wrong approach. Instead wallets like MetaMask are adopting https://eip.tools/7715 which will essentially allow for delegation of granular permissions on contracts from your wallet to session keys. Imo this is a cleaner solution.

1 reply

0 recast

1 reaction

v1rtl pfp

how could you achieve this with ERC-7715? is there an example of a Content-Hash using it?

1 reply

0 recast

2 reactions

Joel pfp

Good question! I don’t have an example yet. I think the MM framework won’t be released until 7702 is available. Paging @danfinlay

1 reply

0 recast

1 reaction