jcgruenhage/matrix-distributed-bridge-doc
1
0
Fork 0
Code Issues Pull requests Releases Wiki Activity

Shortened description of the solution to the second hurdle.

Browse source
This commit is contained in:
Jan Christian Grünhage 2017-03-27 18:18:33 +02:00
parent f0e5a9e917
commit d25275314f
Signed by: jcgruenhage
GPG key ID: 321A67D9EE8BC3E1
1 changed files with 2 additions and 3 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

5
README.md
View file

@ -22,8 +22,7 @@ Looking at the IRC Bridge though, shows that the first one is easy to solve. The
Failover needs some way where the bridges can communicate, but hey, they are all already connected to a federated communication network, that should not be a problem. A "bridge status room" to accompany a chatroom should be fine for that. Determining a bridge to take over for an unresponsive bridge should be easy, just base that on the reliability of the different bridges.
The second problem is harder though. The easiest way would be to have an openly available database of 3rd party room to matrix room (needed for 2) and 3rd party user to matrix user (needed for 1.2) mappings. That is not desirable though, since it is centralised and leaks some information, that should not be leaked/does not need to be leaked.
Decentralizing that is as easy as moving from a central database to a matrix room. Accessing that should be easy, with a list of public aliases to make sure joining that room works even when some servers go down unexpectedly. Fixing the data leak is also not that bad. You'd just need a public mapping of a 3rd party id to the bridge bridging that user, to get the room mappings, since the bridges can then communicate through matrix privately.
The second problem is, after some thought, easily fixed by mapping hashes of 3rd party IDs to the bridge that is bridging that user, by letting the bridge post this hash into a matrix room that is acting as a directory.
Once a user joins some 3rd party channel, the bridge can look through the other users and check if one of them is a bridged matrix user. If so, it can get a matrix room alias, matrix ID to 3rd party ID mapping, and the alias of the "bridge status room" described above from that bridge, if not, it simple creates these two rooms.
From then on, what's left to do is writing a spec on this and actually implementing it, but how to do it should be rather clear now.