2013-04-19: the day the indieweb successfully federated a comment post.

The Test Note

It started with Laurent Eschenauer using Storytlr to post a simple note on his site that sent mention pingbacks to Barnaby Walters and Aaron Parecki:

Testing #indieweb federation with @waterpigs.co.uk, @aaronparecki.com and @indiewebcamp.com !

Laurent Eschenauer, 2013-04-19

The Prompt Reply

Less than 10 minutes later, Aaron Parecki used p3k to post a reply on his own site, which sent a pingback to Laurent's post and was automatically syndicated there as a comment on that post. Laurent's site automatically parsed Aaron's reply's h-entry microformat markup to retrieve its text, permalink, datetime of publication, and authorship information. The HTML+microformats of Aaron's reply literally acted as its own API. No separate meta tags or sidefiles in another syntax needed. No separate "api.***" URL. No API key. No TOS.

The Follow-up Commentary

Two days later, Christophe Ducamp used WordPress with some indieweb plugins to post a blog post commenting about Laurent's note, also pinging it and automatically being syndicated into its "Comments" section, again by Laurent's site parsing the microformats at the comment permalink.

One day after that, Barnaby Walters used Taproot to post a reply on his own site congratulating Laurent and also had his comment incorporated into the growing thread on Laurent's post.

Who will be next?

Four independents, from four different countries (Belgium, USA, France, England), on four personal sites, with four implementations.

Who will be the next to post an indieweb comment on Laurent's post?

Laurent's personal site running Storytlr is the first to accept indieweb comment pingbacks, parse the h-entry microformats at their permalinks, and automatically display them as full fledged comments, beautifully styled to look as good and as natural as any local comment.

Who will be the next to accept indieweb comment pingbacks (or preferably webmentions) and automatically display them on their posts?

The federated indieweb is here and growing.

Join us on IRC and in person at IndieWebCamp 2013 this June in Portland, Oregon.

Elsewhere

• Twitter
• Google+
• Hacker News

Translations

• Le Premier Fil de Discussion Fédéré de Commentaires #Indieweb by Christophe Ducamp

I have to admit that sometimes standards work can be annoying and frustrating. There are misbehaviors that I've tired of and I'm unsure how to reduce their occurrences in the future.

Normally when something (like a standards discussion) provokes such a negative emotional response my first assumption is that perhaps it's me, not the apparent source. Maybe it's something about my context that may be contributing: the day, recent unrelated experiences, etc.

So I braindump into a text file, I write a draft reply, save it, and wait. A day. A few days. A week. I sample time series emotional data. More often than not upon delayed re-evaluation, the negative emotional responses decrease, decay, or outright disappear. The braindump/draft has served its purpose to process the emotions without propagating them, leaving only rational criticisms to rewrite in a constructive form.

But sometimes, there's little or no change, which to me means that yes, there's a problem. And sometimes the problems pile up. So here's a brief list of recent frustrations, without links to specific examples (for now), to at least bring up the problems:

• plagiarism - copying without citing sources. Just because something is liberally licensed (e.g. in the public domain or apparently so) doesn't make it any less wrong to copy it and neglect to cite your source. It's lazy at best, and deceptive at worst.
• excess generality/hierarchy/complexity - making things more generic/hierarchical/complicated than necessary.
• ignorance of existing standards (one possibility)
• deliberate divergence from existing standards (the other possibility) without explicitly stated/explained reasons
• gratuitous renaming of terms - a particularly bad (yet all too common) case of divergence
• re-using a URL for the "latest version" of specification when the specification has fundamentally changed in non-trivial ways

In an attempt to provide a glimmer of positivity, here's the logical complement, the constructive suggestions (which I'd love feedback on how to improve so they're more well practiced).

• always cite your sources
• start simple - simpler than you think possible, and only add as a result of iteration with real world implementations
• research existing standards
• reuse existing standards, or portions thereof. And if you do choose to diverge, document your reasons for doing so.
• make new URLs for new specifications. URLs are cheap. Leave the old ones in place so past references still make sense. If an old specification is no longer maintained, say so and provide a forward pointer to whatever new approach you're taking.

Are these constructive suggestions helpful? How would you improve them? How can we better teach them to folks that are new to standards development?

In a post on branch, Brian Oberkirch asks, Why are silos beating the light out of an open social Web? with some insightful points by Dave McClure. The biggest change I've seen in this debate over the years is a shift from "versus" to "leverage", and a recognition of the strengths of different approaches and in having a diversity of approaches.

Always selfdogfood

First, let's dissect Dave's points one at a time:

"1) the problems we were interested in were only relevant to geeks"

This is a fair criticism of a lot of open social web work, though the seemingly obvious response was ironically worse. When open social web geeks attempted to prematurely design their technologies/solutions to attempt to work "for everyone" or for your (insert less tech-savvy family-member stereotype here), they ended up creating solutions that no one wanted for themselves, not even the geeks on their own websites. WebFinger is a prime example here.

The answer is not to not "only [be] relevant to geeks", but rather, reframe it as a positive, and be relevant to yourself. That is, design, architect, create, and build for yourself first, others second. If you're not willing to run your design/code on your own site, for your primary identity on the web, day-in and day-out, why should anyone else? If you started something that way but no longer embrace it as such, start over. Go Selfdogfood or go home.

Copy, simplify, personalize UX

Next point:

"2) our UX sucked and no real people wanted to use them"

UX is hard. Design is hard. Both are so hard that even silos screw up sometimes (often?) and regress in their interfaces. Look at how cluttered even Twitter has become, as compared to their initial simple input box on top of a stream of posts interface.

Another side-effect of selfdogfooding is that it makes you self-conscious about the look and usability of what you're creating, because you're putting it on your own primary identity on the web! It's a constant emotional feedback loop that forces you to keep improving it. If all you're working on is an open source project that you expect other people to download and use, then all the design and UX problems are one level removed, they're a to-do list instead of a personal impression problem and are less likely to be fixed.

Want a decent UX? Steal from the best and then simplify. All the silos are pressured to clutter and corrupt their UX with ads, "stickiness", "engagement", and all kinds of other garbage in a never-ending hamster-wheel chase of ever more page views. You don't have that problem. Take their best stuff and make it simpler, more elegant by cutting out all that crap. And then iterate.

Business, web architecture, why not both?

Dave's last paraphrased point:

"3) we weren't working on the business drivers & instead put our faith in the architecture of the Web as a thing that should and would seek its own level in terms of creating and parsing out value."

Too bad about the web. If only Tim Berners-Lee had focused on the "business drivers", maybe HTML, HTTP, and URL would have succeeded.

But seriously, the point is not so much about putting "faith in the architecture of the Web as a thing" (though there's plenty of examples demonstrating the greater robustness/longevity of "webby"/decentralized architectures over centralized ones), but more about focusing on solving real problems for people, starting with yourself, and connecting with those you care about.

People pay hundreds of dollars annually to providers to own their own cell phone numbers which they can use to contact others with phone numbers. They can "port" their numbers from one provider to another.

Some (new?) ISP/domain/web host will eventually figure out a way to make it just as easy to sign-up for a domain and web hosting as it is to get a cell phone number, and with the right software, just as (more) useful, as well as portable to other hosting providers. A portable "one-click indieweb setup" as it were.

And why not both? How about a "phone" that would let you "txt" someone via their domain name? All you would need would be an open web based device, an indieweb messaging protocol & library, and a simple webapp to do so.

I'd much rather say "just txt tantek.com" than "txt (10-number-sequence)". There are even hints at attempts at backward compatibility with solutions like Apple's iMessage, which albeit limited to iOS and latest OSX devices, still let me say "just iMessage tantek at tantek dot com" and receive it on my iPod, without having to pay a cell provider for the service. I am not a number, I am my domain name.

Leverage the silos

Brian wrote:

"Fast forward & almost everyone works at one of the silos"

Some are certainly trapped behind gilded walls, lost in silo-specific UX and product design. Some are just tired of protocols and instead are getting paid to learn how to make user-useful interfaces. Others are (were) even trying to change things from the inside. Whatever the reason, it's clear there's more to be gained by figuring out how to leverage silos, instead of leaving them. Individuals who work at Google, Twitter, and other silo hosts have actively and positively contributed to IndieWebCamp every year, often with new and helpfully broadening perspectives.

The evolution of indieweb identity

"ID & social graph is dominated by them [the silos]"

No doubt there. Facebook "Connect" is not merely an option but sometimes required (Massive Health, Lyft). OpenID proponent Simon Willison wrote about why he used Twitter sign-in instead of OpenID for his own startup Lanyrd (I'd link to his post but his domain simonwillison.net appears to be down).

Though new adoptions of OpenID appear to be waning, it's still in use in plenty of places, sometimes even required, e.g. to submit a proposal for the Open Source Bridge conference (which you should and can do until the 23rd).

Mozilla's Persona appears to be gaining some adoption (see also: Persona on MDN).

And lastly, there's Web Sign-in (based on RelMeAuth) which leverages various silos' OAuth support to provide independent domain based identity. The best example of Web Sign-in is the nice service-based version IndieAuth which the IndieWebCamp.com wiki and several indieweb sites support for signing-in.

Try IndieAuth with your domain name and see how it works.

Feeds are dying, long live feed semantics

Brian continues:

"feeds themselves feel like they might be failing"

Indeed. Yesterday's announcement that Google is retiring Google Reader adds weight to that. Although it's possible that Google culturally/hierarchically doesn't care about building services on the open web (aside from search), preferring instead to funnel everyone (via search, Gmail, YouTube) into their G+ silo.

Then again, maybe we don't need separate feeds anymore. Feeds were always a bizarre DRY violation, often of lower quality than the home page they claimed to be an "alternate" of.

We're using the h-entry microformat (update to hAtom) to markup our blog archives and our home page updates with feed semantics that anyone can easily parse with open source libraries.

Just design/code/build/ship/share it

"Should we try to put these ideas back into play? Admit that we framed it incorrectly? Or is the outlook better than what I have described?"

Yes.

Many of the "open social web" ideas have been either misframed or misprioritized, e.g. federation rather than people, or designing for every-person something you won't even run for yourself.

If we take the more positively framed approach, focusing on building stuff you'll use every day yourself, and focusing on connecting with each other, we end up with a different set of diverse building blocks, some of which look a lot like old building blocks, but repurposed to be useful to us immediately, rather than useful someday to someone, and taking a diversity of approaches, rather than advocating a monoculture around any one particular open source project.

If you care about the "open social web", then put your online identity on the line. Get started with your own indie web site. Create and ship some of your own design/UI/code for it and then share it.

Join the indieweb

Finally, if you've gotten this far, you should join the rest of us doing so:

• Immediately, on IRC: #indiewebcamp on Freenode.
• In person, at IndieWebCamp 2013, June 22-23 in Portland, Oregon

Together, with a diversity of approaches/designs/implementations, we can keep advancing the indieweb, regardless of what silos rise and fall in the meantime.

Previously, previously, previously

• 2012-12-18 Every time I chat with @brianoberkirch I seem to spew a blog post...
• 2012-06-22: Great @radar @haxor interview on PubSubHubbub, federation vs engagement, #indieweb
• 2011-06-30: On Google Plus, Pownce Prior Art, Friends over Federation, Day One Data Export and This Summer's Social War

Elsewhere

• Twitter
• Google+
• Hacker News

Translations

• À Propos des Silos vs un Web Social Ouvert [#indieweb] by Christophe Ducamp

Comments

1. 2013-03-14 Barnaby Walters: “I am not a number, I am my domain name”
2. 2013-03-14 Ben Werdmuller: Silos, the open web, and selfdogfooding
3. 2013-03-15 Tom Morris: Some indieweb reading matter: ...
4. 2013-03-15 Jeremy Keith: On Silos vs an Open Social Web by Tantek
5. 2013-03-15 Laurent Eschenauer: On Silos vs an Open Social Web [#indieweb] - by @t

Want to comment? Post your comment on your own site and mention this post somehow. Maybe even on a syndicated copy of your comment on Twitter.