The problem:

Even though the matrix.org blog describes two way puppeting bridges as the holy grail of bridging, and they link a great community project as an example how to do that, there still is a problem: How to decentralise this?

Until now, everyone can run their own bridge, in addition to their own home server, and 3rd party rooms will be mapped into matrix just fine. What happens though, if two people, who both use this kind of bridge, join the same 3rd party room? The matrix room they write to is not, how one might assume (or rather hope), the same room, and all of a sudden, messages written by matrix user A arrive at the room of matrix user B as some ghost user, from the 3rd party network.

The solution(s):

A single, centralised bridge:

The easiest way to circumvent the problems caused by decentralising this, is not doing that by just using one central bridge for all users. I don't have to tell anyone why this is a really bad idea, since there are multiple bad problems with that.

Multiple Bridges:

Using multiple bridges in a single room creates some other problems though:

1. What messages should a bridge forward?
   1. Everything -> Duplicate messages.
   2. Only those of it's registered users -> Missing messages.
2. How to find the already existing matrix room, or how to even know if there is any.

These problems, especially the second one, seem rather difficult to solve at first, adding a lot of complexity, with not a lot to gain.

Looking at the IRC Bridge though, shows that the first one is easy to solve. The difference between receiving a message a lot of times on one server (the single freenode bridge on matrix.org) due to a lot of connections (one per user), and receiving a message a lot of times on different servers is not so big. One of the connections is used for receiving the third party messages and piping them into the matrix room (all except those, that come from users bridged by other bridges), and the other ones are used for sending messages as the corresponding users.

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, 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.