backfeed | Chris Aldrich

After a bit of experimentation and tinkering tonight, it appears that one can use their #WordPress website to create threaded conversations on #Mastodon (and likely other portions of the #Fediverse) using the IndieWeb syndication strategy of POSSE with backfeed of comments using #Webmention and Brid.gy. I’d outlined the process using Twitter in the past, and the same principles seem to work well for Mastodon. #IndieWeb #FTW #FediTips

Replied to a post by

Kathleen Fitzpatrick (hcommons.social)

@chrisaldrich Another #IndieWeb question for you! I'm syndicating blog posts from kfitz.info to Mastodon, where they appear from @kfitz@kfitz.info, and then I boost from this account. Replies to @kfitz@kfitz.info appear as comments to the blog post, as desired. But if I reply to the comment on the blog, that reply doesn't syndicate here, so the commenter doesn't know. And if I reply to the comment here, the reply comes from this account (and I'm not yet sure whether it appears as a reply on the blog or not). How do you manage this?

@kfitz I’m not sure that the straightforward functionality you’re looking for exists within the ActivityPub plugin (yet), but it’s certainly something you could potentially file as a feature request.

Since you have other Fediverse accounts you’re using, you might be able to follow the same general pattern I’d documented with Twitter for threading comments between my site and Twitter: https://boffosocko.com/2018/07/02/threaded-conversations-between-wordpress-and-twitter/

Generally, you’d post on your site where it’s seen in the Fediverse via the ActivityPub plugin and/or optionally boosted by your native Mastodon account. Replies to your post (on Mastodon) show up on your site as comments and you reply to them there in your site’s comments section. Then you manually copy/paste the text of your reply from your website into your native Mastodon account and include the comment/reply permalink in that reply. If you’ve got Webmention set up with Brid.gy for Mastodon, replies to your replies on Mastodon should then make their way back to the proper threaded spot in your website’s comments section.

An example of this at work can be seen on my earlier mistake:

The original post on my site;
My own reply on my site;
My manually copied reply on Mastodon;
My Mastodon reply shows up on my site via Brid.gy;
A like of that Mastodon reply shows up on my site (also courtesy of Brid.gy via Webmention).

Related, I’ve been playing around with mirroring my WP site as an instance with the ActivityPub plugin and have boosted posts with my more broadly followed mastodon.social account the same way you mentioned that you were doing with yours. Somehow I’m anecdotally finding that I get more responses/reactions with native posts that with these boosts. I’m curious what your experience has been with this strategy so far? I’m still just starting my experimentation here, but I do like the fact that I’m able to include richer presentation of wrapped links in my WordPress native posts which are seen in the Fediverse while Mastodon seems to strip them out or not allow them (see an example of this in the post above this reply).

Replied to The ethics of syndicating comments using WebMentions by

@edent (Terence Eden’s Blog)

This blog uses WebMention technology. If you write an article on your website and mention one of my blog posts, I get a notification. That notification can then be published as a comment. It usually looks something like this: Screenshot of a comment showing that someone mentioned my post on their bl...

Not an answer to the dilemma, though I generally take the position of keeping everything unless someone asks me to take it down or that I might know that it’s been otherwise deleted. Often I choose not to delete my copy, but simply make it private and only viewable to me.

On the deadnaming and related issues, it would be interesting to create a webmention mechanism for the h-card portions so that users might update these across networks. To some extent Automattic’s Gravatar system does this in a centralized manner, but it would be interesting to see it separately. Certainly not as big an issue as deadnaming, but there’s a similar problem on some platforms like Twitter where people will change their display name regularly for either holidays, or lately because they’re indicating they’d rather be found on Mastodon or other websites.

The webmention spec does contain details for both editing/deleting content and resending webmentions to edit and/or remove the original. Ideally this would be more broadly adopted and used in the future to eliminate the need for making these choices by leaving the choice up to the original publisher.

Beyond this, often on platforms that don’t have character limits (Reddit for example), I’ll post at the bottom of my syndicated copy of content that it was originally published on my site (along with the permalink) and explicitly state that I aggregate the replies from various locations which also helps to let people know that they might find addition context or conversation at the original post should they be interested. Doing this on Twitter, Mastodon, et al. is much harder due to space requirements obviously.

While most responses I send would fall under fair use for copying, I also have a Creative Commons license on my text in an effort to help others feel more comfortable with having copies of my content on their sites.

Another ethical layer to this is interactions between sites which both have webmentions enabled. To some extent this creates an implicit bi-directional relationship which says, I’m aware that this sort of communication exists and approve of your parsing and displaying my responses.

The public norms and ethics in this area will undoubtedly evolve over time, so it’s also worth revisiting and re-evaluating the issue over time.

Thirteen: Backfeeding ideas with Brid.gy

Let’s say I syndicate a thought to Twitter. I can use Bri.gy to backfeed ideas and interactions with my Tweet back to my original in my digital notebook (where it’s most useful). This helps outside ideas filter into and interact with my own ideas.

#HeyPresstoConf20

You knew ideas can have sex, right?!!

Manual Backfeed in the Blogosphere

Forcing webmentions for conversations on websites that don’t support Webmention

Within the IndieWeb community there is a process called backfeed which is the process of syndicating interactions on your syndicated (POSSE) copies back (AKA reverse syndicating) to your original posts. As it’s commonly practiced, often with the ever helpful Brid.gy service, it is almost exclusively done with social media silos like Twitter, Instagram, Flickr, Github, and Mastodon. This is what allows replies to my content that I’ve syndicated to Twitter, for example, to come back and live here on my website.

Why not practice this with other personal websites? This may become increasingly important in an ever growing and revitalizing blogosphere as people increasingly eschew corporate social sites and their dark patterns of tracking, manipulative algorithmic feeds, and surveillance capitalism. It’s also useful for sites whose owners may not have the inclination, time, effort, energy or expertise to support the requisite technology.

I’ve done the following general reply pattern using what one might call manual backfeed quite a few times now (and I’m sure a few others likely have too), but I don’t think I’ve seen it documented anywhere as a common IndieWeb practice. As a point of fact, my method outlined below is really only half-manual because I’m cleverly leveraging incoming webmentions to reduce some of the work.

Manually syndicating my replies

Sometimes when using my own website to reply to another that doesn’t support the W3C’s Webmention spec, I’ll manually syndicate (a fancy way of saying cut-and-paste) my response to the website I’m responding to. In these cases I’ll either put the URL of my response into the body of my reply, or in sites like WordPress that ask for my website URL, I’ll use that field instead. Either way, my response appears on their site with my reply URL in it (sometimes I may have to wait for my comment to be moderated if the receiving site does that).

Here’s the important part: Because my URL appears on the receiving site (sometimes wrapped as a link on either my name or the date/time stamp depending on the site’s user interface choices), I can now use it to force future replies on that site back to my original via webmention! My site will look for a URL pointing back to it to verify an incoming webmention on my site.

Replies from a site that doesn’t support sending Webmentions

Once my comment appears on the receiving site, and anyone responds to it, I can take the URL (with fragment) for those responses, and manually input them into my original post’s URL reply box. This will allow me to manually force a webmention to my post that will show up at minimum as a vanilla mention on my website.

(Note, if your site doesn’t have a native box like this for forcing manual webmentions, you might try external tools like Aaron Parecki’s Telegraph or Kevin Mark’s Mention.Tech, which are almost as easy. For those who are more technical, cURL is an option as well.)

Depending on the microformats mark up of the external site, the mention may or may not have an appropriate portion for the response and/or an avatar/name. I can then massage those on my own site (one of the many benefits of ownership!) so that the appropriate data shows, and I can change the response type from a “mention” to a “reply” (or other sub-types as appropriate). Et voilà, with minimal effort, I’ve got a native looking reply back on my site from a site that does not support Webmention! This is one of the beautiful things of even the smallest building-blocks within the independent web or as a refrain some may wish to sing–“small pieces, loosely joined”!

This method works incredibly well with WordPress websites in particular. In almost all cases the comments on them will have permalink URLs (with fragments) to target the individual pieces, often they’ve got reasonable microformats for specifying the correct h-card details, and, best of all, they have functionality that will send me an email notification when others reply to my portion of the conversation, so I’m actually reminded to force the webmentions manually.

An Illustrative Example

As an example, I posted on my website that I’d read an article on Matt Maldre’s site along with a short comment. Since Matt (currently) doesn’t support either incoming or outgoing webmentions, I manually cut-and-pasted my reply to the comment section on his post. I did the same thing again later with an additional comment on my site to his (after all, why start a new separate conversation thread when I can send webmentions from my comments section and keep the context?).

Matt later approved my comments and posted his replies on his own website. Because his site is built on WordPresss, I got email notifications about his replies, and I was able to use the following URLs with the appropriate fragments of his comments in my manual webmention box:

https://www.spudart.org/blog/xeroxing-your-face/#comment-43843
https://www.spudart.org/blog/xeroxing-your-face/#comment-43844

After a quick “massage” to change them from “mentions” into “replies” and add his gravatar, they now live on my site where I expect them and in just the way I’d expect them to look if he had Webmention support on his website.

I’ll mention that, all of this could be done in a very manual cut-and-paste manner–even for two sites, neither of which have webmention support. But having support for incoming webmentions on one’s site cuts back significantly on that manual pain.

For those who’d like to give it a spin, I’ll also mention that I’ve similarly used the incredibly old refbacks concept in the past as a means of notification from other websites (this can take a while) and then forced manual webmentions to get better data out of them than the refback method allows.

Spent a few minute to finally set up my website with Brid.gy so that it’s now pulling responses back from Mastodon. It’s so nice to see all the interactions that were once “lost” to me coming back to live with their proper contexts on my website.

For those looking to tinker with their websites as it relates to interacting with Mastodon, the IndieWeb has a reasonable number of potential options in addition to your ability to roll your own.

Replied to a tweet by

Rachel Cherry (Twitter)

I finally got tired of not finding exactly what I want out of social media automation and started building my own system.

So, basically that means the @wpcampusorg account will be excessively tweeting a tad bit over the next few days while I tweak the algorithm. :)

— Rachel Cherry (@bamadesigner) June 18, 2019

I’m definitely curious what you come up with! There are so many syndication options and I’m always on the look out for better/more standardized methods. (Of course, nothing beats the feed directly from the source…)

Once you have posting out done, are you going to work on backfeed to have the responses to your posts on Twitter come back to aggregate the conversation on the original site? Perhaps using Webmention and Brid.gy?

👓 facebook backfeed via email notifications · Issue #854 · snarfed/bridgy | GitHub

Read facebook backfeed via email notifications · Issue #854 · snarfed/bridgy (GitHub)

this is a kinda crazy, somewhat dangerous, generally inadvisable idea that we almost certainly shouldn&#39;t do...at least, not as a public facing service for everyone. @chrisaldrich had the ...

👓 Backfeed without code | Ryan Barrett

Read Backfeed without code by

Ryan Barrett (snarfed.org)

I’ve spent most of my time in the IndieWeb on backfeed: sending interactions from social networks back to your web site. Bridgy, the service we built, has served that need wel...

This sounds like a lovely and simple idea. Definitely worth attempting as a simple method.

Manually reconstructed Bridgy URLs redirect to silos

Filed an Issue snarfed/bridgy (GitHub)

Bridgy pulls comments and likes from social networks back to your web site. You can also use it to publish your posts to those networks.

It’s mentioned in the documentation that one can reconstruct URLs to allow manually resending webmentions for missed backfeed. However, it appears this may no longer work(?) as these reconstructed URLs, which used to be static are now automatically redirecting to their siloed instances.

Example: https://brid.gy/post/twitter/schnarfed/476408043819659264
redirects to https://twitter.com/schnarfed/status/476408043819659264

Separately, though related, the example in the documentation for Instagram no longer seems to exist and could be replaced and the example for Google+ could be removed as the service no longer exists.

Replied to facebook backfeed via email notifications (unlikely) · Issue #854 · snarfed/bridgy by Ryan Barrett (GitHub)

thanks @grantcodes!

i could come up with gmail, sieve, etc email filters for people to install that would forward all facebook emails except password resets. or maybe only notification emails. still seems iffy security wise, and awful UX, but...meh?

quick poll time. hey @aaronpk @chrisaldrich @jgmac1106 @grantcodes @dshanske @tantek and others: if you could get facebook backfeed again by setting up an email filter like this, but it'd be somewhat sketchy security wise (discussion above), and might be inconsistent and incomplete, and the bridgy UI might be weak or nonexistent...would you do it? feel free to emoji respond +1 for yes, -1 for no. also feel free to @-mention anyone else who might vote.

I should have outlined this originally… Likely safer (for Bridgy and the end user) would be to follow the model of posting to WordPress via email (or services like Reading.am which allow posting to it via custom email addresses). Bridgy could provide users with a private hashed email address like 123xyzABC@brid.gy which could be linked to their particular account to which they could manually (or automatically) forward the relevant Facebook notification emails. Upon receipt, Bridgy would know which account sent it and could also match it to the user’s post URL as a check before sending the appropriate webmentions.

This would leave Bridgy free from being the potential source for security leaks and put the onus on the end user. You’d naturally need to have the ability to reset/change the user’s hash in the case that they accidentally allowed their custom email address to leak, although generally this isn’t a huge issue as emails which don’t match the user’s account/endpoints would be dropped and not send webmentions in any case. (In some sense it’s roughly equivalent to my being able to visit https://brid.gy/twitter/schnarfed and clicking on the Poll now or Crawl now buttons. It’s doable, but doesn’t give a bad actor much. You’d probably want to rate limit incoming emails to prevent against mass spam or DDoS sort of attacks against Bridgy.)

A side benefit of all of this is that those who have kept their old email notifications could relatively easily get much of their past missing back feed as well. Or if they’re missing back feed for some reason, they could easily get it by re-sending the relevant emails instead of some of the current manual methods. Perhaps allowing preformatted emails with those same manual methods could be used to do back feed for Facebook or other providers as well?

We could also put together some forwarding filters for common platforms like gmail to help people set up autoforwarders with appropriate keywords/data to cut down on the amount of false positive or password containing emails being sent to Bridgy.

The one potential privacy issue to consider(?) is that this set up may mean that Bridgy could be sending webmentions for private messages since users get both private and public message notifications whereas the API distinguished these in the past. To remedy this, the comment URL could be tested to see if/how it renders as a test for public/private prior to sending. Separately, since Bridgy doesn’t need to store or show these messages (for long?), private messages could be sent, but potentially with a payload that allows the receiving end to mark them as private (or to be moderated to use WordPress terminology). This would allow the user’s website to receive the notifications and give them the decision to show or not show them, though this may be a potential moral gray area as they could choose to show responses that the originator meant to be private communication. The API would have prevented this in the past, but this email method could potentially route around that.