For fun, we can use this to estimate the total number of webmentions sent in the wild to date. We previously estimated that we hit 1M somewhere around 2017-12-27, at a rate of ~929 new webmentions per day. At that time, ~95% of all webmentions had come from Bridgy, 880 per day.
Since then, Bridgy lost Facebook and Google+, which accounted for ~53% of its webmention volume. We know it’s sent 1,356,878 webmentions total as of today.If we assume non-Bridgy webmention growth has continued apace, from 48 per day at the end of 2017 to 77 per day now, that would add ~53k before then, plus ~33K since, for a total of ~1.44M sent to date, plus or minus a few thousand. Let’s keep it up!
My last post to Facebook was almost a year ago on July 31, 2018, a day before Facebook turned off their API and prevented my website from interacting with their service. Other moral and ethical concerns with Facebook aside, I’ve got what I hope to be a useful method for people’s interactions with my Facebook account to come back to my site. This will let me better own and control my data while still interacting with people “stuck” on this problematic service.
This return post will serve as a test to see if I might return to and occasionally post there again.
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?
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.
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.
I’ve found a few instances in which Brid.gy will apparently fail to send a webmention (and/or fail to find a target) when the original URL contains an emoji(s). I’d suspect it’s a quirky encoding issue of some sort. I’m sure I’ve seen this issue before on Instagram where it’s probably more likely as the result of emojis in Instagram “titles” when using PESOS methods.
When I subsequently remove the emoji from the permalink, and reprocess Bridgy then has no problem finding the URL and sending the webmention. So at least there’s a “fix” on the user’s side for those experiencing this issue, but only if they’re aware it exists and have the means of executing it.
Example of failed webmention:
(I’ll note that it’s also got a fragment # in the URL, but don’t think this is a part of the issue)
Syndicated copy that was liked: https://twitter.com/ChrisAldrich/status/1129124049068498944#favorited-by-14591484
Bridgy Log: https://brid.gy/log?start_time=1558056830&key=aglzfmJyaWQtZ3lyTAsSCFJlc3BvbnNlIj50YWc6dHdpdHRlci5jb20sMjAxMzoxMTI5MTI0MDQ5MDY4NDk4OTQ0X2Zhdm9yaXRlZF9ieV8xNDU5MTQ4NAw
Example of previously failed webmention that ultimately went through following emoji removal:
Syndicated copy: https://twitter.com/ChrisAldrich/status/1129124049068498944#favorited-by-19844672
Bridgy Log: https://brid.gy/log?start_time=1558714459&key=aglzfmJyaWQtZ3lyTAsSCFJlc3BvbnNlIj50YWc6dHdpdHRlci5jb20sMjAxMzoxMTI5MTI0MDQ5MDY4NDk4OTQ0X2Zhdm9yaXRlZF9ieV8xOTg0NDY3Mgw
Another potential example from Instagram
Done via PESOS from Instagram which I’m sure missed webmentions (though too far back to find the specific logs):
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.
I see a Bridgy account: https://brid.gy/twitter/StormlightTech but nothing for @microbitch2017 or @ShortShadyBlog so they can’t get webmentions from Bridgy because it doesn’t know about them. Clicking on the timestamp in Bridgy will give you some troubleshooting ideas.
Thank you to @RyersonResearch and especially @joyceemsmith for inviting me to talk about my research today. I had a great time talking IndieWeb, and specifically, Bridgy. Jan 30, 2019 Lunch and Learn at Ryerson Journalism Research Centre I presented a study I’ve been working on about Bridgy, i...
It’s that time of year again! No, not awards season…Bridgy stats time!
Looking at the graphs, the elephant in the room is clearly the Facebook shutdown. It was Bridgy’s second largest silo, numbering 1477 users when we wer...
A few weeks ago, Bridgy‘s traffic suddenly shot up to 20-50x its baseline, from 5-10 human visitors per day to 200-300. Humans in browsers, not bots or other requests; this ain’t Google Analytics’s first ro...
This is some excellent news. I hope it continues to pick up!
Right now, I just want to write. ❧
You might find that the micropub plugin is a worthwhile piece for this. It will give your site an endpoint you can use to post to your site with a variety of third party applications including Quill or Micropublish.net.
October 14, 2018 at 01:01AM
My hope is that it will somehow bring comments on Facebook back to the blog and display them as comments here. ❧
Sadly, Aaron Davis is right that Facebook turned off their API access for this on August 1st, so there currently aren’t any services, including Brid.gy, anywhere that allow this. Even WordPress and JetPack got cut off from posting from WordPress to Facebook, much less the larger challenge of pulling responses back.
October 14, 2018 at 01:03AM
Grant Potter ❧
Seeing the commentary from Greg McVerry and Aaron Davis, it’s probably worthwhile to point you to the IndieWeb for Education wiki page which has some useful resources, pointers, and references. As you have time, feel free to add yourself to the list along with any brainstorming ideas you might have for using some of this technology within your work realm. Many hands make light work. Welcome to the new revolution!
October 14, 2018 at 01:08AM
the autoposts from Twitter to Facebook were ❧
a hanging thought? I feel like I do this on my site all too often…
October 14, 2018 at 01:09AM
I am giving this one a go as it seems to be the most widely used. ❧
It is widely used, and I had it for a while myself. I will note that the developer said he was going to deprecate it in favor of some work he’d been doing with another Mastodon/WordPress developer though.
October 14, 2018 at 01:19AM
I suspect that @chrismessina could do it quickly, but for those who’d like to leave Twitter for #WordPress with similar functionality (but greater flexibility and independence), I recorded a 2 hour video for an #IndieWeb set up/walk through with some high level discussion a few months back. If you can do the 5 minute install, hopefully most of the rest is downhill with some basic plugin installation and minor configuration. The end of the walk through includes a live demonstration of a conversation between a WordPress site on one domain and a WithKnown site running on another domain.
tl;dr for the video:
- WordPress base install
- IndieWeb Plugin (gives you quick access to most of the plugins below)
- The SemPress Theme or Independent Publisher Theme
- Webmention and Semantic Linkbacks plugins (for site to site communication and notification)
- IndieAuth plugin (for authenticating with Micropub, Microsub, and other related tools)
- Micropub plugin (for a variety of clients you can use to publish to your site)
- Syndication Links plugin (to indicate which sites, like Twitter, that you syndicate your content to to stay in touch with those left behind)
- WebSub plugin (to ping feed readers for real-time communication)
- Brid.gy for WordPress plugin (to pull in backfed comments from other social silos)
- Post Kinds plugin (for better delineating articles, status updates (notes), replies, favorites, likes, etc. with appropriate microformats markup)
- Aperture Plugin (allows you to sign into a variety of Microsub readers which also act as your stream and allow you to reply to others directly from your reading interface. This part is still a bit experimental, but the kinks are being worked out presently for a richer experience.)
Additional pieces are discussed on my IndieWeb Research Page (focusing mostly on WordPress), in addition to IWC getting started on WordPress wiki page. If you need help, hop into the IndieWeb WordPress chat.
For those watching this carefully, you’ll notice that I’ve replied to David Shanske’s post on his website using my own website and sent him a webmention which will allow him to display my reply (if he chooses). I’ve also automatically syndicated my response to the copy of his reply on Twitter which includes others who are following the conversation there. Both he and I have full copies of the conversation on our own site and originated our responses from our own websites. If you like, retweet, or comment on the copy of this post on Twitter, through the magic of Brid.gy and the Webmention spec, it will come back to the comment section on my original post (after moderation).
Hooray for web standards! And hooray for everyone in the IndieWeb who are helping to make this type of social interaction easier and simpler with every passing day.
Summary: David is about to head off abroad for a month. We talk about what’s been happening recently and his plans for his upcoming sojourn.
Recorded: August 5, 2018
IndieWeb Camp NYC–September 28-29, 2018–RSVPs are open now
Micropub Plugin work for WordPress
It will include a Media endpoint
Code for integration with the WordPress REST API
This sketch solution may be an end-around the issue of getting WordPress (or potentially other CMSes) Themes to be microformats 2 compatible, and allow a larger range of inter-compatibility for websites and communication.
As planned, Facebook turned off some of its key APIs for posting and fetching data on Wednesday, and I disabled Facebook for Bridgy entirely. It’s a sad day. Facebook was t...
It is a sad day. Ryan couldn’t have said it better. This is almost precisely how I feel about it.
Thanks for keeping things up and running as long as you could Ryan! We appreciate it.
The #IndieWeb community has been working on this for a while. There’s even a service called Brid.gy to help enact it. At the same time, as Ben Werdmüller indicates, we need to be careful not to put too much reliance on silos’ APIs which can, and obviously will, be pulled out from underneath us at any moment.
As any kindergartner can tell you, “It’s difficult to play ball when the local bully owns the ball and wants to make up their own rules or leave in a huff.”
One of the things I love about IndieWeb is that we’re all trying to create a way for balls to be roughly standardized and mass manufactured so that everyone can play regardless of what the bully wants to do or what equipment people bring to the game.1
And as Nikhil Sonnad has reminded us very recently, we also need more than just connections, we need actual caring and thinking human interaction.2