walletbeat

Frontend

🚧 Introducing Krome 🚧

🏗️ An MIT licensed starterkit for building onchain apps that run as native apps on iOS, Android, windows, linux, and macOS
🔒 Comes preloaded with Helios Light Client
🤝 Started in collaboration with 
@shazow
 and 
@dionysuzx
 
🦀 Write your app Rust and JavaScript (via svelte)

Project just started. Reach out if you want to contribute

https://github.com/evmts/krome

Krome 🤝 Walletbeat
    Light clients
    everywhere

Contributor @ /walletbeat.

Censorship resistance requires privacy.

The dream would be to have a lightclient RPC service worker you can access from an ENS domain.

Still a few trust assumptions left on how that ENS domain is initially resolved, who controls the ENS name, whether what it resolves to is mutable or on IPFS, and (if on IPFS) whether the browser verifies the content hash of it or blindly trusts an HTTP gateway, etc... but yes!

Ideally, all content has a hash, that hash is checked point to point, and with the hash is a signature saying who had it before you.

IPFS is actually getting fairly decentralized. Their https://inbrowser.link/ project is quite cool. Main trust assumption is initial load of webworker + DNSsec to make average ipfs nodes available from the browser.
I think we would need similar efforts to make it possible to connect to the CL swarm of Ethereum. Should be straight forward for eth nodes to support autoTLS:

IPFS is actually getting fairly decentralized. Their https://inbrowser.link/ project is quite cool. Main trust assumption is initial load of webworker + DNSsec to make average ipfs nodes available from the browser.
I think we would need similar efforts to make it possible to connect to the CL swarm of Ethereum. Should be straight forward for eth nodes to support autoTLS: https://blog.libp2p.io/autotls/