Categories
Blogs and blogging Social Web

Deleted tweets on Facebook are a reminder about controlling your content

I noticed this story on TechCrunch about how cross-posted tweets were removed from Facebook, along with the conversations that formed around them.

Facebook users are complaining the company has removed the cross-posted tweets they had published to their profiles as Facebook updates. The posts’ removal took place following the recent API change that prevented Twitter users from continuing to automatically publish their tweets to Facebook. According to the affected parties, both the Facebook posts themselves, as well as the conversation around those posts that had taken place directly on Facebook, are now gone. Reached for comment, Facebook says it’s aware of the issue and is looking into it.

Axios published a post clarifying what happened:

Here’s what happened, according to a source close to Twitter.: Twitter had initially asked Facebook for more time to see if there was a way for users to continue joint posting to both social networks, but Facebook said no.

As a result, the Twitter app for the Facebook platform was essentially made useless earlier this month once Facebook officially removed the ability to cross-post. With the app’s sole function eliminated, Twitter decided to delete it from the Facebook platform, having no reason to think that doing so would remove old tweets that were cross-posted. It’s not clear whether Facebook knew this would happen, either.

Those tweets have apparently since been restored to Facebook, so the harm was short-lived. At the same time, this incident serves as an important reminder that you rarely have effective control over your content on platforms like Facebook and Twitter.

It’s also a big reason why I prefer the POSSE (Publish (on your) Own Site, Syndicate Elsewhere),  approach to publishing my content. That said, moves like Facebook’s changes to their API at the beginning of August 2018 have the effect of frustrating this to a degree.

It’s affected people’s ability to publish to their Facebook News Feeds automatically using external services (although you can still publish automatically to your Facebook Page). That said, this just reinforces the importance of having your own space on the Web where you have considerably more control over your content.

Categories
Applications Semantic Web

IFTTT v Pinboard

Never mind Batman v Superman. Now it’s IFTTT v Pinboard and I’m caught in the cross-fire.

I use Pinboard daily in some form or another. I also use the great “connector” service, IFTTT, daily to automate a host of little tasks like adding Instapaper highlights to a text file in Dropbox and many more.

In particular, I use a number of IFTTT recipes that include Pinboard in various little workflows that make my life easier and now it seems that is going to come to an end in just a week or two. I received this alarming email from IFTTT:

IFTTT v Pinboard

I rushed over to the Pinboard blog to see what Pinboard’s creator, Maciej Cegłowski, has to say about the matter. It turns out, he has quite a bit to say in his blog post titled “My Heroic and Lazy Stand Against IFTTT”. He cited two reasons for this little impasse:

Because many of you rely on IFTTT, and because this email makes it sound like I’m the asshole, I feel I should explain myself.

In a nutshell:

  1. IFTTT wants me to do their job for them for free
  2. They have really squirrely terms of service

It’s entirely IFTTT’s decision to drop support for Pinboard (along with a bunch of other sites). They are the ones who are going to flip the switch on working code on April 4, and they could just as easily flip the switch back on (or even write an IFTTT recipe that does it for them). Weigh their claims about Pinboard being a beloved service accordingly.

I understand his concerns and I agree with him that he shouldn’t have to reinvent the wheel at his cost to satisfy IFTTT’s requirements to remain connected to the service. Surely IFTTT could have come up with a more developer-friendly way to migrate to their new platform and help developers make the transition at a lower cost?

I would also have reservations about the contract they want developers to agree to as part of their transition to the new platform. Requiring developers to agree to the sorts of terms Cegłowski quote seems pretty unreasonable given what the clauses would seem to be saying.

At the same time, I’m caught between these two providers I rely on for various tasks. I don’t like the approach IFTTT seems to be taking but I love the service they provide. It literally makes my life easier in so many ways. I have also been using Pinboard for a while now as my personal bookmarking service and I even pay for the archival service. It is a simple and effective service.

This IFTTT v Pinboard impasse between the two companies just hurts people like me who either have to switch to some IFTTT competitor to address the soon-to-be introduced gaps in my workflows or just abandon those workflows altogether. The effect of that is to diminish the value of both services for me, just enough to leave me with that sick, disappointed feeling you get in times like these.

I hope this situation is resolved in some form or another but, if it isn’t … well, that just sucks.

Postscript:

IFTTT v Pinboard Redux – Contracts and Condescension