9 ms·

Can someone elaborate more on the "Working for Free" section? I'm not well versed in IFTTT, but shouldn't I as the owner of a website that wants to offer a reci

Can someone elaborate more on the "Working for Free" section? I'm not well versed in IFTTT, but shouldn't I as the owner of a website that wants to offer a recipe be responsible for the details that recipe? This is all very unclear without specific examples.

djrogers 11y ago
This isn't about offering recipes, this is about IFTTT requiring sites to write support for a new API (notice, it's not write to a new API, they have to build this new PI in to their site) so others can write IFTTT recipes.
dljsjr 11y ago
I believe, and I could be wrong here, that previously IFTTT simply consumed public APIs to cobble things together. They are now asking services that want to be IFTTT-able to expose an API that IFTTT defines. IFTTT will still be hitting endpoints on the developer's product's site, but the endpoints are defined by IFTTT and not public.
msbarnett 11y ago
The site doesn't provide recipes, it provides endpoints (API calls) that users can write recipes to use. How it worked until now: 1) IFTTT wrote glue code to interface with a site's published API, and IFTTT could then write recipes to use the site. IFTTT thus stitched together other sites published APIs as a service. How IFTTT has decided it will work from now on: 1) IFTTT comes to you and orders you to write private endpoint(s) that do X, Y, and Z. They reserve the right to ask for additional endpoints, different call results, or anything else they dream up down the road. You sign a legal agreement promising to ask "how high?" any time they say "jump". You will not be compensated for this privilege.
- dave2000 11y ago
  Wouldn't you be performing this work because you believe it will facilitate the transfer of traffic to your site? Aren't you comitting to make changes as and when ifttt change their API so that you can continue to receive their calls? Sites/services can just walk away if they don't want the traffic. No one's obliged to pay or do anything they don't want to.
  - cissou 11y ago
    It is correct in the sense that they're not forcing anyone to use IFTTT, but they make it sound like the website owner is responsible for the degradation of service, while in reality it's IFTTT's decision.
    - dave2000 11y ago
      Yeah, but i'm not getting how they're doing anything wrong. It's their site/service; they can make any changes they want. It's like developers having to keep up with changes to Android, for example. The UI can change from release to release; new rules get added to the play store; how access to external storage is allowed/handled changes often. Google isn't doing it for the fun of it and it makes no sense to take them to task over it; it's just one of those "keep up" things which has been at the root of software development for as long as I can remember.
      - mrgoldenbrown 11y ago
        Keeping up with something you chose to support (like if you wrote an Android app) is reasonable. But that is the opposite of what happened here. IFTTT chose to support pinboard, not the other way around. If they are choosing to stop support, they need to own up to it, not put the blame on IFTTT.
      - msbarnett 11y ago
        I think you've really missed the point here. Nobody is arguing that IFTTT can't change their service as they see fit. They can, as they've chosen to here, move from a model in which they write client code for other sites APIs, to a model where other sites write client code for their API. It's obviously beneficial to IFTTT if they can offload this work to other sites for free. What's shitty and rude and presumptuous about their behaviour is going to other sites who never asked to be part of IFTTT (IFTTT was just a consumer of pinboard's public API) and saying "here sign this and get cracking on implementing our specs". And when a site owner refuses such a "request", IFTTT is basically lying to its customers when it says that Pinboard has chosen to leave the service, rather than "IFTTT has chosen to shut down their working pinboard API client code". To reuse your analogy, it's as though Google themselves built an App client for my site, then decided to move to a model where Android apps were responsible for hosting and bandwidth of their own app (their right) and disable all apps in the store who didn't specify a hosting location (their right), deleted the app they built (their right), mailed me the specs for their app and a deadline to reimplement it myself and host it at my cost (why would I be interested in this? I never asked for any of this), and then when I told them to get bent emailed customers "Sadly, beloved app $APP has chosen to take themselves out of the Android store" (lying).
deleted 11y ago
[deleted]

djrogers 11y ago

This isn't about offering recipes, this is about IFTTT requiring sites to write support for a new API (notice, it's not write to a new API, they have to build this new PI in to their site) so others can write IFTTT recipes.

dljsjr 11y ago

I believe, and I could be wrong here, that previously IFTTT simply consumed public APIs to cobble things together. They are now asking services that want to be IFTTT-able to expose an API that IFTTT defines. IFTTT will still be hitting endpoints on the developer's product's site, but the endpoints are defined by IFTTT and not public.

msbarnett 11y ago

The site doesn't provide recipes, it provides endpoints (API calls) that users can write recipes to use. How it worked until now: 1) IFTTT wrote glue code to interface with a site's published API, and IFTTT could then write recipes to use the site. IFTTT thus stitched together other sites published APIs as a service. How IFTTT has decided it will work from now on: 1) IFTTT comes to you and orders you to write private endpoint(s) that do X, Y, and Z. They reserve the right to ask for additional endpoints, different call results, or anything else they dream up down the road. You sign a legal agreement promising to ask "how high?" any time they say "jump". You will not be compensated for this privilege.

dave2000 11y ago
Wouldn't you be performing this work because you believe it will facilitate the transfer of traffic to your site? Aren't you comitting to make changes as and when ifttt change their API so that you can continue to receive their calls? Sites/services can just walk away if they don't want the traffic. No one's obliged to pay or do anything they don't want to.
- cissou 11y ago
  It is correct in the sense that they're not forcing anyone to use IFTTT, but they make it sound like the website owner is responsible for the degradation of service, while in reality it's IFTTT's decision.
  - dave2000 11y ago
    Yeah, but i'm not getting how they're doing anything wrong. It's their site/service; they can make any changes they want. It's like developers having to keep up with changes to Android, for example. The UI can change from release to release; new rules get added to the play store; how access to external storage is allowed/handled changes often. Google isn't doing it for the fun of it and it makes no sense to take them to task over it; it's just one of those "keep up" things which has been at the root of software development for as long as I can remember.
    - mrgoldenbrown 11y ago
      Keeping up with something you chose to support (like if you wrote an Android app) is reasonable. But that is the opposite of what happened here. IFTTT chose to support pinboard, not the other way around. If they are choosing to stop support, they need to own up to it, not put the blame on IFTTT.
    - msbarnett 11y ago
      I think you've really missed the point here. Nobody is arguing that IFTTT can't change their service as they see fit. They can, as they've chosen to here, move from a model in which they write client code for other sites APIs, to a model where other sites write client code for their API. It's obviously beneficial to IFTTT if they can offload this work to other sites for free. What's shitty and rude and presumptuous about their behaviour is going to other sites who never asked to be part of IFTTT (IFTTT was just a consumer of pinboard's public API) and saying "here sign this and get cracking on implementing our specs". And when a site owner refuses such a "request", IFTTT is basically lying to its customers when it says that Pinboard has chosen to leave the service, rather than "IFTTT has chosen to shut down their working pinboard API client code". To reuse your analogy, it's as though Google themselves built an App client for my site, then decided to move to a model where Android apps were responsible for hosting and bandwidth of their own app (their right) and disable all apps in the store who didn't specify a hosting location (their right), deleted the app they built (their right), mailed me the specs for their app and a deadline to reimplement it myself and host it at my cost (why would I be interested in this? I never asked for any of this), and then when I told them to get bent emailed customers "Sadly, beloved app $APP has chosen to take themselves out of the Android store" (lying).

deleted 11y ago

[deleted]