walletbeat

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:

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/

you might want to use Blumen

you could replicate the IPFS deployment on multiple services and use Safe to manage the website

Contributor @ /walletbeat.

Censorship resistance requires privacy.

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/

building Stauro ❇ frontend dev at @ensdomains ❇
prev. @rainbow, @geniexyz, @fleek

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.

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.

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