Matrix itself is a fairly flexible building block for decentralised communication of any kind where you care about decentralising the conversation history. You can use it for messaging, VoIP, IoT data - and once threading lands it'll be good for email and forums too.
Right now most of the clients are geared up for the messaging and VoIP use cases.
The value prop is to provide a meta-network which connects together all the existing communication silos, so users can talk to folks on other platforms (eg Slack, IRC) without caring what service or client they are using. Ideally someone on Slack could end up talking to someone on IRC, bridged via a decentralised Matrix room, without even realising they are using Matrix. Alternatively you could use a native Matrix client like Vector.im or the Matrix API to get at the data. The key thing is that no single silo ends up owning or controlling the data - it is replicated over all the participants, who thus own the conversation equally.
The end goal is to let users select which communication apps and services they want to trust with their data (including running their own, if they so desire), rather than the communication and contacts being fragmented over hundreds of different apps.
It isn't very technically detailed, but it should be clear enough. Your system sounds like a good match for what I imagine. The TL;DR: The messages are in focus, not the servers. Content-addressing using hashes, threads managed through messages referencing prior messages directly by their hashes. When creating forums, servers are just (optionally) defined to simplify routing / delivery.
One could build discussion servers on top of the matrix home server, and discussion clients to match.
Heh, this is awesome and pretty much precisely what we have in mind with Matrix. All that is missing is threading and editable message support, which we are working on shortly. Help would be very very much appreciated, especially in building bridges to forums!!
Does this imply that one could build a distributed GitHub-style issue tracker/pull-request manager on top of Matrix? That sounds pretty awesome, if true.
Yes, you could, although it's not a perfect fit right now as the only data structures you get in matrix are a timeline of arbitrary objects (events) for a room, and a key-value map of arbitrary "state" events. This is flexible enough for many purposes (and you could probably use them for issue tracking and PR management), but we can't efficiently store arbitrary object graphs or trees yet. It'd be great to get there though; meanwhile there are other projects like IPFS and IPDB which are active in that space too.
Right now most of the clients are geared up for the messaging and VoIP use cases.
The value prop is to provide a meta-network which connects together all the existing communication silos, so users can talk to folks on other platforms (eg Slack, IRC) without caring what service or client they are using. Ideally someone on Slack could end up talking to someone on IRC, bridged via a decentralised Matrix room, without even realising they are using Matrix. Alternatively you could use a native Matrix client like Vector.im or the Matrix API to get at the data. The key thing is that no single silo ends up owning or controlling the data - it is replicated over all the participants, who thus own the conversation equally.
The end goal is to let users select which communication apps and services they want to trust with their data (including running their own, if they so desire), rather than the communication and contacts being fragmented over hundreds of different apps.