Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Please add LibreSignal to f-droid #37

Closed
kakedacich opened this issue May 4, 2016 · 488 comments
Closed

Please add LibreSignal to f-droid #37

kakedacich opened this issue May 4, 2016 · 488 comments
Labels

Comments

@kakedacich
Copy link

@kakedacich kakedacich commented May 4, 2016

Dear maintainers, I'm reading here:

#28 (comment)

that the people behind f-droid are willing to have LibreSignal distributed there.
What they're waiting for is a pull request from you (last sentence of that comment).

I hope you are already aware of this and that you'll allow everybody to get this great fork from f-droid!

Thank you

@kakedacich kakedacich changed the title Please add the clien to f-droid Please add LibreSignal to f-droid May 4, 2016
@mimi89999
Copy link
Member

@mimi89999 mimi89999 commented May 4, 2016

What they're waiting for is a pull request from you

There are still several important issues:

  1. The signing key for reproducible builds. If the signing key is changed, an update won't be possible. Also, who would "own" the signing key in such a case?
  2. Our relations with OWS are really bad. I'm afraid, that one day, they will ban LibreSignal from their server...
  3. Calling still doesn't work.

@LibreSignal what do you think? Should LibreSignal be moved to the main F-Droid repo?

@eighthave
Copy link

@eighthave eighthave commented May 4, 2016

I don't think it makes sense to include LibreSignal in F-Droid until you have a server to run it. They have explicitly said that the only want their own builds of Signal using their server.

@eighthave
Copy link

@eighthave eighthave commented May 4, 2016

even better, help them move to 100% free software and working without Google, so there isn't a need for the fork.

@mimi89999
Copy link
Member

@mimi89999 mimi89999 commented May 4, 2016

@eighthave

Until you have a server to run it.

Running a server costs money and I am not sure if OWS will want to federate with us.

even better, help them move to 100% free software and working without Google, so there isn't a need for the fork.

The problem is that Moxie and OWS don't want Signal to be 100% free/libre software (it is not important for them...)

@paride
Copy link

@paride paride commented May 4, 2016

@eighthave They are not interested in removing the Google GCM dependencies, so unfortunately this is not possible. Moxie has been quite explicit on this point, several times.

@mimi89999:

  1. Can't the package be signed with the f-droid key, like the other packages on f-droid, and then this binary becomes the reference for LibreSignal's reproducible builds? Maybe here I'm missing something...
  2. Is is technically possible for them to ban unofficial clients? I'm not sure about this, and not even the big and evil players (Microsoft, Yahoo, Google...) ever did so. I remember Moxie asking for a client identification string to be modified on LibreSignal, and I get this as an indirect way to say "I'm OK with your client, but please let me recognize it on the server side". IMHO, if OWS bans LibreSignal at least it would be clear message to the community, and a lot of effort would be saved for better projects.
  3. I think that disabling calling altogether would be fine for the moment. Then, as there is a lot of attention on fdroid, there is a better change for it to be fixed.

This said, I understand why the inclusion on fdroid needs to be well pondered.

@paride
Copy link

@paride paride commented May 4, 2016

@mimi89999 but that is about calling the independent build Signal, and after that discussion (and legal threats) xmikos renamed it to LibreSignal (s/Signal/TextSecure). It's mostly about the trademark.

@mimi89999
Copy link
Member

@mimi89999 mimi89999 commented May 4, 2016

@legovini

  1. F-Droid signing keys might get stolen or somebody from F-Droid might be forced to sign a malicious apk. If LibreSignal is added using reproducible builds, this won't be possible...

EDIT: Please read https://f-droid.org/wiki/page/Deterministic,_Reproducible_Builds#How_it_is_implemented_as_of_now

@mimi89999
Copy link
Member

@mimi89999 mimi89999 commented May 4, 2016

@legovini Let's ask @moxie0 if he is OK with LibreSignal using OWS servers.

@moxie0
Copy link

@moxie0 moxie0 commented May 5, 2016

I'm not OK with LibreSignal using our servers, and I'm not OK with LibreSignal using the name "Signal." You're free to use our source code for whatever you would like under the terms of the license, but you're not entitled to use our name or the service that we run.

If you think running servers is difficult and expensive (you're right), ask yourself why you feel entitled for us to run them for your product.

@mimi89999
Copy link
Member

@mimi89999 mimi89999 commented May 5, 2016

@moxie0

I'm not OK with LibreSignal using the name "Signal."

LibreSignal is using the name "LibreSignal". The name "LibreSignal" contains "Signal". If you prefer, I can rename "LibreSignal", so that it doesn't contain "Signal" in the name... I can also change the icon if you want.

If you think running servers is difficult and expensive (you're right), ask yourself why you feel entitled for us to run them for your product.

You are receiving donations for developing Signal-Android and running the servers. I am not.

If I finance running a TextSecure server for LibreSignal, will you federate with us?
Also, I won't be able to run a RedPhone server because it is not open source.

What about other Signal forks like Signal Plus (https://play.google.com/store/apps/details?id=org.privatechats.securesms) (https://github.com/WizDom13/SignalPlus-Android) Their app name also contains "Signal" and they are also using OWS servers.

@mimi89999
Copy link
Member

@mimi89999 mimi89999 commented May 5, 2016

@xmikos @JavaJens @SecUpwN @mvdan @krt16s What do we do now?

@h-2
Copy link

@h-2 h-2 commented May 5, 2016

@moxie0

You're free to use our source code for whatever you would like under the terms of the license, but you're not entitled to use our name or the service that we run.

If you think running servers is difficult and expensive (you're right), ask yourself why you feel entitled for us to run them for your product.

@mimi89999

If I finance running a TextSecure server for LibreSignal, will you federate with us?
Also, I won't be able to run a RedPhone server because it is not open source.

I think these are the crucial points. Nobody wants to annoy WhisperSystems or create extra expenses or support tickets, but we do need inter-operability and interaction of the users. @moxie0 if you release the red phone server components and would agree to federate, I am sure we could gather enough resources to maintain own servers and not bother you further 😄

@moxie0
Copy link

@moxie0 moxie0 commented May 5, 2016

If you prefer, I can rename "LibreSignal", so that it doesn't contain "Signal" in the name... I can also change the icon if you want.

Thanks, that would be great!

You are receiving donations for developing Signal-Android and running the servers. I am not.

You're capable of doing that as well, though. We're barely able to support our own apps, and having to support products outside of our control would make our lives even more difficult. If you think that collecting donations to run and maintain servers for your own project is difficult, why would you expect us to do it for you?

If I finance running a TextSecure server for LibreSignal, will you federate with us?

It is unlikely that we will ever federate with any servers outside of our control again, it makes changes really difficult.

What about other Signal forks like Signal Plus (https://play.google.com/store/apps/details?id=org.privatechats.securesms) (https://github.com/WizDom13/SignalPlus-Android) Their app name also contains "Signal" and they are also using OWS servers.

Yep, we're working on it.

@mimi89999
Copy link
Member

@mimi89999 mimi89999 commented May 5, 2016

@moxie0
I don't think that the several LibreSignal users are a big impact on the server. Anyway, since you rely on donations, what is the difference for you if the user is using Signal-Android or another Signal fork? You don't have to specially "support" this app. It is communicating with the server the same way as Signal-Android and Signal-Desktop. (AFAIK Signal-Desktop is using WebSockets).

It is unlikely that we will ever federate with any servers outside of our control again, it makes changes really difficult.

Some time ago you federated with CyanogenMod. What has changed since then?
LibreSignal [server] would use the code that is in you repo and would be updated regularly. I don't understand the part "it makes changes really difficult".

@paride
Copy link

@paride paride commented May 5, 2016

@moxie on #37 (comment), I expected you to welcome LibreSignal on OWS servers because you have nothing to lose but a lot to gain. What is at stake here is the opinion and support of a big community, something that can make the difference in the future Signal. All the "freebie" PR you receive for your products do not come from people that just want to work for free.

I hope you see the difference between LibreSignal and the SignalPlus-like apps that just want to earn something using somebody else's work. I really see the space for a good cooperation here.

@mimi89999
Copy link
Member

@mimi89999 mimi89999 commented May 5, 2016

@legovini Signal Plus doesn't look bad (I didn't look yet at the entire code...). The only problem is that it is a bit outdated.

@paride
Copy link

@paride paride commented May 5, 2016

@mimi89999 my fault, I thought it was not distributed for free on the play store.

@mimi89999
Copy link
Member

@mimi89999 mimi89999 commented May 5, 2016

Signal Plus is a fork that contains many interesting features, that users asked for on the Signal-Android issue tracker, but that were never added by OWS (file transfer, wallpapers, etc.).
The issues with Signal Plus are that the app isn't 100% FOSS/FLOSS and that it requires gapps (like Signal-Android). The app is also a bit outdated, but I think that they might be open to PR.

@ghost
Copy link

@ghost ghost commented May 5, 2016

Law is difficult, I don't know what trade/wordmarks OWS holds and what it can enforce with it. My common sense tells me that's a joke to have any such thing for a general word like "signal" in any way, but law is not common sense.

As for F-Droid: As I said, I wont be the in merging it into mainline. And even if there is a vote, I will not be in favor of it anymore. It's clear that OWS will (or might) take actions, thus leaving users out in the rain... (giving OWS yet another reason to say "see, that's why we dont support fdroid").

Let's just use XMPP/Conversations and be done...

@moxie0
Copy link

@moxie0 moxie0 commented May 6, 2016

I don't think that the several LibreSignal users are a big impact on the server. Anyway, since you rely on donations, what is the difference for you if the user is using Signal-Android or another Signal fork?

The difference is huge; one we have control over, the other we don't. I understand that federation and defined protocols that third parties can develop clients for are great and important ideas, but unfortunately they no longer have a place in the modern world. Even less of a place for an organization the size of ours. Everyone outside the FOSS community seems to know it, but it took actually building the service for me to come to the same understanding, so I don't expect you to believe me.

I invite you to try it yourself with your own federated network of clients controlled by multiple developers, but please do not expect me to undertake that experiment for you. Again, if it sounds like a lot of work, ask yourself why you feel entitled for me to do it for you. Truly though, I wish you well in the endeavor, it's something that I'd love to be proven wrong about.

Some time ago you federated with CyanogenMod. What has changed since then?

What changed was going through that experience. It seriously degraded the UX for our users and held us back in the development process at many times. I'd estimate that all told, we lost about 6 months to a year of progress. It's something we'll probably never do again, and has fully convinced me that federated protocols are a thing of the past in this world of ours.

I hope you see the difference between LibreSignal and the SignalPlus-like apps that just want to earn something using somebody else's work. I really see the space for a good cooperation here.

If people want to use our source code to develop their own products, that's fine, so long as it's done under the terms of the license. That's the deal we're making with everyone, and I agree that it allows for possible collaboration. However, we are not running a service for other people's products, and we are not letting other people use our name in their products. Those things aren't part of the deal.

Let's just use XMPP/Conversations and be done...

You have no idea how much I would love it if you did, but the fact that you don't is sadly telling.

@ghost
Copy link

@ghost ghost commented May 6, 2016

Let's just use XMPP/Conversations and be done...

You have no idea how much I would love it if you did, but the fact that you don't is sadly telling.

I am not involved in LibreSignal, and for my personal usage I actually am using XMPP the whole time and am pretty happy with it. My comment was directed to the LibreSignal devs. It's clear that you have other plans and other priorities. No hard feelings here, it's just when someone wants federation, no non-free blobs or whatever, Signal is not the thing to use. XMPP has quite some other problems, so if someone cares about that (more), it's not for him.

@mimi89999
Copy link
Member

@mimi89999 mimi89999 commented May 6, 2016

@moxie0
Some users that care about their device security and about the 4 essential freedoms (use CyanogenMod (I know CM isn't great either for the 4 essential freedoms...), don't flash gapps, etc.) use LibreSignal to contact users that don't know how to do that...

The difference is huge; one we have control over, the other we don't.

I don't see the huge difference. The protocol is the same. The only difference I see is that you can't directly push updates to LibreSignal users.

It's something we'll probably never do again, and has fully convinced me that federated protocols are a thing of the past in this world of ours.

What about email or XMPP? Are they a thing of the past in this world of ours?

I don't like the idea of a central server controlled by a small group of people that allows only official clients. Especially if a project claims to care about users security, privacy and freedom!

I don't even see how it would be possible for you to block Signal forks from using your servers if they keep "OWS as the "USER_AGENT".

@cjeanneret
Copy link

@cjeanneret cjeanneret commented May 6, 2016

I love the fake opensource provided by OWS : use the code, but go f*** yourself for federation, out-of-store distribution and acceptation.
Really an open mind as we want to see more and more. 👎

Seriously, if OWS continues that way, even libreSignal will be dropped from my devices, and no other apps from this organization will ever come back.

Currently, people seem to be wanting to help, provide resources (like servers) and are apparently just asking for federation (that was already working with CM), but all we hear are "no", and not alternative.

People that actually care for privacy just don't want to have gapps on their device. This is a basic step toward a bit more control over data and privacy.
How do you think those people will use your apps, @moxie0 ? Seriously? Locking out non-gapps-ed users is probably the worst idea you might have, since the drop of sms encryption with TextSecure (and the rebranding to signal an so on).

OWS policy just goes against real privacy, letting people with gapps, thus google services (mails, sync and so on) without the possibility to NOT let that on their phone.
That's against all logic.

Like they said: so long and thanks for all the fish.

Will follow that issue, but if LibreSignal (or whatever name it will get later) is locked out OWS servers, and no federation is possible, be sure to lose users. At least all the one that are using LibreSignal and self-build Signal. Your policy is the wrong one. And it's a shame.

C.

@mvdan
Copy link

@mvdan mvdan commented May 6, 2016

Whatever your take on what "the right thing" is, there is no need to get personal.

And as previously said, Signal is free software - that entitles you to the source code, and no more. Noone is in the right to demand that OWS do anything else, and that includes most of what is being said in this thread.

@paride
Copy link

@paride paride commented May 6, 2016

I agree with @mvdan and I thank @moxie0 for replying when asked by @mimi89999, providing his (OWS) point of view in a polite and useful way, bringing up some truly interesting aspects of the issue.

I can understand @cjeanneret's frustration, feeling just one step away from a truly free and secure messaging system, but this is no excuse for being rude.

@vanitasvitae
Copy link

@vanitasvitae vanitasvitae commented May 6, 2016

I'd find it really sad if OWS would stop LibreSignal from using their Servers. Up to this point the two projects coexisted in a nice peaceful manner. And as far as I can tell LibreSignal does not add any load to OWS servers. If a user has GApps he probably uses Signal, if he doesn't he may be using LibreSignal. That's it. Also afaict LibreSignal is not an app that generates tremendous amounts of traffic as it IS Signal with GCM removed.

Of course feel free to correct me if I'm wrong.

After all its their servers and they can do what ever they want with it, but for me there was no "real" argument against LibreSignal so far.

@mimi89999 mimi89999 added the wontfix label May 6, 2016
@mimi89999
Copy link
Member

@mimi89999 mimi89999 commented May 6, 2016

I see only 3 possibilities now:

  1. Do as @xmikos said earlier JavaJens#72 (comment) JavaJens#72 (comment)
  2. Stop LibreSignal and focus on another secure messaging app.
  3. Host our own servers, but without federation that would mean creating our own desktop and iOS client (using our own servers). That would also mean starting the user base from 0.

@LibreSignal

@kakedacich as for your original issue, it is a "wontfix".

@mimi89999
Copy link
Member

@mimi89999 mimi89999 commented Mar 27, 2017

@akliyan They didn't remove proprietary GMS libs.

@akliyan
Copy link

@akliyan akliyan commented Mar 27, 2017

It seems that pseudo privacy oriented apps like signal are not any better than popular mass surveillance tools owned by secret services such as Facebook/Whatsapp, except that for the first the agenda is somewhat hidden.
https://www.youtube.com/watch?v=vmre4SeWunk

I am sure Libresignal was forced to shutdown (by servers denial) because it is really promoting what “Signal” is pretending to promote (privacy).
If Moxie and Whisper Systems guys are really interested in community privacy, why should they be rude against improvements brought by “Libresignal” while allowing other forks on their servers, just because they serve, in someway, their hidden agenda ?

It is sad to see this project hit the wall, and I hope someday it will revive. In the meantime, I’m looking for better alternative and would like to welcome suggestions from experts like “Libresignal” promoters.

I am thinking about “Kontalk” but I don’t know much about its “pros” and “cons”. Does it really do what it says it does?

Thanks

@vanitasvitae
Copy link

@vanitasvitae vanitasvitae commented Mar 27, 2017

@akliyan Please just read this thread, I think nearly every other messaging app and its pros and cons was introduced already.

@hackel
Copy link

@hackel hackel commented Jun 15, 2017

Wow, moxie0 just sounds sounds like a giant cunt. Anyone who uses a binary compiled release of Signal from the Google Play Store for security is a fucking idiot.

@victoroldschool
Copy link

@victoroldschool victoroldschool commented Jul 2, 2017

I had to register just to agree with the above few posters. I've been following this project since before it came out. Moxie had stalled on removing Google Dependencies for YEARS. When an alternative came out that achieved just that - he destroyed it. Absolute shame about LibreSignal. They would have ended up becoming the preferred choice for many, as it was able to achieve what Moxie has simply refused to do. LibreSignal demonstrated that the numerous claims Moxie made about things "not being possible" or "wouldn't work", was nothing more than lies.

Eliminating TRUE encryption (SMS based encryption was/is the pinnacle of secure communications) in favor of a vastly less secure option running through data. Wonder why that happened.... it probably actually WORKED, and if that's the case, it would not be 'permitted' in his country. Cough - LavaBit.

LibreSignal was already a "more secure" option without the Google dependency, and instead of taking ideas from the project and incorporating it into Signal, he had it killed. How does that make sense from a security or open source view? They made the product more secure - and you never adopted any of the changes they made, and go as far as to criticize and flame the developer... Hmmmmmm.

Everyone needs to be aware that this does not protect your data from anything. It might make you "feel better" but security is not the#1 issue. Follow all the discussions over the years here on Github - notice any "trends"? :P

Anyways, we have removed Signal from all 500+ of our clients and have started reaching out to others who also have lots of clients, encouraging them to do the same. No point in using it.

If you want secure SMS (remember signal doesn't actually do encrypted 'sms') - there are better alternatives that are more complicated to setup. But once they are initially setup, they work amazing.

This has reached the point of becoming absolutely ridiculous. People been concerned about the same things for YEARS - and it will never be addressed. How can security be of utmost importance to you, when it's been the "same old" problems that have been discussed for YEARS.

Moxie, you shoot down literally EVERY person that has contributed something "substantial" over the years. EVERY TIME. It's almost like the goal is to keep the app "functional" but not offer "too much" in the way of encryption.

But then again.... I'm sure if you didn't "comply" with the wishes of the state (seeing as you're an American company), you would be in prison right now. So I do understand where you're coming from.

Please everyone, look closely at the case of "LavaBit" - and look what happened to the owner of the company that refused to hand over SSL keys in order to break their encryption. This happened in 2013, and things have only gotten MUCH WORSE. Wondering why Moxie is a free citizen, especially if his service actually WORKS? Anyone else in his position has been "cut down".

Please folks, follow your "gut". If it don't feel right - there's usually a reason. In this case, all you need to do is read through various github discussions and forum posts to get a better sense of the picture.

Good luck!

@SafwatHalaby
Copy link

@SafwatHalaby SafwatHalaby commented Aug 25, 2017

Signal now works without Play Store / Play Services, and APKS are available directly from their website. This makes LibreSignal redundant (and an F-droid download to some extent).

Wow, moxie0 just sounds sounds like a giant cunt. Anyone who uses a binary compiled release of Signal from the Google Play Store for security is a fucking idiot.

I'm no expert but I believe Playstore APKs must be signed by the developer himself. So it might be a bit more secure than you think.

@SafwatHalaby
Copy link

@SafwatHalaby SafwatHalaby commented Aug 25, 2017

As an off-topic offshoot, please calm down people. There is no need to resort to offensive language, non factual information, and even borderline conspiracy theories just because Websockets / independent apk took some time. Experts agree Signal is secure.

SMS based encryption was/is the pinnacle of secure communications

No. Metadata can be more dangerous than the data. Although message bodies are secure, SMS metadata cannot be encrypted. This was the prime motive for moving away from it. It offered a superficial form of security.

"SMS and MMS are a security disaster. They leak all possible metadata 100% of the time".

Wow, moxie0 just sounds sounds like a giant cunt. Anyone who uses a binary compiled release of Signal from the Google Play Store for security is a fucking idiot.

https://signal.org/android/apk/

https://android.stackexchange.com/questions/75279/does-the-play-store-app-verify-the-apks

https://developer.android.com/studio/publish/app-signing.html

Notably:

Every app must use the same certificate throughout its lifespan in order for users to be able to install new versions as updates to the app. For more about the benefits of using the same certificate for all your apps throughout their lifespans, see Signing Considerations below.

The certificate is controlled by moxie. Meaning Google cannot MITM, at least not through the normal Play Store app distribution mechanism. (I am not qualified to say for sure that the firmware / some code can bypass the checks)

Edit: minor rephrasing and more links.

@mimi89999
Copy link
Member

@mimi89999 mimi89999 commented Aug 25, 2017

Having a single server isn't much safer then SMS actually. Even if OWS isn't storing metadata, NSA/FBI could either find a way to backdoor it and to make it leak all metadata or they could take the servers and run them (as they did in many cases) collecting metadata...

A single server is a single point of failure.

@SafwatHalaby
Copy link

@SafwatHalaby SafwatHalaby commented Aug 25, 2017

I'm only saying that "SMS based encryption was/is the pinnacle of secure communications" is a false statement. Different setups have different trade-offs and threat models. SMS is not a holy grail and has its flaws, and so does the server model. The developers decided that the flaws of the SMS model outweigh the flaws of the server model.

@SafwatHalaby
Copy link

@SafwatHalaby SafwatHalaby commented Aug 25, 2017

I'd blind guess that one consideration was: A server is a theoretical single point of failure, but many carriers are proven to be compromised nodes.

@mimi89999
Copy link
Member

@mimi89999 mimi89999 commented Aug 25, 2017

Sure

@DJCrashdummy
Copy link

@DJCrashdummy DJCrashdummy commented Dec 6, 2017

Having a single server isn't much safer then SMS actually.

@mimi89999 regarding metadata, i would go so far and call a single server less secure than the sms-system!
because with "infiltrating" one server NSA/FBI can collect the metadata of all possible users in the whole world; but with sms it is not that easy because of the different carriers in every single country...


the 3 important things that go hand in hand for real security, are the same and will stay:

  • cryptography
  • open source
  • federation/decentralism

and one thing of them is pretty much nothing without the others...

@grote
Copy link

@grote grote commented Dec 6, 2017

i would go so far and call a single server less secure than sms!

You probably haven't heard about SS7.

@DJCrashdummy
Copy link

@DJCrashdummy DJCrashdummy commented Dec 6, 2017

@grote please read the whole sentence!!! (just updated the original phrasing a little bit to make in more clear.)

regarding METADATA, i would go so far and call a single server less secure than the sms-system!

PS: if you are concerned about your sms-content, which everybody should (also without/before your interesting article), you should use Silence.

@gohanko
Copy link

@gohanko gohanko commented Oct 3, 2018

@moxie0 This was 2 years ago but I do not get your reasoning for not supporting non GCM users? Users in China don't have Google Play installed, which means they don't get notifications until they open the app.

@Flohack74
Copy link

@Flohack74 Flohack74 commented Dec 26, 2018

This I also find interesting. @moxie0 I tried to talk with your support guys many times about supporting the Ubuntu Touch push server, so that users of Ubuntu Touch can get notifications for their signal-compatible App. I got turned down a few times and finally gave up. If you have a mission to proliferate the world with secure messaging, why you are restricting the access to it behind arguments of costs and support?

Can I compare this to Telegram, maybe? With those guys we have an excellent relationship, we are allowed to use their servers, they send us push notifications, not a big deal. We are not allowed to use the name Telegram to not confuse with the original app, but that's fine. They also wont do support for our app, of course. We get support, and recently, they have released tdlib, a great project to make Telegram clients possible without even implementing 1 bit of their API.

Telegram uses a versioned API, so that newer developments can be deployed without breaking downstream forks (immediately). You need to do the same, then its not a big deal to advance in features but still stay compatible for older apps. And don´t tell me such an API cannot be done, I have enough examples where this works well, I am a software dev myself. Maybe not for years, but at least for some months needed for downstream to catch up.

We are currently discouraging people on Ubuntu Touch to use Signal because we don't see a future for it. People instead recommend Matrix. That´s rude, I know. But it´s like your argument about living in today´s world. What does this mean, that all experiences and gains of knowledge from the past are to be thrown away because "Apps"? Cmon, modern software development has come a long road. Making services closed also limits what you can achieve with them.

Currently about 3 or 4 hardware vendors are working on independent phone hardware. They will have Linux flavours installed, will have no relation to Google or Android at all. Plasma Mobile is one of the bigger bets besides Ubuntu Touch. They will have apps that can be interchanged because of common packaging formats. They got their own app stores and federated push servers. We will get rid of the chains of big vendors. Shall Signal be a part of this future or not? I leave it open to you.

@janvlug
Copy link

@janvlug janvlug commented Dec 26, 2018

I support this request from the perspective of the yet to be released Librem 5 Linux based cell phone from Purism. I have pre-ordered the Librem 5, and currently I have 100+ Signal contacts. I really would like to still be able to use Signal when the Librem 5 will be arrive (currently planned for April 2019).
See this thread on the Purism forums: Signal client for the Librem 5.

@JohnD28
Copy link

@JohnD28 JohnD28 commented Dec 27, 2018

@janvlug
I think it's not the right place. We already speak about that here :

signalapp/Signal-Desktop#2383

FYI :
https://mastodon.social/@diggity/101046739048944068

I'm actively recruiting volunteer devs for a native Signal / Signal-like client in Gtk, in the hopes that we can bring it to the @purism Librem 5 phone. Please contact sean.obrien@puri.sm if interested.

PGP/GPG: FA9D 40F1 5FE1 D8AB 8312 4AAA 77E3 1447 CD1F C3F6

@fabianski7
Copy link

@fabianski7 fabianski7 commented Apr 11, 2020

it's already 2020 and I'd like to contribute to that too

FUCK YOU OWS!!!

@mimi89999
Copy link
Member

@mimi89999 mimi89999 commented Apr 12, 2020

Sorry. I'm locking this issue.

@LibreSignal LibreSignal locked as too heated and limited conversation to collaborators Apr 12, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
You can’t perform that action at this time.