The current media/content repository in Matrix is somewhat reliant on the origin server staying online indefinitely to serve the media, which is not always the case. Some servers may be bandwidth constrained (don't want to be dealing with thousands of people requesting media from them) or simply go down for maintenance/indefinite closure. When this happens, it would be useful to have media stored on other nodes and have a way to contact them.
We could invent our own system for finding out which other servers have a copy of the given media and gossip it, or we could rely on a solution that has solved this problem.
IPFS describes itself as a peer-to-peer hypermedia protocol and fits perfectly within Matrix's vision of an open, secure, and decentralised world. It handles media distribution for free (from our perspective) and is easily integrated into Matrix.
If not obvious by now, the proposal is to use IPFS within Matrix for media handling. Unfortunately
this proposal does not recommend using ipfs:// URIs in place of mxc:// for backwards compatibility
reasons, however is sufficient adoption is achieved then Matrix could easily switch over to that.
For now, clients and servers should handle ipfs:// URIs if they see them however this proposal
mostly focuses on introducing IPFS in a backwards compatible manner.
TODO: Decide if not using ipfs:// is a mistake.
IPFS uses "content IDs" (or "cid") to reference media which are compatible with Matrix's media IDs (TODO: CONFIRM),
making the process even easier to migrate. To support backwards compatability with older clients
and servers, the media ID is proposed to be formatted as ipfs:<cid> for IPFS-hosted media. This
will allow legacy servers and clients to contact their homeserver and resolve it to an IPFS gateway
to be served while indicating to supporting implementations that they do not need to contact the
origin server and can instead use IPFS directly to retrieve the media.
For completeness, an example IPFS-styled MXC URI would be mxc://example.org/ipfs:cidgoeshere.
Because clients can embed an IPFS node into themselves or access IPFS from the browser,
it would be extremely useful to allow the client to bypass the /upload endpoint and publish its
own MXC URI after having used a local IPFS node. Considering ipfs:// support is not proposed here,
clients will need to get a homeserver name/origin to put into the mxc:// URI. They'll also need to
know if the server even supports IPFS to be able to bypass /upload entirely.
To permit the bypass of /upload, a new capability is proposed: m.ipfs. When present, this indicates
to the client that the server's media repo is IPFS-capable and thus can be bypassed. Clients will still
need to know an origin to provide in the MXC URI however. Clients should use the following steps to
determine an appropriate origin:
- The one they were explicitly provided (in the case of a user wanting to use a particular gateway).
- The origin specified by the optional
preferred_originin them.ipfscapability. - The domain name for the user's ID, as a default option.
This proposal does encourage that client implementation embed IPFS support to avoid having to contact
the homeserver for content. Clients might still wish to use functionality like thumbnails from the
server, however if specified well enough by other MSCs a client could feasibly use the thumbnail_uri
provided by the sending client to display appropriate content without ever having to contact the
homeserver.
TODO: Investigate ways to mitigate.
- Retention and redaction, erasure.
- Spam, abuse, etc
- Quarantining content (not currently specified, but should be considered).
TODO: Find other solutions than IPFS and explain why they're bad.
TODO: This.
While this MSC is not in a released version of the spec, io.t2bot.ipfs should be used in place of
m.ipfs. No special endpoints, version flags, or other prefixes are required for this MSC.