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

[Eben Eliason]

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
<bmschwar at fas.harvard.edu> 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 <michael at laptop.org> 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.