[moxie]

I'm repeating myself on many of these points, so I've cut and pasted some of my previous responses:

> Signal uses servers controlled by OWS. Other organizations could conceivably operate their own servers because OWS open sources the software, but because OWS strictly opposes federation (meaning the interconnection of independently operated servers which the XMPP protocol (jabber) or e-mail allows), only the users connected to the OWS-run server can communicate with each other.

I've tried to write about why I don't feel like this is going to be a part of our future here: https://whispersystems.org/blog/the-ecosystem-is-moving/

However, I would love it if someone proved me wrong. The Signal clients and server already support federation, so there shouldn't be any technical hurdles stopping the people who are really into federation from using our software to start their own federated network that demonstrates the viability of their ideas.

If anyone needs help doing that, let me know. I'd be happy to help.

> If a government does not approve of the use of Signal, it can simply block a single server farm, solving the problem for the state actor, and resulting in total loss of service to the users.

The authors of this article conflate a lot of things with federation. Federation = anonymity, federation = metadata protection, federation = censorship circumvention.

I don't think any of those are true. Email is federated, and I run my own mail server, but almost every single email I send or receive has GMail at the other end of it -- so running my own server does not provide me with any meaningful metadata protection, even though it is a federated protocol. The idea that everyone in the world is going to run their own mail server (or messaging server, or whatever) has not born out in practice, even in environments that natively support federation.

I think serious metadata protection is going to require new protocols and new techniques, so we're much more likely to see major progress in centralized environments that can change rather than federated environments that are stuck in time (in the same way that Signal Protocol is now on over two billion devices, but we're unlikely to ever see even basic large scale email end to end encryption).

In the case of censorship circumvention, I think it's much more common that people use censorship circumvention tools like VPNs or Tor rather than changing their entire federated identifier (and somehow re-discovering their entire social graph doing the same) every time a service gets blocked, particularly since censorship isn't just as simple as host-level filtering these days.

Again, I think we're more likely to see the incorporation of these types of censorship circumvention techniques into centralized rather than federated services.

> The community reacted to this by developing a version that does not rely on GCM, however, OWS refused to merge the changes into the Signal code.

I don't believe this is true. To clarify this for casual readers, no data at all is transmitted over GCM. GCM is only used as a push event to tell the Signal Android client to wake up and connect to the Signal server to retrieve messages from the queue if the app isn't in the foreground.

This is pretty fundamentally just how Android works. However, people who want to use Google's OS without any Google services flash custom ROMs onto their devices that are missing this dependency.

I have said many times that I have no problem with supporting these custom ROMs. But I would like someone from that community to submit the PR: "I would consider a clean, well written, and well tested PR for websocket-only support in Signal. I expect it to have high battery consumption and an unreliable user experience, but would be fine with it if it comes with a warning and only runs in the absence of play services."

Nobody has done it.

> The final point of criticism is that OWS distributes the Signal app exclusively via Google Play while actively preventing the distribution of independent builds.

We'd love to distribute Signal outside of Play, and have written about what we would need to be able to do so. As of yet, nobody from the FOSS community has stepped in to help.

We'll get there eventually on our own, but we have a lot of work on our plate, and have to set our priorities according to what we think is important for Signal as a whole.

> The community’s demands for decentralized web services controlled by the users themselves, or by designated professionals elected by the users, seems like a burden to them.

I do not feel like the FOSS community is a "burden," however I do wish they recognized that many of their desires are unique to a very small minority of Signal users. I wish that they'd take more responsibility for manifesting those desires themselves.

This is the second time in two months that someone from the FOSS scene has written up a list of complaints, but as far as I know, in neither case have the authors ever contributed anything to Signal in an effort to meet their own needs.

[eggie]

I really like Signal, at least as far as I can tell from the UI and the single conversation I've managed to have using it.

The biggest problem that we (my whole friend group) seem to be having is that we can't find each other due to the fact that we don't use phone numbers for communication.

Are you thinking about ways to resolve this problem?

Is it any less secure to use email addresses for identification and discovery than phone numbers?

What about ways to share a unique user id?

[eggie]

> I do not feel like the FOSS community is a "burden," however I do wish they recognized that many of their desires are unique to a very small minority of Signal users. I wish that they'd take more responsibility for manifesting those desires themselves. > This is the second time in two months that someone from the FOSS scene has written up a list of complaints, but as far as I know, in neither case have the authors ever contributed anything to Signal in an effort to meet their own needs.

I think that the interest in the FOSS community is relatively low given the centralized format in which Signal is offered. I know many people who are deeply into FOSS who would love an alternative to IRC but cannot be found even using Signal. But "their own needs" are completely out of bounds for you, and it seems pretty clear that this isn't something that's going to be fixed in patches and code, so expecting them to come and fix it because you have an open code base is rather disingenuous.

If you started by promoting Signal as a generic protocol or backend to other projects, it would get much more traction in the FOSS community, as they are attracted to components on which other things can be built.

You can claim that this is a reason to ignore the criticism. But, you will always be right in dismissing critiques like this as you've set up the environment in a way which limits the kind of constructive collaboration that is the hallmark of FOSS.

You will probably say this is not true and cite existing public contribution to the project. But what I am saying is that the interest and contribution would be orders of magnitude larger if you really ran the project in a traditionally open way. One hallmark of this would be federation. Whether or not this makes sense practically (the gmail metaphor applies obviously), it is something that people want an need to order to feel they have ownership of their work on a messaging platform. You're simply not going to talk your way out of this.

For human and community reasons, the upside to federation is probably a lot higher than you appreciate. I hope you consider it. You have built a nice platform, but for your work to make a lasting impact you need to share it with others.

[moxie]

> But "their own needs" are completely out of bounds for you, and it seems pretty clear that this isn't something that's going to be fixed in patches and code, so expecting them to come and fix it because you have an open code base is rather disingenuous.

Many of the things listed in these articles, such as making GCM optional, or supporting distribution outside of Play, are not "completely out of bounds." We've expressly indicated support for them and enumerated the work required, but nobody has committed to doing the work.

I don't expect anyone to do the work, but I do think it's strange when someone from the FOSS community complains that we haven't done it for them.

> If you started by promoting Signal as a generic protocol or backend to other projects, it would get much more traction in the FOSS community, as they are attracted to components on which other things can be built.

Signal is broken into three layers, two of which are designed to provide exactly that:

A crypto protocol that can be incorporated into other projects: https://github.com/whispersystems/libsignal-protocol-java

A service protocol that can be pointed at any back end: https://github.com/whispersystems/libsignal-service-java

The service protocol even includes support for federation. I don't think it's a good idea for the reasons I've enumerated, but anyone can use this code to start their own federated network and prove me wrong.

> For human and community reasons, the upside to federation is probably a lot higher than you appreciate. I hope you consider it. You have built a nice platform, but for your work to make a lasting impact you need to share it with others.

We've done more than consider it, we've done it. We started Signal as a federated service, and it was kind of a disaster.

I'd definitely reconsider if people have a plan for avoiding the problems that we encountered the first time, beyond "federation is good." In the mean time I'm happy to help anyone deploying Signal in their own federated environment.

[eggie]

> Many of the things listed in these articles, such as making GCM optional, or supporting distribution outside of Play, are not "completely out of bounds." We've expressly indicated support for them and enumerated the work required, but nobody has committed to doing the work.

> I don't expect anyone to do the work, but I do think it's strange when someone from the FOSS community complains that we haven't done it for them.

The linked article notes that you have not been so supportive of such developments in the past:

> The community reacted to this by developing a version that does not rely on GCM, however, OWS refused to merge the changes into the Signal code. When the project was forked, they prevented the newly established LibreSignal project [5] from connecting to Signal’s servers and prohibited the use of the term “Signal” in their name.

Reading through the comments that are linked it looks like you mostly had technical concerns about the work. Is that correct?

Clearly the perception of your actions is different than you intend. In your comment here you make it sound like no one had even attempted to do resolve these issues. But that's not what the author of the article believes, and given the public record I'm inclined to agree.

> I'd definitely reconsider if people have a plan for avoiding the problems that we encountered the first time, beyond "federation is good." In the mean time I'm happy to help anyone deploying Signal in their own federated environment.

Your key point is that you're content if people do federation in their own, outside of your domain. That's fair. But what I'm saying is the dream of a federated secure messaging system that's also popular is something which you have the power to chase if you commit to it by making it a core feature of Signal.

[moxie]

> Reading through the comments that are linked it looks like you mostly had technical concerns about the work. Is that correct?

> Clearly the perception of your actions is different than you intend. In your comment here you make it sound like no one had even attempted to do resolve these issues. But that's not what the author of the article believes, and given the public record I'm inclined to agree.

From that original discussion on LibreSignal:

"If the only thing that the remaining people here want out of LibreSignal is a websocket-only solution and gmscore isn't an option for whatever reason, I would consider a clean, well written, and well tested PR for websocket-only support in Signal. I expect it to have high battery consumption and an unreliable user experience, but would be fine with it if it comes with a warning and only runs in the absence of play services. However, I also realize that still won't help people that are trying to build a Google-free experience on Google's platform, since we still don't have the things we need to be comfortable distributing software outside of Play."

I have repeated that many times. That was June. Nobody has done the work, but plenty of people have written articles like this. The latter is definitely easier.

> Your key point is that you're content if people do federation in their own, outside of your domain. That's fair. But what I'm saying is the dream of a federated secure messaging system that's also popular is something which you have the power to chase if you commit to it by making it a core feature of Signal.

Again, we already committed to making it a core feature of Signal, and it was a disaster. We've learned from our mistakes.

If it's something that you think is important, please get involved in the project and come up with a plan to introduce federation in ways that actually deliver on the promise of metadata hiding, anonymity, and censorship circumvention as well as avoid all of the problems that we documented based on our initial attempts.

[pvg]

I think that the interest in the FOSS community is relatively low given the centralized format in which Signal is offered.

How is Signal offered in a 'centralized' way? There is a free and open-source implementation that already (according to Moxie) supports federation. And a standing offer from the authors to help anyone doing further work on federation. What more could one reasonably expect, short of demanding OWS do the work.

[eggie]

Do read the linked article. It describes the situation quite a bit better than I can.

[pvg]

I've read the article and am asking about your comment. No amount of reading the article is going to make it clear.