HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
signalapp
Signal-Android
Kotlin2011–2026
signalapp / Signal-Android

Signal-Android

A private messenger for Android.

280Distinct people
372Mentions
5Explicit recommenders
29.6KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

A private messenger for Android.

GitHub

Where it is used

  • Molly — Molly uses the signalapp/signal-android codebase as an independent fork to deliver a variant of the Signal Android app with added features. It ships as its own app built from the Signal Android project. Source

What people are saying

I never hated on Signal, on the contrary I recommend it too many people but I can say that the energy consumption on Android is in many cases abysmal for multiple years now and…

johschmitz used a recommendation phrase. 5 indexed comments match. This is a phrase match, not a verdict.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 12:03:30 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year372 dated mentions

Observed mentions: 2011-12-21 12:48:31 UTC to 2026-10-12 11:10:46 UTC.

0204060802011-01-01 00:00:00 UTC to 2012-01-01 00:00:00 UTC (exclusive): 1 mentions; 1 submissions, 0 comments20112012-01-01 00:00:00 UTC to 2013-01-01 00:00:00 UTC (exclusive): 4 mentions; 1 submissions, 3 comments2013-01-01 00:00:00 UTC to 2014-01-01 00:00:00 UTC (exclusive): 12 mentions; 0 submissions, 12 comments2014-01-01 00:00:00 UTC to 2015-01-01 00:00:00 UTC (exclusive): 23 mentions; 0 submissions, 23 comments2015-01-01 00:00:00 UTC to 2016-01-01 00:00:00 UTC (exclusive): 26 mentions; 1 submissions, 25 comments2016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 46 mentions; 1 submissions, 45 comments2017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 22 mentions; 2 submissions, 20 comments2018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 24 mentions; 4 submissions, 20 comments20182019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 10 mentions; 1 submissions, 9 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 25 mentions; 1 submissions, 24 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 87 mentions; 12 submissions, 75 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 30 mentions; 2 submissions, 28 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 13 mentions; 0 submissions, 13 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 16 mentions; 2 submissions, 14 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 23 mentions; 1 submissions, 22 comments2026-01-01 00:00:00 UTC to 2027-01-01 00:00:00 UTC (exclusive): 10 mentions; 0 submissions, 10 comments. Incomplete calendar period.2026*

* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20112011-01-01 00:00:00 UTC2012-01-01 00:00:00 UTC110
20122012-01-01 00:00:00 UTC2013-01-01 00:00:00 UTC413
20132013-01-01 00:00:00 UTC2014-01-01 00:00:00 UTC12012
20142014-01-01 00:00:00 UTC2015-01-01 00:00:00 UTC23023
20152015-01-01 00:00:00 UTC2016-01-01 00:00:00 UTC26125
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC46145
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC22220
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC24420
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC1019
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC25124
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC871275
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC30228
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC13013
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC16214
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC23122
2026 (partial)2026-01-01 00:00:00 UTC2027-01-01 00:00:00 UTC10010

What Hacker News says

46 sources
>> Can I run a client from the Git repo and still use all of their infrastructure? > Yes. You can. The thing is, lucideer, the "restrictions" on the use of the source code are engineered to raise the barrier to independent use, notably by preventing or discouraging redistribution. This means that only those who are able and willing to compile Android source can run their own binaries. Everyone else has to go with the binaries they distribute which, as the other poster has correctly argued, cannot be independently verified. > Do you have some personal issue with OWS? I do not know about him. But I do. Please read on. > and provided via F-Droid (though I have read their arguments against that w.r.t. performance) Oh, so it's "performance" this time? It's not something about "updates" like last time¹, or "features", or "metrics"? Do you real
Read the rest
ly not think, if you go through the discussions, that there's just too many excuses? Does it make sense to you? Do you not get the feeling someone's got something to hide, if you would pardon the pun? :-) But I tell you what really got in my tits, it was this message: (https://github.com/WhisperSystems/Signal-Android/issues/53#i...) "Please do not install software from F-Droid. It is an unverified build, exceptionally out of date, and should be considered malware." You know what? I fucking trust F-Droid. And I for one I am very grateful to everyone who collaborate to make that happen and stand firm in their commitment to open source, and especially to Ciaran, the founder, who gives so much to the community in spite of very challenging family issues (which are publicly known). Top bloke he is. And then you get some lying, incompetent, manipulative², and possibly delusional individual accuse them of distributing malware. That is seriously not cool. For those of you unaware, this is the person we are talking about (I suggest you read the comments too): http://www.gandibar.net/post/2010/04/07/The-googlesharingnet... ¹ Cooperative and competent (or at least willing) open source developers can set it up so that F-Droid auto-builds every time you tag a new release. ² And I say this because I'm sure someone will correctly argue that he did not call F-Droid itself malware--that would be too crass even for this guy. He's very careful in choosing his words.
In Worried About the Privacy of Your Messages? Download Signal
> I'd even argue it's free software Terminology. What you call free software I call open source. As you go on to mention, you can see the source but not use it in any meaningful way. In particular: > but have clarified that it is indeed ok to build your own binary from the source they provide, Exactly. Your own binary. From their source. Build your own binary for someone else, and it's "malware", as the guy had the nerve to call F-Droid in that bug report (here: https://github.com/WhisperSystems/Signal-Android/issues/53). That sort of bad faith, coming from a known liar (see my other reply) is what I really cannot condone. > and use their servers. Yeah, similarly. Use a source other than theirs or servers other than theirs and they start whingeing. That is not open source. > I'm not quite convinced about their argument for official app st
Read the rest
ore distribution and updates, Possibly because every time it's a different excuse? > but I can understand the argument. Yes, so can I: they want to control the platform so that it is their users, so that they can sell it to someone else, like they did last time. And I would be perfectly fine with that, if it wasn't done via lies, deception, and denigrating third parties, particularly the chaps at F-Droid who at least have the decency of using their real names (not to mention not seeing you as the product). > Sticking with an app store does require trust in the provider though. Agreed. How high is Google in your "trusted" list? Yes, I'm picking on Google because it's a bit of an easier target than Apple, but still. > I think it would be best to avoid FUD. I agree, and that's precisely why I feel the need to speak up. I challenge the honesty not of their enterprise (which is no different from that of Skype, Whatsapp, or any other player) but of the way they are pursuing their goal. See above. > It certainly strikes me as one of the better options for pragmatic secure messaging, I don't know. As mentioned elsewhere, XMPP meets all my requirements and is not vendor-dependent. But the availability of options depends on each user's definition of things like "pragmatic" and "secure" (and even "messaging" for that matter!) From seeing what's out there though, it appears that modern versions of Whatsapp (which I don't use, I'm FOSS-only) offer essentially the same capabilities as this application though, including end-to-end encryption. And of course, essentially the same disadvantages. I could be mistaken here though. > that allows for a fairly narrow and reasonable set of threats (Google/Apple/Microsoft (possibly more than one of each, depending on your platform), Whisper Systems themselves, probably most state actors). I guess it also depends on each user's definition of "fairly narrow and reasonable". :-)
In Worried About the Privacy of Your Messages? Download Signal
> I'm probably just inviting myself to get trolled by replying to this I'm sorry that you get that impression, but I do appreciate your input. > Cryptographer Matthew Green on Signal's crypto and code quality (it was called RedPhone/TextSecure at the time of this writing) That's the application that they sold to Twitter, not the one being talked about here. I do not know how different the code bases are. It is also around that time that the app had a gaping, amateurish hole in that it was simply leaking everything via logcat. And what does the guy do? Instead of addressing the issue like a professional, he goes on a complete tangent rubbishing F-Droid (https://github.com/WhisperSystems/Signal-Android/issues/53) and then making rather poor excuses as to why you should get your application from the Google store and not from anywhere else. E
Read the rest
xcuses which by the way, have been evolving over time. I think he eventually admitted that he wants to keep track of how many users are using it (handy to show to your potential buyers). He also has a history of lying, such as when he used fake WHOIS details to run his "Google anonymiser" thing. And of course, when he was shut down by the registrar, as you do when someone has given you false details, what did he do? He went to the press to whine about the registrar! After he entered a contract in bad faith, something which happens to be a prosecutable offence. That's the sort of person we are talking about here. I hope you will understand if his word does not exactly fill me with confidence. > https://www.eff.org/node/82654. That page starts with: "This is version 1.0 of our scorecard; it is out of date, and is preserved here for purely historical reasons." And continues with: "the results in the scorecard below should not be read as endorsements of individual tools or guarantees of their security" > Signal has been analyzed, with favorable results, by academic researchers at least twice: Yes, I am aware of those. And that is not what validation and verification is which, as I said, in the absence of publicly available design documents, is impossible to do independently. The guy is trying to make it look like he's selling a "secure" communication platform, but if you presented that to a defence contractor (which I have some experience with) you would be laughed out of the building. Proper security is not done like this at all. For a start, you actually define your goals, i.e., what you intend to secure, against what threats, etc., etc. If you can show me a paper with that information I would be grateful. Notably, you may have noticed that those papers, like Green's, are a protocol analysis, not an analysis of the entire solution. In that respect, you're back to the previous situation: the protocol might be ultra-secure, but if you're still leaking your plaintext on a different channel... > Moxie Marlinspike and [...] probably wouldn't call themselves "cryptographers," At the risk of sounding elitist, what is his academic background? (I elided the other person because I do not know who he is). > but almost anybody in the field would agree that they are experts on applied cryptography. What do you base that conjecture on?
In Worried About the Privacy of Your Messages? Download Signal
> it is not open source Huh? https://github.com/WhisperSystems/Signal-Android I'd even argue it's free software - the team has managed to create some confusion about distributing modified binaries - with regards to using the servers Signal operates -- but have clarified that it is indeed ok to build your own binary from the source they provide, and use their servers. I'm not quite convinced about their argument for official app store distribution and updates, but I can understand the argument. > it requires Google Play services I'm fairly sure the iOS client doesn't depend on Google Play Services. Sticking with an app store does require trust in the provider though. Whisper System have made some fairly clear choices, and while it's perfectly fine to disagree, I think it would be best to avoid FUD. It certainly strikes me as one of the be
Read the rest
tter options for pragmatic secure messaging, that allows for a fairly narrow and reasonable set of threats (Google/Apple/Microsoft (possibly more than one of each, depending on your platform), Whisper Systems themselves, probably most state actors). The other reasonable option I'm aware of (that make slightly different trade-offs), is ChatSecure/zom.im (where zom.im is a "friendly" fork of ChatSecure).
In Worried About the Privacy of Your Messages? Download Signal
Thank you! tl;dr: You can fork the Signal code if you want, but if you do, Moxie Marlinspike asks you to change the app name and run your own servers. The server source code appears to be available at https://github.com/WhisperSystems/Signal-Server, but I've heard it doesn't include the voice component. So, for example, if you think that Signal ought to support a feature like iMessage's "Invisible Ink" (https://mic.com/articles/146347/i-os-10-s-invisible-ink-feat...), which Moxie has specifically refused to support (https://github.com/WhisperSystems/Signal-Android/issues/5103), then you can't just fork the client, implement it yourself, and use the new client normally, because you'd no longer be able to talk to regular Signal client if I understand correctly. I mean, even if you figured out a way for two clients to tell each other whether
Read the rest
or not the feature was available. So Signal is open source, but not in a way that's useful if you want to change something. I don't want to discourage people from using Signal. It's a great app. But I thought this was worth pointing out, assuming the LibreSignal is representative of what will happen if people want to make changes to their client.
In Worried About the Privacy of Your Messages? Download Signal

Showing the 15 most recent of 46 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.