[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.