Privacy-focused messaging app Signal is adding new features for video calls, including links, reactions and a calls tab, in a bid to pose as an alternative to Zoom, Google Meet and Microsoft Teams.
Jitsi is a open-source video platform you can self-host.
I don’t trust anything going through another company’s servers. Zoom had to backpedal when it was found feeding content to AI… Imagine talking about your company business secrets and now some dickwad are Zoom reads the transcripts and steals it.
Is Signal video and call not end to end encrypted like their messaging?
Until you can manage a “group of people” (your company), and give them permissions to “rooms” (chats/channels) by group, Signal can’t compete.
Administrators aren’t going to one-off everything, or rely on users to do it when there is no admin visibility.
Getting admin tools right with an encrypted service is key here.
TBF, the level of privacy afforded at work will never be usable in most companies.
At scale, it’s a security nightmare. PII, HIPAA, PCI, If OPSEC can’t at the very least go back and see what happened in private channels, it’s going to be a hard sell.
That’s fine and all, but if I use a product (especially a privacy focused one) for my personal communication, I do not want to use it for work. A proper separation between work and personal is too important to me.
Great. Now can we get text messaging back so that it’s possible to convince people to use it again?
Security risk, by their own admissal.
No, that was an excuse. They claimed people could mistakenly send unencrypted messages. Easily resolved by changing the color of conversations and send buttons to flag SMS as insecure.
It was really about moving development resources to features like this one. Unfortunately, it makes it much harder to convince people to use (or keep using) Signal, meaning more messages that go by insecure messaging instead.
Disagree. Consider that Pegasus’s vector was very often specially crafted SMS payloads.
Is that a US thing? I don‘t know anyone who still uses SMS. Or do you mean something else?
Nailed it. Yes, it’s a US thing.
The U.S. lagged adoption of SMS compared to Europe (relatively high prices for texting in the early days while relatively low prices for calling in the same era) but now SMS/RCS/iMessage are the dominant mobile messaging method in the U.S. There’s much lower adoption of third-party services like WhatsApp compared to the rest of the world because basically everyone has those services (SMS/RCS) already on their phone, they don’t have to sign up for a service that not everyone might use, and it’s basically free on every phone in the U.S. now.
SMS and especially MMS sucks ass though.
And an alternative to Discord?
A chatroom isn’t hard to replace, but the video/voice calling on Discord is what keeps people there.
Signal should evolve to have discord-like channels and servers. I think it’d be brilliant.
Fuck discord.
Please don’t.
I am aware what Discord is for and respect it but it’s ectic to be in a Discord room. Signal does not need it.
Yes they should. Having business and gaming communities using it also helps the journalists and activists that use it to stay safe by normalizing its use
So they just added a few buttons?
Call links are a lot more work than “a few buttons”
That’s not really the best example to prove a lot of work. Call links are actually pretty easy from a conceptual standpoint:
-
Make a small website to accept
https://join.my.website/?callid=...&password=... -
Have the website redirect to:
myapp:join/:callid/?password=... -
Have your app register as a
myappprotocol handler. -
When a
myapp:join/:callid/URL is visited, open the same window that would be used normally for joining a call by ID.
I’ve been an android developer for a decade at this point, I’m aware of how app deep links work.
The comparison is not “what LOE is call linking from scratch” but rather “how does call linking meshing into existing production codebases across all platforms compare in LOE to 3 buttons?” And the answer is self evidently more.
You’re minimizing the amount of effort and we’re comparing it to buttons. Adding “a few buttons” is very different than setting up 3 platforms to all use a new protocol (calls from links will require new handling - previously all calls were just based on authenticated users being allowed into webrtc calls based on their tokens. Now you have to have a new handler which joins a call with the token in the URL - that can’t be handled identically). Then we get into the Android app, much of which is still in Java, which uses multi-activity-srchitrcgure meaning you’ve gotta pass data through each layer manually, rewriting each of these activities to accept the new deep link and route to the right end.
And then you’ve got to be sure it all coordinates across iOS, Android and your backend.
It’s not hard but it’s not “a few buttons”. It’s probably 2 weeks of work for skilled and competent engineers, 1 per platform.
Do you actually have any experience in Mobile dev? You sound like a fresh outta college junior eng - cocky and confident that everyone else is wrong, making it harder than it needs to be etc.
Just like that cocky junior eng you’re too unaware of what you don’t know to realize you’re wrong. Wade through the grass a few times and you’ll realize the flowery meadow is full of snakes.
You’re barking up the wrong tree here, buddy. I’m not the person who said “it’s a few buttons.”
I was merely pointing out that from a conceptual standpoint, deep links don’t need months of research and design work. The difficulty—as you pointed out—comes in knowing how to work with the various different platforms and integrating the feature into existing codebases.
-
