Matrix

[davidar]

Several people from both the @ipfs and @matrix-org communities have expressed an interest in the possibility of integration between the two. I'm opening this issue to coordinate this effort.

Relevant links:

• https://botbot.me/freenode/ipfs/msg/49412288/
• https://matrix.org/jira/browse/SPEC-223
• ipfs/ipfs#73
• https://ipfs.io/ipfs/QmXkxZvZ8apvsVL7naAwsL8kGxu41PSBHzvTpaw39oowBB

CC: @jbenet @ara4n @dbkr matrix-org/matrix-spec-proposals#33

[hackervera]

👍

[jbenet]

For starters, we should:

• host matrix web clients in ipfs today

• host a log-viewer in ipfs

• (provide option to) host logs directly in ipfs

• make a "one-click-to-join-chatroom" button for the web. embeddable in markdown, a link like:

  [ ![img](https://ipfs.io/ipfs/<hash>/btn.png) ]( https://ipfs.io/ipfs/<hash>/client?chan=<channel>&whateverelse )
  

• make a "one-click-to-join-IPFS-chat" button for all our repos.

• add the button to all our repos.

[ara4n]

On the Matrix side, we've been looking at this on three levels:

1. hosting matrix web clients in IPFS (which @davidar looks to be doing a great job at with Vector)
2. potentially using IPFS as a means for storing and sharing files in Matrix. Currently we have a naive HTTP-based replication strategy between servers; IPFS might be a huge win, with the IPFS node itself either sitting in the client, homeserver or IPFS gateway (in descending order of preference).
3. the thought experiment of using IPFS as an alternative server<->server transport/protocol for Matrix.

The 3rd point is the most controversial, as Matrix and IPFS's goals start to overlap somewhat at this point in that they both want to provide a big global DAG; Matrix currently optimised for pubsub group messaging; IPFS currently optimised for files. Right now the server-to-server protocol for Matrix is core and pretty vital for us to get perfect, and we're expecting to keep using it for our state synchronisation and pubsub for the forseeable rather than making it dependent on any 3rd party project.

However, it is also designed to be replaceable - so down the line, one could certainly consider replacing it with something like IPFS (or a Tor + Pond style transport). We'd go and bridge the current Matrix network into this alternative one, and then on with the show. It would be a very significant amount of work to replace the replication of a matrix homeserver, though, and to map the requires permission and merge resolution semantics onto a hypothetical IPFS pubsub system.

The fun thing about Matrix is that even if the federation transport is completely replaced in this manner, all of the current Matrix clients, bots and application services (e.g. bridges) would be untouched and still work absolutely fine. So if someone ever did make Matrix homeservers store/synchronise their data via IPFS, you'd be able to use it seamlessly with all the existing apps :)

In terms of storing logs in IPFS... one could certainly write a Matrix AS that copies Matrix events into IPFS as a 'log', and then write a log-viewer app to view them. However, we'd obviously hope that the Matrix DAG itself performs this job pretty well now, and you don't need a separate log-viewer app as you can just go and use any old Matrix client to view the Matrix DAG. That said, nothing to stop someone going and doing this anyway if they want to :)

[ara4n]

oh, on the whole "one-click-to-join-chatroom" thing... hell yeah, as per our discussion at the PDX meetup. We should have this finally implemented in the next month or so, with any luck.

[jbenet]

@ara4n awesome stuff all around.

one quick note for now: we've had a goal of building pubsub. we'll get to designing this pretty soon. if you help us understand your requirements, we can make sure to meet them. (or even use protocols from matrix if you're ok with that). it may be that what we should be doing is using the matrix pubsub mechanisms to move ipfs merkledags inside ipfs itself. i'll look at your specs in next week(s)

[ara4n]

Most of the matrix spec is concerned with the client<->server and application<->server APIs rather than server<->server (aka federation) API. The best we have right now on the smart stuff (i.e. ACL-aware merge resolution algorithm) is https://github.com/matrix-org/matrix-doc/blob/master/drafts/erikj_federation.rst.

The hard thing here isn't the pubsub, which can just be a simple "prod listeners when stuff changes", but having the right semantics for propagating updates and solving merge conflicts on said stuff in the context of the room. Needless to say, if you want to experiment with applying Matrix's semantics on top of IPFS, we're not going to stop you - and as per above you'd automagically gain a bunch of clients/bots/etc by doing so. But it could be a large amount of work. It may get easier over the next few months though as we go through splitting out our homeserver implementation into separate services - some of which will probably be written in Go rather than Python. One of those services is likely to be the federation service, so if we structure things right we might actually get a modular system for swapping out federation transports for this kind of hackery anyway!

[jbenet]

nice! this is great to hear. will look deeper into this stuff as time permits. if anyone else beats me to it, thank you!

The hard thing here isn't the pubsub,

i'm worried about making it scalable in light of massive churn (Millions+ nodes). IPFS nodes will be coming up and down all the time.

[Ericson2314]

I'm eyeing https://github.com/libp2p/rust-libp2p, https://github.com/ruma/ruma, and wishing.

[swedneck]

Me and tulir discussed how IPFS could be used in the matrix media repo, and how mxc:// urls could be decoded into IPFS hashes: t2bot/matrix-media-repo#115

I've also published Riot on IPFS: https://riot.swedneck.xyz

[bmiller59]

Hi @ara4n. Are there any update on using IPFS to store files for Matrix worth mentioning here? If someone wanted that to move forward, what would you recommend as some steps towards that goal? Thanks! Referencing this here as well: https://github.com/matrix-org/matrix-doc/issues/539

[ara4n]

well, t2bot/matrix-media-repo#115 moved forwards last week...