Replied to a tweet by curried apotheosiscurried apotheosis (Twitter)
I do something like this on my own website. Post issues there so I can own the data (and tags) and control the details and notes and syndicate a copy to GitHub. I’ve documented some of it here: Enabling two way communication with WordPress and GitHub for Issues. Others have done it as well: https://indieweb.org/issue. I’m sure there are other ways of doing this, but it works well for me and just for the reasons you describe.

If others want to see my details, the’re available on my site (when I make them public), but they’re primarily for my benefit and not others. The public copy conforms to the silo’s requirements and can be modified by the repo owners, if necessary. 

Bookmarked at 2020/01/10 9:51:41 pm

Liked a post by Jamie TannaJamie Tanna (jvt.me)
With the help of snarfed.org I've now got brid.gy running locally and syndicating RSVPs from my website to Meetup.com - hopefully it'll be live next week for the rest of the to enjoy https://github.com/snarfed/bridgy/issues/873
I can’t wait for this. It is awesome.
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.

Narwhal Microblog Plugin for WordPress: Quickly Posting Notes to your IndieWeb Site

This morning, after reading a brief, but interesting snippet in the IndieWeb WordPress chat from last night, David Shanske made me think about an old itch I had to have a quicker and more stripped down posting interface for notes on my website. I immediately thought of WordPress’s P2 and 02 themes/products which had a built-in simple posting interface reminiscent of Twitter’s UI. 

Screencapture of Twitter's simple posting interface

Not wanting to wait to see what David might come up with before the next couple of IndieWebCamps, I thought I’d at least do some research to see what was hiding in the good old WordPress repository. I found a few old plugins that were roughly the sort of idea I was looking for, but they were last maintained about 8-10 years ago. 

Then I came across the Narwhal Microblogging plugin from Billy Wilcosky, which is being actively developed/maintained and has almost exactly what I’m looking for!

Screencapture of the Narwhal microblogging plugin user interface

Apparently the plugin itself had an early simple start before the developer came across Jon Smajda’s plugin Posthaste which was apparently repurposed for the Prologue/P2 code that WordPress used for that product/theme. He’s since rewritten a large chunk of it based on Posthaste’s original code and added in some basic formatting options and the ability to add media, so one can post a quick note along with a photo.

Settings for the plugin are hiding in Settings << Writing admin interface (or at the path /wp-admin/options-writing.php on your website) which includes the ability to choose which pages to display the “widget” and allowing one to hide the title, tags, categories, draft seclector, one’s Gravatar, and the Greeting and Links. I’d personally pare my version down to just provide tags, categories, and the draft options to keep the interface as clean as possible.

Screencapture of the settings for the Narwhal plugin

Finally the developer notes that within the user interface “if you leave the ‘Category:’ box at its default setting it posts to your default category. However… If you have a category named ‘asides’, it will put posts with empty titles into the ‘asides’ category even if you do not explicitly specify the ‘asides’ category in the dropdown. You can then style them as asides.”

This is the view of the posting interface on my site after paring it down to my personal bare minimum.

Benefits

I’ve already discussed some of the immediate benefits for easily and quickly posting directly from my own website. Just below I’ll add a few others.

Most importantly for me at the moment, the plugin works with the Classic Editor in WordPress. The interface also only shows up when one is logged into their website, so visitors won’t ever see it.

Titleless posts

The plugin automatically takes the first 40 characters of your note and posts that into the title field, so you don’t have to bother with it. Sadly, this means that feed readers and other services will take your status updates and give them a title. (Though in the wild, most feed readers do something like this anyway. I am hearing strong rumors that Inoreader is about to have better support for social media-like posts soon.) For those using the plugin for IndieWeb use and prefer to keep their notes/asides/status updates titleless, you can spelunk into the code pretty easily and make a quick change which the developer kindly documents in his support page:

But, if you want to modify the title character limit it is easy to do.

  1. Go to this plugin’s folder and open the narwhal-microblog.php file.
  2. In this file you will see a line for this max character limit and you will see the number 40. You could just increase it to something like 100, 3500, or 999999. Depending on how long you are willing to let your titles get.

In my case, I think I’ll just decrease the character limit to 0 and then rely on the Post Kinds plugin to add it’s customary pseudo-title to the admin interface on my back end so that I can distinguish my posts in the posts pages.

UI suggestions

The category chooser could be a little cleaner and provide a dropdown of all my pre-existing categories with the ability to select multiple ones. I suspect that somewhere in the WordPress universe there’s a way to do this even if it means swiping a snippet of code from core’s editor.

The basic text box for entering text could be a bit smaller on the page to accept 2-4 lines of text since it’s meant for short posts. As it stands now, it defaults to 10, but it also smartly already has a slider that appears when you type more than the available number of lines and it also has a handle in the corner to allow you to increase the boxes size.

I’ve mentioned doing natively titleless notes above, but to make things a bit more user friendly, it would be nice to have the ability in the settings page to enter a number for the text excerpt, so that users could configure it without needing code. I suspect that most in the IndieWeb space would set the title excerpt to zero so as to not have titles on their notes.

It will take me some time to dig into it, but it would be nice if the developer had some notes about the CSS classes used in the plugin so that one might more easily style the display of the output on one’s website. Fortunately the defaults to match one’s current theme seem relatively solid.

At present, there isn’t any UI for including syndication targets to external services like Twitter, Mastodon, etc. It would be nice if there was some tie into syndication services or functionality like that provided with Syndication Links plugin and brid.gy publish or brid.gy fed if those pieces are present.

The last dovetail that would be nice to have, particularly within an IndieWeb framing, would be to have better direct integration of this plugin with the Post Kinds plugin. This could extend to auto-setting the post kind to “note”, which should in turn allow the automatic setting of Post Formats to either “status” or “aside”.

Summary

In sum, this plugin is really fantastic for allowing a simple and lightweight means of posting quick status updates or notes to one’s WordPress website! It’s the next best thing to using any of the variety of Micropub clients, particularly when you already happen to be at your own site.

I suspect this plugin is the sort of thing that many within the IndieWeb and WordPress communities will love using–and at least one person in the chat has already said they think it’s a great find. There are currently less than 10 active installations of the plugin, but I think it deserves a magnitude or more. Let’s see what we can do about that!

Have you tried it? What do you think of the idea?

Home

54 °F thunderstorm

👓 Bridgy stats update: Updated through mid June 2019 | snarfed.org

Read Bridgy stats update by Ryan BarrettRyan Barrett (snarfed.org)

Updated through mid June 2019 for State of the IndieWeb at Summit 2019. Graphs below. The one big noticeable event since Jan was the Google+ shutdown on 2019-03-07.

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.

Replied to a tweet by Rachel CherryRachel Cherry (Twitter)

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?

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.

No webmentions to original URLs that include emojis

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

Original: https://boffosocko.com/2019/04/29/%F0%9F%93%85-virtual-homebrew-website-club-meetup-on-may-15-2019/?replytocom=262215#respond

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:

Original: https://boffosocko.com/2019/04/29/%F0%9F%93%85-virtual-homebrew-website-club-meetup-on-may-15-2019/?replytocom=262215#respond

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):
https://boffosocko.com/2017/10/15/docteur-jerry-et-mister-love-%E2%9D%A4%EF%B8%8F%E2%9A%97%EF%B8%8F%F0%9F%91%93%F0%9F%8E%ACi-found-this-original-french-one-sheet-47-x-63-after-the-move-will-have-to-get-it-mounted-and-fram/

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.

Replied to a tweet by StormlightTechStormlightTech (Twitter)
“Thinking that we might have been the ones to teach @microbitch2017 and @ShortShadyBlog how to do webmentions? Has it worked? Bridgy must be failing, because, no retweets showing up comments.”
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.

👓 a post on Brid.gy and IndieWeb | Jack Jamieson

Read a post by Jack JamiesonJack Jamieson (jackjamieson.net)
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...

❤️ Bridgy stats update | snarfed.org

Liked Bridgy stats update by Ryan BarrettRyan Barrett (snarfed.org)
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...

👓 Bridgy traffic bump | snarfed.org

Read Bridgy traffic bump by Ryan BarrettRyan Barrett (snarfed.org)
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!