“add opportunity to create the bridge not only from the matrix but from the xmpp conference too” is listed under “future plans” 💔
Also log4j shenanigans. But I’ll add a link to it, thank you.
“add opportunity to create the bridge not only from the matrix but from the xmpp conference too” is listed under “future plans” 💔
Also log4j shenanigans. But I’ll add a link to it, thank you.
In other words, I want to be able to use a normal email, IRC, or XMPP client (either is fine, listed in order of fave (email) to least fave (XMPP)) to join any Matrix room or talk to any Matrix user. (Willing to install a gateway server to do so, and even register an account (manually or through autopuppeting). The point is that I wanna use the cozy comforts of my familiar clients.)
There are many bridges that work in the other direction, that lets Matrix users join our rooms (if they’re willing to jump through hoops and install bridges and register accounts, but they at least get to use the cozy comfort of their favorite Matrix clients). That’s great for them. I’m looking for the reverse.
(Not particularly urgently, which is why I’m not working on one myself.)
@Sandra Interesting. I suppose you would want that built into the protocol as opposed to middleware slapped onto every instance, or room, or 1-1, etc. A "meta-protocol." That seems like something that would require some serious effort and maintenance.
Out of curiosity, you said 'that let's Matrix users join our rooms' -- who is 'our' or 'we'?
Matrix tried e-mail bridging: https://github.com/kamax-matrix/matrix-appservice-email
@jch It doesn’t have to be built into the protocol at all. There are gateway servers from irc to Fediverse, or from email to Fediverse, or from email to IRC, without being built into either protocol.
You linked to Kamax’ defunct email-bridge, which, like the two non-defunct email bridges (by Jojii and by taki-tam) allow Matrix users to use Element as an email app. That’s what I meant by “they can join our rooms” — “our” meaning email users, and “joining our rooms” meaning creating email threads with multiple recipients.
Great for them. I want the other way around. ♥
“more interoperability with Matrix than any other messaging platform”— If Matrix can use IRC (they can use Libera at least, pretty easily) but IRC can’t use Matrix, where’s the “inter” part of interoperability? I can ask Matrix users out of band to join my channels on Libera, but if I see a Matrix room on a project web page, I can’t join it.
Matrix added a new thing and set it up as some sort of “standard”. I have a lot of patience with lobste.rs (“a mailing list, with an open source daemon and an unusually fancy web interface/archive”) and Gitter or Mattermost (“an IRC server, with an open source daemon and an unusually fancy web interface/archive”). I’m more salty over Matrix, since they did a completely new thing but still try to pawn it off as the most bridged&interoperable thing ever. Situation: There are 15 competing standards. 💔
@jch Here is maybe a good place to start for an email-to-Matrix bridge: https://github.com/orgs/simplebot-org/repositories?type=all
I have a question since I don’t normally use Matrix: can users join rooms across instances? If so, we’d only need one instance bridged, which is why https://github.com/matrix-org/matrix-ircd seems by far like the most hopeful of all the reverse bridges.
@Sandra Thanks for the link. It's something I might look into.
To answer your question: Yes, the joining of rooms across instances is what makes it 'federation'--like our two ActivityPub services are doing now. I have joined a few Freenode channels (i.e. joining #freenode_#[email protected]), and the experience is sub-par, mostly because of nickserv, netsplits, etc--good ol' IRC. :P
Each room can be configured to varying degrees of access from others.