Huh, I was going to point out that the Signal server isn't Free Software either, since for a while it wasn't being published, but it seems they have gotten back into publishing it.
while it's amazing for them to keep maintaining it, as the person mentioned down the thread, it's hard to know what they are actually running, right? and it's not a lot of work to patch this or clone/branch as necessary before deploying. Oh well, i already resigned that a part of my life will be run by someone else by now.
Publishing server code provides no assurance of anything (although it is still nice, for other reasons) since nobody can know if what they (for any "they") run in production is the same as the public source.
Open client code and documented protoccols are much more important. If you can compile your own client from open source code and it works fine, then you can know for sure what you're sending to the server.
If you bothered to look, you would find that both of the examples given are open-source servers. You might then deduce that you misunderstood the comment to which you replied.
You cannot audit the system/service logs for those servers, neither can you audit the hardware running those servers, nor the internet providers who can snoop on the traffic et al... That's the argument behind "Open source server" in case it wasn't clear.
Not sure what part of my comment amused you so much.
An IM platform server can be open sourced. Just like any kind of software.
It's just a matter of publishing your code and, preferably making it possible to verify that the service your users are connecting to is build using the same published code.
How could you possibly verify what code they are running server-side?
Typically, the way it goes is that you implement e2ee such that even a fully compromised server cannot read the clients messages, publish the client's source code, and build it yourself or use reproducible builds. That ladt part is where you can criticize Signal. Whether they publish the server code is mostly irrelevant unless you want to run a separate messenger infrastructure.
> unless you want to run a separate messenger infrastructure.
Or if you S2S federate with the upstream server. Which is a core differentiator of XMPP and Matrix. Signal server(s) notably supported proper federation during their initial growth-phase but famously closed it off ("The ecosystem is moving").
Similar story as Google [Chat/Talk/Hangouts], which did federate over XMPP before they closed that down years ago.