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 <[EMAIL PROTECTED]> 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] http://lists.laptop.org/pipermail/security/2007-December/000341.html > [2] http://www.xmpp.org/extensions/xep-0234.html > [3] http://www.xmpp.org/extensions/xep-0214.html > > On Tue, Mar 25, 2008 at 3:40 PM, Michael Stone <[EMAIL PROTECTED]> 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]: http://lists.laptop.org/pipermail/devel/2008-February/011108.html > > 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]: http://dev.laptop.org/git?p=users/krstic/installer;a=tree; > > > > 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 [email protected] http://lists.laptop.org/listinfo/sugar
