Consider IPFS as an alternative to MXC for Matrix's file repository (SPEC-223)

Currently we use our basic mxc:// distributed URI scheme for sharing file attachments between matrix servers. This is a very naive system where you PUT files to your local HS, and then users in the room on remote HSes request the file from their local HS, which downloads and caches a copy on their behalf in order to decentralise the contents.

There are some problems here:

• No streaming file transfer (yet)
• Caching semantics of the remote copies are up to that HS; it's relatively easy for all the HSes to decide to expire the content and lose the original forever
• It has no mechanism for discovering which servers have cached copies of a file, so once the originating server discards its copy there is no way for it or another server to recover a file.
• There is no built-in check to confirm that a file downloaded from a server matches the file that was uploaded. For example we don't include the hash of the file in the mxc uri.
• Your HS needs storage for all the files it's consciously cached
• It has no mechanism for grouping files together into a hierarchical namespace or otherwise labelling files so that they could be accessed by desktop tools.
• ...?

It's an interesting thought experiment to consider whether supporting IPFS URLs as well as MXC URLs in m.file (and similar) events would help with this. Clients which aren't IPFS-aware would need to go via an IPFS bridge; ones which are running an IPFS node would be able to go use IPFS itself.

Thoughts?

(Imported from https://matrix.org/jira/browse/SPEC-223)

(Reported by @ara4n)

Start by reviewing the issue's description of MXC file sharing and the proposed support for IPFS URLs in m.file and similar events. Investigate how Matrix clients and servers would discover, retrieve, verify, and bridge these files; done requires a decided protocol direction rather than a narrowly specified edit.