After years of letting algorithms make up our minds for us, the time is right to go back to basics.
This article, which I’ve seen shared almost too widely on the internet since it came out, could almost have been written any time in the past decade really. They did do a somewhat better job of getting quotes from some of the big feed readers’ leaders to help to differentiate their philosophical differences, but there wasn’t much else here. Admittedly they did have a short snippet about Dave Winer’s new feedbase product, which I suspect, in combination with the recent spate of articles about Facebook’s Cambridge Analytica scandal, motivated the article. (By the way, I love OPML as much as anyone could, but feedbase doesn’t even accept the OPML feeds out of my core WordPress install though most feed readers do, which makes me wonder how successful feedbase might be in the long run without better legacy spec support.)
So what was missing from Wired’s coverage? More details on what has changed in the space in the past several years. There’s been a big movement afoot in the IndieWeb community which has been espousing a simpler and more DRY (don’t repeat yourself) version of feeds using simple semantic microformats markup like h-feed. There’s also been the emergence of JSON feed in the past year which many of the major feed readers already support.
On the front of people leaving Facebook (and their black box algorithmic monster that determines what you read rather than you making an implicit choice), they might have mentioned people who are looking for readers through which they can also use their own domains and websites where they own and maintain their own data for interaction. I’ve written about this in more depth last year: Feed reader revolution.
One of the more bleeding edge developments which I think is going to drastically change the landscape in the coming years for developers, feed readers, and the internet consumption space is the evolving Microsub spec which is being spearheaded by a group of projects known as the Aperture microsub server and the Together and Indigenous clients which already use it. Microsub is going to abstract away many of the technical hurdles that make it far more difficult to build a full-fledged feed reader. I have a feeling it’s going to level a lot of the playing field to allow a Cambrian explosion of readers and social related software to better leverage more easily reading content on the web without relying on third party black box services which people have been learning they cannot fully trust anymore. Aaron Parecki has done an excellent job of laying out some parts of it in Building an IndieWeb Reader as well as in recent episodes of his Percolator microcast. This lower hurdle is going to result in fewer people needing to rely solely on the biggest feed readers like Facebook, Twitter, and Instagram for both consuming content and posting their own content. The easier it becomes for people to use other readers to consume content from almost anywhere on the web, the less a monopoly the social networks will have on our lives.
This week, using the magic of open web standards, I was able to write an issue post on my own website, automatically syndicate a copy of it to GitHub, and later automatically receive a reply to the copy on GitHub back to my original post as a comment there. This gives my personal website a means of doing two way communication with GitHub.
This functionality is another in a long line of content types my website is able to support so that I’m able to own my own content, yet still be able to interact with people on other websites and social media services. Given the number of social sites I’ve seen disappear over the years (often taking my content with them), this functionality gives me a tremendously larger amount of control and ownership over my web presence and identity while still allowing me to easily communicate with others.
In this post I wanted to briefly sketch what I’ve done to enable this functionality, so others who are so inclined can follow along to do the same thing.
Setting up WordPress to syndicate to GitHub
I’ll presume as a first step that one has both a GitHub account and a self-hosted WordPress website, though the details will also broadly apply to just about any content management system out there that supports the web standards mentioned.
Register your GitHub account and your website with Bridgy
Ryan Barrett runs a fantastic free open sourced service called Bridgy. To use it you’ll need the microformat rel=“me” links on both your GitHub account and your website’s homepage that point at each other. GitHub will do most of the work on its side for you simply by adding the URL of your website to the URL field for your GitHub account at https://github.com/settings/profile. Next on your website’s homepage, you’ll want to add a corresponding rel=“me” link from your website to your GitHub account.
In my case, I have a simple widget on my homepage with roughly the following link: <a href="https://github.com/username">GitHub</a>
in which I’ve replaced ‘username’ with my own GitHub username. There are a variety of other ways to add a rel=“me” link to your webpage, some of which are documented on the IndieWeb wiki.
Now you can go to Brid.gy and under “Connect your accounts” click on the GitHub button. This will prompt you to sign into GitHub via oAuth if you’re not already logged into the site. If you are already signed in, Brid.gy will check that the rel=“me” links on both your site and your GitHub account reciprocally point at each other and allow you to begin using the service to pull replies to your posts on GitHub back to your website.
To allow Brid.gy to publish to GitHub on your behalf (via webmention, which we’ll set up shortly), click on the “Publish” button.
Install the Webmention Plugin
The underlying technology that allows the Bridgy service to both publish on one’s behalf as well as for the replies from GitHub to come back to one’s site is an open web standard known as Webmention. WordPress can quickly and easily support this standard with the simple Webmention plugin that can be downloaded and activated on one’s site without any additional configuration.
For replies coming back from GitHub to one’s site it’s also recommended that one also install and activate the Semantic Linkbacks Plugin which also doesn’t require any configuration. This plugin provides better integration and UI features in the comments section of one’s website.
Install Post Kinds Plugin
The Post Kinds Plugin is somewhat similar to WordPress’s Post Formats core functionality, it just goes the extra mile to support a broader array of post types with the appropriate meta data and semantic markup for interacting with Bridgy, other web parsers, and readers.
Download the plugin, activate it, and in the plugin’s settings page enable the “Issue” kind. For more details on using it, I’ve written about this plugin in relative detail in the past.
Install Bridgy Publish Plugin
One can just as easily install the Bridgy Publish Plugin for WordPress and activate it. This will add a meta box to one’s publishing dashboard that, after a quick configuration of which social media silos one wishes to support, will allow one to click a quick checkbox to automatically syndicate their posts.
Install the Syndication Links Plugin
The Syndication Links plugin is also a quick install and activate process. You can modify the settings to allow a variety of ways to display your syndication links (or not) on your website if you wish.
This plugin will provide the Bridgy Publish Plugin a place to indicate the permalink of where your syndicated content lives on GitHub. The Bridgy service will use this permalink to match up the original content on your website and the copy on GitHub so that when there are replies, it will know which post to send those replies to as comments which will then live on your own website.
You should now be ready to write your first issue on your website, cross post it to GitHub (a process known in IndieWeb parlance as POSSE), and receive any replies to your GitHub issue as comments back to your own website.
Create a new post.
In the “Kinds” meta box, choose the “Issue” option.
Type in a title for the issue in the “Title” field.
In the “Response Properties” meta box, put the permalink URL of the Github repopository for which you’re creating an issue. The plugin should automatically process the URL and import the repository name and details.
In the primary editor, type up any details for the issue as you would on GitHub in their comment box. You can include a relatively wide variety of custom symbols and raw html including
and with code samples which will cross-post and render properly.
In the GitHub meta box, select the GitHub option. You can optionally select other boxes if you’re also syndicating your content to other services as well. See the documentation for Bridgy and the plugin for how to do this.
Optionally set any additional metadata for your post (tags, categories, etc.) as necessary.
Publish your post.
On publication, your issue should be automatically filed to the issue queue of the appropriate GitHub repo and include a link back to your original (if selected). Your post should receive the syndicated permalink of the issue on GitHub and be displayed (depending on your settings) at the bottom of your post.
When Bridgy detects future interactions with the copy of your post on GitHub, it will copy them and send them to your original post as a webmention so that they can be displayed as comments there.
If you frequently create issues on GitHub like this you might want a slightly faster way of posting. Toward that end, I’ve previously sketched out how to create browser bookmarklets that will allow you one click post creation from a particular GitHub repo to speed things along. Be sure to change the base URL of your website and include the correct bookmarklet type of “issue” in the code.
The Post Kinds plugin will also conveniently provide you with an archive of all your past Issue posts at the URL http://example.com/kind/issue/, where you can replace example.com with your own website. Adding feed/ to the end of that URL provides an RSS feed link as well. Post Kinds will also let you choose the “Reply” option instead of “Issue” to create and own your own replies to GitHub issues while still syndicating them in a similar manner and receive replies back.
Given the general set up of the variety of IndieWeb-based tools, there are a multitude of other ways one can also accomplish this workflow (both on WordPress as well as with an infinity of other CMSes). The outline I’ve provided here is one of the quickest methods for beginners that will allow a relatively high level of automation and almost no manual work.
One doesn’t necessarily need to use the Post Kinds Plugin, but could manually insert all the requisite HTML into their post editor to accomplish the post side of things via webmention. (One also has the option to manually syndicate the content to GitHub by cutting and pasting it as well.) If doing things manually this way is desired, then one will need to also manually provide a link to the syndicated post on GitHub into their original so that Bridgy can match up the copy and the original to send the replies via webmention.
If you’ve followed many of these broad steps, you’ve given already given yourself an incredibly strong IndieWeb-based WordPress installation. With a minimal amount of small modifications you can also use it to dovetail your website with other social services like Twitter, Facebook, Flickr, Instagram, Google+ and many others. Why not take a quick look around on the IndieWeb wiki to see what other magic you can perform with your website!
I’ve documented many of my experiments, including this one, in a collection of posts for reference.
If you have questions or problems, feel free to comment below or via webmention using your own website. You can also find a broad array of help with these plugins, services, and many other pieces of IndieWeb technology in their online chat rooms.
I ran my domain through IndieWebify.me. Almost all of the rel=“me” links either don’t link back or couldn’t be fetched. The following work perfectly and can be used with the IndieAuth authentication plug-in.
That’s 4 out of 43.
Khürt , The majority of them don’t link back because the silos (like Keybase, Instagram, and Medium which you mention) aren’t putting the rel=”me” microformat on the URLs in your profile like Twitter, Github, and Flicker do. If you view the page source for those silos, you’ll see that they list your URL, but don’t have rel-me’s pointing back at you. Sadly, you can’t control these, though you could file issues with the sites that don’t to encourage them to.
The indiewebify.me site has a parser that is looking at the two sites to see that they not only point at each other, but it requires that the two links have the rel=”me” microformat on them. Most don’t, but this doesn’t mean too much in practice. Whether or not they both have rel=”me”, the only way both sites could point at each other indicates that you “own” or control them both. Kevin marks has proposed/built an interesting decentralized verification service based on them. His version is certainly much better distributed than Twitter’s broken verification set up.
Other than having a stronger two-way ownership indicator, what do you get out of them? As you mention, some have the ability to be used with IndieAuth. Those that can be used with IndieAuth are relying on the service (like Twitter or Github) having a OAuth implementation for signing into their services. This allows an indie site to piggyback on another services’ OAuth implementation without having to go through the trouble to build one themselves, which can be a lot of work to do, much less do correctly (securely). Most of the services you see not linking back not only don’t add the rel=”me” tag, but they also don’t support OAuth, so you wouldn’t get too much more out of having the correct reciprocal link anyway.
Incidentally, one of the benefits the rel=”me” links do have is that they allow you to use your website to log into the IndieWeb wiki to participate directly in that part of the community. (Give it a try!)
Some services like Brid.gy get around services like Instagram or Facebook not having a physical rel=”me” microformat because they’re relying on looking at the appropriate data (usually via API) on your profile page to see if it links back (either in your website field or typically in your bio).
Don’t be overly concerned that the vast majority of sites appear not to link back even if you’ve got links on both pointing back. (And if you think your batting average is bad with only 4 of 43, just imagine how many of my 200+ sites do?!)
If you want to see an interesting tech-forward application of rel=”me” and the XFN friends network, take a peek at Ryan Barrett’s Indie Map which he unveiled over the summer:
Some of these building blocks will likely add a lot more value later on as more and more sites explicitly indicate their relationship to and from each other.
I know that I have provided my perspective [already](https://readwriterespond.com/2017/10/indieweb-reflections/), but I have been doing a lot of thinking about it of late. There are so many elements that just feel so foreign. Take for example H-Cards.
Aaron, thanks for your continued thoughts on my post. These are some good observations. Interestingly, on November 9th of this month I had noticed that the h-card page on the wiki was one of the few around that had absolutely no section heading for IndieWeb Examples which is nearly ubiquitious on most other pages. (Examples of what others have done is not only a helpful guide, but helps to push the limits of what might be possible next.) I naturally added a section for them and added myself and made a call in the chat for others to do the same. One of the bits of feedback that resulted there was that the microformats.org wiki had a large number of examples and that was one of the reasons that the IndieWeb wiki had none. Naturally, for people in generation two and beyond this may be an issue as they’re potentially less likely to go looking for this information on another website. As of this afternoon, there’s now at least a link on that page that also points to the microformats wiki page for those other examples. I’ve also added a few other bits which may be helpful with regard to h-cards for the beginner.
As the IndieWeb continues onward, part of the underlying foundation is that “Each generation is expected to lower barriers for adoption successively for the next generation.” – from the Generations page on the IndieWeb Wiki.
To date, the majority of people in the movement are developers or programmers by trade, but increasingly there are people from generation 2, 3, and even many from generation 4 who are starting to take a look at what is now possible on the web that wasn’t just ten, twenty, or even thirty-six months ago. Many are not only just looking, but, like you, are spending the time, effort, and energy to implement what they’re able to and simultaneously spreading the word to larger circles.
As someone who personally identifies as being on the border of generations 1 and 2, I’m finding more and more people seeing what is happening and wanting the fruits and benefits of these tools for themselves. It’s the raw value they find in these methods and processes that spur them on even when they find themselves in deeper waters than they may have expected. Fortunately there are a large number of giving and helpful developers in the generation 1 crowd who are watching and listening to those coming after them. They’re taking up the mantle to not only improve things for just themselves, but to improve things for their fellow netizens.
All of this to say that there is currently a slow reworking and refining of material that’s on the wiki. It was only just earlier this week that a self-identifying fourth generation member asked about the word POSSE, which many would rightly consider jargon, and inquired about its relation to the more commonly known term of “cross-posting“. Surprisingly, cross-posting didn’t really exist on the wiki yet, but it was quickly added, and then later expanded to bring the ideas of POSSE, PESOS, PESETAS, and PASTA within it and then tied into the broader idea of syndication.
Your questions about h-card are very similar. Yes, the wiki page on the idea is certainly very generation 1 specific and perhaps a bit over-burdened by jargon. While I don’t think the concept of microformats is very difficult, I also realize that saying that is the result of having spent no less than ten hours reading about it, looking at examples, and implementing pieces of it by hand myself. So how can we make it simpler and easier for the next generation? The page needs a bit of overhaul and work for the next generations. Some of this is my goal in writing an IndieWeb book, though it’s geared toward an audience that is less likely to get their information from a wiki or contribute back to one in practice.
While h-card is a specific type of microformat, in practice most instances of it on the wiki are really referring to an object on a webpage that conveys identity. I’d suggest that it’s far easier to look at an h-card as an online version of a business card that contains some basic information about a person (or even a business or other entitiy) online. It has things like their name, their address, their email, their phone number, perhaps a photo, or even other very basic information about them. Each of these pieces of data has its own microformats to indicate to machines what they specifically represent. While some h-cards are human readable (like mine), some could be hidden in a web pages’ header and are meant to be machine readable.
While h-cards can convey data in other use cases, in most IndieWeb instances they’re conveying information about either the owner of a website (and thus found on the site’s homepage), or they’re found on individual posts as indicators of the authorship of the content on that page.
Depending on how they’re nested into a web page, they can have different meanings. As possibly the most common example on a traditional WordPress article post, the main h-card for the page would indicate information about the author of that post. However, these article posts will often contain comments sections at the bottom and each individual comment will have it’s own separate author and author information and thus its own h-card. Because these comments are properly nested, they only indicate the authorship of each particular sub-section of a page.
For most IndieWeb use, having an h-card on your homepage tells parsers (code run by other computers) who you are and some basic information about yourself. Generally this extends to your name, your avatar, and your homepage URL.
In your case Aaron, when you’ve generally been sending me webmentions from your primary website (readwriterespond.com), I’ve often been missing your avatar in your comments because you didn’t have an h-card available on them. (I typically remedy this on my own website by hand because I’ve been able to guess the email address/”key” you use for your Gravatar account which then automatically fills in that missing data for me on those comments.)
In the particular case here, for your reply you’ll notice in looking at the source for the page with your response that your ZenPress theme smartly and kindly includes an h-card for you automatically. Here’s what it looks like in code:
You’ll see that it includes (and I’ve highlighted them in red with the relevant microformats classes) your name, your website URL, and it also pulls in your Gravatar avatar using the WordPress back end, since you’ve provided your WordPress installation this data. This is the benefit of a smartly built and designed theme! Thus it would seem that for your “Collect” site, you needn’t worry about an h-card because your theme is already handling the details for you to a great extent. Ideally all themes would do this using standard data fields within a WordPress install. But until then…
Anticipating your next question, what about readwriterespond.com? There, your theme isn’t doing this work for you, so you’ll need to do it yourself. The easiest way to pull this off quickly is to use the IndieWeb Plugin for WordPress. The plugin adds a bunch of additional fields to the page under the “Users” menu located at /wp-admin/profile.php within your admin UI. By filling them in you’re providing the details you’d usually add to an h-card or for rel=”me” uses. The IndieWeb plugin then also makes an h-card widget available at /wp-admin/widgets.php. You can drag and drop it to any of the available pieces of your theme which often include sidebars, footers, and sometimes headers.
The widget does a relatively good job, but some will want more control over what and how things are presented and designed. For those, another option is to create your own HTML-based widget and put the code/data for your h-card into it. This is essentially what you’ve seen on my homepage at boffosocko.com. While mine is entirely handcoded, it may be easier for most to use the microformats website which has a fill-in-the-blanks h-card generator that will allow one to input all of the data they’d like to display and it will automatically mark all of it up properly so that one can cut and paste the semantic HTML directly into a web page or a widget.
There are a bevy of other options for dropping an h-card into your site which will work. You mentioned doing something via a child-theme and that’s an option as well as any one of dozens of plugins that will allow you to drop arbitrary code into your header and/or footer. (Incidentally a child-theme is an excellent way of doing small customizations of your theme without preventing future (security) updates of your theme from overwriting them. If you’re not using one, I recommend following one of the tutorials on the wiki to create one. I would hope it shouldn’t take you more than an hour to implement based on what I know of your skill level.)
As I think you’ve mentioned, there are a few simple validators that will accept a URL which they can parse to show the h-card data they find. These include:
pin13.net, an mf2 parser which outputs raw parsed JSON
People can use these to see if their h-cards are working as they generally expect them to.
Naturally, there are some additional subtleties in h-cards which are noted on both the IndieWeb wiki and the microformats wiki pages, but most of these aren’t of huge consequence to average users or are experimental features which aren’t widely distributed or supported. If it makes you feel better, I’ll also note that it’s not always the case that experienced theme builders or even WordPress core maintainers will properly use microformats as there are frequently cases where they’re wildly misused, abused, or mistreated in the extreme. We can only do our best I suppose…
Hopefully some of this helps put things into perspective. Now that you’re able to sign into the IndieWeb wiki, I invite you to add or modify parts you feel could be clearer or improved as you use and implement them yourself. Surely doing so will help make things easier for those that follow us both.
Syndicated copies to:
I wrote in the morning again with one or two small snippets later in the evening. I focused mostly on the topic of rel=”me” for profile equivalence and identity-consolidation with about 1,882 words.
I added a couple of new chapter ideas that will need to be fleshed out as well–I’m surprised I’m still coming up with outline pieces.
Today: 3,115 words
Total: 6,532 words
At the end of NaNoWriMo day 1, I’ve added 2,859 words, most of them written in the early morning. A chunk is in the introduction, but the biggest part includes a relatively solid 1,800 words on the topic of microformats.
The power company decided to turn the power off at the home office today, so I had to migrate over to the local Starbucks for an impromptu write-in.
It’s probably going to take me a few weeks of heaving editing when the whole thing is said and done, but overall it felt like a terrifically productive first day. I am managing to get a bit of light editing done as I go through, particularly to try and make sure I don’t miss anything too significant. I’m going to need to spend a few days on screen captures when this is all said and done.
The best part is that even with a short section of code, the whole file compiled on the second run! And this was without putting any real effort into it as I was writing.
Hopefully in the coming week, based on output versus the scope of the outline I’ve set, I’ll have a better idea about how much of the book I’ll be able to finish within the month. I’m presently a tad concerned that it’ll take a few additional weeks to properly cover all the introductory topics I want to touch upon.
I keep having to remind myself of the likely technical level of the audience, but I feel like I’m keeping it simple enough to be clear while hopefully encouraging people to want to learn more about eventually learning to write some code themselves when they’re done reading and working through the book.
I’m happy that it feels like it’s almost writing itself, but the couple of dozen sites I’ve built in the past few years and a relatively solid outline are helping a lot.
Today: 2,859 words
Total: 3,417 words
Syndicated copies to:
I’m not sure what’s changed recently but I went from a few spam comments on my website every week to hundreds a day.
Now that I have a larger and more diverse set of post types, it’s become more entertaining to read the incongruous spam posts about how brilliant and insightful I am when I’ve just posted a simple checkin.
Spammers are going to have to start using microformats parsers to know which post types to properly add their spam to in the future.
We tend to have a love/hate relationship with social networks. The ability to interact with friends, colleagues, and even celebrities is wonderful, but the lack of control over privacy or content algorithms is troubling. A better way lies ahead, where you aren't tied to large social networks and where you can own your own data.
Recorded at Atlanta Connect.Tech 2017 on 9/21/2017
A few weeks back Keith gave a great non-platform specific overview to some of the moving pieces of the IndieWeb at Connect.Tech 2017 in Atlanta. I wish I could have been there in person, but glad that it was archived on video for posterity.
Somehow I managed to get a mention in his talk as did our friend Jeremy Cherfas.
Commenting on blog posts and other website articles is a divisive topic in web circles. WPMU DEV has as many articles about dispensing with comments altogether as it does with fostering conversation through WordPress!
Michael, good job bringing some attention to these two new specs!
After having used Webmentions on my site for 2+ years, I think you (and the Trackbacks vs Pingbacks vs Webmentions for WordPress article) are heavily underselling their true value. Yes, in some sense they’re vaguely similar to pingbacks and trackbacks, but Webmentions have evolved them almost to the point that they’re now a different and far more useful beast.
I prefer to think of Webmentions as universal @mentions in a similar way to how Twitter, Facebook, Google+, Instagram, Medium and others have implemented their @mentions. The difference is that they work across website boundaries and prevent siloed conversations. Someone could use, for example, their Drupal site (with Webmentions enabled) and write (and also thereby own) their own comment while still allowing their comment to appear on the target/receiving website.
The nice part is that Webmentions go far beyond simple replies/comments. Webmentions can be used along with simple Microformats2 mark up to send other interactions from one site to another across the web. I can post likes, bookmarks, reads, watches, and even listens to my site and send those intents to the sites that I’m using them for. To a great extent, this allows you to use your own website just as you would any other social media silo (like Facebook or Twitter); the difference is that you’re no longer restrained to work within just one platform!
Another powerful piece that you’re missing is pulling in comments and interactions from some of the social services using Brid.gy. Brid.gy bootstraps the APIs of Facebook, Twitter, Instagram, Google+, and Flicker so that they send webmentions. Thus, I can syndicate a post from my WordPress site to Twitter or Facebook and people commenting in those places will be automatically sending their commentary to my original post. This way I don’t really need to use Facebook natively to interact anymore. The added bonus is that if these social sites get shut down or disappear, I’ve got a copy of the full conversation from other places across the web archived in one central location on my personal site!
To add some additional perspective to the value of Webmentions and what they can enable, imagine for a moment if both Facebook and Twitter supported Webmentions. If this were the case, then one could use their Facebook account to comment on a Tweet and similarly one could use their Twitter account to like a Facebook post or even retweet it! Webmentions literally break down the walls that are separating sites on the web.
If it helps to make the entire story clearer and you’d like to try it out, here’s the link to my original reply to the article on my own site. I’ve syndicated that reply to Twitter and Facebook. Go to one of the syndicated copies and reply to it there within either Twitter/Facebook. Webmentions enable your replies to my Twitter/Facebook copies to come back to my original post as comments! And best of all these comments should look as if they were made directly on my site via the traditional comment box. Incidentally, they’ll also look like they should and absolutely nothing like the atrociousness of the old dinosaurs trackbacks and pingbacks.
Rel=”me” is a microformat tag put on hyperlinks that indicates that the paged linked to is another representation of the person who controls the site/page you’re currently looking at. Thus on my home page the Facebook bug has a link to my facebook account which is another representation of me on the web, thus it has a rel=”me” tag on it.
His data is a bit old as I now maintain a page entitled Social Media Accounts and Links with some (but far from all) of my disparate and diverse social media accounts. That page currently has 190 rel=”me”s on it! While there was one other example that had rel-mes pointing to every other internal page on the site (at 221, if I recall), I’m proud to say, without gaming the system in such a quirky way, that each and every one of the rel=”me” URLs is indeed a full legitimate use of the tag.
I’m proud to be at the far end of the Zipf tail for this. And even more proud to be tagged as such during the week in which Microformats celebrates its 12th birthday. But for those doing research or who need edge cases of rel-me use, I’m also happy to serve as a unique test case. (If I’m not mistaken, I think my Google+ page broke one of Ryan’s web crawlers/tools in the past for a similar use-case a year or two ago).
The Moral of the Story
The take away from this seemingly crazy and obviously laughable example is simply just how fragmented one’s online identity can become by using social silos. Even more interesting for some is the number of sites on that page which either no longer have links or which are crossed out indicating that they no longer resolve. This means those sites and thousands more are now gone from the internet and along with them all of the data that they contained not only for me but thousands or even millions of other users.
This is one of the primary reasons that I’m a member of the Indieweb, have my own domain, and try to own all of my own data.
While it seemed embarrassing for a moment (yes, I could hear the laughter even in the live stream folks!), I’m glad Ryan drew attention to my rel-me edge case in part because it highlights some of the best reasons for being in the Indieweb.
(And by the way Ryan, thanks for a great presentation! I hope everyone watches the full video and checks out the new site/tool!)
Tweetstorms have been getting a horrific reputation lately.  But used properly, they can sometimes have an excellent and beneficial effect. In fact, recently I’ve seen some journalists using it for both marketing and on the spot analysis in their areas of expertise.Even today Aram Zucker-Scharff, a journalism critic in his own tweetstorm , suggests that this UI form may have an interesting use case in relation to news outlets like CNN which make multiple changes to a news story which lives at one canonical (and often not quickly enough archived) URL, but which is unlikely to be visited multiple times:
Why not publish a sequence of small stories that connect together rather than one big one on the same URL that keeps changing?
Why not publish a sequence of small stories that connect together rather t
— Aram Zucker-Scharff (@Chronotope) February 10, 2017
A newsstorm-type user experience could better lay out the ebb and flow of a particular story over time and prevent the loss of data, context, and even timeframe that otherwise occurs on news websites that regularly update content on the same URL. (Though there are a few tools in the genre like Memento which could potentially be useful.)
It’s possible that tweetstorms could even be useful for world leaders who lack the focus to read full sentences formed into paragraphs, and possibly even multiple paragraphs that run long enough to comprise articles, research documents, or even books. I’m not holding my breath though.
Technical problems for tweetstorms
But the big problem with tweetstorms–even when they’re done well and without manthreading–is actually publishing them quickly, rapidly, and without letting any though process between one tweet and the next.
Noter Live–the solution!
Last week this problem just disappeared: I think Noter Live has just become the best-in-class tool for tweetstorms.
Noter Live was already the go-to tool for live tweeting at conferences, symposia, workshops, political debates, public fora, and even live cultural events like the Superbowl or the Academy Awards. But with a few simple tweaks Kevin Marks, the king of covering conferences live on Twitter, has just updated it in a way that allows one to strip off the name of the speaker so that an individual can type in their own stream of consciousness simply and easily.
But wait! It has an all-important added bonus feature in addition to the fact that it automatically creates the requisite linked string of tweets for easier continuous threaded reading on Twitter…
When you’re done with your screed, which you probably wrote in pseudo-article form anyway, you can cut it out of the Noter Live app, dump it into your blog (you remember?–that Twitter-like app you’ve got that lets you post things longer than 140 characters at a time?), and voila! The piece of writing that probably should have been a blog post anyway can easily be archived for future generations in a far more readable and useful format! And for those who’d prefer a fancier version, it can also automatically add additional markup, microformats, and even Hovercards!
Bonus tip, after you’ve saved the entire stream on your own site, why not tweet out the URL permalink to the post as the last in the series? It’ll probably be a nice tweak on the nose that those who just read through a string of 66 tweets over the span of 45 minutes were waiting for!
So the next time you’re at a conference or just in the mood to rant, remember Noter Live is waiting for you.
Aside: I really wonder how it is that Twitter hasn’t created the ability (UX/UI) to easily embed an entire tweetstorm in one click? It would be a great boon to online magazines and newspapers who more frequently cut and paste tweets from them to build articles around. Instead most sites just do an atrocious job of cutting and pasting dozens to hundreds of tweets in a long line to try to tell these stories.
Much like WordPress’s native post formats (standard, aside, image, quote, link, status, audio, etc.) which were introduced in v3.1, Post Kinds instead provides a better mapping of post types across a larger variety of social media types (article, bookmark, favorite, itinerary, jam, like, listen, note, photo, play, read, reply, repost, watch, and more). In addition to changing the visual layout and formatting of most posts, the plugin also importantly includes the correct microformat classes for each of these post types and this enables a lot of other fantastically important functionality for the open web.
Custom URLs for Post Kinds
One of the problems I had with using it initially was taking the extra time to cut and paste in the several pieces of additional data or fill in meta data to make a post. It was particularly painful in a mobile setting. I was thrilled when David mentioned that he’d built in some customized query parameters which could take URLs to import in much of the data as well as to set the correct post kind automatically. They came with the general format of
where one could replace @url with the target URL of the site to be bookmarked, for example. Replacing bookmark with the appropriate post kind name would allow one to set the flag for each post to the proper post kind automatically, and naturally one should replace example.com with the base URL for their site.
Putting this customized URL into a browser will create a new post in one’s website admin UI and Post Kinds will automatically set the URL and scrape its meta data. One can then modify any additional data or add a comment and then publish quickly and easily.
As a concrete example, I would put the following URL in my browser of choice to “like” the Post Kinds Plugin page: http://www.boffosocko.com/wp-admin/post-new.php?kind=like&kindurl=https://wordpress.org/plugins/indieweb-post-kinds/
Below is the modified code that can be put into a bookmarklet to allow for easily bookmarking a particular post:
Other versions of the bookmarks can easily be made for all the other other Post Kinds by replacing the two red highlighted portions of the code sample appropriately for each one. Specifically one should exchange bookmark with the name of the kind desired (all of them should be in lowercase) and replace example.com with one’s own domain name.
Perhaps I (or someone else enterprising) would contribute all this back into the plugin repository for Post Kinds so that these bookmarklets would be self-generated for plug and play usage within the admin interface for the plugin the way the bookmarklets are for the IndieWeb plugin’s PressThis bookmarklets, perhaps at /wp-admin/admin.php?page=kind_options.
A Post Kinds “Bookmarklet” for Mobile
For those who would like something similar to the above for use on mobile platforms (and particularly Android) I’ve written up some instructions below which allow one to use the Android app URL Forwarder to use the ubiquitous mobile “share” functionality from most pages and/or apps in a way similar to this bookmarklet functionality. (This is based in part on some work by Ryan Barrett and some work I’d written up for the Known CMS a while back.)
I’d suspect that there’s also a similar app for iOS, but I haven’t checked. If not available, URL Forwarder is open source on Github and could potentially be ported. There’s also a similar Android app called Bookmarklet Free which could be used instead of URL Forwarder.
Configuring URL Forwarder for Post Kinds
Open URL Forwarder on your phone
Click the “+” button to create a filter.
Give the filter a name, “Bookmark” for the bookmark version. (See photo below.)
Use the following entry for the “Filter URL” replacing example.com with your site’s domain name: http://EXAMPLE.com/wp-admin/post-new.php?kind=bookmark&kindurl=@url
Leave the “Replaceable text” as “@url”
Finish by clicking on the checkmark in the top right corner.
Repeat the above for the other desired post types but replacing “bookmark” with the lower case names of those other types.
Configuring URL Forwarder
To bookmark a page, use the share icon and choose the URL Forwarder app
Select the appropriate option from the menu based on the site and post type you want to create. (You can set things up for multiple sites!)
Creating a post via mobile
With the configuration above set up, do the following:
On the mobile page one wants to bookmark, like, favorite, etc., click the ubiquitous “share this” mobile icon (or share via a pull down menu, depending on your mobile browser or other app.)
Choose to share through URL Forwarder
Click on the “bookmark” option just created above (or other option as necessary for the desired post type).
Change/modify any meta data within your website administrative interface or add any additional thoughts and publish. (This part is the same as one would experience using the desktop bookmarklet.)
After having spent the weekend at IndieWebCamp Los Angeles, it somehow seems appropriate to have a “Voted post type” for the election today†. To do it I’m proposing the following microformats, an example of which can be found in the mark up of the post above. This post type is somewhat similar to both a note/status update and an RSVP post type with a soupçon of checkin.
<span class="p-voted">I voted</span>
in the <a href="http://example.com/election" class="u-voted-in">November 8th, 2016 Election</a>
Possible Voted values: I voted, I didn’t vote, I was disenfranchised, I was intimidated, I was apathetic, I pathetically didn’t bother to register
Send a Webmention to the election post of your municipality’s Registrar/Clerk/Records office as you would for a reply to any post.
You should include author information in your Voted post so the registrar knows who voted (and then send another Webmention so the voting page gets the update).
Here’s another example with explicit author name and icon, in case your site or blog does not already provide that on the page.
The IndieWeb movement is a global community that is building an open set of principles and methods that empower people to take back ownership of their online identity and data instead of relying on 3rd party websites. Come learn more about the next generation of the Web.
For the first time since 2013, when it appeared in Hollywood, IndieWebCamp is coming to Los Angeles! I’m definitely going, and I invite you to join us. For the past two years or so, I’ve been delving into the wealth of tools and resources the community has been developing. I’m excited to attend a local camp, help out in any way I can, and will help anyone who’s interested in learning more.
Join us in LA (Santa Monica) for two days of a BarCamp-style gathering of web creators building and sharing open web technologies to empower users to own their own identities & content, and advance the state of the #indieweb!
The IndieWeb movement is a global community that is building an open set of principles and methods that empower people to take back ownership of their identity and data instead of relying on 3rd party websites.
At IndieWebCamp you’ll learn about ways to empower yourself to own your data, create & publish content on your own site, and only optionally syndicate to third-party silos. Along the way you’ll get a solid grounding in the history and future of Microformats, domain ownership, IndieAuth, WebMention and more!
For remote participants, tune into the live chat (tons of realtime notes!) and the video livestream (URL TBD).
General IndieWeb Principles
Your content is yours
When you post something on the web, it should belong to you, not a corporation. Too many companies have gone out of business and lost all of their users’ data. By joining the IndieWeb, your content stays yours and in your control.
You are better connected
Your articles and status messages can go to all services, not just one, allowing you to engage with everyone. Even replies and likes on other services can come back to your site so they’re all in one place.
You are in control
You can post anything you want, in any format you want, with no one monitoring you. In addition, you share simple readable links such as example.com/ideas. These links are permanent and will always work.
1333 2nd Street, Suite 200
Santa Monica, CA, 90401
United States Map
Day 0 is an optional prep night for people that want to button up their website a little bit to get ready for the IndieWebCamp proper.
18:30 Organizer setup
19:00 Doors open
19:30 Build session
22:00 Day 0 closed
Day 1 Discussion
Day 1 is about discussing in a BarCamp-like environment. Bring a topic you’d like to discuss or join in on topics as they are added to the board. We make the schedule together!
08:00 Organizer setup
08:30 Doors open – badges
09:15 Introductions and demos
10:00 Session scheduling
12:00 Group photo & Lunch
13:00 Sessions on the hour
16:00 Last session
17:00 Day 1 closing session, break, meetup later for dinner
Day 2 Building
Day 2 is about making things on and for your personal site! Work with others or on your own.
09:30 Doors open – badges
10:10 Day 2 kick-off, session scheduling
10:30 Build sessions
12:00 Catered lunch
14:30 Build sessions continue
16:30 Community clean-up
17:00 Camp closed!