Backfeed is an important element in breaking out of silos like Twitter, Facebook, and others. Backfeed means if I post something from my site to e.g. Twitter, that the responses to it (likes, answers) also become visible on my site. So that when those silos inevitably go away and get replaced, my interactions are still available on my own site and available in my own database. Ryan Barrett of the valuable backfeed service Bridgy writes about the difficulties of creating backfeed (with lots of things to figure out for each additional silo), and wonders about making backfeed possible without additional or separate code. Sort of how IFTTT allows you to create your own recipes to let various applications you use talk to each other.

An example of backfeed in action:

I posted this article on ‘slow AI’ on my website, and had Brid.gy automatically post it to my Twitter account.


the tweet, notice the repost and likes.

On Twitter people responded, with a repost and 2 likes.
Which Brid.gy sends back to my site, so I can show it underneath the original article:


the article showing the repost and likes as well

Through this, I can use Twitter to reach people and interact with them, without actually going to Twitter myself. I post on my site, it gets automatically sent to Twitter in the background, where people respond, which I see directly on my own site as incoming reactions. A full conversation on Twitter can be done completely on my own site this way. When Twitter dies, which it will, they will take all their data with them and all conversations will be lost. Yet, my Twitter interactions through my blog will remain available to me. Losing conversations isn’t necessarily a bad thing, but I’d rather decide myself which conversations to keep and which to remove, than let some third party or outside event be the judge of that.

Backfeed is an emerging key bit of internet plumbing, much like RSS already is for a long time. Making that plumbing easier will be of tremendous use.

Some links I thought worth reading the past few days

  • On how blockchain attempts to create fake scarcity in the digital realm. And why banks etc therefore are all over it: On scarcity and the blockchain by Jaap-Henk Hoepman
  • Doc Searl’s has consistently good blogposts about the adtech business, and how it is detrimental to publishers and citizens alike. In this blogpost he sees hope for publishing. His lists on adverts and ad tech I think should be on all our minds: Is this a turning point for publishing?
  • Doc Searl’s wrote this one in 2017: How to plug the publishing revenue drain – The Graph – Medium
  • In my information routines offline figures prominently, but it usually doesn’t in my tools. There is a movement to put offline front and center as design principle it turns out: Designing Offline-First Web Apps
  • Hoodie is a backendless tool for building webapps, with a offline first starting point: hood.ie intro
  • A Berlin based company putting offline first as foremost design principle: Neighbourhoodie – Offline First
  • And then there are Service Workers, about which Jeremy Keith has just published a book: Going Offline
  • Haven’t tested it yet, but this type of glue we need much more of, to reduce the cost of leaving silos, and to allow people to walk several walled gardens at the same time as a precursor to that: Granary

Is this why Bridgy can’t find my web address on Twitter and returns an error when I try to post to Twitter from my WordPress blog? Bridgy expects a rel=”me” reference to my site’s URL on both my blog and my Twitter profile. I have that, but the Twitter one is a t.co shortened version and only shows my actual url as title, not as the link. Like rel=”me” href=”https://t.co/OaBGAJ7WV6″ title=”https://zylstra.org/blog”. So no 2-way confirmation of the relationship? [UPDATE It’s a missing www on my site. Tested with indiewebify.me and works now]