Update: thanks to Ryan Barrett for pointing me to his Keep Bridgy Publish dumb post, which explains why Bridgy doesn't include the features mentioned below!

Nerd alert: This post is me geeking out and will involve talk of protocols.

In keeping with the IndieWeb concept of POSSE (Publishing on my Own Site, Syndicating Elsewhere), I try to make social media posts on my own site first and then make similar (not always identical!) posts to my accounts on silos like Twitter and Facebook. I then add links to the posts on my site indicating that you can find the "syndicated copies" of that post on those silos.

My process for doing this is something like:

• Make a new post, likely with a micropub client like Quill.
  
• Log in to Twitter and make a similar post, making note of the URL to the new tweet.
  
• Log in to Facebook and make a similar post, making note of the URL to the new FB post.
• Edit the metadata to my post to indicate the new syndication links.
• Re-publish the post on my site.

Because of the way my site is set up, this manual process requires the use of my laptop, so I can't do it on the go.

When thinking of ways to automate this process, I found myself drawn to another nice IndieWeb tool called Telegraph. Telegraph takes the URL for a post, finds links inside that post, and (if they support webmentions) allows me to notify those sites about that my post links to theirs with a single click.

I like the way Telegraph works for several reasons:

• It's not purpose-built for a single website - it can be used for sending webmentions from any site that publishes their content with the right markup to any site that can receive them.
  
• It puts the final decision to send a mention in my hands - I can choose to send mentions to any particular link mentioned in my post, or not.
• With a bookmarklet, the process of sending webmentions becomes very simple. I visit the page for my post, click my Telegraph bookmark in my browser, and Telegraph shows me the links and send buttons for my post.

There already exists a great tool for copying content from my site to certain silos: brid.gy. While brid.gy's primary use case is to use webmentions to syndicate comments and other activity from silos onto your own site, brid.gy also has a Publish feature which accepts a URL from your site and attempts to create a similar post on the silo of your choice. Brid.gy Publish is a great feature, and I make good use of it. However, there are still a few pain points that I feel when using it:

• While Brid.gy Publish gives a nice preview of what it will do, I can't tweak the content before publishing without editing my own post.
  
• Brid.gy does not, as far as I can tell, support bookmarklet functionality. So, publishing takes multiple steps:
  1. Visit my brid.gy profile page for a particular silo account.
  2. Enter the URL for the post on my site.
  3. Approve the post.
  4. Copy the URL for the new silo post from brid.gy.
     • Note: These steps can be automated via hidden links and webmentions, and it even returns the URL for the new post. However, this comes at the cost of the ability to preview what is to be posted.
• Finally, while Brid.gy lets me know in its UI that my post succeeded, Brid.gy has no mechanism for informing my site that the new syndicated post is available. I still need to enter the syndication URLs into my post manually and re-publish my post.

With that groundwork of existing tools, here is what (I think) my ideal workflow would look like:

1. Make a new post to my site, likely with a micropub client like Quill.
2. While looking at my post, click a bookmarklet that takes me to a syndication tool.
3. The syndication tool shows me previews of what my post would look like on each silo where I'd like to publish. I can tweak the content, if needed.
4. A single "Publish" click for each silo would create the post on that silo, but would also update my website with the new syndication link.

This tool seems non-trivial to implement, but I think there are several building blocks which could be quite useful:

• silo.pub is a micropub-to-multiple-silos service that can simplify the process of getting content into silos. Brid.gy Publish also does much of this.
  
• Micropub supports querying source properties of a given post. (it also supports querying for a list of syndication targets, but this seems primarily intended for setups where the micropub server itself will handle the syndication).
• Micropub supports updates. this could be used to add the syndication targets back to the original post. In fact, this use case is in the spec.

I am not currently aware of anyone who does POSSE with this particular flow. I would be interested to know other folks' thoughts on this! Feel free to let me know with a post on your own site that mentions this one, or hit me up in the #indieweb-dev IRC chat!

Further Reading:

• https://indieweb.org/syndication-brainstorming
• https://indieweb.org/micropub_chaining

Audio edition for This Week in the IndieWeb for April 8th - 14th, 2017.

You can find all of my audio editions here.

You can subscribe with your favorite podcast app on huffduffer.

Music from Aaron Parecki’s 100DaysOfMusic project: Day 48 - Glitch, Day 49 - Floating, Day 9, and Day 11

Thanks to everyone in the IndieWeb chat for their feedback and suggestions. Please drop me a note if there are any changes you’d like to see for this audio edition!

Jonathan Prozzi and I have challenged one another to make a post about improving our websites once a week. I'm late with this one!

Most of the features on my website are experiments in learning new things. Sometimes I learn a better way of doing something that I've already built into the site and it's time to migrate!

Moving Media files from Git LFS to a Media Endpoint

I build my site with Jekyll, and I store my site's configuration and text content via Git. One of the things that most folks avoid with Git is storing text content (which fits into Git's model of efficiently storing differences over time) with large binary files like images, etc. (which Git cannot manage as efficiently).

When I first set up my site, I made use of Git LFS ("Large File Storage") for managing anything that wasn't text. Any images, video, or audio that I added to my site was stored in an _assets/ folder in a way that matched uploaded files to the posts they were a part of. Git LFS would transparently ship those files off to a secondary server rather than include their content in the Git repository itself. I had to go through some hoops to set up my local GitLab server to support Git LFS and to set up Git LFS with the server that handles receiving new posts via Micropub, compiling and deploying the site.

It turns out that there are many reasons that a site would want to handle media files separately from the text content that refers to them. In fact, it is a common enough pattern that the Micropub standard includes a definition for a separate "media endpoint" to handle file uploads. I shared a Micropub media endpoint implementation that I built called Spano a while back, and it has been working well with support from tools like Quill. So the text content of my site is served from https://martymcgui.re/, and my media files from https://media.martymcgui.re/. With a couple of changes in my code and my workflows, this has become the way I handle all media files for my site.

However, I still had a bunch of files in site being handled by Git LFS, and some of my Jekyll code (plugins and templates) for showing embeds expected files to be on the local filesystem. This past week I took some time to write some scripts to find all references to those local files, migrate them to my media server, and update the outgoing links. I also updated my embed handling so it didn't rely on local files. This let me delete a lot of local metadata I was keeping but not using, like all the EXIF tags in uploaded photos. I am now Git LFS free and it feels like one less thing to worry about.

Better Caching for Mentions from Webmention.io

When I finally started displaying webmentions, I had a very simple model for how to cache all the info from webmention.io. Basically: I stored all mentions in a big array and, when my site went to fetch new mentions, it would keep fetching until it saw the "last" mention again. This led to a bit of a bug where someone might send me a mention, update their page, and send the mention again. My site would not be able to recognize the "last" mention, so it would fetch all my mentions again, leading to everything appearing twice.

This past week I rewrote my mention handling to avoid this problem by replacing this array and storing mentions in a hash based on the source and target. The new code also checks to see if the verification date of the mention has changed (giving me a way to detect and notify about changed mentions in the future). I also reorganized my mention cache to include an index by the target URL on my site. This makes it a bit quicker to find mentions for a given page when rendering out the site.

Neither of these changes are really visible to readers of my site, but they have been useful for cleaning things up. The webmention.io handling in particular has brought my plugin a lot closer to being something I could release for other people to use!

Audio edition for This Week in the IndieWeb for April 1st - 7th, 2017.

You can find all of my audio editions here.

You can subscribe with your favorite podcast app on huffduffer.

Music from Aaron Parecki’s 100DaysOfMusic project: Day 48 - Glitch, Day 49 - Floating, Day 9, and Day 11

Thanks to everyone in the IndieWeb chat for their feedback and suggestions. Please drop me a note if there are any changes you’d like to see for this audio edition!

IndieWeb Summit in Portland, OR Jun 24-25th!

Looking forward to meeting some lovely IndieWeb folks!

Inspired by Eddie Hinkle's recent post about viewing webmentions, I decided to improve the way I display webmentions on my site.

TL;DR, my site now pulls attempts to recognize single-emoji comments and display them as a "Reaction".

Slightly longer version - my site uses webmention.io for handling webmentions, and I use brid.gy to backfeed interactions from Facebook to my own site. The way brid.gy handles Facebook reactions other than the standard "like" is a little quirky - they show up in webmention.io as a "reply" with a single emoji as the "content".

Using the Ruby twemoji library, my site checks the "content" of a reply against the emoji index and, if the content is a single emoji, pulls it out of the usual "reply" display and puts it in a facepile. The emoji itself is shown as an icon in the corner of the little face image.

While I was at it, I cleaned up a lot of my webmention-handling template to make things much clearer. This will make things easier for folks that want to re-use this code when I (eventually) release this as a Jekyll plugin.

Tonight is a Homebrew Website Club night, but Baltimore is not having another official meetup until April 19th. Still, I wanted to get something done to continue my deal with Jonathan to post something IndieWeb related at least once per week.

Audio edition for This Week in the IndieWeb for March 25th - 31st, 2017.

You can find all of my audio editions here.

You can subscribe with your favorite podcast app on huffduffer.

Music from Aaron Parecki’s 100DaysOfMusic project: Day 48 - Glitch, Day 49 - Floating, Day 9, and Day 11

Thanks to everyone in the IndieWeb chat for their feedback and suggestions. Please drop me a note if there are any changes you’d like to see for this audio edition!

Jonathan Prozzi and I have challenged one another to make a post about improving our websites once a week. I'm a little late with this one!

I recently added support for displaying mentions, such as likes, reposts, comments, etc. from around the web that refer to the posts on my site. One thing the update didn't do is catch another type of mention, such as when someone mentions me in a tweet (example). These get fed to my website by brid.gy, but weren't displayed anywhere.

So, I created a /mentions page for displaying these mentions. In the future, when a post mentions my homepage, the result will show up on the mentions page.

My mentions still don't yet update in real time - they are compiled into my site whenever I make a new post. That's coming up in the future, but I have taken one more step towards real-time interactions with notifications!

Webmention.io, the service that I use for accepting and storing webmentions, has a WebHook option that can notify your site whenever a new webmention has been received. I wrote up a simple Python service using Flask that will listen for these messages from webmention.io and send them to me via PushBullet, a notification service that I've been using for a while for other projects.

Now, I'll see a notification on my phone and laptop when another site sends me a webmention!

Update: Here's an example notification!

I write a text script for each of these audio editions, which I would like to find a way to add to the post as a transcript for the audio. A couple of (silly?) things stopping me: (1) I’m not sure of the best way to lay that out and mark it up for the widest use and (2) My script format includes lots of notes-to-self that need to be cleaned up, adding yet-another-editing-task to getting this podcast out. :}

Audio edition for This Week in the IndieWeb for March 18th - 24th, 2017.

You can find all of my audio editions here.

You can subscribe with your favorite podcast app on huffduffer.

Music from Aaron Parecki’s 100DaysOfMusic project: Day 48 - Glitch, Day 49 - Floating, Day 9, and Day 11

Thanks to everyone in the IndieWeb chat for their feedback and suggestions. Please drop me a note if there are any changes you’d like to see for this audio edition!