|
@mjg59 | |||||
|
Fun thing: if someone's using a Matrix bridge to IRC and ends up in a situation where they're on the Matrix channel but have fallen off the IRC channel for whatever reason, Matrix will still give them the history for while they weren't visibly present on IRC
|
||||||
|
||||||
|
Matthew Garrett
@mjg59
|
2. sij |
|
Bridging protocols with different semantics is always doomed to hitting weird corner cases and having stuff break and we apparently learned nothing from the days of proprietary mail systems that were being bridged to SMTP
|
||
|
|
||
|
Russ Garrett
@russss
|
2. sij |
|
This exact scenario is why we store per-user logs on @irccloud. It would be a lot easier for us if we didn't, but we didn't want to break the semantics of IRC.
|
||
|
|
||
|
Russ Garrett
@russss
|
2. sij |
|
That and the fact that it's surprisingly hard to tell whether two servers are part of the same network at any given time....
|
||
|
|
||
|
Nicolás Álvarez
@nicolas09F9
|
2. sij |
|
I saw an IRC channel end up with two Matrix bridges. It caused a loop of both messages and bridge-joins: bridge user from one appeared as a normal IRC user to the other, which then appeared in Matrix and was bridged back to IRC.
|
||
|
|
||
|
Nicolás Álvarez
@nicolas09F9
|
2. sij |
|
With all the nicks like mjg[m][m][m][m] it briefly became the channel with most users on freenode until one bridge was killed.
|
||
|
|
||
|
Matrix
@matrixdotorg
|
2. sij |
|
This really shouldn't happen - we jump through hoops to rapidly sync the IRC connection's state to the Matrix room membership to ensure the history semantics are preserved. If things have fallen behind though there's a risk of badness; we're investigating this incident. Sorry :(
|
||
|
|
||