191–200 of 215 posts
Earlier quoted context omitted.
It is actually possible because Signal is 1. Open source. 2. Has verifiable builds (just being open source isn't enough). 3. Uses end to end encryption. You need all three of those to get what you want. Also you need to spend a ton of time building Signal from source and auditing it, which I doubt you're going to bother with but at least in theory it is possible.
4. Verification
Earlier quoted context omitted.
It is actually possible because Signal is 1. Open source. 2. Has verifiable builds (just being open source isn't enough). 3. Uses end to end encryption. You need all three of those to get what you want. Also you need to spend a ton of time building Signal from source and auditing it, which I doubt you're going to bother with but at least in theory it is possible.
What's running server side?
Yet another "Matrix isn't mature enough so just give up and use a centralized service" post that completely ignores the fact that XMPP is still alive and kicking. With multiple independent implementations (both client and server) that all work together pretty decently. We're never ever going to tear ourselves away from this death by centralization if we keep inventing excuses for why we don't use the federated/distri…
Email is another decentralized, distributed system that is often ignored. The only real difference between chat and email is that the interface makes it seem like chat is quicker. Nothing stops us from writing such interfaces for email as well, though.
Earlier quoted context omitted.
> People seem to have an expectation that Signal server API is public, and that it should allow any compatible client to connect That's because people have a reasonable assumption that a single actor (however good it is) should not have power over all of our communications. That's why we had federated networks in the first place (HTTP, SMTP, XMPP, DNS). Avoiding vendor lock-in is an important feature for most people.
Do people not realise that lots of single actors have power over all their communications°? Their ISP, for instance. ° Let's gloss over the fact that all here is hyperbole, unless you use a single mechanism / medium for communicating with everyone.
A bad state of affairs is no reason to keep going in the wrong direction.
Most of these criticisms are solvable problems. If you make a direct connection to other users, they see your IP address. So use Tor or a VPN. Many P2P lookup systems assign identifiers for routing etc. So assign ephemeral ones for anything that doesn't need a persistent one, and make sure persistent ones aren't suitable for correlation, either by not using the same identifier for multiple services by the same person…
This response has been written a thousand times, but here goes again... Using a VPN or Tor is not a viable option for the average person.
Earlier quoted context omitted.
What does "scam" even mean here? I know what I'm signing up for, privacy-wise, when I provide Signal my phone number and access to some of my contacts, and I clearly get something in exchange.
Why are you providing your phone number to anyone? Software should be free.
The author specifically criticizes IPFS and others, who do not care for privacy, and rightly so. However, this is not inherent to the technology. There are others who do, such as https://gnunet.org
Earlier quoted context omitted.
“Please don't repeat falsehoods like this.” You accuse the parent commenter of making a falsehood, but then you go on to confirm their statement as true.
> Essentially you either use the main server or you are a large org that can pay for a powerful machine to run it. To be perfectly clear, the above was the original statement I was referring to and it is completely false.
It’s also not going to remain true over time.
But it’s not a false characterization in practical terms for most people.
Earlier quoted context omitted.
that definition seems like a bit of a stretch: decentralized does not mean anything more than not being centralized. Federation implies decentralization.
> Federation implies decentralization. No it doesn’t. Gmail is a centralized instance of a federated network. You can have a federated node that becomes so popular that it’s basically centralized. This federated/decentralized distinction is pretty common. You’re dwelling on literal definitions but there are more semantic differences those words have picked up in the communities involved.
For a long time, federated architecture was seen as special case of decentralized, for example in designing stuff for internal use. It still makes sense in that context.
In the context of larger external facing systems, I've found it useful to think of federated as "partly decentralized", and "decentralized" is short-hand for "fully decentralized".