Live data from Hacker News

Reflections: The ecosystem is moving

whispersystems.org

21–30 of 103 posts

Re: Reflections: The ecosystem is moving

#21
post #14

Earlier quoted context omitted.

It's precisely the fact that Moxie is so credible on this topic that makes his post so frustrating. I believe that he's telling the truth as he sees it, and I believe that he's as well-situated as anyone could be to pull off a white-hat secure messaging system, so if he says it can't be done with federation, it's awfully hard for me to assert that he's wrong. The problem is that I don't see the point of doing any of…

The fact that Signal exists, and I can use it every day with friends and coworkers, is evidence that we are not locked in. No one is making money from Signal, and anyone who uses Signal can switch to any of ten different (less secure) apps in five minutes. And if Signal goes away or whatever, we can build our own! The only thing stopping us is that we are a lot worse at designing crypto than Moxie and Trevor ;)

You cannot use it with EVERYONE though, can you? Signal requires Google Play Services and is refusing to remove that dependency - leaving out all those users who cannot install Google Play Services, either for privacy reasons (as moxie calls them: "cryptonerds") or because they live in countries where Google is banned (all of China for example).

LibreSignal folks are willing to do the work for removing that dependency on GCM but Signal won't federate with them.

OTOH, moxie does have a point. They've tried federation with Cyanogen and the experience was painful.

Re: Reflections: The ecosystem is moving

#22
IMO you can still add federation (and you should for freedom and security), but no need to expose it to the user. For example: set the default server to signal servers. For sake of sanity, you probably want to route all servers to the default signal server. But you could easily allow user@server. If you can figure out how to use phone numbers directly between servers, congratulations, cause it will not be easy. But I think people who want to run their own server will not find that much of an issue.

In terms of getting stuck in time, you could use though love, and require backwards compatibility for like a month but no-longer. But so long as you keep the phone-numbers @the signal servers, your server will be the reference, and any server not following will get the blame.

Re: Reflections: The ecosystem is moving

#23
post #6

I'll add my thoughts here, since I think a number of people will be disappointed in this post. There are a number of competing goals when developing software that "the whole world can/will use". And it seems obvious to me that getting the whole world to use a secure, encrypted messenger like Signal (now, Whatsapp) is a noble goal. The obvious competing goal is federation, and the fact that we've failed at improving f…

I feel the same way, about achieving goals "right now" as you put it. The largest problem I see with security, is the ecosystem is in a constant cold war. Always trying to be perfect, many times at the cost of in convenience. "Do one thing and do it well," always rings true to me.

As an aside I have made a stab at prototyping a solution to the federated services using the keybase API: https://github.com/lettergram/AnyCrypt

Re: Reflections: The ecosystem is moving

#25
post #6

I'll add my thoughts here, since I think a number of people will be disappointed in this post. There are a number of competing goals when developing software that "the whole world can/will use". And it seems obvious to me that getting the whole world to use a secure, encrypted messenger like Signal (now, Whatsapp) is a noble goal. The obvious competing goal is federation, and the fact that we've failed at improving f…

> I think it sucks that constantly-improving services are impossible to address in a federated way, and he's not really offering a solution to that.

The solution would be education. Federation would work okayish if the average user was more tech-literate and thus could see that federation in combination with the willingness to migrate to a new protocol every decade (or even sooner) would be superior to any centralized solution.

Of course, changing protocols on a weekly basis would be too much but everything has its trade-offs.

Re: Reflections: The ecosystem is moving

#26
post #10

I totally get this; federation is hard , and its so much easier and nicer ─ as a developer ─ to have a centralised service. Often centralisation is the right choice for a particular project, and I respect that. That doesn't mean we should give up trying to federate things, though. The major upside (for me) to federated systems is simple: choice . Choice over the client you use. Choice over the servers you use. Choice…

> The major upside (for me) to federated systems is simple: choice. Choice over the client you use. Choice over the servers you use.

With a centralized system, you cannot choose the servers you use, but you can still choose the client, if the procotol is open and versioned.

As explained in Moxie's post, being able to choose the servers you use doesn't help if all servers use the exact same protocol with the exact same features, frozen in time.

> The reason I think that things like email and SMS are still so prevalent is how you don't need to care what service the other people are on, you don't need to worry about how other people are going to talk to you, it all just works.

You're right, people continue to use email and SMS because they are available everywhere. But people also use things like Facebook, Skype or WhatsApp because of email and SMS limitations.

Re: Reflections: The ecosystem is moving

#27
I agree with Moxie's assertion: federated services are losing. As it stands they can't keep up with the rate of change and iteration currently offered by centralized protocols.

But rather than this being a problem with federation itself, perhaps it's an issue with existing implementations. Things like XMPP give protocols so much flexibility with extensions that upgrades become costly and difficult to implement. Others, like HTTP, SMTP, and IRC are updated very slowly.

It seems like it should be possible to implement federated protocols that are focussed on fast iterations. For example, a protocol could specify that each version has a fixed lifetime of just one month, and require all clients and servers update to the new release in the last week of that month. Such a fast-paced protocol would have some disadvantages over slower ones (e.g. longevity), but it seems better suited to the pace of modern software and service development.

But I've never developed a protocol, let alone a federated one. I'd love to hear some potential problems or examples of failed protocols that have taken this kind of approach.

Re: Reflections: The ecosystem is moving

#28
post #14

Earlier quoted context omitted.

It's precisely the fact that Moxie is so credible on this topic that makes his post so frustrating. I believe that he's telling the truth as he sees it, and I believe that he's as well-situated as anyone could be to pull off a white-hat secure messaging system, so if he says it can't be done with federation, it's awfully hard for me to assert that he's wrong. The problem is that I don't see the point of doing any of…

The fact that Signal exists, and I can use it every day with friends and coworkers, is evidence that we are not locked in. No one is making money from Signal, and anyone who uses Signal can switch to any of ten different (less secure) apps in five minutes. And if Signal goes away or whatever, we can build our own! The only thing stopping us is that we are a lot worse at designing crypto than Moxie and Trevor ;)

> Signal exists

Only if you have an Android device with a mobile phone number.

Re: Reflections: The ecosystem is moving

#29
> As a software developer, I envy writers, musicians, and filmmakers. Unlike software, when they create something, it is really done — forever. A recorded album can be just the same 20 years later, but software has to change.

This is funny, a few lawyers I know, constantly complain they should have got into software.. Write once, sell many (pre-SaaS days..). They complain in their job, every day they have to go out and perform to continue to earn. Just funny how we ALL think the grass is greener on the other side (and tend to oversimplify).

Re: Reflections: The ecosystem is moving

#30
post #6

I'll add my thoughts here, since I think a number of people will be disappointed in this post. There are a number of competing goals when developing software that "the whole world can/will use". And it seems obvious to me that getting the whole world to use a secure, encrypted messenger like Signal (now, Whatsapp) is a noble goal. The obvious competing goal is federation, and the fact that we've failed at improving f…

For me the sentence that resonated most was "If a centralized provider with an open source infrastructure ever makes horrible changes, those that disagree have the software they need to run their own alternative instead.". If the centralized service is running mostly open source software than people can easily switch to another provider. GitLab.com runs GitLab EE which is similar to GitLab CE people can use to start another service (which has been done). I think having a centralized service allows us to move faster than with a federated service. That doesn't mean we wouldn't like to make it more federated, I would love that https://gitlab.com/gitlab-org/gitlab-ce/issues/4013#note_306...
Post reply on HN