Like Barriers to a more social indieweb – Tracy Durnell...
Tracy and Sara have been posting about social norms with a specific view to the indieweb.
What caught my attention in Tracy's latest was the question:
Does the indie web – or the indieweb – feel enough like a place to organically foster norms for interaction, or do we need to be deliberate in crafting them?
To add context she says:
I use indieweb to refer to the set of protocols enabling personal websites to interact, especially Webmentions, as well as the community of people active in working on and using them. When I use lowercase “indie web,” I'm referring more broadly to the entire realm of independently operated, largely personal websites beyond corporate silos.
This is an important distinction.
The "indie web" is too large and diverse (topically, culturally, geographically, I could go on) to expect any single social norm to develop or be adhered to. As is made clear, our expectations of "norms" vary based on age, experience, the platform or medium, and the culture within which they are established.
You might propose a baseline of "don't be a dick" but certain online communities embrace being idiots/abusive/offensive – that is their social norm.
I am reminded of Rebecca Blood's statement in The Weblog Handbook when considering your audience: "Your only objective is to avoid sorely offending them."
Not going to fly in certain circles.
Over a decade ago, I wrote about the functionality within competing apps causing social norms within them: app X has feature A so apps Y & Z had better develop it or get left behind. This isn't so much copying your competitors but meeting the expectations of your users. Such functionality, however, while "matching" is siloed so not entirely applicable.
Tracy focuses on indieweb technologies in her post and how they might foster or affect social norms but rightly surmises that their very nature likely precludes such norms.
The indieweb encourages the plurality of "approaches and implementations" rather than a monoculture where participants "build what works for them, and then figure out how to interoperate between different coding/implementation approaches". A number of standards exist for technical implementation but not, as Tracy discusses, for presentation. As such there can be no set expectation for how something will look or be treated. How do you create a social norm under such conditions?
The indieweb is not a "place" but an idea and it does not have sufficient adoption and momentum to become one. This in itself causes issues. What it means to be part of the indieweb itself is not set in stone, it is a guiding principle and there is no requirement to implement specific technologies. Without doing some digging, you can never be sure if a site implements specific indieweb technologies 1 and so will play nice with yours. Not to mention the inconsistency in presentation.
"Guiding principles" mean that there is a lot of room for individual interpretation about what should and shouldn't be part of the technology. Take the "nomention" idea. Tracy writes:
There could also be times when someone might want to link to a page or post without sending that site a Webmention – the equivalent of a nofollow link, but for mentions.
I had this idea back in 2018. It was decided not to include my request for such functionality in the WordPress Webmention plugin: rather than just a feature it was adding a new property to webmentions which needed more community discussion. That it is still being independently pondered five years later indicates that such community discussion has either not happened or deemed it not necessary but not publicised that decision.
I wrote a plugin to implement it for my own uses but have no idea if it still works.
While my initial usage scenario was to prevent duplicates (where I might be mentioning a conversation on micro.blog and didn't want it showing as a post and a reply) some consider a nomention, or submention, analogous to the subtweet which is considered bad practice.
Different strokes.
Unless the indieweb "community" defines standards for presentation and behaviour rather than just technical interoperability (which flies in the face of plurality) I don't think you'll ever establish social norms in this regard. One person's expectations will not necessarily match another's implementation.
I think that's why I stopped making a big thing of it a while ago despite persisting with webmentions.
-
although you could repurpose the old joke: How do you know if someone is a vegan? Don't worry, they'll tell you. ↩
Looking back, I see a journey that has taken twists and turns and doubled back on itself.
Six years ago today I first considered building an integrated RSS reader after realising that this was the way to go a week or so before:
"my initial reaction was a combined feed reader/blogging environment"
It took me nearly five years to reach the point where I could actually build it.
I wanted a tool within which I could directly react to posts in my feeds but this only works properly if both sides support webmentions.
Yes, I can take actions in /reader and they will show as posts on the blog but the other person may never know. That's the big problem with relying solely on indieweb building blocks: scope and reach.
I recently built /updates which only shows me which feeds have new items so that I can follow links to see them in their native environment. I was unhappy with the homogeneity of seeing everything displayed according to my own style preferences.
This, obviously, put me right back to where I was before /reader – reading and responding as a multi-step, multi-system process. Maybe, with current restrictions, that is how it should be. I could add a fallback that sends pingbacks (where supported) if there is no webmention endpoint but is that the answer? 1 I mentioned before that using /updates means I leave more comments at the original source – surely that's a good thing.
Does every response I write need to be held on my own site? No, absolutely not. Do those who read my words need to know about everything I reply to? Again, no. If I want to keep track of specific replies and/or conversations there are other ways to do so.
The idea behind an integrated reading and writing environment is still valid, even desirable, but there isn't the technological consistency to make it truly viable. Web wide interoperability is a nice goal but is it really necessary? We have come this far without it. Would requiring that everything can talk to everything else stifle innovation?
Even if I appear to repeatedly contract myself or my previous actions I will keep doing what feels right at the time. It doesn't mean it was wrong, but it also doesn't mean the new way is right. I reserve the right to change my mind, as well all should. I can only pose questions, it will take those far wiser than I to answer them.
-
I probably will anyway ↩
PHP-MST has completely stolen my spare cognitive resource, creating the standalone, file-based version of /reader has taken a back seat.
I know why:
- it's easier to build, and
- because it is a riff on Andy's node.js app there is a social element to its development
The indieweb movement preaches scratching your own itch but it's often more fun to collaborate or do something in tandem – even if you're working on separate things the interaction between them adds extra fuel to the creative fire.
Still, once I've gotten this to the point I will share it with the world, I will be able to take certain things I've learnt back to the other project. It's productive procrastination.
Bix wrote about the idea of universally followable /now pages. This notion is a replacement for / addendum to an idea he previously had about a site or service that would show you when people have made updates to their info rather than what those updates actually were.
The key is that it would let the individual explore those updates in their own time. They are given the minimum information required rather than be overloaded.
He says:
"So that's my pitch to the /now page community: develop tools that publish these pages not just to a webpage but to RSS and/or ActivityPub, as well as tools to markup, perhaps using some kind of microformats, the underlying HTML in ways that would allow for a crawler to parse them even absent an RSS or ActivityPub feed."
Microformats2 certainly could work. There are already indieweb tools that parse pages based on markup, like monocle but RSS is far more familiar with much wider adoption. Even if people persist in saying social killed RSS or that it died with Google Reader.
Using rssCloud to push updates (I wish more feeds supported it) would be a nice addition.
This got me thinking about feed readers. They became popular because of their killer feature: convenience. They bring everything together in one place allowing the consumer to easily scan updates from multiple sources without having to navigate halfway across the web.
Feed readers also homogenise content, displaying it according to local preferences. Links will always be the same colour and other elements, like blockquotes, will always look the same. It reduces the cognitive load when consuming posts from multiple and varied sources.
But is this always a good thing?
I've written before about trying to shift away from posts just being "social units" in a timeline – that is one of the big disadvantages with certain social networks: all content is rendered the same. Also mentioned in passing before.
It makes me wonder if we're 'doing it wrong' with feed readers.
The homogenisation of post content means we lose the personality behind the words. As I have previously quoted Robin Sloan: "presentation is a form of content" – abstracting the content from how it was meant to look can do it a disservice.
I have been intrigued by the idea of having "less of an emphasis on the actual consumption itself within the reader – more of a notification system" and Bix's post brings me back to this.
The menu tray for /reader is just a list of blogs with an indication of unread posts. What if this was all it did? Just told you someone had updated their site and it was up to you, the reader, to go off and find out what.
I wondered if this approach might cause me to read less due to the loss of convenience. Conversely, it might make me interact more, leave more comments, as I would already be on the host site.
I posited an alternative view for /reader 7 months ago (wow, was it really that long) but nothing ever came of it. Now, however, I think the time is right to return to it and see what I can come up with.
Something seems to be coalescing across the web. Strands are coming from different areas and angles but meeting in the middle. I'm talking about the idea of a single timeline – and that doesn't mean just using one social network.
One timeline for each user. Lots of choice, but one timeline. And there has to be a basic agreement on what goes in that timeline. What are the elements of a message. A way to define more types, without going to a standards body, which always crush the individual in favor of the bigco's. Something minimal, orderly, easy to document, lots of example code.
Craig Hockenberry, from The Iconfactory, said something similar:
One thing I've noticed is that everyone is going to great lengths to make something that replaces the clients we've known for years. That's an excellent goal that eases a transition in the short-term, but ignores how a new open standard (ActivityPub) can be leveraged in new and different ways.
Federation exposes a lot of different data sources that you'd want to follow. Not all of these sources will be Mastodon instances: you may want to stay up-to-date with someone's Micro.blog, or maybe another person's Tumblr, or someone else's photo feed. There are many apps and servers for you to choose from.
It feels like the time is right for a truly universal timeline.
The current buzz is around ActivityPub (and its poster child, Mastodon) but it doesn't have to be based on this; any way for systems to talk to each other and get information from point A to points B, C, D... Write once, broadcast to many, whatever they are using. Conversely, you need to be able to get stuff from B, C & D all fed back to A – again, no matter what everyone is using. Like blog posts in a feed reader. I've always said that I like micro.blog because it acts as a social feed reader rather than just a siloed network.
I've taken a look at ActivityPub on a couple of occasions and found it far too confusing to even consider implementing it. As much as I like the indieweb ideals a lot of them are also beyond me.
Dave has been reiterating how RSS is a way of moving data around the web and that current uses are too narrow-focused. It's great for subscribing to blogs and podcasts but could be used for so much more with a bit of vision.
I was curious, therefore, to see Andy Sylvester mention he was working on something with the working title "MyStatusTool" – a Twitter like interface powered by RSS and using rssCloud to get everything updated. He may be starting with "a text box to enter a short post" but the potential applications are so much wider.
One to watch.
