Replies: 1 comment
-
Hi, if I understood you correctly, then you want to expose This project here creates a REST API interface around signal-cli's internal API, so signal-cli's internal API(s) aren't directly exposed to the user. While this obviously has some disadvantages (e.g we do not have every functionality of signal-cli exposed yet via APIs), this also has one big advantage: API stability and versioned APIs. So that's mainly the reason why this API wrapper exists :) |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
I have an application that uses the Dbus Mode of signal-cli. While I know you don't like Dbus much, I see that you have a pretty sophisticated Docker creation that with RPC now also supports a kind of "daemon" mode.
While I really struggle providing my users a dockerized version (also due to my limited Docker know how), I would think that adding a Dbus MODE to your project should not be so complicated.
With 0.9.0 signal-cli daemon can be started without -u parameter and all the registration is done via Dbus as well, so a container that just runs a signal-cli with "daemon --system" is what I'm looking for.
To make Dbus work however, I believe that
/var/run/dbus/system_bus_socket
would need to be exposed somehow (here my Docker know how definately is insufficent)
What do you think - could we add that (willing to help here) and prevent inventing the wheel again?
Beta Was this translation helpful? Give feedback.
All reactions