From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mail.toke.dk; spf=pass (mailfrom) smtp.mailfrom=protonmail.com (client-ip=185.70.40.131; helo=mail-40131.protonmail.ch; envelope-from=jvanveen@protonmail.com; receiver=) Authentication-Results: mail.toke.dk; dkim=pass (2048-bit key; secure) header.d=protonmail.com header.i=@protonmail.com header.a=rsa-sha256 header.s=protonmail3 header.b=hwg7ikzq Received: from mail-40131.protonmail.ch (mail-40131.protonmail.ch [185.70.40.131]) by mail.toke.dk (Postfix) with ESMTPS id 924BD989FEF for ; Thu, 14 Jul 2022 07:42:09 +0200 (CEST) Date: Thu, 14 Jul 2022 05:41:59 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1657777328; x=1658036528; bh=vYyPC2pdjn7DaXPGtdvAK4yWKwbz9B8zyw1eoOFShf0=; h=Date:To:From:Reply-To:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID; b=hwg7ikzqr1vanY/tNxKfnEOclvAcz66ZHGYoRKGGy/8jbPCxp767vA6BMWQRDUeU5 F7cjaLO0hVjlcQOMCqnHhNisEMZnyTnJSbazG/3TzAqH59tzaWy9b+0HXhYoK9jDgf JhxZT4KCbPNTpA9KNm6c/gMRVB4JsjKvyX2XMo8NbVxpK3DTRV2E953ymVbPmJw1wf ICMVxJH8nuDudzaFL82E/ytfDCzACTY75Z3vnnedl3rVrD4IxzbbgBs4nN9/SN0hzv GVenJzVkpbYtgde/XdQSgx2m4yu3Mkg/tqhFIGn9FQBsE81mOtos5s56fTBAcSmOp+ riy7vsocS+GiQ== To: "galene@lists.galene.org" , Juliusz Chroboczek From: Jeroen van Veen Message-ID: In-Reply-To: References: <87edyp3pc5.wl-jch@irif.fr> Feedback-ID: 11782011:user:proton MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID-Hash: 4ZODHRMG23TXM6IVJHTFQIGSDSEZLWOW X-Message-ID-Hash: 4ZODHRMG23TXM6IVJHTFQIGSDSEZLWOW X-MailFrom: jvanveen@protonmail.com 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.5 Precedence: list Reply-To: Jeroen van Veen Subject: [Galene] Fw: Re: Versioning the Galene protocol 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 Juliusz, > 2. The protocol starts with an exchange of 'handshake' messages. I'm > going to add a field 'version' to the handshake messages, and if the > versions don't match, the connection fails. Sounds good! Additionally, it may be useful to have the protocol.js as a np= m package in the Galene repo with its own releases on npm. This would make it easier = for external Javascript projects to work with the protocol library. It would add some co= mplexity for Galene's own client, but an additional bundle step may not even be necessar= y when using es-modules. The current flow to use an updated protocol.js is to copy-paste it from the Galene repo into its own file locally, and then add an export to expose= the ServerConnection & Stream. Easy to do, but having a library with its own semver may make it easier to communicate major/minor/patch protocol changes= . > Since the client sends it handshake first, this means that the client > will need to commit to a single version, while the server will be able > to adapt its version depending on what was announced by the client. An > alternative would be to allow the client to announce a list of versions > that it supports -- is that useful? Why support multiple versions of the same protocol? Wouldn't that only comp= licate things at the Galene side? I don't mind personally to stick to a version of= the protocol, that was made to work with that particular version of Galene. > 3. If it is useful, we may add an "extensions" field to the handshake > message, in order to allow a peer to announce that it supports > extensions to the protocol, for example new group actions. > > Other than the versioning, I have only one change to make to the protocol > right now: I'm planning to require that the client request explicitly tha= t > it is interested in chat messages. (Currently, the client needs to > actively request media streams, but it has no way to state that it is not > interested in chat messages.) Would that be to be able to subscribe to certain kind of messages? (e.g. ch= at) Otherwise, I don't understand the use for it. Could you ellaborate? Would it be a problem to just be able to use newly added group actions in the protocol without explicitly having to mention that it's part of an extension? cheers, Jeroen > ------- Original Message ------- > Op woensdag 13 juli 2022 om 7:16 PM schreef Juliusz Chroboczek jch@irif.f= r: > > > > > Hi, > > > > Following R=C3=A9mi's issues, and since there are a number of third-par= ty > > clients for Gal=C3=A8ne slowly starty to emerge [1,2,3], I think the ti= me has > > come to add some versioning and extensibility to the Galene protocol. > > > > Now Galene uses three different protocols: > > > > 1. A very simple REST interface, that is used to populate the list of > > public groups and to discover group parameters before connecting. > > > > 2. A WebSocket based protocol, used for chat and audio/video codec > > negotiation. > > > > 3. The whole WebRTC protocol stack, which is used for transmitting audi= o > > and video. > > > > The protocol that needs versioning is the WebSocket-based protocol, num= ber > > (2) above. It is described here: > > > > https://galene.org/README.PROTOCOL.html#message-syntax > > > > I've given it some thought, and here are my plans. Please let me know i= f > > you think I'm missing something. > > > > 1. I'm going to ignore the built-in protocol negotiation of the WebSock= et > > transport, since I don't feel that version negotiation should be done > > at this layer. > > > > 2. The protocol starts with an exchange of 'handshake' messages. I'm > > going to add a field 'version' to the handshake messages, and if the > > versions don't match, the connection fails. > > > > Since the client sends it handshake first, this means that the client > > will need to commit to a single version, while the server will be able > > to adapt its version depending on what was announced by the client. An > > alternative would be to allow the client to announce a list of versions > > that it supports -- is that useful? > > > > 3. If it is useful, we may add an "extensions" field to the handshake > > message, in order to allow a peer to announce that it supports > > extensions to the protocol, for example new groupactions. > > > > Other than the versioning, I have only one change to make to the protoc= ol > > right now: I'm planning to require that the client request explicitly t= hat > > it is interested in chat messages. (Currently, the client needs to > > actively request media streams, but it has no way to state that it is n= ot > > interested in chat messages.) > > > > Comments welcome, none of this has been implemented yet, so it's easy t= o > > change. > > > > [1] https://github.com/garage44/pyrite > > [2] https://github.com/erdnaxe/galene-stream > > [3] https://github.com/igniterealtime/openfire-galene-plugin > > > > -- Juliusz > > _______________________________________________ > > Galene mailing list -- galene@lists.galene.org > > To unsubscribe send an email to galene-leave@lists.galene.org