4 ms·

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

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.

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.