Automatic transfer/update of activities on the mesh (Was: Sharing behavior in the core Read activity)

[Benjamin M. Schwartz]

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