Matrix #42
Comments
|
👍 |
|
For starters, we should:
|
|
On the Matrix side, we've been looking at this on three levels:
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 :) |
|
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. |
|
@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) |
|
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! |
|
nice! this is great to hear. will look deeper into this stuff as time permits. if anyone else beats me to it, thank you!
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. |
|
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 |
|
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 |
|
well, t2bot/matrix-media-repo#115 moved forwards last week... |
|
It would be awesome to amalgamate |
|
@ara4n You've probably seen this already, which got recently merged. But I just made the connection with your presentation of libp2p and other p2p experiments on this year's fosdem. |
|
Has there been any progress using IPFS as transport for Matrix? Would be absolutely awesome if you could use The ipns would need to point to a profile folder which contains the individual clients as text files with the ipfs public key and the matrix public key for encryption as well as profile data like the profile picture. The connections would need to be established to the clients directly instead of a centralized server. Easiest solution would be to create the server portion directly in the clients. Which means a foreign server would connect to the clients in the ipfs folder following a prioritization. The individual clients would need to connect between each other to exchange notifications about new messages, while the messages could be stored in ipfs directly. After like 14 days individual messages would need to be compacted in single flies for each chat, to avoid the overhead of hundreds of thousands single message files 😁 |
|
See
You will notice that the blog post was a bit negative on libp2p's current methods and was looking at Yggdrasil. But that would be a shame, as it's great how so much of the ecosystem has been moving towards libp2p, and since libp2p aims to be "mechanism not policy" (it's a library of things one could use). Hopefully Yggdrasil-like spanning tree mechanisms could also have a home in libp2p so there's not a collaboration/experimentation trade-off. |
|
At the risk of being the annoying fan shipper here :D, https://matrix.org/blog/2021/05/06/introducing-the-pinecone-overlay-network has an update saying:
Which is just the sort of thing I am hoping for! I eagerly opened matrix-org/pinecone#7 in response to track any such developments. |
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:
CC: @jbenet @ara4n @dbkr matrix-org/matrix-spec-proposals#33
The text was updated successfully, but these errors were encountered: