391–400 of 403 posts
Earlier quoted context omitted.
So are you telling me I can run my signal server and use it to communicate with others on the signal network?
You can run your signal server and use it to communicate with others on your signal network. The openness or otherwise of the code has literally nothing to do with the terms of use of any service being run.
The product _is_ the network. By restricting access to the network, access to the product is also curtailed.
Earlier quoted context omitted.
In which world does Microsoft conform to open standards or protocols? Your point simply doesn't make sense.
Microsoft's Windows APIs are, in some sense, an "open platform". They don't accept third party contributions, but they are thoroughly documented and their whole purpose is to support third party developers. Because that's their goal, they won't ever break that backwards compatibility. That, I think, is what the GP was getting at - the Signal team does not want to wind up being constrained in the ways that MS is by su…
Win32 is an open API in a certain sense. Of course it's not open as in open source as in consensus and cooperative standards as in FLOSS, at all. But. It's well documented. Anyone can target it. It's stable.
Textbooks on Windows Vista programming 15 years ago are almost completely applicable to Windows 10 development. Even software that was targeted at a reasonable subset of the Windows 95 API, whether binary or source, is still going to run on Windows 11 without change in many cases. You get notice of what parts of the API they're gonna break in the next version (usually) too.
In the olden days this was an "open platform" meant, usually. It's what the open in OpenWindows, OpenUnix, OpenStep was about. An open API. As opposed to a possibly undocumented, unstable API you only used under special contract and arrangement with the supplier. Often there was no actual prohibition (legal or technical) but there'd be no support. And it'd break randomly without notice.
As you say, it's a potentially enormous commitment, and organizational issue, to provide that sort of long-term API stability. And you can box yourself in regarding development and design choices.
Earlier quoted context omitted.
It is a hypothetical scenario for the purpose of an example. It could have been literally anything, the point is for it to be rare.
Yes, but the fact that scenario is hypothetical doesn't counter my argument that whatever the developer thinks is rare is actually rare.
I hope this gets the point across. Yes, maybe what he said is not rare, but that is besides the point.
Earlier quoted context omitted.
This is a messaging app we're talking about here. There's nothing outrageously difficult or complex that hasn't already been done 25 years ago. If 36 people and $100 million in funding is not enough to make a messaging app that doesn't suck, what _is_ required and why is it more than that?
> This is a messaging app we're talking about here. There's nothing outrageously difficult or complex that hasn't already been done 25 years ago. If you think it's so easy, be your own change and do it, and then we can judge the results. > If 36 people and $100 million in funding is not enough to make a messaging app that doesn't suck, what _is_ required and why is it more than that? You're assuming there's a solutio…
Earlier quoted context omitted.
Signal placing restrictions on who can use their service has nothing to do with whether or not people can contribute to the codebase.
It does. There is less incentive to work on a Signal client fork if it can't be used to interoperate with the Signal service.
Earlier quoted context omitted.
You can run your signal server and use it to communicate with others on your signal network. The openness or otherwise of the code has literally nothing to do with the terms of use of any service being run.
No. The product _is_ the network. By restricting access to the network, access to the product is also curtailed.
So what's your point? Do you think everyone should have a right to connect to their servers however they like, and the service operator can't exert any control over that?
Earlier quoted context omitted.
> It's not reasonable or constructive to expect their software to never have bugs I think nobody demanded anything of that sort, that is just a strawman. What was actually demanded is that priority of such bugs be raised, and perhaps users be adequately warned about known defects that may compromise the confidentiality of their messages. That Signal developers didn't have an idea what was going on for 6 months? And t…
> I throw around the label "proprietary" because software which doesn't come with source code is in fact, proprietary. If Signal pushes new server code to production and keep its source to themselves, calling that still "open source" requires serious mental gymnastics. It comes with source code, just not on your time-frame. That's still open source. And if that's unacceptable to you, just use something else. >> Signa…
Everyone can of course have their own opinions. But they cannot have their own facts, a discussion does not work that way.
Whether one considers some statement as entitled, that is an opinion and we can disagree about this.
But whether a program is open source or not is a fact. It doesn't matter if the source code is going to be released a day or a year after the Signal server has been pushed into production, at that very moment the program is not open source. Your comment about my time-frame is irrelevant. In the github issue 11101 link I posted above is Moxie admitting to running versions of the server that are ahead of the public git repository. These are factually closed source, and you continuing to argue against that fact doesn't reflect well on you, nor the ability to have serious discussions with you.
Earlier quoted context omitted.
It does. There is less incentive to work on a Signal client fork if it can't be used to interoperate with the Signal service.
That's a bit like saying there's less incentive to work on (for example) Elasticsearch, because you can't deploy your fork on Elastic Co's official managed service. It's nonsense.
Earlier quoted context omitted.
> You must force everyone in the ecosystem to use the latest version of the API Couldn't Signal just announce a "flag day"[0] in advance and say that their servers would block connections from clients that don't support a specific version of the API by that date? For non-essential upgrades, the API change should be announced well in advance, but client developers might be given just a few days notice before security…
They could, but again it's not just about the API, the client itself must also be secue enough. That means enforcing security in some way to third parties, or just blocking them until they've solved all issues. And in practice if you let people migrate at their own pace they just won't migrate until clients complain.
I'm sure there are cases where a third party client would be less secure and Signal would be justified in refusing to relay messages to/from that client, but what about situations, like the current one, where it is Signal itself that is insecure? To be consistent, shouldn't Signal have to block their own client until they fixed the issue?
Even if you accept the idea of Signal having a (inconsistently applied) veto over which apps are allowed to use its infrastructure, how far do you take it? Should they deliberately brick official Signal clients running on versions of iOS or Android that are deemed insecure? Should they require that the phone manufacturer is "trustworthy" so that it doesn't risk containing Chinese government spyware?
Taken to extremes, Signal would need to come with its own antivirus scanner or support some sort of remote attestation of all the versions of all the software running on the phone, to prevent messages being leaked through side-channels. And what would that achieve, other than pushing people to use other, less secure apps?
I think it is a dangerous distraction for Signal's threat model to worry about anything other than making their own app secure, and making sure that the protocol supported by their servers is secure.
Earlier quoted context omitted.
> I throw around the label "proprietary" because software which doesn't come with source code is in fact, proprietary. If Signal pushes new server code to production and keep its source to themselves, calling that still "open source" requires serious mental gymnastics. It comes with source code, just not on your time-frame. That's still open source. And if that's unacceptable to you, just use something else. >> Signa…
> We're going to have to agree to disagree there. Everyone can of course have their own opinions. But they cannot have their own facts, a discussion does not work that way. Whether one considers some statement as entitled, that is an opinion and we can disagree about this. But whether a program is open source or not is a fact. It doesn't matter if the source code is going to be released a day or a year after the Sign…