As much as I love Signal, we've got to move to things that are decentralized. I setup a prosody[1] server a while back, but have nobody to talk with. If anyone wants to try their system out, I'm bjt@2n3904.net on XMPP.
Edit: Aaand I'm up! Got my first message. Thank you for your help, and for your work on Prosody!
That's not to say decentralized doesn't have a ton of benefits just uptime for the user isnt one.
I know they don't like third party implementations because then if you need to make a protocol change you'd have to wait 30 years for everyone else to update their clients. But if you're already requiring a single client that it makes it easier to do decentralized messaging for exactly the same reason.
Another option that works pretty well is to do both. So try decentralized (DHT / direct connection) first and fallback to a central server if that doesn't work. Then you're up as long as either one of them is working. And there is a lot less load on your central servers.
But there are also solutions that don’t require everyone to host their own server. Rather, people just host impersonal nodes on the network and everyone uses the whole network together.
Examples would be Status[1] (Ethereum) and Session[2] (Oxen neé Loki).
I’m sure there are others that use this architecture too. I just like it because I don’t have to be personally concerned with who is running my “home server”. Because there is no one single home server in this model.
[1]: https://status.im/
It sounds like these must be centralized systems presented as decentralization, similar to how Keybase marketed themselves as end to end encrypted and nobody noticed that you can't actually verify peer's keys thus making it TOFU (similar to blindly accepting ssh keys). (And when you asked people about their claims about Keybase, they'd tell you to RTFM regardless of whether you already said you did that... A marketing department can be very powerful even on HN.)
Personally I think that’s the best way to do it. Public keys aren’t very different from phone numbers at this point. Nobody memorizes phone numbers anymore either. Each person just has their own Rolodex mapping of keys to names.
How easily can Signal replace those dependencies if this comes for them?
"Extremists move to secret online channels": https://www.nbcnews.com/politics/congress/extremists-move-se...
AWS S3 is/was used to share files with other users. It became a standardized API, with many alternatives supporting the protocol, so switching to a different provider or on-premises should not be difficult.
Signal intends to remove the dependency on phone numbers, and therefore Twilio, but this has not be done yet.
And if the OS decides to kill your app's process, your polling dies with it and you don't get notifications.
Maybe that's a good reason to open for federation and now I wonder if it would be possible to have an user migration between servers without cooperation from the origin server. This would allow users to move to a new one without losing track of existing conversations.
Seems crazy, but the reason we can't do this with email is the lack of a generally agreed identity for an user account that does not depend on the server itself. Signal accounts have a "master" key that can provide this and it's only stored in the device and backups (it's the most trusted of all keys, after all).
A sketch:
- User creates an initial account on server X (account: user@serverX.org), the procedure includes signing a message saying "I use server X since $TIMESTAMP and this is the 1st server that I use";
- Everything works as now.
- User wants to change server, so they signs a new message "I use server Y since $TIMESTAMP and this is the 2nd server that I use" (account: user@serverY.org); this message is sent to all chats/groups/contacts and to the old server (as an information only, it may be already down or be non-cooperative). Contacts update the server part of the account and start sending messages through the new one. Maybe the user can still try to contact the old server for a while, for the event it delivers a message from a account that didn't get the first, but at some moment all users will get the new address.
Notice: I have no idea of how this can work with sealed senders of other metadata-prevention measures that Signal uses and we all love.
Bonus: no more dependency on phone numbers.
Or if it goes to an more email-like architecture were users only speaks with their servers, it can adopt concepts from djb's Internet Mail 2000 [https://cr.yp.to/im2000.html]. This will *not* work for current email due to the need of keeping compatibility with the enormous existing user base, but this problem does not exist for a new protocol.
Maybe you're mixing it up with Matrix, Briar, or some other decentralized chat system.
Is there any decentralized protocol that's in widespread use? Email is the only one, and if hackers take out Gmail and 2-3 other major email providers 99% of the world's personal email is gone.
Do you need a static IP? (Xfinity appears alergic to allowing static IPs any more, and I am too lazy to setup my own router after 26 years setting up other peoples net infra..)
Id love to chat with you...
I've used XMPP servers for intra-organization chatservers before though, and it worked great!
Sure.
>Do you need a static IP?
Well you need a domain name to identify your server. It's the same thing as with email. So however you can do that...
It might be less work to just use a preexisting public server:
Easily.
> Do you need a static IP?
No, but you need access to a domain record to add the required entries for XMPP, and update them if your IP changes. One can do this for free (once you have a domain that points at their DNS records) with a provider like Digitalocean and their API to update the domains.
Set up guides: https://prosody.im/doc
Community to ask: https://homebrewserver.club/
I'm using Conversations for Android. If you have a server that will allow self service registration, you can make an account right from the app.