4 ms·

So, someone (who?) comes out with a standard, and then everyone just freezes capabilities then? Nothing evolves? Or if it does, it does so very unequally? Alrea

So, someone (who?) comes out with a standard, and then everyone just freezes capabilities then? Nothing evolves? Or if it does, it does so very unequally? Already in this announcement is the non-transfer of Live Photos because presumably Google doesn't support it. Apparently they also have a 20k per album cap, which at that point you get different behavior than you're expecting. These are just a few examples of where things go wrong. If we're going to legislate anything, I believe the right way is to force complete data export is made available via a reasonable API/process, which then allows people to independently evolve & progress, and competitors will then need to support (or not) what comes out on the other side. But customers then know they can always extract or simply backup their data themselves if needed.

fishywang 6y ago
An interface doesn't necessarily limit what the implementation can do. An implementation can well be a super set of the interface (some open standard it supports), with additional features that's not in the interface.
Barrin92 6y ago
>and then everyone just freezes capabilities then? Nothing evolves? Or if it does, it does so very unequally? every client provider can do whatever they want, that'd be the beauty of it. Someone could write a stripped down, privacy respecting Facebook client and charge users five bucks instead of running ads, if that's what users want. Someone could offer a chronological news-feed free of algorithmic meddling, or one that you can fine-tune however you like. That'd would simply be developer and user choice. Just think of RSS-readers or podcast apps or email clients. They're not all equal, but that's a feature, not something gone wrong.
- puszczyk 6y ago
  What does the Facebook get out of it?
  - Barrin92 6y ago
    absolutely nothing, it would subject their applications to genuine competition (they could of course still offer their own client) and destroy their walled garden, which is the entire point. The purpose such regulation is to benefit consumers, developers, and the health of the market overall. not Facebook. I assume they would be kicking and screaming.
    - deleted 6y ago
      [deleted]
    - chipotle_coyote 6y ago
      > it would subject their applications to genuine competition (they could of course still offer their own client) and destroy their walled garden, which is the entire point. Hmm. At least in the case that the OP was taking about -- third-party Facebook clients -- I don't think it would "destroy their walled garden" any more than third-party Twitter clients did back when those were meaningfully a thing. Standardized APIs aimed at enabling full-featured third-party social network clients wouldn't really contribute to a robust market in competing social networks; they'd just contribute to a robust market in, well, third-party social network clients. What it seems to me you want is a couple steps beyond data portability, which honestly really isn't enough on its own. What I actually need is a way to import the user's social graph from Facebook or Twitter. That's arguably how Instagram bootstrapped its success initially: if you gave it your Twitter account, it would download all your followers/following info. (And, of course, that's why Twitter shut down that API after that.) "But doesn't that violate GDPR?" someone is raising their hand to say, and: yes. GDPR as written does help protect privacy, but it's also an incredible boon to social network incumbents: it under it, your social graph can't be treated as your data, because by definition it contains personally identifiable information about all your contacts. For your regulation idea to be meaningful, GDPR and similar privacy regulation around the world would have to be overhauled -- if all the "open API" can do is import/export my personal data sans social graph, it becomes little more than a backup mechanism and a convenient way to fill out registration forms.
- leadingthenet 6y ago
  > every client provider can do whatever they want I feel like you're missing his point a bit, which is that sure they can do whatever they want, but it would be within a well-defined and highly regulated system, and would need to conform to an interface that would be difficult to change and evolve. A bit like how IRC never really got updated with features people like to see in newer IM apps, like conversation history, read receipts, sending images and videos, threading, and so on. Or HTTP. Or email. Federation always leads to ossification.
- dwighttk 6y ago
  But I already have and use an rss reader
- lrem 6y ago
  I think you missed an important link here: opening the API is not the same as making a good standard. The latter tends to take years. The former... Well, Google internal APIs often have minor changes every couple weeks. And the standard of documentation is more or less "go read the code". Opening those would not be useful. I don't know if Facebook is any better. But their motto is "move fast and break things", so I'm skeptical.
  - Barrin92 6y ago
    don't forget that there will be competition on the protocols as well, I'm not just arguing for protocols as a means for more innovation on the client side, but also more competition on the backend itself. If data becomes portable, which is one side effect of protocols, competition on standards itself intensifies. So if Google and Facebook are bad stewards of their APIs, there is room for competition to emerge. Google does stuff that sucks on their end? Use existing APIs to migrate over to dropbox or whatever, tell your users. In an open market there is an incentive for good standards.
    - lrem 6y ago
      I, uh, can't grok competing protocols as a good thing.
lupire 6y ago
HTML had been a standard for about 25 years and it doesn't seem to be stagnant.
oarsinsync 6y ago
> Already in this announcement is the non-transfer of Live Photos because presumably Google doesn't support it. Google Photos definitely supports Live Photos, I've successfully uploaded and shared lots of Live Photos via the Google Photos for iOS app. Which then raises the question of why doesn't the tool support it?
- kemayo 6y ago
  Assuming that they're using the Google Photos API for this, maybe the upload media API calls [1] don't trigger whatever handling is needed for Live Photos? The Google Photos app might be doing something undocumented/unavailable-in-the-public-API that triggers the Live Photo behavior, since a Live Photo is two associated pieces of media. Or Apple might just not be uploading the videos that accompany the photo for some reason. [1]: https://developers.google.com/photos/library/guides/upload-media https://developers.google.com/photos/library/guides/upload-m...
- jwagenet 6y ago
  Just spitballing here: when I copy photos from my iPhone via usb to pc there are two files: the image and a .mov for a Live Photo. My guess is the metadata is lost when exporting to google photos, like usb, so you lose the “Live Photo”.
barnabee 6y ago
Forcing the protocol to be open and documented and free for any user that can use the official site/client to connect to doesn’t have to mean forcing a standard. You might want to require o rubies compatibility with old versions and deal with obfuscation or unnecessary changes as anti competitive behaviour, but otherwise just ensuring that anyone can create and sell or give away clients, interoperability and import/export tools, etc. would be an excellent step in the right direction. With no obvious downsides.
coldtea 6y ago
>So, someone (who?) comes out with a standard, and then everyone just freezes capabilities then? Nothing evolves? Hopefully yes. Most "progress" is towards worse services and more user data minining and ads. But if needed, they can always innovate. But they'd still have to be able to export to the standard format (even if it can hold less than their full features).

fishywang 6y ago

An interface doesn't necessarily limit what the implementation can do. An implementation can well be a super set of the interface (some open standard it supports), with additional features that's not in the interface.

Barrin92 6y ago

>and then everyone just freezes capabilities then? Nothing evolves? Or if it does, it does so very unequally? every client provider can do whatever they want, that'd be the beauty of it. Someone could write a stripped down, privacy respecting Facebook client and charge users five bucks instead of running ads, if that's what users want. Someone could offer a chronological news-feed free of algorithmic meddling, or one that you can fine-tune however you like. That'd would simply be developer and user choice. Just think of RSS-readers or podcast apps or email clients. They're not all equal, but that's a feature, not something gone wrong.

puszczyk 6y ago
What does the Facebook get out of it?
- Barrin92 6y ago
  absolutely nothing, it would subject their applications to genuine competition (they could of course still offer their own client) and destroy their walled garden, which is the entire point. The purpose such regulation is to benefit consumers, developers, and the health of the market overall. not Facebook. I assume they would be kicking and screaming.
  - deleted 6y ago
    [deleted]
  - chipotle_coyote 6y ago
    > it would subject their applications to genuine competition (they could of course still offer their own client) and destroy their walled garden, which is the entire point. Hmm. At least in the case that the OP was taking about -- third-party Facebook clients -- I don't think it would "destroy their walled garden" any more than third-party Twitter clients did back when those were meaningfully a thing. Standardized APIs aimed at enabling full-featured third-party social network clients wouldn't really contribute to a robust market in competing social networks; they'd just contribute to a robust market in, well, third-party social network clients. What it seems to me you want is a couple steps beyond data portability, which honestly really isn't enough on its own. What I actually need is a way to import the user's social graph from Facebook or Twitter. That's arguably how Instagram bootstrapped its success initially: if you gave it your Twitter account, it would download all your followers/following info. (And, of course, that's why Twitter shut down that API after that.) "But doesn't that violate GDPR?" someone is raising their hand to say, and: yes. GDPR as written does help protect privacy, but it's also an incredible boon to social network incumbents: it under it, your social graph can't be treated as your data, because by definition it contains personally identifiable information about all your contacts. For your regulation idea to be meaningful, GDPR and similar privacy regulation around the world would have to be overhauled -- if all the "open API" can do is import/export my personal data sans social graph, it becomes little more than a backup mechanism and a convenient way to fill out registration forms.
leadingthenet 6y ago
> every client provider can do whatever they want I feel like you're missing his point a bit, which is that sure they can do whatever they want, but it would be within a well-defined and highly regulated system, and would need to conform to an interface that would be difficult to change and evolve. A bit like how IRC never really got updated with features people like to see in newer IM apps, like conversation history, read receipts, sending images and videos, threading, and so on. Or HTTP. Or email. Federation always leads to ossification.
dwighttk 6y ago
But I already have and use an rss reader
lrem 6y ago
I think you missed an important link here: opening the API is not the same as making a good standard. The latter tends to take years. The former... Well, Google internal APIs often have minor changes every couple weeks. And the standard of documentation is more or less "go read the code". Opening those would not be useful. I don't know if Facebook is any better. But their motto is "move fast and break things", so I'm skeptical.
- Barrin92 6y ago
  don't forget that there will be competition on the protocols as well, I'm not just arguing for protocols as a means for more innovation on the client side, but also more competition on the backend itself. If data becomes portable, which is one side effect of protocols, competition on standards itself intensifies. So if Google and Facebook are bad stewards of their APIs, there is room for competition to emerge. Google does stuff that sucks on their end? Use existing APIs to migrate over to dropbox or whatever, tell your users. In an open market there is an incentive for good standards.
  - lrem 6y ago
    I, uh, can't grok competing protocols as a good thing.

lupire 6y ago

HTML had been a standard for about 25 years and it doesn't seem to be stagnant.

oarsinsync 6y ago

> Already in this announcement is the non-transfer of Live Photos because presumably Google doesn't support it. Google Photos definitely supports Live Photos, I've successfully uploaded and shared lots of Live Photos via the Google Photos for iOS app. Which then raises the question of why doesn't the tool support it?

kemayo 6y ago
Assuming that they're using the Google Photos API for this, maybe the upload media API calls [1] don't trigger whatever handling is needed for Live Photos? The Google Photos app might be doing something undocumented/unavailable-in-the-public-API that triggers the Live Photo behavior, since a Live Photo is two associated pieces of media. Or Apple might just not be uploading the videos that accompany the photo for some reason. [1]: https://developers.google.com/photos/library/guides/upload-media https://developers.google.com/photos/library/guides/upload-m...
jwagenet 6y ago
Just spitballing here: when I copy photos from my iPhone via usb to pc there are two files: the image and a .mov for a Live Photo. My guess is the metadata is lost when exporting to google photos, like usb, so you lose the “Live Photo”.

barnabee 6y ago

Forcing the protocol to be open and documented and free for any user that can use the official site/client to connect to doesn’t have to mean forcing a standard. You might want to require o rubies compatibility with old versions and deal with obfuscation or unnecessary changes as anti competitive behaviour, but otherwise just ensuring that anyone can create and sell or give away clients, interoperability and import/export tools, etc. would be an excellent step in the right direction. With no obvious downsides.

coldtea 6y ago

>So, someone (who?) comes out with a standard, and then everyone just freezes capabilities then? Nothing evolves? Hopefully yes. Most "progress" is towards worse services and more user data minining and ads. But if needed, they can always innovate. But they'd still have to be able to export to the standard format (even if it can hold less than their full features).