Enshroud dApp Access

Here at the Enshroud Project, we take seriously our commitment to privacy and strong encryption. This means that we cannot utilize any encryption technology that we have reason to believe may be inadequate or compromised.

Unfortunately this means that we cannot use HTTPS in the context of our dApp. This is not because of any known defects in the SSL/TLS encryption algorithms on which it relies. Rather, it's because the Public Key Infrastructure (PKI) for HTTPS has been compromised by "captive CAs" who supply fake certificates for MITM attacks to LEOs and spy agencies. (If you think this is an exaggerated claim, please read this article. They are now admitting publicly what has long been standard practice.)

At the same time, it's vital that our dApp protect users' communications with our L2 MVO servers using strong encryption. In order to provide this without reliance on HTTPS, we deployed ECIES, a hybrid ECDSA/AES-256 encryption algorithm, to generate one-time keys for every message exchange. This is superior encryption, which travels over ordinary HTTP.

It's also vital that our MVO servers (which are essentially privacy miners) should operate like crypto miners (bare IPs, no domains or site certificates), to reduce the attack surface against their operators. This goal is also accomodated by building on ECIES. (Note the URLs and public ECDSA keys of MVO nodes are recorded on-chain.)

Therefore, the Enshroud dApp is published on IPFS.

You can access our dApp here:
http://localhost:8080/ipns/k51qzi5uqu5dm8tgpqw0z1atp487ctgbil2f2ejxtqj0rsz4dxamk7aih3e13v

which your browser may rewrite equivalently as:
http://k51qzi5uqu5dm8tgpqw0z1atp487ctgbil2f2ejxtqj0rsz4dxamk7aih3e13v.ipns.localhost:8080/

Access via IPFS (Interplanetary File System) also has the effect of guaranteeing file integrity, since all addressing is via content hashes. (An HTTPS website cannot do this.) These IPNS (Interplanetary Name Service) links will remain consistent across updates, and assume your local IPFS gateway is running on the default port of :8080.

There is one wrinkle:

Because browsers won't access HTTP URLs from within a "secure" HTTPS context, you cannot use a https:// gateway URL to access our IPFS content. You might pull up the dApp, but communications to our L2 nodes wouldn't function. This means that the IPFS Companion and similar plugins won't work, because they rely on public relays secured with HTTPS, such as .dweb links.

We therefore recommend that you install Kubo, the IPFS Go client. You can obtain Kubo here.  Extensive documentation including installation guidance is also available at that link. Mobile platforms (iOS, Android) are not supported by Kubo.

Note regarding wallet usage (WalletConnect unsupported)

In order to connect to the Enshroud dApp, you will need a wallet which strictly supports the window.ethereum.providers Web3 standard, including EIP-712 signature support. We suggest that you use the MetaMask Web3 plugin with the Brave, Chrome, or Firefox browsers. (All of these have been tested by us.)

Unfortunately, most wallets targeted at mobile devices (such as Rabby) rely on SDKs such as RainbowKit, which is based on the WalletConnect Protocol. In order to work with the WalletConnect Network, every dApp project must apply for a project ID, according to these terms of service; see also these terms (note esp. Section 23). While getting an ID from them would no longer require that we supply a complete roster of all our project devs, seed investors, admins, and responsible persons (yes, the TOS used to stipulate this!), it does still require us to: accept the legal jurisdiction of the Cayman Islands, the USA and the State of Delaware; agree to comply with all GeoIP-blocking, address blacklisting, and sanctions decreed by the US Treasury or other national and international regulatory bodies; and generally not allow our services to be used in the service of any illegal purpose (whatever that might mean); and if we should ever fail to do any of this, our ID could be turned off and access to our dApp terminated.

As a PrivFi project with an anonymous team and no VC funding, and since our tech has zero ability to perform any blacklisting or sanctions compliance in the first place, these terms are unacceptable to us. Accordingly, we cannot readily support users on mobile devices, unless we want our dApp to become an application permissioned by a third party based on our promised obsequious compliance with American law.

But, given that smartphones and tablets are essentially self-purchased surveillance devices to start with, that may actually be for the best anyway. Convenience always comes at the expense of privacy, so perhaps it's best to insist on being the adults in the room here. Our dApp isn't really intended for mass adoption; rather, it's a reference implementation targeted at Web3 power users.