OK, the mini-conference happened - thanks for trying to let off-siters like
me participate. Here's the Gobby doc which resulted, below are my
post-meeting comments:
Activity sharing:
* Should we show people what the size/download time for a package is before
d/l?
* We might download something more readily if it's coming from a friend.
* Michael: Trusting a friend isn't the same as trusting code coming from
that friend.
Ben: The only security question is whether it's safe to *replace* an
activity
with a new one. Bitfrost guarantees that running untrusted code is
safe.
Scott: You can always modify code, but you have to give it a new name.
Michael: Making something default is a separate UI action from downloading
it.
Should distinguish between activities by their hashes; version numbers
shouldn't
be used for equality.
homunq: unsigned versions should obviously not get the same preference
directory.
proposals for naming:
* centralized registry, e.g. microsoft.com
* mstone: first person to get there owns the space (and others get
another version of %s)
* each activity has a random guid for same activity and ...
http://wiki.laptop.org/go/Talk:Activity_bundles#A_proposal_for_Activity_Signing
How to put related activities together?
* group by tag
* add prefix in name, sort by name
* group by magic sortkey tag
decision: A and/or B as author decides.
SJ: Attach names to the inherent identity of an activity
.. okay, SJ can type what he meant ;-)
I make a new activity, *E*. It gets a ¨unique¨ id, E.id and a ¨pretty
unique¨ package name, ¨E¨. ¨E¨ is the friendly name you use locally to
identify the activity. There is also a pretty name ued in interfaces, which
is ¨E!¨ this can be translated, changed from version to versiion.
when I join a larger group that has some other activity named E, I should
change my public activity-name (andraelly should change the display name).
Everyone can see that my ¨E¨ is differnet from the existing one, since they
have different unique IDs, but to supprot simple intreface-driven updates
and version selection, the friendly package name should change.
aside: there is some confusion about the hisotrical and practical use of
sortkeys. this is some piece of metadata that an author can acontribuet,
which will help to sort a cluster of related activities with one another.
similarly, which activities appear nextto which other ones in the circle
view is improtnt. note - this is NOT aout ¨favorites¨.
Grouping Version Identity
P10 X
\- P 9 O -- change in ownership
N 8 X
\- N 7 X
Eben: Use tags to support grouping, e.g. tamtam or mamamedia or draw
Scott: Localisation of tags is hard.
note : having ¨signed¨ versions of activities, and the ecure model, is not
necesarily relevant to lots of activities and use caes. we should support
identifying versions that claim to e of the same underlying activity, and
claimed merges and forks, without worrying about keys and signing.
THINGS ABOUT WHICH THERE IS NOT CONSENSUS.
how to bulk update a set of activities soeveryone in a room has the same
version
update on share? is this a good idea? how would it work in ui?
push updates - is this a good idea? how would it work?
My post-meeting comments:
1. for version threading, what we need for an activity is not a claim like
I am a version of activity ID 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.
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.
3. For push updates and school versions, I would presume you'd in some
manner beyond the scope of this discussion get an xo bundle (or a bundle of
bundles), the only problem here is how to install it and mark it as the
official school version. Stated like that, it seems to be obviously a
problem of tagging. How do you securely tag documents you receive from
external sources? I'd say that only signed tags should be allowed to move
from one XO to another, and that it should be possible to have a filter
which automatically pushes
