Phil Windley's Technometria

September 2, 2010

Twitter and the OAuthalypse: A RESTful Misfire

Yesterday was the OAuthalypse—the day when Twitter stopped accepting HTTP Basic authorizations on theis API. I had a few apps break—like almost everything I’ve done with Twitter. To get them back working I’ll have to spend some time on each moving them over to OAuth. For some that won’t be hard—they’re already using a library that supports OAuth. For others it will be more work. All of them are single user apps (like the UtahPolitics retweeter and so will use the OAuth single token pattern.

The reason for moving to OAuth is so that apps won’t need to ask users for their Twitter password or store it anymore. Twitter had a bad experience with this and that led to the decision to go nuclear on usernames and passwords on their API. This is a clear win for delegated authorization protocols like OAuth and the more capable ones that are surely to follow. What’s more it trains users to use a delegated authorization scheme. I love it.

But what’s curious about the move is that in everycase (except the retweeter) my apps are not updating information. These are read-only apps that simply read a friend timeline for a partcular user. I can’t figure out why any authorization is needed at all. Since who I follow is public information, it would be simple enough to reconstruct my friend timeline from available information. My theory is that Twitter uses authentication on read-only data as a substitute for a poorly designed API. That is, they use the authentication as a substitute for merely allowing me to specify whose timeline I want to see.

This is classic REST stuff and it seems that Twitter got it wrong. Thousands of apps are failing today because Twitter requires them to authorize when they don’t really need to. Am I wrong?

August 30, 2010

Come to Kynetx Developer Day

In the past Kynetx has held two Kynetx Impact conferences, one last fall and one last spring. Kynetx Impact exceeded my expectations both times with lots of people and energy. But holding a conference of that size is, frankly, a lot of work for a small team. Consequently, we’ve decided to move to an annual schedule with Kynetx Impact, holding the conference once a year in the spring. At the same time, we didn’t want to lose the ability to contact and work with developers, so we’ve created Kynetx Developer Days. The first Kynetx Developer Day will be held in our Utah office on September 18, 2010. (Register here…it’s free!)

At Kynetx Dev Day, you’ll find tracks for beginning KRL programmers as well as more advanced topics for experienced KRL developers. The full agenda is available online. We’ll be announcing and teaching people how to use some cool new features, including how to use Kynetx with email and telephony services like Twilleo via webhooks. But there’s more…

Last Friday we gave a demonstration of the power of Kynetx to orchestrate multiple services (Web, email, telephony, and so on) in pursuit of the end-user’s purpose. In this case we showed how an email from a person’s radiologist suggesting they need neck surgery based on their MRI results could kick-off a whole series of interactions and tasks. Our demo showed how a dozen individual, small, simple cooperating KRL applications could automate the interactions to significantly reduce the user’s cognitive load.

Not only will we be showing the latest version of that demo at the Sept 18th Dev Day, but we’ll be teaching about the techniques necessary to build those kind of compelling experiences. You don’t want to miss it.

And for those who can’t be in Utah on Sept 18th, one of the reasons for moving to the simpler format for our fall event was to be able to spread them around more. We plan on conducting similar Kynetx Dev Days in other locations in the coming months. Stay tuned for more information…

In the meantime, register for the Sept 18th event if you’d like to come. It’s free. We’d love to have you.

Come to Internet Identity Workshop East Next Week

The East Coast edition of the Internet Identity Workshop (IIW) will happen next week on Thursday and Friday (Sept 9-10) at the Josaphine Butler Parks Center in Washington DC. The theme for this edition of IIW is Open Identity for Open Government. You can register online. Late registration fees kick in after Friday, so register now.

August 24, 2010

CTO Breakfast this Thursday: The Once and Future Web

The CTO Breakfast will happen this Thursday at 8am in the cafeteria at Novell’s Provo Campus. As usual, we’ll talk tech; so bring interesting topics you’d like to discuss.

Anyone interested in how information technology is used to build products or run companies. Despite it’s name, you don’t have to be a CTO to attend—just interested in technology, where it’s headed, and the problems of starting and building a high-tech business in Utah.

There’s a calendar of upcoming CTO Breakfast events if you’d like to subscribe.

At this CTO Breakfast, Sam will have a special demo of some cool ideas we’ve been working on at Kynetx that foreshadows the future Web and the role personal data can play. This will blow your mind.

August 16, 2010

The Kynetx Rule Language: The First Internet Application Platform

A while ago, someone asked, in a comment, “What’s KRL?” I realized that while I had lots of snippets that explained KRL and what it could do, there’s was no good place to point people who ask that question. Consequently, I put together a white paper that explains, in some technical detail, what KRL is, how it operates, and why we think it’s so damn cool. The paper is The Kynetx Rule Language - The First Internet Application Platform (PDF). If that title doesn’t pique your interest, maybe a few paragraphs from the intro can:

Imagine walking into Borders and having your smartphone alert you to the fact that the book you put on your Amazon wish list this morning is available right now and on sale. As another example, think about an application that gathers relevant articles from your RSS and Twitter feeds based on searches you’ve performed or that are related to an email you received from a friend today.

These examples show the power that can be achieved when applications can work across multiple domains and multiple protocols at the same time. We think of this as “programming the Internet” and the results are much more impressive than those achieved by building a mere Web site. There’s no reason that clients in different domains, like your smartphone and Web browser, shouldn’t be cooperating under your guidance to help you get things done. But to make that happen, we need new architectures and programming paradigms.

One way of viewing the Internet is as a big reactive system. When you browse, tweet, email, and so on the Internet reacts to what you’re doing, or so it seems. Thus, programming the Internet requires reacting to user activities. Existing Web programs do this in a fairly ad hoc manner because most Web frameworks provide little support for managing program data and control flow across individual user interactions.

This document describes a new programming language, the Kynetx Rule Language or KRL, and the system that runs it, the Kynetx Network Service or KNS. KRL is designed for programming the Internet and makes it easy for developers to create applications, or apps, that behave like the scenarios imagined above. KRL is a programming language for building reactive systems that respond to complex scenarios across multiple Internet protocols, domains, clients, and devices.

When we invented KRL our goal was to build notational support for the hard things that Web programmers face everyday—especially on the client-side. Our mantra is “let the machine take care of the details.” Linguistic expression and abstraction give programmers the tools to do amazing things without making heroic efforts.

After going over the benefits of using KRL, the paper contains a description of the primary components of what entails a new programming model for applications that work across the Internet in behalf of the user—as opposed to the typical Web program that works on a single site on behalf of the site owner. The model and services I describe form a platform for creating Internet applications. In the paper I explore in some detail the primary concepts in this new model: events and rules. I also briefly describe the architecture of the system of services that support this model. The document ends with three examples showing applications built to take advantage of this model.

The paper lays out a fairly audacious vision by describing a system for creating applications that are completely unlike your typical Web application. You can be part of that by trying out KRL today using a free account.

August 11, 2010

IIW XI, IIW East, and IIW Europe

In addition to our traditional semi-annual meeting at the Computer History Museum on November 9-11, IIW is also holding events in Washington DC and London this fall. Unlike other identity conferences, IIW’s focus is on the use of identity management approaches based on open standards that are privacy protecting.

The IIW East (more info here) will be September 9-10 at the Josephine Butler Parks Center. I suspect that because of the location and discussion that’s going on around identity in government circles that this event will have a distnctly different flavor and set of sessions than IIW has traditionally had. You can register for IIW East here.

The IIW Europe event (more info here) will be held October 11, 2010 at MacMillam Hall at the University of London. You can register for IIW Europe here. Early bird pricing is in effect until Aug 31.

And, of course, we’ll have the Fall IIW (more info here) at the Computer History Museum in Mountain View, CA on November 9-11. This is the primary event for people interested in such user-centric identity technologies as OpenID, OAuth, Webfinger, and so on. I’m sure there will be considerable discussion of Personal Data Stores at this event. Last spring IIW has almost 250 people in attendence. You don’t want to miss this. You can register for IIW XI here. Super early bird pricing is in effect until Aug 31.

August 9, 2010

Starting a High Tech Business: The Wind at Your Back

I’m starting a new business called Kynetx. As I go through some of the things I do, I’m planning to blog them. The whole series will be here. This is the twenty-fifth installment. You may find my efforts instructive. Or you may know a better way—-if so, please let me know!

Saturday I rode the ULCER century bike ride for the fourth time. This is a great century that goes around Utah Lake. I look forward to it every year.

Every year the ride is a little different. This year, the wind was blowing from the South-South West and the weather was perfect with some high clouds that cooled things off a little. Before 11am, there wasn’t much wind at all. There was a rest stop at mile 45 at a place called Lincoln Beach on the south shore of Utah Lake. The next rest stop after Lincoln Beach was at Elberta, almost 20 miles away. After Lincoln Beach the route turns south and the wind was picking up. That stretch is on the west side of West Mountain and has some small hills (e.g. 1-2 miles of 4% grade). So, you’re 50-60 miles into a 100 mile ride, it’s getting hilly, and the wind’s blowing in your face.

I wasn’t particularly tired and I didn’t have any trouble with the hills since I normally climb a lot. But during that stretch I had a cramp in my leg and my right shoulder hurt (I have a hunching habit on my bike that I’m trying to break). I did everything I could to get comfortable but nothing worked. After we turned west we were on Highway 6 with traffic and the wind was still blowing. I wasn’t having fun. In fact all I could think about was how much my shoulder hurt and how much further to the next rest stop.

At Elberta there was a rest stop and the route turns north and we had a tailwind. In between mile 70 and 80, I had the best 10 mile stretch of my life averaging over 30mph. I decided to make hay while the wind was blowing and got into my biggest gear and pushed with everything I had. Even after that I felt like I was flying. I felt great. I realized my leg was no longer cramped and my shoulder didn’t hurt anymore. Amazing.

What’s funny about that is that my shoulder probably did still hurt. In fact it hurts this morning. I just wasn’t noticing because I was having too much fun. Things (specifically the wind) were going my way. I finished with my personal best time of 5 hours 51 minutes over 107.5 miles.

Startups are a lot like my ride. One of the stories Steve likes to tell is about one of the down times at Kynetx. We had been writing code for 9 months and had one pilot customer. We had a meeting with them and they said they were turning us off. In essence, they were going to plug the fat pigeon. We came back to the office and, as Steve tells it, he was very dejected. I went back to my office and started writing more code. He looked at me and said “what the hell are you doing?” I said “writing code.” He thought I was nuts.

In truth, I wasn’t any less dejected than Steve. I was just lucky in that I had something concrete to do and so I went and did it. I just kept pushing toward my milestone, whatever it was, even though we’d just gotten kicked in the teeth. Steve had the harder job, as far as I’m concerned. He had to pick up the phone and call the next potential customer and pitch a product he was having trouble believing in because of the experience we’d just had.

I have to say I never stopped believing in the product, maybe because it was my baby. But there are some times when you have to keep going despite setbacks. There are times when the wind is blowing against you and you’re just slogging along. Everything hurts and you’re grumpy. Other times, the universe is conspiring to make you successful and it feels like you’re flying. The trick, of course, is to put your head down when the wind’s blowing against you and keep your next milestone in sight. Just keep moving ahead. Find ways to keep moving ahead. And then, when things are going your way, push as hard as you can.

August 4, 2010

Beyond APIs: Declarative References to Data

APIs are coming into their own. Gluecon was abuzz with them. I’ve seen Sam Ramji’s talk on Darwin’s Finchs and APIs referenced everywhere—and rightly so.

One of the problems with RESTful APIs, however, is that every time someone comes up with an API, I have to read the docs and then code, by hand, an interface between that API and my language. For popular APIs libraries are already written to do that. For smaller APIs, I’m on my own.

At the Cloud Camp that preceded Gluecon, one of the discussions was about a way to fix that: an API description language (sometimes called an IDL). Using an IDL, interfaces to an API for any given language can be generated rather than written by hand. WSDL, of course, is such a language for SOAP but it’s not suitable for REST. There have been attempts to create description languages for RESTful APIs (like WRDL) but they’ve failed to take off. Some would argue that REST doesn’t need a description language, that it’s too heavyweight, but I, for one, am tired of writing libraries to every API that I want to use—especially as the number of authorization protocols like OAuth and UMA propagate.

There’s an alternative to IDLs, however, that’s even better: declarative references. XRI + XDI are a system for creating declarative references to data. XRI provides a language for describing the data you want without specifically saying how to get it. When an XRI is dereferenced, it can point to an XDI data store that contains the data. How’s this different than performing an HTTP GET on a URI?

If the RESTful API is very well designed, it’s largely the same with a few exceptions (which I outline below). Putting together an XRI reference for data is not necessarily easier than putting together the URI for someone’s random data element. But most RESTful APIs aren’t well designed; they force programmers to write lots of code to get around API inconsistencies. XRI/XDI has thought these issues through.
Non-standard implementations of authorization standards like OAuth (are you listening Google) in RESTful APIs just add insult to injury. XDI has a single, comprehensive, portable authorization scheme called link contracts that normalize access to data.
XRIs are location independent because they resolve to an XRDS document that is used to get to the right location. That means I can change the location of my data—even if I’m storing it on someone else’s servers using their domain name—and things just keep right on ticking.
Moreover, XDI creates an RDF-like scheme called the XDI graph which means that the data stored in an XDI store is portable from one XDI store to another.
XDI includes the ability to interrogate and inspect the data dictionary associated with a store, providing a semantic namespace that is referencable through XRIs. This means that creating the reference is most standardized than just putting together a URL according to someone’s whim.

All of this convinces me that as we move to a world where personal data is more and more important, we’re going to need something more than what HTTP+URIs provide. That doesn’t mean they’ll go away. They’ll continue to be a critical building block. But we’ll move up the stack to something that plugs some of the holes in HTTP. I think XRI+XDI is a good candidate.

Phil Windley's Technometria

Organizations Get the IT They Deserve

Technometria

About Phil

Essays

Software

Topic Guides

Categories

Archives

Utah Tech Organizations

Friends

Copyright

I'm CTO of Kynetx

Free Newsletter!

Search

What I'm Doing

Find Me Elsewhere

Digital Identity

Upcoming Events

Recent Entries