search

wireapp / wire

:wavy_dash: Overview of the open source code for Wire
https://wire.com
GNU General Public License v3.0
2.4k stars 173 forks source link

Wire servers can't federate with each other #266

Open strypey opened 5 years ago

strypey commented 5 years ago

A lot of people are interested in being able to self-host a Wire server for them and/or their family/ friends/ organization, and still be able to communicate over Wire with users on the flagship Wire server, and on servers hosted by others. Some of the reasons for this are discussed in #160 and #219 .

You might ask how this would be good for Wire as a company, since in theory, it would allow other companies to set up servers in competition with them. I've had a lot of discussions recently with folks who see Wire as being equivalent to Signal (or even Telegram), and who prefer to use and promote Matrix or XMPP because they are federating chat technologies. Even though they concede that Wire has a more intuitive UX for non-geeks than most (if not all) Matrix and XMPP apps, especially when you factor in E2E encryption. If Wire servers could federate, a lot more early adopters would become interested in using and promoting it. The only arguments that would remain for using Signal would be claims that their security model or execution are technically better.

This increase in interest among the software freedom community might also increase the number of people willing to make outside contributions to the Wire code. This might lead to the development of non-Electron clients, support for a wider range of platforms, maintaining backwards compatibility with 32-bit systems, and many other things that could benefit Wire users, but are not a priority for Wire as a company.

I'm wondering if the Wire team has agreed in principle that server>server federation is a goal you want to pursue, but that it's proving to be technically complicated to make it work without compromising your security goals? If so, here's what I suggest. Put up an official blog post stating that server>server federation is a design goal, and will be part of Wire in the future. Invite anyone with relevant programming skills, and especially knowledge of cryptography, to have a look at your server code and help make that happen. You might be surprised by how much help would be forthcoming.

raphaelrobert commented 5 years ago

Hi @strypey,

Thanks for the post! Federation is still very much on the roadmap and we even started to talk about it in this blog post: https://wire.com/en/blog/mls-meeting-summary/ Federation will be tied to MLS, as MLS brings new security guarantees that don't exist in current protocols and are important for secure federation. For more information, see https://datatracker.ietf.org/doc/draft-omara-mls-federation/ We will publish more on the subject as the project progresses.

As for other clients, we would like to see that as well. Currently we focus our resources on the electron client, but we welcome help on other clients, such as e.g. coax.

strypey commented 5 years ago

That's great news! Very exciting that there is a common protocol for this being standardized at the IETF. I've posted about this on the fediverse.

Can you point to any particular parts of the Wire server (or client) code where federation work is being done (or needs to be done), in case anyone from the community wants to help? Also, can you please leave this issue open, and have someone from your team pop back with an update whenever anything significant happens that moves you closer to getting federation working? Once it is, of course, that can be mentioned here and the issue closed.

stevenroose commented 5 years ago

There is already a discussion going on about XMPP federation in here: https://github.com/wireapp/wire-server/issues/631.

strypey commented 5 years ago

Wire could apply for EU Next Generation Internet funding for "Privacy and Trust", to work on standardized server>server federation code that supports E2EE and other privacy protection measures: https://nlnet.nl/PET/

winie commented 3 years ago

After this feature, is a Matrix <-> Wire connection possible?

dm17 commented 2 years ago

Hi @strypey,

Thanks for the post! Federation is still very much on the roadmap and we even started to talk about it in this blog post: https://wire.com/en/blog/mls-meeting-summary/ Federation will be tied to MLS, as MLS brings new security guarantees that don't exist in current protocols and are important for secure federation. For more information, see https://datatracker.ietf.org/doc/draft-omara-mls-federation/ We will publish more on the subject as the project progresses.

As for other clients, we would like to see that as well. Currently we focus our resources on the electron client, but we welcome help on other clients, such as e.g. coax.

Is there an ETA or roadmap for MLS? Kind of waiting on this to start self-hosting. Will be epic!

@strypey - exactly!

strypey commented 2 years ago

@dm17:

Is there an ETA or roadmap for MLS? Kind of waiting on this to start self-hosting.

While you're waiting, you could try out other options for self-hosting federated chat:

dm17 commented 2 years ago

Hi @strypey,

Thanks for the post! Federation is still very much on the roadmap and we even started to talk about it in this blog post: https://wire.com/en/blog/mls-meeting-summary/ Federation will be tied to MLS, as MLS brings new security guarantees that don't exist in current protocols and are important for secure federation. For more information, see https://datatracker.ietf.org/doc/draft-omara-mls-federation/ We will publish more on the subject as the project progresses.

As for other clients, we would like to see that as well. Currently we focus our resources on the electron client, but we welcome help on other clients, such as e.g. coax.

Any news on this you can share? Matrix and XMPP are not of interest to me really. getsession.org is a potential solution, but I wonder about video and audio calls. I haven't checked out delta.chat yet. Thanks!