Command Line Interface for Signal | Hacker News Reader

Command Line Interface for Signal

github.com

164 pointsjanekg71 comments

A really useful tool for us folks who don't use smartphones, been using it for the last 5 years to have Signal-desktop without a smartphone. Can't thank the maintainer and contributors enough!

https://ctrl.alt.coop/en/post/signal-without-a-smartphone/

> us folks who don't use smartphones

Good to know you. I'm working on a plan to get rid of it myself in the near future, Is there any community for non-smartphone but technically inclined?

So... we're gonna write code in python ...that interfaces with a CLI ...that's a wrapper around a Java library ...that communicates with Signal's API?

Would it not be better to write code in python that communicates directly with Signal's API?

> Would it not be better to write code in python that communicates directly with Signal's API?

Only the official builds of the official signal clients are allowed to connect to the signal servers, everything else is considered unauthorized use (under the CFAA) by moxie, Signal’s lead dev.

At least that’s what he said on the bugtracker of the fork "LibreSignal" while forcing them to shut their fork down.

Forcing?

Didn't Signal have some weird licence restriction saying that non-official clients are not allowed to connect to official servers?

How does this client bypass it? Can I use it to text a friend who uses the official servers?

It's not a licensing restriction, it's a terms of use for their network service. It's also not enforced. Their clients are open source, signal-cli uses a fork of the Android app's client library.

> It's also not enforced

https://github.com/LibreSignal/LibreSignal/issues/37#issueco...

When did this stance change? Is there a current statement from moxie to that effect?

I guess what finnn meant is that nobody can actually stop you from ignoring moxie's statement.

signal-cli uses a clearly identifiable user agent [0] that could easily be blocked if Signal wanted to. signal-cli could escalate by trying to evade that kind of a block, but as it stands signal-cli has been operating without trouble for several years.

I meant they may ask some clients not to use their servers, but they don't have any enforcement mechanism in place beyond asking them to stop on github.

[0] https://github.com/AsamK/signal-cli/blob/05abb3f9f6294677d2d...

If it'd be enforced, we'd see a cat and mouse game of forks spoofing their user agent, and who knows what else.

They can apply measures to the users. They are not doing it right now, but they could suddenly start. By the discussion on some reddit threads [1], this moxie guy looks sketchy to say the least.

But I support the devs who work on alternative clients. The official Electron app is just bad, especially on Wayland. Hope signal-cli will keep working.

[1]: https://www.reddit.com/r/linux/comments/mp2j0j/starting_a_na...

Sorry what am I looking for in this 200 comment reddit thread? I don't see any comments from moxie himself, just a lot of other people claiming to know what moxie wants. Are there reports of specific issues with 3rd party clients or comments from a Signal employee or something?

You are looking for links to what moxie said and people's experiences of interacting with him.

The links to LibreSignal (already mentioned here) and Wire stories summarize most of what I was pointing at: https://github.com/LibreSignal/LibreSignal/issues/37#issueco... https://medium.com/@wireapp/axolotl-and-proteus-788519b186a7

I'm looking for people's experience interacting with the Signal server, not moxie. We're talking about if the server enforces any kind of client restrictions.

I haven't looked super deep, but to the best of my knowledge that's not something that happens really. I looked through that reddit thread (thanks for that BTW, whisperfish seems interesting) and skimmed over that enormous GitHub thread, but I couldn't find much in the way of people actually experiencing issues interacting with the Signal server. Again, would appreciate it if you could link me to such a thing. As I mentioned elsewhere, I maintain an unofficial signal client and I try to be aware of these sort of things.

moxie views the servers as his, to change policy wise as he sees fit. I'm not sure you can separate the two practically.

We know the policy, no one is confused about the policy, all 3rd party clients violate the policy.

Is the policy enforced? I've seen no evidence of it.

Most of the replies in this sub-thread are not about servers possibly disrupting the work of custom clients right now. But you react as if they were.

Other things that are being brought up here are at least as important and interesting to discuss.

Okay, that's fair. I interpreted them as a response to the original question about if the policy is enforced.

I also interpreted them that way.

> this moxie guy

Most people here who are interested in privacy know who "this Moxie guy" is.

Isn't he deliberately pseudonymous?

His civil name is displayed right on the Wikipedia article about him. So not exactly secret.

People wonder why I won't sign up for these Apps.

I said it's not enforced.

I cannot speak for moxie or Signal. I can speak for my own experiences, as the maintainer of a fork of signal-cli, and I have never seen any evidence that Signal's servers block signal-cli or my fork. I don't know about signal-cli but my fork clearly identifies itself in the user agent (and another field called the "signal agent") to the server. If they wanted to block me they could.

edit: signal-cli also sets a user agent clearly identifies itself: https://github.com/AsamK/signal-cli/blob/05abb3f9f6294677d2d...

Not equally enforced is the phrase you probably want, since the linked thread contains evidence of multiple instances of enforcement...

Could you point me to some of those instances?

Can you link to one or two? I read through most and haven’t seen any, but I may have missed it.

https://github.com/LibreSignal/LibreSignal/issues/37#issueco... ?

Again, can you point to a specific comment in that thread indicating enforcement? I see none.

Yes, the one that I linked, and then this one:

https://github.com/LibreSignal/LibreSignal/issues/37#issueco...

A Google Play app was taken down: https://play.google.com/store/apps/details?id=org.privatecha...

A GitHub repo was removed: https://github.com/WizDom13/SignalPlus-Android

After reviewing the thread, I think that it may just be that we have had a genuine misunderstanding over the meaning of the word enforcement due to context. moxie has made it clear that third party clients are not allowed to use OWS servers, and enforced it by having such clients removed from the internet. I feel that counts as 'enforcement' although upon re-reading the thread I can see why this happened. I am not aware of enforcement on the server-side although this is certainly enough to dissuade me from pursuing third-party Signal clients.

edit: reworded after rereading the thread a couple more times

It looks to me like those clients were removed due to trademark infringement (having "Signal" in their name), I don't think they were taken down because their code connects to OWS' servers (would GitHub or Google ever honour a takedown request like that?).

Sending messages to authors of third party clients that you are not ok with their use of your servers (literally the exact comment the link I and other posters shared):

> 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.

Yes, they mention both trademarks _and_ servers, and yes, if there was not a trademark issue, github and google would not remove the repo just for connecting to Signal's servers against Moxie's wishes.

However, the act of informing third party client developers that they are not allowed use the official servers is itself an act of enforcement - maybe one with not much teeth behind it unless he follows up with a legal complaint, but still nonetheless enforcement.

I see what you mean, I guess the mix-up here is that we have different working definitions of "enforcement".

For example, I would argue that Moxie's desire for unofficial clients to not use the word "Signal" in their project name is a statement of policy, whereas the takedown requests to remove the projects from GitHub and the Play Store are examples of enforcement of that policy.

That said I think I can be convinced that directly informing a violator of your policy of said policy is a type of enforcement in itself.

> 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.

I don't get Moxie's stance. Aren't they running Signal as a public service? This sentence reads as if LibreSignal would be stealing profits from Signal by using later's servers. But there is no intention to raise profits / add monetization, is there?

MOB (MobileCoin) looks like an attempt at monetization, a bit shady if you ask me.

Other than monetization, I get Moxie stance, even though I disagree. If you control both the server and the client and don't allow alternative clients and federation, it is easier to make changes, keep focus, and you don't have to deal with complains from users with crappy clients.

Signal is also security and privacy-focused, and Moxie presumably want to keep that image. What if some forks throw away that aspect, for example by storing plain text message in "the cloud". Personally, I actually don't care that much about the privacy/security aspect of Signal, as weird as it may sound, for me, Signal is just a nice, no nonsense messenger with security as a bonus and I would welcome a fork that makes a convenience trade off. But these less secure clients may undermine trust for those who really see it as a primary reason.

If their clients are open source, why would they have a ToS saying you can't make your own clients?

Because open source is only used as a publicity tool by Signal. That's why their server code was abruptly closed sourced without announcement for a year (purportedly to add a scam cryptocurrency that Moxie has a conflict of interest in).

It's hard to trust a project with a divisive, evasive and concealing leader.

This makes me really miss Keybase.io. Anyone around from Keybase? Will it just bit rot away or will it get some attention/love in the future?

It will probably bit rot away, or be rebooted when Zoom wants to make a PR move. In my opinion, the Keybase founders always intended to sell it off and never intended to keep their promises of OSS-ing the tech. It was a cool idea, but I never saw any vision for the idea or really what benefits it brought the tech community.

Do you have any citations for the "founders intended to sell it off" part?

There's a "In my opinion" in front of that sentence. You don't need citations for opinions.

Absolutely, but there are at least some circumstantial things you have heard/read to opine this way?

I still use Keybase heavily for work and personal contacts, and the Linux client just got updated. It's not really a platform with high visibility usage (which is a benefit IMHO).

There are several great e2ee features:

  - 250GB of free storage
  - personal subdomain that serves your public folder
  - git (e2ee)

>250GB of free storage

Would be more useful if you could upload more than one file at a time.

I guess it's intended for use on a computer. I could drag multiple folders/files into my /keybase/private folder.

In what situations does that matter?

I've never seen or hear anyone I know use Keybase.io for actual texting, and I work at a large software company. Everyone just uses it for PGP keys, then forgets it exists.

I was one of the early adopters (July 2014) and I used it for texting for a time.

When they started pushing cryptocurrency I felt it was time to leave, a short time after Zoom bought them out and I was glad that my account was already purged.

For PGP keys, I've managed to replace my usage of Keybase with Keyoxide.

1: https://keyoxide.org/ 2: https://codeberg.org/keyoxide/keyoxide-web

I do and know several people who do too. Although the UI could be improved.

What's so special about keybase? I feel like Signal is current solution to go to if you just need easy e2ee (espexially because of its big userbase). Otherwise it's Matrix for me as it offers "the future of messaging" (well, you wish)

Keybase does way more than just the messaging. Fundamentally it's a really cool solution to the digital identity problem. With that solved, they built a lot of useful tools around those identities, ranging from secure messaging to secure file storage and git hosting.

I should have said this is my comment above, but keybase had a CLI from the start that would do anything the UI would. It would make it usable on a headless machine, and was so easy to script. With the keybase CLI you could write a simple chat bot in a few lines of bash. I had a few "reminder" bots that were just lines in a crontab. Those were the killer features for me.

I really thought Keybase was going to be huge. It had such potential!

I wish it had created a SSO feature to auth 3rd party apps. I think that would have boosted adoption.

I think it's going to rot away, but I really wish it wouldn't.

I really liked the storage and sharing features, the ability to create groups which have git, storage, chat etc that just works. But the devs should have integrated with or made a layer on top of github, gitlab and other git hosting services because a lot of folks wouldn't move their codebase.

I wonder if we'll ever see something similar? "Digital Identity Management" seems like it would be a great use case. What with a wallet feature built in, it seems like there's not much of a leap to having multiple currencies represented there. Plus it could have implemented a password repository or integrated Bitwarden into the storage backend and have the whole thing signed/encrypted by GnuPG.

How does this compare with signald? I wrote a signald xmpp bridge, but signald can be a bit wonky. One time it just stopped responding, and it doesn't pull in as much peer data as the official client.

signald is a fork of signal-cli

signald is developed slower. Right now you need to compile it from git from a branch to fix groups v2.

signald works in the background and can be used with libpurple. If you want to use bitlbee, spectrum2 or similar you need to use signald. Signald needs to be controller over signaldctl

Signal-cli needs to be called manually. There are a few clients that provide wrapper functionality for it and it has dbus functionality.

Edit: removed a sentence over commit frequency and quality as I feel everyone should make their own assesment of this

> at least Java Runtime Environment (JRE) 11

Yeah I stopped right there. I've had enough of one app wanting IBM Java, another wanting Oracle Java, another wanting Sun Java, another wanting 32-bit Java, another wanting 64-bit Java, another wanting Java 8, another wanting Java 11, ...

I really wish this were written in literally any other language, ideally one whose compiler can be apt-gotten on a default Ubuntu install.

You could use a docker container. e.g https://github.com/bbernhard/signal-cli-rest-api

(I am the author of REST API wrapper)

But I agree with you on that...Java isn't my preferred language either.

Fascinating. I know how to write an app that requires java 8 (just use lambdas) or 11 (just use newish TLS), but wow does one even write an app that needs 32-bit or 64-bit java? Or that works with Sun java but not with others?

JNI libraries.

Good point.

Some apps rely on optional JRE features or even private APIs.

Newer Java versions have started blocking private API usage. You can override the block but hopefully, it helps developers become aware of what they’re doing.

  apt install openjdk-11-jdk

You might want to have a look at presage - an implementation in rust: https://github.com/whisperfish/presage

It asks me to get a captcha on https://signalcaptchas.org/registration/generate.html, but the site does not seem to work.

"After filling the captcha, the site doesn't show the token but redirects to a signalcaptcha:// url that contains the token. [...] To see the URL you can open the browser developer tools (F12) before completing the captcha." https://github.com/AsamK/signal-cli/wiki/Registration-with-c...

Using Tor Browser I can see the signalcaptcha:// address in the window title of a detached Developer Tools window.

still missing some kind of ncurses UI for Signal now

I look forward to reviewing this. Neat idea.

Reply on news.ycombinator.com