[sugar] Mini-Conference Proposal: Automatic transfer/update of activities on the mesh

[C. Scott Ananian]

2008/4/3 Jameson Chema Quinn <jquinn at cs.oberlin.edu>:
> 1. for "version threading", what we need for an activity is not a claim like
> "I am a version of activity ID XXXX" but "My prior version was XXX and the
> one before that was YYY". What is the granularity of XXX and YYY? I'd say, a
> hash on the activity.info would be fine - that way, version changes are
> automatically picked up, but not every change in the source code. If, later,
> activity.info picks up some elements which are too volatile (thus leading to
> unnecessarily-long geneologies), we could filter those out before hashing.
> Note that this is totally orthogonal to whether an activity version is
> signed by the original devteam, and yet allows for forks to become
> independent without fighting over who is the "real pippy
> org.laptop.XYZ1FFE3". I submit that merges are unnecessary.

I think this is overkill.  A single unique tag, randomly generated,
suffices to identify all applications which claim to be a version of
"Activity X".  Let's make it As Simple As Possible.

> 2. If we get the version threads right, then the auto-update on sharing
> becomes safer. I still don't understand who has to sign to avoid a break in
> the ownership chain - I would presume a given set of maintainer/developers,
> and I would presume that there would be some way for the group to change
> over time - but those details can be worked out.

You're still thinking that the "signing key" corresponds to a
*person*.  It doesn't.  It corresponds to an *activity*.  With the
first version of Pippy, cjb generates a new key.  The "chain is
unbroken" as long as new versions of Pippy continue to be signed with
that key, whether because cjb gives the key to a new maintainer,
entrusts it to a group, or because he's making them himself.

When cjb releases Words, it has its own unique "signing key".

Replacing an old key with a new key would be interesting, but it adds
a lot of unnecessary complexity.  Better (to me, for the moment) to
just let the chain be broken when that becomes necessary.
 --scott

-- 
 ( http://cscott.net/ )