Open hoehermann opened 4 years ago
I compiled and ran the plugin with Arch Linux and signal-cli
from AUR. This specific package from AUR places the jars under /usr/share/java/signal-cli
. purple-signal.so
had to be renamed to libpurple-signal.so
(lib
-prefix). After that I was able to run it and link it with my account.
Hm I missed this earlier, sorry; I should be able to test this out later this week. For reference, I'll be using this as a plugin to bitlbee, compiling then running in an Alpine docker container. I presume this can peacefully live alongside the existing signald-based plugin?
@mooomooo Yes. By design, they do. At least they coexist on my system. :D
If you registered the number via signald, you need to use signald's add_device command directly (with netcat via command-line or something).
If you registered the number via the official app on your phone, you can use qrencode
or any appropriate online service to generate a QR code to link your account.
This plug-in uses the directory structure from signal-cli. You can switch back and forth between the two, but not use both at the same time simultaneously.
Hm. Not having any experience with cmake, I'm not sure if I'm doing the right thing. I'm getting warnings that are treated as errors and thus not allowing me to build.
RUN curl -LO# https://github.com/AsamK/signal-cli/releases/download/v0.6.8/signal-cli-0.6.8.tar.gz
RUN mkdir /opt/signal-cli
RUN tar xzvf signal-cli-0.6.8.tar.gz -C /opt/signal-cli --strip-components=1
RUN git clone https://github.com/hoehermann/purple-signal.git
WORKDIR /root/purple-signal
RUN cmake .
RUN cmake --build . --target install
Dies with errors (full trace snipped):
/usr/include/libpurple/media/../util.h:1397:13: error: Deprecated pre-processor symbol, replace with [-Werror]
1397 | G_CONST_RETURN gchar *purple_gai_strerror(gint errnum);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
...
/usr/include/libpurple/media.h:165:3: error: 'GParameter' is deprecated [-Werror=deprecated-declarations]
165 | guint num_params, GParameter *params);
| ^~~~~
...
/usr/include/glib-2.0/gobject/gparam.h:271:8: note: declared here
271 | struct _GParameter /* auxiliary structure for _setv() variants */
| ^~~~~~~~~~~
... (and another deprecated GParameter ) ...
cc1: all warnings being treated as errors
make[2]: *** [c/CMakeFiles/purple-signal.dir/build.make:83: c/CMakeFiles/purple-signal.dir/libsignal.c.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:162: c/CMakeFiles/purple-signal.dir/all] Error 2
make: *** [Makefile:150: all] Error 2
Error: error building at STEP "RUN cmake --build . --target install": error while running runtime: exit status 2
@mooomooo I have seen this error in purple-gowhatsapp. It is not an issue with this plug-in's code, but rather between glib and the purple library. Please remove -Werror
from c/CMakeLists.txt
and try again.
Hm ok having made that change, it compiles and I now have a /usr/lib/purple-2/libpurple-signal.so
alongside my /usr/lib/purple-2/libsignald.so
. But the plugin isn't showing up in my list of supported protocols? There's nothing in the bitlbee log, but I don't really know what I'm doing here so I'm not sure how to debug.
Well in that case I just take your findings as "does not work with bitlbee". Thank you for your help. :)
Hello Hermann,
I have downloaded the binaries provided by your buildbot and successfully got the plugin running. I have noticed the following and would like to make sure that this is the expected behavior of this early stage of development.
Best regards Torsten
On Sun, 2020-07-05 at 15:24 -0700, Hermann Höhne wrote:
@fancypantalons @ttlmax @mooomooo In the past days, I saw you being active over at libpurple-signald. Care to help me out testing this project? Compared to libpurple-signald, purple-signal integrates way more directly with signal-service-java. My gut says, this is cool and we should focus future development on this one rather than libpurple- signald. purple-signal eliminates the need for a separately running service and offers support for Windows. Right now, only linking to an existing device and single chats are supported. I am interested in finding out whether is it usable for any of you. Binaries are provided here: https://buildbot.hehoe.de/purple-signal/builds/ (.so is targeted Ubuntu amd64 18.04). Installation instructions are located here: https://github.com/hoehermann/purple-signal/blob/master/INSTALL.md — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.
Thank you for your response @ttlmax . Good to hear my binary works for you.
I did not implement these for this alpha.
Ugh. That sounds like a nasty one. Thank you for pointing it out. I always power off my machine, next to never I suspend it. I would never have noticed. Now I can investigate.
I've downloaded the Windows dll, copied it to Pidgin's plugins folder and restarted Pidgin but I can't select Signal as a protocol when I want to add a new account. Using Pidgin 2.14.1 on Windows 10.
@rvdborgt Thank you for taking the time to try the plug-in. Unfortunately, copying the dll is not enough. The plug-in also needs the jar, the jars coming with signal-cli and a 32bit installation of Java added to the path (so jvm.dll can be loaded automatically). INSTALL.md contains detailed instructions.
It is possible for me to enhance the dll in such a way that it actively complains about missing files. Implementing this is tedious, makes the overall code more error-prone and – at best – provides a one-time benefit for each user only. This is why I chose not to include such functionality in the alpha.
@Mavoy Nice to hear you tried it. During the past weeks, I have been working on some improvements (especially in regard to error handling), but they are not finished yet. Feel free to use the attached binaries to try again.
If they do not work, open a Power Shell window in your Pidgin installation directory, execute "pidgin.exe -d > somelogfile.log". Close Pidgin, search the logfile for "signal" and post it along with a couple of lines before and after. Remove all mentions of personal data.
Pidgin is 32bit so the plug-in needs a 32bit Java. A recent Java 11 or 13 runtime can be obtained from https://adoptopenjdk.net/releases.html. I should probably supply an installer next. ;)
Hey @hoehermann, thanks for finding time to work on this! It would be super useful to have Signal support in Pidgin on Windows. I tried to set it up and here are my findings:
plugins
dir.(21:09:00) plugins: D:\Apps\Pidgin\plugins\purple-signal.dll is not loadable: `D:\Apps\Pidgin\plugins\purple-signal.dll': The specified module could not be found.
Since the plugin wasn't loaded I didn't see Signal as an option when adding a new account. The error is not super helpful, as it doesn't state what module cannot be found. Do you have any idea how can I get more info on this issue? I use Windows 10, Version 2004 (OS Build 19041.685) and Pidgin 2.14.1 (libpurple 2.14.1).@konto-andrzeja Thank you for contributing. Every piece of information is valuable. Did you adjust your user's environment variables so C:\wherever\you\put\OpenJDK\jre\bin\client
is listed in PATH
? Many uses overlook this step. I am working on an installer that does this, but it is not ready yet.
@hoehermann C:\Program Files (x86)\AdoptOpenJDK\jdk-15.0.1.9-hotspot\bin
was added automatically by the installer, now I tested C:\Program Files (x86)\AdoptOpenJDK\jdk-15.0.1.9-hotspot\bin\client
, but it didn't help. Since open-cli
works, I assumed my Java set up is ok.
My bet would be on purple-signal.dll
requiring some other dll file which I don't have. I had a similar issue with some other plugin, if I remember correctly I had to add libjson-glib-1.0.dll
to D:\Apps\Pidgin
directory and it was fixed. Could you check what kind of dll files you have in your pidgin directory? I'll also try this to find the culprit, but it may take a while.
I tried to do the following:
plugins
directory.The only additional three files that were requested by Pidgin when trying to load purple-signal were jvm.dll
, libgcc_s_sjlj-1.dll
, libstdc++-6.dll
. I have those files, I added them to Pidgin
root directory, so they can be found easier and they were, but then VCRUNTIME140.dll
was missing, event though I have Microsoft Visual C++ 2015 Redistributable
installed. I could add more and more of those files but I have a feeling it shouldn't be necessary. I found some tips about using -static-libgcc
and -static-libstdc++
compiler flags to include at least some of those DLLs in binaries, maybe that's the way. Or maybe something is wrong with my Java after all.
Good, very good. Thank you for the input. I now know that I need to look out for dynamic dependencies. I obviously have them installed implicitly in my development environment, but a pristine Windows installation probably won't have them. I found this question, but it looks like I need to fiddle around with the options to link everything statically but not jvm.dll
and purple.dll
.
@konto-andrzeja I am sorry, I am very sorry. In the end, it turned out to be a caching error in the build bot. The current build now uses the proper configuration. Only direct dependencies are now (correctly) jvm.dll
, libglib-2.0-0.dll
(from gtk+) and, libpurple.dll
(from Pidgin). Please feel free to try again.
It works, awesome! I successfully linked my account and was able to send some messages, then saw them in the mobile app. Since it's 1am everybody is asleep and nobody will answer, so I'll test receiving messages in the coming days.
It seems that receiving messages doesn't work. I get Exception while handling message: null
when somebody writes to me.
Dang it. Here I was, thinking it was working at least a bit. Receiving messages is working fine for me. In my tests, I use a number which I registered directly. I assume, messages from linked devices are transferred differently. I want to try and get myself a smartphone to run the official client on so I can test it this theory.
I just checked signal-cli
to make sure that it works and it does work, signal-cli -u MY_NUMBER receive
command receives messages. If I can help you in any way let me know.
I welcome your offer to help. If you start pidgin.exe -d
from cmd or PowerShell, does the Java Runtime print a stack trace right before/after "Exception while handling message: null" happens?
Now it's working. I wonder if it has something to do with the fact that when checking whether signal-cli
works on its own, I manually did this for the contact that's testing with me.
Also, after setting up signal-cli
I had to link my account again and it failed several times before I finally managed to make it work. I don't know how I made it work, I tried several times, removing my account and adding it again, at some point it started working. When it failed it was with this error:
connection: Connection error on 04449C20 (reason: 16 description: Unable to finish device link: null)
org.asamk.signal.manager.UserAlreadyExists
at org.asamk.signal.manager.ProvisioningManager.finishDeviceLink(ProvisioningManager.java:83)
at de.hehoe.purple_signal.PurpleSignal.lambda$linkAccount$0(PurpleSignal.java:101)
at java.base/java.lang.Thread.run(Thread.java:832)
Exception in thread "finishDeviceLink" (20:34:50) gtkutils: gdk_pixbuf_new_from_file() returned nothing for file D:\Apps\Pidgin\pixmaps\pidgin\protocols\16\skype.png: Failed to open file 'D:\Apps\Pidgin\pixmaps\pidgin\protocols\16\skype.png': No such file or directory
java.lang.NullPointerException: Cannot invoke "String.equals(Object)" because "<local2>" is null
(20:34:50) gtkutils: gdk_pixbuf_new_from_file() returned nothing for file D:\Apps\Pidgin\pixmaps\pidgin\protocols\16\signal.png: Failed to open file 'D:\Apps\Pidgin\pixmaps\pidgin\protocols\16\signal.png': No such file or directory
at de.hehoe.purple_signal.PurpleSignal.lambda$linkAccount$0(PurpleSignal.java:106)
at java.base/java.lang.Thread.run(Thread.java:832)
One thing I'd like to report after chatting with my friend is that those [Message delivery.]
and [Message read.]
messages could be optional. Especially the former, since it always pops up after I send a message.
It looks like I did not fully understand how signal-cli works internally. Accounts managed by signal-cli and purple-signal should be completely independent as they use different locations (signal-cli uses a file somewhere in %userprofile%, purple-signal uses the Pidgin user's accounts.xml) to store their data (including the keys) in. Apparently, there is still some overlap somewhere.
The setup being unreliable is bad. Good you made it work by persistence. :) Nice to hear it is working for you. At least for now.
The debug output looks very useful. Thank you for providing it. I cannot do much about the linking being unreliable, but I should be able to display the reason (UserAlreadyExists) in Pidgin rather than the unhelpful "null" error message. :)
I can make the messages optional. They are only there to help with debugging. ;)
More testing today with the newest version. It seems that my conclusion about signal-cli
being connected to what happens with Pidgin was premature. What I tried:
UserAlreadyExists
pops up again when trying to link.$HOME/.local/share/signal-cli
folder.UserAlreadyExists
still pops up when trying to link.However, when I send or receive messages using the mobile app, Pidgin crashes. Tried to run signal-cli
and link it to my main account as the second trusted device, then do this again, didn't help.
Tried to use -d 2>&1 > "%USERPROFILE%\debug.log"
when running Pidgin to store logs in a file, so I can see what happened before it crashed, but the file is empty. I'll try to figure that one out, so I can provide you with some logs.
Finally got logging to a file working, but still not sure if what I see in those logs is the cause of the crashes.
When I send a message to somebody using the mobile app, but I don't have this somebody stored as a contact in Pidgin, it crashes with:
[signal] SignalServiceEnvelope
[signal] ServerTimestamp: 0
[signal] SourceAddress:
[signal] Number: +MY_NUMBER
[signal] Timestamp: 1608896767773
[signal] isSignalMessage
[signal] SignalServiceContent
[signal] serverTimestamp: 0
[signal] SyncMessage
[signal] Sent:
[signal] Destination:
[signal] Identifier: SOME_UUID
[signal] Number: +RECIPIENT_NUMBER
[signal] Message:
[signal] Body: "Test message"
[signal] Recipients:
[signal] +RECIPIENT_NUMBER
[signal] timestamp: 1608896767773
[signal] timestamp: 1608896767773
(12:46:09) g_log: purple_conversation_get_im_data: assertion `conv != NULL' failed`
It even crashes when Pidgin was off at the time of sending the message and is started later. In pidgin.RPT I can see this:
Error occured on Friday, December 25, 2020 at 12:46:09.
Windows Version 6.2 Build 9200
D:\Apps\Pidgin\pidgin.exe caused an Access Violation at location 68367979 in module D:\Apps\Pidgin\pidgin.dll Writing to location 00000000.
Registers:
eax=00000000 ebx=0283962c ecx=04770408 edx=ffe5d100 esi=048828c8 edi=04770408
eip=68367979 esp=0061da60 ebp=028395c8 iopl=0 nv up ei pl zr na po nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010246
Call stack:
D:\Apps\Pidgin\pidgin.dll [2.14.1.0]
Using Debug Symbols from: D:\Apps\Pidgin\pidgin-2.14.1-dbgsym\pidgin.dll.dbgsym
68367979 D:\Apps\Pidgin\pidgin.dll pidgin_connection_uninit
When I add this contact manually in Pidgin and send a message from Pidgin (important, without this step it still crashes), then it starts to handle messages from the mobile app. This conv != NULL' failed
no longer pops up.
EDIT: Two more things:
Exception while waiting for message: Cannot invoke "org.whispersystems.signalservice.api.messages.SignalServiceContent.getSender()" because "<parameter2>" is null
or Exception while handling message: org.whispersystems.libsignal.InvalidMessageException: No valid sessions.
errorsAccess Violation
Thank you for your tests. None of the problems you describe happen on my system, so it is very useful you tell me about them – without your help, I would never know. :)
assertion conv != NULL failed
is not a critical error. It happens if there is currently no conversation window open for the contact. It should not be affected by the contact being on the buddy list or not. I want to find out why it crashes.
The Exception while handling message
indicates an error in the library functions, I merely forward it to the Pidgin UI. Maybe I am using the library wrong. The Exception while waiting for message
is an odd one. I cannot even see where it comes from. I will probably take long until I can really fix these errors. In the meantime, I want to make them "non-fatal" so Pidgin at least automatically reconnects the account.
None of the problems you describe happen on my system
Then I guess all the issues pop up only if you also use the mobile app and you link to your existing account instead of registering a new one.
It happens if there is currently no conversation window open for the contact. It should not be affected by the contact being on the buddy list or not. I want to find out why it crashes.
Makes sense, the second time I had the window open since I sent a message. Unfortunately I'm not able to provide more info, unless you have some ideas on how to force Pidgin to provide more logs. The last line in the log file before Pidgin crashes is this assertion conv != NULL failed
. In pidgin.RPT
I only get the infamous Access Violation
. I think it would be super helpful if somebody with the mobile app set up could try and reproduce it using the steps I provided.
I will probably take long until I can really fix these errors. In the meantime, I want to make them "non-fatal" so Pidgin at least automatically reconnects the account.
Sure thing, it's awesome that you're doing this at all, take your time and if I can help you in any way, let me know.
One additional thing I've noticed - the messages are properly logged and I can access them with View log
even though the app crashed. So it works something like this:
View log
and I can see all three messages there in separate entries.Thank you for being with me on this. :) I spent an entire day adapting the build process to MSVC so I can debug with Microsoft Visual Studio on native Windows 10. Unfortunately, I gained some experience and a huge amount frustration, but no significant insights. It looks like I managed to write code which results in undefined behaviour. Is is no problem on Linux, it is not much pronounced when cross-compiling for win32 with GCC, but is absolutely horrible when compiled with MSVC. With an MSVC build, I cannot even send or receive a single message without a crash. It looks like the stack becomes corrupted in the moment a call from C into Java happens or when GTK is involved. Last time I had a problem like this, it stumped me for half a year (see a44efce) – let's hope this time the solution is found quicker. ;)
It's not that extreme for me, I can send messages without much problems, but receiving can crash my Pidgin, unfortunately it now also happens even for added contacts to which I sent some messages.
Also, today I ran into another error org.whispersystems.signalservice.api.push.exceptions.PushNetworkException: java.net.UnknownHostException: No such host is known (textsecure-service.whispersystems.org)
which disabled my account.
I've got the plugin to show up in accounts but when I try to set up my account I get an account disabled message with the error
'Failed to find class 'de/hehoe/purple_signal/PurpleSignal'.'
I double checked the install instructions and everything seems to be in order. The only thing is that my pidgin lives in .\Program Files (x86)., but if that where a problem the plugin wouldn't even show up would it?
Why not "plain old C", why using Java? I always had problems with Java - programs using Java frequently requires "this and no older and no newer version" of Java, and when someone wants more than one program using Java, it creates nightmare of many different version of Java, and redirecting apps to use correct Java installation :)
@pkar70 A good suggestion, but the implementation of the Signal protocol is more than 25000 lines of Java code. The implementation also depends on 35 libraries which also may or may be not be available for Java exclusively. Re-implementing all of that in C is not something I have fun doing. And I do this for fun. ;)
@Michkovy Did you copy both, the .dll and the .jar into Pidgin's "plug-ins" directory? I was working on an installer, but I did not finish it, yet. If you start pidgin from within e.g. the PowerShell with pidgin.exe -d
, some of the output might be useful.
Anyway, I just uploaded my latest changes, new binaries are available. Unfortunately, the win32 build suffers from undefined behaviour. I have not figured out where it comes from. :(
So, it is very complicated protocol :) Your WhatsApp plugin probably has much less lines of code :)
@pkar70 My WhatsApp plugin does exactly the same: The real work is done by a library. The library is not written in C but in go. The plug-in also has less features and is badly written. I struggle more with the interface to Java than with the interface to go. It still feels good to learn from the experiences. :)
@Michkovy Did you copy both, the .dll and the .jar into Pidgin's "plug-ins" directory? I was working on an installer, but I did not finish it, yet.
I can confirm that both dll and jar is in plugins. I've updated to the latest version of all files too. Install instructions still point to signal-cli v0.6 btw. Still getting the same error.
I tried logging but the log file is empty. Just to have it right.
Then I'd expect there to be something in the log, right?
@Michkovy Thank you for pointing out the old version in the instructions. Your assumptions are correct. Though pidgin should start with the PowerShell being open. That is odd.
Update: I just noticed that the current signal-cli needs an additional library. I updated the installation instructions. You need to download the x86 build from https://github.com/dennisameling/zkgroup/releases/tag/v0.7.1-test and place it besides the purple-signal.dll and purple_signal.jar. What a mess!
On the bright side, the MSVC warned me about dangerous implicit type conversions. One of them regarding 64 bit timestamps in 32 bit applications was actually helpful. The current windows build now crashes less often. :)
The newest version is a huge improvement, I had a proper conversation using Pidgin, messages from the the mobile app were properly synchronized, looks really promising. Awesome job! I'll use the plugin for some time and check if there are any bugs left. :)
No change for me with the new builds. I noticed you have a different java from me in the install instructions, where you have openjdk-11. I'm using the Oracle java, could be a difference between the two.
Regarding the log, pidgin starts while the powershell is still open, but never fully boots. I can see Pidgin in the task manager, but it only shows the main window once powershell is exited.
pidgin.exe -d > somelogfile.log
@Michkovy This should be .\pidgin.exe -d 2>&1 > "c:\debug.log"
. For me it opens a new terminal window with logs in it and Pidgin starts. Logs are also stored in c:\debug.log
. I actually use the portable version, so to be more precise it's .\pidgin-portable.exe -d 2>&1 > c:\debug.log
.
@Michkovy I'd like to try it just to see the difference, but I cannot even find Oracle Java 11 for Windows i586/x86/32bit. https://jdk.java.net/java-se-ri/11 features only x64/64bit builds. https://www.java.com/de/download/manual.jsp only offers Java 8.
Meanwhile I found out that in PowerShell one needs to prefix the command with an ampersand. So
& .\pidgin.exe -d 2>&1 | Out-File pidgin.log -Encoding UTF8
is working for me.
Right got logging to work now, thanks for bearing with me on that. Here is the interesting bit, Pidgin trying to connect to signal, stripped my phone number from the first line but that's all I did. I got the full log if you need more.
(05:54:58) account: Connecting to account
(05:54:58) connection: Connecting. gc = 42605040
(05:54:58) signal: -Djava.class.path=C:/Program Files (x86)/Pidgin/plugins/purple_signal.jar;C:\Program Files (x86)\Pidgin\Gtk\lib/annotations-13.0.jar;C:\Program Files (x86)\Pidgin\Gtk\lib/argparse4j-0.8.1.jar;C:\Program Files (x86)\Pidgin\Gtk\lib/asm-7.1.jar;C:\Program Files (x86)\Pidgin\Gtk\lib/asm-analysis-7.1.jar;C:\Program Files (x86)\Pidgin\Gtk\lib/asm-commons-7.1.jar;C:\Program Files (x86)\Pidgin\Gtk\lib/asm-tree-7.1.jar;C:\Program Files (x86)\Pidgin\Gtk\lib/asm-util-7.1.jar;C:\Program Files (x86)\Pidgin\Gtk\lib/bcprov-jdk15on-1.68.jar;C:\Program Files (x86)\Pidgin\Gtk\lib/curve25519-java-0.5.0.jar;C:\Program Files (x86)\Pidgin\Gtk\lib/dbus-java-3.2.4.jar;C:\Program Files (x86)\Pidgin\Gtk\lib/jackson-annotations-2.9.0.jar;C:\Program Files (x86)\Pidgin\Gtk\lib/jackson-core-2.9.9.jar;C:\Program Files (x86)\Pidgin\Gtk\lib/jackson-databind-2.9.9.2.jar;C:\Program Files (x86)\Pidgin\Gtk\lib/java-utils-1.0.6.jar;C:\Program Files (x86)\Pidgin\Gtk\lib/jffi-1.2.23-native.jar;C:\Program Files (x86)\Pidgin\Gtk\lib/jffi-1.2.23.jar;C:\Program Files (x86)\Pidgin\Gtk\lib/jnr-a64asm-1.0.0.jar;C:\Program Files (x86)\Pidgin\Gtk\lib/jnr-constants-0.9.15.jar;C:\Program Files (x86)\Pidgin\Gtk\lib/jnr-enxio-0.28.jar;C:\Program Files (x86)\Pidgin\Gtk\lib/jnr-ffi-2.1.15.jar;C:\Program Files (x86)\Pidgin\Gtk\lib/jnr-posix-3.0.58.jar;C:\Program Files (x86)\Pidgin\Gtk\lib/jnr-unixsocket-0.33.jar;C:\Program Files (x86)\Pidgin\Gtk\lib/jnr-x86asm-1.0.2.jar;C:\Program Files (x86)\Pidgin\Gtk\lib/kotlin-stdlib-1.3.71.jar;C:\Program Files (x86)\Pidgin\Gtk\lib/kotlin-stdlib-common-1.3.71.jar;C:\Program Files (x86)\Pidgin\Gtk\lib/libphonenumber-8.12.6.jar;C:\Program Files (x86)\Pidgin\Gtk\lib/okhttp-4.6.0.jar;C:\Program Files (x86)\Pidgin\Gtk\lib/okio-jvm-2.6.0.jar;C:\Program Files (x86)\Pidgin\Gtk\lib/protobuf-javalite-3.10.0.jar;C:\Program Files (x86)\Pidgin\Gtk\lib/signal-cli-0.7.2.jar;C:\Program Files (x86)\Pidgin\Gtk\lib/signal-metadata-java-0.1.2.jar;C:\Program Files (x86)\Pidgin\Gtk\lib/signal-protocol-java-2.8.1.jar;C:\Program Files (x86)\Pidgin\Gtk\lib/signal-service-java-2.15.3_unofficial_15.jar;C:\Program Files (x86)\Pidgin\Gtk\lib/slf4j-api-1.7.30.jar;C:\Program Files (x86)\Pidgin\Gtk\lib/slf4j-nop-1.7.30.jar;C:\Program Files (x86)\Pidgin\Gtk\lib/slf4j-simple-1.7.30.jar;C:\Program Files (x86)\Pidgin\Gtk\lib/threetenbp-1.3.6.jar;C:\Program Files (x86)\Pidgin\Gtk\lib/zkgroup-java-0.7.0.jar
(05:54:58) signal: -Djava.library.path=C:/Program Files (x86)/Pidgin/plugins
Listening for transport dt_socket at address: 10044
(05:54:58) connection: Connection error on 42605040 (reason: 16 description: Failed to find class 'de/hehoe/purple_signal/PurpleSignal'.)
If I read the second to last line right is it looking for java in the wrong place? My java path is
C:\Program Files (x86)\Java\jre1.8.0_271\bin\client
it appears to look at
C:/Program Files (x86)/Pidgin/plugins
before throwing the error.
As for the version, I'm using v8 update 271 build 1.80_271-b09, 32 bit. Your install instructions have the v11 in them.
Thank you for the reply. Due to recent changes in the signal library, Java 11 is actually the required minimum. Java 8 cannot run it. :(
I updated the installation instructions regarding support for the new groups on Windows.
@pkar70 I just noticed that someone is actually doing what you suggested: The protocol is being reimplemented here. The new and annoying dependency of zkgroups.dll for the V2 groups is a sign they will eventually move away from the current implementation completely. It looks like with my plug-ins (signal and signald), I am basically riding dying horses. I am considering to throw things. It was fun while it lasted, though.
But I want Windows version of plugin to Pidgin :)
Linking to a phone, plain text messaging (one on one and groups), receiving attachments from others (not from self) works on Windows. I want to tackle downloading contacts and registration without a phone next. However I doubt if it is sensible to pursue this approach with the new library coming up to replace it anyway. :/
Right got it working now, just need contacts on Signal to talk to, I should be able to figure that out myself.
It looks like with my plug-ins (signal and signald), I am basically riding dying horses. I am considering to throw things. It was fun while it lasted, though.
Not sure I understand, does that mean that signal-cli
will stop working soon?
For now your plugin is super stable, even though it's alpha with debug messages it doesn't crash and everything works fine (apart from receiving images, but I just check them on my mobile app :)). You basically fixed every issue I mentioned and you did it almost immediately after it was reported. Hopefully people can enjoy effects of your great work a little longer.
@fancypantalons @ttlmax @mooomooo In the past days, I saw you being active over at libpurple-signald. Care to help me out testing this project? Compared to libpurple-signald, purple-signal integrates way more directly with signal-service-java. My gut says, this is cool and we should focus future development on this one rather than libpurple-signald. purple-signal eliminates the need for a separately running service and offers support for Windows. Right now, only linking to an existing device and single chats are supported. I am interested in finding out whether is it usable for any of you.
Binaries are provided here: https://buildbot.hehoe.de/purple-signal/builds/ (.so is targeted Ubuntu amd64 18.04).
Installation instructions are located here: https://github.com/hoehermann/purple-signal/blob/master/INSTALL.md