Hacker News new | comments | show | ask | jobs | submit login
Reflections: The ecosystem is moving (whispersystems.org)
226 points by tprynn 558 days ago | hide | past | web | 98 comments | favorite



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 federated services (e-mail being the best/most important example) is a problem.

Ultimately, Moxie's arguments here hold a lot of sway for me. 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. But instead he presents arguments I hadn't thought about much, which is that perhaps non-federated services can be dramatically better than federated services in the short-term. And in the long term, perhaps we'll move back to federated services; right now, the cost of changing services/ecosystems is very low. So we don't need to be as 'doom-and-gloom' about the fact that Signal does not achieve all the competing goals, because it achieves a number of extremely important goals right now, and we can work on the other goals in the future.


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 this without federation. If we're just using the Internet as a substrate for a bunch of proprietary silo services, then we're just back to the way things were before - walled gardens and media conglomerates and extortionate Bell System-style lock-in shenanigans. So what? Why bother? What have we gained, with all this effort, if we're back in the same old shit again?

The whole point was that we no longer needed to get anyone's permission to communicate, to publish, to build new services for interacting with each other; we could just do it. If federation is gone, then those days are gone, and the most important reason to care about the Internet is gone, too.


I think this post misses one of the points in the original essay, which is that federation is less important for user-level protocols because the network layer beneath it is open. That tilts the slow-moving-federated-service vs. fast-moving-centralized-service tradeoff towards fast-moving-centralized-service, which is why we see the landscape we see today.

His argument applies for any centralized top-layer services built on top of open substrates. Because the substrates are open, users can relatively easily switch between centralized services, which lowers the badness of centralization, which in turn makes centralization a more reasonable tradeoff to make.

The question he didn't address, I think, is what happens in the case where you have centralized services emerging on top of another centralized service. In that case users might be able to switch their top-level service providers, but it would be much harder to switch the lower-level provider.

But then again, that's exactly the lesson that everyone in the software industry learned with the dominance of Windows as a platform in the '90s and early '00s, and I think that's why you see so many companies building proprietary layers on top of open source components, and the current growth of cross-cloud compatibility libraries. The user-facing service providers want to make sure they can never be hurt by a centralized platform underneath them. And that's the dynamic that I hope will end up protecting users as well.


"what happens in the case where you have centralized services emerging on top of another centralized service"

It is too shaky ground. Both Facebook and Twitter had a chance to be a platform for 3rd party apps, and they both chose to leave the developers in the cold.


> Because the substrates are open, users can relatively easily switch between centralized services,

How is it easier for me to switch from Facebook to something else, if it's carried over the Internet as opposed to something proprietary like their own modem pools for example?

I can't think of a single service for which that is true. Facebook is the lock in, just as Microsoft is the lock in for office PCs even if the underlying technology is somewhat open.


I hesitate to get all Clay Shirkey here, but I think this is fundamentally different from media conglomerates and Bell Systems, given that now anyone has the ability to build their own overlay service with relatively minimal investment.

Part of what I've been noticing is that we have these "walled gardens" today that people consider to be synonymous with "lock in," but it's actually easier for people to move from Viber to WhatsApp to Telegram to Signal today than it is for people to move from gmail to yahoo mail.

In a sense there's less lock-in with centralized messaging services than there is with the federated ones, due in part to the move towards user-owned identifiers like phone numbers.


I get what you are saying about it being easier to move from one walled garden to another (based on the evidence that those moves happen more often than moves from between email providers)... but there is such a huge caveat that those moves are never a move chosen by an individual.

I cannot, as an individual, choose to move from one walled garden messenger app to another - if I do, I cannot message those people that don't. I am stuck going along with the group. This is ok in a lot cases (when the group's priorities line up with mine), but sometimes the things that are important to the group are different than the things that are important to me. For example, I might prioritize security over ease of use, but since the group doesn't, I will never get my wish, and I am stuck on a service that sacrifices security for ease of use.


Wouldn't you still have that problem with a federated system? You could roll your own uber-secure decentralized messaging protocol right now, if you wanted, but if nobody else adopts it then you're basically SOL.


The difference, I think, is that with federated system you can have a partial state where you communicate securely with those that have also adopted the security extensions, while making insecure connections with those who didn't, all within the same application/protocol (by using protocol extensions). Therefore, such features can be gradually adopted by an increasing amount of users.

If the system is centralized and it doesn't support security, it's all or nothing; to enable secure protocols, both you and the other party must change to a different app, and you'd have to support both systems in order to communicate with secure and insecure users.


Part of what I've been noticing is that we have these "walled gardens" today that people consider to be synonymous with "lock in," but it's actually easier for people to move from Viber to WhatsApp to Telegram to Signal today than it is for people to move from gmail to yahoo mail.

I wonder how much of this is specific to messaging services, though:

After all, messagers are both real-time and strongly biased towards current information. This means it's both very easy no notify people of a new account and relatively painless to close down an old one - you rarely have valuable archieved Whatsapp messages that you can't afford to lose.

Finally, thanks to platform notification APIs, it's very easy to run different messengers at once, so if your social network is split between different services, that's usually not a problem.

I don't see how those qualities are present in other services which have become more centralized - e.g. email, cloud storage, more persistent social networks or publishing. If I'd like to shut down my Facebook account and switch to some other hypothetical network, without losing all my contacts, that's going to be a lot more difficult than switching messengers.

Also note that smartphone apps are pretty much "walled gardens within a walled garden" as of now: Yes, it's easy to port my contacts from one android app to another android app or to run different messenger apps in parallel. But that's because I'm actually just giving different apps permission to the same underlying APIs and database. Shutting down my Google account and migrating to a cempletely open alternative: not so easy.

I do agree with the post that centralized services de facto are more sucessful than federation in the current ecosystem. But I'd argue that centralized services still have a lot of disadvantages for their users. So maybe we should start analyzing why this is the case instead of just shrugging and saying this is how the works works.


> it's actually easier for people to move from Viber to WhatsApp to Telegram to Signal today than it is for people to move from gmail to yahoo mail.

That's only because those apps aren't used for anything complex, while email goes in all kinds of automation and long term storage.

Ant that's only because email is some stable technology that you can count on working without "staying in contact", or "checking you got it". (Even if many people will do those things.)


Okay, I guess I see some value there. The problem is that my motivation is fundamentally political, and centralized services are basically autocracies. I suppose it's a good thing that people can emigrate more easily now, thereby forcing dictators to compete with each other to attract subjects - but I wasn't looking for a benevolent dictatorship, I wanted us to kick the whole hierarchy over and use our shiny new communication tools to organize a happy self-regulating democracy. What frustrates me about your article is not that I think you're wrong, because I don't have sufficient knowledge to make such a claim: what bugs me is the fear that you're right, which would mean that we failed to get the job done and now the window of opportunity has closed. I guess a more benevolent dictatorship is an improvement, but it's a sufficiently small improvement that it leaves me feeling like the last 15 or so years of Internet development were basically a waste of time.


There's an old quote from Arthur C. Clarke that I think is relevant here:

"When a distinguished but elderly scientist states that something is possible, he is almost certainly right. When he states that something is impossible, he is very probably wrong."

(Apologies to moxie for the whole "elderly" bit!)


"It's precisely the fact that Moxie is so credible on this topic that makes his post so frustrating."

Exactly. He's right. And it sucks.

It's especially annoying for messaging. There are now all these messaging apps that don't interoperate. If you're on WhatsApp and the other party is on Telegram, the message doesn't get through. It's like the early days when MCIMail and CompuServ didn't talk. But if you don't have a walled garden with broken glass on top of the walls, you can't monetize messaging.


Centralisation and federation must die, bring on peer-to-peer networks.


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 ;)


I was using Signal, too. One day it phoned home, got some new instructions from its creators, refused to work any longer, and demanded that I download an upgrade. I was not excited about this, since upgrades generally break things, but after a few days of grumbling I knuckled under. Sure enough, the upgrade is broken: it insists that I have to upgrade Google Play Services, which I can't do, because I deleted it along with the rest of the Google code I don't want to use.

I can't use Signal anymore, by Open Whispersystems' choice, which means I can't easily communicate with a fair number of my friends anymore, and that's apparently just the way it is. Open Whispersystems demands that I let Google have a level of access to my phone I don't want them to have, or they won't let me use Signal. Their proprietary Signal software is the only way to use the Signal service, so I can't just switch to an app whose privacy characteristics might be a better fit for my needs, as no other apps exist.

Am I going to convince everyone I want to communicate with that they should stop using Signal and start using something else? No, I am not, because why would they do that? They're all happily using Signal now, and I'm the odd one out, so I lose. Sure feels a lot like lock-in; I have no good choices here.


I guess at the end of the day, that exactly my concern too.

Signal is awesome, which is why we want to use it, but then suddenly the user finds they're now inextricably tied to Google or Facebook collecting their metadata - while we know Google themselves have been compromised (technically & legally) and are forced to hand that data over. Notably, to an NSA that has lied to Congress about it's operations, without consequence, and hence is now beyond oversight and reach of regulators too.

Also that the iOS code, which appeared to be free & open, is actually not, because other projects are denied permission to use in a way that's compatible with iOS's App Store). Ironically because the libraries are under GPL. Hey, blame Apple I know, or ourselves for not reading all Apple's T&Cs before promoting Signal, but it's disappointing none-the-less (while also still being OWS's right).

From all their history, the OWS guys seem to really want and be trying to do the right things, within the constraints and trade-offs available to them. The answers aren't trivial, but something about where it's all ended up leaves a very uncomfortable feeling.


Wisper's arguement here is basicly: you don't matter, and we arn't going to do anything to help you.

And due to their walled garden, you can't do anything to help yourself either.

so much for "open source infrastructure for a centralized network now provides almost the same level of control as federated protocols"

Unless you mean control for Google.


I see where you're coming from but I think you're being too harsh. I don't know Moxie personally, but he's been out there fighting the good fight since the '90s - I have a vague and possibly erroneous memory of having encountered him on the old cypherpunks list, back during the dawn of time. While I have had a frustrating experience with Signal, I have nothing but respect for Moxie's skill and his commitment to secure, private communication. Engineering is hard, everything is a tradeoff; I'm certain that nobody involved with Signal has any intention whatsoever of trying to sell us out to Google. They're undoubtedly looking at a complicated problem and trying to do a good job with it. It just happens that their particular choices aren't working for me.


Signal is open source, so you can just fork it to remove the dependency on GCM.

In fact, someone already has, so you can just use it: https://fdroid.eutopia.cz/


Open Whisper Systems have asked LibreSignal to stop using their servers and may decide to shut it out.

See https://github.com/LibreSignal/LibreSignal/issues/37 and discussion upthread.


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.


I'm an outsider, so I'd like to make sure I understand this...

So moxie here is claiming to offer the superlative encrypted communication service. On the other hand, he's insisting on a hard dependency that not only compromises privacy, but locks out one of the biggest emerging markets?


His reply here may be relevant: https://news.ycombinator.com/item?id=10665520


> Signal exists

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


Signal does not require an Android device.


So how can I run it?

Difficulty: the only hardware I own is my desktop that runs a custom Linux.


You aren't in the target audience; normal people who make up mainstream society.


What does that have to do with Signal's dependency on a mobile number? Signal is not an option for everyone, while other tools that use a less myopic design don't have that restriction.

If the goal is to fight passive surveillance, it's a bad idea to artificially exclude minority groups. Cell phones may be popular, but they are not universal.


I'm not moxie, but that is his stated goal; the majority not everyone. Especially not people who have heard of OpenPGP.



> The fact that Signal exists, and I can use it every day with friends and coworkers, is evidence that we are not locked in.

???? This does not even start to make sense to me. The fact you could chat with your friends on ICQ/MSN/FacebookChat/Compuserve/AIM/Yahoo! IM/Prodigy meant you were not locked in?


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...


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


> 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.


In general I agree with @moxie's arguments, however I've come to to be wary at his condescending attitude and discontent towards people disagreeing with his choices.

Like there's a review on the Android Signal app complaining that it asks for too many permissions, and it does ask for an arm, a leg and your soul, with the reply being unprofessional imho. I understand that this is open-source, but if you publish it and want users, you need to act professional, otherwise it shouldn't be a surprise when people complain.

To the subject at hand, I strongly disagree.

Moxie says that email is frozen, being why it is unencrypted, blaming the lack of progress on it being federated. But you know, I'm willing to bet that in 10 years from now WhatsApp and Slack will be both dead, just like Yahoo Messenger and ICQ before them, while email and IRC will still be around.

And I think that email is unbeatable, because it is federated, because it's governed by standards and because in spite of all constraints, it's quite adaptable, being the kind of platform supporting short term proprietary solutions because (and not in spite of) its client/server decoupling.

Slack for us is just a long and one dimensional stream of greetings, jokes, warnings and meaningless blabbering. Email on the other hand is the archive of everything we do, being the Git of our interactions and the primary channel for knowledge dissemination.

Is it unencrypted? Sure, but it doesn't matter though. Because we are willingly trading that for a capable search engine and a good web interface. Trade secrets aren't communicated over email anyway.

I think Moxie is missing the point. He's emulating WhatsApp, but you can't beat WhatsApp at their own game. Did WhatsApp really deliver encryption to 1 billion users? Well, those are 1 billion users that probably won't use Signal or chat with Signal users. Oops.


I think you're really missing the point here.

> Moxie says that email is frozen, being why it is unencrypted, blaming the lack of progress on it being federated. But you know, I'm willing to bet that in 10 years from now WhatsApp and Slack will be both dead, just like Yahoo Messenger and ICQ before them, while email and IRC will still be around.

Yes, and email will still be unencrypted, while the WhatsApps and Slacks of the future will probably be encrypted end-to-end.

> And I think that email is unbeatable, because it is federated, because it's governed by standards and because in spite of all constraints, it's quite adaptable, being the kind of platform supporting short term proprietary solutions because (and not in spite of) its client/server decoupling.

It's not adaptable enough to introduce meaningful encryption to it.


Slack isn't encrypted and it doesn't make sense to pretend that it is. Introducing encryption is actually difficult for them, since they rely on a web interface connecting to a central server.

But anyway, email can support encryption if you want it, not by one, but two protocols. Email is actually the main channel that journalists and businesses are using for communicating actual secrets over the wire. It's actually the only generally available "meaningful" channel, because even with WhatsApp's encryption, you still can't fully trust a binary blob communicating with a proprietary server, not without the ability to do third-party reviews.

You can do S/MIME, which is encryption with certificates released by an authority (just like HTTPS), or you can do PGP/GPG which is more decentralized, putting the onus of establishing a chain of trust on you. S/MIME is supported out of the box in most email clients and setting up GPG in something like Thunderbird is actually not that hard: https://support.mozilla.org/en-US/kb/digitally-signing-and-e... ; And even for web interfaces there's this browser extension called Mailvelope that's pretty cool: https://www.mailvelope.com/

You see, email does support encryption, just not by default. And the reason for why encryption isn't popular with email is because people don't freaking care.

And the often dreaded protocol that Moxie usually speaks against is XMPP. XMPP apparently isn't good for delivering push notifications on mobile phones, but it does supports easy to use encryption. It's called OTR: http://wiki.xmpp.org/web/OTR ; Oh, and there are is of course an open-source Jabber / XMPP client for Android and it does support OTR, working quite well actually: https://play.google.com/store/apps/details?id=eu.siacs.conve...

You see, WhatsApp's progress is extraordinary, but only because of popularity, because they delivered encryption to people that don't care. Which is quite a feat, except that with another update they can also revert all of that, without users being able to do anything about it. And WhatsApp's progress is not extraordinary for its technical challenges.


> Slack isn't encrypted and it doesn't make sense to pretend that it is.

I didn't say it was.

> But anyway, email can support encryption if you want it, not by one, but two protocols. Email is actually the main channel that journalists and businesses are using for communicating actual secrets over the wire.

Yes, but they're using GPG over email. Another example of a nesting protocols approach are plugins that support OTR over XMPP. Nesting protocols is a valid approach for technical users, but the user experience is such that it will never catch on with non-technical users. And, in context, providing e2e encryption that non-technical users will use is a big part of moxie's goals.

S/MIME can't be deployed meaningfully because major webmail providers will never support it; data-mining email is a huge part of their business model.

So no, email does not support encryption.

> And the reason for why encryption isn't popular with email is because people don't freaking care.

Nobody cares about encryption in the abstract, but a great many people care about privacy. Many people who care about privacy simply don't have the technical knowledge to know what encryption they need and use it, and can't give up the communication that email/chat/etc give them. My dad, who has trouble bolding text in Word, learned how to use Signal because he cares about encryption.


> And I think that email is unbeatable, because it is federated, because it's governed by standards and because in spite of all constraints, it's quite adaptable, being the kind of platform supporting short term proprietary solutions because (and not in spite of) its client/server decoupling.

E-mail's biggest problem is that many, many, many people get it wrong either through configuration snafus or a holier-than-thou approach to how it talks to other servers. It's a miracle that it has managed to function as well as it has; and has done so only only out of sheer necessity.

The problems that e-mail face are the problems that Moxie doesn't want to deal with. If other people want to go for a protocol that has interoperability that's fine, but he wants no part in it. He has no obligation to provide a service to clients he doesn't want connecting and he's right to demand that those who use "Signal" in their name cease its use so to not confuse their attempts with his own.

We already saw a revolt when Signal (when it was known as "TextSecure") went away from its SMS model to a client-server one, leading to a version that still relies on SMS. The point of switching away was to further remove metadata that otherwise would have become exposed. This demonstrates that the type of people who want to go against Moxie's wishes are the type that are to get this implemented incorrectly.

> Is it unencrypted? Sure, but it doesn't matter though. Because we are willingly trading that for a capable search engine and a good web interface. Trade secrets aren't communicated over email anyway.

Your username should be enough to tell you that trade secrets are traded over e-mail routinely.

A multitude of inappropriate material that should not be shared via e-mail is done so on a regular basis. If you work at any company that has credit card numbers being used for either expenses or customer details, you'll quickly find that with a search for 16-digit strings within e-mails will give results.

The problem you're neglecting to acknowledge here is that data at rest can be left unencrypted but overall has no business being unencrypted when in transit. If data from party A is meant for party B (and C, D, E, F, and so on) then any party that is not involved has no business knowing about its contents other than where it is destined to--and even that is questionable.

Those who favour convenience over security are part of a huge problem that faces the Internet.

> I think Moxie is missing the point. He's emulating WhatsApp, but you can't beat WhatsApp at their own game. Did WhatsApp really deliver encryption to 1 billion users? Well, those are 1 billion users that probably won't use Signal or chat with Signal users. Oops.

Moxie isn't trying to beat WhatsApp at its game; he in fact went and improved it by incorporating aspects of Signal into it [1]. Signal is meant to be something else and not something to directly compete with WhatsApp on. Signal and WhatsApp cater to different groups and markets.

[1] https://whispersystems.org/blog/whatsapp-complete/


First of all, I really respect Moxie's choices and am very grateful for his work. What he wants to do, it's entirely his choice. Never meant to imply otherwise.

> Those who favour convenience over security are part of a huge problem that faces the Internet.

I'm not necessarily in favor of convenience, the problem is I cannot trust a binary blob communicating with a proprietary server, even if I can trust some of the people that worked on it, at least for now. I cannot trust something like WhatsApp. Signal I can trust, because at least it is open-source and up for review, but Signal will not succeed in being popular. At least not when it makes the same design choices. You say they cater to different markets, but I don't see a difference. For example Signal considers the phone number as being the username, just as WhatsApp.

Hence I end up carrying more about freedom than security. When I changed my email provider from Google Apps to FastMail, nobody noticed and I value that a lot.

> If you work at any company that has credit card numbers being used for either expenses or customer details, you'll quickly find that with a search for 16-digit strings within e-mails will give results

That may happen, but we've got strict policies in place. Nothing over email is communicated that's more important than source code. And given that source code lives in a Git repository provided by a public service, it would be ridiculous to do encrypted email, but not have behind-the-vpn on-premises Git repositories. And I know mistakes are made, etc. I still want federation more than I want end-to-end encryption.


Some relevant background information on this issue:

https://github.com/LibreSignal/LibreSignal/issues/37


This is Tocqueville applied to open source: “That is why the desire for equality always becomes more insatiable as equality is greater”.

Making Signal open source is not enough; now they want to constrain Moxie in doing something he doesn’t want to do. As predicted by Tocqueville, this is the moment when the desire for equality gets in the way of liberty.


Interesting discussion.


I don't understand how Guardian were unable to obtain a license to use Signal/Axolotl in Chatsecure. The libraries on Github are GPL3, is there some missing IP I'm not aware of?

Also it saddens me that LibreSignal is effectively dead now, along with any future third-party clients. I think forking the Signal server and (later) adding federation could spark a community of free and secure messenger apps for the 21st century.

Even if that means starting with an empty user base. After all, most of my contacts with Signal only ever use it to contact me, it wouldn't be difficult to convince them to change app.


This is probably what made me double-take the most.

I don't understand why Guardian were denied permission to use the code. Sure, OWS aren't under any obligation to, but it doesn't really feel like it's in the spirit of openness at all.

The code might be 'open source', but it's neither free as in user freedom or beer, unless you're giving Facebook or Google your metadata now.

If the code can't be reused, it's pretty hard for users to move to something else. Unless that something else is totally starting over again from scratch.

It just feels weird that because of the Apple situation, in this case the GPL appears to work directly against user freedom.

I think a lot of people have been taken by surprise by that, to discover the platform is not what they thought it was.


Apple imposes usage rules on software downloaded from the App Store. The GPL doesn't allow this, so Open Whisper Systems would have to offer different terms.


Definitely. The background convinced me even more that the essay really makes sense.


I would like to point to a very similar piece that was written about infrastructure for open science [0]. The basic argument is along similar lines, but adds another important wrinkle, which is that in federated systems centralization will eventually arise and often it will be controlled by people and organizations that the federated community do not trust and cannot control (Elsevier being the example in the scholarly world). It is often better to spend time building lasting open institutions that have principles that are in line with the values of the community and are federated at the social level rather than the technical level. Politics matters, and despite how much we might like to avoid it, sometimes we can use it to our advantage.

0. http://cameronneylon.net/blog/principles-for-open-scholarly-...


That's one of the most depressing things I've read in a while. If this is actually true, the internet has failed.


Just because it's not super simple doesn't mean we should treat federation as a dead end. Sandstorm is one way for non-admins to have their own server and there's work regarding self-hosting everything. It's unsexy, it's not a money maker like a centralized messenger, but unless we want to live in a world where there's only one or two centralized messaging solutions, we as developers have to eat our own dog food and improve easy hosting and federation.


How would apps running on Sandstorm avoid the problems with federation in today's world outlined in the blog post?


It looks to me like your article is really arguing for central control of the code, rather than central control of the serving infrastructure. Having everyone running the same code means changes can be made quickly because only one implementation needs to change. Centralized serving infrastructure makes central control of the code easy.

But if you look at mobile, we have central control of the code there without central control of the infrastructure: everyone has their own phone, yet runs the same apps that stay up-to-date via app stores.

Sandstorm is basically taking that model to servers: within 24 hours of an app update, everyone gets a notification and can click one button to update their copy, so everyone tends to stay up-to-date.

(Disclosure: I'm the lead developer of Sandstorm.)


> central control of the code

That's just an excuse to not implement backwards compatibility in the protocol. Central control is also a security risk, as we've seen recently with Apple and the FBI. If the code is controlled centrally, the FBI (or whomever) only has to strong-arm one target.

> gets a notification and can click one button to update their copy

That sounds like you're trying to keep the user in control, which is great. I haven't head of Sandstorm before, but it sounds interesting.

Have you considered the problem of forced updates? I'm not sure there is a good way to protect against the FBI trying something similar to the recent drama with Apple, where they order you to force a "special" update on {someone,everyone}.


There's certainly a trade-off here. I think that making updates as frictionless as possible is overall a big win for security and development velocity. The down side is, of course, that malicious updates take effect more quickly.

FWIW, Sandstorm is already designed to limit the possible damage from malicious apps in general, by making sure each app has only the minimum privileges it needs to do its job (and making sure the UX to grant said privileges is painless for the user). For example, we've seen quite a few security vulnerabilities in apps that were largely mitigated when running the app on Sandstorm:

https://docs.sandstorm.io/en/latest/using/security-non-event...

Hypothetically, in the Sandstorm model, you could architect a messaging app which is incapable of leaking messages to a third party: for each contact, you would create a separate grain (fine-grained instance, in Sandstorm terminology) of the app, and you would permit that grain to communicate only with that contact's corresponding grain they created for you. If the app cannot communicate with other grains of itself -- much less third parties -- then it cannot leak any communications.

Obviously, there are a lot of UX questions raised by this design. It is a goal of the Sandstorm project to solve those UX issues, and we believe they are solvable, but I can't claim to have all the answers today. More likely what you'd run today is a single grain which can talk to all your contacts. In this case an evil app update could almost certainly find a way to covertly leak any message through the network of contacts.

(And, of course, another issue, if communications are crossing the internet, is traffic analysis and covert channels embedded therein.)

So, yeah, there may or may not be a good technical solution here. But on the bright side, the Apple-FBI case seems to indicate that the government doesn't have the power to compel false signatures on code updates. I can only hope that interpretation stands and is reinforced over time.


Stuff like sandstorm is a massive leap towards practical federation, but it came about 10 years late into the conversation. Not that it doesn't still hold great promise (I'm a huge fan, and 100% target demo), but that span of time has allowed us to see this same dynamic play out in enough software spaces that it's a sound observation and rationale for guiding your business or project.

When something like sandstorm can hide even the abstraction of server maintenance, and either: 1) Creating a service is background to account creation. Like say a private hosted sync point (choose your own host) is created when you install the application. 2) I can deploy via an account or "brand" I have established loyalty with, but maintain true portability.

These are new conversations, not possible before.


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.


This is very confusing and the argument don't hold very much. It looks sadly more like a justification against making the effort, which he has a right to not want to attempt, but doesn't make sense.

The real issue is how can we have an open governance model that moves protocol forward a lot faster and it seems that with a little imagination we could tackle most of the pain points. So maybe we should fix the infrastructure instead of celebrating silos that don't talk to each other even when using the same protocols?


> An open source infrastructure for a centralized network now provides almost the same level of control as federated protocols, without giving up the ability to adapt.

That's simply not true. Unless you're Google/Facebook/Apple/Amazon, you'll be unable to get anyone to use your centralized network. Which makes it worse than useless. "Build it and they will come" doesn't work in a world of walled gardens, curated content and censorship.


I think I read this in The Mythical Man Month but writing from memory: Every software development project, no matter how well executed will produce outdated software. Said differently any software that is used is by definition outdated. This is simply, because unknown unknowns only become known unknowns during development.

Bitcoin is a perfect example of this. It might stick around for a while mainly because so many people are already invested in it, but when it comes to features Ethereum runs circles around Bitcoin. On the other hand Ethereum will probably never be fully finished.


Well, Ethereum features a turing complete scripting system and a ton of tools to make use of it, but it doesn't solve Bitcoins most serious problems, and is in fact worse off for most of them.

Miner centralization is a huge problem for Bitcoin. The fact that 11 entities control >90% of the hashrate, and that 2 control >50% of the hashrate is a huge issue for Bitcoin. The pressures we understand to be causing this are more significant in Ethereum at scale. Ethereum is not even at scale and already is doing worse than Bitcoin in terms of hashrate centralization.

Ethereum also has significant scalability problems. Bitcoin struggles to hit 4 transactions per second, and every transaction on Ethereum is substantially heavier per transaction than Bitcoin. That scripting system is not free, and already Ethereum is 20% as heavy as Bitcoin despite being 1/5th the age and having 1/10th the usage. And that's before the fancy apps like Augur have gained traction. Augur is significantly heavier than anything running today, and it's definitely not the heaviest app that people have gotten excited about.

And the development is almost fully centralized. The current state of Ethereum is that what Vitalik says is what will happen, and while there are people who could shut him down... they won't. At least not in the near future. Ethereum has already performed hardforks and has several more planned.

I agree that Bitcoin has taught us a lot of lessons that have paved the way for its obsolecense. But I don't think that Ethereum learned them, and I think that Ethereum will seem a lot less attractive after it has to deal with demand matching what is currently demanded from Bitcoin.

I would almost go as far as saying they are orthogonal products. Bitcoin, above all else, prioritizes decentralization. Ethereum prioritizes features and flexibility, at the cost of scalability and centralization.


> 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).


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. For something so fundamental as how we communicate over the internet that's incredibly important. I want to be able to use the app I want without having to figure out if the other person is using the same app, and i don't want to have to have 10 different apps on my phone just to keep in touch with everyone.

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. It's true that currently a lot of the email traffic is going through google, that sucks, but:

- If google discontinues gmail then your email still works, people can still talk to you. It's annoying you need to get the new addresses for all your contacts that used to use gmail, but that will get resolved quickly enough.

- A day may very well come where people decide another service is better, but then people are free to move there without having to try and convince all their friends and family to also switch. (Take browsers, for example, the browser that everyone uses to access the internet changes over time. And its great! People use what they want to use, the servers don't care, everything just works ─ well, more or less).

Not everything needs to be federated, often there are situations where its advantageous for there to be a central authority. (The blog post highlights a few of those situations). That's also great! People who want those things are then free to choose to use those things as well. Using 2 apps you want to use is still better than 10 you don't want to use.

Federation is hard, and it imposes constraints, but I really, really hope that we can build something that works before we give up and hand over all our comms to a particular company.

This is exactly why I work at matrix.org; I just want to be able to use the clients I want without having to care what everyone else uses. I don't even have to care if matrix.org goes down (except the fact I have to fix it), I can happily talk to other people since I connect via my own server.

I do actually agree with a lot of what's said, I just disagree with the conclusion. Federation iss hard, but it's just so worth it if we can get right.


> The major upside (for me) to federated systems is simple: choice. Choice over the client you use. Choice over the servers you use. Choice. For something so fundamental as how we communicate over the internet that's incredibly important. I want to be able to use the app I want without having to figure out if the other person is using the same app, and i don't want to have to have 10 different apps on my phone just to keep in touch with everyone.

Isn't that exactly the point of the post? If you have lots of choices, what you end up using depends on the intersection of features that your client and the client of the person you communicate with can handle. Which usually ends up advancing slowly, if at all. I'm still a user of XMPP and maybe there is a way to do video chats. But I don't bother trying to set that up as I don't expect it to ever work reliably: I just checked five random contacts and everyone of them uses a different jabber client. So what I end up doing is using XMPP for text chat on my desktop machine and skype/hangout if I need video conferencing.

Same with email. Apart from a bunch of anti spam headers, emails I receive basically look the same they did 10 or 20 years ago. Trying to implement accessible end-to-end crypto probably won't happen for the same reasons.


And yet the Matrix team is doing it remarkably well.

I've been a user of Matrix for going on a year now, and they continue to roll out updates and improvements, over ALL of their platforms -- I use the android, iPad, and desktop/web apps every single day. They're also a federated service. Several of my friends run their own servers.

Some days there's a little bar across the top of my page on the desktop client that says "refresh to update your experience!" and I do. My experience updates. Everything continues to work.

Matrix has done such a good job making it easy to roll out updates that people... do.

And I can't tell you how thrilled I am to be living in a federated world. You just can't compare this to e.g. Slack. I can get friends from all backgrounds on the same system because it's so open.

The Matrix team is proof by example that federation and rapid forward motion is possible.


There’s middle ground between the extremely loose coordination of XMPP and one client, one server, one network.

Open Whisper Systems pays people to work on Signal. A major reason XMPP video chat never took off is that no popular Windows client supported it. What if the XMPP Software Foundation had funded that work?


> 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.


With Signal you cannot even choose a repository from which to download its client. You either give your credentials to Google, or you are out of luck.


Are we super sure about this premise: a vendor builds a centralized solution on top of (or evolved from) a federated protocol in order to be able to adapt with speed to a moving environment?

For instance, I am not so sure that is the reason Whatsapp built a custom XMPP.

I am more inclined to think that decentralized-anything is basically impossible to monetize so companies thinking for-profit will always chose the centralized walled garden.


I'm writing from the perspective of Signal, which is not a business, so it's definitely not about monetizing users for us.


It would be interesting to know how you do see Signal, then.

After reading your comments on the LibreSignal tracker, my impression was that you are very much writing with your business hat on, as you are framing alternative clients as "products" and trying to protect the Signal brand, as well as preventing third-party clients from using your service - all typical business moves.

I can see how federation breaks the phone-number-based identity and discoverability, so I accept your position in that regard.

However, opening up the service to community-developed clients would be A Good Thing. You have to maintain backward compatibility to a certain degree for the official client anyway. If community clients fail to roll out a new protocol version, it will be a valid move to lock them out together with outdated official installations. You wrote that maintaining servers is difficult, but I am sure that it is possible to find a scheme where your additional financial burden of accepting (but not providing support for) third-party clients is compensated for.


Good to hear that's remained the case @moxie.


The term "federation" has been overused, misused and abused. At it's base layer, Federation can be thought of as process that unifies things and the people using the things in a way that is reproducible at a future date. Within the context of the Internet and Software (the cloud), Federation should mean "federated use of computer resources" and extend the three primitives of the cloud to be used by all, at will:

1. Compute - allows the transformation of one type of data to another.

2. Storage - allows the storage of data.

3. Network - allows the transfer of data from compute to storage, or vice versa.

Federation's historic constituents have been standards, payments and identity. In order for cloud federation to be viable, the primitives above must be able to be used in a way that allows some type of "standardized trust" to be applied, some type of identity to be associated with it, and some way of paying for the resources used.

One possible solution for implementing a Federated Cloud of Clouds is to use cryptocurrencies to pay for the processing of data, identify who's data it might be, and then encapsulate the data being federated into some type of standard. I have explored a generalized solution for this and have presented it to a few peers. It seems doable, if we can mobilize the development community's intent to change how software is written.

BTW, I don't consider "standards" to be anything other than a light consensus mechanism applied to a set of data which is then made immutable. One might consider a blockchain a "standard" by the evidence it is unchanging, once created.

Federation will only occur once we've moved infrastructure to using cryptocurrencies for deployments. It will also require a radical shift in the way we think about how software is written and paid for.


No users, no walled garden. More users, more walled garden. Is this just the natural state of systems that require/acquire network effects?


I have a universal theory about this which is "spam and abuse make everything suck".

This is why we can't have an open libertarian Internet, and instead have walled gardens and moderated forums - ordinary users don't want to deal with the crap.

It's also why we don't have open API's, and why the API's that the big providers do give us tend to be nerfed and then discontinued - they're constantly abused, which imposes a maintenance cost that businesses have to justify.

It's why an email server is so difficult to run and email delivery is so unreliable. It's why you can't (or shouldn't) rely too much on Paypal. It's why governments effectively outsource Internet policing to big providers.

And so on.


Not necessarily. Microsoft kept trying to make a walled garden around the web. They might have had a lot of users, but the web fought back and luckily today we have 'world wide web', not a totally isolated Microsoft Web, Google Web, Apple Web, Firefox Web etc.

I hated the days when you constantly had to switch web browsers to get pages to render. I'm glad it's rare now, because we didn't give up on the hope of open systems.

Mark might have lost the battle to have HTTP/2 encrypted by default, but at least when Let's Encrypt came out, it still worked in all browsers.

Would we have been better to just give up and have lots of walled gardens instead? I don't think so. I'm glad we have WWW.

Personally I don't think XMPP failed because being open made it slow to adapt. I think we're mostly stuck because ICQ, AOL & MSN just got there first.

I don't envy being in Moxie & OWS's position of figuring out how to make this work. I'll add opinion and some of it harsh, though I'll reserve criticism until I've built something as awesomely globally deployed as Signal.


Nonsense, the www is not stuck in the 90's. Browsers adapt, compete and innovate. And err http is at 2.0. The fact that gopher didn't kick off does not rubbish the idea of common protocols in the first place.


HTTP is used for far more than just browsers. how broad is the current adoption of HTTP 2.0? Will there ever be a time when all HTTP clients, servers, proxies, etc will have upgraded to 2.0 - clearly that's never going to happen in the foreseeable future so we're stuck in a mishmash of supporting HTTP 1.x and HTTP 2.x clients and server software indefinitely - similar to XMPP extensions the article refers to. It's obviously much faster to innovate and update all clients when you have control over a centralized network and auto-updating clients.


What's more, HTTP's recent movement is arguably only because the web experience has centralized so much around Google.

Google already had the top two most popular websites in the world, so once Google Chrome also became the most popular web client, it was easy for them to develop a new communication protocol of their own, which everyone else has more or less begrudgingly agreed to call HTTP/2 and start deploying as well.


Google did not write the HTTP/2 spec.

While Roberto Peon is one of the authors (and a core developer of the preceding SPDY protocol) saying that HTTP/2 is some Google invention is a bit of a punch in the face to the IETF and the two other authors who do not work at Google.


So what? Many standards originated from some particular need of one or two companies popular at that time. Look at the current IETF WGs and the authors of the drafts they produce.


I'm largely sympathetic to Moxie's core arguments, and to the extent that I disagree, it's his prerogative to do what he thinks is best with his project.

I will point out that some people are using "federated" and "decentralized" as synonyms, when they are distinct concepts. The Tor network, for example, is decentralized, but not federated. You can run your own Tor node, but that node has to be accepted by the directory authorities in order to become a part of the network. You could conceivably set up your own Tor network, with your own directory authorities, but of course you can also create your own alternative network with Signal, since both the client and server code are free software.

Ricochet, the messenger that uses client-side Tor hidden services to create server-less chat, is also decentralized, but not federated. Ricochet clients talk to other Ricochet clients. There is not IETF RFC out there for Tor or Ricochet, that you can use to build your own implementation and federate into the network.

Moxie's claim that federation inevitably leads to moribund cruft may be over-stated; after all, http is not exactly in trouble. Nevertheless, I think that it's probably true that maintaining a federated protocol that is also an easy, seamless, user-facing piece of software is most likely a tall order.


I think his view on the address book as your personal social graph is interesting. Because this has been mainly discussed as privacy violation because it involves uploading the address book to a server to check for in-network users.

But it has also another side and sadly this side as an independent social graph is mostly ignored, at least in Germany.

How is this being discussed in other places? I had this discussion when WhatsApp turned on full end to end encryption.


Moxie: there's a third alternative to centralization and federation which nobody is talking about on this thread: P2P. I'd be interested to hear your thoughts on what pitfalls someone (me) might encounter trying to implement a peer-based messaging system. I've got a lot of learning to do before I feel qualified to actually write code for such a project, but it's something I'm actively working toward.


If federation is too hard then I don't think P2P, which is even harder, will be considered.


It's harder to deploy updatable encryption on a federated protocol than a centralized one, but as I see it, the difficulties are social rather than technical. Deploying updatable, usable encryption on P2P is technically more difficult than on federation or centralization, but I'm not convinced it's socially more difficult.

The core problem of updating federated systems is that big players can choose not to play. If Google or Yahoo decide not to support a change to email, the change is dead in the water. This isn't just hard, it's intractable.

But with P2P systems, non-reliance on peers doing anything in particular is built-in. For example, peers that don't support a change limit the size of the swarm you can peer with, but they don't inherently break the feature as long as there are some peers who support the change. Many Bittorrent clients support encryption and many don't, many bitcoin miners support alternate protocols to speed up pooled mining, and many don't.

I don't know what the implications of this would be for a system like Signal. It maybe that it doesn't solve anything; I'm just not ready to conclude that for myself yet and I'd be interested to hear Moxie's take.


So: I was the other side of the email conversation that Moxie alludes to in this post, so I'll respond to it here given comments are disabled on the OWS blog :)

1. Totally agreed that federation slows down evolution of the core protocol. However, higher level protocols do NOT have to be stuck in time forever in the manner of SMTP if you design them with a migration/evolution strategy from the outset. For instance, with Matrix.org the core premise is decentralising communication between different networks. This includes different versions of Matrix itself. We could build an entirely new Matrix 2.0 tomorrow, using (say) a fully p2p WebRTC Datachannel transport or IPFS or whatever rather than today's HTTP APIs... and simply bridge it into the existing Matrix network using Matrix's existing bridging architecture. In fact, one of our favourite thought experiments is the process of how to evolve Matrix into a full e2e-and-metadata-privacy-protecting protocol at some point in future - as per http://matrix.org/~matthew/2015-06-26%20Matrix%20Jardin%20En.... How you protect metadata privacy if locked to a single centralised service like Signal is perhaps questionable.

We believe that avoiding being dependent on any single communication provider is just as important to user freedom as maintaining communication privacy. If I don't trust Signal to host my communication reliably, I want to pick my own provider... whilst still being able to talk to other Signal users.

One could argue that end-to-end encryption is incompatible with federation, as if a vulnerability is found in the encryption ratchet you need the power to upgrade the world 'instantly', as WhatsApp or whoever can. However, I am not convinced this is a showstopper. It's certainly convenient that WhatsApp can instantly lock out all versions of an app which are known to contain a vulnerability from their network, but you can get a similar effect by issuing a press release as per heardbleed, poodle etc; giving users a way to check if they're vulnerable; encouraging them to move to a provider or app which is not vulnerable. It's not watertight, but it's a compromise I think many would be willing to make in exchange for having the freedom to select their communication provider and communicate with who they choose.

2. If the federated protocol has well-defined layers, it's not even a problem if the lower layers are slow and hard to evolve; you just go and swap out the higher layer ones. Internet Protocol is so widely deployed it's infamously painful to evolve... but it's a relatively simple and well-focused problem domain, so a huge migration like ipv4->ipv6 happens very rarely. But it hasn't materially slowed down the adoption and uptake of the internet - in fact, ipv4 is a victim of its own success! Meanwhile, HTTP is also so widely deployed that it's a relatively slow process to do something like HTTP/1.x->HTTP/2. But, again, it turns out this isn't remotely a showstopping problem - most of the interesting stuff happens layered as applications on top of HTTP - HTTP does one thing, and does it relatively well, so it's a great building block. And it's the basis of the entirely open and interoperable architecture of the web.

With Matrix, we're trying to provide a similarly simple and focused base layer: a decentralised pubsub/storage API layered on HTTP. We provide some modules that define additional semantics (messaging, VoIP etc) as layers on top of that core API (http://matrix.org/docs/spec/client_server/r0.1.0.html#module...) which can evolve separately.

We believe that having an open and interoperable protocol for securely synchronising data in realtime is as fundamental as the web itself, and this is NOT a function that should be silo'd into any provider.

3. The blog post says: "One of the controversial things we did with Signal early on was to build it as an unfederated service.". This seems a bit strange, given the TextSecure server itself exposes a basic federation API: https://github.com/WhisperSystems/TextSecure-Server/tree/mas...

4. My actual retort wasn't to tell Moxie that he's dumb - he's obviously an incredibly smart guy, even if I disagree with his position here. I actually said: "Okay. The internet wouldn't have got very far without interoperable application-layer protocols defined by 3rd parties, but if you would only ever consider using one for TextSecure that you invented yourself, that's your call :)"

So, if anyone's reading this and still believes in the dream of an interoperable and federated internet, feel free to come hang out at https://matrix.to/#/#matrix:matrix.org and live the dream :)


> If I don't trust Signal to host my communication reliably, I want to pick my own provider... whilst still being able to talk to other Signal users.

I couldn't agree more. And it's not just a matter of trusting the host. It's a matter of trusting and liking the clients. If e-mail were hotmail only, I'd hate it. But it's not. E-mail is thousands of clients on dozens of operating systems, which can all talk to each other. Signal, hah, it doesn't even work on my phone, and there aren't even dozens of phone operating systems out there.


Let me summarize. "We want to make sure we make money."

Let's burn these star networks!


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.


what Facebook did with email

What did Facebook do with email?


Bloody murder, basically.

Whenever I try to communicate with someone under 30, e-mail is simply not an option. A Facebook message is often the only way (or worse).


Made it obsolete, didn't you hear?


There's a sort of resignation about the tone here, both in the article and the comments, which is very depressing.

Let's take that punch, roll with it, and redirect its energy. If centralized efforts, much like BDFLs, are looking like a good option for development cycles, okay. How can we wield that knowledge, but also build lifecycles around it that can help us buy back the powers and critical freedoms of federated systems?


Every security engineer I have met so far is to some extent (some of the to quite an extent) paranoid and control-freak. That's good for security engineers, you want them to be paranoid and control freaks. Of course, the bad part is that they are paranoid and control-freaks.

So, although I don't question huge amount of work brought to the public for free by Moxie, I cannot notice that he killed all points of federation (even those which were to some extent under his control, http://www.cyanogenmod.org/blog/whisperpush-end-of-life), that he sabotages non-Google-controlled repositories (https://github.com/WhisperSystems/Signal-Android/issues/127) of his so called open software client. I don't care that much because for this and other reasons I won't touch Signal with a ten-feet pole, and federated alternatives (XMPP) work for me just fine, thank you. So, my suspicion is that instead of some theoretical difficulties the issue is that he got how own fiefdom under his control, and now he is not willing to let it go.

All these opponents of federation and open software (I am not talking about just FLOSS here, I mean truly community-drive software), each with their fiefdoms to protect, argue that we are stuck with the open technologies from 1990s (or even earlier), and only their proprietary silo (proprietary meaning with only one implementation and under their control) is able to bring us a shiny new blink. However, they tend to ignore the other part of the story. The biggest problem of storing my life in proprietary silos is not that they are under control, I don’t live a life in delusion of importance, so I don’t expect anybody to mine my communication with my wife about what to do for dinner (and yet, even that communication is encrypted by a pretty good encryption system, which works just fine with a plain XMPP). The biggest problem is that every individual proprietary silos in the moment owner of such silo goes out of business, or for some other reasons looses interest in providing the service. So, the question is not how many technologies from 1990s we use, but how many proprietary technologies from 1990s we don't use. Yes, I have stored on my hard drive all emails since 1997, because old boring mbox files still work as they did. But all those exciting and sometimes tearful conversations I had on Yahoo! IM or ICQ are gone forever. That bigfoot.com and mail.com accounts I had for my life? Yeah.

And to the second lie Moxies lies to himself (I am willing to believe he really means it). It is suddenly easy to move between proprietary silos? Yeah. It is lovely that we have to keep unique identifier (phone number) for all NSAs to trace us in some weird databases somewhere (that livejournal.com account? yes, it is now owned by the Russian Коммерса́нтъ; yes, I know that this newspaper is not that bad). And yes, it is seriously interesting if perhaps phone numbers would serve as the unique personal identifier most Americans were so afraid to introduce. A possibility to have anonymous accounts? Yeah.

However, even this does not seem to make transfer between platforms that easy. If all your friends are on Telegram, then no matter how easy for whole group it would be easy to transfer, you cannot transfer unless whole group does. How many people really and truly love Twitter, and how many of those who hate it with passion are able to move to some better platform? Nobody, because that is where people are.


Perhaps the "federation" that should evolve is not federation of the servers behind a single protocol or app, but federation between multiple apps. Applying the traditional definition of "federation" to Signal implies that any entity could host a Signal server, and any Signal client could talk to that server. Moxie mentions the main issue with this, namely that because of the "evolving ecosystem," it's impossible to keep all servers using the same protocol. Also consider that trust is another significant issue -- can you trust the operator of the Signal server you're connecting to? Can you trust not only that the server software is up to date, but also that no malicious actor has modified it?

Because of these trust issues, the benefits of federation for users are unclear. Why connect to some random Signal server if you feel safer connecting to the official servers?

If the answer to that question is, "because I can connect to my own Signal server, so I don't need to trust anyone," then I posit this question: Do you need permission to build a federated service? Is it possible that federation can evolve without any central planning or permission to do so?

Consider the "messenger wars" of the early 2000s. There was no official "federation" of messaging services, and yet, people built clients that could interoperate with all of them. In fact, Microsoft itself wrote a client that was interoperable with AIM. [0]

Why can't the same sort of "grassroots federation" evolve within the current ecosystem of chat apps? If somebody reverse engineers the whatsapp protocol and builds a "whatsapp server," then modifies the whatsapp binary to talk to it (perhaps using something like theos-jailed [1]) instead of the official servers, isn't that effectively accomplishing unsanctioned federation? Along the same lines, is there anything stopping somebody from reverse engineering Signal to talk to Whatsapp, and vice versa?

The "walled gardens" have made it harder to reverse engineer binaries and protocols, but there is no fundamental impediment to achieving cross-messenger interoperability. If developers are motivated enough to build third party clients, it will always be possible, although the requisite reverse engineering effort grows more complex with every release.

[0] https://nplusonemag.com/issue-19/essays/chat-wars/

[1] https://github.com/BishopFox/theos-jailed


See http://spectrum.im/ with https://github.com/davidgfnet/whatsapp-purple (or use it with pidgin/adium/finch directly).




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: