From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mail.toke.dk; spf=pass (mailfrom) smtp.mailfrom=irif.fr (client-ip=2001:660:3301:8000::1:2; helo=korolev.univ-paris7.fr; envelope-from=jch@irif.fr; receiver=) Authentication-Results: mail.toke.dk; dkim=pass (2048-bit key; unprotected) header.d=irif.fr header.i=@irif.fr header.a=rsa-sha256 header.s=dkim-irif header.b=m3M5NjAp Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) by mail.toke.dk (Postfix) with ESMTPS id F0EFBA89C64 for ; Sat, 14 Sep 2024 15:55:50 +0200 (CEST) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id 48EDtif9030911 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sat, 14 Sep 2024 15:55:44 +0200 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/82085) with ESMTP id 48EDtiiS022284 for ; Sat, 14 Sep 2024 15:55:44 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 25767246F1 for ; Sat, 14 Sep 2024 15:55:43 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=irif.fr; h= content-transfer-encoding:content-type:content-type:mime-version :user-agent:subject:subject:from:from:message-id:date:date :received:received; s=dkim-irif; t=1726322142; x=1727186143; bh= 6jHTD7oME1WjYbdekpFZd6zdfieZ1swDpgG5sq6tdX0=; b=m3M5NjApvRwqu+7R LiR1OQNyQ9Swun1rPFvVrciMlyEeHO+5kebFtUUuv8A+8SPdRkAqMlKV3J9iy+J5 aSyBm0TsKcXUrBkEczLMMZnCeRHOy0s4ABQN5BvyrVNIk1HowMTtNQVB+NI64bSt UDid0OJXgwLqGD4wb9u2ZTN6V+Sw9tyzOQCE7lM/zg8z71VVAbdR8Cm0yW4zn3Oq zk4/+NP+01qXaaHRJKn4IWKdx/BXm6fi+JD1BT1+wsqAGDeUKnS/OJlAj5Jt5QSz Ra4V0R2j1F+irYVrZVbnLF+V5ShO1OupQES8XN/WIMD6F/oUJH4Ooc0rUlZp+Nuw quLNrg== X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id NkQfZXtBGBc8 for ; Sat, 14 Sep 2024 15:55:42 +0200 (CEST) Received: from pirx.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 4E4A7246F0 for ; Sat, 14 Sep 2024 15:55:41 +0200 (CEST) Date: Sat, 14 Sep 2024 15:55:41 +0200 Message-ID: <87tteipcf6.wl-jch@irif.fr> From: Juliusz Chroboczek To: galene@lists.galene.org User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/29.4 Mule/6.0 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Sat, 14 Sep 2024 15:55:45 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Sat, 14 Sep 2024 15:55:44 +0200 (CEST) X-Miltered: at korolev with ID 66E595E0.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 66E595E0.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 66E595E0.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 66E595E0.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 66E595E0.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 66E595E0.000 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Message-ID-Hash: KPRJIDRAEVPXE2VCY45AQE4E6XVLJSQZ X-Message-ID-Hash: KPRJIDRAEVPXE2VCY45AQE4E6XVLJSQZ X-MailFrom: jch@irif.fr X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.9 Precedence: list Subject: [Galene] Keeping the developer honest: why native clients are important List-Id: =?utf-8?q?Gal=C3=A8ne_videoconferencing_server_discussion_list?= Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: 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=A4 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