Switch to signal-cli's JSON-RPC interface?

[donnm]

Multiple accounts are now supported via signal-cli dbus daemon by not specifying the -u parameter with the daemonoption:

AsamK/signal-cli@ca86c42

In this case, the data directory is scanned for registered accounts and a new dbus endpoint is created for each one.

It would be nice if scli would support this, and perhaps best if scli checks to see whether a signal-cli dbus daemon has already started before trying to open it directly using Popen.

[exquo]

I've thought about incorporating this change into scli, but couldn't think of what problem that would solve.

Since scli is a single-user application, it has to know which account to use. If there is only one registered account in the signal-cli data folder, scli already automatically selects it (does not require the -u argument). If there is more then one account, I guess there's no way around selecting one manually.

Do you mean scli could be made into a multi-account application (i.e. send and receive messages for all registered signal-cli accounts)? Or just --help / README need to be more clear that -u argument is optional?

---

… best if scli checks to see whether a signal-cli dbus daemon has already started before trying to open it directly using Popen.

Scli reads signal-cli output from a signal-cli process' stdout. That's not the only way to get signal-cli's messages: we could alternatively listen to messages signal-cli sends through dbus. But that's how it's currently done, we start a new signal-cli subprocess and attach a pipe to its stdout.

I can see a use-case here: if you have multiple accounts and want to use one of them with scli while using others with other programs. Is that along the lines you were thinking?

[donnm]

I can see a use-case here: if you have multiple accounts and want to use one of them with scli while using others with other programs. Is that along the lines you were thinking?

Yes, exactly this scenario (I can see my first post was a bit vague). I don't mean for scli to be multi-account. Instead, support for communication with signal-cli over dbus would be enough.

[exquo]

Gotcha. There might be some advantages in listening to dbus output rather then using stdout, but a big disadvantage is that signal-cli's dbus interface's features often lag behind the stdout interface.

If there are other considerations (either pro or against), please leave a comment.

For using scli with one account among several run by signal-cli daemon, you can specify the username with -u in both scli and signal-cli. This might become cumbersome if there are more then a few accounts, but that's probably a pretty rare usage.

[oo-san]

Gotcha. There might be some advantages in listening to dbus output rather then using stdout, but a big disadvantage is that signal-cli's dbus interface's features often lag behind the stdout interface.

If there are other considerations (either pro or against), please leave a comment.

I don't know about the past, but a least lately, signal-cli's dbus interface has been receiving first-class support and attention, if not having more features now implemented than the plain CLI interface. Some additional benefits for listening on the dbus interface:

• Allows the launch of signal-cli to be managed outside of scli (if you start it as a service, for instance)
• Use signal-cli's built-in support for multiple signal numbers/accounts through one running daemon
• If signal-cli is launched as a sandboxed user select users running scli could be able to interface with with the dbus interface according to some access list. I understand your earlier remark about scli intended as a single-user application, but using users and namespaces is a way to sandbox application environments. For example, preventing applications run under the current user from reading the data folder that signal-cli or scli use.
• One could abstract away much of the notification logic and run that as a separate entity that listens on the dbus interface directly

What are your thoughts about these?

[exquo]

Signal-cli has a newer JSON-RPC API with the most comprehensive functionality. The dbus interface "will likely always lag behind". JSON-RPC would be the best choice for scli, but switching to it now will require quite a bit of a code rewrite. We might do it at some point in the future, though.