AllBugsFeaturesChangelogSearchNew post
Sign in with Fluxer
Features

Support Matrix Federation

(#128) Feature Declined federation
by RexSystem edited originally by @Hedwig7s on GitHub

Problem

Federation is on the Fluxer roadmap, which is great, but creates a standard proliferation problem. Matrix is currently the largest federated chat platform, but with Fluxer implementing its own federation, it may attract users away who prefer the functionality over the privacy. This is fine and great for the user and Fluxer, but it fragments the ecosystem making users have to pick one or run both at the same time which can be annoying and be harmful for communities both ways. Also, Matrix already being decently established may make it more attractive for communities driving away interest from Fluxer.

Proposed solution

I would like to see, alongside the Fluxer federation, support for Matrix federation, likely at the relay level. Fluxer users should be able to join spaces and rooms in Matrix and Matrix users should be able to join communities and group chats/dms in Fluxer.

Notes (optional)

Matrix and Fluxer work fundamentally differently than each other, making mapping them to each other complicated and potentially unviable. Some notable differences include: Matrix rooms can both be in isolation and in a Space, Fluxer not having a decent equivalent to the former without a "Matrix Rooms" community, as rooms contain more complex permissions than group dms You can join a room without joining the space and vice versa, the latter can be solved by auto-joining on access but the former would require moving channels between communities and would not work properly with the members list Matrix rooms can be in multiple Spaces while Fluxer channels can only be in one, making it potentially necessary to clone the room between multiple communities Matrix uses permission levels while Fluxer uses roles (unsure if per-user permissions are supported) Matrix rooms hold their own independent permissions from Spaces while community roles span all channels, requiring lots of per-channel permission bridging Matrix rooms can be E2EE, requiring key storage and exchanging either by the client or the relay, otherwise encrypted rooms cannot be supported at all All Matrix rooms can host calls, while only voice channels can in Fluxer (afaik) Everything in Matrix is effectively a Room, while in Fluxer communities, dms and channels are separate types (afaik) Matrix rooms are either public, unlisted or Also, for voice channels: Matrix has 3 calling implementations, complicating implementation (although element call should suffice) Matrix has E2EE calls which are much more difficult to implement Excluding voice from federation wouldn't be too bad of a dealbreaker, but having it would be nice Alternatives to relay-level include: Instance level: Doesn't integrate well with Fluxer's federation setup and would suck if your instance didn't have support Client level: Likely cleanest, but not portable and would require essentially writing a matrix/fluxer client Puppeting bridge: Likely requires self hosting an instance, and far harder to set up while not avoiding any of the previous issues. Relay (type, not location) bridge: Requires per-community/space setup, also likely to require self hosting Client+relay level: Partial support on the client would significantly improve UX and reduce adaptation burden, but adds more work to the client + future clients This is a huge undertaking that is very unlikely any time soon if ever, and I understand if you do not wish to add this level of complication or work, but I will still open this issue for the sake of putting the idea forward and detailing limitations, as to increase the chance that such a feature is added and in case the platforms grow large enough as to merit interoperability I don't know how to end this so TL;DR Interoperability with matrix would be nice and beneficial, but complicated, I hope it's done eventually especially if both platforms become large enough (like bluesky/mastodon), but unlikely any time soon
  1. Rex changed the status from Won't fix to Declined

18 comments

Sign in with Fluxer to comment and vote.
Comment by @Screampuff
RexSystem 1 vote originally by @Screampuff on GitHub
Matrix is already extremely fragmented between clients and servers and lacks multiple core features that Fluxer already has. Fluxer trying to support Matrix would be, quite frankly, a wasted effort without far more effort on Matrix's side, which I would imagine they have zero interest in, considering both platforms have far different directions. It would be far more reasonable and realistic to make a matrix relay bot instead of trying to shoehorn compatibility into the base software.
Permalink
Comment by @Hedwig7s
RexSystem 1 vote originally by @Hedwig7s on GitHub OP
Matrix is already extremely fragmented between clients and servers and lacks multiple core features that Fluxer already has. Fluxer trying to support Matrix would be, quite frankly, a wasted effort without far more effort on Matrix's side, which I would imagine they have zero interest in, considering both platforms have far different directions. It would be far more reasonable and realistic to make a matrix relay bot instead of trying to shoehorn compatibility into the base software.
That's probably the easiest approach, but limited and difficult to set up Each community would have to manually set this up and bridge channels (which most of them won't bother to do), and would likely require self hosting the bot and a matrix homeserver or relying on a third party bot (which the best one for Matrix <-> Discord runs like absolute garbage) Too much friction IMO
Permalink
Comment by @AmeliaRhelicc
RexSystem 1 vote originally by @AmeliaRhelicc on GitHub
the communities that may overlap between sites are far and few since both products have different target audiences, so while a bot is hacky (i dont disagree) i dont think its something neither platform needs atm we don't know how federalization would materialize, there can be so many things that could be taken from matrix to do something even better, and the platforms are already vastly different, and i fear that making concessions to allow a connection between 2 platforms may limit the potential of fluxer's federation it may not be a protocol like how matrix handles stuff, it might just be auth where you can use your account of one server to access another server like ive seen people suggest in the testers server or it might be something future feature proof while still being some kind of protocol! i dont think that fluxer nor matrix should focus on catering each other's userbase, and i feel like fragmenting the chat platform space is a good thing for everyone as a whole even if inconvenient to some
Permalink
Comment by @metal0
RexSystem 1 vote originally by @metal0 on GitHub
i feel like fragmenting the chat platform space is a good thing for everyone as a whole even if inconvenient to some
"some" being the majority of humans on this planet? We shouldn't be finding ways to make the problem worse (XKCD 1810 ) Nevertheless, developing a Matrix client is a huge undertaking and certainly not something that this project probably wants to do at this point. While I do agree that having a discord-UI client but for matrix would be amazing (I'm currently working on one), I don't think it fits this project.
Permalink
Comment by @AmeliaRhelicc
RexSystem 1 vote originally by @AmeliaRhelicc on GitHub
We shouldn't be finding ways to make the problem worse (XKCD 1810 )
huh never saw it that way, i just felt it was natural to try and use different tools for different forms of communication and needs, i wouldn't use email for day to day communications but NEED it for work, i dont use whatsapp to communicate with friends but i do need it for family, and so on though i really like that insight thanks ^^, still i personally dont believe its a problem, its just human nature and trying to make something that is useful for everyone and everything will be hated by everyone sadly
Permalink
Comment by @MeguminSama
RexSystem 1 vote originally by @MeguminSama on GitHub
The current plan is to use relays for communicating between Fluxer homeservers. Additionally, I do think matrix federation is a HUGE undertaking that would probably be better served by creating a bridge server. If you run your own fluxer homeserver, you could even auto-create an account for each bridge user so that they're properly searchable rather than using webhooks.
Permalink
Comment by @Hedwig7s
RexSystem 1 vote edited originally by @Hedwig7s on GitHub OP
While it would be preferable for integrated support, I suppose a bridge server would likely be a better option I'll close this for now @metal0 Cinny does a pretty good job at that, especially with its WIP element call support
The current plan is to use relays for communicating between Fluxer homeservers.
I do have to ask, is there any reason for the Fluxer instances to not just communicate directly?
Permalink
Comment by @Nama
RexSystem 1 vote originally by @Nama on GitHub
We shouldn't be finding ways to make the problem worse (XKCD 1810 )
I'm with team federation with matrix. Especially XKCD 927...
i wouldn't use email for day to day communications but NEED it for work, i dont use whatsapp to communicate with friends but i do need it for family, and so on
That's not really a reasonable comparison. WhatsApp and matrix are for instant messaging, therefore comparable. I want E2EE, federation and therefore selfhost, text and VoiP, streaming. And that doesn't matters with whom... I want all this with everyone I chat.
Permalink
Comment by @lucyrose39
RexSystem 1 vote originally by @lucyrose39 on GitHub
I'm fully against federating with the matrix protocol. It's half baked and missing basic functionality that would hinder fluxer (mixed media messages for example are still not supported)
Permalink
Comment by @Hedwig7s
RexSystem 1 vote originally by @Hedwig7s on GitHub OP
I'm fully against federating with the matrix protocol. It's half baked and missing basic functionality that would hinder fluxer (mixed media messages for example are still not supported)
Why would this hinder the protocol? Make it a federation limitation not a fluxer limitation Just like iMessage but with good reason (there isn't an RCS for Matrix)
Permalink
Comment by @AstralPhnx
RexSystem 1 vote originally by @AstralPhnx on GitHub
> I'm fully against federating with the matrix protocol. It's half baked and missing basic functionality that would hinder fluxer (mixed media messages for example are still not supported) Why would this hinder the protocol? Make it a federation limitation not a fluxer limitation Just like iMessage but with good reason (there isn't an RCS for Matrix)
Compatibility with matrix would enforce effective feature parity with matrix, all its downfalls included, and at that point you'd basically be making another matrix client with extra steps. You'd be better off using a bridge at that point because trying to make two very different protocols work together is far from ideal
Permalink
Comment by @lucyrose39
RexSystem 1 vote originally by @lucyrose39 on GitHub
> > I'm fully against federating with the matrix protocol. It's half baked and missing basic functionality that would hinder fluxer (mixed media messages for example are still not supported) > > Why would this hinder the protocol? Make it a federation limitation not a fluxer limitation Just like iMessage but with good reason (there isn't an RCS for Matrix) Compatibility with matrix would enforce effective feature parity with matrix, all its downfalls included, and at that point you'd basically be making another matrix client with extra steps. You'd be better off using a bridge at that point because trying to make two very different protocols work together is far from ideal
This is correct. Integrating with the matrix protocol is a bad move
Permalink
Comment by @Hedwig7s
RexSystem 1 vote originally by @Hedwig7s on GitHub OP
> > I'm fully against federating with the matrix protocol. It's half baked and missing basic functionality that would hinder fluxer (mixed media messages for example are still not supported) > > Why would this hinder the protocol? Make it a federation limitation not a fluxer limitation Just like iMessage but with good reason (there isn't an RCS for Matrix) Compatibility with matrix would enforce effective feature parity with matrix, all its downfalls included, and at that point you'd basically be making another matrix client with extra steps. You'd be better off using a bridge at that point because trying to make two very different protocols work together is far from ideal
Literally the only difference between bridging and more native federation would be higher availability and the ability to smooth it out a bit at the client level (which isn't even necessary, just nice to have) at the cost of it being a bit more integrated than a seperate bridge and thus needing some more work You do not compromise the protocol for compatibility you compromise the federation You have to be in a community to join a channel? Block joining them without already being in the equivalent space Matrix can't do multi file type messages? Don't federate them Matrix can't have media and messages together? Send 2 Roles and permission level clash? Do a best guess permission level and reject messages that violate the role Don't think a channel can be federated properly without major issues? Don't federate it And for most Fluxer -> interactions they can be mapped pretty cleanly, heck just one way federation to Matrix would be nice I'm struggling to see why the ability to interop would require crippling Fluxer
Permalink
Comment by @rajil
RexSystem 1 vote originally by @rajil on GitHub
Yes, please. Matrix federation would be great.
Permalink
Comment by @lucyrose39
RexSystem 1 vote originally by @lucyrose39 on GitHub
> > > I'm fully against federating with the matrix protocol. It's half baked and missing basic functionality that would hinder fluxer (mixed media messages for example are still not supported) > > > > Why would this hinder the protocol? Make it a federation limitation not a fluxer limitation Just like iMessage but with good reason (there isn't an RCS for Matrix) > > Compatibility with matrix would enforce effective feature parity with matrix, all its downfalls included, and at that point you'd basically be making another matrix client with extra steps. You'd be better off using a bridge at that point because trying to make two very different protocols work together is far from ideal Literally the only difference between bridging and more native federation would be higher availability and the ability to smooth it out a bit at the client level (which isn't even necessary, just nice to have) at the cost of it being a bit more integrated than a seperate bridge and thus needing some more work You do not compromise the protocol for compatibility you compromise the federation You have to be in a community to join a channel? Block joining them without already being in the equivalent space Matrix can't do multi file type messages? Don't federate them Matrix can't have media and messages together? Send 2 Roles and permission level clash? Do a best guess permission level and reject messages that violate the role Don't think a channel can be federated properly without major issues? Don't federate it And for most Fluxer -> interactions they can be mapped pretty cleanly, heck just one way federation to Matrix would be nice I'm struggling to see why the ability to interop would require crippling Fluxer
An incomplete or non feature complete integration would just add frustration and friction for users who do not care about nor want matrix. If the goal is a replacement to discord and modern chat apps, matrix isn't a part of it as the matrix protocol itself has not been updated with basic features for many years now. It's dated and proven that it cannot keep up with the demands of modern chat needs. A bot using webhooks for the small group of people who want matrix is the better albeit more janky solution. Adding a bunch of bolt ons to a new, clean system just bogs down an otherwise lightweight app. To the devs, please do not make this a native feature.
Permalink
Comment by @multimokia
RexSystem 1 vote originally by @multimokia on GitHub
In my opinion it makes more sense to just develop a new client that looks like fluxer but operates on the matrix protocol. Fluxer and Matrix under the hood are operationally very different, having to build an adapter for it sounds like a lot of issues especially in how sync would work. I think Fluxer should focus primarily on getting itself to a stable point. Matrix's approach also has problems that are well documented here: Why not matrix? And given the issues, it's understandable why many would not want to federate with Matrix.
Permalink
Comment by @filips123
RexSystem 1 vote originally by @filips123 on GitHub
If Matrix is inappropriate for Fluxer federation, have you considered XMPP, which might be more, well, extensible, so it might work better in this case? Other clients still won't be able to access Fluxer-specific features, but at least accounts and basic messages could be federated, and if other features would be added as XEPs, other clients could also support them eventually.
Permalink
Comment by @chocmake
RexSystem 1 vote originally by @chocmake on GitHub
Matrix's approach also has problems that are well documented here: Why not matrix?
This touches on some things I've been wondering about in terms of how Fluxer will handle federation. Since one of the issues with Matrix is deleted content can persist via other servers that ignore such requests, which can include legally problematic content and spam (apart from things like accidental self-doxxing, etc). Mastodon, which uses ActivityPub, is another example with this issue. Servers can use blocklists for unwanted instances but this seems to assume too much good faith as a default and ironically from what I've read introduces a catch-22 where deletion requests can't be propagated to blocked instances that store any pre-blocked mirrored data, so even if some of those instances would respect the request it causes the data to persist non-deliberately. If Fluxer's approach was anything similar I'm not sure whether it'd necessitate some integrity check between self-hosted servers that they're running a known-good version of Fluxer that respects proper content sync. Obviously nothing would stop forks from just removing such a check and federating among themselves. Maybe this is already a solved problem in some other federated platforms?
Permalink