webmention.js updated

Comments

The fact that yesterday’s intent post ended up changing URLs (because I’d inadvertently titled it for 2020 instead of 2019) made it so that it made sense to finally add support for multiple incoming webmention target URLs. So I added this to webmention.js, and also to the sample beesbuzz.biz templates. So now I can slurp up arbitrarily many target URLs' mentions on any given page.

Incidentally, yesterday I ended up releasing a new version of Pushl which also has to do with URL updates. Gee, I wonder why these things both came up in such close proximity.

So anyway this is two IndieWeb-focused things in as many days and they aren’t even things I was intending to work on. But low-hanging fruit is just as tasty.

My IndieWeb Challenge 2019 aspirations

Comments

The IndieWeb community has an annual daily improvement challenge. Jacky posted his aspirations so I figured I’d post some of mine too.

I don’t plan on actually releasing everything every day (speaking of which I’m glad Novembeat 2019 is finally over with, holy heck!) but I definitely have things I want to get done this month.

Read more…

WebSub support update

Comments

Almost exactly one year ago, I wrote about the state of WebSub support in feed readers. I’ve noticed a few incoming mentions from folks citing it as definitive (when that was never my intention), and so I decided to check to see if things have changed. I’m happy to say that it has!

Read more…

Re: Why Publ won’t support magic auth links

Comments

In response to a Publ blog post, Kicks Condor writes:

One question, though—could the Atom feed list rel alternate versions of the feed? (That would have type application/atom+xml?) It also seems like rel self could have the non-authenticated version of the feed. It doesn’t make sense for credentials to be in that URL. These are possibly naive suggestions—apologies, if so. Again, fantastic write-up!

The problem is that it’s up to the sharing news reader to know which URL to use for the sharing, and there’s no way to control what URL the reader happens to use. I know that Feed On Feeds will use the URL for the actual subscription (since that’s the only source URL it tracks in the first place), and who knows what other readers with sharing features will do!

And changing the rel="self" URL has a different problem – some readers (again, such as Feed On Feeds) treat that as the canonical URL and will update their subscriptions to point to that URL instead, so setting rel="self" to the unauthenticated feed means most users will be unable to remain logged in.

Basically, it’s a tricky issue that has no right answer with the Atom spec as it currently exists. So if some other mechanism has to be designed, it might as well be done in a safe, unambiguous way from the beginning. If some other use case for magic auth links comes up I’ll reconsider implementing them, but at least for friends-only subscription access, the privacy risks are simply not worth it.

Some template changes

Comments

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

Comments

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

Comments

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

Comments

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

Comments

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.