Some thoughts on comments and interaction

Comments

Recently I’ve been thinking a lot about some of the differences between self-hosted vs. silo spaces. One thing that really stood out to me is that in self-hosted spaces, the tendency is to allow complete control over which comments are visible, and silos almost never allow that, or if they do it’s at best an in-retrospect thing.

For example, most self-hosted blogging systems give you the ability to moderate all comments (as I do), or give easy access to deleting comments which got posted, or any number of mechanisms for curating the community.

But most silo systems don’t give you that access; you might be able to block recurring trolls, or flag a comment for third-party review (usually to no effect), but all posts are set to allow anyone (with access to the post) the ability to post anything at any time, and by default everything gets floated to everyone else.

This came especially to mind today because of this unfortunate video:

I’ve seen so many creators get burned out on what they like doing, because even if 99% of the comments are positive, that 1% really gets under their skin, and they stop creating.

I’ve seen so many creators get burned out on their communities, because even if 99% of it is positive, that 1% really gets under their skin, and they stop interacting with the community, turning it into a toxic cesspool.

I’ve seen so many creators decide to capitulate to the communities and set up a personal SubReddit that they designate other people to moderate, just to keep it contained somewhere else.

I know so many creators who are on the verge of burnout and getting really tired of the dark side of having an audience.

I’m not sure if giving people the ability to require commentary to be opt-in rather than opt-out would solve these problems, but I do know anecdotally that the random snipe-type responses I get from Twitter or Mastodon are way more annoying to me than the comments I opt not to post when submitted to my site. They’re out there and visible and I have to take extra steps to get rid of them, and it’s taken out of my hands as to whether I even can get rid of them.

I don’t think I like how webmention works.

Read more…

webmention.js 0.4.0

Comments

I’ve just released v0.4.0 of webmention.js, which adds the ability to coalesce comment-type responses into the “reactions” section. I’d been considering it for a while but finally got the impetus to add it during today’s Respectful Responses IndieWeb session.

This change shouldn’t break current users of webmention.js, as it’s an opt-in configuration value.

As an aside, I really need to get around to making an actual site for PlaidWeb, so I have somewhere to put non-Publ discussion and release announcements.

Stuff about webmention

Comments

Marty wrote a great, thoughtful essay about some of the problems with webmention right now, and I agree with it.

One of the many problems that’s emerging with webmention is it’s turned into a sort of Swiss army knife of notifications; the IndieWeb uses it not just to send responses to folks, but also for things like publishing to Bridgy Fed or syndicating content to content aggregators. It’s the basis of how notes work. It’s up to the recipient to try to disambiguate the meaning based on context and post-type discovery, and what things are can change over time, sometimes in unpredictable ways that fall apart.

Read more…

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 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.

Some WebSub-Atom observations

Comments

As part of testing my WebSub changes for FoF, I decided to switch to a WebSub hub for myself that provides some subscriber analytics and so on. One neat thing about how WebSub works is that the “hub” layer is completely modular and it really doesn’t matter at all which one you use, and if the one you use has problems you can switch to another one just by changing the URL in your feed and all subscribers will eventually seamlessly migrate (at their next normal polling interval); if anyone even notices a problem it will just be that they don’t receive a push update during that polling interval. (Which, let’s be honest, is incredibly unlikely for most RSS feeds.)

Anyway, because of these new analytics, as well as information I gathered from my new WebSub-supporting reader, I now know a bit more about the state of WebSub.

Update: A lot more supporting readers have shown up in my stats in the two years since I published this article! Please see this entry for a list.

Read more…