[cap-talk] Webkeys vs. the web

Chip Morningstar chip at fudco.com
Sun Mar 22 18:15:37 EDT 2009

(Note: this was originally sent to the friam list, but Kevin Reid suggested
that it would be appropriate for cap-talk as well, so I'm resending to the
broader audience.)

I was thinking about webkey API design based on some conversations we had at
last Friday's meeting at HP, and so I ran off and designed what I thought was a
really spiffy and self-consistent interface for the thing I'm building...then
as I was dozing off last night I realized there was a horrible flaw in what I
was doing, and I don't quite know how to fix it.

If all authority is carried via webkeys, then to get at anything a user needs
to know the thing's URL.  Looking at this from the perspective of the web
browser, there are three places it can hold onto webkeys: (1) in bookmarks, (2)
in the browse history, or (3) in an open page, either in links that are
actually on the page or in the memory state of Javascript objects loaded from
that page.  These are the roots of the browser's authority.  It can also get to
anything reachable from these by fetching whatever they link to and following
the chain of references.  So far, so good.

Now let's consider a browser-based UI.  I can't reliably count on using (1) or
(2) to hold the user's root authorities (in essence, their powerbox) because
the user might not be coming to the site using the same browser as last time,
and even if they did they might not have thought to bookmark the right things,
either because they're stupid or because they just didn't know that that was
what they were supposed to have done.  And we can't be having customer support
reps lecturing users "well, you *should* have..."

So to deal with this, I had the notion of a having the server hold the
powerbox, and have a password-authenticated "login" operation that hands it
back.  So the user logs in, gets their bundle of root authorities, and off to
the races they go.  This was the notion we discussed Friday.  And it was so
clever and elegant, I went off and designed a whole API...  But what happens
when they navigate to another page?  At that point, the memory state of the
page they were on is lost and they get a whole new memory state loaded from the
new page.  But if the new page was gotten by following a link to something that
doesn't hold their authorities, now they have no way to get back (other than
the history, but we're stipulating here that the human factors folks are
telling us that that's way too hard for average people to use in this way,
especially if the root of the user's authority is a long, long way ack in the
history, which it could easily be).

The normal way sites deal with this sort of thing, when they aren't webkey
based, is to have a link on every page labelled something like "Home", and
that's likely the kind of thing our UI people will ask for too.  But in order
to do *that*, the page would need to have the user's home webkey, which we've
already said it doesn't have.  What's a capability-oriented guy supposed to do?

I can think of two approches, but neither of them is completely satisfactory.

Approach #1 is to never leave one's home page, but have all navigation take
place via scripted fetches of particular bundles of data.  That preserves the
capability model but it breaks the web nature -- I can't, in this scenario,
bookmark things I go to (remember, I didn't say we couldn't use bookmarks, just
that we can't rely on the user making particular bookmarks) or snapshot the
URLs of pages to have links to pass to others.

Approach #2 is to have every page in this system include a "powerbox module"
and use a session cookie so that when I load the powerbox module, the backend
populates it with my stuff but when you load it it populates it with your
stuff.  The session cookie in this scenario ends up being, in essence, a webkey
that is held in a cookie (and handed around like a cookie), which makes me very
queasy.  The key thing the cookie is providing is a bit of short-term memory
state that survives page load.

I'm thinking we have no choice but to go with option #2, but it makes me really
uncomfortable, given all the various issues cookies have.

What think y'all?


More information about the cap-talk mailing list