<div><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">A lot of this looks like a wishlist for the future rather than something<br>we can implement in the short term, I'm afraid... I think the only
<br>user-visible feature we'll be adding in the near future is invitations.<br>We'll try to design in ways that don't prevent what you've asked for in<br>future.</blockquote><div><br class="webkit-block-placeholder">
</div><div>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.
</div><br><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">On Tue, 07 Aug 2007 at 19:44:30 -0400, Eben Eliason wrote:<br>> This may be quite silly, but if it's 90x90 px it will fit cleanly into the
<br>> grid we've been using for designs. Since it's not a power of two, I'm not<br>> sure why 96 is the blessed number. Are there technical reasons here?<br><br>That would be fine too. The important thing for me is "it's small". 96px
<br>just happens to be the size PS currently scales to (well, the size it<br>scaled things to before we removed that feature so we could have our<br>performance back).<br><br>> They will also have a version identifier of some kind, which may need to
<br>> relate to the activity identifier when we decide what is actually<br>> represented on the mesh. We're still discussing details in this area.<br><br>Well, I've been told we have feature-freeze on Monday, so that's
<br>going to have to be a future addition.</blockquote><div><br class="webkit-block-placeholder"></div><div>Yup. We don't even have versions in the datastore yet. That functionality is pending. </div><br><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">
> A few notes on activity properties...<br>> the Kind of the<br>> activity (eg. "Paint"; not listed above)<br><br>That's the "type" in our spec - we use a centrally defined D-Bus service name,
<br>e.g. org.laptop.Paint or something, and assume that the UI will localize it<br>appropriately. As currently implemented, it does, at least into English;<br>I assume other localizations are just a matter of writing the translations
<br>in the .activity file.</blockquote><div><br class="webkit-block-placeholder"></div><div>Oh, of course. That makes sense. </div><br><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">
> and the Icon (Type above seems to<br>> relate here, but I think we need to directly associate the icon and not just<br>> its identifier; how does this work?)<br><br>So... you want per-activity-instance icons? That's a requirement I've
<br>never heard of: currently, the icon is 100% determined by the type (e.g.<br>Paint) and the color (i.e. it's the activity program's icon as it<br>appears in the donut view, with colors adjusted to match the initiator's
<br>colors).</blockquote><div><br class="webkit-block-placeholder"></div><div>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.
</div><br><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">> As for color, we have put some thought into the version history system, and<br>> have a potential use for associating different color pairs with different
<br>> versions in the history. This is still immutable from the perspective of<br>> the kids, of course.<br><br>Is this something for which we need to transfer information over the<br>network, or can the color be determined by asking the journal? For the
<br>purposes of this email I only care about information going over the<br>network. Again, this is a requirement I've never heard of before.</blockquote><div><br class="webkit-block-placeholder"></div><div>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.
</div><div><br class="webkit-block-placeholder"></div><div>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.
</div><div><br class="webkit-block-placeholder"></div><div>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.
</div><br><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">It simplifies the implementation massively, particularly on Salut, if<br>once an activity chat room has been opened, most/all of its properties can't
<br>change at least until everyone leaves. Obviously we'll have to make an<br>exception for the name and (if implemented) the tags.<br><br>> Regarding tags, I won't get into details here, but we also have ideas around
<br>> tags which require each tag to have an associated identity (unique ID for a<br>> buddy and a color pair) for use in displaying the tags. If we do follow this<br>> approach, we'll need a more complex data structure for the tag list.
<br><br>It's looking as though tags can't happen for Trial 3 or FRS; we certainly can't<br>implement "a more complex data structure" without knowing in advance what it<br>*is*, and the feature freeze date is rumoured to be Monday.
</blockquote><div><br class="webkit-block-placeholder"></div><div>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.
</div><br><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">> which are set when the activity is created, and are required to be<br>> > visible in the mesh view to children who have not joined the activity.
<br>><br>> It won't be required that every child see every activity. Only activities<br>> which the child is able to join should be shown in the mesh (at the moment,<br>> this simply means any shared activity, but in the future we may have more
<br>> scopes which limit who can see what on the mesh).<br><br>OK, perhaps that was badly phrased. The assumption I wanted you to<br>accept or reject was that for an activity to be shown in the mesh view, it is<br>sufficient to know the properties I listed (plus members, but that's a
<br>bit different anyway).</blockquote><div><br class="webkit-block-placeholder"></div><div>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.
</div><br><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">> No other information is required to be visible in the mesh view, and<br>> > properties will be added sufficiently slowly that it's acceptable to
<br>> > require<br>> > changes to Gabble, Salut and PS for each new property.<br>><br>><br>> We also have a notion of an activity Description, though semantics are not<br>> defined here either. This description could appear on the mesh, and also
<br>> has a place in the Journal. We're not sure how to reconcile different<br>> Descriptions across versions and across different kids' Journals.<br><br>We can't implement something with unknown semantics, so this will
<br>have to be delayed until we know what to implement.</blockquote><div><br class="webkit-block-placeholder"></div><div>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.
</div><br><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">"Description" makes me think "likely to be multiple sentences". There is a<br>quite small limit to the amount we can store using the current mechanism
<br>on Salut, so we'd need to think about using a different mechanism. Not a<br>problem necessarily, but it makes this a larger feature to implement, so,<br>later.</blockquote><div><br class="webkit-block-placeholder">
</div><div>This is likely true. We don't want to limit the description field in length, unless we really need to. </div><br><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">
> We also need to associate the list of participants with an activity,<br>> regardless of how this is shown in the UI. Obviously we would like to group<br>> the XO icons around their active activity. We may also want a list of the
<br>> names of the participants in the rollover for an activity on the mesh.<br><br>Yes, we track who's in an activity. At the moment we let people claim to<br>be in activities they're not, and claim not to be in activities they
<br>*are* in, but I'm going to remove that "feature" if I redesign the API -<br>it was intended to make implementation easier in Gabble, and indeed it<br>does, but it makes the implementation in Salut much more complicated.
<br><br>> There is a 4th kind which might also be a trial 3 goal. We'd like "group"<br>> activities, such that all the members in a given group can see any<br>> activities that are shared with that group, without needing an explicit
<br>> invitation.<br><br>I don't think it's feasible for the connection managers to know about<br>groups for Trial3, and architecturally I don't think it's a good idea<br>anyway.<br><br>There is a way to get the same UI-visible result with less code,
<br>although that probably won't be feasible for Trial 3 either.<br>As a future enhancement we could add API for sending "quiet" invitations<br>which are basically the same at the Telepathy/XMPP level, but are handled
<br>differently by the UI (i.e. just quietly put the activity on the mesh view<br>without doing the special invitation handling in the frame). Then the UI<br>could use "quiet" invitations when people are invited due to a scope
<br>widening.</blockquote><div><br class="webkit-block-placeholder"></div><div>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.
</div><br><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">> I do want to point out, however, that any activity to which<br>> you've been invited should remain on the mesh even if you decline the
<br>> invitation. It should always be accessible to you in the future.<br><br>That's the mesh UI's concern... I don't plan to make that impossible.</blockquote><div><br class="webkit-block-placeholder"></div>
<div>Heh, with the implementation of "quiet invitations" it is the UI's concern. Works for me.</div><br><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">
> We talked a lot about this in terms of security. I think the current idea<br>> here is that children CAN'T change them, at least without a reasonable<br>> amount of effort. When they change their name, they essentially take on a
<br>> new identity and need to be reintroduced to everyone. Short answer is no.<br><br>So, our planned performance improvement can work. Good.<br><br>> Can the child's "home XMPP server" change, i.e., can their JID change?
<br>><br>> I assume this is the registration question. There is a ticket about it, and<br>> the current idea is to present a "register" action within the secondary<br>> rollover for a school server, so that a child can re-register when needed.
<br>> I don't know the technical details.<br><br>For this to work, there will have to be considerable coordination<br>between PS, registration and security. Not feasible for Trial3, but we<br>can try to plan the API so we won't gratuitously break this.
<br><br>> > Do we need the concept of a buddy's "current activity"? (Currently it's<br>> > implemented, but in practice is write-only)<br>><br>><br>> Absolutely. Once we have the grouping UI implemented in the mesh, we need
<br>> to associate an XO icon with only a single activity at a time. The "current<br>> activity" provides this possibility. The granularity with which this<br>> property is known on the mesh is arbitrary. I don't think it needs to be
<br>> event based, necessarily.<br><br>OK then, follow-up question: Suppose Alice and Bob are in an invite-only<br>activity, ID abcabc. Their current activity IDs are advertised to the<br>world (as all the buddy properties are). Charlie can look at their
<br>activity IDs and infer that they're in an activity together, even if<br>it's not possible to tell anything about that activity. Is this<br>acceptable?</blockquote><div><br class="webkit-block-placeholder"></div>
<div>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?
</div><br><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">(If not, considerable work will be needed to support this. For Trial3 I<br>don't believe this to be feasible.)
<br><br>> I prefer the latter in the sense that I'd like to know who is in an activity<br>> before I join it. On the other hand, I don't like the idea of transmitting<br>> a list of participants which could soon become stale. Ideally, the act of
<br>> receiving an invitation (without yet opening it) should render the<br>> associated activity within the mesh just as the rest are represented.<br><br>That's what I'd feared. That's technically possible, but causes more
<br>protocol complexity and more network traffic (every time someone joins<br>or leaves the activity, everyone who has sent invitations has to<br>contact the people they invited and tell them about the membership<br>change). If we can't do that, which of my suggestions is less bad,
<br>"just the inviter" or "stale snapshot of members list"?</blockquote><div><br class="webkit-block-placeholder"></div><div>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.
</div><br><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">> Also, we should probably revoke an invitation if the inviter leaves the<br>> activity. Ideally, the invitation would simply disappear as though it
<br>> hadn't ever existed when this occurs.<br><br>Depending how we implement invitations in Salut, invitation revocation<br>may or may not be technically possible. In Gabble we're somewhat at the<br>mercy of the server software - I don't know offhand whether XMPP handles
<br>invitation revocation.<br><br>It would be possible to tell the UI it's no longer welcome (i.e. get it to<br>stop displaying an icon, at least), although again that's more complexity.</blockquote><div><br class="webkit-block-placeholder">
</div><div>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.
</div><div><br class="webkit-block-placeholder"></div><div>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.
</div><br><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">> This automatically handles the case<br>> when the activity is no longer present on the mesh at all, which is a
<br>> concern even if we don't revoke it when the inviter leaves.<br><br>You're assuming here that people always leave activities voluntarily, I<br>think. If someone just drops off the network (maybe they walked out of range
<br>or their battery ran out), they're in no position to notify anyone about<br>anything (which causes some bugs already).</blockquote><div><br class="webkit-block-placeholder"></div><div>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...
</div><br><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">I suppose invitations might eventually need to time out after a while</blockquote><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">
unless renewed, or something (at least from the UI's perspective). More<br>network traffic, but better failure modes.</blockquote><div><br class="webkit-block-placeholder"></div><div>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.
</div><div><br class="webkit-block-placeholder"></div><div>- Eben</div></div><br>