What does HackerNews think of signal-cli?

If you want one for just personal use; this works well: https://github.com/AsamK/signal-cli

Just sign up with a Twilio number (using voice call) and you can make your own bot.

Started with just the email integration, and added other integration types over time, one by one. A few were contributed as GitHub PRs.

The Signal one took by far the most effort to get going. But, for ideological reasons, I really wanted to have it :-) Unlike most other services, Signal doesn't have public HTTP API for sending messages. Instead you have to run your own local Signal client and send messages through it. Healthchecks is using signal-cli: https://github.com/AsamK/signal-cli

I don't know about the moderation tools for large channels, but bots should be possible: https://github.com/AsamK/signal-cli

A good free way to achieve this is to use Signal. This project https://github.com/AsamK/signal-cli enables you to send Signal messages from the command line, including from Raspberry Pis. It obviously needs an internet connection to work, but has the added bonus of being more secure than SMS.

Possibly of interest: https://github.com/AsamK/signal-cli

There is a CLI client. Notifications/subscriptions may not be available. I think someone mentioned later in the thread that signald is a fork of signal-cli.

https://github.com/AsamK/signal-cli

well "signal-cli" is already in use by https://github.com/AsamK/signal-cli (which signald is a fork of)

> It's practically a principle of the Signal project to discourage third-party clients

It depends on what you call "client". At the protocol level sure, you're supposed to behave just like any official client. But to do that you just have to use their client library[0] and implement whatever you want on top of this, like signal-cli[1] has been doing successfully for quite some time now.

Some forks exist here and there (from memory, there's one with WhatsApp import, another with UI features), there's just no interest for a completely new client. There's only so much space for innovation for what is mostly a messaging app.

To be fair, the absence of an API (which Telegram has) also limits possibilities.

[0]: https://github.com/signalapp/libsignal-client [1]: https://github.com/AsamK/signal-cli

Signal is still an improvement over other non-federated messengers in that it's open-source, so you actually can try to improve the situation, although it's notoriously difficult. As an example of more platform support: https://github.com/signalapp/ringrtc/pull/12

signal-cli is an example of a 3rd party client which is tolerated for now: https://github.com/AsamK/signal-cli

The main problem right now is that they don't have enough developers to take care of everything, but it's not specific to centralized services (no developer == no code). If you care about it, you can develop your own client using their library (à la signal-cli).

Regarding your last paragraph: I could probably list 20 features I'd like to see in Signal. That doesn't mean I want somebody implementing them with no guarantee about how securely they are implemented. One of the main goals of Signal is to provide guarantees against dragnet surveillance, and that constraint takes precedence.

Yes, once this is more mature, it should make it easier to write Signal bots.

You can already do quite a lot with this awesome project: https://github.com/AsamK/signal-cli. It doesn't support everything though.

Do you know Signal-cli? I'm using it for all my Signal bots. https://github.com/AsamK/signal-cli

Maybe with signal-cli? (Java)

https://github.com/AsamK/signal-cli

> Keeping all those different bridges running over time is difficult.

The issue is that most of the services Matrix tries to bridge to are basically hostile entities (except IRC and Slack). I'm honestly shocked how well Matrix bridging works when you take that into consideration -- and unsurprisingly the Slack and IRC bridges are the nicest ones to use. But I will admit that I think Matrix's marketing around bridging as being core to their chat model is a bit of a stretch -- while all of the bridges do work, most are a bit dodgy (and some require you to self-host).

For instance, the Signal bridge is actually a hacked-up version of the Signal Chrome App with a bunch of hooks added so that they can simulate you doing things through the web app. There is a project that uses libsignal-service-java directly to create a more usable CLI and DBus interface[1], but unfortunately they haven't switched to using that (and if it became widely used, Moxie would probably decide to block it). Whatsapp is probably similarly hacked-together.

> It doesn't really do 1:1 chats so every time someone chats with you you get a 'room invite' from the bridge, which you have to accept, and all those old rooms stay forever cluttering up the system.

Maybe this is bridge-specific, but I have several long-lived IRC 1:1 chats that are all in one room. There's nothing stopping a bridge from doing this correctly (as far as I know). As for old rooms cluttering up the system, I believe that (non-joinable) rooms with no members get garbage collected but I might be mistaken.

[1]: https://github.com/AsamK/signal-cli

This uses signal-cli[0] (communication happens over D-Bus) and signal-cli in turn uses a patched version of libsignal-service-java[1]. The latter might be used in some of the clients provided by Signal (not sure) but the signal-cli + libsignal-service-java combo talks to Signal servers instead of any apps running locally.

Nothing is stopping you from building a web client for yourself.

[0]: https://github.com/AsamK/signal-cli [1]: https://github.com/signalapp/libsignal-service-java

> Can I use Signal from desktop only?

Yes, the desktop client functions independently from the phone client once linked (so not like whatsapp that proxies everything through your phone).

> Can I create an account from desktop?

Technically yes, but you either need to compile the desktop client yourself[0] and miss some features or use something like signal-cli[1] to act as the main client. So it's not supported (yet?).

> Is my account independent of any specific device?

The first client that registers acts as the main client, so no. But it might get easier to restore access on a different device without using backups with the secure value recovery[2] stuff they are working on.

> Can I use Signal on multiple computers at the same time with correct credentials?

It's possible to link and use several desktop clients at the same time.

[0] https://github.com/signalapp/Signal-Desktop/blob/development...

[1] https://github.com/AsamK/signal-cli

[2] https://signal.org/blog/secure-value-recovery/

>I need a chat application where I can have a client that I can use in my terminal, and Signal doesn't do that

Have you looked at signald or Signal-CLI?

https://gitlab.com/thefinn93/signald https://github.com/AsamK/signal-cli

I've been switching people to Matrix recently, mainly because they have a solution for losing your chat history (you don't, at least not with the new key backup system) and there's a lot of other features like bridging and federation. Matrix is far from perfect at the moment but I feel that it will end up being a much more complete solution than Signal (the new seven-word key verification system is really cool and much better than how verification works for Signal).

> Not both. Why? I don’t know. But Signal insists that it is more secure.

It's because the provisioning support is only implemented in the JavaScript "SDK" (in scare-quotes because we all know Moxie is very hostile to users using apps other than the one they publish).

Not only that, there were PRs that implemented the core functionality required and Moxie effectively said that the author was too inexperienced for the patch to even be worth reviewing[1]. There are third-party signal clients[2] which use that patch to allow for you to create "virtual devices" in your shell and thus (in theory) script signal chats or create Matrix bridges (I hope to do the latter at some point).

[1]: https://github.com/signalapp/libsignal-service-java/pull/21 [2]: https://github.com/AsamK/signal-cli

Moxie has been very anti-federation when it comes to Signal for a few years[0] (while I disagree with his reasons, he is right that having a centralised system does make it easier to make protocol changes without splintering your user-base).

There is a Signal bridge[1], but it's incredibly hacky (it does some ungodly things with JavaScript to re-use the Signal Chrome App) and requires you to register Signal for a device and then use the linked device configuration to get messages. Personally that's far from ideal, and I think a better solution would be to actually set up a full-on fake device with signal-cli[2] (an unofficial wrapper around the Signal Java library) and then forward things.

Unfortunately, Signal bridges would necessarily have to man-in-the-middle your messages (breaking a lot of the benefits of the Signal crypto). You could forward the messages to an encrypted chat, but you still have a fairly big issue -- especially for shared homeservers. So you'd probably need to run your own homeserver and then you get into a lot more fun.

[0]: https://github.com/LibreSignal/LibreSignal/issues/37 [1]: https://github.com/matrix-hacks/matrix-puppet-signal [2]: https://github.com/AsamK/signal-cli

There signal-cli [1] which works pretty nicely. Uses SMS for initial signup.

[1] https://github.com/AsamK/signal-cli

There's even a cli client that someone has written: https://github.com/AsamK/signal-cli

Motion + signal-cli[0] has been working well for me.

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