## Keeping it personal

I just read this great essay by Matthias Ott. It does a great job of summarizing the state of affairs of blogging and social media, and how we can try to escape the current orbit to get back to where the web was meant to be.

I especially like the bit about “Don’t do it like me. Do it like you.” Because that is exactly why I’ve been building Publ the way I have; I have specific goals in mind for how I manage, maintain, and organize my site, and these goals are very different than what other existing blogging and site-management software has in mind. The fact that I post so many different kinds of content and that they need different organizational structures to make sense makes this a somewhat unique problem. I’d like to think that Publ is a very general piece of web-publishing software, but it’s probably so general because I have such specific needs. Which makes for an interesting paradox, I suppose.

I guess what I’m saying is that I want to see more types of web-based publishing where the schema and layout fit the content, not the other way around. But it also needs to be able to interoperate with other stuff, while still making sense from a producer-consumer UX perspective.

One thing that somewhat bothers me about the current pushes in the independent web is that rather than being personal spaces for people to carve out their own niches, they’re instead independent alternatives to the so-called siloed providers such as Twitter and Facebook. While they’re way better due simply to having actual governance and notions of community and so on, they’re still fundementally a stream of updates from people, and there isn’t really room to share things that don’t fit into the firehose-of-short-updates setup. Some Mastodon instances like dragon.style try to, um, spread their wings (so to speak) by having support for longer-form posting, but that doesn’t really fit in with the UX model of Mastodon in general.

I see a really strong distinction between the actions of “following” vs. “subscribing” to content. When I’m following a comic or a long-form blog or a news site, I’m subscribing to it; I expect to see all of their posts, ideally in chronological order, and with the ability to quickly decide whether it’s something I’m going to look at or skip. When I look at it, I’m going to look at it in detail, possibly on the originating site, but I definitely want to see a summary or 20,000-foot view or the like so that I can decide whether I’m going to read, skim, or skip.

And there’s definitely a space for microblog-type updates like Twitter or Mastodon or… half of Tumblr. But I see those as more of a chat that you can dip in and out of. I have absolutely no interest in reading my entire timeline on services like those, and I really don’t understand how so many people actually can expect to read everything. Microblogging/stream-of-updates sites are very much “in the now,” rather than something that’s intended to have posterity and continuity.

Ever since my ActivityPub rant I’ve learned that my gripes with ActivityPub are really mostly gripes with Mastodon (which happens to be the primary example of what ActivityPub is used and designed for); ActivityPub as a protocol can certainly be used to provide things similarly to RSS/Atom/h-feed. But the design of it is based on the assumptions that things are going to be a timeline stream of updates, things posted in-the-now, things that you consume briefly and then don’t keep around forever. There isn’t much of a provision for things like getting a backlog, or having multiple categories of updates, or backfilling a subscription after having missed an update, or whatever. The protocol is incredibly push-based, which is great for certain use cases – particularly ones that I’m referring to as “following” – but not so great for long-form structured content like webcomics or the like.

This site publishes to ActivityPub using Bridgy Fed and so far it doesn’t actually seem to work all that well for, well, anything. There’s a gigantic impedance mismatch between the concept of this-site-as-content-store vs. things being subscribed to as in-the-now updates. When I backfilled updates, it ended up spamming everyone who was subscribed to the ActivityPub feed with really old stuff, presented in the mostly-random order that the backfill script encountered it. This wasn’t good UX for anyone.

But if I’d only pushed forward new updates, then someone trying to read this site via ActivityPub wouldn’t be aware of anything that existed previously. And this is probably more a limitation of Bridgy Fed than ActivityPub but I have no way of providing different streams of updates; my comics and music and photography and so on are all intermingled in a single stream of updates. That’s fine for when people are following my content for updates, but not so useful for exploring things, or for looking back through the timeline.

In principle, an ActivityPub reader could provide a proper ordered timeline, but then that means that when some new content is published, it’ll only be seen if it happens to appear with a timestamp that’s newer than the rest of the stream of activities. Maybe a heuristic could take care of that, but it’s not a use case that’s really expressed by the tooling that’s available.

What I like about Atom (and RSS and h-feed) is that it provides a structured means of discovering new content, while also keeping it in the context of the site’s own updates. A feed reader which implements archive backfilling could very well consume all the content on my site (and categorize it all into separate feeds as appropriate) and provide a mirror of it, to be read at someone’s leisure. Jamey Sharp has a prototype for a reader that does exactly that.

Feeds can be used to support both subscription-type reading and follow-type reading, as well. As the IndieWeb grows, a lot of people are using it to implement stream-of-updates type functionality, and Webmention seems particularly geared towards that. There are a lot of folks who I’d love to follow, but don’t necessarily want to subscribe to; fortunately there are IndieWeb-focused readers that are also providing that sort of UX, such as Monocle+Aperture. Personally I’d love to have a single dashboard which provides the trifecta: chronological/inbox-based subscriptions to some feeds, timeline/flood-of-updates follows of other feeds, and the ability to post quick boosts/favorites/comments via Webmention and Micropub. (Ideally to a feed that’s separate from my main site feed.)

Oh, but then that’s multiple feeds, which cause their own UX headache. When someone wants to subscribe to what I post, they can subscribe to http://beesbuzz.biz/feed and they get all of my subscription-style content, and then my IndieWeb identity is http://beesbuzz.biz/, which provides that as its feed URL – but then if I were to have another separate feed for more spammy/smaller/Twitter-style updates, that adds some more UX difficulty. Do I provide both feeds from http://beesbuzz.biz/ and hope that peoples' readers provide a choice of subscription options? Don’t I want this stuff to be on a separate “landing” site though, like another subdomain? But then does that subdomain become my identity? This all just gets weird when you dig into the technical details when trying to reconcile what the interface to others looks like.

For now I kinda-sorta have the update stream living in my chatter section but that still shows up as a subcategory of my main site; the way my feeds are structured, it’s very easy to choose to only see that, but not to choose to not see that. But I don’t really want to subject people who subscribe to my blog to see all my random comments as well. I could make my normal feed filter out that section and have people subscribe to the chatter feed separately, but that’s not really that different from the other issue.

And even then, the way that “chatter” works is regrettably much like how Tumblr works; Tumblr is in this weird middle ground between follow-type and subscribe-type content, where boosts/replies/comments are all seen as streams of updates as entirely separate items. Popular items end up showing up on my dashboard dozens of times, usually with different variations of the conversational thread. It’s very overwhelming and doesn’t lend itself very well to actually being followed. And then on Twitter you have fragmented threads with and without quote-tweets, and Mastodon tries to solve that by only doing threads but because of how federation works you still don’t see all the replies and the UX just makes following a conversation hard. Threaded comments like Disqus work so much better for actually having a conversation. Webmentions are basically Tumblr. I like them for notifications of being talked about but trying to have a conversation through them is just… well. See for yourself.

Tumblr does provide an RSS feed, and for a select few Tumblrs I subscribe (via FeedOnFeeds), rather than follow (via Tumblr’s dashboard), but many of those creators (comics especially) end up working around Tumblr’s follow-based nature by forcibly reposting each of their updates multiple times a day, to ensure their stuff doesn’t get lost in the chatter. Which means when I subscribe via RSS I end up seeing every single one separately, because even if they self-reblog, each entry looks fresh and new. And this is a very difficult problem to solve!

So, the impedance mismatch between what a cartoonist needs to do to be seen on the native format (Tumblr) and what people on other platforms makes for a bad experience for everyone.

For now I am content to post my content to my site with feeds that people can subscribe to, or they can follow it via any number of update mechanisms (such as my POSSE to Twitter/Mastodon/Tumblr or the Bridgy Fed ActivityPub feed which I don’t even know how to link to outside of a Mastodon context, because holy heck that’s another gigantic impedance mismatch) and I can hope that people follow my stuff in whatever way suits them best. But there’s got to be a better way.

The web is very fragmented between publication and subscription styles, and there’s impedance mismatches between what’s good for creators and what’s good for platforms, and the UX that emerges in the intersection between the two only makes things more inelegant. It feels like hacks all the way down.

I keep saying how I’m going to write an article about these impedance mismatches, and I sort of ended up falling into doing that with this unstructured ramble. It isn’t particularly well-organized, though, and I need to give it a second draft eventually. I expect most people will have gone into skim mode by now. I certainly would have.

So, just think of this as a rough draft for a better article to come. In the meantime, my comments (and webmentions) are open.

Addendum: I should mention (mostly for my own future reference when I revise this into an actual article) that while I appreciate WebSub as a protocol for making “follow”-type updates easier to handle (in that you get fast push if things are working but if they aren’t the failure mode is a slow pull with eventual catching-up, rather than losing stuff entirely or dealing with cruddy retry logic), for subscription-type updates it’s not really necessary anyway. It’s Nice To Have™, but I could absolutely live without it. It does save a small amount of HTTP traffic (which doesn’t matter in the grand scheme of things) and it’s a bit friendlier than having to implement cache-control correctly (which is hard!) but mostly it doesn’t make any real difference in a subscription-oriented model. But it’s not like it hurts anything, either.

That said, it makes a huge difference in a follow-oriented model, and for people who want a sip-from-the-firehose stream-of-follows experience using protocols that are much easier to implement than ActivityPub, it’s absolutely a good thing.