Our great sponsors
-
Signal-Server
Server supporting the Signal Private Messenger applications on Android, Desktop, and iOS
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
-
-
matrix-doc
Discontinued Proposals for changes to the matrix specification [Moved to: https://github.com/matrix-org/matrix-spec-proposals]
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
On the public repo, there have been no changes since April 2020
https://github.com/signalapp/Signal-Server
If you go here https://github.com/signalapp you can see there were changes 8 hours ago.
So yes no public changes have been pushed, but changes are happening. It is fair to ask what changes are being pushed given their push for privacy.
How much do you want to trust here?
It's worth noting that this sounds to be an unfederated server.
The reason Synapse has a reputation for being resource hungry is on publicly federated servers: if one of the users starts going and joining a bunch of large busy public rooms from their new server, then those rooms get dutifully replicated onto the server, which inevitably consumes resources.
The more users and the more servers in the room, the more changes of gnarly forks and merge resolution problems, and the more the risk of CPU spikes. We're constantly working on the memory footprint and state resolution algorithm (e.g. https://github.com/matrix-org/synapse/blob/develop/docs/auth... landed a few days ago), so the situation is improving, but this is the root cause.
The benefit of running Signal on F-Droid is its secure update mechanism.
Do you really think a homebrewed self-update mechanism is superior to the battle tested F-Droid?
Moxie has a complete stranglehold on the Signal system. You are completely at his mercy for all decisions affecting the platform
See:
https://github.com/LibreSignal/LibreSignal/issues/37#issueco...
The solution is federation, like email has always been.
There are a couple of ways to solve this problem, which can be used in tandem. We can stop Signal from knowing when we’re talking to each other by using peer-to-peer chats. This has some significant drawbacks, namely that both users have to be online at the same time for their messages to be delivered to each other. You can still fall back to peer-to-server-to-peer when one peer is offline, however. But this isn’t the most important of the two solutions.
The most important change is federation. Federated services are like email, in that Alice can send an email from gmail.com to Bob’s yahoo.com address. I should be able to stand up a Signal server, on my own hardware where I am in control of the logs, and communicate freely with other Signal servers, including Open Whisper’s servers. This distributes the security risks across hundreds of operators in many countries with various data extradition laws. This turns what would today be easy for the United States government to break and makes it much, much more difficult. Federation would also open the possibility for bridging the gap with several other open source secure chat platforms to all talk on the same federated network - which would spurn competition and be a great move for users of all chat platforms.
Moxie forbids you from distributing branded builds of the Signal app, and if you rebrand he forbids you from using the official Open Whisper servers. Because his servers don’t federate, that means that users of Signal forks cannot talk to Signal users. This is a truly genius move. No fork of Signal4 to date has ever gained any traction, and never will, because you can’t talk to any Signal users with them. In fact, there are no third-party applications which can interact with Signal users in any way. Moxie can write as many blog posts which appeal to wispy ideals and “moving ecosystems” as he wants5, but those are all really convenient excuses for an argument which allows him to design systems which serve his own interests
> A common defense in favor of Signal is, “But it’s all open source!”. Sure is, but on what basis do I trust them? ...
The open source aspect for me means 2 things.
- I can verify the e2e encryption claim.
- I can reproduce the client builds ensuring that what I run matches the source [1]
Is there a detail relating to the server that would invalidate this?
[1] https://github.com/signalapp/Signal-Android/tree/master/repr...
Builds on Android have been (mostly) reproducible since 2016: https://signal.org/blog/reproducible-android/
Looks like the situation is more complicated and still unresolved for iOS: https://github.com/signalapp/Signal-iOS/issues/641
On another note, yesterday I set up my own matrix-synapse [0] homeserver along with a token-based registration page [1] with nginx+lets encrypt as a reverse proxy. I spent ~1 hour setting it up on a fresh Ubuntu 20.04 VM.
I then on-boarded my wife, brother, father and mother without issue. I just sent them a text with screenshots and detailed instructions on what to do. Everyone's in, and we have E2EE group chats going. Within ~20 minutes of sending instructions everyone was participating in chat.
All clients are Element [2] right now, though I plan on trying Weechat [3] this week.
Honestly, I didn't expect it to be this easy to do after seeing all the complaints on HN. I subscribed on Patreon yesterday and wish you all the best of luck!
[0] https://github.com/matrix-org/synapse
[1] https://github.com/ZerataX/matrix-registration
[2] https://element.io
[3] https://github.com/poljar/weechat-matrix
You can see some proposals for server migration/fallback here:
https://github.com/matrix-org/matrix-doc/issues/915