This post summarizes a recent thread in Slack started by @jarradhope. In the spirit of openness and engagement with the wider Status community, we’re moving the discussion here.
Image Sending is the top feature requested by Status users through the app. The main obstacle to its successful implementation is that while the ‘correct’ way to implement it would be to light-client to Swarm or IPFS, neither have implementations that could be considered light clients (Swarm light client requirements are being tracked here). The most obvious concession is to use a proxy server, which Jarrad is personally very much against because we immediately break the trust model in doing so. Also, it’s worth noting that if we solve this, it allows us to do full encrypted app-state recovery (appdb backups to swarm, chat history, etc.), and we can also retrieve sites directly on Swarm (both features part of the original vision). Starting down this path is a slippery slope.
During the Status.app (July 4th-7th 2018), we plan to define the essential security properties that we want to maintain at all times (see Status.app, Status.app), so as to make it obvious any time we are tempted to start down a slippery slope due to technical challenges or other.
Although there is already some ongoing work in the Research team, @oskarth mentioned the need for Status to spend more time experimenting with Swarm and IPFS on mobile, and understanding the requirements for light nodes.As for the choice between Swarm and IPFS, @jarradhope mentioned leaning more towards Swarm, since it already runs on the same network as the rest of the ETH peers, whereas IPFS would require maintaining another P2P network, at least until/if everything moves to libp2p. Additionally IPFS, even with Filecoin, in his opinion, doesn’t provide very strong guarantees on data availability, even though it has better mindshare. Swarm, on the other hand, embeds the economics directly into the protocol.
@divan raised the possibility of building a storage abstraction that can support Swarm, IPFS and other future candidate technologies.
In addition, @arnetheduck pointed that Swarm is more censorship-resistant than IPFS by design - i.e. in general, on IPFS data is stored on a particular server (initially your own) and distribution happens as a side-effect of downloading data - the base mode of operation is a fancy cache with a DHT to lookup on which server stuff can be found. On Swarm, data is uploaded to a “cloud” of Swarm servers that essentially have little control over the specific data that they store - the DHT contains the data, not records about where to find it. If we’re going to support “both” of IPFS and Swarm, examining properties like this might be a good first step because they offer fundamentally different tradeoffs, tradeoffs that we’ll pass on to our users.