You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I just realised we don't actually have a spec bug for a possible evolution of Matrix to be p2p. To quote the GSoC suggestion:
"Matrix currently follows a client-server architecture, where the servers federate together. This means that to host your own conversations in Matrix you have to own and maintain a server with a static IP and DNS SRV record etc. This isolates many people from running their own Matrix nodes. An interesting experiment would be to write a homeserver variant (probably in Node.js) which advertises itself via a DHT or similar (e.g. using js-libp2p) and uses WebRTC data channels for p2p synchronisation of message graph data. This could make it much easier to run homeservers - either as a standalone node daemon, or built into a desktop or even web client. Such a server would implement the basic features of today's Matrix C-S API, but obviously break compatibility with today's Matrix S-S API. An extension might be to write a bridge between the two federation protocols."
An extension beyond this could be to then relay the data off onion-routing and pond-style store-and-forward servers in order to protect metadata.
Was about to open an issue for this ... So yeah it would be nice, maybe it doesn't have to be a breaking change, it well says in the FAQ that in the future the federation could implement more efficient transport protocols(libp2p) keeping http as the baseline for compatibility. Maybe people building dendrite or ruma want to give it a try? libp2p for Go and Rust are up to the task!
I'd love this to happen, I want to have my home "server" to enable my decentralized chatting needs at home from my laptop or phone connecting to it but NATs crush my dreams 😭
I just realised we don't actually have a spec bug for a possible evolution of Matrix to be p2p. To quote the GSoC suggestion:
"Matrix currently follows a client-server architecture, where the servers federate together. This means that to host your own conversations in Matrix you have to own and maintain a server with a static IP and DNS SRV record etc. This isolates many people from running their own Matrix nodes. An interesting experiment would be to write a homeserver variant (probably in Node.js) which advertises itself via a DHT or similar (e.g. using js-libp2p) and uses WebRTC data channels for p2p synchronisation of message graph data. This could make it much easier to run homeservers - either as a standalone node daemon, or built into a desktop or even web client. Such a server would implement the basic features of today's Matrix C-S API, but obviously break compatibility with today's Matrix S-S API. An extension might be to write a bridge between the two federation protocols."
An extension beyond this could be to then relay the data off onion-routing and pond-style store-and-forward servers in order to protect metadata.
(Imported from https://matrix.org/jira/browse/SPEC-455)
(Reported by @ara4n)
The text was updated successfully, but these errors were encountered: