Galène videoconferencing server discussion list archives
 help / color / mirror / Atom feed
From: Sean DuBois <sean@siobud.com>
To: Juliusz Chroboczek <jch@irif.fr>
Cc: galene@lists.galene.org
Subject: [Galene] Re: Keeping the developer honest: why native clients are important
Date: Wed, 18 Sep 2024 11:10:10 -0400	[thread overview]
Message-ID: <jnrdnarifhlo7ki2zhizzlbrg3hb32qsbry4qnsqyl5m663j6z@vshmto47ognu> (raw)
In-Reply-To: <87tteipcf6.wl-jch@irif.fr>

On Sat, Sep 14, 2024 at 03:55:41PM +0200, Juliusz Chroboczek wrote:
> 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

Native clients are very important. I hope with WHIP/WHEP they start to
get more attention.

  - Better Accessibility. A native client can be designed to accommodate particular needs.
    The user could then point them at any service.

  - Auditable/Learnable. Modern Javascript is equivalent to shipping a
    stripped binary. It is going to be even harder with
    WebCodecs/WebTransport/WASM. I would love to see Open Source clients
    where the community can iterate and improve on Congestion
    Control/Error Correct etc... would be great if that even forces
    companies to put resources on it.

  - User Freedom. No vendor lock-in! If your conferencing service starts
    doing bad things, just point your client at a different URL.

----

I would like to extend WHIP/WHEP to cover a few more use cases. I am not
sure where to start though.

* Conference Calling. I have one WHIP session to upload, then one
  (or many) WHEP sessions to download. Maybe some sort of 'pseudo WHEP'
  resource that I can listen for SSE events on? That would announce the
  streams as they join/leave?

* Autoconf. I want to push video into OBS. Or send video OBS<->OBS into
  the same network. Remove dependence on proprietary software to do
  video mixing in the LAN.

  reply	other threads:[~2024-09-18 15:10 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-14 13:55 [Galene] " Juliusz Chroboczek
2024-09-18 15:10 ` Sean DuBois [this message]
2024-09-18 19:07   ` [Galene] " 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=jnrdnarifhlo7ki2zhizzlbrg3hb32qsbry4qnsqyl5m663j6z@vshmto47ognu \
    --to=sean@siobud.com \
    --cc=galene@lists.galene.org \
    --cc=jch@irif.fr \
    /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