HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
signalapp
libsignal-protocol-java
Java2016–2021
signalapp / libsignal-protocol-java · Archived

libsignal-protocol-java

Discover this repository through its Hacker News conversations.

Explore on GitHubRead Hacker News discussions
11Distinct people
15Mentions
0Explicit recommenders
1.8KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

A public description has not been verified.

Where it is used

No documented product use was verified in the last source check.

What people are saying

No recommendation phrase was found in the indexed comments.

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:45:45 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 year15 dated mentions

Observed mentions: 2016-04-05 17:53:41 UTC to 2021-11-25 02:25:25 UTC.

0369122016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 12 mentions; 0 submissions, 12 comments20162017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 1 mentions; 1 submissions, 0 comments20182019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2021

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
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC12012
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC101
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC110
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC000
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC000
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC101

What Hacker News says

12 sources
moxie·Nov 28, 2016
> But "their own needs" are completely out of bounds for you, and it seems pretty clear that this isn't something that's going to be fixed in patches and code, so expecting them to come and fix it because you have an open code base is rather disingenuous. Many of the things listed in these articles, such as making GCM optional, or supporting distribution outside of Play, are not "completely out of bounds." We've expressly indicated support for them and enumerated the work required, but nobody has committed to doing the work. I don't expect anyone to do the work, but I do think it's strange when someone from the FOSS community complains that we haven't done it for them. > If you started by promoting Signal as a generic protocol or backend to other projects, it would get much more traction in the FOSS community, as they are attracted to co
Read the rest
mponents on which other things can be built. Signal is broken into three layers, two of which are designed to provide exactly that: A crypto protocol that can be incorporated into other projects: https://github.com/whispersystems/libsignal-protocol-java A service protocol that can be pointed at any back end: https://github.com/whispersystems/libsignal-service-java The service protocol even includes support for federation. I don't think it's a good idea for the reasons I've enumerated, but anyone can use this code to start their own federated network and prove me wrong. > For human and community reasons, the upside to federation is probably a lot higher than you appreciate. I hope you consider it. You have built a nice platform, but for your work to make a lasting impact you need to share it with others. We've done more than consider it, we've done it. We started Signal as a federated service, and it was kind of a disaster. I'd definitely reconsider if people have a plan for avoiding the problems that we encountered the first time, beyond "federation is good." In the mean time I'm happy to help anyone deploying Signal in their own federated environment.
In Wrong signal
niftich·Jul 8, 2016
> I'm assuming for people who don't have strong security backgrounds That's already a bad start. You mean inventing Signal from scratch (which is rough) or incorporating the libsignal protocol into a new messaging app? All of the libsignal repos have a good readme that explains init [1][2] , so you can start there. Browsing Signal source is helpful not so much to understand the protocol, but to see if any special precautions were taken against side-channel and other implementation pitfalls. I mean, you could contract moxie (hey moxie, what's your price?) EDIT: there's also this [3] independent implementation of libsignal in golang that tries to make some targeted modifications to fit their need. Can't vouch for its quality, but it's an interesting effort nonetheless. [1] https://github.com/WhisperSystems/libsignal-protocol-java [2] https:
Read the rest
//github.com/WhisperSystems/libsignal-service-java [3] https://github.com/OpenBazaar/libsignal
In Facebook Messenger begins testing end-to-end encryption using Signal Protocol
jsnell·May 18, 2016
"Impossible" is a tough standard to meet. But given how different idiomatic Java code and idiomatic Rust code are, it does seem kind of unlikely. I'd expect nothing at all would carry over from one codebase to the other even if you were making as straight a port as possible. Or alternatively one program would look like total garbage, like someone mechanically translating Lisp to C. And indeed, with a quick browse through the Wire [0] and OWS [1] repositories I just can't find any kind of commonalities at all. Not in the structure, not in the comments, not in naming, not in the data structures, etc. Am I missing something, is there anything at all in the code itself that suggests the two codebases are related in any way at all? Or is the "GPL's OWS code" you refer to something else entirely? [0] https://github.com/wireapp/proteus/tree/dev
Read the rest
elop/src/intern [1] https://github.com/WhisperSystems/libsignal-protocol-java/tr...
In Open Whisper Systems Partners with Google on End-To-end Encryption for Allo
nkobeissi·May 18, 2016
> Complaints about Signal are, unsurprisingly, getting dumber and more venomous. For instance, last week, Nadim Kobeissi (the author of Cryptocat, a competing secure messaging system that I think you should avoid) was on Twitter talking about how impossible a GPL violation could have been given that Wire's Signal implementation is in Rust. Given that I'm mentioned by name (and tied to a bunch of exaggerated claims), I'd like to clarify a few points. 1. I never claimed that a GPL violation was impossible because of different programming languages. I merely questioned whether this was the case with Wire's Rust codebase [0], given that its data structures, namespacing etc. are substantially different from the OWS Java code [1]. To me, different code organization + different implementation style + different programming language don't exactly
Read the rest
amount to a line-by-line conversion from Java to Rust as OWS seems to be claiming. 2. Cryptocat does not compete with Signal: it's a desktop XMPP client that focuses on synchronous messaging (that I write in my free time and with no funding or business plan, to boot), and does not at all target the mobile space. I was very happy to adopt a variant of Signal Protocol into Cryptocat and consider Signal's contributions to the field of secure messaging to be highly valuable. I'm not sure why tptacek brings up Cryptocat (completely unrelated to this discussion) but by all means, don't avoid it! The recent rewrite is pretty good, actually. Overall, this situation just struck me as very ugly. Moxie seemed at some point to be reticent to allow fully independent implementations of the protocol, and Wire's lawsuit was pretty aggressive. Both parties locked in a catfight and then (apparently?) realized their approaches were counterproductive and gave it up. The best resolution here, in my view, would have been for Moxie to publish a public-domain reference specification document of Signal Protocol that's independent of the code, and for Wire to be allowed to write a Rust implementation of it without any party causing drama. [0] https://github.com/wireapp/proteus [1] https://github.com/WhisperSystems/libsignal-protocol-java
In Open Whisper Systems Partners with Google on End-To-end Encryption for Allo

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.