1) I would expect "signald" to be the server that clients connect to (as in, the thing provided by signal) and "signalcd" to be a client that is in the form of a daemon (akin to dhcpd vs. dhcpcd).
2) You can't use either of these names as Signal owns a trademark on their name (and even cares, as they should, particularly for a security product) and this looks like an official product in a way you can't disclaim away: come up with your own name for your daemon and then "support" signal or be "for" signal.
> Signal’s Rights. We own all copyrights, trademarks, domains, logos, trade dress, trade secrets, patents, and other intellectual property rights associated with our Services. You may not use our copyrights, trademarks, domains, logos, trade dress, patents, and other intellectual property rights unless you have our written permission. To report copyright, trademark, or other intellectual property infringement, please contact abuse@signal.org.
Also Signal has a history of shutting down third party clients, e.g. there was an effort making Signal completely FOSS and publishing it on F-Droid and Moxie shut them down for using the official servers, as well as the name: https://github.com/LibreSignal/LibreSignal/issues/37#issueco...
You're totally allowed to publish client software that has the URLs of the official servers in the code, including that forked from the official client. Believing otherwise is a common (and false) misconception that I wish people would stop repeating. (However, if you do fork the program, pick a new name! "Signal" is trademarked, don't use it in your name.)
The ToS for the signal service API applies to end users who connect to that API. The ToS of the API does not apply to software - the AGPL license applies to that, and the AGPL permits anyone to make forks (including ones that are configured to talk to the official servers).
EDIT: Disregard the following paragraph. See below.
There is a little bit of an issue, though, because contributions to Signal's upstream are not accepted unless the contributors sign the CLA, which allows Signal to relicense future versions more restrictively as they wish. They could relicense and then introduce intentional incompatibilities in the protocol if they really wanted to harm forks, but that would make them non-free, non-open-source software.
EDIT: Turns out I'm wrong in the above - the Signal CLA, to their immense credit, only permits relicensing under OSI-approved free software licenses. Fork away!
Moral of the story: don't listen to bluster, stick to what the license says (and the AGPL says you can fork), and never sign a CLA. You don't have to sign a CLA to contribute to the Linux kernel, and you shouldn't ever sign one to contribute to any other open source project.
I also wonder if it's even possible to enforce an "official clients only" restriction in the ToS for the service API. This would be a little bit like Google claiming that you aren't authorized to use Firefox to access google.com (i.e. insanity). Technologically if you tracked upstream closely enough, they probably wouldn't even be able to tell if a given 3p client user is running your fork or the official one.
(This whole comment is a paraphrase of a blog post[1] I published just a few hours ago that tries to dispel this whole "but you can't fork Signal and use the official servers" false meme.)
How or why would they ban you for publishing software?
If they ban end-user accounts that use your client software to connect to their API, that's obviously a bug in your software as it diverges from the behavior of the official client. This is why anyone making an alternative client should be doing so with a fork of upstream that is regularly updated. You'd need to keep it in sync pretty closely. Most official Signal clients autoupdate (a huge security vulnerability in and of itself[1], as SolarWinds demonstrated very nicely for everyone), but not all of them (you can't override the user's systemwide app autoupdate setting on iOS), so they have to maintain BC with out of date versions for at least a few weeks/months.
I was referring to banning of users who use third party clients and I do not think it would be particularly hard to do if they really wanted to. You can for example use request patterns or the fact that the unofficial clients do not autoupdate. I doubt that they would go that far, but it would be trivial if they really wanted to.
Banning the set of users that are so passionate about your service that they jumped through hoops to work around your dogshit software is probably not the best decision a product company can make.
Nothing GP said has to contradict either of these. I think you’re accusing them of accusing him of lying. Was Marlinspike paid for his services to mobilecoin, possibly even as CTO? Be more careful with your accusations. https://www.coindesk.com/signal-founder-may-have-been-more-t...
That thread is a bit ridiculous, the guy was already told that he can block updates.signal.org if he really wants to inspect the commits first, but he insists there no workaround.
Is the link you provided right? I don't see how it relates to this. I generally agree with your statements, but I wouldn't want to run a project like LibreSignal with the lead of the original project not wanting my project to exist, although I find moxy's behaviour in this case very unsetteling.
My rant about the licensing confusion is at the bottom of the post, below the part about how it silently ruins the files you attach. It should probably be a different blog post, but I don't feel the rant alone is worthy of its own webpage. I like dispelling misinformation, but I don't like drawing specific attention to misinformation, if that makes sense?
It would appear that encryption is optional in this tool. That's a 50 caliber footgun (on par with Telegram) if I ever saw one; I won't be using this software.
OMEMO is optional because not all of the 37283749 XMPP clients support it. But it is enabled by default if all involved parties are using Quicksy, Conversations or another reasonably new client.
Even with a granted trademark, it would be up to the company to enforce it. Simply stating “you can’t use our name” is much different from perusing open source projects in court or sending them cease and desist letters.
"Twitteriffic" and "Tweetbot" exist as accepted third-party Twitter-related apps, despite the fact that Twitter owns the "Twitter" and "Tweet" trademarks.
Signald sounds much more official than twitteriffic (trademarks are all about confuseability). Besides, how twitter does or does not enforce its trademarks has no bearing on what signal does.
That really doesn't affect the legality (or, frankly, morality) here for many reasons, but the most obvious is that the word "unofficial" is certainly not going to be used in all of the discussions about the software as it simply isn't actually in the name, which is clearly only "signald".
First off, morals are subjective, but, also, yes: if you're going to have a different project, it should have a different name. Otherwise you run the very real risk of deceiving people into thinking that A is affiliated with B.
I've been using this as the data source for a Matrix bridge for the better part of a year now. I'm thrilled with it so far! The only worry I have is Signals hostility towards analogous projects, but for the meantime it works for me as this is helping me wean off Signal. Maybe one day regular people will use Matrix...
I want to like matrix but the UI is just beyond terrible when you enable encryption. It also just ends up in lots of strange situations where if you log in from a new place the verification system completely bugs out. I can barely make sense of what it wants most of the time let alone getting non tech friends to use it. I want to like matrix but the non default encryption and terrible UI on element is a dealbreaker.
I agree that the whole identity verification stuff is confusing in element. I think it would be less so if they just generate and present the backup security key at account creation, telling users to use this when they want to login on a different device and drop the whole ad-hoc 'scan a qr code' process.
Having said that, is the UI/UX apart from the above really terrible? When using as a simple messenger app, the experience for me is almost the same as WhatsApp (which almost completely replaced sms at least in the Netherlands). The biggest issue I have is that when you open the emoji selection screen when typing a message, you have to close this and reopen the keyboard to continue typing, which is a bit silly, but not a deal breaker.
> I think it would be less so if they just generate and present the backup security key at account creation, telling users to use this when they want to login on a different device and drop the whole ad-hoc 'scan a qr code' process.
That's exactly what I like about Matrix. I can verify other devices simply by comparing emojis - simple, easy, great. That it should work reliably is a completely different matter, but in itself it's great.
Fair enough, maybe it was just buggy behavior that made this process confusing to me, as I agree that something like this could in theory provide a smooth experience.
Yeah I completely agree. And server side, it's not good either (you can't federate with only a few servers, bugs are everywhere)… I honestly don't get how it started to be the "de facto" open source chat system trying to replace IRC while it is this broken.
Those are minor growing pains, and irrelevant when compared to the nightmare of navigating fifty independent slack instances or convincing an entire group to move their communication onto a private solution. For me matrix has been absolutely transformative. It's letting us grow our project's realtime communication without bounds. Because it's open and federated, without the political baggage of tools like Signal or the ancient cruft of IRC, we can convince anyone to meet us there. There are almost no impediments to it's use. The clunkiness is very minor. Although they may lack some subtle UI polish, the tools don't crash and work more than well enough. I'm looking forward to when the world meets on matrix.
In my experience, neglecting the onboarding experience is a cardinal sin for any project challenging some incumbent.
I‘ve been struggling with understanding what Element wants from me when signing up or signing in on a new device. Unfortunately I can‘t, in good conscience, recommend this to less technically knowledgeable friends and family.
...Except you can? federation_domain_whitelist in synapse settings. Seems to have been working since 2018. I'm using it. Enabling it can sometimes cause significant delays when communicating with users on homeservers you're not federating with, though - I have some vague memory of seeing an open issue around improving relaying in these scenarios.
I do agree that there's a long way to go before I can start recommending anything Matrix-based for friends and family. Things are just too slow, broken and inconsistent on both server- and client sides. There has been steady progress on all fronts, though. Maybe in a year or two.
While the UI is a bit buggy I would not call it terrible. It is an improvement over Google Hangouts (which is also quite buggy), Facebook Messenger, Skype and Whatsapp. Sure it is not as good as Slack or Discord, but if people are fine with Facebook Messenger they can also use element.
Mind sharing the matrix bridge? I think we are really close to regular people using matrix. Element is a really good client but it's slightly too rough around the edges still. We need something that's as joyful and fun to use (and look at) as Slack.
We also need a very easy export/import process for other clients. That's a huuuge untapped feature. It means the data stays the same but you just slap a new UI on top of it. "Apps" then only compete on UI which means the diversity and sophistication of those experiences will grow rapidly.
Combine that with a plug and play self hosting solution eventually and we're well on the road to secure personal clouds.
I found it on Matrix's site[0], direct link is here[1]. It's a bit of a pain to set up initially, particularly in a Docker-Compose deployment, as the containers are created to incrementally build up configuration.
> I think we are really close to regular people using matrix.
I personally haven't met any "real" people who are even aware of Matrix. When I broached it with a non-IT friend, they were actively uninterested in unifying messaging applications as they had "facebook friends" and "whatsapp friends" and interacted with them differently.
> export/import process for other clients
conversation history, you mean? Is there other data a messaging app captures that you want access to?
I am running my own home server, everyone in my family has an account they use there (the domain is our last name). Non-techy people use it and like it (past the initial setup, since setting up a custom domain requires a few more clicks than :matrix.org account). I am not waiting for the day, though, when they will need to set up a new device without access to the old one because of E2E setup. I would like Matrix to provide a setting to advise UIs to not use e2e encryption for the same domain -- that's useless if you trust the home server (my family do trust my home server).
> I personally haven't met any "real" people who are even aware of Matrix. When I broached it with a non-IT friend, they were actively uninterested in unifying messaging applications as they had "facebook friends" and "whatsapp friends" and interacted with them differently.
I tried to sell it too with the "unify your messaging apps", but this is a wrong selling point to new users. First they need to start using matrix as their messaging app, realize that it works well, including VoIP and video calls. Once trust is there, only then start thinking about using bridges. Because there will be rough edges (e.g. federated voice/video calls do not work).
Because of the way bridges integrate to third-parties, they are not bug-free. Reliability is just not great yet. Maybe except a hosted service, Beeper[1], which is run by people who know most about these bridges and can provide support.
To sum up, I am using Matrix for my family network, and some bridges personally; I am not yet planning to spread the use of bridges beyond myself. Besides the encryption setup, I like the UI a lot. I also use gomuks[2] from time to time, which is a terminal matrix application. I have not stumped into server-side problems.
I am donating monthly to Tulir[3], the most prolific Matrix bridge developer (and, to my knowledge, co-founder of beeper). Because I started using Matrix thanks to his bridges.
Oh, and I love the Matrix sms bridge[4]. I set it up to see if it works, and I am not going back. It's great.
> I would like Matrix to provide a setting to advise UIs to not use e2e encryption for the same domain -- that's useless if you trust the home server (my family do trust my home server).
It's not useless. What if there is a server vulnerability and someone (or something) hacks your server? Now all your logs have been exposed because they were stored plaintext.
That's super cool! I have not gotten anyone else on Matrix, I (and my bridges) am the sole user of the server, and it's my first exposure to the ecosystem. I had basically just set everything up when I saw Beeper's announcement. I'd love to set up an Android VM to host WhatsApp, as that's an appealing part of Beeper's offering. The host phone having to stay Internet connected is a pain.
> Oh, and I love the Matrix sms bridge
Agreed - I totally buy Beeper's testimonials, as I 100% am more willing to have an actual conversation with a text contact if I'm able to type it out on the device of my choosing. Ever since by Blackberry kicked the bucket, I've hated typing on my phone. That said, I've meant to fork the Android app to try and put a bit more feedback in it - if it doesn't work 100% right off the bat it gives roughly no indication of why. Could use a little love, as it's one of the killer bridges!
Holy moly I can't believe it took me this long to hear about beeper. I'm pretty awful at responding to msgs sometimes because I have so many different places that I can receive them. Will definitely be giving Beeper a shot and am surprised that more people aren't looking for this exact solution.
I even went looking a while back and all I found was franz which felt clunky and unusable.
Even though I want to get away from the fb ecosystem, at the end of the day, normies gonna norm.
Ahh ok I wasn't aware of this. I used the bridge about 1.5 years ago and dropped it because of its crazy memory use and instability. I didn't realise it had been rewritten. I'll give it another try, thanks!
> I think we are really close to regular people using matrix.
I wish this were true. We're not even that close to getting regular people to use Signal, at least not in meaningful numbers. Perhaps your friends family are more tech-savy and privacy-focused than mine, but it's like pulling teeth to get folks away from iMessage or Whatsapp.
If no "regular" people use these, then anyone who does sticks out like a sore thumb. One of the main reasons I'm using products like this is to support journalists, whistleblowers, lawyers, etc. (Who also are "regular" people in relevant ways.)
I don't understand why people have such an issue running multiple messaging clients on the same phone. I've managed to move a large chunk of my WhatsApp friends onto signal, then block in WhatsApp to enforce the signal usage. Of course there are holdouts.
> I don't understand why people have such an issue running multiple messaging clients on the same phone.
Simple: there's a messenger everyone is on. WhatsApp. There is no need to install anything else.
One of my friends who studied something IT related is adamant about having only one messenger installed. It's too complicated having 2-3 and not all contacts use either of the alternatives to WhatsApp.
Here in Sweden also everyone have multiple messengers installed due to no messenger ever reaching a critical mass. Both MSN Messenger and Skype were close at some point but neither succeeded.
> The only worry I have is Signals hostility towards analogous projects
Moxie certainly know that, but he can't actually prevent third-party clients. Not even Microsoft, ICQ and AOL succeeded on this when we were using Pidgin (and Licq and Gaim before that) to talk in MSN Messenger, ICQ and AIM.
Yeah, it creates an adversarial relationship which isn't particularly pleasant. E.g. they have no incentive to build functionality to help integrate, nor do they have the same incentive to provide stable integration points. In fact, it sounds like stable integration points are borderline actively dissuaded as they would limit agility of Signal and relegate it to irrelevance.
As much as I disagree with the underlying values, I haven't carved out 40 million monthly active users from a crowded space, so maybe it really is the best chance.
Nobody needs to absolutely prevent third-party clients; they just need to create enough friction to prevent serious investment in those clients. At least in Signal's case, there's a clear rationale for why they're doing that.
I kinda feel like that's more due to lack of interest than anything else, at least on the part of WhatsApp, which is restricted enough feature-wise that it'd be somewhat feasible to reverse engineer and build a client.
If I think about something like Slack or Discord, though, they surface area of those things are just huge. So many protocol details to work out, and so many features to duplicate for a third-party client. And they're such moving targets, too, with features added at a regular cadence (unlike AIM, ICQ, etc. back then, though even then Gaim/Pidgin didn't have voice & video support for a long time).
I also think the third-party client drive for AIM and ICQ was driven by people who wanted to use it on Linux but had no way to do so at all. The clients were Windows- (and Mac-?) only, WINE was a pain to use back then, and there were no web clients initially. But with Slack and Discord the impetus just isn't there. At least with Slack (I'm not super familiar with Discord), Windows, Mac, Linux, Android, and iOS are all officially supported, and there's always the web client if you don't like the Electron-based desktop clients.
On top of that, Slack's API is rich enough to enable things like a Matrix bridge, so, again, probably just not enough interest to do something truly standalone.
The only thing I'm somewhat surprised about is that no one has tried to build a third-party standalone WhatsApp client that doesn't require being tethered to the mobile client. But perhaps Facebook/WhatsApp has done a better job at obfuscating and hiding their protocol than AOL and Mirabilis did long ago. Or maybe the interest just isn't strong enough to warrant the effort.
Interesting, what makes you think the surface area of Slack is larger than that of WhatsApp, for example?
I think the latter hides a lot of complexity behind a simple UI, most notably all the E2E encryption logic and the purely client-side message storage, with an optional backup system and even its own built-in remote access server (for the web client).
Compared to that, Slack is mostly a HTML renderer as far as I can tell, with most of the complexity server-side (e.g. complex notification rules, multi-client support etc.)
I suppose the poster above you is referring to user experience - WhatsApp doesn't even have reactions, never mind the huge list of plugins that slack has. The only thing in favour of WhatsApp as a user is the encryption, which AFAIK slack just doesn't bother with (maybe that changed now).
I‘m still not convinced that all of these user-facing features necessarily translate into a larger client codebase.
My guess is that WhatsApp (and Signal, Matrix etc.) client logic is much more complex, since so many things that are fairly easy to do server-side need to be reliably performed in the client instead once E2E encryption is introduced.
Same here. I'm literally forced to use it with no more than a dozen contacts among close friends and part of the family, and despite the very short list of people, it's absolutely impossible to convince anyone of them to use anything else.
I would so welcome a FOSS client.
The official WhatsApp client has an excellent UX. There's simply no reason to use another.
For Signal it's not the case. The client is slow, has many quirks and lack features.
If Moxie allowed third-party clients, it would be a win-win situation. Over time users will get a usable client, and the core Signal team would be able to concentrate on their Crypto business.
I completely agree that Signal could very much use a third-party client, especially on the desktop. That being said if they want to push their cryptocrap they have to keep a strong control on the clients because third parties are likely to just ignore that functionality altogether, hampering adoption.
I'm not saying that's the main reason for them to exert such a tight control on the Signal ecosystem but it shows how damaging that move has been: now you can't really exclude an ulterior motive for them refusing to integrate with third parties. It damaged the trust I had in the project.
Is everyone using another WhatsApp client than me? If I would rate all chat clients I have used I would put it in the bottom 2, only Skype has a worse client.
The whatsapp bridge is based on the whatsapp-web api, which is non-functional if your phone is off. The phone part is what needs reverse engineering and replacing.
The motivation presumably is that if people start using Signal, but half their messages don't arrive because their contact is using a half-baked third-party client that hasn't kept up with Signal's development, then that's a great way to lose potential users.
Instead I lose half my messages because the desktop application won't sync correctly and/or corrupt its database every other week.
Surely there's a version header in the protocol that could be used to reject outdated clients outright?
That wouldn't be much of an issue if the official clients worked better and had the features I expect from a modern IM client. For instance I never really considered using a third party Telegram client because the official one works really well in my experience.
But apparently proper syncing will have to wait while they implement a cryptocurrency payment system. Priorities.
Yeah, I can imagine that especially if the team with full access to the back-end already has problems making everything work properly, they don't want to add additional developers with less hands-on involvement to the mix. (Even if those say the adhere to the same version.)
Look, I'm not saying you have to agree with the reasoning or that you would've made the same trade-off in their stead, but at least personally I always prefer to understand how they came to a decision and recognise that, even when I don't agree and am affected by the consequences of it, they're not doing it to spite me.
I'm not ascribing malice to their decisions, but I think they're really shooting themselves in the foot with the way they handle their PR.
Maybe I'm wrong but my theory is that it started with "end-to-end encryption means that you don't have to trust us" and it seems that many among the Signal team and fans took that to mean "we can behave as shadily as we want and not communicate well since it doesn't really matter anyway".
But there's more to trust than end-to-end encryption. I also need to trust that the project will keep improving and that I'll still want to use it three years from now. The fact that Signal is not federated and they keep such a strong hold on the project makes it even worse, I really have all my eggs in moxie's basket.
I used to actively tell people to use Signal, now I say nothing and these days I find myself using Telegram more and more even though protocol-wise Signal is clearly the superior option.
I won't presume the relative weighting of motivations, there's a notable blog post here [0] that elaborates on Moxie's dislike for federation. E.g.:
> So long as federation means stasis while centralization means movement, federated protocols are going to have trouble existing in a software climate that demands movement as it does today.
While my initial reaction was "omg, I hate it", I don't 100% disagree. I think one of the biggest drivers for adoption in Matrix world would be a streamlined on-boarding to a central server (matrix.org?), so that it "just works" by default. Like the front page of Reddit, get people in the ecosystem, then they can discover the subreddits and engage more deeply with the platform.
Agreed, although at that point, what's the point of the decentralisation?
As a comparison, email is technically decentralised, but if I were to move off of Gmail, 80% of my emails would still be on their servers because that's what their recipients use.
(This is of course somewhat of an exaggeration - it's still better than if email were a proprietary Google thing. But it's less of a utopia than my decentralisation-minded self had in mind in the past.)
I've been using this for a while (and even wrote the python library for it), it has worked quite well. My only feedback is that the release process was a bit too fast, frequently changing and breaking things without much API stability, to the point where I couldn't keep up with upstream changes and just stopped upgrading my personal instance and the library.
Hopefully that's gotten better nowadays, with a more solid versioning scheme. Judging from the site and documentation, signald more mature, which is a good sign.
I've never had an issue with the daemon itself, it's been working fine for years now. All in all, an excellent and extremely useful project.
Honestly the multi-device support is a big barrier to my adoption of Signal. Currently I use Telegram across several devices, and the messages just "sync" near instantly. With Signal you see them appear one-by-one, which is painful in a large + busy group chat. Obviously Signal has technical issues to overcome that Telegram does not, but the UX issue is still there
> With Signal you see them appear one-by-one, which is painful in a large + busy group chat.
How much delay are we talking about? In my experience we're talking maybe seconds, definitely less than 5s (depends on your connection of course). And since you only use one client at a time in theory (?), this shouldn't matter.
Or are you talking about the initial sync when you start your Signal client after a long period offline? This has improved recently for Signal-Desktop.
Telegram doesn't have encrypted groups, though. So it's a bit of a different use case. I share your pain when syncing Signal but Telegram is no option in regard to true privacy.
To all the humans mulling to play with this library, note that the signal-service-java[0] dependency signald relies upon isn't an officially shipped one. It's a fork with backported features. To me, it makes the library 2-times unofficial as it relies upon an unofficial library itself.
The official implementation[1] hasn't been updated for around 1,5 years.
This is really interesting. I’ve been wanting to push messages to signal via a webhook or something similar, and couldn’t find a way. I’ll have to try it!
Daemon presumably to handle receiving messages and triggering actions based on that. Do other signal clients allow CLI usage, or integrating with other software? (I'm genuinely not sure)
This daemon handles as much of the weird signal-specific stuff and exposes an easier to use API. It handles things like encrypting and decrypting messages, generating and storing keys, syncing with linked devices and a bunch of others.
signald doesn't really "trigger actions" or anything, but it would be pretty easy to write something that does using it.
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.
I suspect that a next step could be a browser-based client, or a Pidgin plugin, etc, something where you cannot just run Java code, or even open a socket.
I looked at the install instructions ("from source") and i while there were instructions, there was no download link for the tarball and no link to the git repository.
Turns out you have to click on the "gitlab" widget that shows the number of stars on the start page to get to the gitlab repository at https://gitlab.com/signald/signald
I wonder if this could be used for a better matrix bridge. The current one is super heavy because it's basically the full desktop client with a bunch of hooks to extract the information.
It is a little frivolous, but "signaldctl" is the most horridly awkward naming for the command line tool. The letters "ctl" are in a terrible location on the keyboard for smooth typing, but ignoring that, it doesn't even fit in typical naming where "signald" would have a "signalctl" binary to control it
Of course you can't really use "signal" because that's the name of the official product, but it still feels like there are better alternatives than the handful that was chosen
(Apologies for pulling a HN classic and being the only comment on the thread complaining about something dumb. At least it wasn't a comment on the web page type face!)
Not everyone uses qwerty (or the same layout in general), so complaining about how hard it is to type a certain string of letters doesn't seem like the job of an individual program to fix. It is a very rare and interesting complaint, however.
By the way, is your issue with the t? I think c and l should actually not be too bad to hit, even on qwerty. They're not in the middle two columns, and they don't use your pinkies.
With Workman, c is moved over one to the right, t is where f is in qwerty, and l is where m is in qwerty. So, t doesn't need me to stretch, and all of them become keys pressed with my index fingers, but since you may not like where qwerty c is already, I wonder if this would even be an improvement to you. It does put c and t much closer together, but both are still pressed with the left hand, and then l with the right. Not sure if hand alternation is part of what you had in mind.
Yup, it's the t :) It knocks me out of touchtype mode (or at least makes it awkward to keep going) I think just due to the sheer distance from both finger locations. A left-hand stroke from c -> t is awkward, using right hand for it seems even worse
signald author here, open to suggestions on that name. As you've noticed, I try to avoid using the word "signal". I do agree that the current name is pretty awkward.
edit: the name for signaldctl. I'm not looking to rename signald at this time
It's fine. You're borrowing from the systemd/systemctl pattern. That would suggest signald/signalctl, but signaldctl works too.
This being said, looking one level up the "bigger picture" chain "signalprotocold" comes to mind - but then "signalprotocoldctl" would give me a small headache :), and I don't know a good solution there. "spdctl" sounds it would be for a DIMM EEPROM configuration (???), "sigprotoctl" sounds nice if somewhat random, and... ugh, naming things is hard.
Sorry for "invading" an unrelated reply, but thanks for your work! I discovered signald an hour ago and I'm really happy about it.
I'm pretty sure that's the way for a better desktop experience with Signal, but I still need to test a few clients. Even before that, with signaldctl and the Python libs alone I already have a way of sending notifications, etc.
Not that I particularly think there's anything wrong with signaldctl, but for other apps that employ a daemon/control model, I've always found <service_name>d and <service_name>-cli combo to be good naming scheme.
2) You can't use either of these names as Signal owns a trademark on their name (and even cares, as they should, particularly for a security product) and this looks like an official product in a way you can't disclaim away: come up with your own name for your daemon and then "support" signal or be "for" signal.
https://signal.org/legal/
> Signal’s Rights. We own all copyrights, trademarks, domains, logos, trade dress, trade secrets, patents, and other intellectual property rights associated with our Services. You may not use our copyrights, trademarks, domains, logos, trade dress, patents, and other intellectual property rights unless you have our written permission. To report copyright, trademark, or other intellectual property infringement, please contact abuse@signal.org.