The web is littered with posts both for and against app.net. Forgive me, but this is another one. In return, I’ll forgive you if you wanted to head straight back to the comfort of Facebook or Twitter. But, if you are just a little curious, read on because I believe you don’t need to join app.net, to share in the excitement that I feel about this new approach to networking the web.

Just another social network?

If you were to spend some time looking at the global stream on alpha (the first web based client for app.net) you could be forgiven for thinking the network was the preserve of narcissistic iOS developers. A little harsh perhaps, but there are two topics that feature quite prominently:

• app.net itself
• demands for access to iOS clients (more on this in another post)

In some ways though, I’m not entirely surprised. Developers are vying for the rights to have their app become the app.net client, and those that, for some reason or other, are unhappy with their experiences on existing networks have come to try and re-create their Twitter experiences. There are undoubtedly other reasons for joining, but these are by far and away the most common.

In fact, the dominance of the global feed by these two user groups is now so strong, that some early adopters are already being put off.

app.net is, after all, just another social network trying to find it’s niche. Or is it?

So why the excitement?

I’d understand completely if, after glancing at the global feed, you came to the conclusion that app.net was boring. Your friends aren’t there, so why pay to get something that you can just as easily get for free? Hardly an attractive proposition.

Don’t be so hasty. You are simply looking in the wrong place. The global feed is fun, but not particularly exciting. So, stop looking at the global feed and instead, head on over to GitHub where you will find the terms of service, and the API specification.

You don’t have to take my word for it, but the bulk of what is offered is indeed very similar to a number of social networks that that are far more mature in their implementation. Indeed, many of the features listed on the API specification are clearly marked as “Not Implemented”. But, one of the things that makes app.net exciting is in how it differs from existing networks.

Many of these differences have been debated in the issues sections on GitHub and I’d strongly encourage you to spend some time reading through these documents and the associated issues if you want to understand why the app.net proposal is indeed something to be excited about.

To get you started though, here are two features and one issue that get me excited about the platform.

Users

The app_data object will allow applications to store application specific data as part of the user profile. To the best of my knowledge, existing networks do no allow you to extend the user profile with your own application specific data. Some even discourage you from developing your own clients altogether.

"app_data":{   
  "appdotnet":{...},   
  "rdio":{...}   
},

Some immediate use-cases spring to mind:

• remember your current position within the stream
• remember your preferences between devices
• enhance the user object: languages spoken, contact preferences, current location, etc.

Acceptance of the fact that we aren’t all human is baked right into the API with the user type object.

"type":"human",

Currently, provisions include human, bot, corporate or feed. Combined with the necessary filters, this opens up a wealth of possibilities. Post everything into the stream and leave it up to clients to show what the users want to see. Publish first, filter second.

Post Annotations

The annotations object will allow applications to store post specific data as part of the post object. The example given on GitHub is for specifying the location associated with a post.

"annotations": {
  "wellknown:geo": {
    "type": "Point",
    "coordinates": [102.0, .5]
  }
},

The intention is for some some globally documented annotations but, in addition, to allow applications to be able to store their own annotations. We now have the basic infrastructure to allow two bots to communicate without this communication needing to be part of the displayed as part of the traditional message feed we’ve become accustomed to. Publish first (text, data or both) and leave it up to clients how to display that data.

For example, it would be possible to include alternative representations of messages. So, a message 你好 could include the Pinyin representation and a link to an audio version. These could be displayed to the user based on their fluency of the language as stored in the user object. Queue a post on the potential of app.net to revolutionise language exchange.

"annotations": {
  "language:cn": {
    "pinyin": "ni hao",
    "audio": "http://someurl.com/34543vrfqf43",
  }
},

And what do the developers have to say to this proposal?

“My thinking is that we’ll give you a pretty serious amount of leeway in terms of how much data we allow you to associate with a post—they’re not meant to be shortcuts to more information, they’re meant to encapsulate all of the metadata without further network fetches.”
- Berg: Issue #5

This ability to include additional information along with the simplistic text based messaging is where a lot of the potential in app.net lies.

Issue #33 – access control

But the app.net team haven’t thought of everything, they couldn’t be expected to. And that is why it is so encouraging to see developers proposing API extensions on GitHub.

“Posts should be able to be restricted in their visibility at the API. This means a Post is never delivered through the API to a Stream which is not allowed to see it.”
- amazingsyco: Issue #33

What follows is a lively discussion (77 contributions as at the time of writing) between developers on the potential implications of user-based and application-based access controls on the network.

When I challenged @dalton on how he planned to mediate between competing suggestions, it was refreshing to hear that the focus was on simplicity.

But what of the underlying philosophy?

We have moved from an era where only a select few were equipped to publish anything to the world to an era where anyone is able to publish their messages to anyone who will listen. Content used to be carefully selected, perfected and then broadcast to the world. We now live in a generation where everyone can publish and everyone can reply. Publishing in public is the modus operandi of the current generation.

But, in this seemingly chaotic world where we publish first and rely on the consumers to filter information from the noise, the social networks of today have stopped short of granting consumers complete freedom over what and how they digest information. The infrastructure is there, but the economics of the web have forced them into maintaining strict control over just how we consume (and share) the information that is important to us.

App.net promises to change that. They offer the promise of a single feed, into which we are able to publish anything and everything. They don’t dictate how or where I consume the information that is available in the feed, instead they provide the tools required to filter the stream and determine, based on my own context, what information I want to have available to me. It is this, that promises to be the differentiator for app.net, and it is for this reason that I decided to back Mixed Media Labs in their venture.

If you want to know more, I highly recommend reading @dalton‘s original blog post: What Twitter could have been