If you use an Android device, you’re familiar with installing apps. Each app has a set of permissions that it requests. For instance, the screen capture at left shows the permissions required by the Google Maps app. As you can see the list is extensive and some of them might give you pause, like “Services that cost you money” or “Your personal information”.

Before you install an app, all of its requested permissions are listed, along with the short descriptions you see here and you can decide whether or not you want to install the app, thereby granting it those permissions. That’s good because unlike iOS, you can see specifically what it wants access to and at least have some knowledge about what it might do and decide whether or not you want to install it. The app cannot access permission-protected functions in the API without this express approval at installation time.

This is good as far as it goes, but it could be a lot better. First, it’s all or nothing. You either accept all the permissions or you don’t install the app. Second, the terse and generic explanations are frequently not sufficient to determine if you want to grant the permission or not.

Developers could provide application-specific explanations of permission use

It would be great if there were explanations of why the permission is needed in terms of the app’s functions. For instance, an app I’m writing requests the “Phone calls” permission because it needs to know the hardware ID of the phone to do some database functions. But it’s not going to make any phone calls. That would be nice for the user to know before they installed the app.

Google Maps would explain why and when it needs to “directly call phone numbers.” After poking around in Maps a bit, I discovered that the “Places” activity locates things like restaurants and gives you a “Call” button right on the listing. This is the kind of when, why, how information you need that is specific to the application in order to decide if you want to grant the permission.

Android could allow permissions to be individually granted

When installing an app, it would be much better if, coupled with the application-relevant explanation of the permission’s use, you could individually grant or withhold a permission. This would require the app developer to identify which permissions were minimally necessary and which were optional, if any. Further, it would require the app to be gracefully tolerant of missing permissions.

For instance, with Google Maps you might choose to deny access to your contact data. When choosing to deny this permission, you should have full knowledge of what functionality you would be missing by doing so. This would make application development more difficult, but would yield significant benefits to the user.

SLAP – Simple Lightweight Announcement Protocol

Today, to only two close developer friends, I’m releasing a first prototype of a new project called SLAP (for Simple Lightweight Announcement Protocol). We’re going to begin multi-server testing of it as soon as possible. If you’re not a developer, you may not immediately grasp exactly what SLAP is all about, but I’m hoping it will help all of us establish our own Social Networks of One, as Jeff Pulver calls it, and not be slaves to the whims of services like Twitter or Facebook, that now determine when and how we can communicate.

SLAP is a project I’ve been developing on and off for a couple of years. SLAP provides a very minimal and fast way to alert content or status subscribers that new or updated information is available, without them having to poll constantly for it.

By eliminating polling we benefit both the subscriber and the publisher. The subscriber gets informed of new content immediately, with no polling period latency and no resources of computing or bandwidth are expended between announcements. Likewise, the publisher does not need to provide sufficient bandwidth and computing resources to respond to polling requests, the vast majority of which result in no new information.

Unlike HTTP and XMPP, SLAP is connectionless, employing UDP (User Datagram Protocol) as its underlying transport mechanism. This is why no significant server or network resources are used between announcements. Although XMPP provides the same immediacy of delivery and elimination of polling, it requires long-lived connections to be maintained even if the frequency of announcements is very low, e.g., once a week. HTTP does not require long-lived connections, but instead requires establishing and terminating much TCP connection overhead in a short amount of time to deliver a very small amount of data.

The SLAP model

SLAP defines announcements in terms of feeds and posts to those feeds. Each feed is identified with a URI and each post with a perma-link URI. Further, each announcement is uniquely identified independently of the feed and post it is related to. This allows many announcements of the same feed and post. For example a post may be initially created, then edited many times, or commented on many times. Each edit or comment can result in a new announcement of a change to the post.

Publishers and Subscribers

There are two basic roles in the use-case model for SLAP; the Publisher and the Subscriber. The Publisher creates new feed content and emits a SLAP event every time that feed content changes that goes to every Subscriber. The Subscribers receive the announcements and respond with an acknowledgement. The announcements and acknowledgements are all delivered using UDP, which means no connection overhead for either the Publisher or the Subscriber. The protocol is tolerant of off-line Subscribers and noisy, unreliable networks. Publishers retry unacknowledged announcements at a fixed period and for a limited amount of time. One of the strengths of SLAP is that a missed announcement is not the end of the world. The Subscriber can periodically check the Publisher for all feed content and discover a missed post that way.

Strictly speaking, SLAP is not intended to deliver content, but only to announce that new or modified content is available on a feed and to provide the URIs for the feed and the post that allow the subscriber to fetch the content. SLAP does provide for a content summary that may in many cases be all the content there is. Microblogging or automated system status updates would tend to use this feature. In these cases, an attribute of the message could show that the summary is the entire post content. This is an optimization that enables a subscriber to avoid making a content fetch when the summary is all that there is.

Having the publisher be responsible and obligated for content storage allows a subscriber that has been offline for an amount of time to fetch any posts it missed simply by reading the feed as it normally would.

Separation of subscribing and fetching from announcing

The core SLAP messaging services deliver and acknowledge announcements, but play almost no part in establishing or terminating subscriptions. Nor do they specify how fetching of post content happens. Subscriptions can be established in any number of ways, as long as the required information for announcement delivery and authentication is provided. The subscription protocol is an open development issue, and your comments and suggestions are welcome. Personally, I see a simple extension to RSS as being the most obvious route. This would allow common blogging or microblogging applications like WordPress or Twitter to add announcement support with a relatively small modification to their current RSS support. RSS feeds could allow SLAP-enabled subscribers to discover the SLAP parameters and automatically connect to those feeds providing SLAP announcements.

Authentication

Any protocol that “pushes” information to a destination opens a possible hole for spammers. One of the challenges to making SLAP work is enabling subscribers to authenticate incoming announcement messages as to their source and to do it relatively quickly. This first version of SLAP uses a simple MD-5 hash of the message contents with a subscriber generated key that is exchanged at subscription time, ideally using secure communication.

Try it, you’ll like it.

SLAP can be used just for publishing, just for subscribing, or both. You’ll need to run it on a machine that you can open the firewall on, and receive UDP messages on ports 14947 for the subscriber and 14948 for the publisher. Or you can use any SLAP server that you’re given access to.

I’m writing a WordPress plugin to add Open Microblogging Support to a blog. In order to do this, I’d like the plugin to add a special OpenMicroblogging Page to the blog. This special Page is supported by a custom Page Template. Page Templates are normally added to the theme directory. And therein lies my lack of understanding. How do I get a plug-in to add a page template? Copy the php file in the installer code? Seems a little dodgy, but maybe?….

It depends on how the UI for subscribing works. If, as with a feed reader, the subscriber enters the URL of the person they wish to follow, authorization is unnecessary. The user has made their intention known to their own account, and can simply request the posting server to send updates.

However, if the the subscriber subscribes by visting the site of the poster, and the poster allows unrestricted access, then there must be a mechanism for the subscriber to tell his own site that he wishes to subscribe to the poster’s updates. This is where OAuth comes in, and it is indeed a well-matched use-case for OAuth’s functionality.

Apologies to Evan at Identi.ca.

Square peg, round hole

The OpenMicroBlogging Specification (OMB) contains a section on the use of OAuth to authorize a remote service to post to a user’s local service. After spending some time studying the OAuth and OMB specs, it seems to me that this is not the use-case that OAuth was designed to solve. A square peg in a round hole, you might say.

This is not to say that authorization is not needed for allowing post-sharing, only that OAuth was designed to address a different situation. The simplest way I can characterize the difference is that OAuth applies to a “one human, two services” problem and microblogging post-sharing is a “two humans, two services” problem.

OAuth’s intended use-case

So, what problem does OAuth fit? OAuth is intended to solve the problem of a person who has content or resources on Service A and wants to allow his/her account on Service B to access those A resources – without giving Service B his/her login credentials for Service A. Note well that it is the same person having accounts on both A and B. This is the “one-human, two services” aspect.

So, for example, let’s say you have an account on Twitter and want to use one of the many alternate Twitter clients out there, e.g., Twalala. You have an account with Twalala and would like to be able to access your account on Twitter without having to fork over your Twitter password. Using OAuth, you would be able to, in essense, tell Twitter to allow your account on Twalala.com to perform various read or post functions with your Twitter data. By the way, Twitter has been promising for months to implement OAuth for exactly this purpose. Again, note that there is only one person with accounts on both systems.

OMB post-sharing use-case

Now, let’s look at the case of two people on two different OMB-compliant sites who want to share their posts, either unilaterally or bilaterally. Let’s say I have an account “joecascio” on site subscriber.com, and my friend has an account “johnsmith” on poster.com and I would like to follow John’s updates. Note that it should not be necessary for either me to have an account on poster.com nor John to have an account on subscriber.com in order for me to “see” his updates. Indeed, this is the whole point of federated microblogging; that we can share posts without having to have accounts on many different services. So simply from this fact alone, OMB post-sharing is clearly not the “one person, two accounts” use-case. If post-sharing worked by requiring John to have an account on subscriber.com (the second of the “two services”) and then authorizing subscriber.com to let his Poster.com account post there, then yes, that would be the OAuth use-case. But it isn’t!!

So, what is an appropriate protocol or process for enabling and controlling post-sharing? I don’t have the complete answer, and I’m hoping that this post will cause some of the many smart people out there to suggest some. But I can state at least some of the problem characteristics, requirements or constraints.

Post-sharing is subscribing, not cross-posting

When I register my interest in someone else’s microblog posts, when I “follow” them, it means I want to subscribe to their post stream, just like I would subscribe to their traditional blog. If it were a traditional blog, I would do this by polling their RSS feed which is a simple GET by the subscriber. It does not involve the poster initiating a transaction to “send” me anything. But since microblogging implies a much lower latency, which would be inefficient to perform by polling, OMB introduces an optimization. The service on which the post was originally made proactively sends the new post to all subscribers. Great! We can now be notified that a new update is available within a few second without having to poll every few seconds.

BUT this is point of my observation. I would argue that this proactive send is merely an artifice of the optimization and does not change the fundamental relationship of poster and subscriber. From that basic user point of view, the fact that the poster initiates the data transfer is immaterial. The subscriber is still simply seeing something they expressed interest in reading.

This is where I believe OMB goes astray. It lets an optimization detail obscure the higher level concept. Following someone’s posts means I want to see those posts in my view, but it does not require that either party perceive it as cross-posting to my site. I could equally accomplish the same viewing of that post by fetching it on demand, albeit not as efficiently.

Subscribing is implicit authorization

Keeping firmly in mind the fundamental concept of poster and subscriber, what if any authorization needs to happen when I request to follow ‘johnsmith’? I would say that the very fact I am requesting to see John’s posts is an implicit authorization that he can send them to me. Whether he wants to let me see them is a different story and the subject of another post. Let’s assume he will let me see his posts and we want to use the OMB optimization of his service (poster.com) proactively sending them to me.

When I request to subscribe, I need to send a URL of where to send the notifications and a means to verify that the sender is who I granted the privilege to.  This could be accomplished to different degrees of security. A fairly loose method would be for the subscriber to send a callback URL in the request that encodes a UID for the poster’s account. If the request transaction is secure, we can be reasonably certain that only the the “real” poster will be sending POSTs to that URL. Of course, this does not prevent the poster from sharing the UID, but the subscriber can always simply invalidate the URL and stop receiving the notifications.

In fact, this is pretty much how the RSS cloud API works and this could be a more proper model for OMB post-sharing.

What do you think?

I would be very interested to hear what others have to say about this post. One thing it does not cover is the complementary function of a subscriber GETting, rather than being sent an update. It also does not cover the perfectly matched use of OAuth to allow a user to grant access to other of his/her services just as described in the Twitter/Twalala example under “OAuth’s intended use-case”.

Listening to his list of specific dos and don’ts in more detail just now made me realize that there’s one overarching philosophical tenet that guides all the details and that is the following.

Run your business and build your product for yourself, not for investors or shareholders or analysts or “big” customers. Run your business to sustain your own life-style and your own integrity. Build things you believe in, not what some purchasing manager put in an RFP.

Investors want you to grow without bounds. That makes you put in crap you don’t want. Salesmen want you to put in a useless feature so they can get a big sale. Big customers want you to put in things only they want. While some of these forces may have some benefits, in the long run, they only push you to do things that dilute or muddy up the product with noise. Truly great products are simple, coherent, easy to understand and perform quickly and reliably.

For me, this means satisfying the artist, artisan and craftsman in myself, not somebody who makes money off of what I do. That is where great works come from; not from a balance sheet, an enhancements list, a specification or god knows, Microsoft Project.

What really impressed me about Jason’s story was that he became a success doing things the way I’ve always thought they should be done. And more to the point, exactly the opposite of the way traditional management tells you it should and must be done. Some examples from his talk.

1. Don’t get venture money. Bootstrap your idea in your spare time keeping your day job. You don’t want anyone telling you what to do who doesn’t share your passion for what you’re doing.
2. Don’t have a board of directors. What do they know about what you’re trying to do?
3. Don’t write specs, write code. You can’t tell whether something is good or bad from a spec, only from working code. Do it quick. If it’s no good, throw it away and move on. People in organizations are dreadfully afraid of making a mistake. Don’t worry about it, just do it.
4. Don’t keep an enhancement or bug list. Trust your gut to do what’s most important. When you keep hearing the same thing from people you know and trust, go ahead and do something about it.
5. Try to do everything in two week increments. That is, don’t let people get bored doing the project. They do their best work when they’re excited about the outcome.
6. Don’t plan too much. My question to Jason was about whether or not his small 12 person operation would scale up. He said, “I don’t know and I don’t care. We’ll worry about that when the time comes.”
7. Don’t hire any marketing people. Your customers are your best marketing dept.
8. Trust your employees. 37 signals gives each of their employees an unlimited charge card, to spend on whatever they want, however much they want. The company bought one employee flying lessons. Not because it would be a usable skill, but because it would make him a more happy and well-rounded employee. In their experience employees do not abuse the charge privilege, but use it sparingly, knowing that it comes of the bottom line.
9. Don’t spend money on an office. Keep employees in their own homes. That’s where they’re most productive. In an office it’s too easy to be interrupted and too easy to call a meeting. Meetings are productivity killers.
10. Charge money for your product from Day One. This is a complement to the Don’t take money from VCs rule. Nothing succeeds like revenue. If you have something worth paying for, people will pay for it. If it can’t sustain itself, find something else to do.

I’m sure there were more, but those are the ones that stuck with me. As a survivor of 35+ years in the software development business, I can personally attest to the practicality of these guidelines. I have seen the opposite fail miserably for my whole career, but every once in a while, I managed to become part of something that didn’t obey the rules, and those were the memorable successes.

Don’t let the management, marketing and financial suits tell you any different. Do what you know is right. If it doesn’t work, learn from the experience and don’t make the same mistake again. But please, don’t think you can ever get it right without trial and error. It’s so obvious it’s painful, but there are still legions of project and product and people managers who wouldn’t have jobs if not for torturing you with requirements statements, schedules and bug reports.

And one thing that he swears will never be added to BaseCamp, their project management tool: Gantt Charts. Hurray!!