6 ms·

This golden aged failed when it missed the boat to go mobile. Ridiculous to think that none of the messengers from this time could envision to sync with the mob

by oezi 5y ago

This golden aged failed when it missed the boat to go mobile. Ridiculous to think that none of the messengers from this time could envision to sync with the mobile phone's address book. I don't think we would have WhatsApp or Signal if any of the desktop chats had allowed that.

l72 5y ago
The Palm Pre actually had a really nice mobile messenger. It synced with Address Book, supported SMS, Jabber, Facebook Messenger (back when it was jabber), aim, and others. It would seamlessly switch protocols based on how the contact messaged you. Like most things with the Pre, it was way ahead of its time.
Groxx 5y ago
Arguably, they were killed by the mobile platform-owners. Sending push notifications, which is broadly necessary for achieving both performance and battery efficiency, has been strictly centralized and locked down (understandably, I'd hate to try to block abuse if I were running it). Federated systems with multiple apps were pushed out because there was no sane way to achieve that with the push architecture, and that's still the case. You see the same thing with nearly any third-party app, they're nearly always partly-crippled experiences because the first-party will not send push notifications to anything but their own app.
- toast0 5y ago
  You absolutely need push on iOS and modern Android. S60 and Android before doze didn't because you could just have a connection in the background; afaik, BlackBerry didn't restrict background data either. But it's not like there was a lot of good mobile XMPP clients that died out when push became mandatory. If there was, it wouldn't take much to make an XMPP extension or three for the client to provide a push url to the server. Client devs would (probably) need to standup a push proxy, so xmpp server pushes to client server pushes to client, because I don't think many platforms give out push urls that can be securely passed on to 3rd parties. There's some expense there, but not a whole lot, IMHO.
  - dinosaurdynasty 5y ago
    XEP-0357: Push Notifications <https://xmpp.org/extensions/xep-0357.html https://xmpp.org/extensions/xep-0357.html> has been a thing for while. A lot of servers support it too: <https://compliance.conversations.im/test/xep0357/ https://compliance.conversations.im/test/xep0357/>.
- thombles 5y ago
  While a lamentable situation, this has been addressed to a considerable degree and it's not all that bad. For example Matrix has its Push Gateway API (https://matrix.org/docs/spec/push_gateway/r0.1.1#id4 https://matrix.org/docs/spec/push_gateway/r0.1.1#id4) which allows any client to register any kind of push service. This means that any given iOS app, for example, can maintain its own backend for feeding events into APNs like Apple requires. I'm not as familiar with it but I believe XEP-0357 does something similar.
- lmm 5y ago
  Nah, they were killed by XMPP's braindead protocol design that made it useless for multiple clients. Apparently the idea that people might want to read messages on both their phone and computer, or on two computers, was completely unimaginable for XMPP, despite every other messaging system doing the sensible thing. Eventually there was an XEP ("Message Carbons") to give the basic sensible functionality, and eventually eventually most servers more or less supported it and it more or less worked most of the time, but that killed XMPP on mobile long before push notification platforms were even a thing.
  - detaro 5y ago
    That indeed was a problem that hurt it badly, but XMPP is also old. If I remember correctly, supporting multiple simultaneous clients at all was more than other contemporary IM systems did.
    - lmm 5y ago
      From my memory at the time AIM and Skype would both Just Work. I think maybe MSN would forcibly log you out if you logged in on a second computer? (Still better than continuing to route messages to your other computer, which is what XMPP does by default).
    - fragmede 5y ago
      Exactly. XMPP's a little younger than AOL, but the idea of having more than one device connected to the Internet and using them simultaneously, was sheer opulence at one point. Combined with XMPP being an open protocol and difficulty incrementing protocol versions, lead to the shortcomings described.
    - AndyMcConachie 5y ago
      This is certainly not a problem with XMPP now. I run my own XMPP server and use XMPP to share things between my different devices. I have multiple accounts logged in from multiple machines all day every day. What I really like about XMPP is that I can do precisely this. Also, setting up and running prosody is dirt simple if you have any UNIX experience. IMO it's even simpler than running your own web server.
- chipotle_coyote 5y ago
  I feel like I must be misunderstanding what you're saying here, at least in the last sentence. I think of "first party" as "platform owner" and "third party" as, uh, not the platform owner, but third-party real-time messaging apps obviously can send push notifications on iOS and Android. While it's been an awfully long time now, I seem to remember that services like AIM didn't successfully move to mobile because they required stateful connections similar to telnet/SSH, and that was something that just wasn't (and largely still isn't) possible under iOS.
  - thaumasiotes 5y ago
    > services like AIM didn't successfully move to mobile AIM is a lot like AIM, and it worked fine on BlackBerries.
    - chipotle_coyote 5y ago
      It's quite possible the Blackberry AIM client supported stateful connections. IIRC, it worked well on the Danger Hiptop / T-Mobile Sidekick, too.
      - lmz 5y ago
        Blackberry had their own software (BES/BIS) running as an intermediary between email and their devices. Were they using the same method for chat apps too?
  - Groxx 5y ago
    Since we're talking about a federated system (xmpp as a whole), I mean "first party" as in "an xmpp ecosystem runner" like google used to be. And "third party" as "any other implementation". Google had an xmpp system (google talk) for which they have a first-party app which they send push notifications to. No other xmpp app can take advantage of that for google accounts - they all need to run, essentially, an xmpp-bouncer + their own push notification infrastructure and client implementation. In ye olden days, a google-free version for google-free xmpp accounts could not be built in many cases, as the mobile device's APIs wouldn't let you hold open connections in the background like that - that was unique to the platform-owner (Android / iOS). Now you basically can, but each implementation increases battery use, so there's a fair bit of pressure to use the built-in one instead... which you can't do, Google won't send your app any push notifications that are intended for their apps. --- The same thing applies to email apps, for example. IDLE just plain doesn't work well enough on phones, so email apps build their own email backends so they can use google's push notification infrastructure to push notifications for google-owned email account events. Google is the first party here, owning the email account and infrastructure, but not sending notifications to other email applications. And also for basically any third-party app for basically any service. E.g. Talon (a third party twitter app) has to resort to polling Twitter's API to do anything. But those at least aren't federated systems, so though I'm still a bit sad about that, it's much more understandable that it happens.
- mro_name 5y ago
  > battery efficiency yep, that's the downside of xmpp, isn't it? How could that be mitigated?
  - MattJ100 5y ago
    It's mitigated in several ways. But first of all consider that XMPP is hardly inefficient by today's standards, when mobile devices can stream video continuously for hours on a single charge. Still, battery is important to consider, so what have we done in XMPP to improve energy efficiency in the past 15 years? One of the first things we did was define a way for clients to reconnect a session that suffered a broken connection - the classic "I just went through a tunnel" scenario. With this optimization we gained two things: a way to quickly reconnect without resynchronizing everything, and a guarantee that no traffic was lost in the process due to the network interruption. Secondly, we've implemented traffic optimization in servers. Clients will tell the server when they are idling in the background, and the server will stop sending any traffic that isn't time-sensitive. As soon as the user focuses the app, it tells the server and the connection switches back to "real-time" delivery. This behaviour helps keep network activity low when the client is in the background, and prevents continuously waking up the device's radio (such wake-ups can be quite power hungry over the course of a day). Finally, modern mobile XMPP clients support push notifications, which is the Apple/Google sanctioned way of solving this problem. It means that you can safely close the XMPP client entirely and still get notified when you receive messages. There's probably more besides these things that I've forgotten but I think these changes are the highlights!
    - mro_name 5y ago
      thank you, that's quite something.
- hagbard_c 5y ago
  > ...has been strictly centralized and locked down (understandably, I'd hate to try to block abuse if I were running it). Not understandably at all, the reason for the lockdown is not for your benefit even if it is portrayed as such. Push notification can be run just like SMTP and is subject to the same type of abuse with the big difference that it actually easier to keep the spammers out since you know up front which senders are allowed to send notifications. It would be fully possible to self-host a push notification daemon which connects to those services which are meant to send you notifications, to which your devices connect for notifications. If you don't want to self-host it would be possible to choose a notification service just like you can choose an email provider. Things could be just as hands-off as they are now without being forced to open an Apple/Google/Microsoft account and hand over your communications to them. Don't be fooled by these 'for your protection' lockdowns, they are for the benefit of the one doing the lockdown, not for your own.
  - Groxx 5y ago
    Those kinds of systems tend to have been created and popularized before any single large actor appeared and started using it. Push notifications were single-actor from the very beginning. Decentralized setups in that situation are much more expensive to build and run - with the exception of "from the goodness of their hearts" projects, a business has little reason to make the sole implementation vastly more complex and open to abuse. And tbh I'm not sure SMTP serves as all that positive of an example. It works, sure, but the reputation system and extreme complexity that has sprung up around it makes it difficult for newcomers to join - I can't just host one from my house, most email hosts will reject my emails. It works in spite of all this because it has too many large actors already using it for any new ones to stand any chance of rejecting (or improving) it.
miohtama 5y ago
It also failed because of this > Signup for an XMPP service anonymously Unmoderated networks quickly degenerate spam pits from Hell. It worked in 90s when everyone was still polite in Internet.
- hnlmorg 5y ago
  People weren't polite on the internet in the 90s! There was plenty of trolls even back then. Plenty of spam too. I'm ashamed to admit this but I even wrote software what ran on Windows 95 and would spam chat rooms with thousands of phrases generated on the fly from a dictionary. The intention was it would run over a RAT (also of my creation) and get other people booted off the chat room. ie the spam would be posted by other people in chat rooms against their will and channel admins would then kick them. I wrote this because at college we "only" had dual ISDN lines and kids in chat rooms would slow down my warez downloads. I know, I know, the justification is worse than the tool itself. But we were young, I've grown up since and these days the lessons I've learned from my college exploits are put to good use :)
hnlmorg 5y ago
> This golden aged failed when it missed the boat to go mobile. There were plenty of mobile applications that supported multiple chat protocols. There might even still be. The issue is proprietary protocols would often change breaking support -- I suspect intentionally breaking support for 3rd party client. Linux / Unix nerds running FOSS would be tolerant of that but I suspect your average smart phone user who might have spent 99c on the client would be less understanding.

by oezi 5y ago

l72 5y ago

The Palm Pre actually had a really nice mobile messenger. It synced with Address Book, supported SMS, Jabber, Facebook Messenger (back when it was jabber), aim, and others. It would seamlessly switch protocols based on how the contact messaged you. Like most things with the Pre, it was way ahead of its time.

Groxx 5y ago

Arguably, they were killed by the mobile platform-owners. Sending push notifications, which is broadly necessary for achieving both performance and battery efficiency, has been strictly centralized and locked down (understandably, I'd hate to try to block abuse if I were running it). Federated systems with multiple apps were pushed out because there was no sane way to achieve that with the push architecture, and that's still the case. You see the same thing with nearly any third-party app, they're nearly always partly-crippled experiences because the first-party will not send push notifications to anything but their own app.

toast0 5y ago
You absolutely need push on iOS and modern Android. S60 and Android before doze didn't because you could just have a connection in the background; afaik, BlackBerry didn't restrict background data either. But it's not like there was a lot of good mobile XMPP clients that died out when push became mandatory. If there was, it wouldn't take much to make an XMPP extension or three for the client to provide a push url to the server. Client devs would (probably) need to standup a push proxy, so xmpp server pushes to client server pushes to client, because I don't think many platforms give out push urls that can be securely passed on to 3rd parties. There's some expense there, but not a whole lot, IMHO.
- dinosaurdynasty 5y ago
  XEP-0357: Push Notifications <https://xmpp.org/extensions/xep-0357.html https://xmpp.org/extensions/xep-0357.html> has been a thing for while. A lot of servers support it too: <https://compliance.conversations.im/test/xep0357/ https://compliance.conversations.im/test/xep0357/>.
thombles 5y ago
While a lamentable situation, this has been addressed to a considerable degree and it's not all that bad. For example Matrix has its Push Gateway API (https://matrix.org/docs/spec/push_gateway/r0.1.1#id4 https://matrix.org/docs/spec/push_gateway/r0.1.1#id4) which allows any client to register any kind of push service. This means that any given iOS app, for example, can maintain its own backend for feeding events into APNs like Apple requires. I'm not as familiar with it but I believe XEP-0357 does something similar.
lmm 5y ago
Nah, they were killed by XMPP's braindead protocol design that made it useless for multiple clients. Apparently the idea that people might want to read messages on both their phone and computer, or on two computers, was completely unimaginable for XMPP, despite every other messaging system doing the sensible thing. Eventually there was an XEP ("Message Carbons") to give the basic sensible functionality, and eventually eventually most servers more or less supported it and it more or less worked most of the time, but that killed XMPP on mobile long before push notification platforms were even a thing.
- detaro 5y ago
  That indeed was a problem that hurt it badly, but XMPP is also old. If I remember correctly, supporting multiple simultaneous clients at all was more than other contemporary IM systems did.
  - lmm 5y ago
    From my memory at the time AIM and Skype would both Just Work. I think maybe MSN would forcibly log you out if you logged in on a second computer? (Still better than continuing to route messages to your other computer, which is what XMPP does by default).
  - fragmede 5y ago
    Exactly. XMPP's a little younger than AOL, but the idea of having more than one device connected to the Internet and using them simultaneously, was sheer opulence at one point. Combined with XMPP being an open protocol and difficulty incrementing protocol versions, lead to the shortcomings described.
  - AndyMcConachie 5y ago
    This is certainly not a problem with XMPP now. I run my own XMPP server and use XMPP to share things between my different devices. I have multiple accounts logged in from multiple machines all day every day. What I really like about XMPP is that I can do precisely this. Also, setting up and running prosody is dirt simple if you have any UNIX experience. IMO it's even simpler than running your own web server.
chipotle_coyote 5y ago
I feel like I must be misunderstanding what you're saying here, at least in the last sentence. I think of "first party" as "platform owner" and "third party" as, uh, not the platform owner, but third-party real-time messaging apps obviously can send push notifications on iOS and Android. While it's been an awfully long time now, I seem to remember that services like AIM didn't successfully move to mobile because they required stateful connections similar to telnet/SSH, and that was something that just wasn't (and largely still isn't) possible under iOS.
- thaumasiotes 5y ago
  > services like AIM didn't successfully move to mobile AIM is a lot like AIM, and it worked fine on BlackBerries.
  - chipotle_coyote 5y ago
    It's quite possible the Blackberry AIM client supported stateful connections. IIRC, it worked well on the Danger Hiptop / T-Mobile Sidekick, too.
    - lmz 5y ago
      Blackberry had their own software (BES/BIS) running as an intermediary between email and their devices. Were they using the same method for chat apps too?
- Groxx 5y ago
  Since we're talking about a federated system (xmpp as a whole), I mean "first party" as in "an xmpp ecosystem runner" like google used to be. And "third party" as "any other implementation". Google had an xmpp system (google talk) for which they have a first-party app which they send push notifications to. No other xmpp app can take advantage of that for google accounts - they all need to run, essentially, an xmpp-bouncer + their own push notification infrastructure and client implementation. In ye olden days, a google-free version for google-free xmpp accounts could not be built in many cases, as the mobile device's APIs wouldn't let you hold open connections in the background like that - that was unique to the platform-owner (Android / iOS). Now you basically can, but each implementation increases battery use, so there's a fair bit of pressure to use the built-in one instead... which you can't do, Google won't send your app any push notifications that are intended for their apps. --- The same thing applies to email apps, for example. IDLE just plain doesn't work well enough on phones, so email apps build their own email backends so they can use google's push notification infrastructure to push notifications for google-owned email account events. Google is the first party here, owning the email account and infrastructure, but not sending notifications to other email applications. And also for basically any third-party app for basically any service. E.g. Talon (a third party twitter app) has to resort to polling Twitter's API to do anything. But those at least aren't federated systems, so though I'm still a bit sad about that, it's much more understandable that it happens.
mro_name 5y ago
> battery efficiency yep, that's the downside of xmpp, isn't it? How could that be mitigated?
- MattJ100 5y ago
  It's mitigated in several ways. But first of all consider that XMPP is hardly inefficient by today's standards, when mobile devices can stream video continuously for hours on a single charge. Still, battery is important to consider, so what have we done in XMPP to improve energy efficiency in the past 15 years? One of the first things we did was define a way for clients to reconnect a session that suffered a broken connection - the classic "I just went through a tunnel" scenario. With this optimization we gained two things: a way to quickly reconnect without resynchronizing everything, and a guarantee that no traffic was lost in the process due to the network interruption. Secondly, we've implemented traffic optimization in servers. Clients will tell the server when they are idling in the background, and the server will stop sending any traffic that isn't time-sensitive. As soon as the user focuses the app, it tells the server and the connection switches back to "real-time" delivery. This behaviour helps keep network activity low when the client is in the background, and prevents continuously waking up the device's radio (such wake-ups can be quite power hungry over the course of a day). Finally, modern mobile XMPP clients support push notifications, which is the Apple/Google sanctioned way of solving this problem. It means that you can safely close the XMPP client entirely and still get notified when you receive messages. There's probably more besides these things that I've forgotten but I think these changes are the highlights!
  - mro_name 5y ago
    thank you, that's quite something.
hagbard_c 5y ago
> ...has been strictly centralized and locked down (understandably, I'd hate to try to block abuse if I were running it). Not understandably at all, the reason for the lockdown is not for your benefit even if it is portrayed as such. Push notification can be run just like SMTP and is subject to the same type of abuse with the big difference that it actually easier to keep the spammers out since you know up front which senders are allowed to send notifications. It would be fully possible to self-host a push notification daemon which connects to those services which are meant to send you notifications, to which your devices connect for notifications. If you don't want to self-host it would be possible to choose a notification service just like you can choose an email provider. Things could be just as hands-off as they are now without being forced to open an Apple/Google/Microsoft account and hand over your communications to them. Don't be fooled by these 'for your protection' lockdowns, they are for the benefit of the one doing the lockdown, not for your own.
- Groxx 5y ago
  Those kinds of systems tend to have been created and popularized before any single large actor appeared and started using it. Push notifications were single-actor from the very beginning. Decentralized setups in that situation are much more expensive to build and run - with the exception of "from the goodness of their hearts" projects, a business has little reason to make the sole implementation vastly more complex and open to abuse. And tbh I'm not sure SMTP serves as all that positive of an example. It works, sure, but the reputation system and extreme complexity that has sprung up around it makes it difficult for newcomers to join - I can't just host one from my house, most email hosts will reject my emails. It works in spite of all this because it has too many large actors already using it for any new ones to stand any chance of rejecting (or improving) it.

miohtama 5y ago

It also failed because of this > Signup for an XMPP service anonymously Unmoderated networks quickly degenerate spam pits from Hell. It worked in 90s when everyone was still polite in Internet.

hnlmorg 5y ago
People weren't polite on the internet in the 90s! There was plenty of trolls even back then. Plenty of spam too. I'm ashamed to admit this but I even wrote software what ran on Windows 95 and would spam chat rooms with thousands of phrases generated on the fly from a dictionary. The intention was it would run over a RAT (also of my creation) and get other people booted off the chat room. ie the spam would be posted by other people in chat rooms against their will and channel admins would then kick them. I wrote this because at college we "only" had dual ISDN lines and kids in chat rooms would slow down my warez downloads. I know, I know, the justification is worse than the tool itself. But we were young, I've grown up since and these days the lessons I've learned from my college exploits are put to good use :)

hnlmorg 5y ago

> This golden aged failed when it missed the boat to go mobile. There were plenty of mobile applications that supported multiple chat protocols. There might even still be. The issue is proprietary protocols would often change breaking support -- I suspect intentionally breaking support for 3rd party client. Linux / Unix nerds running FOSS would be tolerant of that but I suspect your average smart phone user who might have spent 99c on the client would be less understanding.