[sugar] Requirements for activity and buddy properties needed

[Eben Eliason]

>
> A lot of this looks like a wishlist for the future rather than something
> we can implement in the short term, I'm afraid... I think the only
> user-visible feature we'll be adding in the near future is invitations.
> We'll try to design in ways that don't prevent what you've asked for in
> future.


Absolutely.  I heard "post trial 3" and thought that this was to be an all
inclusive list of future goals for the purpose of directing a stable API,
regardless of how complete its implementation is in the near term.  It will
require some goal setting, and further discussion, for sure.

On Tue, 07 Aug 2007 at 19:44:30 -0400, Eben Eliason wrote:
> > This may be quite silly, but if it's 90x90 px it will fit cleanly into
> the
> > grid we've been using for designs. Since it's not a power of two, I'm
> not
> > sure why 96 is the blessed number.  Are there technical reasons here?
>
> That would be fine too. The important thing for me is "it's small". 96px
> just happens to be the size PS currently scales to (well, the size it
> scaled things to before we removed that feature so we could have our
> performance back).
>
> > They will also have a version identifier of some kind, which may need to
> > relate to the activity identifier when we decide what is actually
> > represented on the mesh.  We're still discussing details in this area.
>
> Well, I've been told we have feature-freeze on Monday, so that's
> going to have to be a future addition.


Yup.  We don't even have versions in the datastore yet.  That functionality
is pending.

> A few notes on activity properties...
> > the Kind of the
> > activity (eg. "Paint"; not listed above)
>
> That's the "type" in our spec - we use a centrally defined D-Bus service
> name,
> e.g. org.laptop.Paint or something, and assume that the UI will localize
> it
> appropriately. As currently implemented, it does, at least into English;
> I assume other localizations are just a matter of writing the translations
> in the .activity file.


Oh, of course.  That makes sense.

> and the Icon (Type above seems to
> > relate here, but I think we need to directly associate the icon and not
> just
> > its identifier; how does this work?)
>
> So... you want per-activity-instance icons? That's a requirement I've
> never heard of: currently, the icon is 100% determined by the type (e.g.
> Paint) and the color (i.e. it's the activity program's icon as it
> appears in the donut view, with colors adjusted to match the initiator's
> colors).


No, I just got confused with the terminology; the relationship of activity
type identifier to icon should be one to one. My main point is that not
everyone will have every activity, and therefore not everyone will know
locally what the icon for (say) org.laptop.Paint is.  If we only send the
string over the mesh, and not the SVG itself, there needs to be a protocol
that asks for the associated icon. It's quite probable that this is already
handled, and I just don't know the details.

> As for color, we have put some thought into the version history system,
> and
> > have a potential use for associating different color pairs with
> different
> > versions in the history.  This is still immutable from the perspective
> of
> > the kids, of course.
>
> Is this something for which we need to transfer information over the
> network, or can the color be determined by asking the journal? For the
> purposes of this email I only care about information going over the
> network. Again, this is a requirement I've never heard of before.


Well, it is a very (as of this afternoon) new idea. The thought is that a
couple kids (call them red and green) could be working on a document (lets
say colored red) in sync.   They go home and work on the red document
independently.  At this point, since they aren't working together, there is
an implicit branch.  The versions that they now store in the Journal could
take on their own colors, so that tomorrow there is a red and a green
version of that document.

The trickier scenario is similar to the above, but the branch is due to the
network falloff (not explicit stop/resume of the activity), and therefore
the activity instances would begin to save with new colors (and be
represented on the mesh as such) even though the instances were never
closed.

Of course, this is tied up with solidifying versions, which we don't yet
have.  In the meantime, there is no requirement for changing the colors of
an active activity instance.  Whether we would like to or not in the future
is up in the air.  Whether we can or not anyway is also a separate concern,
and the answer could be 'no'.  Let us know, since we're still in early
design talks about the concept.

It simplifies the implementation massively, particularly on Salut, if
> once an activity chat room has been opened, most/all of its properties
> can't
> change at least until everyone leaves. Obviously we'll have to make an
> exception for the name and (if implemented) the tags.
>
> > Regarding tags, I won't get into details here, but we also have ideas
> around
> > tags which require each tag to have an associated identity (unique ID
> for a
> > buddy and a color pair) for use in displaying the tags. If we do follow
> this
> > approach, we'll need a more complex data structure for the tag list.
>
> It's looking as though tags can't happen for Trial 3 or FRS; we certainly
> can't
> implement "a more complex data structure" without knowing in advance what
> it
> *is*, and the feature freeze date is rumoured to be Monday.


We really want basic tags for FRS, since its an essential aspect of the
filesystem.  By basic, I really mean in the best case a list of Unicode
strings (as you specified), and in the worst case a single Unicode string
that is full-text searched for now.  Again, here I was trying to lay out the
potential design directions so we don't box ourselves in.  The tags could,
for now, be local to the Journal and not transmitted on the mesh.

> which are set when the activity is created, and are required to be
> > > visible in the mesh view to children who have not joined the activity.
> >
> > It won't be required that every child see every activity.  Only
> activities
> > which the child is able to join should be shown in the mesh (at the
> moment,
> > this simply means any shared activity, but in the future we may have
> more
> > scopes which limit who can see what on the mesh).
>
> OK, perhaps that was badly phrased. The assumption I wanted you to
> accept or reject was that for an activity to be shown in the mesh view, it
> is
> sufficient to know the properties I listed (plus members, but that's a
> bit different anyway).


Sounds good. Other details we may want later are a timer (how long it's been
going on) and a preview. The latter, of course, has dramatic implications
and is definitely a future feature.  The timer would be easy to add, but
isn't needed near term, if ever, so ignore it for now.

> No other information is required to be visible in the mesh view, and
> > > properties will be added sufficiently slowly that it's acceptable to
> > > require
> > > changes to Gabble, Salut and PS for each new property.
> >
> >
> > We also have a notion of an activity Description, though semantics are
> not
> > defined here either.  This description could appear on the mesh, and
> also
> > has a place in the Journal.  We're not sure how to reconcile different
> > Descriptions across versions and across different kids' Journals.
>
> We can't implement something with unknown semantics, so this will
> have to be delayed until we know what to implement.


Indeed.  This gets closer: At the moment we're thinking of treating it
almost like a commit comment. It gets associated with a version within the
journal.  It can be edited later at any time. The description would be
assigned to an active instance at time of resume by the Journal which
initiated resume action, so no collisions occur. Once the instance is active
on the mesh, anyone participating can change it, and future revisions saved
within the Journal will take on the description present in the active
instance at time of save.  Nonetheless, this can also wait.  Tags are more
important.

"Description" makes me think "likely to be multiple sentences". There is a
> quite small limit to the amount we can store using the current mechanism
> on Salut, so we'd need to think about using a different mechanism. Not a
> problem necessarily, but it makes this a larger feature to implement, so,
> later.


This is likely true.  We don't want to limit the description field in
length, unless we really need to.

> We also need to associate the list of participants with an activity,
> > regardless of how this is shown in the UI.  Obviously we would like to
> group
> > the XO icons around their active activity.  We may also want a list of
> the
> > names of the participants in the rollover for an activity on the mesh.
>
> Yes, we track who's in an activity. At the moment we let people claim to
> be in activities they're not, and claim not to be in activities they
> *are* in, but I'm going to remove that "feature" if I redesign the API -
> it was intended to make implementation easier in Gabble, and indeed it
> does, but it makes the implementation in Salut much more complicated.
>
> > There is a 4th kind which might also be a trial 3 goal.  We'd like
> "group"
> > activities, such that all the members in a given group can see any
> > activities that are shared with that group, without needing an explicit
> > invitation.
>
> I don't think it's feasible for the connection managers to know about
> groups for Trial3, and architecturally I don't think it's a good idea
> anyway.
>
> There is a way to get the same UI-visible result with less code,
> although that probably won't be feasible for Trial 3 either.
> As a future enhancement we could add API for sending "quiet" invitations
> which are basically the same at the Telepathy/XMPP level, but are handled
> differently by the UI (i.e. just quietly put the activity on the mesh view
> without doing the special invitation handling in the frame). Then the UI
> could use "quiet" invitations when people are invited due to a scope
> widening.


This sounds like a pretty good idea.  A single bit in the invitation could
indicate that, which makes me happy.  It certainly simplifies the idea,
since the invite carries the data for the activity anyway.  Good thinking.

> I do want to point out, however, that any activity to which
> > you've been invited should remain on the mesh even if you decline the
> > invitation.  It should always be accessible to you in the future.
>
> That's the mesh UI's concern... I don't plan to make that impossible.


Heh, with the implementation of "quiet invitations" it is the UI's concern.
 Works for me.

> We talked a lot about this in terms of security.  I think the current idea
> > here is that children CAN'T change them, at least without a reasonable
> > amount of effort.  When they change their name, they essentially take on
> a
> > new identity and need to be reintroduced to everyone.  Short answer is
> no.
>
> So, our planned performance improvement can work. Good.
>
> > Can the child's "home XMPP server" change, i.e., can their JID change?
> >
> > I assume this is the registration question.  There is a ticket about it,
> and
> > the current idea is to present a "register" action within the secondary
> > rollover for a school server, so that a child can re-register when
> needed.
> >  I don't know the technical details.
>
> For this to work, there will have to be considerable coordination
> between PS, registration and security. Not feasible for Trial3, but we
> can try to plan the API so we won't gratuitously break this.
>
> > > Do we need the concept of a buddy's "current activity"? (Currently
> it's
> > > implemented, but in practice is write-only)
> >
> >
> > Absolutely.  Once we have the grouping UI implemented in the mesh, we
> need
> > to associate an XO icon with only a single activity at a time.  The
> "current
> > activity" provides this possibility.  The granularity with which this
> > property is known on the mesh is arbitrary.  I don't think it needs to
> be
> > event based, necessarily.
>
> OK then, follow-up question: Suppose Alice and Bob are in an invite-only
> activity, ID abcabc. Their current activity IDs are advertised to the
> world (as all the buddy properties are). Charlie can look at their
> activity IDs and infer that they're in an activity together, even if
> it's not possible to tell anything about that activity. Is this
> acceptable?


Hmm, interesting question.  I suppose that's OK, though just shy of perfect.
 Is it always necessary for Alice and Bob to advertise their active activity
to the whole world?  Once we have encryption, can you encrypt these
advertisements so that only the people with (for instance) the same group
key can find out what they're doing, and everyone else just ignores the
advertisement?  From a UI/interaction perspective guess I don't really care.
 Ivan, what are your thoughts on the privacy/security side?

(If not, considerable work will be needed to support this. For Trial3 I
> don't believe this to be feasible.)
>
> > I prefer the latter in the sense that I'd like to know who is in an
> activity
> > before I join it.  On the other hand, I don't like the idea of
> transmitting
> > a list of participants which could soon become stale. Ideally, the act
> of
> > receiving an invitation (without yet opening it) should render the
> > associated activity within the mesh  just as the rest are represented.
>
> That's what I'd feared. That's technically possible, but causes more
> protocol complexity and more network traffic (every time someone joins
> or leaves the activity, everyone who has sent invitations has to
> contact the people they invited and tell them about the membership
> change). If we can't do that, which of my suggestions is less bad,
> "just the inviter" or "stale snapshot of members list"?


I think I'm going to defer that until I can talk about it from a design
perspective with Pentagram and others.  On the technical side, I would argue
that it's not necessary make this event driven.  If a new snapshot is taken
every few minutes it might be adequate enough.  You could also send the list
as a diff, to minimize bandwidth a bit.

> Also, we should probably revoke an invitation if the inviter leaves the
> > activity.  Ideally, the invitation would simply disappear as though it
> > hadn't ever existed when this occurs.
>
> Depending how we implement invitations in Salut, invitation revocation
> may or may not be technically possible. In Gabble we're somewhat at the
> mercy of the server software - I don't know offhand whether XMPP handles
> invitation revocation.
>
> It would be possible to tell the UI it's no longer welcome (i.e. get it to
> stop displaying an icon, at least), although again that's more complexity.


This is the most essential part, from a user interaction perspective.  If
the person who invited me isn't there (or no one is there), then the
invitation should just hide. I'm not sure the fact that I might get a key to
the activity which is then "soft-revoked" is a problem.  I suppose if I
hacked it a bit I could join the activity even though my friend is gone, but
that doesn't worry me from a security standpoint, since the fact that he's
no longer there doesn't mean I'm any lest trustworthy.  It just means from a
social perspective that it might be odd for me to join.  I may, in fact, not
even want to.

Could you, similar to the "quiet invitation" add one more bit for "revoke
invitation"?  You could omit the other details in the revocation to save
bandwidth, needing only the activity ID, perhaps.

> This automatically handles the case
> > when the activity is no longer present on the mesh at all, which is a
> > concern even if we don't revoke it when the inviter leaves.
>
> You're assuming here that people always leave activities voluntarily, I
> think. If someone just drops off the network (maybe they walked out of
> range
> or their battery ran out), they're in no position to notify anyone about
> anything (which causes some bugs already).


Hmmm, good point.  We need to come up with some guidelines for what happens
when connectivity is intermittent.  In the worst case (probably average
case), one or both of the separated versions will change in the meantime.
 Perhaps there's some small amount of leniency built into the system which
will automatically rejoin the active instance on the mesh and take on that
versions changes.  Of course, that depends upon implicitly deciding which is
the active one, which you could try to do based upon number of participants,
but you can't rely on in any case.  This is another instance where the "new
colors" could come in, so that the activity is clearly split at that point
and in order to resync one party would join the other's active instance.
 More thought needed...

I suppose invitations might eventually need to time out after a while

unless renewed, or something (at least from the UI's perspective). More
> network traffic, but better failure modes.


That might be a logical approach.  In the world we're talking about the
invitations can be somewhat transient. Deciding what the timeout should be
is another tricky problem.  I think that we need to express the life of an
invitation within the UI if they do timeout -- the secondary rollover would
be a fine place, assuming the interval is sufficiently large (perhaps 30
minutes?).  I hesitate to say they timeout without warning.  If you were
away from the computer and return to 10 invitations, you'd have no idea how
urgent they were.

- Eben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.laptop.org/pipermail/sugar/attachments/20070807/fbcd5082/attachment-0001.htm