New problem: My notes do not have a "u-syndication" link to the app.net version like they do for the Twitter versions, because my code has no idea that app.net syndicated my post automatically using PourOver.
Possible solution: app.net could send me a webmention when they pull in one of my posts. Since I'd parse it and see their u-url link back to my post, I can at that point update my post to have the u-syndication link.
After I posted my article, An Open Challenge to App.net, @po shared it on App.net. You can see the full thread here.
Rather than respond individually to the replies on App.net, I thought it would be more appropriate to respond collectively with another post.
I send pingback (and webmention) notifications of any URLs I mention in posts on my site. If App.net supported receiving pingbacks, then you would have seen this post as a reply to your App.net post if you responded to me. Of course, pingback is one of the open standards App.net doesn't yet support, so if you replied to me on App.net, you will have found this post some other way.
No. This is completely missing the point. App.net should support open standards that are already in use across the web if they are trying to be something more than a social network silo.
It shouldn't take a third party to build a service that fills in for what App.net is lacking.
I should not have to create an account to join a conversation on the web. Guess who got this right? Status.net! Using Status.net, it's possible to subscribe to anybody's feed using PuSH, even if they have no idea what Status.net is!
This screenshot of a post on App.net illustrates the problem perfectly:
It's analogous to email. Can you imagine if you needed to create a Gmail account in order to send an email to someone else's Gmail address? Conversations across the web should work like conversations across email. I use my existing email address to join any email conversation. I want to use my existing website to join any web conversation.
Exactly. @tantek summarized it well in a couple notes on his site:
If you're building yet another social network and not trying to solve this, you're solving the wrong problems.
A common problem with self-described "federated" protocols is that they aren't actually federated. Email is a truly federated protocol. We have yet to see a solid player in the game for a federated web protocol.
Exactly.
People commonly think that just because some software can run on multiple servers that means it's federated. Really that just means it's distributed. It's easy to develop a distributed system, you don't need to talk to anybody else and you don't need to get anybody to agree. You just create your own protocol and build your own software and then deploy it.
This is the beauty of what we're working towards with the Indie Web building blocks. Everybody who is currently contributing functional code is working on their own in whatever language and environment they're used to, and we're making things talk at the protocol layer rather than the software layer.
Thanks to @po and @julien for backing me up on the App.net thread, and to @tantek for continuous insights and quotable sentences.
The best way to reply to this post is to create a post on your own site and send me a pingback or webmention notification.
I am no longer publishing content to my App.net account until I can syndicate my content to their service without writing a single line of code.
I should not have to write custom code to publish to App.net. App.net should be able to pull in content from my own site using my Atom/hAtom feeds, receiving real-time updates I send via PubSubHubbub.
Back in August, @brennannovak wrote an interesting post about app.net. Overall, he was very optimistic about the project, for many of the reasons most people are. (App.net's tagline is "We are selling our product, NOT our users.") At the bottom of his post, he asked @dalton to promise a few things in regards to interoperability with other systems supporting web standards.
In Dalton's response to Brennan Novak, he publicly stated that App.net will support the following things:
I understand development takes a long time, and I'm not asking Dalton to build all of this immediately. But ever since the project successfully raised funding, I haven't seen much improvement in supporting an open web. Instead, they've create a proprietary API not based on any existing standards, and have not added support for open standards.
I don't need another microblogging service to write content in and build another social network graph. I don't see the value of having yet another place to build a "friends" list.
What I would like to do, however, is to leverage social networks as distribution platforms for content created elsewhere. You see this all the time, people share links to things on these networks. More and more, people are using Twitter as way to just share links. They act as distribution hubs rather than a place where you create content.
Facebook has been doing a great job of showing inline previews of content before you click through to the link, and even Twitter launched Twitter Cards as a way to show a preview of linked content within their timeline.
As a distribution platform, these services like Twitter, Facebook and App.net are great. They allow people to find people whose content they are interested in, and easily subscribe to it. It's a central place people can go to get updates from their friends without having to visit a bunch of individual blogs. Sound familiar? It's all the same benefits RSS feed readers promised years ago!
I publish my short notes on my site, in HTML at aaronparecki.com/notes. Naturally I don't expect everyone to go look at that page all the time. I expect people to discover my content through distribution platforms.
Publishing my own content is only as useful as the number of people I have reading it. Rather than try to get a bunch of people to subscribe to my RSS feed, I can leverage these distribution platforms to syndicate my content to a wider audience.
At scale, a service dedicated to distribution of content can do a far better job of delivering content to many subscribers than my own site. This is one of the reasons behind the architecture of PubSubHubbub, where a Hub is a different system from the Publisher, and its only role is to push content to Subscribers.
Different platforms can compete on speed of delivery. I would expect some platforms could charge more for real-time delivery to a guaranteed number of subscribers, where other free ones may not have a guarantee.
Another way distribution platforms can add value is by providing analytics. Twitter is already doing this to a certain extent by showing the number of "retweets" and "favorites" a tweet gets. Some RSS services like Feedburner provided analytics to publishers such as showing the number of people subscribing to the feed.
Services like App.net should be like plumbing in your house. I can swap out copper pipes for plastic pipes any time I want, and the person upstairs using the faucet won't know the difference. Both pipes get the job done, to move water from one place to another.
If App.net is truly a valuable service, then they will excel at one of the value-adds that distribution platforms can provide. If this happens, I will enjoy using their service over anyone else's because of the features where they add value.
As a publisher of content on my own domain, I already provide hooks for people to read my content several different ways. I have a web page with a list of recent notes marked up using Microformats, an RSS feed that can be subscribed to in a feed reader, and I send a ping to a PuSH Hub when new content is posted, allowing anyone to get this content in real time.
That said, I fully understand very few people will actually find my content this way. More likely they will find the link I publish to Twitter, Facebook, and possibly Hackernews. These services are currently easier to use and will likely continue to be easier to use than RSS readers, which is why distribution hubs can still be a critical component of an open, independent web.
I should not have to write custom code to publish my content to App.net. Instead, they should consume my PuSH-enabled feed and automatically create a new post on my App.net account based on the content I create on my site.
App.net has a great opportunity to be a major player in the Indie Web. If App.net truly wants to support an open web, they need to commit to using existing open standards, and not require people to custom-build code to use their platform.
I would also like to personally challenge @dalton to participate in IndieWebCamp 2013 in Portland in June, or in Brighton in September.