[Sugar-devel] [sugar] XO identity shared via Browse

[Robert McQueen]

Ivan Krstić wrote:
> For those just tuning in, the whole story of Jabber on the XO  
> has basically been colorfully fucked, as has that of the entire  
> collaboration stack. I suggest further proposals of actually using  
> Jabber for anything wait until the basic XO implementation gets to the  
> point where IRC was 20 years ago -- namely, working.

I really don't think these kind of comments are productive for anyone.
I'm pretty fed up of discussions about collaboration which take the
format of stating that things are broken, hypothesizing about new
approaches which might work better, and ignoring what Collabora has done
and why.

I know we've made mistakes with what has been implemented but we can
operate e-mail clients reasonably well and we're not fucking idiots, so
I'd like to think it's worth communicating with us so we can explain the
rationale behind what we've done. Then maybe we can actually cooperate
and correct any misapprehensions and hence make the appropriate
corrections to our implementation, rather than just talking across each
other all the time.

However, I'm not interested in participating (therefore I have not done
so) in participating in discussions about collaboration on Sugar which
a) ignore everything we've done so far, and b) contain fallacies such as:
 * Given a working IPv6 network, we...
 * Given a global DNS hirachy of school servers, we...
 * ...

If these presumptions were true (and considering XMPP only because
multicast[1] is a complete fuckup on the XO mesh network), then what
we've implemented would work a hell of a lot better than it currently
does. There's nothing about XMPP that will prevent it from "actually
working", except for certain errors we've made in our implementation:
 1. Abusing rosters on the XMPP server to achieve mutual visibility,
    which scales poorly and destabilises the XMPP server.
 2. Sending XMPP data in-band is slow as hell.
 3. The tubes APIs are hard to use.
 4. The JIDs are allocated in a user-opaque fashion.
 5. You can't transfer files.

The reasons for these errors (respectively)
 1. The UI had no way for controlling visibility, and no discussion
    about how to do it ever terminated, so we made a hack which stuck
    way longer than it should've done. We didn't have a lot of timeline
    or requirements to go on, so our decisions for what to prioritise
    were underinformed, and the starting of deployments with what we had
    really took us by surprise.
 2. We were under-resourced and prioritised implementing the tubes API
    for others to use over implementing it in a performant fashion, and
    then we continued to be under-resourced and chasing other issues
    like why multicast worked so badly.
 3. We didn't have time to think a lot about how to make it easy, and we
    didn't have any requirements, so we had to pick some stuff and hope
    that activity authors would push back. We understand D-Bus well, so
    a D-Bus tube seemed like a really good idea to us to expose a
    multi-participant primitive which had some routing capabilities, but
    didn't mean using multicast in the application. Stream tubes let you
    share arbitrary socket apps with no modification and a tiny bit of
    Telepathy glue code, but, you know what? POSIX sockets aren't /that/
    easy to use either. Distributed systems are actually hard.
 4. We were given vague requirements about ensuring consistency of
    identity across different collaboration mechanisms using the XO's
    key, and although the exact reasoning escapes me now, the
    constraints of the legacy (before we turned up) presence service API
    meant the only way we were able to reconcile this with XMPP was to
    make the key hash part of the JID to avoid the need for any
    additional communication to verify identity of buddies. But we were
    told that key hashes weren't unique enough, so in the face of
    apparently unsatisfiable requirements we just left this one to focus
    on other things instead.
 5. We were told that live collaborative applications were more
    important.

Our plans for fixing them (respectively):
 1. Martin and the other XS guys have already done great work fixing up
    ejabberd to be more reliable even in this odd configuration, and
    we've written Gadget, the XMPP server-side component which takes
    care of indexing and searching buddies and activities which are
    available on your server. Total mutual visibility no longer has to
    be enforced on the server, and the XO (code, at least) can opt in or
    out to publishing its activities and presence, as with normal XMPP.
 2. We've basically fixed this now, Gabble has code for using the
    standard XMPP SOCKS5 bytestreams to implement stream tubes using
    peer to peer connections. It can soon make use of a relay component
    on the XMPP server to aid NAT traversal, and falls back to in-band
    bytestreams. It's harder on D-Bus tubes because they're one to many
    and D-Bus has message ordering guarantees which we currently rely on
    the XMPP server to enforce for us. We can revisit this later after
    file transfer works better, or work on the activities we have to
    favour stream tubes (and hence inherently P2P traffic) over D-Bus
    tubes, or just use them for light synchronisation traffic (like send
    next/prev D-Bus messages, but make a stream tube or a file transfer
    for dumping the initial document).
 3. Some people have had great ideas at building simpler primitives for
    simpler use-cases, like the shared object state python classes by
    Ben Schwartz, but unless you do something roughly turn-based or rely
    on a single master, it's still not very easy to keep shared state
    synchronised with multiple distributed participants. Distributed
    systems continue to be quite hard. Most journal sharing and
    datastore versioning discussions never quite seem to terminate for
    this reason too. :P
 4. We've given up on that, in favour of using the JID as the unique ID,
    so provided the school server actually has a unique DNS name, we're
    all set. We can expose different contacts on different protocols as
    possibly different buddies, then delete a whole load of bullshit
    (most of presence service, we hope), and we can revisit the security
    requirements once stuff is working better and the XMPP folks have
    moved further on how their end to end crypto should work (or join
    forces and move it with them).
 5. We were told recently that transferring files was important too, so
    we've implemented it in Telepathy, starting with the Salut backend,
    and soon in Gabble too (using the XMPP file transfer standards).

Currently Collabora is working on fixing these issues as pro bono work,
because we believe that SugarLabs is worth supporting and we admit that
we've made some mistakes and we'd like to fix them. However, every time
people continue to criticise and ignore us, it gets more and more
tempting to just wash our hands of the whole thing and just give up.

So, given we've got some existing code which can actually work, and a
plan of action to make it work better, we'd really appreciate if people
actually talk to us with coherent criticisms and suggestions for
improvements, rather than just at best ignoring us, or at worst
criticising us, and somehow hoping that a fairy will descend and make
these problems go away.

> --
> Ivan Krstić <krstic at solarsail.hcs.harvard.edu> | http://radian.org

Regards,
Rob

1: Red Hat were already using multicast when Collabora were engaged, so
it was handed to us as a requirement. We quickly identified that it
worked very badly on the XO mesh, so we filed a ticket, which was
ignored for almost an entire year, at which point people turned around
and said "OH MY GOD, YOU'RE NOT USING MULTICAST ARE YOU? YOU FOOLS!".
Anyway, screw that, if the XO mesh honestly can't be made to do
multicast, and you can't/won't ever fix it, then some kind of
higher-layer hack like Cerebro seems a reasonable workaround, and we
showed it was entirely possible to implement Telepathy APIs on top of
Cerebro. However, outside of the OLPC project, working around the XO's
broken networking hardware is of little to no interest to Collabora and
the Telepathy project.

-- 
Robert McQueen                                 +44 7876 562 564
Director, Collabora Ltd.             http://www.collabora.co.uk