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. <a href="http://microsoft.com">microsoft.com</a>   * 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 ...     <a href="http://wiki.laptop.org/go/Talk:Activity_bundles#A_proposal_for_Activity_Signing">http://wiki.laptop.org/go/Talk:Activity_bundles#A_proposal_for_Activity_Signing</a>   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   P            10     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 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 <a href="http://activity.info">activity.info</a> would be fine - that way, version changes are automatically picked up, but not every change in the source code. If, later, <a href="http://activity.info">activity.info</a> 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 activity versions with "tag X signed by entity Y" to the front of the line, or even into the activity donut. This filter would be user-modifiable, but the default filter could be to trust the signature of your school server; thus, the 99% of kids who didn't bother with that would automatically and painlessly use the official school version. Jameson   <div class="gmail_quote">On Tue, Mar 25, 2008 at 3:31 PM, Eben Eliason <<a href="mailto:eben.eliason@gmail.com">eben.eliason@gmail.com</a>> wrote: <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">After just a couple well considered responses, it seems that this might be another topic worthy of some time under the spotlight at the mini-conference.  I copied both of these great responses to my initial email below, just to make sure they remain for everyone to reference. I trust that you can faithfully reconstruct my initial proposal and questions from the responses. - Eben On Tue, Mar 25, 2008 at 4:02 PM, Benjamin M. Schwartz <<a href="mailto:bmschwar@fas.harvard.edu">bmschwar@fas.harvard.edu</a>> wrote: > On Tue, 2008-03-25 at 13:46 -0400, Eben Eliason wrote: >  > Naturally, there are some security concerns, but those could be easily >  > addressed, I believe, with the usual signing mechanisms.  Updates to >  > activities would only be transparent if the update was signed, etc. > >  I agree.  For a first implementation, only basic signing is required. >  Eventually, we may have activities written by teams of children in which >  new members come and go, and the projects occasionally fork.  This >  requires a more complex signing/upgrade system.  I sketched one proposal >  at [1]; it is not perfect. > > >  > The bigger question is really determining how to make the whole >  > transfer process work smoothly in these cases.  Can we use a torrent >  > model to make it easy to get activities from the mesh, even as people >  > come and go on an unreliable network? > >  For a first implementation, this is not necessary.  Most Activity >  Bundles (.xo's) are about 100 KB or less.  Over a direct mesh link, >  transferring small bundles takes about a second.  Only with very large >  activities, and very bad links, will simple transfers be insufficient. > > >  > Can we transfer it directly >  > from someone who is in the activity we join? > >  This seems the simplest solution. > > >  > If so, can we still ask >  > the next activity participant for the remainder if the first one >  > leaves? > >  Yes.  However, for a first implementation, the download should probably >  just restart.  This optimization will only be important for activities >  with exceptionally high turnover. > > >  > As there has been interest expressed in developing basic OS >  > integrated object transfer as a GSoC project, I wonder if those >  > efforts could also be applied to this problem, or if this should be >  > offered as another distinct project alternative. > >  Current implementations of file transfer (Read, and therefore >  Distribute) work by getting a Stream Tube from Telepathy, and then >  running a HTTP server on this tube.  Any near-term implementation of >  transferring Journal Entry Bundles or Activity Bundles is likely to use >  the same mechanism. > >  This works, and will work for the proposed case.  For the future, I see >  file transfer as precisely the sort of thing that should be handled >  internally to Telepathy.  Perhaps Telepathy should implement XEP-0234 >  (file transfer)[2] or even XEP-0214 (file sharing)[3]. > >  > What do people think? > >  I think it would not be too hard, and should definitely be on the to-do >  list.  It would be a major user-visible milestone in the journey toward >  Complete Sugar.  There are several things that have to happen first: > >  1. Basic activity signing. >  2. Pushing SVG files through Presence, so that I can see the icon in the >  mesh for an activity I don't have. >  3. Sane activity storage: >  What if the shared session is a newer version of an installed activity, >  but it's been modified by someone other than the original author?  I >  should then be able to join, but it should be treated as a new activity, >  not an upgrade, even though it has the same name.  This means we need an >  activity storage mechanism that can handle multiple activities with the >  same name. > >  Also, all installed .xo bundles must be kept around, or Sugar must be >  able to reconstitute them on demand without invalidating the signatures. > >  --Ben > >  [1] <a href="http://lists.laptop.org/pipermail/security/2007-December/000341.html" target="_blank">http://lists.laptop.org/pipermail/security/2007-December/000341.html</a> >  [2] <a href="http://www.xmpp.org/extensions/xep-0234.html" target="_blank">http://www.xmpp.org/extensions/xep-0234.html</a> >  [3] <a href="http://www.xmpp.org/extensions/xep-0214.html" target="_blank">http://www.xmpp.org/extensions/xep-0214.html</a> > > On Tue, Mar 25, 2008 at 3:40 PM, Michael Stone <<a href="mailto:michael@laptop.org">michael@laptop.org</a>> wrote: > Eben, > >  I've got more questions than answers for you, but perhaps my smaller >  questions will make the overall problem easier to analyze. > >  Michael > >  Questions: > >  First, how will we discover that a code exchange is needed? > >   Three straw-man options include: > >   a) include adequate information in a presence notification or in a >      resource discovery URL [1] to permit us to calculate decide >      protocol compatibility > >   [1]: <a href="http://lists.laptop.org/pipermail/devel/2008-February/011108.html" target="_blank">http://lists.laptop.org/pipermail/devel/2008-February/011108.html</a> > >   b) add a new handshake to the "join a shared instance" protocol to >      establish this information. > >   c) leave it up to the activity to figure out (perhaps with assistance >      from a system service or library) > >  Next, let us assume that a code or data exchange is necessary in order >  to provide protocol compatibility. How do I figure out what bits are >  needed? How do I figure out where to go in order to get the requisite >  bits? > >   I think it would be wise to add some indirection here so that people >   who are not in physical proximity can acquire the bits from low-cost >   sources when possible and to fall back on direct exchange of bits when >   necessary. Also so that we can extend the bit-acquiry software with >   new protocols as they become available. > >   (For a first draft, we might as well copy Read's use of >   HTTP-over-Tubes, since it's already conveniently available to us.) > >   NB: If we ever want to imagine running Sugar on platforms other than >   XOs, (or even between XOs running significantly different builds), >   then we'd better consider system-dependency issues up front. (We can >   ignore this question temporarily while doing feasibility studies on >   our own platform, but if this idea is going to rock the world like I >   want it to, then we need to think early on about giving the humans >   operating our technology access to information adequate to debug and >   work around incompatibilities between their respective systems.) > >  After acquiring the bits, there's a small question of what to do with >  them. Do they go into the Journal as a new entry? Are they immediately >  unpacked alongside the user's other activities? If so, do they >  obscure older versions of the same activity? Should the older version be >  removed? > >   I'm particularly concerned by Pippy-generated bundles here because >   they seem like they might be particularly subject to edit wars simply >   by being so easy to create and modify! (Should Pippy-generated bundles >   "stake claims" to their names in the fashion proposed in [2]?) > >   [2]: <a href="http://dev.laptop.org/git?p=users/krstic/installer;a=tree" target="_blank">http://dev.laptop.org/git?p=users/krstic/installer;a=tree</a>; > > >  > Naturally, there are some security concerns, but those could be easily >  > addressed, > >  They are far from "easily" addressed, but there's a good argument that >  they're _worth_ addressing because, in my opinion, easy and safe code >  sharing is one of the most attractive UI goals of our project! > > >  > I believe, with the usual signing mechanisms.  Updates to >  > activities would only be transparent if the update was signed, etc. > >  Information assurance mechanisms primarily deal with spoofing attacks >  and network hanky-panky. Isolation mechanisms are what we're using to >  make it generally safer to run code, regardless of whether we know where >  it came from. Both are necessary to make this "easy code sharing" policy >  more safe to pursue. _______________________________________________ Sugar mailing list <a href="mailto:Sugar@lists.laptop.org">Sugar@lists.laptop.org</a> <a href="http://lists.laptop.org/listinfo/sugar" target="_blank">http://lists.laptop.org/listinfo/sugar</a> </blockquote></div>