Edit history

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

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

Checks

• ☑ I searched for existing issues and didn't find a duplicate.