Sunday, August 12, 2012

My thoughts on app.net


It's now t minus 40 hours until the pledge round for app.net closes and I just need to put a few thoughts out there that have been swirling around in my brain for some time now. And once it is out there I'll go ahead and pledge my 100$ for app.net.

I liked the app.net idea a lot after reading Dalton's Audacious Proposal and other posts where he compares services like twitter to infrastructure. Nobody is unhappy paying for infrastructue, he outlines, and he's right. I pay for water, power, trash, I pay road taxes and for public transport and probably many more things. For some I pay a flat-rate, but most are billed on a per-use basis.

For me there is one key piece missing from app.net: When we talk about infrastructure, we talk about a service that anyone can provide. Anyone can (with proper training) build roads or lay piping or wiring or generate power with solar panels. So applying the infrastructure analogy on app.net this means: Anyone can (with proper training) build "app.net" and clients for it (a solar panel being the client, connected to the grid). I put app.net in quotes here because it encompasses more than what has been (publicly) planned for it so far. Let me elaborate:

At the moment, app.net looks to me like just the next twitter/facebook/whatever: "A means of communication between its users" (with the USP being: no ads but you pay for the service). So we go from one platform that's controlled by a single company to the next one. I don't see the benefit in this. App.net can and should be much more. I didn't follow the developments and the blogosphere on app.net too closely but Brennan Novak has already talked about this point. TL;DR of his post being app.net should federate with as many other platforms as possible. I think this is an important point but I think it should go even further.

Getting back to the infrastructure analogy, true (Layer 7) Internet Infrastructure must fulfill a few key points.
  1. Open Protocol Specifications
  2. Anyone can build and run Clients
  3. Anyone can build and run Servers
  4. Decisions on changes to the protocols are seldom and made in a democratic fashion
Well established technologies like E-Mail (smtp, pop3, imap4) or DNS/IRC/XMPP and many more fulfill these criterias. All of these technologies can be run by anyone on a server somewhere, anyone can be a provider and become part of the global infrastructure itself. For a long time in my youth I had my very on firewall, storage, web and email servers running in the basement, I myself was a provider (to myself and my family only but that's the beauty of these services: you can go small too). A friend of mine runs an NTP server in the global ntp pool, the load on this box is negligible (and btw, ntp is a service that is free to use and ad-free as well since it lives from volunteers like him).

So to lift app.net net to the same level, I'd like to see the following things happen:
  1. Open Protocol Specifications
    1. For clients this is already the case on github.com:appdotnet/api-spec
    2. For servers this has yet to be done
      (I'm thinking subscribing/notifying status updates across providers. I'd leave user-management internal to each provider much like mail/xmpp etc, this seems like a proven approach. Add a way for users to switch providers which would include moving all his assets similar to moving a domain from one registrar to another...)
    3. Consider allowing for extension points in the protocols, so extra features don't need new versions of the base protocols but only an extension, similar to http content negotiation or openssl encryption algorithm selection.
  2. Once the Protocols are implemented, reviewed and have been stable for some time, freeze them and put each of them in an RFC to make them an official standard.
  3. Create a steering committee that will decide on future protocol changes (I'm thinking along the lines of the Java jcp.org process which is community and industry driven). It should be independent of corporate control (maybe facebook will eventually succeed in acquiring app.net? ;) ) and it should be a democratic process. Not to sound idealistic but we the netizens, we are the ones who oppose restrictions and corporate control and idiotic legislation on the internet - the least we can do is to lead by example when it's about our own self-built communications infrastructure, right?
  4. Optionally make the app.net code open source. I don't care too much about Dalton's code being open source because thanks to the points above anyone can create his own implementation of the protocols and connect to the other providers.
Following these steps we should end up with a distributed and open layer7 communications infrastructure that has the potential to replace some of the existing services and to interconnect with all the others. That's what I'd like app.net to become.


Respectfully,
Patrick


PS: About pricing: I don't care about that. Each provider should decide for himself if he wants to inject the occasional ad into the status stream or if he wants to charge users for his service. Let the users and the market decide. It has worked out like that for E-Mail, for ISPs etc. And it seems we like to pay for our ISPs but we use a free and ad-supported E-Mail Service (I'm guessing most users use one of these free and ad-supported ones?). So maybe for app.net the users need or want something else like free for users but pay for corporate accounts for example? I'd expect pay and ad-supported offers to coexist as it is with many other service types.