#adn
-
A response to replies I received on my post "An Open Challenge to App.net"
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.
"Won't (insert single point of failure free service here) achieve what he wants?"
-
I guess he never heard about #buffer or #IFTTT? Either way he won't be missed >> @po: "An open challenge to app.net"04:52 PM - 30 Mar 2013
-
@darnell I'm with you in not being too worked up over it taking a few steps to just firehose content here without actually participating.05:19 PM - 30 Mar 2013
-
@po won't IFTTT achieve what he wants?09:41 PM - 30 Mar 2013
-
@po If @aaronpk wants to "syndicate" his notes without writing a single line of code then he needs to utilize a service like @IFTTT, @Buffer or #Twitterfeed. App.net is a platform built for proactive people. // @wickedgood03:54 AM - 31 Mar 2013
-
@wickedgood I also question why @aaronpk is raising a fuss about this when there are plenty of options available (for free nonetheless) that can do what he wants. If he doesn't want a third party involved, he needs to code it himself then. // @po04:21 AM - 31 Mar 2013
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.
The "Create an Account" Problem
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.
-
@po Do you think "forcing" people to open account just to communicate with other is better? I don't need a hotmail account to send email to people there, yet GMail grew because they offered better features, UI, ads... etc.07:30 AM - 31 Mar 2013
Exactly. @tantek summarized it well in a couple notes on his site:
-
problem with app.net & silos right in their header: Want to join the conversation? (CREATE AN ACCOUNT>)8:38 on 2013-03-31 -
conversations on email do not require creating new accounts. neither should conversations on the web. #ADN #indieweb8:42 on 2013-03-31
-
I can use my existing email address to join email conversations. I want to use my existing website not a silo account.8:47 on 2013-03-31
If you're building yet another social network and not trying to solve this, you're solving the wrong problems.
Federation: I Do Not Think It Means What You Think It Means
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.
-
@po I think @aaronpk is partly right. @dalton promised things that #ADN has not delivered so far. Now though I don't think crossposting/syndication/POSSE is the right approach for ADN. I would prefer a full "federation" approach.05:06 AM - 31 Mar 2013
-
@po a federation approach mean that @aaronpk would not even need to have an account on #ADN, but yet I could just follow him from here.05:10 AM - 31 Mar 2013
Exactly.
-
@julien tent.io is federated (or de-centralized). App.net is non-federated (or centralize) like Twitter, etcetera.07:43 AM - 31 Mar 2013
-
@darnell Tent.io is federated? With whom? Being alone can't make you federated, and running on multiple server is not federation either :)07:44 AM - 31 Mar 2013
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.
-
@darnell No, federation is not software layer, it's protocol layer. Again, email is what we should aim for: Hotmail, Gmail and pop.myserver.tld don't run the same software, yet they talk.08:45 AM - 31 Mar 2013
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.
-
@julien True, although I think Tent.io aims to be just like email. Or maybe akin to blogs back in the day when they would ping each other (or track back links). Back in the olden days before the rise of the Spampire.09:19 AM - 31 Mar 2013
-
@darnell I don't know what they aim to be, I only know what they are now: not federated.09:22 AM - 31 Mar 2013
Thanks
Thanks to @po and @julien for backing me up on the App.net thread, and to @tantek for continuous insights and quotable sentences.
Summary
- App.net should support open standards that are already in use across the web if they are trying to be something more than yet another social network silo.
- I should not have to create an account to join a conversation on the web. (This goes for Branch too!)
- A federated system is different from a distributed system. A federated system can be built with different code bases in different languages.
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.
-
-
An Open Challenge to App.net
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.
Background
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:
- Activitystrea.ms Atom & JSON feeds
- PubSubHubbub (PuSH) support (as a publisher, initially)
- Exposing user identities with Webfinger
- Support open-source clients
- Support users in building inbound and outbound syndication to and from App.net
The beginning of the disappointment
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.
App.net should be a distribution platform, not a microblogging service
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!
Where distribution platforms can add value
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.
Overcoming the network effect
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.
Speed
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.
Analytics
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.
Supporting the Indie Web
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.
The Challenge to App.net
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.
