A long time ago, chat apps actually were decentralized — with XMPP as the common protocol (I’m dating when I got on to the interwebz :-P) That still works btw, and I’m sure there’s a substantial...
A long time ago, chat apps actually were decentralized — with XMPP as the common protocol (I’m dating when I got on to the interwebz :-P) That still works btw, and I’m sure there’s a substantial population using various apps/clients to chat over XMPP.
Google Talk was one the most popular clients, and it so happened that around the turn of the last decade everybody and their uncle got infatuated with “network effects” and “owning captive audiences” on their own walled platforms. So the web giants pivoted to lock down their communication platforms and social networks.
There does seem to be a small but strong push for more decentralized options like ActivityPub and Matrix. Time will tell how successful & widespread they become.
I think that is only part of the story. Network effects and captive audiences are certainly a big part of the business justification for moving away from XMPP, but there is also a big technical...
I think that is only part of the story. Network effects and captive audiences are certainly a big part of the business justification for moving away from XMPP, but there is also a big technical one: It is almost impossible to get everyone to agree on how to bring new features into a widely adopted open standard.
Upgrading XMPP with modern features like rich content, end-to-end encryption, and a number of other features popular in Slack, Discord and WhatsApp would require everyone using the protocol to agree on how they should be implemented. It could break compatibility with existing clients that do not get updated in a timely manner. There will also always be a small but very vocal minority of Luddites who think the existing standard is perfect the way it is and vehemently oppose the adoption of "mainstream" features like these.
There are tradeoffs between interoperability and speed of innovation when talking about closed vs open communication protocols.
This is very true, but keep in mind that there are also people who advocate against the addition of features that require ever more computing power because there are people who do not have access...
There will also always be a small but very vocal minority of Luddites who think the existing standard is perfect the way it is and vehemently oppose the adoption of "mainstream" features like these.
This is very true, but keep in mind that there are also people who advocate against the addition of features that require ever more computing power because there are people who do not have access to more computing power. People in rural areas don't have the bandwidth for live video. People in developing nations may not have always-on connections. There are a number of valid reasons why it can be difficult to retrofit existing standards with newer features. There definitely are people who just want things to never change, too, of course.
I'm not sure I understand what you mean. If I purchase a device or software to communicate with other people, and it works with my device/connection, then the standard is updated to require more...
I'm not sure I understand what you mean. If I purchase a device or software to communicate with other people, and it works with my device/connection, then the standard is updated to require more processing power or bandwidth than I have access to, and every server I use now requires those features, I'm now unable to communicate with my contacts. That seems like a pretty straightforward scenario that doesn't involve self selection.
If someone can't use YouTube because it requires high bandwidth, that's not "self selection out of bandwidth-heavy websites." That's not using websites because they aren't accessible to you. What you've stated is equivalent to saying, "People in wheelchairs self-select out of going to businesses that only have stairs." They didn't "self select." They were forced to choose something different because business owners didn't give them proper consideration.
You can have progressive asset loading (dynamic resolution), and optional asset loading. We're talking about chat apps. If YouTube comments were used for communication (oh god) then you could very...
You can have progressive asset loading (dynamic resolution), and optional asset loading. We're talking about chat apps. If YouTube comments were used for communication (oh god) then you could very easily still communicate with others on a low bandwidth connection by not pressing play on the videos. So if you have a chat app with support for images you can continue to chat with images disabled. Or the images could be streamed up to a certain resolution.
It's more like a person in a wheelchair having friends that like to go hiking. They hang out with their friends most of the time. But not on hikes.
The blue and green bubbles trick only works because SMS is an ancient open standard that cell carriers have no interest in upgrading. If green bubbles didn't come with a downgrade in features,...
The blue and green bubbles trick only works because SMS is an ancient open standard that cell carriers have no interest in upgrading. If green bubbles didn't come with a downgrade in features, people wouldn't actually care.
The blue and green bubbles thing isn't just marketing. It's how a well-designed UI keeps users from being confused by differences in functionality that might not be immediately apparent. It's a...
The blue and green bubbles thing isn't just marketing. It's how a well-designed UI keeps users from being confused by differences in functionality that might not be immediately apparent. It's a way to inform the users that they may not be able to use all features, depending on who they're corresponding with.
This seems like a good way to support ancient standards while also supporting more advanced functionality that hasn't been standardized. The big providers could have done that for XMPP as well as SMS, if it mattered enough to them.
The downside is that you're not treating all users the same. But arguably, people should not be treating their correspondents the same anyway. For example, you need this for accessibility or you'll end up sending an image to a blind person. People aren't all the same and the adult thing to do is to understand and adjust to this.
It's not going to stop some teenagers from being cruel to their "friends" because they have an Android phone, but such people would find another excuse.
An alternative is to make your custom client available on all common platforms, and that's the more usual route taken. So you end up with multiple apps on your phone to communicate on different networks.
The problem here then ends up being 'how does it get paid for'. Facebook and Google put their free messaging clients on every platform, because their revenue comes from selling data they harvest...
An alternative is to make your custom client available on all common platforms, and that's the more usual route taken.
The problem here then ends up being 'how does it get paid for'.
Facebook and Google put their free messaging clients on every platform, because their revenue comes from selling data they harvest through these free services.
Apple only puts their "free" messaging client on their platform, because their revenue comes from users buying into said platform. You pay for iMessage when you buy an iPhone or a MacBook.
They sell ads driven by user data. Go read up on the Cambridge Analytica scandal if you want to see how much information advertisers can learn about you through these advertising platforms. The...
They sell ads driven by user data. Go read up on the Cambridge Analytica scandal if you want to see how much information advertisers can learn about you through these advertising platforms.
The point is, you are paying for the service by giving up your privacy instead of your money.
The Cambridge Analytica hack was due to a bad actor abusing Facebook's API's, against their terms of service. That's not "selling data" either since it didn't happen with Facebook's consent. You...
The Cambridge Analytica hack was due to a bad actor abusing Facebook's API's, against their terms of service. That's not "selling data" either since it didn't happen with Facebook's consent. You could compare it with a rogue app with excessive permissions collecting user data on Android or iPhone.
But there is the question of what's changed since then to prevent it from happening again, and whether that's reasonable. It looks like Facebook tightened up app permissions quite a bit but I don't know if that's sufficient.
I don't know what kind of past you and @petrichor are remembering but XMPP was never the majority standard, it just happened to be the only open source implementation so it found its way to a few...
I don't know what kind of past you and @petrichor are remembering but XMPP was never the majority standard, it just happened to be the only open source implementation so it found its way to a few apps, including Google Talk. But MSN, AIM, YIM, ICQ were all proprietary protocols and all of them were more popular than Google Talk (except maybe ICQ by the time gtalk was around).
Then Google Talk became hangouts, Facebook also dropped all usage of XMPP when they started working on Messenger, and that was it for the open source protocol.
Matrix is indeed the most promising future for open source, decentralized chat applications. It has a long way to go.
So to answer your question, @suspended, chat apps aren't decentralized because of mobile: companies jumped on "solving" chat before open source, stuck on the idea of XMPP which was wholly unsuitable on mobile, could catch up. Neither Facebook nor Google were interested in making a cross-compatible open source solution, and none of the smaller players had the capacity to do so.
Now, Matrix is … complex, but I believe it's getting there. We need more libraries, more clients, more implementations, more of an ecosystem around it in general. We need second-layer implementations, too: Things like, Rails/Django/React/iOS implementations of support and in-app chat solutions built on matrix. And then once that is built, the third layer is tooling: Things that give an innate benefit if your comms implementation uses Matrix. Things like Matrix backends for auth providers, and so on.
This is how email won. This is how HTTP won. You don't think of them as a protocol to implement anymore, they're just there.
I'm in the alpha of Beeper, a Matrix client which uses bridges to connect to a bunch of different networks. I use it daily for Messenger, Whatsapp, Telegram, Hangouts and Signal. It's nice, albeit...
I'm in the alpha of Beeper, a Matrix client which uses bridges to connect to a bunch of different networks. I use it daily for Messenger, Whatsapp, Telegram, Hangouts and Signal. It's nice, albeit full of rough edges still.
The only catch is the monthly fee. Experience has been excellent, it's better than all the other wannabe-pidgin-clones out there. As I said there's a lot of rough edges and bugs still, though....
The only catch is the monthly fee. Experience has been excellent, it's better than all the other wannabe-pidgin-clones out there.
As I said there's a lot of rough edges and bugs still, though. There's also missing features; for example they only recently added voice message support. Voice&Video calls are unavailable. It's also a pretty leaky abstraction: You see beeper bot usernames in various places and what not. It does the job pretty well, but I wouldn't recommend it for someone who isn't an enthusiast yet.
Interoperability isn't really a default state, so the question is somewhat malformed. For services to be interoperable, it means that all these different players have to get together and agree to...
Interoperability isn't really a default state, so the question is somewhat malformed. For services to be interoperable, it means that all these different players have to get together and agree to all to one spec for client to client messages.
There's many reasons why this wouldn't be the case; for one, there needs to be an impetus, otherwise it's a great deal of effort so the service operators wouldn't bother without some gain. There also needs be a convenient vehicle for this consensus to occur - is there a dominant player that can organize everyone? Or is there a 3rd party that everyone can put their trust in? Should a new organization dedicated to maintaining this spec be created?
Secondly, it can hurt product agility. If you want to add a feature, then you either have to make your client a superset of the shared spec (i.e iMessage on top of SMS), or try and herd cats to get all the decision makers to approve your feature for the whole spec. On the other side, you may be forced to implement some feature you don't care about because a peer forced their feature into the spec.
Designing and agreeing on a spec is also hard. Specifically for messaging apps, recently there has been some consensus on using Signal's model for E2EE, but it's only very recently. Designing an encrypted protocol is very hard, very error prone, and also changes fairly frequently (for instance, SSL 2 -> 3 replaced RSA for the key sharing with ephemeral diffie-helman to prevent replay attacks). As E2EE became a desirable trait for the most part the different messaging apps went their own way.
For that matter, email is a laughably poor spec these days in terms of security - you should really treat all email as open communication, and that has been a flaw for decades without much remedy.
It also limits the control you have other your platform - both a good and bad thing. A way this can be bad - take email for example. No one can stop bad actors from spamming you except the client. Because email is an open messaging protocol, anyone can indeed send you any email, and the only recourse you have is on a client level.
Finally, just because a spec exists does not mean that it is truly interoperable. The web is a good example; it is an open spec, but we all know the reality is that Chrome is the de facto target, and any undefined behavior on Chrome is de facto the one you should implement. Webkit (Safari) has a full list of hacks to make sure websites work as expected that you can look at in Github.
Because proprietary platforms are easier to innovate on. Facebook or telegram can roll out any new feature they want and it just works on day one while email is still struggling to standardise...
Because proprietary platforms are easier to innovate on. Facebook or telegram can roll out any new feature they want and it just works on day one while email is still struggling to standardise server to server encryption let alone end to end encryption.
There is also corporate interests at hand but I think the major reason is simply that decentralised systems are 100x harder to build and almost impossible to upgrade.
A long time ago, chat apps actually were decentralized — with XMPP as the common protocol (I’m dating when I got on to the interwebz :-P) That still works btw, and I’m sure there’s a substantial population using various apps/clients to chat over XMPP.
Google Talk was one the most popular clients, and it so happened that around the turn of the last decade everybody and their uncle got infatuated with “network effects” and “owning captive audiences” on their own walled platforms. So the web giants pivoted to lock down their communication platforms and social networks.
There does seem to be a small but strong push for more decentralized options like ActivityPub and Matrix. Time will tell how successful & widespread they become.
I think that is only part of the story. Network effects and captive audiences are certainly a big part of the business justification for moving away from XMPP, but there is also a big technical one: It is almost impossible to get everyone to agree on how to bring new features into a widely adopted open standard.
Upgrading XMPP with modern features like rich content, end-to-end encryption, and a number of other features popular in Slack, Discord and WhatsApp would require everyone using the protocol to agree on how they should be implemented. It could break compatibility with existing clients that do not get updated in a timely manner. There will also always be a small but very vocal minority of Luddites who think the existing standard is perfect the way it is and vehemently oppose the adoption of "mainstream" features like these.
There are tradeoffs between interoperability and speed of innovation when talking about closed vs open communication protocols.
This is very true, but keep in mind that there are also people who advocate against the addition of features that require ever more computing power because there are people who do not have access to more computing power. People in rural areas don't have the bandwidth for live video. People in developing nations may not have always-on connections. There are a number of valid reasons why it can be difficult to retrofit existing standards with newer features. There definitely are people who just want things to never change, too, of course.
We have solutions for those situations in web (including self selection out of bandwidth-heavy websites). Not sure why that is a compelling argument.
I'm not sure I understand what you mean. If I purchase a device or software to communicate with other people, and it works with my device/connection, then the standard is updated to require more processing power or bandwidth than I have access to, and every server I use now requires those features, I'm now unable to communicate with my contacts. That seems like a pretty straightforward scenario that doesn't involve self selection.
If someone can't use YouTube because it requires high bandwidth, that's not "self selection out of bandwidth-heavy websites." That's not using websites because they aren't accessible to you. What you've stated is equivalent to saying, "People in wheelchairs self-select out of going to businesses that only have stairs." They didn't "self select." They were forced to choose something different because business owners didn't give them proper consideration.
You can have progressive asset loading (dynamic resolution), and optional asset loading. We're talking about chat apps. If YouTube comments were used for communication (oh god) then you could very easily still communicate with others on a low bandwidth connection by not pressing play on the videos. So if you have a chat app with support for images you can continue to chat with images disabled. Or the images could be streamed up to a certain resolution.
It's more like a person in a wheelchair having friends that like to go hiking. They hang out with their friends most of the time. But not on hikes.
Either way, the impact is the same; people who want to implement new features get held back by those who do not.
You could do it like Apple Messages did, with blue and green bubbles. That can cause other issues because people are terrible.
The blue and green bubbles trick only works because SMS is an ancient open standard that cell carriers have no interest in upgrading. If green bubbles didn't come with a downgrade in features, people wouldn't actually care.
The blue and green bubbles thing isn't just marketing. It's how a well-designed UI keeps users from being confused by differences in functionality that might not be immediately apparent. It's a way to inform the users that they may not be able to use all features, depending on who they're corresponding with.
This seems like a good way to support ancient standards while also supporting more advanced functionality that hasn't been standardized. The big providers could have done that for XMPP as well as SMS, if it mattered enough to them.
The downside is that you're not treating all users the same. But arguably, people should not be treating their correspondents the same anyway. For example, you need this for accessibility or you'll end up sending an image to a blind person. People aren't all the same and the adult thing to do is to understand and adjust to this.
It's not going to stop some teenagers from being cruel to their "friends" because they have an Android phone, but such people would find another excuse.
An alternative is to make your custom client available on all common platforms, and that's the more usual route taken. So you end up with multiple apps on your phone to communicate on different networks.
The problem here then ends up being 'how does it get paid for'.
Facebook and Google put their free messaging clients on every platform, because their revenue comes from selling data they harvest through these free services.
Apple only puts their "free" messaging client on their platform, because their revenue comes from users buying into said platform. You pay for iMessage when you buy an iPhone or a MacBook.
They don't sell data as far as I know. Where you can you buy data from Google or Facebook? It's not for sale. They do sell ads.
They sell ads driven by user data. Go read up on the Cambridge Analytica scandal if you want to see how much information advertisers can learn about you through these advertising platforms.
The point is, you are paying for the service by giving up your privacy instead of your money.
The Cambridge Analytica hack was due to a bad actor abusing Facebook's API's, against their terms of service. That's not "selling data" either since it didn't happen with Facebook's consent. You could compare it with a rogue app with excessive permissions collecting user data on Android or iPhone.
But there is the question of what's changed since then to prevent it from happening again, and whether that's reasonable. It looks like Facebook tightened up app permissions quite a bit but I don't know if that's sufficient.
I don't know what kind of past you and @petrichor are remembering but XMPP was never the majority standard, it just happened to be the only open source implementation so it found its way to a few apps, including Google Talk. But MSN, AIM, YIM, ICQ were all proprietary protocols and all of them were more popular than Google Talk (except maybe ICQ by the time gtalk was around).
Then Google Talk became hangouts, Facebook also dropped all usage of XMPP when they started working on Messenger, and that was it for the open source protocol.
Matrix is indeed the most promising future for open source, decentralized chat applications. It has a long way to go.
So to answer your question, @suspended, chat apps aren't decentralized because of mobile: companies jumped on "solving" chat before open source, stuck on the idea of XMPP which was wholly unsuitable on mobile, could catch up. Neither Facebook nor Google were interested in making a cross-compatible open source solution, and none of the smaller players had the capacity to do so.
Now, Matrix is … complex, but I believe it's getting there. We need more libraries, more clients, more implementations, more of an ecosystem around it in general. We need second-layer implementations, too: Things like, Rails/Django/React/iOS implementations of support and in-app chat solutions built on matrix. And then once that is built, the third layer is tooling: Things that give an innate benefit if your comms implementation uses Matrix. Things like Matrix backends for auth providers, and so on.
This is how email won. This is how HTTP won. You don't think of them as a protocol to implement anymore, they're just there.
I'm in the alpha of Beeper, a Matrix client which uses bridges to connect to a bunch of different networks. I use it daily for Messenger, Whatsapp, Telegram, Hangouts and Signal. It's nice, albeit full of rough edges still.
This looks so good I'm instantly suspicious. Is there a catch? Also, can you talk a bit more about your experiences with it so far?
The only catch is the monthly fee. Experience has been excellent, it's better than all the other wannabe-pidgin-clones out there.
As I said there's a lot of rough edges and bugs still, though. There's also missing features; for example they only recently added voice message support. Voice&Video calls are unavailable. It's also a pretty leaky abstraction: You see beeper bot usernames in various places and what not. It does the job pretty well, but I wouldn't recommend it for someone who isn't an enthusiast yet.
Thanks! I'll definitely be keeping my eye on this. I can absolutely see myself and others using it once it matures.
Interoperability isn't really a default state, so the question is somewhat malformed. For services to be interoperable, it means that all these different players have to get together and agree to all to one spec for client to client messages.
There's many reasons why this wouldn't be the case; for one, there needs to be an impetus, otherwise it's a great deal of effort so the service operators wouldn't bother without some gain. There also needs be a convenient vehicle for this consensus to occur - is there a dominant player that can organize everyone? Or is there a 3rd party that everyone can put their trust in? Should a new organization dedicated to maintaining this spec be created?
Secondly, it can hurt product agility. If you want to add a feature, then you either have to make your client a superset of the shared spec (i.e iMessage on top of SMS), or try and herd cats to get all the decision makers to approve your feature for the whole spec. On the other side, you may be forced to implement some feature you don't care about because a peer forced their feature into the spec.
Designing and agreeing on a spec is also hard. Specifically for messaging apps, recently there has been some consensus on using Signal's model for E2EE, but it's only very recently. Designing an encrypted protocol is very hard, very error prone, and also changes fairly frequently (for instance, SSL 2 -> 3 replaced RSA for the key sharing with ephemeral diffie-helman to prevent replay attacks). As E2EE became a desirable trait for the most part the different messaging apps went their own way.
For that matter, email is a laughably poor spec these days in terms of security - you should really treat all email as open communication, and that has been a flaw for decades without much remedy.
It also limits the control you have other your platform - both a good and bad thing. A way this can be bad - take email for example. No one can stop bad actors from spamming you except the client. Because email is an open messaging protocol, anyone can indeed send you any email, and the only recourse you have is on a client level.
Finally, just because a spec exists does not mean that it is truly interoperable. The web is a good example; it is an open spec, but we all know the reality is that Chrome is the de facto target, and any undefined behavior on Chrome is de facto the one you should implement. Webkit (Safari) has a full list of hacks to make sure websites work as expected that you can look at in Github.
Because proprietary platforms are easier to innovate on. Facebook or telegram can roll out any new feature they want and it just works on day one while email is still struggling to standardise server to server encryption let alone end to end encryption.
There is also corporate interests at hand but I think the major reason is simply that decentralised systems are 100x harder to build and almost impossible to upgrade.