Commit
- Loading branch information
There are no files selected for viewing
36 comments
on commit 873e7d7
There was a problem hiding this comment.
@infinity0 Because LibreSignal is using WhisperSystems servers.
There was a problem hiding this comment.
@vanitasvitae please explain how that prevents LibreSignal from working. I don't think it's technically feasible for OWS to distinguish LibreSignal from Signal-Desktop or any other "official" client, to be able to block it.
There was a problem hiding this comment.
It dies not prevent LibreSignal from working and I dont know whether OWS can distinguish LibreSignal from their client.
Nevertheless LibreSignal is targeting a "foreign" server. I know it's a shame that @moxie0 doesn't tolerate 3rd party clients on his servers (which are mostly funded by the community), but that's the current situation. If you want to continue to use LibreSignal you are free to do so. There will probably be no updates though.
For more background information see #37
There was a problem hiding this comment.
Yes I was on that thread, I just don't understand the conclusion "moxie doesn't like it, therefore we won't do it". Thanks for clarifying that this is not a technical issue. I encourage anyone else reading this to disregard moxie's opinions and continue hacking. Feel free to contact me for help in case of any legal threats.
There was a problem hiding this comment.
I should add that I am not a member of the developer crew, so this is not an official statement :)
There was a problem hiding this comment.
They can distinguish LibreSignal users from Signal users because:
- LibreSignal has "LSA" as "USER_AGENT" (Signal has "OWS").
- LibreSignal keeps a WebSocket connection with the server.
There was a problem hiding this comment.
But all of this could be fixed - just make it behave like an official OWS client that uses WebSocket. We do a similar strategy for various anti-censorship tools. Yes, they can put more extra money into developing more complex analysis, but then it becomes a cost trade-off game. (The long-term goal of course is to move away from these centralised technologies, but short-term we can keep playing with relatively little cost, is what I'm saying.)
There was a problem hiding this comment.
But that is not the point. It is better to focus on something like XMPP, that doesn't rely on phone numbers. On XMPP, there is no central server, that collects all metadata and that everybody has to rely on.
There was a problem hiding this comment.
That's exactly what I said in my last sentence. In the meantime though, we don't have yet a good solution for async e2e encrypted messaging. One can enable offline message delivery in XMPP, but the inherent nature of OTR is to destroy session state when the program closes / your phone restarts. Then you can no longer read OTR ciphertext in your offline queue.
There was a problem hiding this comment.
And therefore it's good to keep LibreSignal alive as a temporary measure. (Of course I appreciate if it's too much effort, then by all means don't do it. But other people could step up. There are no intrinsic barriers to keeping this thing alive.)
There was a problem hiding this comment.
The point is that LibreSignal will never be officially hosted on main F-Droid or an officially licensed repository. We can't use calls for the reasons mentioned in #37 and we may as well just use Signal or some such. Since LibreSignal would only face more issues and has all of the metadata problems that Signal does. Personally I can't avoid the Play Store and google services for now because non-ASCII keyboards, especially for complex input are practically non-existent outside of the Play Store.
There is very little advantage to LibreSignal even temporarily. You can still use the current code for as long as you want.
There was a problem hiding this comment.
A better choice is Conversation app that supports OMEMO encryption...
There was a problem hiding this comment.
That's what the talk in #37 is all about. The future of collective efforts is finalizing OMEMO (effectively Axolotl for XMPP). Conversations is being merged with ChatSecure for Android and CahtSecure-iOS will continue on. They are working on a non-GPL implementation of OMEMO. Zom is from the same team as ChatSecure and is an easy way to get set up for beginners. The reference implementations will likely be ChatSecure and then Zom and then hopefully other apps, especially PC ones like Pidign, Instantbird and TorMessenger pick it up as well. The non-GPL license will go a long way in helping that.
So @mimi89999 Conversations is the place to be, so to speak. It is the gold standard just as Pidgin-otr is the gold standard for OTR.
There was a problem hiding this comment.
I know you know this. I'm just putting it all together. Basically, I feel vindicated in pressing for Conversations over KonTalk for now,
There was a problem hiding this comment.
I know it's a shame that @moxie0 doesn't tolerate 3rd party clients on his servers (which are mostly funded by the community), but that's the current situation.
One of the reasons we don't make an effort to solicit donations from users is because there are already a very vocal group of people who are incredibly rude and act amazingly entitled even when they're not paying anything, so we shudder to think how they'd act if they had paid $1. It's funny that even after we've tried to avoid situations like this, here you are suggesting that you should be entitled to do whatever you want because you're "mostly funding" this service anyway! How, exactly, did you come to that conclusion?
Yes I was on that thread, I just don't understand the conclusion "moxie doesn't like it, therefore we won't do it". Thanks for clarifying that this is not a technical issue. I encourage anyone else reading this to disregard moxie's opinions and continue hacking. Feel free to contact me for help in case of any legal threats.
Listen, you can do what you want, but I'd prefer that you didn't use our service. You're free to use our software under the terms of the license, but we ask that you don't use our name or our service. If you really can't understand why people would choose to honor the preference of the organization that's developing this software and hosting the service for free, there's probably not anything more I can say at this point. If we're really so evil, though, I'm not sure why you'd want to.
There was a problem hiding this comment.
It's funny that even after we've tried to avoid situations like this, here you are suggesting that you should be entitled to do whatever you want because you're "mostly funding" this service anyway! How, exactly, did you come to that conclusion?
I did not say I'm entitled to do anything. The project is already dead, so it doesn't matter anyway. I just expressed my opinion. I am disappointed that you do not tolerate LiberSignal on your servers AND do not allow federation. This is in stark contrast to what I have experienced in the free software world so far. Even Telegram encourages 3rd party clients.
Of course it's your good right to forbid 3rd party clients. Nevertheless you have to live with the consequences and other peoples opinions.
But since the project is dead anyway, let's end this discussion or move it to #37.
There was a problem hiding this comment.
@moxie0
For what it's worth, thank you for the largely unpaid work making a successor to OTR. There was no guarantee you'd get paid to consult for a company that is owned by Facebook or Google.
If Moxie wants to keep his own implementation GPL3 and only re-license to others for money, it may be frustrating for us, from a self-centered viewpoint, but it's his prerogative. No one is harmed by closed source apps using Axolotl. WhatsApp would have 99% of the same userbase but without E2E encryption. It's no worse than FLAC or Ogg using MIT license and proprietary companies using it.
It's only an "unfair" advantage on iPhones with the pesky AppStore, but without Moxie we'd have nothing anyway.
And since we LibreSignal users are interested in a federated protocol, then we need a new implementation anyway.
OpenWhisperSystems servers act as a charity and I can understand not wanting others on it. Totally ethical behavior.
I only use riseup.org's resources for politically related stuff, (I should donate at some point, too) and occasionally, and keep data usage low. They ask for that. I respect that. I don't want to jeopardize service for whistleblowers just so I can upload dozens of 1.5 MB photos and send them to my family.
Asking for OpenWhisperSystems to provide free hosting for our communications when the owner is against it is really out of line
There was a problem hiding this comment.
It's only an "unfair" advantage on iPhones with the pesky AppStore, but without Moxie we'd have nothing anyway.
Thanks for the kind words! For the record, we've also repeatedly told OSS projects that we have no problem with them distributing our GPL software through the app store. We're looking into ways that we can formalize that in a license, it's not our intention to prevent OSS iOS apps from using our libraries.
There was a problem hiding this comment.
For the record, we've also repeatedly told OSS projects that we have no problem with them distributing our GPL software through the app store. We're looking into ways that we can formalize that in a license, it's not our intention to prevent OSS iOS apps from using our libraries.
That are really good news!
There was a problem hiding this comment.
That's really great! I hope that the licensing issue will finally be clarified by an official statement from OWS.
There was a problem hiding this comment.
In the modern digital world, lots of services are free. It doesn't mean that users are selfish or rude, for criticising those services for not providing basic levels of freedom, or asking for it for free. Services make their money back via other means - some by advertising, OWS by grants from OTF and other sources. In many cases, free users help the service via a network effect. The work is definitely not "unpaid" and it is not relevant that was "no guarantee at the start" he would make money - it is now being funded adequately, and OWS would have packed up shop if this hadn't happened.
So trying to shame free users, and abusing the fact you made some very nice past contributions, to milk unlimited amounts of praise from everyone, to deflect the criticisms - this tactic is not sincere and is inaccurate about the overall picture.
We are not causing you any more economic damage in using LibreSignal, than if we used the official client. Federation is an unrelated point; I am only focusing on client flexibility here. You claimed elsewhere that "the difference is huge; one we have control over, the other we don't." But the control does not translate into actual economic damage. There is also no future economic model where this is likely - either it stays a trivial minority, or you will see way in advance its growth, easily accommodate for it, and maybe even find some way to turn it into an advantage.
Yes, your nightmare scenario is if all Android users suddenly switched to LibreSignal, overloading the websocket servers. But this is not going to happen. In the event that it does, (a) I'm sure people will step up and donate, including myself, if you provide some concrete figures on the actual costs rather than pushing FUD scare-tactic conjectures, and (b) it means significant numbers of your users actually give a crap about not using GCM with Signal, and you ought to bloody well listen to them instead of taking away their options!
Pushing the FOSS angle is also insincere. If a software's primary purpose requires communicating with an API, then users should be able to tinker this and not be blocked, or called rude, selfish, or entitled for creating a derivative work that actually functions. Similar reasons were why GPL-3 was created - because it was seen that forces in the software world were moving to "match the definition" of FOSS, but not really be FOSS. Tell me Mr Anderson, what use is a phone [to call your lawyer], if you cannot speak?
TL;DR: Do what you like, but stop trying to guilt-trip users into avoiding the actual issues; it is really disgusting.
There was a problem hiding this comment.
In the modern digital world, lots of services are free. It doesn't mean that users are selfish or rude, for criticising those services for not providing basic levels of freedom, or asking for it for free. Services make their money back via other means - some by advertising, OWS by grants from OTF and other sources. In many cases, free users help the service via a network effect. The work is definitely not "unpaid" and it is not relevant that was "no guarantee at the start" he would make money - it is now being funded adequately, and OWS would have packed up shop if this hadn't happened.
Most services aren't designed to "make their money back," they're designed to make a profit. OWS is different in that it isn't a business, so our objectives are different from those endeavors. You may think that we're "adequately funded," but if you look at our website you'll see that we have two developers on staff. Any comparable organization with the scope and user base of our software today has at least fifty developers on staff, and they're paid almost 10x more.
This doesn't mean that we can't function, but it does mean that we have to make choices about what we prioritize and what we take on.
So trying to shame free users, and abusing the fact you made some very nice past contributions, to milk unlimited amounts of praise from everyone, to deflect the criticisms - this tactic is not sincere and is inaccurate about the overall picture.
I was responding to a comment where someone suggested that they should be able to use our service in any way they would like, since it is "largely funded by the community." That is simply not true.
We are not causing you any more economic damage in using LibreSignal, than if we used the official client. Federation is an unrelated point; I am only focusing on client flexibility here. You claimed elsewhere that "the difference is huge; one we have control over, the other we don't." But the control does not translate into actual economic damage. There is also no future economic model where this is likely - either it stays a trivial minority, or you will see way in advance its growth, easily accommodate for it, and maybe even find some way to turn it into an advantage.
I think it's strange that, having contributed nothing, you feel you know best about what we can and can't accommodate. Third party clients and third party servers both create the same compatibility problems for us and inhibit our ability to easily make changes moving forward. We have limited resources, and any additional complexity is something that we can't accommodate right now. I can't imagine what else you think our motives would be? We're the ones doing the work, so we're the ones who know what it is that we can and can't take on.
Yes, your nightmare scenario is if all Android users suddenly switched to LibreSignal, overloading the websocket servers. But this is not going to happen. In the event that it does, (a) I'm sure people will step up and donate, including myself, if you provide some concrete figures on the actual costs rather than pushing FUD scare-tactic conjectures, and (b) it means significant numbers of your users actually give a crap about not using GCM with Signal, and you ought to bloody well listen to them instead of taking away their options!
No, this is not my nightmare scenario. Believe me, I have no fear that everyone is going to start using LibreSignal. However, the thing about compatibility is that it doesn't only effect users of a 3rd party client like LibreSignal, but also every Signal user who communicates with them. It's the latter that is ultimately problematic for us.
We haven't asked users to fund the service thus far, so I'm not sure why you feel entitled for us to publish a breakdown of our costs.
Pushing the FOSS angle is also insincere. If a software's primary purpose requires communicating with an API, then users should be able to tinker this and not be blocked, or called rude, selfish, or entitled for creating a derivative work that actually functions. Similar reasons were why GPL-3 was created - because it was seen that forces in the software world were moving to "match the definition" of FOSS, but not really be FOSS. Tell me Mr Anderson, what use is a phone [to call your lawyer], if you cannot speak?
We are, by definition, writing free software. That means you can use the software we write under the terms that we make it available (gplv3). That does not entitle you to use our name, or to use a service that we run for your own product. You're free to run your own service, however. If running your own service for your own product sounds like a lot of work, why would you feel entitled for us to do it for you?
TL;DR: Do what you like, but stop trying to guilt-trip users into avoiding the actual issues; it is really disgusting.
If you maintain that you're actually helping us by using Signal and demanding that we spend the limited time we have to do whatever it is you think is important, please stop helping us.
There was a problem hiding this comment.
However, the thing about compatibility is that it doesn't only effect users of a 3rd party client like LibreSignal, but also every Signal user who communicates with them. It's the latter that is ultimately problematic for us.
You never shared the technical details with us. Doing that might have helped... 😄
There was a problem hiding this comment.
Thank you for going into more concrete details, and this is what the discussion at #37 should have gone down the lines of. I hope this continues.
We are not causing you any more economic damage in using LibreSignal, than if we used the official client. [..]
I think it's strange that, having contributed nothing, you feel you know best about what we can and can't accommodate. Third party clients and third party servers both create the same compatibility problems for us and inhibit our ability to easily make changes moving forward. We have limited resources, and any additional complexity is something that we can't accommodate right now. I can't imagine what else you think our motives would be? We're the ones doing the work, so we're the ones who know what it is that we can and can't take on.
Yes, your nightmare scenario is if all Android users suddenly switched to LibreSignal, [..]
No, this is not my nightmare scenario. Believe me, I have no fear that everyone is going to start using LibreSignal. However, the thing about compatibility is that it doesn't only effect users of a 3rd party client like LibreSignal, but also every Signal user who communicates with them. It's the latter that is ultimately problematic for us.
As @mimi89999 mentioned, it would be good to have more specifics on this. I don't know the precise details on what you can best accommodate - but as an experienced software engineer I can spot when things contradict my understanding on how general software systems and development ought to work.
It's not the case in general, that unsupported clients should cause server operators any more work. You don't need to solve any compatibility issues, the developmental cost ought to be zero. You make it very clear unofficial clients are not supported. Everybody that uses LS, understands that it's not supported by OWS - i.e. LS may not work from time to time - though, agreed, a change of name and branding would make this more effective, in case you are getting too many extra emails from ignorant LS users.
If you're worried that the LS client may cause the server to operate incorrectly, this is something you should be protecting against anyway, regardless of whether LS exists or not. (If someone was trying to break your servers, they would create their own client and not tell you about it.)
We haven't asked users to fund the service thus far, so I'm not sure why you feel entitled for us to publish a breakdown of our costs.
I'm only saying that you should do this, if you are going to cite cost issues, as a justification for requesting that other people voluntarily self-limit their own freedom. These cost reasons don't make much sense to me, as I tried to explain above - so I have no reason to override my natural dislike at being asked to self-limit. However, more data might tilt the balance - and I imagine for others, too.
We are, by definition, writing free software. That means you can use the software we write under the terms that we make it available (gplv3). That does not entitle you to use our name, or to use a service that we run for your own product. You're free to run your own service, however. If running your own service for your own product sounds like a lot of work, why would you feel entitled for us to do it for you?
The primary purpose is to communicate with friends, and running another server wouldn't allow people do do that. This is similar to why AGPL was invented. It does not sound like a lot of work; I run my own XMPP server etc and offer it to my friends for free, without calling them entitled if they expect it to work with their own custom clients (I just tell them to fix it themselves), or asking them for the $0.05 extra that their presence on the server would cause me (on top of what my costs would already have been, if I was just running it for myself).
There was a problem hiding this comment.
It's not the case in general, that unsupported clients should cause server operators any more work. You don't need to solve any compatibility issues, the developmental cost ought to be zero. You make it very clear unofficial clients are not supported. Everybody that uses LS, understands that it's not supported by OWS - i.e. LS may not work from time to time - though, agreed, a change of name and branding would make this more effective, in case you are getting too many extra emails from ignorant LS users.
Again, the problem isn't just that 3rd party clients can break, but that it impacts the experience of normal Signal users who communicate with them as well. We've written all of this up here.
The primary purpose is to communicate with friends, and running another server wouldn't allow people do do that.
It sounds a lot like you're saying that it would be too much work to build a service that meets your needs. Again, why do you expect us to do it for you then?
I run my own XMPP server etc and offer it to my friends for free, without calling them entitled if they expect it to work with their own custom clients (I just tell them to fix it themselves),
How's that working out for XMPP? We no longer live in a world where it's feasible to tell people to fix it themselves. If something doesn't work, people don't care if it's because the person they're communicating with is using a 3rd party client that's broken, or doesn't support whatever feature they're trying to access, or works slightly differently. They'll just think that your app is unreliable.
I get that you wish we lived in a different world, but the fact that you're using Signal when you have your own XMPP server at your disposal is probably an indication of that perspective's shortcomings. If what you're asking for is so great and so reasonable and will work so well, why not just continue using XMPP and leave us alone? I wish that you would.
There was a problem hiding this comment.
- Still no technical details...
- I managed to get all of my LS contacts to move to Conversations app. Since OMEMO was added, the Chat Secure OTR issues noted on OWS blog are no longer actual... The only problem is implementation of OMEMO/Olm on iOS to get owners of iBad devices...
There was a problem hiding this comment.
The only incompatibility that I know of, is that calling doesn't work and that's clearly not LS' fault but rather caused by OWS not publishing redphones server code...
There was a problem hiding this comment.
The only incompatibility that I know of, is that calling doesn't work and that's clearly not LS' fault but rather caused by OWS not publishing redphones server code...
This is actually a great example. Right now LibreSignal doesn't support voice calls, so when a normal Signal user tries to call them, they won't be able to. Those normal Signal users aren't going to understand that they can't call certain contacts because those people are running a certain 3rd party app, they're just going to think that Signal calls are unreliable and don't work sometimes. That's the situation with XMPP right now, and is a large part of why that ecosystem is such a failure. It's not an experience we want to replicate.
And again, @vanitasvitae, you're very mistaken. The whole point of this discussion is that LibreSignal isn't running their own servers, so source code access to the TURN server we use wouldn't change anything. The problem is that voice call setup depends on GCM, and LibreSignal doesn't support GCM, so voice calls won't work on LibreSignal.
Moving forward, more situations like this would inevitably emerge. Add more clients and it will eventually look like the ridiculous discussion happening in #37 where people are trying to figure out what arcane combination of random XEPs is supported by the intersection of which servers and which clients in order to produce an only moderately sane experience. I couldn't have parodied it better, but they're actually serious. If that's the world you want, you can have it, but don't expect us to follow.
There was a problem hiding this comment.
Again, the problem isn't just that 3rd party clients can break, but that it impacts the experience of normal Signal users who communicate with them as well. We've written all of this up here.
The original point was that "3rd party clients can break" is not a problem that costs OWS any money. Your blog post is about federation, not client flexibility. You're conflating the two; they are separate topics. For this thread, I am not interested in federation.
Right now LibreSignal doesn't support voice calls, so when a normal Signal user tries to call them, they won't be able to. Those normal Signal users aren't going to understand that they can't call certain contacts because those people are running a certain 3rd party app, they're just going to think that Signal calls are unreliable and don't work sometimes.
(a) This impacts very few of your official-client users, and (b) Signal calls don't work sometimes, e.g. if the other person has their phone off. There doesn't have to be a UX distinction here, LS users can always "be offline".
It sounds a lot like you're saying that it would be too much work to build a service that meets your needs. Again, why do you expect us to do it for you then?
You've already built the WebSocket server for your other needs, and LS is only latching onto it at very little extra marginal cost for you (under my reasonable software engineering estimates). I'd be happy to admit my estimate is wrong, if you provide some reasons (data) for me to do so.
I run my own XMPP server etc and offer it to my friends for free, without calling them entitled if they expect it to work with their own custom clients (I just tell them to fix it themselves),
How's that working out for XMPP? [..] I get that you wish we lived in a different world, but the fact that you're using Signal when you have your own XMPP server at your disposal is probably an indication of that perspective's shortcomings.
The original point was me disputing your assertion that "it's hard to run the server", and correcting your original wording, that assumed a cost model of you running the entire service solely for LS. That cost model is wrong - LS' marginal cost on OWS is minimal (based on reasonable average SWeng assumptions as before).
Whether XMPP is better or worse than Signal is irrelevant, for the topic at hand. You'll notice you can flip the variables in your own argument to produce an equally valid argument "but the fact that you're using XMPP when you have a Signal account is probably an indication of that perspective's shortcomings". Really you don't need to take pot-shots every chance you get (and this one is logically invalid, anyways). I agree that the XEP situation is ridiculous, but that's a topic for another time (and this doesn't mean that I agree federation in general is ridiculous; but I'm not interested in arguing this further, for now).
There was a problem hiding this comment.
The original point was that "3rd party clients can break" is not a problem that costs OWS any money. Your blog post is about federation, not client flexibility. You're conflating the two; they are separate topics. For this thread, I am not interested in federation.
The blog post is about consistency and control in a world where the ecosystem is moving. eg: "For example, even GitHub has problems with consistency and control right now. They introduced issue templates, but a number of 3rd party GitHub clients don't support them, so even after creating a thorough issue template for the Signal Android repository, we still get people who post "it doesn't work please help," because their client never even showed them the template. That makes me annoyed with GitHub, even though I use the official GitHub clients. It's a potential opportunity for a GitHub competitor that can display issue templates consistently."
Server consistency and client consistency are the same problem.
(a) This impacts very few of your official-client users, and (b) Signal calls don't work sometimes, e.g. if the other person has their phone off. There doesn't have to be a UX distinction here, LS users can always "be offline".
Except they aren't offline. They may have just sent you a message, but the call fails. That's a terrible UX. This is also just one example, more would inevitably emerge over time as development progresses, just as it has with XMPP.
You've already built the WebSocket server for your other needs, and LS is only latching onto it at very little extra marginal cost for you (under my reasonable software engineering estimates). I'd be happy to admit my estimate is wrong, if you provide some reasons (data) for me to do so.
You're very focused on the costs associated with the actual file descriptors consumed, but what I'm talking about is the cost of our inability to iterate while delivering a clean user experience when we don't control the software connected to our service. That's development time, which if you want to frame in terms of economics, does add up to very real dollars. You don't want to conflate that with federation, but it's the exact same problem.
You obviously disagree with my assessment, even though we're the ones doing the developmnt, have all of the experience with this project, are the ones incurring these costs, and are best positioned all around to understand what our own limitations are. You could use the open source software that we've provided to run your own service and prove your hypothesis correct, but want us to do it instead because you think it'd be too much work.
Whether XMPP is better or worse than Signal is irrelevant, for the topic at hand. You'll notice you can flip the variables in your own argument to produce an equally valid argument "but the fact that you're using XMPP when you have a Signal account is probably an indication of that perspective's shortcomings". Really you don't need to take pot-shots every chance you get (and this one is logically invalid, anyways). I agree that the XEP situation is ridiculous, but that's a topic for another time (and this doesn't mean that I agree federation in general is ridiculous; but I'm not interested in arguing this further, for now).
The comparison isn't irrelevant, it's the exact question we're discussing. XMPP is a nightmare because there is no consistency. We don't want people building their own products that use our service because we want to avoid that nightmare.
There was a problem hiding this comment.
if one wants to have a decent debate, one has to be able to imagine herself in the skin of her oponent. to at least try to feel what and why the oponent feels. i am afraid this debate is going nowhere because @infinity0 is totally uncapable of doing this. he only sees himself and what he wants but can not have and he would only accept "counterarguments" if they would give him exactly what he wants. everything else is wrong, bad or not important at all. i think that kind of attitude is selfish. childish even.
There was a problem hiding this comment.
For the record, we've also repeatedly told OSS projects that we have no problem with them distributing our GPL software through the app store. We're looking into ways that we can formalize that in a license, it's not our intention to prevent OSS iOS apps from using our libraries.
@moxie0 So in a hypothetical world where code magically writes itself, if I or someone else turned around tomorrow and published on the Apple app store an OMEMO client for iOS, dumped the source on GitHub under GPL (or MIT?), you would have no problem with that, and we could expect no legal repercussions for doing so?
Note: the axoltl/double rachet specification was put in the public domain by Trevor, here.
What if someone rips code out directly from Signal-iOS, dumps the source for the OMEMO application on GitHub under GPLv3, but also publishes on the App Store? Do you have a problem with that? Presumably this would be a GPL violation, would OWS be willing to grant someone a license specifically for redistribution of that code on the Apple App Store ONLY under a non-GPL license?
What if someone looks at your/ code in order to understand how to write their own code, but then writes their own closed source implementation and doesn't publish the code at all, but publishes their code on the Apple Appstore, and states publicly that they use Axoltl/double rachet for encryption? Do you have a problem with that? (My understanding is this is what the Wire guys did with Rust (see also: hacker news thread) and presumably you did have a problem with that).
There was a problem hiding this comment.
[..] what I'm talking about is the cost of our inability to iterate while delivering a clean user experience when we don't control the software connected to our service. That's development time, which if you want to frame in terms of economics, does add up to very real dollars.
You're coming up with some very vague general assertions, but have yet to come up with specific instances where you actually had to spend time dealing with LS. The offline call issue, was given to you by someone else on this thread, so you can't seriously argue that you actually lost real development time over this.
Server consistency and client consistency are the same problem. [..]
You could use the open source software that we've provided to run your own service and prove your hypothesis correct, but want us to do it instead because you think it'd be too much work. [..]
You're repeating your original assertions, after I just explained why they are false. You should instead respond directly to those latter points that I made.
i am afraid this debate is going nowhere because [infinity0] only sees himself and what he wants [..] i think that kind of attitude is selfish. childish even.
Please don't add unconstructive comments here. If you are going to say that I'm being childish, at least actually add some specific arguments about the specific things I said. Your argument is equally valid for everyone participating here, including yourself - you are not imagining yourself in my skin, either.
There was a problem hiding this comment.
You obviously disagree with my assessment, even though we're the ones doing the developmnt, have all of the experience with this project, are the ones incurring these costs, and are best positioned all around to understand what our own limitations are.
You are indeed in the best position to do that, but it does not make you immune to being questioned. Otherwise, nobody external would be able to criticise any organisation, ever. That is what I am doing now, so please just take it in your stride. We should continue with the other points.
There was a problem hiding this comment.
Your argument is equally valid for everyone participating here, including yourself - you are not imagining yourself in my skin, either.
i am totally imaginig you at your position: you don't want to use GCM (and that is a relevant choice) so it would really be the best for you and to likeminded people to have another option. nothing wrong with this. i, myself, would also love to use everything googleless. also, ideologicaly, i am totally for federation - it is a great concept that is based on freedom of choice.
the problem is, and here i think you are being selfish and even childish, that you can't accept any argument, no matter how strong it is, that doesn't allign with you wishes. i dont want to repeat the arguments that were pointed out so many times on many conversations, there were enough of them for a blind man to see. i only want to point out one practical example from the past:
i've seen complain after complain after complain after complain on Signal's github of people that were using CM's implementation of the software and also Signal users that were comunicating with those people. there is no way for Signal devs to force a synchronous development of both programs and also no way to not being blamed themselves by disappointed users for something that's not in their jurisdiction. but CM was only one and only exemple of federation, now imagine yourself more of them. i think that organisation that aims to offer a thrustworthy messenger service can not afford such situations, period.
there is nothing wrong with you not to agree with those facts. but to not at least try to put yourself in moxie's skin, to demand something, that he does not need to provide you and to blame him of being some kind of FLOSS traitor if he doesn't want to comply with your wishes is selfish and childish if you ask me.
There was a problem hiding this comment.
I can sympathise how masses of bad arguments can make one ignore a good argument that is similar to the bad arguments. But what I am doing in this thread, is trying to explore the specific details of the OWS position that "allowing LS will be costly". Please, do spend some time reading the exact wording and points that I wrote, instead of assuming they are the same as what was said before. I have also read some of those discussions, and not seen any specific discussion of the actual underlying issues, which is why I am bothering to spend time on a Sunday to talk about it here.
I can understand OWS' fears that LS might be costly. When you run a business, you have to think about risk. So yes, I do understand OWS' desire to restrict LS, as a conservative risk estimate, and other companies would do likewise. I can understand that you guys are "not evil", and am not trying to argue that.
However, other companies that give more weight to the ideals of freedom, think through this risk estimate a bit more, and find out that actually, the original conservative risk estimate was too conservative, and that in practise the real costs are not actually that much - you get the benefit of both worlds, you can preserve user freedom and also your own costs. This is what I am trying to show in the above arguments. I encourage OWS to adopt this latter approach, and they are (as advertised) not trying to be like typical companies.
Sorry (and you too moxie) if my previous points came across as aggressive, it takes time to re-read and re-write my words to lessen that impression. The remaining undiscussed points are UX consistency, and the risk of developmental costs associated with that. I'm about ready to stop here, and we're probably not going to agree on these particular topics, but the discussion has been useful - it helps to clarify some OWS positions, such as not being too worried about LS popularity, or infrastructural cost, etc.
Moxie is not the boss of you, nor of the community. Why don't you just ignore him and continue with this project?