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.
next prev parent 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