Aaron Parecki

Facebook Live offers a seamless viewing experience for people to watch your livestream and then see an archived version after you're done broadcasting.

I often want to share screenshots in text chat from my computer, and I don't like sharing Dropbox links since they load a huge HTML+JS app just to show an image.Since I already have a Micropub Media Endpoint that apps like Quill use to upload photos, I thought that would be a good place to also share screenshots from. The Media Endpoint is a simple HTTP API. It accepts a file upload, and returns the URL to the file in the Location header.OSX has what's called "Folder Actions" where the system will trigger a script to run any time a file is added to a folder. I created an Automator script that will upload the newly added file to the media endpoint, and copy the resulting URL onto the clipboard.

Checkins can easily be faked. The Foursquare app does a reasonable job of preventing fake (and accidental fake) checkins, but it's still possible. If checkins weren't posted on Foursquare, but instead were posted on each person's own website, the possibility of fake checkins is much greater. What would it look like to have a way for a venue to know (and republish) checkins that it knows were real?

The thing I was most excited about at IndieWebCamp Brighton was coming up with a Private Webmention extension to Webmention. The version we outlined in Brighton was drastically simplified from previous iterations of potential ways to send private Webmentions.Nearly a week after speccing it out, I now have a first draft implementation of sending. My goal this week was to finish implementing sending private Webmentions, to get some real-world feedback on the spec.

I'm excited to announce that Micropub is now a W3C Candidate Recommendation!

It's been an exciting year in the IndieWeb so far!

The videos from IndieWeb Summit are finished and online now! I put together separate video clips for the two keynote talks in the morning, and also for the demos on the second day. (Apologies for the somewhat noisy audio, the air conditioners in the space were loud!)State of the IndieWebTantek ÇelikCutting Edge IndieWebAaron Parecki, Ben Werdmüller, Kyle MahanDemos from IndieWeb Summit 2016

When I first built Monocle, I modeled it after the "timeline" or "stream" view now common in social networks, but made it possible to subscribe to h-entry feeds as well. The main UI showed a stream of posts, with the full post contents rendered inline, along with the author info and favorite/repost/reply buttons.

I just launched an update to p3k which adds an integrated authorization server. This means that now when I sign in to Micropub apps like Quill, it will redirect me to my own server where I can have more fine-grained control over the access I am granting the application.

Since publishing the latest W3C draft of Micropub on March 1, there have been a few minor updates based on feedback from people who have implemented it.Simpler update syntaxThe update syntax had an extra nesting that was not necessary. The syntax changed from:replace[properties][content]=Hello+Moonto replace[content]=Hello+MoonMoving a postIf the update operation caused the post to be moved to a new URL (such as when the URL scheme is based off of the post's date, or has a custom slug that is editable), the Micropub client needs a way to know the new URL of the post.The Update Response section now includes HTTP 201 as a possible response, along with:If the update operation caused the URL of the post to change, the server must respond with HTTP 201 and include the new URL in the HTTP Location headerMore InformationYou can read the latest editor's draft of the spec here: http://micropub.net/draft/ as well as see the change log. The git commit history shows the full detailed changes.Thanks to Greg for providing feedback on his Micropub implementation.As always, feedback from implementation experience is appreciated! Feel free to file an issue, or join the #indiewebcamp chat!

I just spent two days finishing migrating the last of my old websites and services off my old server and into new homes. This project has been on my todo list for over two years, and I've been making slow progress since then, mostly by spending a day on it here and there.I finally finished moving the last things off the server today. The last two things left were my Twitter streaming search script and a really old MediaWiki website. Both were running on a 6-year old operating system, and under deprecated versions of Ruby and PHP. The MediaWiki instance had been EOL since 2012. The OpenSSL library was so old the Heartbleed bug hadn't even been written yet. Other things on that server were a Gitlab install (which I replaced with Gogs in February), my own SSL root authority (which is significantly less useful now that Letsencrypt makes certificates free and easy), an old web app I haven't used since 2009, and many cobbled together scripts.This was quite a painful process all told, and I would like to avoid getting into this this situation in the future. Here are some things I'm planning to do that will help make the upgrade process easier in the future.Upgrade regularlySpend the time it takes to upgrade the whole server (OS as well as application dependencies) every 3-6 months, instead of letting the machine get to be several years old. The whole reason I got into this situation in the first place is the OS was so old incremental upgrades were no longer possible. Updating the OS, PHP/Ruby versions, and applications regularly means smaller incremental changes rather than getting into a situation where your app no longer runs because the scripting language changed so much since the last upgrade.Separate the web and database serversI've had a separate database server for a long time. The main benefit this gives me is I'm able to move the source code for a website to a new server without having to also worry about migrating the database at the same time. It's one less moving part in the migration process, and I will continue to do this in the future.Productize everythingSome of these projects and websites were so old that I didn't actually have them in Git repos yet. Some of them were in Subversion, some were just piles of files on disk. A few of them shared a common set of files on the server, rather than using any sort of package management and proper dependency chain. Of course my more recent projects are much better packaged, but I had forgotten I had not always done things this way. Making each project a self-contained application with its own Git repo makes it easier to move them around to new servers later.Avoid using servers in the first placeThese days, we have many options for running applications without dealing with the underlying operating system. Google AppEngine (on which I currently run indiewebify.me and xray.p3k.io), Amazon Lambda (where I run ca3db), and Heroku to name a few. Once a service is running in infrastructure such as these, you can forget worrying about the underlying operating system updates, and focus on your application logic. The service providers will handle everything under the hood and you can forget that upgrading OpenSSL is a thing that needs to happen.

You can use Telegraph to receive Webmentions when your site is linked to by any website tracked by Superfeedr, even if that site doesn't send Webmentions itself!

I just had a very pleasant experience installing and setting up Gogs.io on my server, so that I can self-host my private repositories.

I use nginx to serve my HTTPS domains, and Letsencrypt support for nginx is still in beta. I also have a relatively specialized nginx config setup so I don't want any automated script messing with those files. Below are the steps I took to use the letsencrypt tool to generate and automatically renew a certificate for a domain.

werd.io/2015/signed-feeds-pubsub-a-simple-verb-protocol-a-publisher-and

I have lived in IRC for about 7 years. What I mean by this is that IRC has been my primary hub for reading information online and interacting with people and systems. I don't use an RSS reader, I visit Twitter and Facebook only occasionally, and I try to limit my email usage to only business. Instead, I have created filters from various sources that send notifications to various IRC channels about things I am interested in.

Earlier this week, Eye-fi announced they are discontinuing the online services for the "Pro" cards in favor of the new cloud-connected "Mobi" ones. Since my primary use of the Eye-fi card is to upload my photos to Flickr, I have no interest in paying for their cloud service. Time to look for another card! Most of the other wifi SD cards on the market come with an iOS/Android app, and basically all they let you do is view the photos from the app if your phone is connected to the card's wifi. Then I discovered the Toshiba FlashAir card, which has a developer site and encourages people to build things on top of the card.

In August 2012, I wrote a quick script to stream front-page Hackernews stories to an IRC channel on Freenode. It broke after 2.5 years, at which point I switched to their new JSON API. That one broke after 2 days. Here is how we can fix this.

Since all of my recent spam has been sent to non-expired endpoints, and since I don't get a high number of webmentions right now, I decided to remove the expiring endpoints from my site for the time being.

In the current world of silos dominating the social media space, people typically have to visit half a dozen websites or apps to see all the latest content from friends. At this point I'm sick of this "multiple inbox" model that I want to find an alternative as fast as possible.