On 5/15/24 18:48, Marvin W wrote: Good points. But from what I read RFB is not the same way as what is proposed here. The XEP as is defines a protocol that can send input to any target without needing graphical interface or video calls. It even says it allows an xmpp client to work as a keyboard for something else for example. lack them (e.g., single-board computers or IoT devices), and it establishes a framework that can be extended to share data (e.g., clipboard content). read the RFC of RFB that can't be done with that. see also in the design goals: has no screen at all. MSavoritias

On 5/15/24 20:35, Marvin W wrote: Yeah probably as is the scope it too broad. MSavoritias

Why is efficiency crucial when events are being produced at the rate a human can produce them? Do we have any examples of a XEP specifying a protocol yet? So far usually we reuse a protocol, such as RTP. No one is saying CBOR is bad in general, but I think if a new input-events-over-cbor-stream protocol is needed the XSF is not the place to specify it. Perhaps this could be called out more? If this is indeed a "direct mapping" to an existing protocol maybe the concerns about it being bespoke are moot.

Hi Goffi, See inline comments. Sorry for the wall of text and if it overlaps with one of the mails you wrote since I started writing this. On Mon, 2024-05-20 at 16:51 +0200, Goffi wrote: The cumulative amount is about 10-20%% [1]. This isn't really a huge improvement and almost all events will fit into a single network layer frame anyway, further reducing the impact of encoding size. Segmentation is also inherent to SCTP, the protocol webrtc data channels use to transfer content frames. There is no win in segmenting the same segments twice. Not untrue, but probably negligible given the resource use of IP, UDP, DTLS, SCTP - all part of the protocol stack you're building on and thus involved in every event to be processed. Especially DTLS encryption is going to be much more resource hungry than the difference between CBOR parser and JSON parser. And notable, CBOR encoding is not a native function in web browsers, so if web is a goal of this thing (and seemingly it is, given all the references to web tech in the XEP), CBOR is probably not much better than JSON. XEP-0247 Jingle XML streams doesn't need to go via the server, it uses Jingle just like your proposed protocol. While the XEP isn't maintained for some time and makes weird references to other XEPs, nothing in it forbids using it with webrtc data channels. In fact this has been discussed as a useful tool for all kinds of things recently (like initial device crypto setup or device-to-device MAM). And of course latency when sending via a server might be sub-perfect, but it's a very similar latency you would see if the network environment requires to use a TURN server, which is one of the ways to use Jingle. And as mentioned, there are valid use cases for having input in cases where low latency is not that crucial. Think of keyboard input to a remote shell - essentially what SSH does - which is not uncommon to be routed through proxies/tunnels that add latency. Of course for game input, drawing and 3d modeling, that's probably not an option. It depends a lot on the usecase and that's why flexibility is very much a good idea. Building something that is exclusively/primarily designed around having a web browser XMPP client connected via Jingle webrtc datachannels doesn't sound like flexibility was part of the design. Just as you can "directly" map data from JSON objects from a web browser to CBOR, you can directly map them to XML. It's not really a good idea to do such a direct mapping in both cases though (e.g. if you used enumerated keys in CBOR instead of a string map, you can drastically reduce the payload size and improve parsing speed). As I mentioned in another email: If you really feel like using RTP for screen content transfer, you can always decide to only use the RFB protocol (or something else) for the input part. I took it as an example for an existing protocol that (among other features) has logic for remote control input. Using RFB for screen transfer may be an adjacent topic, but not a requirement. Network traversal is on a completely different layer than the protocol to transfer screen content (RTP vs RFB). Nothing speaks against running the RFB protocol over webrtc datachannels. Running RFB over websockets in web browsers is also not well specified anywhere, but is still widely deployed [2]. Web APIs are designed around what browsers can reasonably do on the machines they run on. That doesn't mean they are well thought out for the generic purpose. I just played with the https://w3c.github.io/uievents/tools/key-event-viewer.html and it's still unclear to me when pressing modifier keys, which events are emitted when and what is the supposed state of the modifier flag for those events. I figured that the behavior is inconsistent between browsers (and probably operating systems) and also between different keys in the same browser. I bet this is not intended, but as the specification and MDN don't really tell me what the correct behavior would be, I can't really blame the browsers either. What I learned is that, as a web developer, you must be prepared to see modifier flags set without a keydown event being emitted for the pressing of the corresponding modifier key and also keyup events being emitted without a corresponding keydown event indicating the key was in fact pressed. So I definitely don't agree to the saying that it must be well- documented and well-thought-out just because it's coming from the Web... I'm not saying there aren't any cases where low-latency is important, where I disagree is that this is the case in all occasions. If you don't have low latency feedback from the remote device, low latency for input is very likely not crucial. Anyway, I remain not convinced that XSF is the place to specify a remote control protocol from scratch (which is what sections 8 and 9 of the XEP are about). Mostly because I feel the XSF does not have the competence for doing so (aka. we will probably do things terribly wrong, due to lack of experience in the field). That doesn't mean we don't need /something/ in XMPP to do the signaling for whatever is used to send remote control events. And using Jingle for this (be it using webrtc datachannels or any other Jingle transport) totally makes sense for low latency. -- There is a bunch of things I would suggest that are not related to this at all. Instead of `<device type="keyboard"/>` I would go with `<keyboard />`, allowing for attributes to be added for more information where there is fit (e.g. for a mouse have an optional buttons attribute with the number of buttons that are on the mouse, or for a gamepad, you might want to provide the layout, etc). This also means that to extend new devices outside this specification, one can just have a `<gamepad xmlns="urn:xmpp:remote-control:gamepad:0" />` or similar. As a general guideline, I feel attributes should only be used if the set of possible is finite. I would strongly opt to not make the use of datachannels a SHOULD in this protocol. It really doesn't matter for the purpose of this protocol and you don't want to need to upgrade this protocol if a new transport protocol becomes available that would be a better fit. Jingle does the abstraction to streaming vs datagram, so that application protocols don't need to deal with it. There is a lot of specification for interaction with the Jingle RTP and WebRTC protocols. This seems mostly unnecessary. - You already write in the requirements that everything should work even without Jingle RTP - You put that one MUST use the same "WebRTC session" (what is that even) for both Jingle RTP and Remote Control. I wouldn't know why this is. Of course using existing sessions in Jingle often makes sense (that's why it's a feature), but it definitely doesn't need a MUST here. - You write explicitly that Remote Control can be added with content- add to existing Jingle RTP sessions. This is already given by the Jingle specification, which doesn't limit what content can be added to a session (e.g. you can also add a file transfer to an existing call). - You say that touch devices should not be used when no video RTP session is active. I don't see why this shouldn't be possible. I do own a drawing tablet that doesn't have a screen but still is an absolute pointing device (aka "touch"). If that device was connected via XMPP, it wouldn't need a RTP session to transfer its input. - You say that absolute mouse events should not be used when no video RTP session is active. I also don't see why this restriction is in place - same as above. For both touch and mouse you use x and y coordinates "relative to the video stream". What does that mean? x and y are doubles, so are they supposed to be relative to the screen, so only values between 0 and 1 (inclusive) are valid? If x and y are absolute values in pixels, why are they doubles? If they are a pixel value, is it the pixels of the screen or the pixels of the video (as the video might use a lower resolution than the actual screen resolution)? I would suggest to go with relative values 0-1. If you want to use an absolute value in pixels, I suggest to make it screen pixels and somehow signal the screen pixels outside and independent of the RTP video resolution. Wheel events don't have a screen coordinate. I'm pretty sure they should have those, as the cursor position for the movement does matter a lot. If I understood correctly, you specify that a session is a screen share session by adding a remote control content without any device. This remote control content would thus effectively not be used, but still require setup of a data channel. This doesn't seem like a good protocol. The fact that a video is a screen share should be communicated outside this specification and this specification should not be involved at all in such a case (as it's not a remote control). A remote control without devices should be invalid. Marvin [1] https://gist.github.com/mar-v-in/003bedfcafb9e49a6ba6083ae374088b [2] https://github.com/novnc/noVNC/wiki/Projects-and-companies-using-noVNC

Hi Goffi, On Tue, 2024-05-21 at 12:47 +0200, Goffi wrote: Why do you rule that out? Because you don't see a purpose, when my whole point is that I do see a purpose? Of course I can send whatever CBOR/JSON you come up with as a base64 blob inside a <message> for my usecase, but then I wonder why not to handle it in first place. RFB definitely is old, so these kind of things are expected. And, while I see that you added clipboard as a potential future extension, it seems odd to complain that RFB has a suboptimal implementation of a feature your proposed XEP currently doesn't have at all. RFB isn't really hard to implement either. And ther are a ton of implementations out there already. I know that your specification doesn't transfer the modifier flags, probably assuming they are superfluous. However, if your browser client was to naively send the key events it receives as is without further checking for plausibility, things will go wrong: I tested pressing the keys that would logically result in the events meta down, control down, control up, meta up and here are the results on different browsers: https://imgur.com/a/zVxDAVa From what I understand, the state of keyup and keydown events in the web API doesn't need to be consistent (e.g. there can be keydown without keyup and vice-versa). Do we want the same behavior for this protocol or something else? I think you misunderstood my point. Using a smartphone as a touch pad or gamepad while playing a game on a screen next to you, is low latency feedback (you can see the screen with low latency). Example for where you don't need low latency would be when blindly typing into a remote shell, because you won't get feedback there (except after confirming a command which is probably not low latency). I was talking about the remote control protocol, which is what runs on the topmost layer (inside the webrtc datachannel or whatever other Jingle transport is used). This protocol is mostly from scratch (it's loosely based on web API events, but then only taking an arbitrarily picked subset of events and event properties) Which isn't an issue if web clients are not relevant for my usecase. And honestly, any kind of pointing to "you should support web clients" sounds weird to me. It certainly is interesting that we can support web clients, but really shouldn't siphon into unrelated specifications (and this one totally is unrelated to web). My point is: Either it's a Jingle session or it's not part of XMPP. Jingle doesn't use WebRTC. It just happens that WebRTC APIs are somewhat compatible to Jingle (because they are based on Jingle), but from XMPP perspective, you never have WebRTC sessions. I don't know exactly what it means to be in the same WebRTC session, but whatever you want here, make it more explicit, because people that don't use WebRTC APIs should not be required to first read the WebRTC specs (or probably implementations source code) to figure out what you mean by that. That's a problematic design. As I said, clients might scale the video to reduce bandwidth use. Dino also has logic to adjust the video resolution of cameras depending on available bandwidth. And as I understood for mouse, it's not relative to the screen, but relative to the previous position, aka a movement vector, like reported from touchpads. An screen relative position that is 0,0 is upper left corner, 0.5,0.5 is center of the screen and 1,1 is lower right corner, would work independent of the target screen resolution. Might work, but then you also need to cover the case where the screen resolution changes during remote control. The Web API uses double because they did weird things for HiDPI. On the hardware layer, there are only pixels and if you click on a point on the screen, it will always be on a pixel (at least in all OS that I am aware of). The transformation of HiDPI in browsers abstract away from actual pixels and 1px might be more or less than a physical pixel. But why would you want to carry this abstraction through the network to a system that shouldn't care about what browsers can do and what they think a pixel is? We also don't allow Jingle file transfers of no file or RTP contents without any codecs. As this protocol is for remote control, it should remain entirely unused for screen share only. To me the use of CBOR here feels not well motivated, except for obscure "better performance" reasons before having done any measurement to back that claim. From XMPP perspective, something in a Jingle XML stream would be more canonical (because it reuses the stack we already have in every XMPP client anyway) and anything diverting from that IMO should be well reasoned. If you're reasoning that CBOR provides significant performance gain over XML, then why is it not a priority to figure out how we use CBOR instead of XML everywhere in XMPP (e.g. by creating some XML<>CBOR translation and using that as an optional stream feature). I want to repeat that I haven't verified that RFB is particularly good fit for the purpose, I just know it's very popular. Best, Marvin

Hi Goffi, On Tue, 2024-05-21 at 18:04 +0200, Goffi wrote: The use case I'm thinking of has low throughput and only short usage time. I might be sending 10 or 20 key events within a short time and then nothing for several hours. Technically, this can all be done with Jingle, but for just a few keys, the overhead of starting a Jingle session just for those keys probably adds way more latency than sending those keys via <message> through an XMPP server. And using Jingle would require way more complex software on both sides. Without a proper specification to send keys, I would do this via non standardized body messages. Works, but isn't particularly nice. I also noticed that in cases where XEP-0174 Serverless Messaging is used, an additional Jingle connection probably doesn't add a lot of benefit either. Well, XMPP clients that also speak a ton of other protocols, including the one you are just creating. My point is that not only does this need to be specified in the business rules, but also a ton of other things. There are probably a lot of side cases that you don't cover and where I can't reasonably expect Council to think about them. There is no best way to do remote control (or precisely, input event sending). Low latency is a nice property to have and certainly doesn't hurt if it comes for free, but it doesn't come for free, it adds complexity, requires a multi-message setup phase and often the management of additional network sockets. And depending on the use case, it might be less important to have low latency than low complexity. The lowest complexity way to provide a streaming transport with Jingle is IBB and it still requires connection setup and is strictly worse than <message>'s for most purposes (except transporting of large binary blobs that exceed single stanza size limits). Both Jingle and especially WebRTC come with huge complexity. Your WebRTC library and your existing code for working with it might take away most of this from you, but that doesn't mean it's not there. By using Jingle and WebRTC you're effectively excluding clients, devices and platforms that can't easily run libwebrtc or any other popular WebRTC implementation. I was already guessing it's not arbitrarily, but probably what made sense in your setup and for your usecase. However, not knowing any of that it *seems* arbitrary. The RemoteDesktop portal was clearly designed for remote desktop use cases, not other remote control cases. However, as you already mention that you designed the data sent around what is needed for the RemoteDesktop portal, why not send the information directly in a format that matches the design of RemoteDesktop portal, instead of a mix of Web API interfaces and RemoteDesktop portal? Also I noticed that the RemoteDesktop portal does not have a notion of an independent wheel, the mouse wheel is tied to the pointing device, why did you choose to not do it the same way? I also checked Wayland protocol and wheel axis events are tied to a wl_pointer as well - and as far as I know, apps do expect scroll wheel to be tied to a pointer so you know where to scroll. The precision on a double (64 bit floating point) remain the same, no matter if you scale [0,1] or [0,<screen-width>]. The precision is about 15 decimal digits which should be more than enough (you barely see screen coordinates with more than 4 decimal digits), even if you do calculations on them (which may result in a few bits of precision loss). Assuming you refer the FPS games, those "lock" the cursor position to the screen center, so they never have that issue. To correctly reproduce this behavior you need a back channel to the controlling app so it can know the cursor position and/or lock if it is changed on the controlled device. (Above might not be correct on all platforms.) Also I did not intend to say that you shouldn't support movement vectors (like touchpads), I was just saying that absolute pointing could be relative to screen size, so that you don't need to know the absolute screen size. The advantage of going down this rabbit hole is: a) We improve XMPP for other usecases b) You can specify this protocol using XML and use Jingle XML streams. As the CBOR<>XML translation will take care of creating the CBOR for you, you still get the CBOR for this protocol, but without the need to make it explicit. And in cases where people prefer to not use CBOR, they can still use this protocol, just with XML. It's a win-win for everyone (except that you as the specification author have more work). If going forward, you still want to specify your own payload/application protocol (that is, the CBOR thing that is transferred with the Jingle streaming transport), I'd like to ask you: - To evaluate if a XEP is the right place to specify such a protocol, of if it is more a generic thing that could well be used outside XMPP and maybe should also be specified elsewhere. - If you consider a XEP to be the right place and want to stick with your CBOR protocol, I'd like to ask you to split it into two parts: 1. the payload protocol (sections 8 and 9 of the proposal) and 2. The Jingle signaling protocol (sections 5 to 7 of your proposal). This way the protocol can be used and referenced easily for use outside of Jingle context. If you feel it's possible to transition to a <message> based approach, this can of course be a single XEP (that will barely have anything to do with Jingle except for anecdotal mentioning that it can be used with Jingle XML stream or serverless messaging for lower latency). Best, Marvin

Le lundi 27 mai 2024, 10:54:25 UTC+2 Goffi a écrit : instance. Correction here, after testing (I should have done it before posting :) ), it seems that I'm actually wrong, on my KDE instance it's not the focus but the pointer position which matters for the wheel. That doesn't invalidate my other points though.

Hi Marvin, Le lundi 27 mai 2024, 12:29:36 UTC+2 Marvin W a écrit : Specifying an external protocol is basically specifying the payload format, and specifying it inside the XEP is the same thing. In some case it's better to use external ones, in other cases it's relevant or even better to specify directly the payload. That said, I'm not saying that my proposal is the best option. I'll evaluate other protocols to see if there is a good match. It's not the same hurdle to create another specification: it requires additional time and energy (and writing this one already took a lot). For a simple and small protocol like the one I've proposed, I really think it's not worth it (given my limited available time, as I'm working extensively on many things). The necessary work is definitely higher for a RFC, and I'm not even sure where to start. For a bigger and more complex protocol, it would definitely make sense yes, but I don't think that it's the case here. We lose all the interest of having a jingle application here. Jingle XML Streams is a Jingle Application, so if I use that, Remote Control can't be one anymore. We then don't have the possibility anymore to add remote control during a call session, or to indicate the intent. We first need to establish the XML stream, then find another protocol to advertise the remote control session. If we talk about remote desktop, we need Jingle for the video stream anyway. I've taken the IM example because it's the more common, but it works with A/V Calling compliance too. I think that Jingle is a major feature that is reasonable to ask as a prerequisite for remote control, it's the only "advanced" feature necessary. Many XEP do that already, or are assuming, e.g., that XEP-0045 is implemented, should we get rid of those because an "advanced" feature is required? This topic worth discussion, and has been spanned on another thread, so I won't continue here. If you are working on restricted devices, you can have a "host" device and only establish the stream connection with the controlled device. But anyway, one hand people say that my proposal is too flexible, and on the other hand we say that we should handle any niche case under the sun. In the vast majority of case, a streaming Jingle connection should be relatively easy to establish. That's true for absolute pointing, that's why there are relative methods, and my specification says to use relative ones when there is no attached video stream. That doesn't change the fact that Remote Desktop portal is designed to work even if there is no ScreenCast. That's true for freedesktop API, but that's an implementation detail, nothing prevent to have dedicated permission. Both web API and desktop portal use separate events for the wheel, I've just followed that. Sure that could be nice, but I definitely don't have time to work on this in the foreseeable future. I have done implementation that's true, but I'm not an expert in remote desktop implementation either. I'm listening to feedback and comment, and will take them into account. I disagree with you and Singpolyma about the wire format description for the stream, and don't see the problem to have such a simple and small protocol described in the same specification. However, I'll explore alternative and see if there are better options. So to summarize: - I'll explore alternative, notably RFB (or any other suggestion if somebody has a good proposition). But only for remote control, I want by design to keep the desktop screen sharing separated, and under XEP-0167 (or any future specialised XEP if proven better). - If I can't find a good alternative, I'll evaluate the use of <message> instead of current CBOR based data, maybe in a separated XEP. - I'll evaluate the use of a protocol usable via server or Jingle XML Stream. But I'm currently really not convinced by that due to the reason exposed above and previously. However, I won't have time to work on that before months, I'm currently very busy with other things. If anybody is interested in implementing remote control meanwhile, please contact me. Thanks again for your time and extended explanation of your point of view. Even if I disagree on some parts, I'm listening and many points are sensible. Best, Goffi

On Mon, 27 May 2024 14:07:49 +0100 Dave Cridland &lt;dave(a)cridland.net&gt; wrote: This seems to also hint at a wider discussion on the XEP process that has been brought up here and there. One example recently with many xeps being in experimental while they are reccomended in the compliance suite and moving them all to stable which as far as I have seen basically means that changes are rare to happen and its encouraged to fork the xep instead. I also have heard that Experimental is supposed to meet some kind of bare minimmum but as we can see here or with XEPs like xhtml this is certainly not the case. I have heard of more cases but these are the ones coming to me now. My thoughts as I have said before and I think it was proposed somewhere would be: - Experimental XEPs shouldnt get a number. Like ietf does. This means no more "pollution" of the xep number space with random xeps that went nowhere. - Council should move to voting only to move to stable. Where xeps get a number and there is a certain bar to be passed for the XEP to be accepted. - We should be much more open to change Stable xeps in the sense of upgarding them to later versions instead of adding even more xep numbers to look for. case in point the horrible muc avatar situation right now. All this would mean that we can remove at least 4 states for XEPs to be in with a quick look. Which the states seem to be 11 now for some reason. MSavoritias

Hi, On Sun, 2024-06-02 at 20:30 +0200, Florian Schmaus wrote: I generally agree. However there has been cases, where a ProtoXEP is submitted without prior interaction was the community and then within the first feedback it is found that there is overlap in functionality with another XEP and that there is a good possibility to make them cooperate instead of compete. Often even the author agrees and is willing to do the adjustment, but changes to ProtoXEPs during the Council review phase are not encouraged (because they reset the voting). Competition might be purely accidental and we should filter those cases *before* they go Experimental (because Experimental is what people implement). I think we might want to have a "scribble" space, where people just dump ideas that certainly don't qualify as Experimental (e.g. because it's just examples). This should be super low barrier (and going through the git certainly is not) and allow for easy sharing of such ideas for very early feedback. In a perfect world, that would be an online tool where you can create and edit your own scribbles (using probably markdown) and make "edit suggestions" to those of others (that they can review and decide to merge or reject). Not sure if something like this exists, I am just daydreaming :) I think Experimental became a high bar not because of the Council, but because the processes don't match what people like to use during their early development and prototyping phase. However this is the phase where feedback is easiest incorporated. Marvin

On 6/2/24 12:30 PM, Florian Schmaus wrote: Once again I would like to suggest that we make it easier to publish experimental XEPs (basically first come, first served à la Internet-Drafts at the IETF). This was our policy in the early days of the JSF/XSF, until the Council decided that it needed to exercise more control or, if you prefer, provide more wise oversight. XEP numbers are cheap and I don't see why we can't rapidly iterate and innovate within the XEP space (consider that XEP-0045 went through 30 versions over ~60 days in 2002 before being advanced to Draft). If that ship has sailed because we now have convinced ourselves that XEP numbers have deep significance, then by all means let's provide an XSF place for ProtoXEPs. But we should recognize that the same urge to control things will rear its head eventually, and then we'll have a discussion about an XSF place for ProtoProtoXEPs. It's "proto" all the way down! Peter

Le dimanche 2 juin 2024, 22:43:27 UTC+2 Peter Saint-Andre a écrit : I completely agree with this. I don't think that creating another status or location for proto-proto-XEPs would be beneficial, as it would only add more confusion. We already have /inbox for this purpose. I want to add that rejecting a proto-XEP can be highly discouraging for contributors, especially first-time contributors who may feel that their work was for nothing (just to be clear: this is not my experience with the proto- XEP submission that sparked this discussion; but I have been in the XMPP community for over 15 years and have submitted several specifications before, so my perspective may be different from that of newcomers). I suggest that we clearly state somewhere (such as in a "write a proto-XEP" document) that talking to the community before starting any work is highly recommended. However, this should not be mandatory, as people may be experimenting with ideas and specifying them at the same time. The "Experimental" state is there for the feedback, improvement, and update cycle, or even retraction. Council input is valuable, but except in cases where a proto-XEP is really flawed, it should not be blocking a move to "Experimental" in my opinion. However, requests for council input should be summarized so that XEP authors can update their work accordingly. Also, statements such as "I don't like" or "this specification is bad" are not helpful and may be disrespectful of the work done by authors. All feedback from experienced community members is valuable, and I see no reason why council feedback should matter more. We should not be afraid of namespace bumps in the "Experimental" stage. I have seen people argue against it several times, but I believe this is a mistake. The "Experimental" stage is for experimentation, and breaking things is a part of the deal. If people implement experimental specifications, they should be prepared to update regularly. Ultimately, the final decision on the relevance of a specification will be made by implementers and users. Best, Goffi

Le lundi 3 juin 2024, 12:37:21 UTC+2 Marvin W a écrit : Experimental is for the specification. Adding whatever status or workflow change you want will not prevent developers from implementing whatever they feel is relevant. People have been implementing things that were not official XEPs because they felt they were relevant, experimental or not (e.g. OTR, OMEMO). Some teams may choose to implement only stable specifications, others want to move fast. I'm in the latter case and I'm okay to refactor or even rewrite something entirely once experience is gained. And I think that both ways are perfectly fine. The "experimental" state is clear: it may change and break. "Stable" may not be desirable for a while. For instance, I've not requested a state change on purpose for submitted specifications such as "XEP-0356: Privileged Entity" because I knew that it would take time and experimentation, and moving to stable would prevent that. I've made important changes years after the original submission. Also, I was working on the only software using it at the beginning; now at least Slidge, a popular bridge, is using it, and its feedback may be valuable for updates before moving to stable. Once again, experimental is for that. Writing things down helps to clearly explain them and how we intend to do them. It's not a starting point for a feature, but it's definitely a good starting point for wider discussions. As I've mentioned above, experimental or not, whatever new workflow won't prevent developers from implementing an unstable feature if it is relevant to them. Experience has shown this to be the case more often than not. Relevant for some XEPs, but not all. Some time you don't want to move to draft on purpose, because you want to gain experiment, and feedback from others. You also need something written as a basis for discussion. My XEP-0356: Privileged Entity specification is an example. As long as it's not mandatory, it's surely a good thing to interact on something as early as possible. I personally like to have something written as a basis for discussions. It is already clearly stated. There is a red warning at the very beginning of the specification. If people chose to implement it, they have reason, and they know what they do. Specification is there for interoperability and explaining how things are done. XSF job is notably to build and maintain them, and help improvement through discussion and collaboration with the wider community. It's not the job of the XSF to say to developer how they should present features, and to tell them (beside current indicators) what to implement or not. Beside extreme cases, I'm also advocating for letting most if not all specification go to experimental. However, beside current warning, it's developers choice to use them in production. Best, Goffi

Le lundi 3 juin 2024, 14:58:23 UTC+2 Marvin W a écrit : Changes don't cause incompatibilities, we have namespaces to handle that. You can perfectly adapt to the change according to namespace. The issue is that people are afraid that other won't implement new things. My client implements both old and new OMEMO and adapts to the right version thanks to namespaces. Doing a new XEP would not have changed anything. People have implemented OMEMO because there was a need (and pressure from users and other IM solutions). Waiting for a new version years later would have only put XMPP in oblivion. Now, projects have to handle priorities, and the current version is working well enough that they handle the implementation when it makes sense to them. Also the "proper" new version is more difficult to implement, so it makes sense that it's done progressively. I totally disagree on that. Namespace bumps are not that expensive and should be used freely in experimental XEPs. But my position is known there, so there's no need to continue in circles forever. I would like to see other inputs. If they have done it before there should be an experimental XEP. My point is actually that experimental XEP should be easier to produce. And we may not all work the same way, but implementing, and writing specification can go in parallel to clarify and draft an idea. Then experimental is there for community feedback/update/experiment cycle. I've never said that. I've just said that the current situation, and I've actually said that it's not good. It's actually quite the opposite: my point is that I would like to make it easy to create a minimal specification, with enough information to be implementable. A Council vote would ensure that the minimal requirements for an implementation are there, and then the feedback, update, and experiment cycle can start. This would be far better than having to rely on specifications, code, and dump snippets scattered all over the web. Why is that? People can try to implement this version and give feedback on what is good, bad, or ugly, or even without implementing it. Why would it not be okay to update it based on experiments and feedback after a period of two months? Of course, the process would take longer: pre-announcement, explanation, waiting for feedback (how much? 24 hours? 2 weeks?), understanding feedback, explaining that the idea was not understood correctly, etc. Here, everybody knows that work is done on a specific topic when protoXEP is submitted, work has started, everybody can read the spec to see exactly what is it about and the vision of the author, and feedback. I don't says that pre-announcement is a bad thing, but it's clearly delaying everything and may actually make things more complicated. I don't see a problem that people do implement experimental feature, but if they consider it as stable, that means that they can't read big red warning (or just the warning and state, people may be colorblind). Not sure about others, but I do implement experimental feature, I do expect them to break, and I'm not worrying because there are namespaces. Actually, why do you even think that developers don't expect the XEP to change? "break" is not even the right word here because they don't break precisely because there are namespaces. Certainly not "publicly release and distribute software that uses it to a large userbase", who has said that? A first draft of a specification describing what is the idea, what is it used for, and how to implement it is certainly very much useful. Regarding the choice of implementing or not something, it's the job of developments teams, not of XSF. No, OMEMO was implemented due to need and pressure, and it's a good thing that it was done because it took years to have a good version. In the meantime, support for OMEMO has been advertised as a strength of XMPP in literature for years. It is absolutely possible to have old and new versions running in parallel (my client does it), and clients will eventually do so when the need arises. There are already several clients implementing OMEMO:2. So, clients that implemented OMEMO when it was just a web page outside of the XSF would no longer be considered "XMPP clients"? If you want to kill XMPP once and for all, that's probably the best way to do it. Best, Goffi

On Mon, 2024-06-03 at 18:29 +0300, MSavoritias wrote: Totally viable option. I would even go further with this (knowing it doesn't work exactly like this for some specifications): - An Experimental XEP is identified only by its namespace. Namespaces are cheap so we can give them out to everyone without any evaluation whatsoever. - When a XEP is turned into Stable, it gets a number. The primary identifier remains to be the namespace. - When we bump a namespace of a XEP it's effectively a new XEP (because the identifier is a new one) and thus goes to Experimental. It also looses it's number (or the number continues to refer to the previous namespace) but we remember what number it was derived from. - When a XEP goes to Stable that was derived from a XEP that had a number, we reassign the number to the newer XEP, so the XEP number is always referring to the latest stable version of that XEP. Thereby we allow for breaking changes through namespace bumps, won't shift through numbers and a XEP when identified by its namespace would never see incompatible changes after being moved to Stable, but when identified by its number it would always refer to the latest version. Problem is: People already have an understanding of the XEP numbering system, so we can't easily change that. If two implementations implement a Stable version of a XEP number, we currently expect those two to be able to talk with each other. A namespace bump would prevent that, so it would be good to at least keep the specification for the old namespace around as Deprecated. I really dislike how we currently in OMEMO have to refer to a specific Experimental version when talking about what the production software implements. Marvin

Hi, On Tue, 2024-06-04 at 11:10 +0200, Maxime Buquet wrote: Of course there are three kinds: (a) Those that consider the protocol ready for use in production software and thus use in production software (b) Those that consider the protocol not ready for use in production software, but don't care because they want the feature and don't want to fix the protocol before using it in production software (c) Those that consider the protocol not ready for use in production software, but need to implement it for compatibility with other production software, because of those in (a) or (b) I'd say that: (a) should just step up and make sure the protocol is turned stable, if it can't be turned to stable, they might even learn why the protocol is in fact not ready for use in production, so it's good for them if they try to move it further. (b) is just irresponsible behavior. Irresponsible towards your users (by shipping things to them you consider broken yourself) and towards the wider community (by requiring everyone to now deal with what is not ready for production in their production software). (c) is the worst that we have it, but impossible not to have as long as there is (a) and (b). I'd hope we can get rid of (a) and (c) through changes in the process and (b) by education. When I talk about production software, I'm referring to the server and clients that are used by thousands of end-users and that are therefor impossible to ensure are properly updated. And I'm talking exclusively about released production software (whatever that means for the project, aka what they suggest their end-users that want somewhat stable software to use). I never said Experimental is an issue. The problem is also not that people want features that are currently only available in Experimental. The problem is that we don't manage to move specifications from Experimental (or even before that) to Stable before they are so widespread that changes are hardly possible. If you can't experiment with it anymore (because it would break production software), then it shouldn't be in Experimental. I was referring to production software implementations, not implementations in test software, feature branches or other experimentation places. MAM should have been Stable for years before it was marked so that everyone has a basis they can develop on. Pidgin is right in saying they don't want to implement something that says "don't ship this to endusers" in it's header. It's just that many others decide to ignore that warning and therefor there is inconsistency in what's supposed to happen with Experimental XEPs. Not sure what you mean. I never said a single person should do a ton of work. I said that if a XEP becomes de-facto stable (because it has widespread production implementations and therefor can't be changed without causing compatibility issues) we should move it to stable. If there is still (backwards-compatible) work to be done for the XEP to be moved to stable and the author can't do it themselves, someone needs to act as a Document Sheppard as outlined in XEP-0001. The process is all defined, we just don't make use of it. I am wondering why you think it's good they use Experimental in production. Wouldn't it be better if the spec they need is in Stable? The list of items I provided obviously only goes if we do all of them: Move things to Stable faster so that developers don't need to use things from Experimental in production. End-users don't decide what is implemented. If end-users see that the message editing they have in their client stops working from one day to the other (because other clients updated to a new, incompatible revision), they will be unhappy. We previously have worked around this by implementing multiple revisions of the same XEP at the same time. And this is where I question the use of the word Experimental (and the warning to not implement it): We do actually consider those revisions to be somewhat Stable and take care of compatibility with them. It's what client and server developers already do today. We look at old revisions to figure out how something was done in previous revisions if it's needed for compatibility. So apparently that old revision is in fact stable enough for it to be used even after it is replaced by a new revision. There's two things that would have improved: a) We can reference and find the version being used due to the different XEP number b) We can tell people in the header that this is in fact ready for use in production as has been shown by a ton of people using it in production. Today XEP-0384 says it's unsuited for production in its header. It probably is not, but even if it is, that's only true for the latest revision. The older revision certain is fit for production. This is not about changing what people implement. This is about our process correctly reflecting what we do in practice. If you just want to rephrase of what Experimental means, we can also do that (making me wonder though what we will need Stable status for). Of course we can just adjust the wording in the header of Experimental XEPs to something like this: Extension Protocol does not imply approval of this proposal by the XMPP Standards Foundation. Experimental status does not imply any encouragement or discouragement to implementations or deployments in production systems. Older revisions of this proposal may be implemented widely, the current revision might be not implemented at all and may be replaced anytime with a newer revisions. Some implementations will consider compatibility with older revisions of this proposal when implementing it, others may not. See [here] for information about implementations in exiting software. With [here] being a link to the data we gathered from DoaP. In this case I would suggest to update the DoaP specification to not point to a single revision when talking about implementation status, but allow to point to multiple revisions (but maybe that's already possible, not sure). Marvin

Hi Goffi, Thanks for your message. I know I'm not particularly good with words and my language sometimes tends to be perceived as aggressive or exclusive. I did not intend to attack or insult anyone and I apologize if I did. On Tue, 2024-06-04 at 14:52 +0200, Goffi wrote: The people that *first* implemented and deployed OMEMO to a large number of end-users of the public XMPP network, before making a reasonable effort to stabilize the specification and to actually get the implementation itself to a stable state were in my opinion acting too careless. It's not always black and white, and to some degree the fault was and is often the XSF here, which is what this discussion was meant to be about: To adjust our XSF procedures to better reflect the need of the community. OMEMO was a mess, I think we all remember the days when half the messages on half of the devices would show up as "Message is OMEMO encrypted", even if their client was supposedly supporting some kind of OMEMO. Developers of clients were put on a public blame list for not implementing OMEMO fast enough. The reference for how things needed to work was not a specification, but a single implementation. And OMEMO still is a mess, next to nobody is implementing the latest revision, even though we know there are ways to upgrade that do not break anything. And those few that only implement the latest revision are totally screwed because their client is incompatible with what all others do, so they can't even do a lot of testing and are considered incompatible to OMEMO, even if technically it's everyone else that's incompatible. I sure hope we learn from this, "educate" ourselves and try to make sure it won't happen like that again. Marvin

On Tue, 04 Jun 2024 17:29:00 +0200 Marvin W &lt;xmpp(a)larma.de&gt; wrote: As a person who is using OMEMO that is still the case. Nothing has changed. I get OMEMO encryption problems regularly to the point that i am using it only if: - The person I am talking to has only one device - Owns/will own the device for a long time and the key will remain static - Is 1:1 conversation Everything else is doomed to fail and get the XMPP is bad reaction. MSavoritias PS. I am NOT saying this to get responses of "File bug reports" or "Work together to improve things", for multiple reasons. One of them being that in general the community seems to have given up on making OMEMO work.

Quoting Goffi &lt;goffi(a)goffi.org&gt;rg>: I like to add: It is an open sprint, so everybody is invited to work on whatever they like :-) Please, everyone, register yourself, if chances are ≥ 1 % that you come to Berlin: https://wiki.xmpp.org/web/Sprints/2024-07_Berlin#Attendees Cheers

Hi, On Tue, 2024-06-04 at 08:43 -0500, Stephen Paul Weber wrote: I think my point is that I don't have the feeling that this the case. With my developer hat, I for once do not generally expect that I will be forced anytime soon to do adjustments to the implementations of Experimental XEPs that are implemented in Dino. I obviously can't speak for others, but with OMEMO we certainly see that implementers are not generally aware that they should or are not willing to change to newer versions of it over time. Also, as some XEPs stay in Experimental for a long period of time, the people that originally implemented it somewhere might long have stopped working on it if an update happens years later - so there might just be nobody that can update the code for realizing a breaking change in some codebase. Marvin

On Wed, 5 Jun 2024 at 02:07, Peter Saint-Andre &lt;stpeter(a)stpeter.im&gt; wrote: Well, indeed. The question is, should their decisions be based solely on their own knowledge and ability, or should they based on a reading of community consensus, or some mixture? And if Council is acting at least to some degree as the enforcers of community consensus, then it ought to have the capability to enforce it outside of two cases (one of which it seems apparent we don't want). Lord Acton was only partly right - it doesn't inevitably corrupt, but it always produces a lot of waste heat. Dave