Galène videoconferencing server discussion list archives
 help / color / mirror / Atom feed
From: Juliusz Chroboczek <jch@irif.fr>
To: galene@lists.galene.org
Subject: [Galene] Keeping the developer honest: why native clients are important
Date: Sat, 14 Sep 2024 15:55:41 +0200	[thread overview]
Message-ID: <87tteipcf6.wl-jch@irif.fr> (raw)

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

             reply	other threads:[~2024-09-14 13:55 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-14 13:55 Juliusz Chroboczek [this message]
2024-09-18 15:10 ` [Galene] " Sean DuBois
2024-09-18 19:07   ` Juliusz Chroboczek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.galene.org/postorius/lists/galene.lists.galene.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87tteipcf6.wl-jch@irif.fr \
    --to=jch@irif.fr \
    --cc=galene@lists.galene.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox