4 ms·

> It already happened for personal correspondence (facebook) and I'm sure at some point it'll happen for work correspondence too. I don't know the numbers but

by cm3 10y ago

> It already happened for personal correspondence (facebook) and I'm sure at some point it'll happen for work correspondence too. I don't know the numbers but I'm part of the population that never used Facebook, so I'm unconvinced you can generalize like that. > Put simply, in a world where clients are all free and the identifier of choice is the phone number, federation doesn't add much value. I didn't really understand Moxie's arguments, but he may know more due to the projects he's involved in. But how is interoperability achieved? The beauty of HTTP, NNTP and SMTP are that you're not bound to one (or maybe two) client experiences or server implementations. I don't understand the desire to leave achievements like that on the floor just for temporary comfort. It's a slippery slope and will lead us into a long time of silo'd communication. To me the current proposals look like if I had to use 4 different post offices depending on whom I want to send a package to. There's a reason addresses are universal.

mike_hearn 10y ago
Moxie's argument is that interop takes place at the level of the operating system's notification tray. If you want to make a better WhatsApp, all you have to do is ... build a better app. The traditional obstacles are largely gone in the mobile world: • You can access the same social graph just by requesting the contacts permission on your mobile phone: it's not like Facebook where the social network is locked away. • You don't have to go through some slow moving standards process which takes years to get the features into the most widely used clients like you would if trying to improve XMPP. • There's no cost to the user having multiple messaging apps installed thanks to Google/Apple's push networks: it's not like Windows/MacOS/Linux where having an app running in the background uses resources and requires permanent on-screen reminders of the resource wastage. So it's easy to get the user to set up your app. • Notifications will appear in the same place the user is looking for them no matter what. • You can (on Android) register for the right intents and whenever a friends phone number is invoked, your app will be offered as an option, so there's no lockin there either. These things together mean the traditional reasons for pursuing federated networks for chat (the avoidance of lockin) are largely irrelevant.
- cm3 10y ago
  That makes more sense, thanks. Re sharing contacts by replacing User@Domain with numbers: Yes, this solves some of it because everyone agreed to use phone numbers, but phone numbers are a thing of the past and you don't always want to share your phone number just for messaging. Re notification overhead: If you have a system-wide notification display system, then of course the resources it requires are limited but you still have to have it running in the background in some form. Granted, it's probably easier to optimize it with everyone using the same notification system. This is just consolidation of a popular feature into system-provided functionality. Re lockin: But lockin still exists because you are the whim of centrally managed for-profit messaging backends, operated by entities whose intentions may not necessarily align with yours. I'm not aware of cross-app synchronization of messages and even less so a common message format (feature) set supported by all that provides a rich experience. I don't disagree with the cited shortcomings of XMPP, though you can always find a flaw in something which wasn't explicitly designed for the current use case, so ignoring that, the basic premise of XMPP is still sound and needed. Implementation details are something else, and honestly I don't agree that replacing XML with JSON (as in some of the proposals) gains anything in terms of efficiency, which it probably wasn't intended to anyway. My impression is that building a messaging system is simple enough that many variants pop pup, but almost all of them get interoperability, synchronization, mobility, and security wrong. It's unsurprising because the simplicity attracts implementers of all domain experience levels.
  - mike_hearn 10y ago
    Android notifications do not require any app to be running in order for them to be displayed. lockin still exists because you are the whim of centrally managed for-profit messaging backends Given that 99.99% of people will never run their own servers, this is irrelevant: someone will be managing the infrastructure and those people will be motivated by profit. Welcome to capitalism: it works better than the alternatives despite its flaws. Things like WhatsApp or GChat do not simply replace XML with JSON. They tend to use binary protocols designed for low power consumption and ease of parsing. Arguably, if any protocol gets it wrong, it's XMPP ... I used to like it back when it was called Jabber, heck, I even hung out with a few Jabber developers back in the day. But Jabber's design goal was instant messaging and it's no longer useful for that. It just couldn't adapt to even quite small changes in circumstances.

by cm3 10y ago

mike_hearn 10y ago

Moxie's argument is that interop takes place at the level of the operating system's notification tray. If you want to make a better WhatsApp, all you have to do is ... build a better app. The traditional obstacles are largely gone in the mobile world: • You can access the same social graph just by requesting the contacts permission on your mobile phone: it's not like Facebook where the social network is locked away. • You don't have to go through some slow moving standards process which takes years to get the features into the most widely used clients like you would if trying to improve XMPP. • There's no cost to the user having multiple messaging apps installed thanks to Google/Apple's push networks: it's not like Windows/MacOS/Linux where having an app running in the background uses resources and requires permanent on-screen reminders of the resource wastage. So it's easy to get the user to set up your app. • Notifications will appear in the same place the user is looking for them no matter what. • You can (on Android) register for the right intents and whenever a friends phone number is invoked, your app will be offered as an option, so there's no lockin there either. These things together mean the traditional reasons for pursuing federated networks for chat (the avoidance of lockin) are largely irrelevant.

cm3 10y ago
That makes more sense, thanks. Re sharing contacts by replacing User@Domain with numbers: Yes, this solves some of it because everyone agreed to use phone numbers, but phone numbers are a thing of the past and you don't always want to share your phone number just for messaging. Re notification overhead: If you have a system-wide notification display system, then of course the resources it requires are limited but you still have to have it running in the background in some form. Granted, it's probably easier to optimize it with everyone using the same notification system. This is just consolidation of a popular feature into system-provided functionality. Re lockin: But lockin still exists because you are the whim of centrally managed for-profit messaging backends, operated by entities whose intentions may not necessarily align with yours. I'm not aware of cross-app synchronization of messages and even less so a common message format (feature) set supported by all that provides a rich experience. I don't disagree with the cited shortcomings of XMPP, though you can always find a flaw in something which wasn't explicitly designed for the current use case, so ignoring that, the basic premise of XMPP is still sound and needed. Implementation details are something else, and honestly I don't agree that replacing XML with JSON (as in some of the proposals) gains anything in terms of efficiency, which it probably wasn't intended to anyway. My impression is that building a messaging system is simple enough that many variants pop pup, but almost all of them get interoperability, synchronization, mobility, and security wrong. It's unsurprising because the simplicity attracts implementers of all domain experience levels.
- mike_hearn 10y ago
  Android notifications do not require any app to be running in order for them to be displayed. lockin still exists because you are the whim of centrally managed for-profit messaging backends Given that 99.99% of people will never run their own servers, this is irrelevant: someone will be managing the infrastructure and those people will be motivated by profit. Welcome to capitalism: it works better than the alternatives despite its flaws. Things like WhatsApp or GChat do not simply replace XML with JSON. They tend to use binary protocols designed for low power consumption and ease of parsing. Arguably, if any protocol gets it wrong, it's XMPP ... I used to like it back when it was called Jabber, heck, I even hung out with a few Jabber developers back in the day. But Jabber's design goal was instant messaging and it's no longer useful for that. It just couldn't adapt to even quite small changes in circumstances.