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