# Signal-Desktop / deltachat-desktop App



## MasterOne (Mar 14, 2021)

I have just seen that neither the signalapp / Signal-Desktop nor the deltachat-desktop app has been ported to FreeBSD yet.

Has anyone already taken a look if it's possible or to run the (Debian-based) Linux binary? Or to run the Windows app with Wine?

P.S. I'm not using FreeBSD (waiting for 13.0 RELEASE to go onto my new laptop) or Signal yet, nor am I a developer, so this is just out of interest.


----------



## Alexander88207 (Mar 14, 2021)

> I have just seen that the signalapp / Signal-Desktop app hasn't been ported to FreeBSD yet.



Signal uses electron and the last electron ports are all out because python 2 as dependency is EOL.



> Or to run the Signal for Windows app with Wine?



In wine electron programs do not run or are only half usable. I tried it once for fun and it crashed right away with a cryptic error.


----------



## twllnbrck (Mar 14, 2021)

Maybe net-im/signal-cli is an alternative for you which doesnt mess up your system on the side.


----------



## MasterOne (Mar 14, 2021)

twllnbrck said:


> Maybe net-im/signal-cli is an alternative for you which doesnt mess up your system on the side.


Nice, I certainly will have a look at this, though...


> signal-cli is primarily intended to be used on servers to notify admins of important events.


----------



## acheron (Mar 14, 2021)

Alexander88207 said:


> Signal uses electron and the last electron ports are all out because python 2 as dependency is EOL.


That's wrong, électron / vscode were recently updated.


----------



## acheron (Mar 14, 2021)

MasterOne said:


> Has anyone already taken a look if it's possible or to run the (Debian-based) Linux binary? Or to run the Signal for Windows app with Wine?


I'm trying to build a native version. It doesn't work yet, I hope I'll be able to fix this 'last' error that is blocking me.


----------



## DannyBoy (Mar 14, 2021)

MasterOne said:


> Nice, I certainly will have a look at this, though...


There is also net-im/scli, a TUI which works with net-im/signal-cli.  BSD Now highlighted a blog post which walks through setting it up a few weeks ago.


----------



## zirias@ (Mar 14, 2021)

acheron said:


> I hope I'll be able to fix this 'last' error that is blocking me.


And then, there's THIS kind of situation: https://www.monkeyuser.com/2018/root-cause/

Well, good luck  (and writing software with electron should really be a criminal offense...)


----------



## matt_k (Mar 14, 2021)

I am using signal-cli with siggo (written in go) client, works fantastically. Some weeks back, I was using the scli frontend, but after each and every update it had some problem, so I switched to siggo. I recommend that for OP.


----------



## MasterOne (Mar 15, 2021)

matt_k said:


> I am using signal-cli with siggo (written in go) client, works fantastically. Some weeks back, I was using the scli frontend, but after each and every update it had some problem, so I switched to siggo. I recommend that for OP.


Nice, but unfortunately there is no port for siggo either. I'd prefer software that's easy to install and keep up-to-date.



acheron said:


> I'm trying to build a native version. It doesn't work yet, I hope I'll be able to fix this 'last' error that is blocking me.


Awesome! Do you have a web page or repo for that to be able to follow your progress?


----------



## a6h (Mar 15, 2021)

Signal-cli with scli on FreeBSD | Freedom Be With All
					






					antranigv.am


----------



## matt_k (Mar 15, 2021)

MasterOne said:


> Nice, but unfortunately there is no port for siggo either. I'd prefer software that's easy to install and keep up-to-date.
> 
> 
> Awesome! Do you have a web page or repo for that to be able to follow your progress?


yeah, there isn't. But for me, siggo is still preferable to scli. You need to rm -rf ~/.local/cache/scli (IIRC) after each update and you'll lose all chat history.


----------



## MasterOne (Mar 21, 2021)

Found another interesting piece of software, that makes use of the email infrastructure, but it's Electron as well and not available as a FreeBSD port (yet) either:

deltachat-desktop - Desktop Application for delta.chat

If Electron / vscode were recently updated, it would be great to see more of such desktop-specific software come to FreeBSD.


----------



## Mjölnir (Mar 21, 2021)

Should I ever manage to get that magic _commit bit_, I hereby swore I'll smuggle some code into the yea free BeaSD to circumvent all hurdles & boycott all that crap to be void! Discord, Signal, Electron, VSCode -- are you serious?!


----------



## MasterOne (Mar 21, 2021)

Mjölnir said:


> Should I ever manage to get that magic _commit bit_, I hereby swore I'll smuggle some code into the yea free BeaSD to circumvent all hurdles & boycott all that crap to be void! Discord, Signal -- are you serious?!


I'm sorry, but I don't have the slightest clue what that's supposed to mean.

I'm looking for a secure open source communication app/service that respects privacy as a replacent for WhatsApp, which unfortunately most people that I know are using nowadays.

Signal seems to be a viable option, in contrast to Discord or Telegram, though something based on XMPP should be preferred. Not sure about the Signal versus XMPP debate though, except that Signal is more bandwidth-friendly?

If you have any more thoughts on that, please have a look at the linked other thread, which seems to be more suitable than this one.


----------



## Mjölnir (Mar 21, 2021)

Yes.  You can easily verify that I'm the OP of that thread... There is _TOX & Matrix_, and if you manage to set up XMPP/Jabber with OMEMO (e.g. net-im/gajim), you're good to go.


----------



## MasterOne (Mar 21, 2021)

Damned, is there really no Gajim equivalent for KDE Plasma / QT5?

Running an own net-im/ejabberd instance would be cool, but that's just something to keep in mind for when that opportunity will present itself in the future. For now, it should be a quick and easy solution.

IDK, but for some reasons Signal is not that tempting anymore, especially since my wife just told me that it's completely out of question that she will be able to forego WhatsApp with the usebase she has to deal with, so the alternative that I'm looking for will only be used for connecting the family in a secure and privacy aware way.

Something XMPP might be the way, but I'll also have another look at Nextcloud Talk (since I have a Nextcloud instance running on a shared webhost, though the last time I tried, it didn't work well at all).


----------



## sidetone (Mar 21, 2021)

Mjölnir said:


> You can easily verify that I'm the OP of that thread...


Which thread?

The only obvious problem I see with Signal, is if one doesn't feel comfortable with using their phone number with the service. That's an understandable concern. By itself, it's more private than simply telephone calls or SMS. Signal does need to be configured to be made more secure.

Another problem is that there isn't a GUI on FreeBSD for Signal.


Signal is hands-down better than Telegram, which claims it's secure by default, when encryption has to be enabled manually, leading people to wrongly believe their communications are already secured. Whatsapp is a joke, so using a speakerphone is more private than that.


Continuing this thread is good for discussing Signal's good points, if there are more than it's better than other specific services. Signal has endorsements, but that doesn't necessarily mean it is absent of major flaws.


----------



## MasterOne (Mar 21, 2021)

The more I look into Delta Chat the more I like that idea, but as said (I have updated the thread title and original post), it's the same problem being an Electron app.

So not sure if there will be any way to make it run on FreeBSD or if there will ever be a port (unless someone with the necessary knowledge, time and interest will look into this).


----------



## MasterOne (Mar 21, 2021)

For cross-reference, I have started a feature proposal thread about this at the Delta.Chat Forums as well:

FreeBSD Port of the deltachat-desktop App​


----------



## sidetone (Mar 21, 2021)

> *Delta Chat doesn’t have their own servers* but uses the most massive and diverse open messaging system ever: the existing e-mail server network.


Email uses an indirect federated network, meaning the communication passes through a number of servers. This design isn't secure on its own as any server point on that connection can be corrupt, as in tampered or spoofed. That's unless the whole communication is encrypted and/or tunneled from multiple prying servers/connection points.

XMPP uses a direct federated network. There's only two or 1 servers on this kind of network (there can be only 2 more connection points if a BOSH or Websockets proxy is used). The servers have to be known as trusted, and the clients can't spoof to their host server, unless the device (such as a user's phone) is physically stolen or a password is stolen. Provided the two servers are trustworthy, these two servers make a direct connection, preventing sources of spoofing or tampering between them.

A direct federated network makes direct connections: from client, to server, to server, to client. If Bosh or Webproxy is used, it goes: a connection manager is added between a server and client on one or both ends. Sometimes the servers are the same, and the connection manager is usually on the same physical location as the server. There's some data that only the servers can write to, or overwrite for sending, so that the client can't spoof it to the other end.

An indirect federated network has something like that, plus a lot of other pass through connections, which is what email is. Delta chat may be good as an alternate way of messaging, but using the same system means it uses an indirect federated network, unless there's a difference in implementation.


----------



## zirias@ (Mar 21, 2021)

I wouldn't be concerned about security as long as a sane end-to-end encryption is used, which is at least claimed on the project's website.

Still I think the choice to build instant messaging on top of email is pretty weird. Email was never designed to be "instant", it's designed to handle temporary errors gracefully (by queueing on each MTA and retrying failed attempts to pass the mail to the next one, with increasing waiting times, up to several days isn't uncommon) and also allow redundancy and alternative paths. And then, it's still "best effort", there's never a guarantee an email sent out would ever arrive. Taking all this into account, that's really NOT what you need for instant massaging.


----------



## MasterOne (Mar 21, 2021)

sidetone Zirias

Delta Chat is not a newcomer, implements the Autocrypt Level 1 standard and can thus E2E-encrypt messages with other Autocrypt-capable apps, and also supports a strong form of end-to-end encryption that is even safe against active attacks (see “verified groups” and more info in the FAQ).

The whole system is a proven concept and it's obviously working very well.

The main benefits I see over XMPP is that you don't need to run your own XMPP instance or have to sign up at and trust a 3rd party server, and that you can reach anyone with an email address, even if the other side is not using Delta Chat, in which case the other party simply can participate using his/her usual email client (only then communication is unencrypted, unless that email client supports Autocrypt or manual OpenPGP setup).

It really is a fascinating concept and totally reminds on how WhatsApp became that successful (by using existing mobile phone numbers instead of regular signups). Just think about it, you can easily reach anyone with an email address without the other party having to sign up or install any software beforehand, so no convincing to move to a new service involved, with the other side hopefully getting interested and starting to use that system after the fact.


----------



## zirias@ (Mar 21, 2021)

You just ignore the fact that email is NOT a viable transport for instant messaging, see above. Reuse isn't a bad concept in general, but I think this particular idea is, uhm, pretty strange 

As I said, I tend to believe the end-to-end encryption is ok. Of course, only having direct s2s connections (like XMPP) still has the little benefit that fewer machines can see conversation metadata (who is communicating with whom). I don't consider that particularly important (direct connections are just a necessity for synchronous acknowledged, aka, instant communication), but I'm very sceptical about the solution for the reasons explained above.


----------



## MasterOne (Mar 21, 2021)

FAQ: If Delta Chat uses E-Mail, is it really an Instant Messenger?

Sure, there are differences to something line XMPP, and it may be a strange idea, but from what I've read so far it really seems to be working very well.

I'm just in the research phase right now, so I haven't tested it, but whatever the outcome, having a port of deltachat-desktop for FreeBSD surely would not be a bad thing.

There are some native approaches without Electron in the works. What I have found so far (though the latter two look abandoned):

KDeltaChat - a Delta Chat client using Kirigami framework
deltar - delta desktop application in rust
deltachat-cursed - a ncurses Delta Chat client developed in Python with the urwid library

If work for Electron on FreeBSD has resumed and building Electron apps is the issue, not running them, any idea what's needed to try running a prebuilt Electron binary on FreeBSD?


----------



## zirias@ (Mar 21, 2021)

MasterOne said:


> FAQ: If Delta Chat uses E-Mail, is it really an Instant Messenger?


Well, what to expect from a FAQ answer of the project itself? IMHO, that's all moot, as email just isn't designed that way. With email, your message can get queued anywhere on the way indefinitely and you will only eventually get a bounce in case of a permanent error. For instant messaging, you want instant acknowledge of the receiver. I still think this is a pretty bad idea.


MasterOne said:


> If work for Electron on FreeBSD has resumed and building Electron apps is the issue, not running them, any idea what's needed to try running a prebuilt Electron binary on FreeBSD?


Basically, a prebuilt binary FOR FreeBSD. Electron apps are NOT OS agnostic.
And the trouble with building Electron apps is what you can see looking into a port doing that. Everything using npm and/or yarn is a major PITA for creating a reliable, reproducible and packageable build.


----------



## sidetone (Mar 21, 2021)

MasterOne said:


> The main benefits I see over XMPP is that you don't need to run your own XMPP instance or have to sign up at and trust a 3rd party server


XMPP offers OMEMO and PGP end to end encryption.


MasterOne said:


> you can reach anyone with an email address, even if the other side is not using Delta Chat, in which case the other party simply can participate using his/her usual email client (only then communication is unencrypted, unless that email client supports Autocrypt or manual OpenPGP setup).





MasterOne said:


> It really is a fascinating concept and totally reminds on how WhatsApp became that successful (by using existing mobile phone numbers instead of regular signups). Just think about it, you can easily reach anyone with an email address without the other party having to sign up or install any software beforehand, so no convincing to move to a new service involved, with the other side hopefully getting interested and starting to use that system after the fact.


Sounds convenient.

It sounds like a good addition for messaging on an existing system of email.

Still, email can be sent by a spoofed address on a secure and encrypted connection, because there's so many server/connection places where the spoof can originate from. On XMPP, only one server where the client signed up can send and change certain data, as there's no more than 2 servers that use SSL certificates to identify themselves to each other, and they set certain data that the client can't set. The only way a spoof is possible here is, is if one client address has a Unicode letter that looks like a regular character. With Omemo or PGP on XMPP, the message is encrypted, but I'm not sure whether header data is too.

We all use email, and we're mostly good with that. I wonder what could be the next thing like email with a direct federation model.

I wanted to point out the differences of direct federated and indirect federated systems.


MasterOne said:


> Delta Chat is not a newcomer


SIP/SIMPLE and XMPP are the only ones that are open-source standards by IETF (a standard has a different distinction than a client). SIP/XIMPLE and XMPP can be standardized for use among different offerings of organizations or providers. Signal has endorsements, and is supported by Open Technology Fund.

Either way, it's good to hear the strengths of Delta Chat and if it gets endorsements.


----------



## guidok (Mar 22, 2021)

vigole said:


> Signal-cli with scli on FreeBSD | Freedom Be With All
> 
> 
> 
> ...


If you follow that guide, do realize that you don't need to muck with the `DBUS_SESSION_BUS_ADDRESS` environment variable. Instead simply run `scli` with `dbus-run-session`, eg:

```
$ dbus-run-session scli --debug -s
```


----------



## acheron (Apr 3, 2021)

MasterOne said:


> Nice, but unfortunately there is no port for siggo either. I'd prefer software that's easy to install and keep up-to-date.
> 
> 
> Awesome! Do you have a web page or repo for that to be able to follow your progress?


I put my notes / build instructions here: https://github.com/MikaelUrankar/signal-desktop (it's pretty rough at this point and I still have no clue of how to fix the ENOTTY problem...)
Text messaging is working, I haven't tried video call.


----------



## MasterOne (Apr 7, 2021)

acheron said:


> I put my notes / build instructions here: https://github.com/MikaelUrankar/signal-desktop (it's pretty rough at this point and I still have no clue of how to fix the ENOTTY problem...)
> Text messaging is working, I haven't tried video call.


Any idea if this information can be applied to the deltachat-desktop app as well?

I have given up looking into Signal and just installed the Delta Chat Android apps on our phones. Having the desktop app available as well, would be really great.


----------



## MasterOne (Jun 7, 2021)

Inglyaffect said:


> Is the destop version available now?


No, just checked, not in ports (yet).


----------



## Maxfx (Feb 22, 2022)

Signal desktop is here https://github.com/MikaelUrankar/signal-desktop/tree/5.32.0/ports/net-im/signal-desktop only run makefile. Now  is not in porttree


----------



## grahamperrin@ (Feb 25, 2022)

signalapp / Signal-Desktop
					

I was just wondering if someone would be interested in porting signalapp / Signal-Desktop or if there is specific reason why it hasn't been ported yet (Linux only?).  P.S. I'm not using FreeBSD (waiting for 13.0 RELEASE to go onto my new laptop) or Signal yet, nor am I a developer, so this is...




					forums.freebsd.org


----------



## sidetone (May 9, 2022)

twllnbrck said:


> Maybe net-im/signal-cli is an alternative for you which doesnt mess up your system on the side.





MasterOne said:


> signal-cli is primarily intended to be used on servers to notify admins of important events.


That sounds right, that signal-cli is for servers and for a backend. It's not for casual use: the command line has to be used for each line.


DannyBoy said:


> There is also net-im/scli, a TUI which works with net-im/signal-cli.  BSD Now highlighted a blog post which walks through setting it up a few weeks ago.


scli is the way to go on the terminal for users. That's a good link.


matt_k said:


> You need to rm -rf ~/.local/cache/scli (IIRC) after each update and you'll lose all chat history.


Signal is built like that. It's intended to lose chat history from device to device. From what you described, it happened from update to update. It's good to know about and to work around. Having more user customization and ability to keep the chat history setting about this would be better. Can the history be saved in another file? I have doubts that its on the server, as it's end to end encrypted, and meant to be secure as in implied not being held on the server after the device receives it.



From finally trying Signal, only 1 device can use an account for a number at a time. It's a little inconvenient, but at least secure in that way.

The configuration for net-im/signal-cli is applicable to net-im/scli. The phone number goes in rc.conf.local. scli displays a QR code on the terminal, which has to be scanned by the Signal app on the phone. The contacts showed up on my terminal. I didn't go past that.


----------



## sidetone (May 9, 2022)

signal-cli(1). Signal-cli's package message, `pkg info -D signal-cli`:

```
signal-cli-0.9.0_1,1:
On install:
Quick start
===========

1. Generate a QR code to link this signal-cli to the other user device like a
   phone or tablet with a Signal app (this step requires qrencode(1), which is
   an additional utility provided by the graphics/libqrencode port):

       signal-cli link -n DEVICENAME | xargs -n 1 qrencode -t ANSI256

2. Scan the generated QR code with an app.

3. Send a test message to yourself:

       signal-cli -u NUMBER send -m "This is a test" NUMBER

See the signal-cli wiki for more details:
https://github.com/AsamK/signal-cli/wiki

Running a signal-cli daemon (using D-Bus user bus)
==================================================

The DBUS_SESSION_BUS_ADDRESS environment variable should be present for
signal-cli to function properly when run as a daemon (`signal-cli daemon`).

The easiest way is to run the graphical session with dbus-run-session(1), e.g.:

    dbus-run-session -- startx

signal_cli service (using D-Bus system bus)
===========================================

There is an rc(8) script available for signal-cli if it's desired to use
signal-cli in a daemon mode with the D-Bus system bus.

First, configure the service in rc.conf(5):

    sysrc signal_cli_enable="YES"
    sysrc signal_cli_phone_number="+48123456789"

Before starting the service, it is needed to either register a new Signal
account or to link this machine with an existing account. It is possible to
create a linking URL this way:

    service signal_cli runcli link -n DEVICENAME

See the signal-cli wiki for more details:
https://github.com/AsamK/signal-cli/wiki
```
Wiki referred to: https://github.com/AsamK/signal-cli/wiki


scli's Readme, located at /usr/local/share/doc/scli/:

```
# scli
`scli` is a simple terminal user interface for [Signal](https://signal.org). It uses [signal-cli](https://github.com/AsamK/signal-cli) and [urwid](http://urwid.org/).

## Features

- vim-like navigation (`j`, `k`, `g`, `G`, etc), command entry with `:`
- optional emacs-like `readline` bindings for input
- external `$EDITOR` support

### Limitations

- Not yet supported by [signal-cli](https://github.com/AsamK/signal-cli/issues):
    - Quoting a message ([#875](https://github.com/AsamK/signal-cli/issues/875))
    - Adding @-mentions in sent messages ([#875](https://github.com/AsamK/signal-cli/issues/875))
    - Voice calls ([#80](https://github.com/AsamK/signal-cli/issues/80))

- *Sending* read receipts for received messages.
- "View once" and "expiring" messages.
- See also: open [issues](https://github.com/isamert/scli/issues).

## Installation
### Automatic
The following methods are supported by community and may be outdated.

[![Packaging status](https://repology.org/badge/vertical-allrepos/scli-signal-cli.svg)](https://repology.org/project/scli-signal-cli/versions)

- [Debian / Ubuntu](https://gitlab.com/packaging/scli/)

### Manual

Clone the repo

```
git clone https://github.com/isamert/scli
```

or download a [release](https://github.com/isamert/scli/releases).

#### Dependencies

- [`signal-cli`](https://github.com/AsamK/signal-cli) `>=v0.6.8`.

    Download and unpack a [release](https://github.com/AsamK/signal-cli/releases), and place the `signal-cli` executable somewhere on the `$PATH`.

    Or compile from source: see [install](https://github.com/AsamK/signal-cli#Installation) section of `signal-cli` readme for instructions.

- [`urwid`](https://github.com/urwid/urwid)

    Availble on PyPI:

    ```
    pip install urwid
    ```

    and in some distributions' package managers, see repology [(1)](https://repology.org/project/urwid/versions), [(2)](https://repology.org/project/python:urwid/versions).

- [`urwid_readline`](https://github.com/rr-/urwid_readline/) (optional)

    For GNU readline-like keybinds on the input line (emacs-like only).

    ```
    pip install urwid-readline
    ```

    Also in a few [package managers](https://repology.org/project/python:urwid-readline/versions).

- [DBus](https://www.freedesktop.org/wiki/Software/dbus/)

    Pre-installed on most linux distributions and BSDs with desktop environments. On macOS, the `dbus` package is available from homebrew, see signal-cli's [wiki](https://github.com/AsamK/signal-cli/wiki/DBus-service#user-content-dbus-on-macos). See also, wiki's [troubleshooting](https://github.com/AsamK/signal-cli/wiki/DBus-service#user-content-troubleshooting) section.

- [Python](https://www.python.org/downloads/) `>=3.7`


### Registering or linking your device

Before running `scli`, `signal-cli` needs to be registered with the signal servers. You can either register a [new device](https://github.com/AsamK/signal-cli/wiki/Quickstart#user-content-set-up-an-account), or [link](https://github.com/AsamK/signal-cli/wiki/Linking-other-devices-(Provisioning)) `signal-cli` with an already registered device (e.g. your phone).

Linking can be done interactively with `scli link`, see the [next section](#linking-with-scli-link).

For more information, see: `signal-cli` [usage](https://github.com/AsamK/signal-cli#Usage), [man page](https://github.com/AsamK/signal-cli/blob/master/man/signal-cli.1.adoc), and [wiki](https://github.com/AsamK/signal-cli/wiki).

#### Linking with `scli link`

Linking with an existing account can be done interactively with

```
scli link [--name DEVICE_NAME]
```

and following instructions on the screen. The `DEVICE_NAME` is optional, `scli` is used by default.

This requires [pyqrcode](https://github.com/mnooner256/pyqrcode) package (available on [PyPI](https://pypi.org/project/PyQRCode/) and other [repositories](https://repology.org/project/python:pyqrcode/versions))

#### Verifying setup

After registering or linking, verify that the following commands work:

```
signal-cli -u USERNAME receive
```

and

```
signal-cli -u USERNAME daemon
```

where `USERNAME` is the phone number you have used (starting with the "+" sign and including your country calling code). Kill the latter process after verifying that it starts successfully and does not throw any errors.

Now you can start

```
scli
```

if you have put it on your system's `$PATH`, or specify the full `/path/to/executable/scli`.


## Usage
A simple two-paned interface is provided. Left pane contains the contact list and right pane contains current conversation. You can switch focus between panes with `Tab` (or `Shift + Tab`). Hitting tab for the first time focuses the conversation, hitting it again focuses to input line. So the focus order is `Contacts -> Conversation -> Input`. You can use `Shift + Tab` for cycling backwards.

### Keys
- `j`/`k` move the cursor down/up in a conversation and the contacts list.
- `g` focuses first contact/message.
- `G` focuses last contact/message.
- `enter` on a contact opens its conversation and focuses the input line.
- `l` on a contact opens its conversation without focusing input line.
- `enter` on a message opens attachment or URL if there is one.
- `o` on a message opens URL or attachment if there is one.
- `y` on a message puts it into system clipboard. (needs `xclip`).
- `e` or `R` on a message opens an emoji picker and sends it as a reaction. Sending an 'empty' reaction removes the previously set reaction.
- `d` deletes the message locally (from the current device's history).
- `D` remote-deletes the message (for everyone in the conversation).
- `i` shows a message info popup with the message's details.
- `U` in contacts list increments contact's unread count (can be used to mark conversation as unread).
- `Alt+Enter` inserts a newline in message composing input field.
- `Alt+J` / `Alt+K` (and `Alt+↓` / `Alt+↑`) open next / previous conversation.
- If [`urwid_readline`](https://github.com/rr-/urwid_readline/) is installed, all of its keybindings can be used in the message compose input field.

### Commands
Commands can be entered by typing `:` followed by one of the commands below.

- `:edit` or `:e` lets you edit your message in your `$EDITOR`.
- `:attach FILE_PATH` or `:a FILE_PATH` attaches given file to message.
- `:attachClip` or `:c` attaches clipboard content to message. This command tries to detect clipboard content. If clipboard contains something with the mime-type `image/png` or `image/jpg`, it simply attaches the image to message. If clipboard contains `text/uri-list` it attaches all the files in that URI list to the message. This command needs `xclip` installed.
- `:openUrl` or `:u` opens the last URL in conversation, if there is one.
- `:openAttach` or `:o` opens the last attachment in conversation, if there is one.
- `:toggleNotifications` or `:n` toggles desktop notifications.
- `:toggleContactsSort` or `:s` toggles between sorting contacts alphabetically and by the most recent message.
- `:toggleAutohide` or `:h` hides the contacts pane when it's not in focus.
- `:addContact NUMBER [NAME]` adds a new contact to the contact list. Added contacts' names are local (not synced with signal servers).
    _Note_: This command works only with signal-cli accounts registered as "master" (_not_ those linked with the phone app).
- `:renameContact [ID] NEW_NAME` renames contact `ID` to `NEW_NAME`. `ID` can be either contact's phone number or contact's name. If `ID` is skipped, the contact from the currently opened conversation is used. If `ID` is a name that contains spaces, they need to be escaped or the whole name put in quotes. `NEW_NAME` can contain spaces without quotes or escaping. 'Contact' can be a group as well as an individual. Individual contacts' renames are local (not synced with the signal servers).
    See _Note_ for `:addContact` command above.
- `:reload` re-reads the `signal-cli`s data file. (Updates contacts list etc.)
- `:quit` or `:q` quits the program.

Examples:
```
:attach ~/cute_dog.png check out this cute dog!
:attachclip here is another picture.
```
**Note**: Commands are case insensitive, `:quit` and `:qUiT` do the same thing.

### Searching
Filtering messages in a conversation is done by typing `/` followed by the match text. Hitting `enter` (or `l`) on a message shows it in the full conversation. Hitting `Esc` clears the search. Searching through the contacts is done similarly.

### Configuration
Configuration options can be passed to scli as command-line arguments or added to the configuration file in `~/.config/sclirc`. Run `scli --help` to show all available options.

In the configuration file the empty lines and lines starting with `#` are ignored. Other lines are `key = value` pairs. Optional arguments (flags) like `--debug` can be enabled in config file with any of: `true`, `t`, `yes`, `y` (with any capitalization, case insensitive).

#### Example
```sh
scli -w 80 --enable-notifications
```
Configuration file equivalent of this command is:
```ini
## Long option forms are used in config file. (w = 80 is not valid.)
wrap-at = 80
enable-notifications = true
```

#### History

Conversations history can be enabled with `--save-history` or `-s` flag. The file will be saved in plain text (to `~/.local/share/scli/history` by default). See the [Security](#data-storage) section regarding an encrypted storage.

#### Colors

Messages' text can be colorized using the `--color` option:

- `--color` (no additional value)
   Use contacts' colors from the master signal device.

- `--color=high`
     Same as above, but use 256 colors instead of the terminal's standard 8. Colors look closer to those on official clients, but not necessarily legible on all terminals' color schemes.

- `--color='{"<signal_color>": "<urwid_color>", ..., "<phone_number>": "<urwid_color>", ...}'`
   Override colors for particular contacts or redefine signal-assigned colors; use signal-assigned colors for the rest, as above. If any of the `<urwid_color>`s is specified as a 256-color, the "high-color mode" will be turned on (like `--color=high`).

- `--color='["<urwid_color_sent>", "<urwid_color_recv>"]'`
   Use one color for sent messages and another for received messages (from any contact).

The list of available `<signal_color>` names is in the [source code](https://github.com/isamert/scli/blob/9a5a49d/scli#L2925-L2939) (first column).
An `<urwid_color>` is one of urwid's [16 standard foreground colors](https://urwid.readthedocs.io/en/latest/manual/displayattributes.html#standard-foreground-colors) (`dark green`, `yellow`, `default`, etc), or [256 foreground colors](https://urwid.readthedocs.io/en/latest/manual/displayattributes.html#color-foreground-and-background-colors) (`#f8d`, `h123`, etc).
To see the available colors rendered in your terminal, run [palette_test.py](https://github.com/urwid/urwid/blob/master/examples/palette_test.py) from urwid's examples.
The single quotes in `--color='...'` above are just shell-escaping, and not needed in `sclirc`.

## Security
This is an independent project not audited or endorsed by the [Signal foundation](https://signal.org/). That is also true of [signal-cli](https://github.com/AsamK/signal-cli) that scli uses as a backend.

### Data storage
Scli saves its history (when enabled, with `--save-history`) in plain text. Likewise, signal-cli stores its data (received attachments, contacts info, encryption keys) unencrypted. To secure this data at rest, it is recommended to use full-disk encryption or dedicated tools like [fscrypt](https://github.com/google/fscrypt).

To protect the data from potentially malicious programs running in user-space, one can run scli and signal-cli under a separate user.

For more detailed discussions, see: [[1]](https://github.com/AsamK/signal-cli/discussions/884), [[2]](https://github.com/isamert/scli/pull/169).

## Similar projects
See [TUI clients](https://github.com/AsamK/signal-cli/wiki#user-content-terminal--tui-clients) on signal-cli wiki.

## Screenshots
![scli](screenshots/1.png?raw=true)
![scli](screenshots/2.png?raw=true)
![scli](screenshots/3.png?raw=true)
```
(This is for convenience, and for those who don't have immediate access to FreeBSD)


----------



## acheron (Jun 23, 2022)

I've committed net-im/signal-desktop


----------



## Zagzigger (Jan 4, 2023)

Apologies for resurrecting this thread, and my newbiness, but I've just changed machines and installed a new 13.1 version and found that signal-desktop is not available as a package; presumably because there is no maintainer. Signal worked really well on my old 13.1, so how can I download it for my new desktop. Thanks (and yes, I know I should know this stuff).


----------



## BobSlacker (Jan 4, 2023)

Zagzigger said:


> Apologies for resurrecting this thread, and my newbiness, but I've just changed machines and installed a new 13.1 version and found that signal-desktop is not available as a package; presumably because there is no maintainer. Signal worked really well on my old 13.1, so how can I download it for my new desktop. Thanks (and yes, I know I should know this stuff).


According to signal-desktop the version on quarterly doesn't build. Only the version on latest it is building.


----------



## SirDice (Jan 4, 2023)

Fallout list - FreeBSD pkg-fallout
					






					portsfallout.com
				




A new quarterly branch should appear soon (2023 Q1). I see the branch has already been made, now all the packages will have to be build and distributed, which is going to take a couple of days.


----------



## acheron (Jan 4, 2023)

Zagzigger said:


> Apologies for resurrecting this thread, and my newbiness, but I've just changed machines and installed a new 13.1 version and found that signal-desktop is not available as a package; presumably because there is no maintainer. Signal worked really well on my old 13.1, so how can I download it for my new desktop. Thanks (and yes, I know I should know this stuff).


I still maintain it, and will do it until I stop using signal. I don't have much spare time and I tend to neglect quarterly.


----------



## Zagzigger (Jan 4, 2023)

acheron said:


> I still maintain it, and will do it until I stop using signal. I don't have much spare time and I tend to neglect quarterly.


It is very good - and people like me tend to rely on it. Thanks, I wish I could do more to contribute.
9th January. Just downloaded it and it works - thanks again.


----------

