Some template changes

I’ve changed my site templates a bit more, to make CWs work a bit better. In particular, now entries which have a CW will also hide the text behind a <details> on the page (for example), and similarly I’ve hidden CWed images on individual comic pages (for example). Comic images will also (finally!) be blurred in the OpenGraph tags, as well, after one too many “oops"es when posting links to Slack demonstrating how my CWs work.

I’ve also improved compatibility with Bridgy Fed and with the way that webmention microformats are supposed to work in the first place, per a conversation in which I learned that I wasn’t actually using reply types correctly. (You may have noticed a bunch more micro-posts on the chatter section as a result of me fixing this as well. I also need to finally implement a thing so I can properly filter that stuff out of the little "latest posts” box on the main page!)

The sample templates repository has been updated, accordingly.

As always, thanks to the various IndieWeb folks, especially Ryan and Kevin for setting me straight on this issue.

Edit: It didn’t take me very long to implement the Publ feature change. I went ahead and cleaned up a bunch of query generator code while I was at it. Also I think I found a bug in PonyORM. Nope, I think I was just being hopelessly optimistic about a thing.

You can now use IndieAuth to login to this site

I’ve released a new version of Authl that has direct login support for IndieAuth. Also as of v0.1.6 it supports discovery via WebFinger, which should at least have Ryan a lot happier.

If you don’t know what any of the above means, this update probably doesn’t matter to you. 🙃

Slowcial networking

Over on IndieWeb Chat, Kevin Marks linked to this wonderful essay about social media that is absolutely worth reading, and examines a part of the “personal social networking” thing I’ve been on a kick about lately but didn’t quite have the words for.

For me, a big part of the problem with social media as it stands today is that everything’s about fast, immediate, in-the-moment dissemination of Hot Takes and viral propagation and so on, and that’s a design that so many of the other indie-focused social networks are trying to replicate. I’m not much a fan of microblogging or protocols which exist to make it the norm (which is why I’m still not particularly interested in supporting ActivityPub natively in Publ!) and I like being able to take some time to expand on my thoughts and not have to chunk things up into 280-to-500-character chunks and worry about fixing my spelling and grammar and phrasing right then and there.

I like being able to sit on things for a few days, and add addendums without it being a whole new post, and I like having feedback come slowly and measured. Yes, I get quick replies and a variety of favorites-like reactions via Webmention and other things, and I do appreciate that in this little nichey corner of the web this is a way that people can interact with me, but I’m not really writing for an audience so much as writing for me and my friends, and hoping that the things I write also maybe resonate with folks who happen to read it.

I still use Twitter and Tumblr and Mastodon quite a lot (much more than I’d like, really) but that’s not how I prefer to interact with folks. I don’t even try to read everything that people post there, and I have no idea how anyone can think of timeline-oriented streams-of-updates services as a place where you’re going to be able to. I just occasionally glance at them to see what’s going on and maybe interact with others in the moment, and spend much more time wondering why the hell I even bother trying to communicate in that way beyond “it’s how everyone else communicates today.”

My big concern about my blogging habits here is that I’m mostly talking about the platform itself. Blogging about blogging is so dreary. Hopefully soon the new-toy shininess will wear off and I’ll get back to using this as a means of talking to my friends about other stuff. I certainly have a lot of other stuff coming down the pike, at least. Hopefully some of it turns out well.

I guess it’s mostly just that what I have to write about is what I’m working on, and this is (mostly) what I’m working on. If I were working on other things they’d be getting posted to other parts of my site.

Not-unrelatedly, I really want to get back into making comics.

My webmention endpoint wish list

While it has some rough edges, the Webmention protocol has a lot going for it. One of the nice things about it is that it’s easy to add support via a third-party endpoint, such as webmention.io, which is what I (and many others) use.

There’s a few things I wish were better, though, and I think these can all be addressed by the endpoint itself, while remaining within the specification as it’s written today. I would be tempted to write an endpoint that works this way, if I weren’t already overwhelmed with other projects.

  1. Definitely support the webmention.io API. There’s a lot of folks already using that to retrieve mentions to display them on their site, and I see no reason for that to change.

  2. Having some form of moderation would be nice. Mentions at their core should be kept perpetually but with a disposition of accept/reject/pending, and domains should also have a default disposition (which defaults to pending). When a new webmention comes in, it should get the domain’s default disposition (along with an unmoderated flag), and then when moderating them, the user should be able to change the default disposition for the domain.

  3. Mentions should be periodically refreshed to see if they’re still valid. The refresh interval can be some form of slow exponential growth, like the Fibonacci sequence or something. Whenever the status of the mention changes, that should reset the refresh interval. Mentions which have disappeared should not be rendered while they’re invalid, and the moderation queue should also show a section for “approved but disappeared” mentions.

  4. When a mention is sent or refreshed, it should also get a source and destination pointer; track the mention in terms of the original URLs provided, but they should be displayed and fetched based on what their current URL is, after chasing redirections or the like.

  5. Relatedly, multiple incoming mentions should be consolidated based on what their source and destination URLs resolve to. For example, if Alice pings Bob from http://alice.example.com/1/first-entryhttps://bob.example.org/blog/hello.html, and then Alice’s URL updates to https://alice.example.com/blog/1/First-Entry, if Alice’s site re-sends backfill pings, the endpoint should only report a single ping that comes from https://alice.example.com/blog/1/First-Entry. Likewise, if Bob’s URL changes to https://bob.example.org/weblog/hello, when Bob’s site retrieves mentions for the new URL it should also include mentions that went to the old URL.

    Obviously for this case there will be a period of time between a site’s URLs changing and the original pings being refreshed, but maybe a new mention to an older target can also trigger a refresh of existing mentions to see if they’re subject to consolidation.

    Also the consolidation should only happen at the retrieval level; the original source/destination URLs should always be preserved, since it’s always possible for an old URL to become unique again.

  6. There should also be some automatic consolidation of pings that have the same URL aside from the scheme; webmention.js handles this on the rendering end but it’d be nice if the endpoint could do this automatically. For example, if a ping comes in from both http://example.com/12345 and https://example.com/12345, they should be consolidated to both have come from the https: version, probably. It would also probably make sense to do some sort of intelligent auto-consolidation based on domain aliases, like www.example.com vs. example.com. (8/28/2019 update: Or use <link rel="canonical">.)

  7. Support for private webmention.

  8. Support for Vouch, both from a validation perspective and providing UX to make it easier for folks to present their whitelist (like maybe when a domain is whitelisted it can also be added to a vouch list).

  9. Also maybe some form of conversation threading would be nice? I’m not sure how that could be reasonably implemented (aside from supporting Salmention and hoping others come along with that) but it’d do a lot to address the UX problems with Webmention as a conversational platform.

Addendum to the previous

Kevin and Ryan raise some very good points about where OStatus went wrong. I absolutely agree that Webfinger is a terrible approach to identity brokering (and I have a lot of problems with the /.well-known thing in general), and while I haven’t looked seriously into Salmon because it seemed unnecessary, it also sounds like it was a major pain in the butt to deal with on top of that.

What’s frustrating to me is that Mastodon (and possibly ActivityPub itself?) makes Webfinger absolutely necessary to support (and provides worse feed discovery/modeling as a result!), and I believe it does something Salmon-esque for conversational threading as well (although I’m sure someone will correct me on this point).

Meanwhile, another reason to avoid ActivityPub is that things like this are necessary.

A long-winded IndieWeb ramble I wrote on the train back from Portland

(This is a somewhat-edited version of a disconnected ramble I posted on Twitter/Mastodon while on the train home today. I feel like putting this somewhere that I own it, but am not in a good enough mental state to actually write it properly.)

Yesterday at IndieWeb Summit, someone – Aaron, I believe – mentioned that one of the big differences between IndieWeb initiatives and ActivityPub is that IndieWeb is made up of simple building blocks you can pick and choose while ActivityPub frontloads a lot of complex work. This is a sentiment I very much agree with and it’s unfortunate that the main reason Mastodon switched from OStatus (which is very IndieWeb-esque) is because it made it slightly less inconvenient to pretend to have private posts. Which aren’t even implemented that well.

Mastodon’s “private” posts really suck from a bunch of standpoints. There’s no ability to backfill or even view on web without being on the same instance, and Mastodon’s actual privacy controls go in the wrong direction, so it’s still necessary for a separate vent account. As usual I don’t know if this is a problem with ActivityPub itself, or an artifact of how Mastodon shoehorned its functionality into ActivityPub, but either way, the end result is that Mastodon’s post privacy isn’t really all that useful, nor is it really all that private.

So, right now ActivityPub is the darling of the fediverse, but I’m hoping that the current push toward AutoAuth and trying to use it as a basis for private webmentions and the obvious next steps of private feeds and private WebSub will change that. I do worry that IndieAuth/AutoAuth are kind of hard to do in piecemeal ways though (well, okay, IndieAuth becomes really easy using IndieLogin but I don’t want to see a single endpoint become what everyone on the Internet relies on). And of course once you get into an integration between auth stuff and content stuff you also need to worry a lot more about content management and how it integrates, as well as this seeming fundamentally incompatible with static site generation.

At the Summit there was definitely a lot of compromise that people were doing, such as using Javascript libraries to introduce externally-hosted dynamic IndieWeb stuff onto statically generated pages. I think in this world where SSGs can be supplemented with third-party endpoints that use client-side JavaScript there could be a world where some level of privacy can happen via clever use of client-side includes of data at non-public unguessable URLs. (Although the ideal solution for that is to use the third-party APIs to generate webhooks that then trigger a file change → git commit → commit hook → build/redeploy.)

Non-public unguessable URLs aren’t great for privacy in general (and I mean, Publ has had “privacy through obscurity” since day one and there’s several reasons why I rarely use it anyway) but it’s at least better than nothing.

Read more…

IndieWeb Summit day 2: Authl finally gets some love

One of the biggest bits of functionality I want to get in the next milestone for Publ is private posts. Doing private posts requires some way of determining the identity of the person who is reading the site. There are a lot of mechanisms to choose from. Most of them are largely incompatible with one another, and there isn’t any single mechanism that checks all my boxes. And of course the standards keep on shifting, and keep on getting a new unifying standard that will fix everything.

So, IndieLogin is a really great way to get started with IndieWeb authentication for people who are in the IndieWeb ecosystem. If you have your own website on your own domain name and an account on one of its connected RelMeAuth providers, it covers everything. But not everyone who I want to grant stuff to has their own website, or the ability to set one up. Siloed OAuth is still useful. And being able to log in via email address is also beneficial.

Read more…

RSS: there’s nothing better

David Yates wrote a great defense of RSS which I completely agree with. To summarize the salient points:

  • RSS is open
  • RSS works
  • RSS is very well-supported by a lot of things
  • RSS is a suitable name as shorthand for “RSS/Atom” because the name “Atom” is overloaded and basically anything that supports Atom also supports RSS and vice-versa

(Note that there’s one inaccuracy in that since that article was written, Twitter has moved over to algorithmic manipulation of the timeline. This can currently be disabled but who knows how long that’ll last?)

Most IndieWeb folks are also really gung-ho about mf2 and h-feed, and while I don’t see any reason not to support it (and it certainly does have some advantages in terms of it being easier to integrate into a system that isn’t feed-aware or convenient to set up multiple templates), I’ve run into plenty of pitfalls when it comes to actually adding mf2 markup to my own site (for example, having to deal with ambiguities with nesting stuff and dealing with below-the-fold content, not to mention a lot of confusion over things like p-summary vs. e-content), and so far there doesn’t seem to be any real advantage to doing so since everything that supports h-feed also supports RSS/Atom, as far as I’m aware.

For me the only obvious advantage to h-feed is that you can add it to one-size-fits-none templating systems like Tumblr where you don’t have any control over the provided RSS feed, but in those situations there’s not really a lot more added flexibility you’re going to get by adding h-feed markup anyway. I guess it also makes sense if you’re hand-authoring your static site, but that just means it becomes even easier to get things catastrophically wrong.

Read more…

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.

Read more…

Reblob!

Reblob!:

It’s been a while since I’ve worked on IndieWeb stuff, but I finally got around to releasing an extremely preliminary version of reblob, a little commandline thingus to make this stuff easier. Eventually I’ll also have a server-based version here, at least as an example.

Of course this is the first entry I’ve written actually using it. Lots of rough edges but whatever!

Medium tedium

Repost: https://micro.coyotetracks.org/2019/04/13/medium-thinks-its.html

Watts Martin writes:

There’s a lot of reasons people are down on Medium, Ev Williams' ongoing whatever-the-hell-it-is. It’s a platform! It’s a publication! It’s a platform for publications! It’s a clean, clutter-free reading experience, except for all the clutter!

There have been a few great stories written about this; my favorites are reporter Laura Hazard Owen’s “The long, complicated, and extremely frustrating history of Medium” and acerbic typographer Matthew Butterick’s “The Billionaire’s Typewriter.” (He occasionally updates this, most recently linking to Owen’s article.) Butterick critiques Medium’s design from an ethical standpoint, which turns out to be bang on point with Medium’s ultimate underlying problem:

Medium thinks it’s a brand.

The rest of the entry is very much worth reading, and is a great description of all the things I hate about Medium and why I wrote Publ and insist on hosting my own blog instead. And I’m sure is why there are so many other self-hosted blog engines available and getting stronger these days.

Read more…

Tag-reply posts?

In response to my tagging announcement, Marty McGuire writes:

This could be a use case for tag-reply posts!

Brid.gy supports this for tagging people in Flickr posts, as well as adding labels to GitHub issues.

(wow I really have got to write some sort of reply-to post importer… hand-converting that to Markdown was way more work than it should have been!)

I’m not quite sure I understand the use case that’s being called for, here. Publ tags are “tags” in the Tumblr sense, where they’re used to filter and organize posts, like being able to limit things to rants or whatever; I get the feeling that this is confusion over multiple uses of the word “tag,” like how on Twitter/Facebook/Flickr/etc. “tagging” means signaling to someone that they should read a post (akin to “Tag! You’re it!”). Think Technorati tags from way back when, or Atom categories, which are most akin to hashtags on Twitter and Facebook.

I think a tag-as-in-notification thing would be implemented in Publ the same way I implement in-reply-to and so on – I have a corresponding header in the entry file and my template generates an invisible <a class="u-in-reply-to" href="..."> in the post body. The relevant bit in my entry template is:

{% for type in ('like-of', 'in-reply-to', 'repost-of', 'bookmark-of', 'mention-of', 'rsvp') %}
    {% for link in entry.get_all(type) %}
        <a href="{{link}}" class="u-{{type}}"></a>
    {% endfor %}
{% endfor %}

So in that sense Publ already supports that at the template level; I can simply add tag-of to the list of microformat types. Or am I completely misunderstanding what is being suggested?

So what is Subl, anyway?

So I’ve been talking about distributed social stuff a lot lately, especially Publ (my publishing engine, which runs this site, in case you are new here), and also ecosystem stuff for things like private entries and other things that have been pinging around in my head for a while.

A thing I keep on mentioning is Subl, but generally only talking about it tangentially without actually going into detail with what it even is. So, I guess I should talk about that at some point.

Read more…

The authenticated Atom musings continue

Now that I’ve had a chance to think about this more than what was afforded by a quick response fired off between songs at a karaoke bar, I feel like expanding more on the details that I’d only implied (and probably badly) from the previous post. So, here’s how I think things could look.

Read more…

Federated access control with Atom and WebSub

I’ve been ranting about ActivityPub vs. RSS/Atom a lot lately, and I think I’ve proven to myself (and maybe a few others) that for fully-public content feeds, Atom (combined with WebSub and WebMention) is superior to ActivityPub; it’s simpler to implement, works with many more hosting environments and configurations, it generally scales better (and handles scaling failures better), and it’s modular and allows for much eaiser migrations between hosting setups and so on.

But one thing ActivityPub supports which Atom does not is the notion of private content. The way it does support this is a bit hamfisted (in that ActivityPub publishers choose to only push content to endpoints which have a trusted user, and endpoints only forward that content over to the trusted users, albeit in a not-very-trustable way). It doesn’t inherently support the ability to backfill older content (or make it otherwise browseable) to someone who is granted friends-only access after-the-fact, though, and it has many scaling and security implications in how this works (since it requires push to be reliable and requires the recipient’s storage of said push notifications to also be reliable).

I’ve put a lot of thought into how to add friends-only stuff to Atom on and off over the years; my previous blog (which used Movable Type for publishing and phpBB for comments) actually had an ad-hoc implementation which worked sort of okay; people could authenticate with my site’s forum, and people in a trusted friend group would see private content. On the public feed, if their reader were logged into the forum (via cookie sharing etc.) it would see the private content in the feed, otherwise it would see placeholders saying “THis is a friends-only entry, please visit the site to read it.” It worked okay but it was never great.

Anyway, I think I have finally come up with an auth approach that works with Atom and offers a… well, least-bad solution all around, which scales better and more reliably than ActivityPub while working with WebSub and existing/legacy feed readers.

Read more…