[Galene] Keeping the developer honest: why native clients are important

[Juliusz Chroboczek <jch@irif.fr>]

Hi,

I've just had a lengthy phone discussion on the subject, so I thought I'd
summarise for the list.

Simplifying somewhat, there used to be two kinds of protocols:
undocumented proprietary protocols, such as SMB, and documented, open
protocols, such as NFS.  The proprietary protocols used to have more
features, but they tended to be messy, since they were not designed for
multiple implementations.  The open protocols tended to be cleaner and
relatively easy to implement, but had fewer features.

At some point, we were convinced that open protocols would win in the end,
but Web applications arrived.  In a web app, the client and the server are
bundled together, and even when the software is open-source, the protocol
is proprietary: it is not designed for third-party applications, it is
undocumented, and it tends to change with every version of the software.
(There are notable exceptions, such as Github, who have published their
protocol, and keep it reasonably stable.)

Galene's protocol is carefully designed to be open:

  1. it is designed to be implementable by non-web clients: it only relies
     on WebSocket and WebRTC, and at no point do we carry HTML or other
     complex formats in a message payload (that's why you cannot have
     italics in Galene's chat);

  2. it is documented; not very well, granted, but it's documented;

  3. it's versioned, and does not change in an incompatible manner between
     versions;

  4. there is a negotiation mechanism that allows the client and the server
     to choose a common protocol version.

Point 1 is the most important, and it's the reason why I've spent
countless hours implementing a native Android client: if the client side
of the protocol is implementable in Java, then it's probably implementable
in Python, in Rust, in C++, or whatever other overly complex language will
be fashionable tomorrow.

There are other advantages to having native clients:

  - the native client can integrate with the platform better than a web
    app can: the current Android client can do screen sharing, which is
    impossible in a mobile browser;

  - the native client is much more reactive than any web browser, which is
    nice if you're not willing to spend 1700€ on the latest Apple shiny;

  - a native client gives potentially better security when accessing an
    untrusted instance of Galene, since the client code is downloaded from
    a trusted source, not from the untrusted server; to be fair, that's
    not really relevant until I implement end-to-end encryption, but
    that's not trivial to do securely, and since we're not trying to sell
    snake oil, it's not worth implementing unless it actually guarantees
    security (I'm looking at you, Zoom).

Of course, we should go further, we should actually strive towards
a standardised protocol for video conferencing.  WHIP (which Galene
implements) is a step in that direction, but it only provides ingress:
it's useful for hooking an IP camera or OBS Studio to an arbitrary server,
but it's not a complete solution for conferencing.  I'm following the IETF
MOQ group, which is working on a media stack based on QUICK, but it seems
dominated by Google and the CDN vendors, so I expect it to be geared
towards Youtube and Netflix rather than videoconferencing.

So for now, the best we can do is ensure that Galene's protocol remains
easy to implement, ensure that there exist native applications, and try to
connect with the rest of the open-source videoconerencing ecosystem.  And
if you've got free time on your hands, you could do worse than hack
together a desktop client for Galene.

-- Juliusz