Library catchup with official java versions

[mitchcapper]

Digging into #43 it seems the like issue that has broken the library (at least for me) is the fact the protocol version has increased the compat requirement beyond where we are at.
While I haven't done any of the official migrations myself from java->csharp I would be happy to give it a wack. I could use some guidance though.

libsignal-protocol-dotnet

Seems up to date (or nearly there with no major commits it looks like in the official repo). The official source I assume is still https://github.com/signalapp/libsignal-protocol-java as I can't find a similar protocol folder to the service migration at https://github.com/signalapp/Signal-Android/tree/master/libsignal/service

libsignal-service-dotnet

The bigger issue. While casually looking through the commits at https://github.com/signalapp/libsignal-service-java I don't see anything majorly difficult to migrate (or maybe it all is as I already see some of the Signal-Android commits in?). can you just clarify which commits there are not yet migrated?

Now the switch to https://github.com/signalapp/Signal-Android/tree/master/libsignal/service may be a bit trickier. Did they import the old history into that repo? How big of a refactor are we talking? I can start walking that as well but again guidance on which commits would be helpful. it seems it did migrate back to protocol buffer v3.

libsignal-metadata-csharp

does seem up to date with https://github.com/signalapp/libsignal-metadata-java/commits/master

Signal-Windows

I don't use this but not sure if there are requirements to get just basic messaging working again with updates. I am guessing a few looking at the items that prevent the latest libsignal-metadata-csharp from working.

[golf1052]

Any help is definitely appreciated.

libsignal-protocol-dotnet is up to date with libsignal-protocol-java as far as I know (they both are on 2.8.1).

libsignal-metadata-dotnet is up to date with libsignal-metadata-java as far as I know (they both are on 0.1.2).

For libsignal-service-dotnet migration is similar to migrating code in the other two repos. The biggest difficulty I typically run into is migrating code that uses javax.crypto. Ever since this commit Signal moved from Spongy Castle (which is basically Bouncy Castle) to javax.crypto. With enough searching online and looking at old code it is possible to figure out what the equivalent C# Bouncy Castle code would be. My recent PR to add the contact discovery service includes a decent amount of Bouncy Castle code.

In terms of the migration from libsignal-service-java into Signal-Android it appears that they just copied the code from libsignal-service-java into Signal-Android with no missing changes. There's no directory structure change either. Here's the migration commit.

I recently added contributing info for libsignal-service-dotnet so hopefully that's helpful.

I haven't tried doing messaging in the last week since after I got the contact discovery service migrated but I would be surprised that messaging broke with other Signal clients in that period. Something that might be useful would be a signal-cli-dotnet ala the Java signal-cli. It would allow another way to test end to end Signal scenarios but it would also be cross-platform.