During the introductions at IndieWeb Summit, Malcolm Blaney showed his site Unicyclic, which is set up as an IndieWeb reader. He has an overview page of recent IndieWeb related postings. To have your own postings incorporated, you need to follow his IndieWeb page and send it a WebMention. Upon receiving the WebMention it will look for a feed to follow on your own site. That sounded like a fun thing to try.
I started supporting the IndieWeb with a small monthly contribution. You can do too if you want.
Brid.gy is a service that lets you connect both ways to various silos and social media platforms. I for instance use it to post to Twitter from here, and provide back Twitter’s interaction to my own site.
What stands out is that there is linear steady growth. Also the closing down of Facebook’s API and the closing of Google Plus are nicely visible as ‘saw tooths’ in the graphs.
Bridgy stats time!
Looking at the graphs, the elephant in the room is clearly the Facebook shutdown. It was Bridgy’s second largest silo, numbering 1477 users when we wer…
Frank Meeuwsen pointed me to this article by David Yates, which contains explanations of IndieWeb components and their purposes, for less tech-oriented people. It concludes that, yes IndieWeb has a wide range of cool features, that let you use the Web itself as social medium, but that implementing them requires tech skills. It works very well for online interaction, “but the only people you interact with are other programmers who’ve also managed to implement all this stuff.”
Which is a good reminder to self. I’m not one of those ‘other programmers’, though I can keep up with tech oriented conversation. Which makes me a bit of a boundary spanner, between the techies and the less tech oriented. Given Peter’s notion of having an obligation to explain, I already had half baked plans to start writing a few explainers. While reading this blogpost by David Yates I had some additional ideas of what that should/shouldn’t look like. And that it should be in both Dutch and English. So thank you David for the nudge.
Meanwhile, I have E as an in-house ‘tester’ to see if my explanations work, and if I understand things correctly myself, while we are indiewebyfying her websites.
I’ve been peripherally aware of the IndieWeb movement for a few years now – mostly because they seem to like RSS almost as much as I do – but I’ve only recently dug into it. In a nutshell, IndieWeb is about using the World Wide Web itself as a social network, through a set of open standards …
Private posts is something I’d like to have too. In WP it is possible, by having posts you need a login for. Finding a way to smooth that, which doesn’t require me to have other people having an account here, would be great. Automating IndieAuth access looks like a viable path.
However, private posts is just a first step in my mind. On my wish list is a deeper form of allowing selective publishing: private elements in otherwise public postings. Where one site visitor might read ‘my daughter’, friend might read her name. Where other read ‘a client’, colleagues would read the organisation’s name. Building a smooth spectrum from fully public to fully private. Along the lines of how we in conversations also continuously switch between different degrees of disclosure, and not just between conversations.
Recently, the call for private posts became louder again. Aaron Parecki is trying to get a group of people together to exchange private posts between Readers. I would like to be one of them…
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:
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.