[Standards] Re: Bibliography and PubSub
Hi Schimon, can you tell use more about your end goal (end-user use-case)? Is it something for social sharing (e.g. I publish a book I'm reading, I want to allow comments, reactions, repeat, etc.) or is it something like having a collection of books/citation, etc? In the later case, you can have a look at XEP-0346: Form Discovery and Publishing, which is a way to share Data Form over Pubsub, I'm already using it to share various kind of things (TODO list, shopping list, tickets, merge requests), and I have plans for books too. It would actually great to have something usable with both, as both use cases are legitimate, in which case it could be describing the data to share and the fields to use in a Data Form, which could then be used either as attachment in a blog item (e.g. with XEP-0470), or directly with XEP-0346. Best, Goffi Le vendredi 7 juin 2024, 12:57:33 UTC+2 Schimon Jehudah a écrit : > Greetings, > > Pardon, I have made a mistake. Please see correction below. > > On Fri, 7 Jun 2024 13:44:08 +0300 > Schimon Jehudah wrote: > > > Greetings XSF! > > > > Thanks to Mr. Timothée Jaussoin (alias "edhelas") who is responsible > > for "XEP-0472: Pubsub Social Feed" I am interested and investigate > > about developing and utilizing XMPP PubSub. > > > > I am working on a couple of XMPP chat bots to which I will integrate > > support for PubSub. > > > > * Slixfeed (integrated) > > > > Slixfeed is a news bot of which PubSub support is almost done. > > > > It will use of affiliation='publisher' as defined in XEP-0060 to post > > news items to PubSub nodes https://git.xmpp-it.net/sch/Slixfeed > > > > * BukuBot (not yet integrated) > > > > BukuBot is a new chat bot which I contemplate on adding PubSub support > > in order to make link directories sharable, yet I do not think it > > would be wise to utilize node `urn:xmpp:links:0` for this purpose. > > > > I meant that I do not think it would be wise to utilize node > `urn:xmpp:microblog:0` for this purpose, and so I suggest to specify a > different node for this purpose; possible nodes would be: > > - urn:xmpp:bibliography:0 > - urn:xmpp:links:0 > - urn:xmpp:uris:0 > > > Because of this, I would like to discuss of a new XEP which probably > > would be similar to XEP-0277 and XEP-0472, yet it would be > > specifically aimed at bibliography management. > > > > Such XEP would be utilized to share Book and Scholar citations, URLs > > (Gemini, Gopher, HTTP, XMPP), and other type of references over XMPP > > PubSub. > > > > I would be thankful for you to help and share your thoughts on this > > matter. > > > > Kind regards, > > Schimon > > > > Regards, > Schimon > ___ > Standards mailing list -- standards@xmpp.org > To unsubscribe send an email to standards-le...@xmpp.org > signature.asc Description: This is a digitally signed message part. ___ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-le...@xmpp.org
[Standards] Re: Proposed XMPP Extension: Chat notification settings
Hi Nicolas, Le jeudi 6 juin 2024, 09:47:17 UTC+2 Nicolas Cedilnik a écrit : > What do you say if we allow context = 'mobile', 'desktop' or 'advanced', > with 'advanced' meaning that rules are defined as children of the > element, eg > > 9:00 > 17:00 > > type='super-subtle' /> > > > We could make that similar to bookmarks extensions in the sense that > clients MUST preserve what's in there, especially if they don't > understand the content? That could do it. My main concern is to let the door open for extensions, and describing that clients MUST preserve as you suggest seems OK to me. You should also specify what to do with unknown "" (do we "ignore" the notification rule? Do we just ignore the context?). Also with your system, we can't specify at the same time "desktop/mobile" and advanced. And I would like to say something like "notify me for my office chats on my mobile during working hours, otherwise silence them". I would actually put "mobile" and "desktop" in child elements of (or whatever name used for filtering. Also, if several rules are allowed, we have to manage conflict: what if I have something which tell me to notify me for a room on mobile, and just after something telling me the opposite? I suppose that the latter one must be used, but it should be specified. Best, Goffi signature.asc Description: This is a digitally signed message part. ___ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-le...@xmpp.org
[Standards] Re: Proposed XMPP Extension: Chat notification settings
Hi, Le mercredi 5 juin 2024, 14:15:21 UTC+2 Marvin W a écrit : > Hi, > > It's a great starting point. As additional input, here's a screenshot > from the notification settings screen in Slack: > https://imgur.com/i6O8GNO > It's probably on the upper end of features one could possibly need, but > I personally do enjoy having the different option for mobile devices. Indeed, and not only for mobile, one may want different kind of notifications depending on hours etc. I think this can be done with future XEP (e.g. to have notification rules filtered by the kind of device). Maybe this could be anticipated in this specification by allowing explicitly several elements? Also, it would be nice to have this working with pubsub, notably for blogging/ comments: it would be great to specify how we want to be notified when somebody mention you in a comment. But this is not about this protoXEP, it's about PEP native bookmarks which only accept so far. Anyway it's a good start, and it's simple which is good. Best, Goffi signature.asc Description: This is a digitally signed message part. ___ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-le...@xmpp.org
[Standards] Re: Council (and what it does, and what it should do)
Le mercredi 5 juin 2024, 08:50:09 UTC+2 MSavoritias a écrit : > 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. For the record, we'll have a meeting in Berlin next month (thanks to Debacle), to work exactly on that: interoperability issue with OMEMO (and A/V). For the wider community: please gather non working scenario, so we can work on them. Best, Goffi signature.asc Description: This is a digitally signed message part. ___ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-le...@xmpp.org
[Standards] Re: Council (and what it does, and what it should do)
Hi Marvin, Le mardi 4 juin 2024, 17:29:00 UTC+2 Marvin W a écrit : > 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. Thanks for your balanced reply. I'm not always diplomatic either :). Thing is, most of us are putting a lot of effort and passion into our work, often for many years. We may disagree on strategy, the way to do things, etc. This is perfectly fine and that's why we are discussing. But I trust the community to know well what it is doing, and even if we may disagree on the right way, I believe that dev teams know what they are doing. > 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. AFAIR there was also a specification on Conversations website from early days. I don't think that is was a mistake, I've already exposed my opinion, but there was pressure from the IM alternatives and the users too, and at the time only OTR was available, and only implemented by few (with problems as we know). If we had waited, for the "right" version which was done at 2021-10-07 (version 0.8.1), I'm pretty sure that the state of XMPP ecosystem would be worst that it is nowadays. First specification is from 2015-10-25, that 6 years! OMEMO has been quoted many times in literature. I believe that XMPP is still considered as a viable protocol for IM and more by many partly thanks to OMEMO. The "Message is OMEMO encrypted" thing was notably due to one client using it by default, which is the only case I remember of a breaking protocol thing, and has nothing to do with specifications. This thing put a lot of pressure on developers. I don't blame the dev which did that, it was done for a reason and it's totally understandable, and maybe a good move. Again, we have disco and namespace to handle various versions, if a client implement a new version, it's a choice to keep previous implementation for compatibility, and I believe most are doing that in critical cases In the case of OMEMO, I only know one client that implement OMEMO:2 and not the legacy one, and this client is young and took some radical decision; I'm not sure if it's still the case, but at one point they didn't wanted to implement XEP-0045, despite its "stable" status, and wanted to focus on MIX, so the specification status didn't change a thing here. I really think that we should separate "specification" work from "implementation" work (put aside the reference implementation thing): you can have a buggy implementation of a final specification, or incomplete, and an "experimental" specification can have a rock solid implementation (which can be updated if new version arise). Also, it's not necessarily a good thing to rush to put something to stable: feedback also come from end-user, and they may suggest an interesting change which could be done with, say, a new attribute or element with a namespace bump, which is easily done with an experimental XEP, but hard to impossible in stable or final. And there are many use cases where important things may not be anticipated at all by developers because they don't know specific fields. I'm thinking about accessibility for instance. Feedback from community from implementing clients is previous there. Trying to freeze as many specification as possible as soon as possible can be counterproductive. > > 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. It's a
[Standards] Re: Council (and what it does, and what it should do)
Le mardi 4 juin 2024, 12:18:34 UTC+2 Marvin W a écrit : > 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. > Though I usually appreciate your feedback, I find this particular comment especially pedantic and patronizing. You are aware that you say people who implemented OMEMO, for instance, were irresponsible and should be "educated", right? signature.asc Description: This is a digitally signed message part. ___ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-le...@xmpp.org
[Standards] Re: Council (and what it does, and what it should do)
k after a period of two months? > but I > would want to encourage both public pre-announcements and a place to > publicly scribble ideas. Of course writing things down properly helps > to find these things, but it also means that the process takes longer > and feedback and collaboration will only be possible at a later stage - > which can worst case mean more wasted energy and time, and we all don't > really have energy and time to waste. 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. > The problem is that people DO implement features based on Experimental > and consider this de-facto stable. That's why we do namespace version > bumps: because developers don't expect the XEP to break, otherwise it > would be no issue to change things in breaking way without namespace > version bump. Reality is: The big red warning doesn't change how people > see Experimental XEPs and claiming it bigger while not changing how we > actually treat it really isn't going to change it. 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. > Gaining experience and feedback from others and discuss doesn't require > to publicly release and distribute software that uses it to a large > userbase. Experimental is totally for these things: experimenting, > discussing, incorporating feedback. It's not for production, because > then you typically can't break anymore without terrible consequences. 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. > [SNIP] > > As explained above, reality shows that this is not the case. OMEMO > being a perfect example. We'll be stuck with a shitty version of it > probably for another decade because people implemented it into > production while it was pre-Experimental or still very much > Experimental. So I do disagree, people don't consider the consequences > of Experimental XEP because in practice, we consider Experimental XEPs > stable and will namespace bump instead of doing breaking changes, so > there are no compatibility issues. And clients tend to implement > multiple versions of Experimental XEPs for good interoperability. 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. > XSF can go as far and say "Client X is not compatible with XMPP as it > implements a protocol that is still Experimental". We do keep a list of > clients that "implement XMPP" so it is within the scope of the XSF to > decide what it means to be an XMPP client and requiring that only > stable specifications must be enabled in the default configuration of a > client to be considered an XMPP client is certainly valid. 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 signature.asc Description: This is a digitally signed message part. ___ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-le...@xmpp.org
[Standards] Re: Council (and what it does, and what it should do)
age the community to interact on XEPs early. > Essentially make it such that if you plan to work on a topic, you throw > a mail to the mailing list saying you're going to work on it so that > everyone knows and can share any insights they have in the topic. We > can also provide tooling to make this easier or refer to tooling > provided by third parties. 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. > > 3. We should more actively discourage release of functionality based on > ProtoXEP and Experimental XEPs in production (except hidden behind > feature flags or options clearly marked as experimental). 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. > 4. We should not have any bar for Experimental except for basics, > because Experimental means nobody should implement it in production, so > there is no harm in publishing it. 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 signature.asc Description: This is a digitally signed message part. ___ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-le...@xmpp.org
[Standards] Re: Council (and what it does, and what it should do)
Le dimanche 2 juin 2024, 22:43:27 UTC+2 Peter Saint-Andre a écrit : > 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! 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 signature.asc Description: This is a digitally signed message part. ___ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-le...@xmpp.org
[Standards] Re: Council (and what it does, and what it should do)
Le dimanche 2 juin 2024, 21:33:55 UTC+2 Marvin W a écrit : > 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. I'm not arguing in one direction or the other, just providing feedback based on my experience: for a couple of years, I've had to implement specifications that were entirely off the XSF circuit, but were really useful or de facto standards (e.g.: early OMEMO). This is terrible because you have to know about them or search for them, the website hosting them can be down at any time, and there is no standard workflow. This is currently the case for at least the following: - A way to encrypt XEP-0320 fingerprint for old OMEMO (https://gist.github.com/ iNPUTmice/aa4fc0aeea6ce5fb0e0fe04baca842cd), which is important for achieving real end-to-end encryption with clients that only support legacy OMEMO. - A new version of DataChannel signaling (XEP-0343), which I'm only aware of because I've discussed it on xsf@ (https://gist.github.com/iNPUTmice/ 6c56f3e948cca517c5fb129016d99e74). This is not even a specification, it's an XML dump. - XEP-0447: Stateless file sharing, where great improvements have been discussed for multi-files support and backward compatibility, but they are just discussions on xsf@ history so far. - Some interesting Auth mechanisms, notably OAuth on Ejabberd (https:// docs.ejabberd.im/developer/ejabberd-api/oauth/#ejabberd-listeners), and I think Prosody has also done work in this area. And probably others. Note that I'm not blaming anyone for this situation. I know how much work it is to write a XEP, even a small one, and everyone is busy. Most of this work is done on a volunteer basis. However, the result is a mess. It would be easier to have everything in a single place, even if it's not perfect or final (again, that's what the "Experimental" workflow is for). I'm also worried about implementing stuff based on snippets scattered around the internet, or missing super interesting features because they are not properly specified or I'm not aware of them. I'm not sure what the best solution for this is, but I wanted to provide my feedback. Best, Goffi signature.asc Description: This is a digitally signed message part. ___ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-le...@xmpp.org
[Standards] Re: Proposed XMPP Extension: Jingle Remote Control
ed on any platform, but > it might be that you can only do so using Jingle IBB (e.g. because your > network controller can only maintain a single TCP connection), in which > case using Jingle is really not an improvement. 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 incorrect. Despite its name, you can actually only use the > > Remote > > Desktop portal to send input; the Screen Sharing part is entirely > > optional > > (and must be explicitly requested). > > I'm pretty sure you can't send absolute pointing events (via > NotifyPointerMotionAbsolute like for a drawing tablet) or touch motion > events (via NotifyTouchMotion) using the RemoteDesktop portal without > also opening a screen cast, because the PipeWire stream node of the > screen cast is a parameter for those APIs. So while some events can be > sent wihout the Screen Sharing, it's not entirely optional. 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. > > As I've said in my previous message, the wheel device, while often > > associated > > with mice, can also be independent. > > The RemoteDesktop portal clearly ties it to the pointer device, it's > not only that the name is NotifyPointerAxis but you also must request a > POINTER device in the session (i.e. only requesting a KEYBOARD and > TOUCHSCREEN device does not allow you to use the API for scrolling). 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. > I know we have EXI and I know basically nobody implements it. It's very > complex, has a lot of features and for best results requires to agree > on a common set of XML schemas. Having something else than EXI that is > easier to implement really might be a good idea, because I doubt EXI is > going to ever be successful. Sure that could be nice, but I definitely don't have time to work on this in the foreseeable future. > So as a summary, for me the deal breaker really is the two protocols in > one XEP, one of which is not really an XMPP protocol. If you do like > the two protocols that you built - after all, you have implementation > experience that I entirely lack, so it may be that all my concerns are > invalid and I'm happy to have that in Experimental - I just feel that > the second one should best not be at the XSF and if there's really no > better place, make it at least a separate XEP. 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 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. > Marvin 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 signature.asc Description: This is a digitally signed message part. ___ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-le...@xmpp.org
[Standards] Re: Proposed XMPP Extension: Jingle Remote Control
Le lundi 27 mai 2024, 10:54:25 UTC+2 Goffi a écrit : > And that makes sense: it's not the pointer coordinate that's important, but > rather where the focus is. You can change focus with a keyboard, for 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. signature.asc Description: This is a digitally signed message part. ___ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-le...@xmpp.org
[Standards] Re: Proposed XMPP Extension: Jingle Remote Control
Le mercredi 22 mai 2024, 16:46:47 UTC+2 Marvin W a écrit : > Hi Goffi, Hi Marvin, Seeing the proposition rejected is definitely disappointing, and I would like to have a clear statement of the reason why the Council thinks this work is "unacceptable". For now, the biggest criticism I've seen is that this protocol specification is… specifying a protocol (which again is required by XEP-0166 for Jingle applications). This seems quite arbitrary to me, and I would like to have a clear statement on why this specification is "unacceptable" to the Council. Specially when I've clearly stated several times that I'm open to changing the payload format and using an existing protocol if they prove easy to implement, flexible, and efficient. The experimental state is made for that. Thanks in advance. > 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 through an > XMPP server. And using Jingle would require way more complex software > on both sides. Alright, I understand better now. That's true; because I have advanced features like Jingle and WebRTC implemented in my software, I'm willing to build on them, but they are not available everywhere. For ease of implementation, it could be indeed interesting to have an based way, usable either via server or via Jingle. On the other hand, this introduces complexity by itself (now the payload can go through two different ways), and I'm not sure that, especially for a niche feature that most clients won't implement, that we should use an inferior solution because hypothetically, in a niche use case within the niche feature, a client may not have Jingle implemented. Jingle is a major stack of XMPP, and it should be implemented in any advanced client according to IM compliance suites. WebRTC is already optional; you can use any streaming transport. > 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. That's another niche in the niche. That's really highly hypothetical, and even if this could be done directly, it doesn't hurt to add an additional Jingle connection. But that said, I'm not firmly opposed to moving to based payload, if that can unblock the situation. > 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. Of course, a proto-XEP is not meant to be perfect at first edition; that's exactly what the experimental status is for. And it's not the job of the Council to think about side cases - that's what standards@ and feedbacks from the whole community are for. Maybe I got it wrong, but for me, the job of the Council is to keep technical stuff on track by ensuring that advancements in XEP statuses are done in order (i.e., X independent implementations, Y feedbacks, etc. as stated in relevant XEPs), and vetoing things that are really unacceptable (e.g., copyright issues, something totally irrelevant, offensive content, etc.). And it's the role of the larger community on standard@ to work on technical stuff, side cases, ease of implementation, and optimization. I realize that there isn't a real definition of what should be an "acceptable" proto-XEP; maybe this should be specified? Because I've seen proto-XEPs refused by some Councils then accepted by others, and this seems quite arbitrary to me. > [SNIP] > > 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. Again WebRTC is not mandatory in my specification. Any streaming transport can be used, as designed by XEP-0166, including in-band via XEP-0261. So we're just talking about Jingle, and this can be implemented on any platform, which is required for advanced IM client according to current compliance suit. > I was already guessing it's not arbitrarily, but prob
[Standards] Re: Proposed XMPP Extension: Jingle Remote Control
Le mardi 21 mai 2024, 16:39:28 UTC+2 Marvin W a écrit : > Hi Goffi, > > On Tue, 2024-05-21 at 12:47 +0200, Goffi wrote: > > I know that, I've just ruled out using through the server > > as it has > > been proposed in another feedback. > > 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 for my > usecase, but then I wonder why not to handle it in first place. I missed that you had a particular use case in mind for using via the server. Could you please tell me more about this use case and why it isn't covered by Jingle transmission? Specifically, what is the advantage of sending through the server instead of handling it directly? I'd like to understand your perspective better. > [SNIP] > 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. That's just something that jump on eye after a quick check, if UTF-8 is not natively supported, I can see problems coming. But I'll check in more details anyway, as I've said before, I'm not against a protocol change if it makes sense. Regarding that it seems odd to you because clipboard sharing is not yet specified, that's simply anticipation. > > [SNIP] > > 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 That's the job of the controlling client to assure consistency. That may be specified in business rules though. > 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? The wire format comes from the web API, but we are not developing browsers, we are developing XMPP clients. > 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). And we come back to the point where I don't see the need to another way of sending input, when there is already a low latency one. I'm not saying that you are wrong, I'm saying that I don't see why we should have another mechanism, when there is already low latency way to send input data to any device. So please, provide me one or more use cases where the current specification is not valid and would not work, or work sub-optimally. At risk of repeating myself: I'm not closed-minded about changing protocols or designs, and I appreciate feedback from people with other experiences, but please provide clear examples of use cases where the current design is incorrect. > [SNIP] > > Again, it is not from scratch. It's re-using existing protocols, in a > > simple, > > working, easy-to-implement, and efficient way. > > 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) It's not arbitrarily at all, it's discarding data which don't make sense in this context, and it has been done while doing an implementation with Freedesktop remote control portal. > 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). I've already said that I'll reformulate to only make is a suggestion, without the "SHOULD". > [SNIP] > 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 (becaus
[Standards] Re: Proposed XMPP Extension: Jingle Remote Control
Hi Marvin, Le lundi 20 mai 2024, 22:48:42 UTC+2 Marvin W a écrit : > 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: > > There are many benefits to using CBOR: > > > [SNIP] > 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. > > [SNIP] > > 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. Note that while recommended, WebRTC Data Channel is not mandatory, and any streaming transport may be used. Your arguments are only valid for WebRTC Data Channels. > > > - Encoding and decoding CBOR are much more efficient, essential for > > quick and > > efficient data processing, especially by low-resource devices (like > > Arduinos). > > 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. Working with Web is a goal, but it should work of course outside web too (I currently have a web implementation for controlling device, and CLI ones for basic controlling device, and for controlled device). CBOR is not native, but there are many implementations available. Anyway, I'm not hard set on CBOR. If the consensus is to get rid of it, we can get rid of it. Regarding the choice of web, it's only because sending event, specially with keyboard, is hard to do well. There are many different way to encode depending on platforms, and various kind of keyboards with special characters. Web API is simple, documented, and abstract this complexity. The web has been around for 35 years, they have already gone through the rough patches. But again, I'm not against switching if there is something as simple and complete. > > [SNIP] > > XEP-0247 Jingle XML streams doesn't need to go via the server, it uses > Jingle just like your proposed protocol. I know that, I've just ruled out using through the server as it has been proposed in another feedback. > 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). In general I love the idea of XEP-0247 for many use cases. I just feel that XML is not adapted in this particular use case. > 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. TURN relay is a worst case scenario. And even then, it's more efficient because you don't have to wait for server queue handling, and processing. > 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. It is not designed around having a web browser at all! It's not because it's inspired by web API that it's the case, otherwise every HTTP upload is designed for web browser too. Fact is there has been and still is a enormous amount of engineering into web techs, and many good things have emerged from there, like WebRTC, WebSockets, WebAssembly, etc. And again, I have a non web implementation already (and a web one). Sure with ssh latency is less a problem (while still annoying), but the current mechanism works in all cases, is simple, and efficient. While adding complexity with another mechanism because "there are valid use cases for having input in cases where
[Standards] Re: Proposed XMPP Extension: Jingle Remote Control
Le lundi 20 mai 2024, 17:35:13 UTC+2 Stephen Paul Weber a écrit : > >- It is smaller. While individual pieces of data may be tiny, the > >cumulative amount is significant, and efficiency is crucial. > > Why is efficiency crucial when events are being produced at the rate a human > can produce them? What do you mean? It's not like humans are entering the data themselves. Input devices are used (most of the time) by humans, but that doesn't mean the data volume is small. With touch devices, you can quickly have several touch points with diameters, pressure, etc., moving around. You quickly accumulate dozens of events. Sure, compared to a video stream, that's minor, but it still needs to be processed quickly and efficiently. Lack of efficiency means latency, which can be annoying at best and problematic at worst (e.g., in games or precision tasks). And in general, when the cost of using an efficient solution is low, why not use it? > > >> If something over Jingle *is* desired, I'm a bit uncomfortable with > >> specifying bespoke binary protocols in XEPs. > > > >The whole point of Jingle applications is to specify the protocol. I'm not > >sure where the problem lies here. > > Do we have any examples of a XEP specifying a protocol yet? So far usually > we reuse a protocol, such as RTP. Well, most XEPs specify protocols. Regarding Jingle wire protocols, reusing another protocol is essentially specifying it. And we don't have many Jingle applications so far. XEP-0166 actually requires specifying how the data is to be sent and received (https://xmpp.org/extensions/xep-0166.html#conformance-apps). > > >Regarding direct XML streams, CBOR is still more efficient. > > 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. It's not a generic input-events over CBOR protocol; it's a specification to control devices via XMPP. This specification is useless without the XMPP and Jingle stack, and remote desktop use case reuses the existing stack. The wire format specified here is simple, efficient, and does the job. If using other standards for wire format is a bad thing, why do we have Socks5, WebRTC, HTTP, and so on used in XMPP? > > >Additionally, the protocol is based on web APIs, and CBOR provides a direct > >mapping. > > 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. It's not a 1:1 mapping of Web API because many data are useless or irrelevant in this specification. For instance, a Web `MouseEvent` has data such as `clientX`, `pageY`, and `relatedTarget`, which are not relevant in this case. Additionally, Web `MouseEvent` indicates key presses during the event, which are obtained through the `keyboard` device in the specification. Only the necessary data are kept. You are right that this should be explained in the specification. If the protoXEP is accepted, I'll add a section to explain that. I hope that I have helped to clarify things. Regards, Goffi signature.asc Description: This is a digitally signed message part. ___ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-le...@xmpp.org
[Standards] Re: Proposed XMPP Extension: Jingle Remote Control
Le mardi 14 mai 2024, 17:34:45 UTC+2 Daniel Gultsch a écrit : > The XMPP Extensions Editor has received a proposal for a new XEP. > > Title: Jingle Remote Control > Abstract: > This specification defines a way to remotely control a device using > local peripheral inputs. > > URL: https://xmpp.org/extensions/inbox/remote-control.html > > The Council will decide in the next two weeks whether to accept this > proposal as an official XEP. > ___ > Standards mailing list -- standards@xmpp.org > To unsubscribe send an email to standards-le...@xmpp.org > Hello, Sorry for the late reply; I was on vacation. Thank you for your feedback. I'll address your concerns below: > I'm unclear on the benefits of this CBOR-over-Jingle approach vs an XML-based > -based approach? Unlike audio/video this data is tiny and does not > benefit nearly as much from direct transmission or binary packing. There are many benefits to using CBOR: - It is smaller. While individual pieces of data may be tiny, the cumulative amount is significant, and efficiency is crucial. - Segmentation is inherent in CBOR, so you always know if you have all the data. This is beneficial for optimization and security. - Encoding and decoding CBOR are much more efficient, essential for quick and efficient data processing, especially by low-resource devices (like Arduinos). > If something over Jingle *is* desired, I'm a bit uncomfortable with > specifying bespoke binary protocols in XEPs. The whole point of Jingle applications is to specify the protocol. I'm not sure where the problem lies here. > - If we define a protocol for remote control, I would prefer this to be > a -based protocol that can be used either using a traditional > XMPP connection or via XEP-0247 Jingle XML Streams. Using server-based would be highly inefficient. Why send gamepad data to the server, incurring delays and extra processing, when you can send it directly from your local network? Add e2ee concerns (e.g. OMEMO override in size and processing), and you're wasting a lot of resources. Regarding direct XML streams, CBOR is still more efficient. Additionally, the protocol is based on web APIs, and CBOR provides a direct mapping. Using XML would require reinventing the wheel. > - Rather than defining our own protocol for remote control and using > traditional video conferencing tech for screen content transfer, I'd > prefer to reuse something like the RFB protocol (RFC 6143), aka. only > create a spec to define how to use RFB via Jingle. The protocol described here is for input sending and potentially other features like clipboard sharing, gamepad, and haptic feedback. In combination with existing specifications, one use case can be remote desktop. The goal is to reuse existing XMPP building blocks to simplify implementation. That’s what XMPP is for: coordinating specifications. We already have an A/V transmission protocol. With WebRTC, it's extremely efficient regarding latency and bandwidth. It’s suitable for remote desktop streaming, including robust network traversal mechanisms. Regarding mouse cursor hiding, I've considered it and will include it in a future version (my implementation does hide the cursor). And, as mentioned, the protocol comes from Web APIs because they are simple, well-documented, and provides a well-thought-out abstraction of the hardware. > In fact low latency, the main improvement of > Jingle vs inband, is only really required if you do have more or less > immediate feedback from the receiving device - e.g. when the screen > content is streamed. Low latency is crucial for inputs, especially for devices like gamepads, touchpads, and mice. Even with keyboards, low latency can be important, for instance, when playing a game. I've used this protocol to utilize my phone as a graphics tablet for MyPaint on my desktop: lot of events, and low latency very much needed. > And I bet as an IoT device developer you also want > to avoid the overhead of a Jingle+WebRTC stack if you can. For very low-resource IoT devices, a "parent" device could handle the XMPP work, with the stream established directly with the IoT device. I see XMPP in IoT as a “router” device managing XMPP and communicating with other devices on the local network using other protocols. But XMPP itself could certainly be used directly in many modern devices, potentially with some optimizations. I hope that I have answered all your feedback. Regards, Goffi signature.asc Description: This is a digitally signed message part. ___ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-le...@xmpp.org
[Standards] Re: Controlling XEP-0060 publish-options behaviour
Hi, Le mercredi 28 juin 2023, 14:54:27 CEST Matthew Wild a écrit : > In this scenario the client *is* the node owner. I'm not sure how we > can sensibly prevent someone from configuring a node they have > permission to configure. Right, the issue is when different clients do different things on user purpose. I think that a while (years) ago Edhelas got issues with Movim regarding client changing the `max-items` field on microblog node (from `max` to `1`), resulting in blog posts disappearing, that's why I've quoted this example in my last message. Anyway, maybe it's just pubsub implementation thing, and a more general `read- only` option to prevent accidental config change could be interesting. The current behaviour with 2 rounds config change is already overriding stuff anyway, so this question is probably out of topic for the change you're willing to make. Best, Goffi ___ Standards mailing list -- standards@xmpp.org Info: Unsubscribe: %(real_name)s-unsubscribe@%(host_name)s ___
[Standards] Re: Controlling XEP-0060 publish-options behaviour
Hi, Thank you Matthew for raising that. Regarding that XEP-0060 is stable, I don't think that a new argument is a good idea. I'm more in favor of any of the other options. If a client may ask for an override, it may be necessary to add a config option to forbid this behaviour. A node owner may have specified a value for a reason, and it would probably be bad UX to make it change transparently because some client thinks that it is better (I realise that this is what is currently happening with the 2 rounds trip, I'm just thinking out loud). Beside that, yeah, let's do some override, as long as nobody is deleting my blog posts by setting `max_item=1` instead of `max` this way. Best, Goffi Le mercredi 28 juin 2023, 13:26:02 CEST Matthew Wild a écrit : > Hi folks, > > Pubsub's is an important part of the protocol, e.g. > to ensure that private data stays private and isn't accidentally > published to a misconfigured node: > https://xmpp.org/extensions/xep-0060.html#publisher-publish-options > > When the configuration provided by the client in publish-options does > not match the node, XEP-0060 requires the service to reject the > publish with a 'precondition-not-met' error. This lets the client > decide how to proceed. > > My understanding is that most clients today will simply respond to > such an error with a configuration request, to set the node > configuration to what they expect. > > This has a few problems. It's possible that clients might fight over > configuration values (most likely to happen on non-essential options > such as max_items, where maybe one client sets it to 99 and > another sets it to 'max'). It's also inefficient, especially in the > case where publishes are frequent and two clients disagree over the > correct configuration of the node. > > I'd like to find a way to eliminate the round-trip introduced by the > precondition-not-met error, and allow clients to request that the > server simply overwrites the current configuration options with the > provided values in the case of a mismatch. > > This is theoretically easy to do, because if the server doesn't > support this it will simply return precondition-not-met and the client > can fall back to the traditional behaviour. My question therefore is > more about how we would want the syntax of this change to look. > > For example, we could introduce a new attribute on publish-options, e.g.: > > > [form here] > > > I suspect some may object to this without a namespace bump (which I'm > sure we all agree is out of the question). > > Or, we can add a new element: > > > behaviour="overwrite" /> > [form here] > > > Or, we could add this as a form field in some way. That could be as a > special-case field, or as an actual node configuration option (which > implies that we could set the default conflict behaviour on a per-node > basis). Note that the latter removes some control from the publishing > client, and potentially changes behaviour for existing clients that > didn't opt in to the new behaviour. > > Before I proceed, does anyone have any strong feelings about any of > this, or shall I close my eyes, pick one at random and PR? :) > > Regards, > Matthew > ___ > Standards mailing list -- standards@xmpp.org > Info: Unsubscribe: %(real_name)s-unsubscribe@%(host_name)s > ___ > ___ Standards mailing list -- standards@xmpp.org Info: Unsubscribe: %(real_name)s-unsubscribe@%(host_name)s ___
Re: [Standards] [XEP-0447] [XEP-0385] multiple files sharing + Highlander's "There Can Be Only One"
As the discussion happened on xfs@ MUC, I'm giving here an update for people interested. After a discussion on the topic, Marvin (larma, the author of XEP-0447) came with a nice solution to allow multiple files sharing + body text in the same message + backward compatibility: A first message is sent with all shared files + no restriction on the body (so a message can be sent at the same time), then optionally sources are sent again in separate messages, one per shared file, with backward compatible fallbacks. Client with latest version of XEP-0447 can ignore those later messages and only use the first one, while other clients will ignore the first one and handle files one by one as usual with later messages. This is IMHO an elegant solution to the problem that should satisfy everybody, and can lead to a deprecation of XEP-0385 so we can finally have a single XEP for attaching multiple files to (and pubsub). A new version of XEP-0447 is to be expected at some point with those changes. Regards, Goffi ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] [XEP-0447] [XEP-0385] multiple files sharing + Highlander's "There Can Be Only One"
About XEP-0477, I've always thought that the "The message MAY include a suitable fallback body. The fallback body MUST NOT include any information that is not also represented in . " was about not adding information *about the shared file(s)*, but it seems that I've misunderstood and it's preventing to have message in body at the same time as attachments. I see no good reason in that, and use should be possible to send message and attachment in the same stanza (also make gateway protocol translation doable without crazy stuff), thus I think that we should get rid of this restriction. Le mardi 21 mars 2023, 11:44:13 CET Goffi a écrit : > Hi, > > Libervia is currently implementing XEP-0447 instead of SIMS as it is supposed > to be a reiteration of XEP-0385. However, it can't currently handle multiple > files in the same message because of §3.3 "Attaching a source" which uses the > message ID (and thus we can only have one element per > ). > > This can be easily fixed by adding an 'id' attribute to element, > allowing multiple in a , and update §3.3 to use the new > 'id' and to make a child of . > > I think that multiple files in a single message should be part of XMPP, but I > also need it for my ActivityPub Gateway, and I guess that Slidge and other > gateways will have the same issue. > > An other point is that we should not have 2 XEPs doing nearly the same thing, > thus we should deprecate either XEP-0385 or XEP-0447. Here are some points > I've said on xsf@ room: > > - XEP-0385 depends on XEP-0372 (Reference), and while it may be nice to have > a reference, it should be optional (it should be possible to have files > available just as attachments). Also it's visible from the example, but not > clear at all in the description, XEP-0372 is not even quoted in the XEP. > > - file-metadata has been split to XEP-0447 with XEP-0447, and this was the > right thing to do instead of weirdly relying on Jingle FT stuff. > > - XEP-0447 has source attachment, which is a neat feature > > But all that could have been fixed directly on XEP-0385. > > Anyway, we have 2 really similar XEPs, please let's choose one right now > transfer the authors from the other one and deprecate the later, and move on. > > I personally want something usable both for and pubsub, and I like > the source attachment feature. Reference to a message is nice, but should be > optional IMO. > > I can make a PR in coming days, but which one should we chose? I propose to > move on XEP-0447, transfer author from XEP-0385 there, and deprecate XEP-0385. > > Thanks, > Goffi > > > ___ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > ___ > ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] [XEP-0447] [XEP-0385] multiple files sharing + Highlander's "There Can Be Only One"
Hi, Libervia is currently implementing XEP-0447 instead of SIMS as it is supposed to be a reiteration of XEP-0385. However, it can't currently handle multiple files in the same message because of §3.3 "Attaching a source" which uses the message ID (and thus we can only have one element per ). This can be easily fixed by adding an 'id' attribute to element, allowing multiple in a , and update §3.3 to use the new 'id' and to make a child of . I think that multiple files in a single message should be part of XMPP, but I also need it for my ActivityPub Gateway, and I guess that Slidge and other gateways will have the same issue. An other point is that we should not have 2 XEPs doing nearly the same thing, thus we should deprecate either XEP-0385 or XEP-0447. Here are some points I've said on xsf@ room: - XEP-0385 depends on XEP-0372 (Reference), and while it may be nice to have a reference, it should be optional (it should be possible to have files available just as attachments). Also it's visible from the example, but not clear at all in the description, XEP-0372 is not even quoted in the XEP. - file-metadata has been split to XEP-0447 with XEP-0447, and this was the right thing to do instead of weirdly relying on Jingle FT stuff. - XEP-0447 has source attachment, which is a neat feature But all that could have been fixed directly on XEP-0385. Anyway, we have 2 really similar XEPs, please let's choose one right now transfer the authors from the other one and deprecate the later, and move on. I personally want something usable both for and pubsub, and I like the source attachment feature. Reference to a message is nice, but should be optional IMO. I can make a PR in coming days, but which one should we chose? I propose to move on XEP-0447, transfer author from XEP-0385 there, and deprecate XEP-0385. Thanks, Goffi ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Pubsub Signing: OpenPGP Profile
Hi, Le mercredi 9 novembre 2022, 14:16:50 CET Paul Schaub a écrit : > Some more feedback: Some more replies > In "Signing a Pubsub Item With OpenPGP", you state that "Signing an item > with OpenPGP requires to have XEP-0373: OpenPGP for XMPP implemented to > handle keys, [...]". I would argue, that - although useful - XEP-0373 is > not strictly required as certificate distribution can also be done in > other ways, so I would personally remove this statement. Of course, this > may change once you describe the process of validating a signed item in > more detail (especially the process of discovering the certificate via > XEP-0373). I need to think about that, that's True that XEP-0373 should not be absolutely necessary. > It probably also makes sense to pin some of the signature parameters of > RFC4880 to fixed values, such as the Signature Type > (https://datatracker.ietf.org/doc/html/rfc4880#section-5.2.1). > I would suggest 0x00; Binary Document. Perhaps though, this should go > into XEP-0373 instead? Not sure about that, I guess this need discussion between people involved. For now the philosophy in our implementation is to let the library used (GPGME for now, we would like to use also Sequoia PGP at some point) make the decision. > Otherwise, for sake of completeness I would like to see a section on > signature verification, not sure if that is required to be able to > create an implementation :) For the record, I have already made an implementation in Libervia (along with OpenPGP for XMPP Pubsub, and Pubsub Target Encryption). Normally the current specification are complete enough. Goffi ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Pubsub Signing
Hi Paul, sorry I forgot to answer, I've got a lot on my minds these days… Le mercredi 9 novembre 2022, 14:01:27 CET Paul Schaub a écrit : > Hey! > > Thank you Goffi for creating this proposal. Cross-reading it, some > points come to mind: > > In the glossary under "signing profile" you write: "a specialisation of > this specification for a specific cryptographic algorithm." > I think instead of "cryptographic algorithm", a more generalized term > such as "cryptographic system" would be more suitable. For example, > OpenPGP as a message format supports all kinds of algorithms. Right, I'll change it on next update if it's accepted. > In "Overview", you write "To sign a pubsub item, the signature and the > signed data are separated.". Its not fully clear to me what that means. > Is this intended to handle the case where an additional signer signs > some already-signed item? Or does it mean that signature and data are > handled separately from another? the source item is not modified, and the signature is put in an attachment. To avoid wasting resources and duplicating the item, only the signature is used, and not the full element wrapped in an signature element like it is done in XEP-0373 > > Also, perhaps a bit nit-picky, "Overview" and "Signing a Pubsub Item" > begin with the same exact phrase. Yeah I may reformulate > > From "Wrapper Element (After Normalization)": "If the pubsub item is > encrypted, the signature MUST be done on the plain text version of the > item before the encryption of the item. The signature attachment SHOULD > be encrypted too.". > It is probably a good idea to add an additional sentence explaining that > adding a signature over plaintext outside of the encrypted data may leak > information (such as a hash) about the content of the encrypted data. > Maybe something for Security Considerations? Hum, maybe a MUST would be better here > > In "Rationales", you could add the use-case of signing-key rotation. I > could imagine a microblogging application where the user can rotate > their signing key. Attaching new signatures can be used to re-certify > old posts. I haven't thought about this use case. Would be good to indeed show a way to add several signatures from the same entity in case of key rotation. > The last paragraph of "Business Rules" is very long and confusing. "It is essential to use the same , , and signing profile extra elements in the element put in attachment and in wrapper element used for signed data, as it is necessary for receiving client to re-build the wrapper element and then validate the signature." => this one you mean? It essentially means that the elements must be in same order to be sure to validate the signature. Maybe I can reformulate, do you have any suggestion? > > In "Security Considerations": "Signature is intimely linked...", do you > perhaps mean "intimately"? Probably, French influence. > > Hope you may find some of my feedback useful :) Definitely, thanks! Goffi ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: PubSub Social Feed
Thanks for your message. I got it and it indeed a useful feature-but it needs to specified in XEP-0060. Kind Regards Goffi Le 5 novembre 2022 14:33:37 GMT+01:00, Maxime Buquet a écrit : >On 2022/11/02, Goffi wrote: >> 'pubsub#type' would be "http://www.w3.org/2005/Atom; in any case here, I >> don't >> see how you would use it to get comment nodes or gallery node. You would >> have >> to add an other metadata for that (which can be done). > >Just reacting to this because I feel this is largely misunderstood. > >No `pubsub#type` wouldn't be `http://www.w3.org/2005/Atom`. The whole >point of `pubsub#type` is to be able to distinguish the payload, which >isn't just Atom here, it's Atom, but used in a way to do >(micro)blogging. > >Tomorrow say I want to use pubsub/atom to send in my accounts and I use >the same Atom namespace, how do I distinguish with your blog articles? > >How do I have a UI/behaviour in my client/server that is different for >my accounts and my blog articles? > >`pubsub#type` is how we do this. By using `urn:xmpp:social:foo` and >`urn:xmpp:accounts:bar` I know of course that it's Atom, but I also know >what rules on top of Atom are being used (type of content, etc.) ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: PubSub Social Feed
Hi edhelas, thank you I understand your intentions better, and the title you chose makes more sense now (I didn't really see the point of XEP at first, now I get it). Let's see where it goes. Le mercredi 2 novembre 2022, 20:37:01 CET Timothée Jaussoin a écrit : > Atom fits perfectly and is super easy to handle when you want to inject > external feeds or transform a Pubsub node into a simple HTTP Atom 1.0 > url. In any case, even if the item contains XEP-0447 elements I'll still > declare those pictures as attachment to ensure proper Atom compatibility. That's the point, you need a http URL then. How would you do with files that need to be retrieved with jingle FT or other XMPP specific mechanisms? > > Regarding comment nodes, I think that to do it properly we should fix pubsub > > collections and put blog + comments nodes in the same collection. Using filters > > and prefixes for nodes is really ugly workaround, and we can end-up with > > comments node persisting while a parent blog has been deleted. > > Lets not over-engineer things there. > > I can hardly have proper support of Pubsub server side, even after years > of work. Asking to have those extra complexity is a perfect way to be > sure that I end up not having those feature before a few more years. That the reason why I've built a standalone, server independent Pubsub/PEP component (which does have support for collections BTW, even if I'm not using them yet). It's not over engineering to group a blog post and its comments or other linked nodes. The goal is to avoid "orphan" nodes, when you delete a parent blog node and the comments stays forever. But this can be done separately. > > However, 'pubsub#type' is not specified in XEP-0060 (only seen in examples), > > and it should get the namespace of the item payload, i.e."http:// www.w3.org/ 2005/Atom" in our case, so you should use (create?) an other metadata field to > > handle "profiles". > > No, we respecified pubsub#type exactly for this, because it was unclear. Well no, as of today (XEP-0060 v1.24.1), 'pubsub#type' is only cited in examples, and examples are not normative, so 'pubsub#type' is not specified. So it would be good then to add an appropriate section either in XEP-0060 or in a new XEPs to explain exactly what this field is supposed to do. So far, my understanding is that it is the expected payload type, i.e. the namespace of the first element, and it is primarily used for filtering nodes on disco request. > For 0277 I'd advise to define a pubsub#type that is actually > 'urn:xmpp:microblog:0' (there > https://xmpp.org/extensions/inbox/pubsub-social-feed.html#profile_microblog) > and not 'http://www.w3.org/2005/Atom' then I know that the node is > actually a bit more than "a Pubsub node with Atom items in it" and as a > client I can adapt my UI/UX to it. It makes sense, but it must be specified somewhere, and not lost in standard@ "advice" or in some random MUC. King Regards Goffi ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: PubSub Social Feed
Hi edhelas, thanks for your feedback Le mercredi 2 novembre 2022, 13:21:01 CET Timothée Jaussoin a écrit : > I think its still valuable in some cases, especially for compatibility > with external tools that wants to import/export Atom items also I'd > prefer to not break any compatibility with Atom. I agree about maintaining compatibility, as long as we are based on Atom, we have to keep this text version, even if it's using bandwidth for nothing. > > - what is this "Gallery profile" thing ? It looks like a terrible way to do > > photo galleries, ignoring all the work done by stuff like XEP-0447. Please, I > > see no good reason to have this. > > The goal is not to replace or have "two-standards". This Gallery profile > is a way to ensure that the node is having at least one attached picture > to all the items, allowing clients to display it using a specific layout > (a grid for example). This would allow to have Picture based social > feeds such as Instagram etc... I still don't think that it's a good way to do this: here images are just http links, while with XEP-0447 we can associate links and/or jingle and/or whatever with all metadata and thumbnails needed, and it's possible to add a way to link a blog post to images. > The goal of this XEP is to pose the bases of "what is a social feed" in > XMPP and the core of it relies on pubsub#type (I asked the support in > ejabberd there by the way > https://github.com/processone/ejabberd/issues/3914). > > The idea would be next to add a few more XEPs to define maybe other > pubsub#type from that one and to see how they can be handled > client/server side. For example we are thinking of adding pubsub#type > based filters in Pubsub services. That would allow clients to only get > the main article-nodes, comment-nodes, galleries-nodes etc... based on > their preferences and not retrieve everything and then filter client > side (it is one of the big performances issues that I have right now). 'pubsub#type' would be "http://www.w3.org/2005/Atom; in any case here, I don't see how you would use it to get comment nodes or gallery node. You would have to add an other metadata for that (which can be done). Regarding comment nodes, I think that to do it properly we should fix pubsub collections and put blog + comments nodes in the same collection. Using filters and prefixes for nodes is really ugly workaround, and we can end-up with comments node persisting while a parent blog has been deleted. > > Regarding the link with XEP-0447: Stateless file sharing I don't see why > can't be used with this XEP. I can try to adapt the > 'urn:xmpp:gallery:0' to gives the choice of the implementer on how he > would like to attach this mandatory picture per item (having two > examples, one with a '' and another one with > '' for example :) ). Then you would be mixing atom and XEPs material, it doesn't feel right. I believe that we need a proper protoXEP to handle photo galleries, probably something like XEP-0214 but with XEP-0447 payloads instead. I don't really like this gallery thing because it will set an ill-conceived precedent and when we come up with a proper photo gallery protoXEP, we'll end- up with 2 competing specifications (which is the plague of XMPP). > > Movim has been for more than 10 years in a weird state where I was > mostly based on 0277 with "hacks" to extend it outside this scope of > Microblog. Despite its name, XEP-0277 supports normal blogging and blogs outside of PEP out of the box, no need for a new XEP for that. > This XEP is a step ensuring that everything that is done is > fully standard and setting the bases of some future extensions in that area. what is done currently is standard XEP-0277. But whatever, I'm not against a new XEP with some extra stuff like node configuration etc. However, 'pubsub#type' is not specified in XEP-0060 (only seen in examples), and it should get the namespace of the item payload, i.e. "http://www.w3.org/ 2005/Atom" in our case, so you should use (create?) an other metadata field to handle "profiles". Also, your proposal is using verbatim stuff from XEP-0277, I believe that original XEP-0277 authors should be quoted somewhere inside your specification. King Regards Goffi ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: PubSub Social Feed
Hi, Le mercredi 26 octobre 2022, 16:45:10 CEST Daniel Gultsch a écrit : > > However in practice Microblogging was not applicable in more common cases and some related features were not used > > Citation needed. I’m inclined to trust the author on that but I'm > generally curious on how and when mirco blogging didn’t work and what > features were not used. I'm curious too actually, I've quickly read this new XEP, and I'm not exactly sure about its purpose and how it differs from XEP-0277, a section explaining clearly why a new XEP is necessary and the difference from XEP-0277 would be more than welcome. Some random comments: - I really doesn't like this marketing name "PubSub Social Feed", "Microblogging over XMPP" is not great either because classic blogging is doable too, but something like "Blogging" or "Atom over XMPP" would be more appropriate IMHO. I can live with this though - if we're about to define a new XEP, we should get rid of the mandatory text version when we publish XHTML (but that would make it incompatible RFC4287, however I think it's not the best choice for XMPP use case) - XHTML-IM should not be recommended IMHO, we need real XHTML fir blogging and also to be able to make proper gateways to other protocols. Security Consideration should give precise advice on how to sanitize the content instead. - I don't think that a html alternate link SHOULD be published, the protocol should not be related to HTML, HTML rendering is just what some clients do - "pubsub#access_model" should not be set to "presence" but to "open" IMO. For privacy reason, "presence" by default may be OK though, I'm not exactly sure what is the best option here. - what is this "Gallery profile" thing ? It looks like a terrible way to do photo galleries, ignoring all the work done by stuff like XEP-0447. Please, I see no good reason to have this. - style remark: quotes (notably in section 4.1) are not following XEP-0143 guidelines Regards Goffi ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Signing PubSub items (Proposed XMPP Extension: OpenPGP for XMPP Pubsub)
Le dimanche 16 octobre 2022, 16:44:07 CEST Martin a écrit : > > Title: OpenPGP for XMPP Pubsub > [...] > > Specifies an OpenPGP for XMPP (XEP-0373) profile for the pubsub use > > case. > > > > URL: https://xmpp.org/extensions/inbox/pubsub-encryption.html > > I hoped that the XEP would provide a way to sign blog posts or other > data, but it does not, at least not explicitely. > > Use case: Help to prevent things like "Twitter: Fake Elon Musk scam > spreads after accounts hacked" on Libervia or Movim. > > Is this out of scope? > > Cheers > > ¹ https://www.bbc.com/news/technology-46097853 (2018-11-05) > > (Reminder to myself: Fake Elon Musk on Libervia with his announcement, > he were up to buy Salut-à-toi. Sell my SàT shares, before people dare to > check the OpenPGP signature. Become rich.) Hi Debacle, I'm currently working on an other protoXEP that I should submit later today or tomorrow to handle the signing case, and it will support signing both plain text and e2ee items. There is a passage in security notice highlighting this. Cheers Goffi ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] The Editor intends to resign
Le mercredi 12 octobre 2022, 18:16:38 CEST Jonas Schäfer a écrit : > Hi there, > > TL;DR: As long as the editor job *requires* manual steps beyond commenting > and > clicking merge on GitHub [2], it's going to burn people out and I am > resigning > effective January 1st, 2023. > > [SNIP] > > best regards, > Jonas Hi Jonas, sorry to read about the difficulties that you have, which are totally understandable. I have no direct solution here unfortunately (being myself far too overwhelmed to take over this job), but I just wanted to thank you for what you have done so far and your responsiveness, it has been very much appreciated. Regards Goffi ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Events
Le vendredi 30 septembre 2022, 13:35:17 CEST Maxime Buquet a écrit : > Thanks Jonas! > > Thanks Goffi! > I have skimmed over the spec, and here are a few comments that shouldn't > pose any issue for the move to experimental. Hi Pep, > > > § 5. Events Nodes > > [..] > > Otherwise, a node may be published on any pubsub service. An events node > > SHOULD be prefixed with 'urn:xmpp:events:0/', which SHOULD be followed > > by an unique identifier. > > I suggest using XEP-0462[0] (PubSub Type Filtering) instead, as it's > exactly what it is here to do. Fill in `pubsub#type` with > `urn:xmpp:events:0` and use an opaque unique identifier as a node name. yes that make sense. I keep that in mind for a future update with other spec changes if the protoXEP is accepted, as it would mean a namespace bump. > > I would also argue this should be used for nodes on PEP, but I agree > advantages are less obvious when node name equals ns. we need a well-known node name in the case of PEP for the personal agenda (nothing prevent to have other agendas on PEP with different nodes though, e.g. professional meetings). > > § 6.4.1 > > If the online location is on an XMPP MUC, an element qualified by > > the 'jabber:x:conference' namespace as described in Direct MUC > > Invitations (XEP-0249) can be used. > > Shouldn't this “can” be a MAY or SHOULD instead? in case of a MUC. > I wonder how else the information that it is a MUC would be transmitted, > as I only see elements to describe HTTP addresses. yes indeed, a MUST seems more adapted. > I understand your main use-case is to convert from AP, which happens in > the HTTP world, but maybe there should be a way to add a URI instead of > just a URL? Actually I've been experimenting events even since before ActivityPub is a thing, the AP gateway and Mobilizon compatibility has just helped to validate the model. About URI, the proposal is actually using XEP-0103, do you think it's not sufficient? What else would you suggest? > > > § 6.5 > > The element MUST contain form as specified in Data Forms > > (XEP-0004) > > “a form”. It's obvious in the sentence below that it's a single form, > but this one is ambiguous. It's a typo, thanks > > > Example: Romeo Submit his RSVP Answer > > >urn:xmpp:events:rsvp:0 > > Contains an additional ">". typo again, thanks > > That's it. > Thanks a lot for the work on the AP gateway! Thanks for your interest and the feedback! King regards Goffi ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Events
Le vendredi 23 septembre 2022, 17:48:38 CEST Jonas Schäfer a écrit : > The XMPP Extensions Editor has received a proposal for a new XEP. > > Title: Events > Abstract: > This specification describe how to handle events with XMPP. > > URL: https://xmpp.org/extensions/inbox/events.html > > The Council will decide in the next two weeks whether to accept this > proposal as an official XEP. > ___ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > ___ > Hi, I've read council logs, and about the title, I was about to propose "Calendar Events" and I saw that Ge0rG did the same, thus if the protoXEP is accepted, I will modify the title accordingly. This protoXEP is the result of my own experience (I've implemented events with a custom protocols for years), and adaptation of metadata seen on ActivityPub (Mobilizon) as I've implemented an AP gateway handling events. About why iCal has not been used directly, here are the rationales: - iCal uses its own formats which is conflicting with XMPP. For instance, binaries are either using base64 encoding or URLs, when we already have things well suited for XMPP (stateless file sharing with XEP-0447). What if an attachment is available via Jingle FT (XEP-0234) for instance? For localisation we would have to parse iCal way when we already have XEP-0080. Same for datetimes with XEP-0082. In general, using iCal is re-doing many thing that we already have. - iCal is made for emails (even if it's independent of transport), and many URL must be "mailto" (e.g. organiser). Thus we would have to hack "it's iCal but we're not following the standard because we must adapt it to XMPP" - when XEP dependencies are already implemented, my proposal is super easy to implement. With an iCal format, you would end-up by looking for an iCal parser, with potential dragons there. - from my experience with blogging (XEP-0277, which uses Atom), it's not necessarily a good idea to re-use verbatim an existing protocol. You end-up doing hacks to adapt it to XMPP (XEP-0277 talks about XHTML-IM for instance, which is not even used in practice in existing implementations), weird stuff (when there is not title, content is put to title to match Atom constraints), and people using stuff not specified in the XEP in potentially different ways (for instance Movim is looking for the presence of an http "alternate" link to determine if it can use the post in its discovery feature, but that's not specified in the XEP). If I were to redesign XMPP blog, I would probably not use Atom. - iCal has its own (ugly) extension mechanism, with non-standard properties, while proper extension is one of the major strengths of XMPP. We should not end up in a state were each project add its own proprietary stuff and we have to check other codes to know what to do (that's what is happening in ActivityPub world due to loose specs, and I think that XMPP way is better). - there are external features that iCal handles like TODO or Alarm, and I have the feeling that those must be put in separated XEPs with proper disco advertising. Using iCal verbatim makes the thing more complicated. - my proposal is adapted to event organisation/sharing, iCal is only doing part of this. Heading picture is supported, RSVP takes profits of existing pubsub features (with automatic summary) and can be simply extended to ask for extra information (e.g. allergy information for dinner), invitee list are handled and uses pubsub permissions, comments can be added, as well as a blog. All those feature are not possible with iCal alone. - my proposal is not reinventing the wheel, quite the opposite actually: it's re-using existing XMPP feature instead of trying to adapt something else. - and last but not least, iCal metadata can actually be used, that's what the "extra data" (https://xmpp.org/extensions/inbox/events.html#extra) is for. We just need to map explicitly iCal metadata to the propose data form field type. Thus nothing is lost here Thanks for the feedbacks, and I hope that my points make sense to everybody. King regards Goffi ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Events
Hi Le vendredi 23 septembre 2022, 20:02:28 CEST Travis Burtrum a écrit : > I don't think we should be accepting XEPs without "Security Considerations" > being filled in. Any chance that could be done before voting starts? Last time that I've modified a protoXEP before voting I was criticised. Thus I'm not sure if it's good to do it before council vote, but if you ask me, I have nothing against it and can do it sure. Regards Goffi ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Clarify meaning of pubsub#item_expire: creation or modification?
Le 2021-09-17 11:29, Martin a écrit : Hi, this question came up when discussing the server side implementation of pubsub#item_expire: Is expiry relative to original creation or to last modification? It looks like both options can make sense, but in most cases, last modification is more useful, e.g. when a singleton node is updated or in case of redacted blog posts. Also, the standard already says, that re-publication were equivalent to modification: Note: If a publisher publishes an item with an Item ID and the ItemID matches that of an existing item, the pubsub service MUST NOT fail the publication but instead MUST overwrite the existing item and generate a new event notification (i.e., re-publication is equivalent to modification). To implement an absolute deadline of an item, the expiry time is not useful anyway, because it is a per node option, not a per item one. In such cases, the publisher should remove the node when time comes. In any case, the standard should clear about what is intended. Patch attached. Cheers, Martin ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___ Hi Martin, there is no notion of "modification" in XEP-0060: an item with an existing ID is overwritten by a new item with same ID, not modified. The notion of modification has been introduced in XEP-0413 (Order-By) that I've authored, because it's useful, but it's not part of XEP-0060. Thus, in the case of pubsub#item_expire, it can only reference the date of items creation (so if item A' with the same ID as item A is published, it's the date of A' creation which is used, and A doesn't exist anymore). Regards Goffi ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Renaming XEP "Draft" stage to "Stable"
Hi Le 2021-08-26 18:45, Matthew Wild a écrit : In practice a XEP only reaches "Draft" stage when it has a bunch of implementation experience, and Council believes it looks ready for broad adoption. I don't think (and checking XEP-0001 tends to confirm) that any implementation is needed to reach the draft state, I've already been surprised to see some XEP reaching this state with nearly no implementation in the wild. But this detail put aside, it's probably a good move, I've seen a couple of time people doing criticism on XMPP because "many XEPs are in Draft state", and indeed when you're not aware of the workflow, it seems like nearly nothing is usable (that's still true with many XEPs used widely which are in Experimental or Deferred state, but that's an other story). Thanks for taking care of this. Regards Goffi ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] [XEP-0060] removing exception for last item when doing a node purge
Hi Jonas Le 2021-08-18 17:16, Jonas Schäfer a écrit : The current idea is to put a note in the text like this into the document to help clients with servers which actually do the MAY thing: Note: Some service may preserve the last item despite the purge request. In such a case and if an entity needs to be certain that all items have been deleted, a query for the remaining items after a purge combined with a specific retraction request for the remaining items should be used. Any opinions? I'm not sure about this extra text, as it means that there is still a slight doubt if the item is remaining, and client has to do an extra and probably useless request each time. Regarding the lack of feedback I suppose that all implementation in the wild are removing all items, and if the PR is applied then letting 1 item should be reported as a bug IMO. Regards Goffi ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Disco Feature Attachment
Le 2021-08-11 17:35, Jonas Schäfer a écrit : Hi goffi, Thanks for proposing this. The council has today vetoed the advancement for this ProtoXEP to Experimental, but I'd like to give you some feedback because I think the problem you're trying to address is real. The bottom of this email contains two recommendations from me which may allow us to solve the underlying issue. [SNIP] Hi Jonas, thanks for the long explanation, and actually I agree with most of the arguments. It's not a problem that this proposal is rejected, all I want is to see this problem tackled and my main goal was to make things move (hopefully they are). I have not the time right now to work on new protoXEPs for disco items and RSM, or patches where necessary, so if somebody wants to jump in, please do. Otherwise I may propose something at a later time. Kind regards Goffi ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Disco Feature Attachment
Le 2021-08-09 02:08, Stephen Paul Weber a écrit : My main observation about this proposal is that it attaches meaning to otherwise-opaque var strings, and in general reads more like a hack than a solution. I am sympathetic to the need here, but I think we can solve it without resorting to this, and even still without needing to update caps. Disco and Caps already define a solid extensability mechanism as data forms to be included with the info. This proposal could perhaps look something like this: … urn:xmpp:feature-attachments http://jabber.org/protocol/rsm;> http://jabber.org/protoco/pubsub urn:xmpp:mam:2 http://jabber.org/protocol/disco#items … Thus anyone not implementing the XEP sees exactly what the do currently, caps will work unmodified, but anyone implementing the XEP can easily (and dare I say *more* easily) get the list of attached features to any given other feature. Hi Stephen, Thank you very much for your suggestion, I find your proposal far better than mine. My proposition was a working base for a problem I want to see solved, so if the protoXEP passes council (and if council member who have voted in favor of it are OK with it), I can publish a new version using this solution, and add you as an author. We have been discussing this suggestion and protoXEP in general on xsf@ MUC room (unfortunately, I would have rather seen the discussions happening here), and there were some useful arguments. As I remember, the main points were (I don't necessarily agree with all of them): - disco feature string should be opaque, and my proposal break this by doing a construction - added complexity: my proposal is more straightforward to implement (we just have to look as the attachment namespace to know if a feature is attached to an other one), while yours must be done in two steps - having a generic solution may bring non sense while attaching randomly to features (e.g. RSM on MUC) - it would be better to specify feature attachment directly on the concerned XEPs (e.g. directly on RSM or Order-By) In my opinion, your proposition is cleaner, takes elegantly profit of data forms/disco extensions, and doesn't feel like a hack. I don't think the extra complexity is a big problem. I also think a generic XEP is needed to have a common syntax, and to know if disco-feature attachment is implemented (otherwise we don't know for older XEPs if a announced feature is implemented for it or not, and some XEPs are in state which prevent namespace bumps). Furthermore, having a generic XEPs explaining the syntax doesn't prevent to mention it and to explain how exactly the feature is attached (e.g. what does it mean using Order-By with Pubsub, and how to use it). I would love to see feedbacks here, I think that the problem we are trying to solve is affecting a couple of XEPs and many people are concerned. Thanks Goffi ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Council Minutes 2021-07-21
Le 2021-07-28 17:24, Jonas Schäfer a écrit : 4a) Proposed XMPP Extension: Disco Feature Attachment URL: https://xmpp.org/extensions/inbox/disco-feature-attachment.html Abstract: This specification provides a way to get caching information from a Pubsub node Small confusion here, the abstract is not the right one: it's "This specification provides a way to indicate that a feature is implemented for a specific namespace". Thanks for the quick minutes even during summer. Goffi ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] [XEP-0060] removing exception for last item when doing a node purge
Hello, in XEP-0060 §8.5 (https://xmpp.org/extensions/xep-0060.html#owner-purge) it is said that: If a service persists published items, a node owner may want to purge the node of all published items (thus removing all items from the persistent store, **with the exception of the last published item, which MAY be cached**). (emphasis is from me). That means, apparently, that a service may or may not keep the last item. This uncertainty make the behavior unpredictable thus the caching impossible. I have provided a workaround in the currently discussed protoXEP "Pubsub Caching Hints" (cf. https://xmpp.org/extensions/inbox/pubsub-caching-hints.html#purge), but it would be better to get totally rid of this formulation, and make sure that a pubsub node purge remove **all** items. I've discussed about that on xsf@ muc, and at least on author of Pubsub XEP (Ralph Meijer) tends to agree. I've proposed a patch to fix that at https://github.com/xsf/xeps/pull/1096, but because the XEP is in Draft and I'm not one of the authors, this needs authors review and/or council approval. I'm posting here to have some feedback and see if XMPP community agrees to do this fix. Thanks Goffi ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Would it be possible to organize a regular review of PRs needing council/board decision?
Hello, I've been checking current Pull Requests on hold recently, and I see a large number of them are blocked by "Needs Author", "Needs Council" or "Needs Board", and I'm really interested in seeing some of them merged. I'm pretty sure that many of those PRs are just forgotten, and the longer they're forgotten, the harder it will be to merge them due to merge conflicts or other issues. Thus I'm proposing that the council and board do a review of all waiting PRs, something like once a month. Of course if may be tedious the first time, but hopefully the number of blocked PRs will shrink quickly. An other problem is that lot of PRs are blocked by "Needs Author", either because the author(s) forgot, or because they're not interested in the XMPP community anymore, or just disappeared. What is the policy in those cases, and can be unblock the currently concerned PRs? Thanks! Goffi ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Reverse ordering in XEP-0413 vs. XEP-0313's flipped pages
Le 2021-06-30 19:48, Holger Weiß a écrit : XEP-0413: Order-By allows for changing the order of items returned in PubSub or MAM responses. When results are returned as RSM (XEP-0059) pages, the question is whether the requested ordering affects (a) the order in which RSM pages are returned and/or (b) the ordering _within_ an individual RSM page. In the XSF discussion channel, Jérôme mentioned that both (a) and (b) should be affected. I think this needs clarification within the XEP. Also, the XEP currently states¹ that the | ordering can be reversed by using the mechanisms already provided by | Result Set Management (XEP-0059). This isn't true for the ordering _within_ an individual RSM page, XEP-0059 just allows for paging backwards. So, if this feature is desired, maybe a `reverse=true|false` attribute should be added to the tag, plus a statement how this interacts with RSM's and tags? And _if_ this functionality is added to XEP-0413, I guess the thing² could be removed from XEP-0313? Apart from that, I think it XEP-0413 should clarify how it also applies to RSM PubSub queries. Last not least, right now there's only a single disco#info feature for MAM and PubSub support.³ So if the server, for example, supports Order-By for MAM but not for PEP, this cannot be announced on the user JID. Holger ¹ https://xmpp.org/extensions/xep-0413.html#reverse ² https://xmpp.org/extensions/xep-0313.html#query-paging-flip ³ https://xmpp.org/extensions/xep-0413.html#disco I've just published a new version of the XEP (with a namespace bump), I think I've addressed all feedbacks (yours and older ones), I've added a full Pubusb with RSM example and some direction for SQL based implementations. Let me know if you're happy with it, thanks. Goffi ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Reverse ordering in XEP-0413 vs. XEP-0313's flipped pages
Hi Holger, Le 2021-06-30 19:48, Holger Weiß a écrit : XEP-0413: Order-By allows for changing the order of items returned in PubSub or MAM responses. When results are returned as RSM (XEP-0059) pages, the question is whether the requested ordering affects (a) the order in which RSM pages are returned and/or (b) the ordering _within_ an individual RSM page. In the XSF discussion channel, Jérôme mentioned that both (a) and (b) should be affected. I think this needs clarification within the XEP. Indeed, thanks for the feedback. I have a few other modifications to do for a while, I'll try to find time this week to publish a new version. Also, the XEP currently states¹ that the | ordering can be reversed by using the mechanisms already provided by | Result Set Management (XEP-0059). This isn't true for the ordering _within_ an individual RSM page, XEP-0059 just allows for paging backwards. So, if this feature is desired, maybe a `reverse=true|false` attribute should be added to the tag, plus a statement how this interacts with RSM's and tags? Yes this one was already mentioned in previous feedback (cf. https://mail.jabber.org/pipermail/standards/2019-January/035609.html ). Sorry I should have updated it for long. And _if_ this functionality is added to XEP-0413, I guess the thing² could be removed from XEP-0313? Apart from that, I think it XEP-0413 should clarify how it also applies to RSM PubSub queries. Last not least, right now there's only a single disco#info feature for MAM and PubSub support.³ So if the server, for example, supports Order-By for MAM but not for PEP, this cannot be announced on the user JID. Yes, probably the same trick as for RSM should be used (i.e. specifying order-by in pubsub like at https://xmpp.org/extensions/xep-0060.html#subscriber-retrieve-returnsome ) Thanks for the feedbacks, I'll try to update it this week. Goffi ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP Wishlist: Encrypted Information Storage
Le 2021-03-13 13:59, Paul Schaub a écrit : Hey everyone! It would be nice to have a way for clients to store end-to-end encrypted information on the server (imagine Private XML Storage or private PubSub nodes, but encrypted). As I heard that there are efforts of specifying ways to store signed data, I thought storage of encrypted data would come close enough to that to be discussed in the same breath. Since both signed and encrypted data would require some sort of asymmetric client/account key pair, we could define that as well? It would open the door to many very interesting use cases, one of them being a single identity key for end-to-end encryption. What do you think? Paul Hi Paul, I'll actually be working on e2ee encryption for Pubsub (including signing) this year thanks to a NLnet grant. I've only mentioned that on xsf@ and sat@ MUC rooms so far, but I'll soon publish a blog post with more details, and of course I'll reach standard@ in time to discuss that. And yeah, this will open the doors to many, many interesting things. Goffi ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Slummit 2021 - Tales
Hello,
I'll post a quick summary of what I've been working on lastly, you can
have
details and follow it on my (XMPP based) blog: https://www.goffi.org .
In a move to make the whole thing more understandable, the project
"Salut à
Toi", a multi-frontends XMPP client, is being renamed to "Libervia"
(which was
formerly the name of its web frontend only). Its various frontends have
their
own names which is confusing, so they will now have aliases:
libervia-web,
libervia-desktop, libervia-tui, etc.
The UI/UX are being improved a lot, and focus is put on web and
desktop/mobile
frontends. The goal is to have a one-in-all familial social network,
including chat of course, but also blog, forums, events, photo albums,
file
sharing, and lists (see below). Long term goal is also to add
calendar/agenda
and video conferencing.
For the needs of the project, a XMPP based tickets system is used for
years to
handle bugs and feature requests. This has been refactored to be a more
generic "lists management" feature, based on XEP-0346. This is useful
for
day to day life with things such as TODO list, shopping list, etc.
There is an easy invitation system to work with other people, even
outside
XMPP network.
I've worked on a file sharing component, supporting both jingle FT and
HTTP
Upload. Some major advantages here in comparison to most existing
solutions, is
that you can list, view and delete uploaded files from the file sharing
feature of Libervia, and you have no upload limit (I'm planning to add a
quota
system). It's currently based on XEP-0329 File Information Sharing, but
I plan
to move at some point to something Pubsub based to have notifications
when a
file is added/modified or deleted.
The Pubsub/PEP component I'm working on ("SàT Pubsub") does now handle
full-text search (XEP-0431). I believe that it's the most feature-rich
FOSS
Pubsub/PEP service at the moment, it offers MAM, RSM, FTS, experimental
feature such as fine permission tuning (per-item permission to do
something
like Diaspora aspect or Google circles, I plan to propose a protoXEP for
that
at some point), serial ids (to have IDs like 1, 2, 3 instead of random
ones,
notably useful for tickets), etc.
The goal of this side project is to have a feature-full Pubsub/PEP
service
usable with any XMPP server (XEP-0355 Namespace Delegation and XEP-0356
Privileged Entity are needed to have PEP support).
The CLI frontend of Libervia is as always being improved, it's now fully
documented (check "jp" on https://salut-a-toi.org/documentation, the
renaming
is not yet done), and I believe that it's a useful tool to have for any
XMPP
dev, admin, or even user.
That's it but there is more (see my blog for details). The project
website is
at https://salut-a-toi.org (the website will probably move to
libervia.org at
some point, but this address will still work). If you have any question,
I'm
available here ore on the MUC room s...@chat.jabberfr.org .
Goffi
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___
Re: [Standards] Announcing Slummit 2021
Hello, is this virtual summit still at thing? I see that it's supposed to happen this week-end, but I see no activity either here on on summit@ MUC room. I was willing to propose a short talk about what I've worked on lastly, and I can still do it if it's not too late, but I would like to be sure that it is still happening. Thanks! Goffi P.S.: this should be probably on summit@ mailing list, but the original thread was here. Le 2021-01-30 17:12, Tedd Sterr a écrit : Due to forseen circumstances, this will be postponed until 20-21 February. I was trying to fit it into what would have been the usual Summit time, but it was obviously a last minute idea and not really enough time for people to prepare anything worthwhile. Since there's no strict reason to keep with that time, I hope three weeks from now is adequate; 20-21 is also a weekend, which I hope is preferable. I was asked whether content should be aimed at members & devs only - I don't think there's any reason to limit it only to members, but I think it's safe to assume some familiarity with XMPP. A separate event for a wider, novice audience would be good for marketing, but this isn't it. If anybody wants help, advice, suggestions for content, or "would this be okay?" then I'll be available for discussion, brainstorming, and talking nonsense. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___ ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Announcing Slummit 2021
Le 2021-01-28 10:29, Dave Cridland a écrit : On Wed, 27 Jan 2021 at 22:11, Tedd Sterr wrote: In lieu of an official Summit, I invite all interested parties to participate in the unofficial Slummit! Reply in this thread with a few short paragraphs about what you've been working on, participating in, any projects you feel others should be made aware of, or anything XMPP-related that you think others would find interesting. Feel free to include a link to a longer, more detailed description elsewhere, but provide a digestible summary first. Great idea! I shall start writing one, and post it later. Additionally, if there's interest, I was considering organising a few voice/video call mini-conferences for groups of 3-7 people (larger groups become a communication burden), each focusing on a particular topic. (Dates 3-5 Feb, times according to participants' availability.) Can I suggest roadcast panel discussions instead? ie, lots of viewers, few speakers? Also are you going to participate, or just lurk in the background and write excellent minutes? Dave. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___ Hi, Maybe peertube (https://peer.tube/) could be used here ? I think it's doing live streaming now, and we can pre-record talks and have a questions sessions over a MUC room. Other option would be of course Jitsi Meet, depending of number of attendees. I can write also a paragraph about what I'm working on, and would be interested to do a short talk too. Regards Goffi ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] LAST CALL: XEP-0393 (Message Styling)
Le 2020-05-25 15:01, Tedd Sterr a écrit : But there is no way to know if the text is formatted or not, there is no marker, discovery, or anything to indicate that styling syntax is used. The assumption is that styling is always present and enabled, and so it's always applied to all text - We can't assume that, many clients don't implement that, because they predate the XEP, the devs don't want to implement, or they use case doesn't involve any need for that. if there happens to be no styling directives then there's no real harm done. yes there is harm, you don't know if "*something*" is styling or not. Not that support necessarily implies it is being used, and not for all messages. A simple '' might be useful? yes that's the idea. Not `styling=inline` because we don't use namespaced attributes and thus I don't think we can add an to , but something after the body like
Re: [Standards] LAST CALL: XEP-0393 (Message Styling)
Hello, Le 2020-05-12 21:35, Jonas Schäfer a écrit : This message constitutes notice of a Last Call for comments on XEP-0393. […] 1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol? no and yes. It was not necessary with XHTML-IM, but now that XEP-0071 has been deprecated, we need something for rich text formatting. 2. Does the specification solve the problem stated in the introduction and requirements? no, the requirements says: "Messages formatted using this specification MUST NOT hinder readability by users with color vision deficiency or impaired vision." while the section" Accessibility Considerations" says itself: "Formatted text may also be rendered poorly by screen readers. When applying formatting it may be desirable to include directives to exclude formatting characters from being read." But there is no way to know if the text is formatted or not, there is no marker, discovery, or anything to indicate that styling syntax is used. 3. Do you plan to implement this specification in your code? If not, why not? No, for the following reasons: - I don't want to implement something without proper discovery and flagging - I think this is a huge step back with accessibility - I don't like to mix wire format and meaningful text, but I could accommodate with that if there was something to properly mark the body as styled 4. Do you have any security concerns related to this specification? yes, it is not clear enough that formatting characters must be kept, and some clients may choose to hide them for aesthetic reasons. This, added to the fact that we can't know if a text is styled or not may lead to meaningful characters behind removed: as a result, several clients can display different things. This can be notably disastrous is a user copy/paste content such as code. §7 states "When applying formatting it may be desirable to include directives to exclude formatting characters from being read.", but how can we achieve this when we can't know if the body is styled or not? 5. Is the specification accurate and clearly written? 2 main concerns: - The §7 quoted above doesn't explain how to apply directives to exclude formatting characters - is it not clear enough that formatting characters MUST be kept Your feedback is appreciated! Thanks for the work done, but I'm really concerned with this specific extensions, and I think that a proper discovery/flagging mechanism would be the bare minimum to make it usable (but even with that, I'm more in favor of a proper separation of formatting and meaningful text). Regards Jérôme Poisson (Goffi) ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] LAST CALL: XEP-0423 (XMPP Compliance Suites 2020)
Hello, I'm really busy these days and couldn't do an extensive review, but here is my feedback: 1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol? Definitely, there is a high demand for this kind of list from users, and on the dev side it's really useful for newcomers to have a starting point and to know where to look at. 2. Does the specification solve the problem stated in the introduction and requirements? It's really chat focused, and I would like to see other categories, notably a "social" one. I would put there XEP-0277 as the bare minimum, and RSM for PubSub + MAM for Pubsub for advanced clients. Also I have the feeling that the XEP numbers support is not enough, as a XEP can be only partially supported (for instance, support for XEP-0060 is really different from one software to an other), so a more fine-grained indicator could be useful. On the other hand, it may over-complicate the compliance suit, so I'm just throwing the idea. I wonder also if it would make sense to announce a compliance support in disco, so a client could check a server compliance without having to check all XEPs namespaces individually. Why Jingle SOCKS5 Bytestreams Transport Method (XEP-0260) is missing from the list while XEP-0261 is there? 3. Do you plan to implement this specification in your code? If not, why not? For this specific XEP there is no notion of implementation, but I'm using it to have an idea of what I need to implement yes. 4. Do you have any security concerns related to this specification? no 5. Is the specification accurate and clearly written? the specification is clear. off-topic: As a side note, it would be useful to have the notes showed in hover tooltips in the rendered XEP, that would avoid to go down and up just to read them. I hope this will be useful Regards Goffi ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XMPP Compliance Badges, prototype feedback requested.
Le 2019-05-23 13:02, Guus der Kinderen a écrit : Hello, There's an effort under way to have developed visual badges associated to the XMPP Compliance Suites. To my knowledge, three variants of badges are under development: * https://op-co.de/tmp/xmpp-compliance-badges/ * https://bitbucket.org/mrtedd/compliance-badges/src * https://opensourcedesign.net/jobs/jobs/2019-03-19-design-of-badges-for-different-xmpp-compliance-levels We're looking for feedback on the visual quality and content of these prototypes. Anything that will help the authors to improve them, as well as for us to eventually choose between them, is highly appreciated. Hello, - I find the 1) (op-co.de) not clear enough: "core client" is a bit confusing for people who don't know the XMPP client. - the 2) (bitbucket.org) version is way more clear: we immediately see that's it's XMPP, the year, then the category passed - version 3) (opensourcedesign.net) is more beautiful and catchy: the 2 first ones looks like any badge while 3) can be recognized at first sight. I think we should see "XMPP" and year first, then the categories passed, in the same spirit as 2). Also this badge would be nice on a web page, but maybe not on top of a rendered README. So my favories are 2) and 3), and I wonder if we couldn't have both: 2) seems better for a documentation, while 3) seems better to put on a website. Other remarks: - will the badges be associated to the compliance tester? In this case should they link to it? And if we go further, could we have a list of all clients passing a test by clicking on a badge? - I know it's more a compliance suite issue than a badge issue, but we should really have a "social" category, with at least XEP-0277. It's a category that we are improving a lot, and a badge would help potential user to see which client support that. Too late for 2019 suite, but would be nice to think about it for 2020. Thanks for the work to all people involved. Regards Goffi ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Files encryption and OMEMO/OX
Le 2019-03-29 18:24, Jonas Schäfer a écrit : On Freitag, 22. März 2019 08:43:01 CET goffi wrote: Hello, about a year ago, Daniel's proposition to encrypt files with OMEMO has been rejected (proposal: https://xmpp.org/extensions/inbox/omemo-media-sharing.html, council rejection: https://mail.jabber.org/pipermail/standards/2018-June/035135.html). The rejection happened for reasons, but so far no counter proposal has been done. This is a real problem, as if we have a session e2e encrypted, user will expect that files are encrypted too. So I'm wondering what are the options (publishing omemo-media-sharing as historical XEP until we find better solution maybe?), and if anybody is working on some alternative (which would ideally work with OMEMO and OX)? Also note that at least Conversations and Gajim use this non standard aesgcm scheme, which is causing compatibility issues for other clients. There is a Jingle extension which allows encrypted file transfer, as far as I know: https://xmpp.org/extensions/xep-0396.html HTTP Upload is not the only file transfer mechanism. kind regards, Jonas Hey Jonas, thank for the feedback, yes I'm aware of this XEP (and I'm definitely not considering only HTTP Upload, I'm a Jingle advocate for long and have worked on a file sharing component based on it), but XEP-0396 only works in one2one synchronous file transfer (in other words it's the transport which is encrypted here, not the file). Currently e2ee is used in asynchronous chat and with group chats. So XEP-0396 is important and useful, but it's not the same use case as omemo-media-sharing. I'm currently at XMPP Sprint in Berlin, it seems most people are going to implement aesgcm. I'm a bit worrying that we start to have more and more stuff developed outside of standards. I'm suggesting that we propose omemo-media-sharing at least as an historical XEP, until someone comes with a better solution. Daniel what do you think about proposing it again as historical? Thanks Goffi ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Files encryption and OMEMO/OX
Hello, about a year ago, Daniel's proposition to encrypt files with OMEMO has been rejected (proposal: https://xmpp.org/extensions/inbox/omemo-media-sharing.html, council rejection: https://mail.jabber.org/pipermail/standards/2018-June/035135.html). The rejection happened for reasons, but so far no counter proposal has been done. This is a real problem, as if we have a session e2e encrypted, user will expect that files are encrypted too. So I'm wondering what are the options (publishing omemo-media-sharing as historical XEP until we find better solution maybe?), and if anybody is working on some alternative (which would ideally work with OMEMO and OX)? Also note that at least Conversations and Gajim use this non standard aesgcm scheme, which is causing compatibility issues for other clients. thanks Goffi ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XMPP Council Minutes 2019-01-16
Le vendredi 18 janvier 2019, 15:56:28 CET Georg Lukas a écrit : > > 4) Outstanding Votes > > One each for Georg and Link, on "Order-By" (expiring 2019-01-23). > > +1 > > My detail objections still exist, but these are not sufficient to reject > the acceptance of the XEP. The ML discussion has shown that this is a > hot and complex topic, and I'm interested in seeing how it develops. > > > > Georg Thanks. I've promised an update but I'm currently overwhelmed with FOSDEM preparation, so I'm postponning that to after FOSDEM. I'll try to address concerns then. Goffi ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Tidying Deferred
Le jeudi 17 janvier 2019, 12:43:02 CET Dave Cridland a écrit : > On Thu, 17 Jan 2019 at 10:38, Ralph Meijer wrote: > Our process should always match reality - and if Deferred merely means > "forgotten about", or "nobdoy cares", then any clear indication that the > community does care should cause it to move out. > > Dave. > In this case, could an author ask for a move back to experimental ? For instance by doing a PR to change the state ? Even if it's not the author it would be nice, there are a couple of Deferred XEPs I would like to see back to experimental (in the case of experimental means "nobody cares", otherwise I don't mind that XEPs are in Deferred state). Goffi ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Tidying Deferred
Hello, Le jeudi 17 janvier 2019, 09:55:17 CET Dave Cridland a écrit : > On Wed, 16 Jan 2019 at 20:48, Tedd Sterr wrote: > Three things leap out at me: > > 1) Is it worth "cleaning Deferred"? That is, is having 177 documents in > Deferred state a problem? > > 2) If it is, our current solution to move them to some terminal, dead state > is to Last Call and then Reject them: (Deferred -> Experimental -> Proposed > -> Rejected). Is that OK? Does the community want 177 Last Calls of > pointless documents? Can the Council do this unilaterally (if, of course, > we allowed this in XEP-0001)? > > 3) Finally, Tedd makes a very good point here in passing - the initial step > of skimming Deferred XEPs can be done by anyone in the community. While the > Council has to agree to put something into Last Call, anyone can request > that of the Council, as (in my guise as Council Chair) I'm happy to have > the Council vote on any Last Call as a general rule. > > Dave. > Note that some Deferred XEPs are actively used but either the authors are missing (that's more or less the case for XEP-0277 that Movim and SàT are using a lot), or the author wants time before moving (that's the case for 2 XEPs I've authored: XEP-0355 and XEP-0356: they are in a usable state, and I'm using them, but I plan to do changes on the long run and I feel it's too early to ask to move to draft). In the first case, maybe there should be a way to change/extend the authors after some time (for instance edhelas or me could work on the XEP-0277). For the later case, Deferred is a state that is OK for me, but I would not see the XEPs being killed (it's usable and used), I'm letting them in this state on purpose for the moment. ++ Goffi ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XMPP Council Minutes 2019-01-09
Hello, Le lundi 14 janvier 2019, 02:41:57 CET Tedd Sterr a écrit : > 3) Proposed XMPP Extension: Order-By - > https://xmpp.org/extensions/inbox/order-by.html > > Georg thinks it's a very specific use case, and defines two hard-coded > properties (creation and modification timestamp) for ordering on, whereas it > would be cleaner to allow ordering by any field. Jonas and Dave point out > that the properties are external to the items themselves. > Jonas wants to discuss further with the author about points already raised. > Georg wonders why the properties couldn't be embedded in the items - Jonas > say servers must not modify items; Georg suggests the client could add the > timestamps itself, but Jonas says the author dislikes this as it would allow > them to be spoofed. > Georg thinks it needs to be renamed to "PubSub MAM Retrieval Ordered by > Creation or Modification." > Dave noticed that it apples to MAM but doesn't really discuss it, and > presumably also has an impact on RSM. Jonas says it doesn't impact RSM, but > the server might have to use different identifiers in RSM to work correctly; > Dave thinks that's worth thinking about and mentioning. Kev says it does > interact with RSM, but 'impact' is a matter of interpretation. > Kev would like to see this have a little more work before being published, > but couldn't find a reason to veto. > > Jonas: [on-list] > Georg: [on-list] (with fallback to -1: very specific use case; requires > [implementation] changes to other XEPs) > Kev: +1 (not keen on it, but it clears the bar-of-incompetence for > Experimental) > Link: [on-list] (still catching up on everything) > Dave: +0 (reserve the right to change that while others are still on-list) For the record, I've answered to the concerns raised by the council at https://mail.jabber.org/pipermail/standards/2019-January/035646.html . I hope this helps. Thanks Goffi ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Order-By
Le dimanche 13 janvier 2019, 12:53:51 CET Evgeny a écrit : > On Sun, Jan 13, 2019 at 2:40 PM, Goffi wrote: > > Future XEPs may extend this, but in case where it's too complicated, > > implementation has always the choice to not implement it, or to have > > different features with different backends. > > I really don't see how this will work in practice. > 1) a client issues a request with "direction"/whatever attribute > 2) a server responds with "not-implemented" or some such > 3) a client gets stuck? or should it re-send a modified request? Well clients already have to manage different feature set. It's more: 1) client discover features of pubsub service 2) a) if server do ordering, fine, we do optimal workflow b) if server doesn't support ordering, we can either show items in the not optimal order (bad UX but it works), or show a warning of whatever. This is a client decision and probably depends of the context. It's already the case for nearly every XMPP feature. For instance most pubsub services don't currently support MAM filtering. If it's available, nice you can click on categories to see filtered items, else you can't do that. In the same spirit, if other client doesn't support video, or e2ee, or whatever, you have to adapt. > Second problem is that competition in servers is quite high > and if customers/users want the feature then I have to implement it > somehow. > That has happened in the past already. If there is a high demand for a feature, there is probably a real need. I don't find this is a good reason to not implement something, quite the opposite actually. > Third problem is assuming SQL-only backend to support the > feature is the wrong approach, in my opinion. This is not assuming SQL only backend at all. You can even implement quite easily this XEP with flat files backend, you just have to keep a list of items ids ordered by creation date, which is trivial to do. ++ Goffi ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Order-By
Le dimanche 13 janvier 2019, 12:28:09 CET Evgeny a écrit : > On Sun, Jan 13, 2019 at 2:16 PM, Goffi wrote: > > For Pubsub services based on SQL or NoSQL databases, it should not be > > too hard to implement as ordering is most of time a part of API. > > Note however, that some NoSQL databases only support a single index > in the query, DynamoDB is such an example. You can apply post-filtering > of course (kinda map-reduce, where filtering is "reduce"), but it may > become inefficient depending on the query subset. > > That's just a thing to consider if you want to go too broad in > your specification. > > ___ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > ___ > Thanks for the pointer. I'm not planning to complicate more the XEP than it is now, so it should not go broader. Future XEPs may extend this, but in case where it's too complicated, implementation has always the choice to not implement it, or to have different features with different backends. ++ Goffi ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Order-By
Le dimanche 13 janvier 2019, 12:24:45 CET Evgeny a écrit : > On Sun, Jan 13, 2019 at 2:16 PM, Goffi wrote: > > a XEP for XPATH like syntax > > And the server will process this XPATH query? > Not sure if you're serious... This is a future plan, not concerning the current proposal, and will be discussed at the time. I'm not thinking about a full XPath engine of course, that would be overkill, just an ultra-simplied syntax to link a specific element or attribute in a stanza or payload. But it's definitely too early to discuss that. ++ Goffi ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Order-By
Hello, I've read the council logs, I'll try to defend the protoXEP here (in addition to what has already been said in this thread). > it's a very specific use case, and it defines two hard-coded properties to > order by. A clean approach would allow ordering by any field of the items, > using some XSLT magic or something. ([16:04:52] ) It's not a niche case at all, it's a major feature for blogging, and many other experimental features I'm working on and hope to standartize in the not too distant future (like tickets handler, forums or events). It seems that at least Movim would be interested too (cf. message from edhelas at https://mail.jabber.org/pipermail/standards/2018-August/035316.html). In my opinion, it is an important missing feature at the moment. About the ordering on arbitrary field, this has been debated with Jonas already (cf. https://mail.jabber.org/pipermail/standards/2019-January/035642.html): it is a future plan but will complicate a lot (a XEP for XPATH like syntax, the issue with data type, and the fields which can be missing in items, to quote the most important issues). > this needs to be renamed "PubSub MAM retrieval ordered by creation or > modification" ([16:07:42] ) I'll make an update to restrict to Pubsub, this doesn't have really much use/sense for MAM with instant messaging. Beside that, the XEP already states that it is extensible, it's not a pubsub only thing. I think for instance that it would be really useful to get list of MUC rooms ordered by number of participants, or order of creation. > I did notice this applies to MAM, too, but doesn't disucss it, and presumably > has quite an impact on RSM, but doesn't mention that. ([16:07:49] ) As said above, I'll restrict MAM to pubsub only. RSM is not impacted (there is the ID which could be something else than item_id, as noticed by Jonas, but this is already a RSM thing, nothing new). I'll mention the RSM after/before ID thing in next update. > I wouldn't be unhappy to see this have more work on it before it's published > ([16:09:06] ) Sure this was a first draft, I'll try to find time to update it today or tomorrow. > my rationale is that it's only adressing a very specific use case, and > requires changes to multiple other XEPs, like PubSub (for storing metadata) > […] it implies changes to their implementation. ([16:09:46] and [16:10:36] > ) No other XEP is modified. About implementation changes, well most of XEPs imply implementation changes. For Pubsub services based on SQL or NoSQL databases, it should not be too hard to implement as ordering is most of time a part of API. For Pubsub services based on flat files (I think it's the case for Prosody), well the feature is not mandatory, and the doc can say that this feature needs an other backend. For the metadata, there is not much to do: - ordering by modification time as defined in the XEP is actually the current default ordering of Pubsub, so there is nothing to do - ordering by creation date needs to keep the date of first item with a specific ID. In practice, you can do that by copying the date (or uid or whatever you're using) on the new item when you have an ID conflict, before destroying the old item, nothing fancy. That's it, I hope I have convinced you. Anyway this is experimental, time will show where it goes. ++ Goffi ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Order-By
Le samedi 12 janvier 2019, 20:50:25 CET Jonas Schäfer a écrit : > They do, here’s how: You have two metadata fields, let’s call them Time and > Author. You have the following data: > > Time Author Item ID > 10:00 Alice1 > 11:00 Alice2 > 12:00 Bob 3 > 13:00 Bob 4 > 14:00 Bob 5 > 14:00 Carol6 > 15:00 Carol7 > > Suppose I want the posts ordered Ascendingly by Author, and use the time as > tiebreaker, descendingly. The resulting set would be: > > 2 1 5 4 3 7 6 Oh you're absolutely right, with multi-levels we could change ordering (ASC then DESC like here) while I was supposing it's always DESC, my bad. I'll add a "direction" argument defaulting to DESC, thanks for the explanation. > […] > I don’t think that relates to what I was trying to say. RSM relies strongly > on > having a unique, immutable identifier for items (which is used in > and ). On the *implementation* side (mind, I’m asking specifically > for > implementation guidance), I am not clear on what would be used here. Sure, > you > can use the Item ID, but there’s the problem that you cannot map that to an > SQL query with ORDER BY. You can use the classic "nth item in result set", > but > that loses the completeness and dub-free guarantees. OK I see. I have an implementation with SQL, and I'm doing an other SELECT with the item_id, I then get either the creation or modification date, and put it in a WHERE clause. But so far I was using one level of ordering, in case of multi-levels this is more complicated, I'll think about it, thanks for the pointer. > […] > The lack of clock synchronisation is a problem in any case, even when the > timestamps are generated on the server side, since XMPP is federated. I’d > even > argue that it is *worse* when the server is solely responsible, because there > is no way for a client to fix it. One node is on one server, so you have only one authority per node, the order will be consistent within that node (you can't achieve that by relying on X clients publishing X items). What I want to avoid, is what we have with email, where spammer put dates in future to be always on top. Note that this only influence the order, in XEP-0277 the creation and update dates (what appears to end-user) are set by the client. > I don’t see the faking of dates as an issue. At least for the blogging case. > Quite the contrary, I think it’s a good thing to have the flexibility (and in > a federated network, an adversary who wins by faking the dates can always > create their own server and spoof the dates there; so there’s no way for > clients to rely on those dates anyways). When you create a blog post, you usually also create the comments node on your own server, so you have control on both. When you visit a third party server, everything can be faked of course (including publisher jid and payload), but I suspect that the case when you want to visit a whole node maintained by a spammer is rare. So in nearly every common case, you can rely on the pubsub service dates for ordering. > On the other hand, I think that *not* letting the server do the date thing > and > instead selecting on the data already present in, for example, Atom, gives us > the advantage of being able to map existing Atom data into XMPP without loss > of usability and generality. I have plans for a future XEP allowing to order on arbitrary field, so client, knowing the context, could choose which method suits the best, but still I think it's important to be able to do it using pubsub service data. What to do if one or two items in a node are not following the right schema? Or if you use a XEP which doesn't set creation date? With pubsub service you are sure that the data is there and reliable (as long as you trust the node as said above). Note that ordering on arbitrary field is not that trivial, because Pubsub service doesn't know which fields are int, or dates, or something else. Also we would need a simplied XPATH like syntax, so a other XEP for that. If I can find some time today (I'm overwhelmed, so it's not sure at all), I'll try to update the protoXEP with all the insightful feebacks I've had sor far. Thank you all for those comments :) ++ Goffi ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Order-By
Le lundi 7 janvier 2019, 21:00:42 CET Evgeny a écrit : > On Mon, Jan 7, 2019 at 8:28 PM, Goffi wrote: > > Are you talking about the fact that "date of modification" (as > > defined in the protoXEP) could be out of sync between clusters? > > No, from the discussion I thought you want to have something like > incremental > unique "order" attribute in the node. > And sorting by timestamps is fine by me. Ah ok, no it was not that :). It's really about sorting by timestamp (or other fields later). ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Order-By
Hi Jonas,
Le lundi 7 janvier 2019, 18:08:25 CET Jonas Schäfer a écrit :
> On Sonntag, 6. Januar 2019 15:16:43 CET Jonas Schäfer wrote:
> > Title: Order-By
> > Abstract:
> > This specification allows to change order of items retrieval in a
> > Pubsub or MAM query
>
> Couple notes:
>
> - The strings for the "modification" and "creation" fields (as used in the
> element) should be URNs, I think, to allow future extensions without
> having to worry about conflicts.
I have thought about that too, but I took XEP-0313 as an example where the
common filters are using simple keywords ("start", "end", and "with" see
XEP-0313 § 4.1).
So I think this is alright to use keyword for the 2 most common cases, and URN
for extensions, in the same way as it is done in MAM.
> - Reversal via RSM seems wrong. You also can’t solve reversal via RSM when
> you
> use multiple levels of elements.
Lets say I have items 1, 2, 3, 4, 5, 6 and I want to get them by creation
order, 6 being the most recent, with a max of 2 per page, I would get with
normal request:
- 6, 5 (page 1)
- 4, 3 (page 2)
- 2, 1 (page 3)
But if I do backward using RSM's element, it would be
- 2, 1 (page 3)
- 4, 3 (page 2)
- 6, 5 (page 1)
(remember, RSM works by pages, so we just get the pages reversed).
In practice, the order if always DESC. But if the client want's to have ASC, it
just go backward using RSM, and reverse the result of each page (which is
trivial), so it would get 1, 2, 3, 4, 5, 6.
In both cases, requesting `4` gives `6, 5` (i.e. page 1) and
requesting `3` gives `2, 1` (i.e. page 3).
Multiple levels of ordering doesn't change anything to the deal, once
everything is ordered, we end up with a simple list of items.
> - In contrast to what Philipp thinks, I think that using multiple
> elements (and having their relative order be significant) is fine; As goffi
> mentions, pubsub itself is a valid precedent for that, and I think even a
> XEP-0004 needs to be able to preserve the relative order of elements with
> equal fully qualified name (i.e. namespace + local name) to render forms
> nicely, so every implementation should support this. (As an aside, I
> generally
> think anything which can be represented with a mapping-of-arrays is fair
> game.)
OK so we can stick with that significant order of elements.
> I think this specification needs to be very clear how this stacks with RSM
> (XEP-0059) and the underlying result set. In my mind, it stacks like this:
>
> PubSub "Database" -> PubSub-level Filters -> order-by XEP -> RSM
>
> I.e. it modifies the base Result Set in RSM terminology.
Yes RSM is not detailed enough, it's a really important thing to describe, I'll
work on it on next update. Do you think my example above is clear enough?
> I think this XEP should also provide guidance how to integrate this properly
> with RSM on the server side: It is not clear to me how a service could
> sensibly pick and item IDs in a way which allows it to
> reserve the guarantees of delivering a result set which does not lack items
> which have existed for the entire time the query was being processed (I call
> this property "completeness"), as well as a duplicate-free result set. If
> this
> is not possible (and I believe that to be true), it should be spelt out
> clearly in the XEP.
Actually the problematic case is for item overwritting, i.e. if we order by
"date of modification" according to the protoXEP terms, and this default case
with XEP-0060 (there is nothing like "modification" or "update", but the result
is the same: if you overwrite an item, it jump on the top).
If you use the new order introduced by the protoXEP (date of creation), the
items won't move, they can only be deleted.
>
> (Note: the guarantees ("completeness" and duplicate-freeness) I am talking
> about are a "MAY" in RSM, §2.2, bullet points 2 and 3.)
yes I was about to mention it is a "MAY" too :). But I totally agree with your
points, I'll explain it clearly in next revision.
> I am not completely sure whether it wouldn’t make more sense to specify an
> extension which allows to sort by arbitrary (or specific) Atom fields and let
> the Atom feed handle the management of modification/creation values. This
> also
> allows to access Atom feeds which are only mapped/gateway’d into XMPP and
> where the (authoritative) creation/modification times in the Atom feed then
> do
> not match the times as perceived and thus used by the PubSub service.
We already have and fields in Atom, but they are
specified by client, so this lead to majors issues:
- clock may not (and will not) be synchronised
- date can be faked
Re: [Standards] Proposed XMPP Extension: Order-By
Hi Evgeny, Le lundi 7 janvier 2019, 09:30:26 CET Evgeny a écrit : > On Mon, Jan 7, 2019 at 10:44 AM, Goffi wrote: > > Is there any implementation in the wild which would have issue with > > node order? > > Sure, any clustered database will have issues with > such naive approach: after partitioning during merge > you'll end up with duplicated orders, like 2 items > with order=4. I think you are talking about the feature in general (the question you are answering to was about using ordering of elements to know which level they are applied to vs using an explicit attribute for the same thing). I'm not sure to get your issue, I've talked about it this morning on xsf@ muc. Are you talking about the fact that "date of modification" (as defined in the protoXEP) could be out of sync between clusters? If so, ordering by date of modification as described in the protoXEP is the same as defaut ordering with XEP-0060 alone, so I don't see how this is different of current situation. If this is something else, can you please describe it with an example so I can understand better the problem? Thanks As I've said earlier, this protoXEP is not much different from the "ORDER BY" clause in SQL which can be used with clustered databases, so I don't see any reason why this would not work in this case. ++ Goffi ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Order-By
Hi Philipp, thanks for your feedbacks > - There is an attr missing that defines if the order should be ascending or > descending, just order by creation is not specific enough to me. > > - There is a part where it says with RSM you can change the order. This is > kind of wrong. With RSM you can in a result set page backwards, but you > cant influence the order of items within the page. I wanted to keep the XEP as simple as possible, but it's true that the order inside the page is not influenced. On the other hand, this is trivial to do client side, and once you know the order (most recent always on top), I don't see the need to complicate the XEP. I should formulate more explicitly the ordering inside the page. > - I feel its not really necessary to mention SQL and ORDER BY anywhere in > the document Probably yes, I'll remove the references on next update if the XEP is accepted. > - Business Rules: Its a first for me that a XEP depends on the order of > nodes in a stanza, i think it would be better to just add an attr that > defines the order. Also conflict seems the wrong word in this context to me. Indeed "conflict" is not the best wording, I'll change the formulation. About order of nodes, I don't see this as a problem, and having an attribute with priority would imply to sort the items once received and check for errors (missing sequence, or 2 elements with the same priority). Not that this is such a difficult thing to do, but it doesn't seem needed. Is there any implementation in the wild which would have issue with node order? When you get the result of a pubsub get query, the order of items is also significant. ++ Goffi ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Order-By
Le dimanche 6 janvier 2019, 15:16:43 CET Jonas Schäfer a écrit : > The XMPP Extensions Editor has received a proposal for a new XEP. > > Title: Order-By > Abstract: > This specification allows to change order of items retrieval in a > Pubsub or MAM query > > URL: https://xmpp.org/extensions/inbox/order-by.html > > The Council will decide in the next two weeks whether to accept this > proposal as an official XEP. > ___ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > ___ > Just a precision because after talking on xsf@ it doesn't seem clear: the order affect the whole archive, not just a result set, pretty much like ORDER BY in SQL. I'll clarify that in a future version of the XEP. ++ Goffi ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0060: Item ordering
Le mercredi 8 août 2018, 17:17:57 CET Peter Saint-Andre a écrit : > On 8/8/18 3:17 AM, Philipp Hörist wrote: > > I always thought the most recent refers to the publish date/time of the > > item, hence if i override a item it also changes the updated time/date > > and it becomes the most recent > > That seems reasonable. So it's really "last modified item". I'm curious > what Ralph thinks. > > Peter Hello (and happy new year everybody). I've asked to Ralph, and he confirm this behaviour: "There's no such thing as updating an item.". It seems logical to me too, but this is a problem in several use cases (blogging, or experimental features I'm working on like tickets). To fix this, I've just submitted a new XEP, "Order-By", that changes the business logic. It should be easy to implement client and server wide. Looking forward for your feedbacks. Regards Goffi ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Server status pages
Le lundi 3 décembre 2018, 11:17:24 CET Kevin Smith a écrit : > On 3 Dec 2018, at 10:02, Matthew Wild wrote: > > > > Hi all, > > > > I'd like to allow servers to advertise status pages to their users. > > See for example https://statut.jabberfr.org/ > > > > This information could be cached by clients, and linked to in case of > > problems connecting, for example. > > > > The question is where and how to advertise it. Someone suggested it > > might fit into XEP-0157, as if you squint hard enough, it is a > > communication channel about the service. The link could also be a URL > > to a Twitter, Mastodon feed, or whatever. > > > > This is one possibility, there are others. Anyone have thoughts to > > contribute? > > 157 clearly isn’t exactly right for this, but it seems ‘close enough’ that > it’d probably be pragmatic to use it. I’d suggest registering a new field, > describing the semantics and using it in 157. We could also do not-quite-157 > by specifying a similar form extension under a different namespace but … I > don’t see a great advantage (or any great disadvantage either, really - it’s > not going to be much harder for servers or clients one way or the other, I > think. > > /K > ___ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > ___ > Hi, That's a great idea. Not sure about XEP-0157, but if nothing better arise, why not. In addition to status page, it would be great to have a way to get future planed maintenance (at least the next one), and estimated time before service is up again. ++ Goffi ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] [XEP-0384] OMEMO: xml:lang + max_items
Le vendredi 27 juillet 2018, 16:41:57 CEST Philipp Hörist a écrit : > Hi, > > Didnt know about that PEP sentence, i dont know any implementation that > does this, but still if its possible we should limit 0384 to singleton > Node usage, but to be honest so should every other XEP that depends on > PEP. Well XEP-0277 that we are using a lot in SàT and Movim is using multiple items, not only the last one, so our implementations keeps all items. The issue is not about notifications here, but the fact that updated items will be pushed to new ones instead of replacing current one, and in the case of OMEMO bundles, this can quickly grow. Goffi ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] [XEP-0384] OMEMO: xml:lang + max_items
Le vendredi 27 juillet 2018, 19:21:22 CEST Goffi a écrit : > An (animated) picture worth thousand words :) > > https://repos.goffi.org/sat_docs/raw-file/tip/screenshots/0.7/ > language_filtering.gif > > The experimental language detection put aside, I'm using xml:lang here to > display the language used, and this allow language filtering, which is > really useful in a multilingual room. This data can also be used to propose > translation, and probably other neat features. > > With OMEMO I'm loosing the xml:lang (the disappear), and I'm not > sure where I could put it (I think this information should be encrypted > too). > > thanks > Goffi sorry, the image link has been cut: https://repos.goffi.org/sat_docs/raw-file/tip/screenshots/0.7/[1] _language_filtering.gif_ [1] https://repos.goffi.org/sat_docs/raw-file/tip/screenshots/0.7/ language_filtering.gif ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] [XEP-0384] OMEMO: xml:lang + max_items
Le vendredi 27 juillet 2018, 17:24:27 CEST Peter Saint-Andre a écrit : > On 7/27/18 8:03 AM, Goffi wrote: > > Hello, > > > > I'm currently working on OMEMO implementation in Salut à Toi thanks to > > the work of Syndace (https://github.com/Syndace/python-omemo), and I > > have two issues with it: > > > > - SàT is using xml:lang attribute, and I don't see a way to specify it > > with OMEMO, how should I do? What are business rules when several > > bodies are available (I know it's not common, but it's allowed by > > RFCs)? > > Could you describe in more detail what you're trying to accomplish? > Section 5.2.3 of RFC 6121 talks about xml:lang for message bodies, but > perhaps you need more information. > > Peter An (animated) picture worth thousand words :) https://repos.goffi.org/sat_docs/raw-file/tip/screenshots/0.7/ language_filtering.gif The experimental language detection put aside, I'm using xml:lang here to display the language used, and this allow language filtering, which is really useful in a multilingual room. This data can also be used to propose translation, and probably other neat features. With OMEMO I'm loosing the xml:lang (the disappear), and I'm not sure where I could put it (I think this information should be encrypted too). thanks Goffi ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] [XEP-0384] OMEMO: xml:lang + max_items
Hey, thanks for the quick feedback Le vendredi 27 juillet 2018, 16:10:38 CEST Philipp Hörist a écrit : > On the Pubsub Questions: > > 1. In Pubsub there is already defined the Singleton Node: > https://xmpp.org/extensions/xep-0060.html#impl-singleton, no need to > invent a new item id for that Oh great, I've missed this one. But it doesn't seems used by other clients unfortunately, would be nice to add an implementation note on that in XEP-0384 > 2. I think its not specified because your client should not care how many > items are in a PubSub Node. Your Client either uses PEP and PEP should > only notify you about the last/most recent item on the node, i think > thats the reason PEP exists. XEP-0163 §4.3.4 says "When processing a new subscription, the service MAY send not only the last published item but instead all items that are currently associated with the node (i.e., up to the maximum number of items at the node, which might be one if the node is a "singleton node" as described in XEP-0060)", so it can send all items > 3. if you dont want to use PEP you can always request the most recent > item from a node with specifying max_items=1 in the request. It's not that I don't want to use PEP (I'm using it), it's that I don't want to have the same items recorded again and again for nothing. I've mentioned max_items=1 in my previous message, but this feature is optional, and if singleton is needed (which is the case), it should be indicated in the XEP-0384 in my opinion. > So my question would be, how do you get into a situation where a server > sends you all items of the Node? It's not in my notifications, I'm checking manually the content of my PEP nodes to check the workflow. > > regards > Philipp Thanks Goffi ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] [XEP-0384] OMEMO: xml:lang + max_items
Hello, I'm currently working on OMEMO implementation in Salut à Toi thanks to the work of Syndace (https://github.com/Syndace/python-omemo), and I have two issues with it: - SàT is using xml:lang attribute, and I don't see a way to specify it with OMEMO, how should I do? What are business rules when several bodies are available (I know it's not common, but it's allowed by RFCs)? - only the first item of PEP nodes are used, and it seems that client are implicitly expecting max_items=1 (i.e. singleton pattern), but I don't see any mention of that in the XEP. Furthermore, max_items support is optional in Pubsub, and I see in my PEP nodes the same items published several times. This could be mitigated by using a well known id for the item (e.g. the OMEMO namespace), so even pubsub services not featuring max_items would simply override the existing item. That's all for now, thanks Goffi ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XMPP Council Minutes 2018-06-20
Hi, after pushing on standard@ on this point because I had not feedback, I'll try to explain better why it's important to have expiration date. For now, when we use HTTP Upload, we blindly upload a file on a server, with no clue for the time of retention, how to delete it, or even to list already uploaded files. Imagine we uploaded an important file by accident (but didn't share the link), no way to do anything except contacting the admin (if they put their contact anywhere). If file is uploaded for one shot (just sharing a picture in a MUC), I would like to know how long the server will keep it. Also HTTP upload can be used for long term : I use it with blogging and I wish my files to stay there for ever except if I explicitly ask them to be removed. I can do it on my server because I know how it is set up, but I would like to have this expiration date available for any server. I know it is not the use case HTTP Upload was initialy planned for, but still it's something people can and will do. There is also the GDPR context in Europe, I think it's a minimum to know for how long a file is kept. So I would like to see at minimum a mandatory expiration date returned by servers, in the same way as size limit can be returned. It would be even better to be able to list existing files and delete them on request, but this can be done in a separated XEP. Thanks Goffi Le samedi 23 juin 2018, 18:08:32 CEST Goffi a écrit : > Did you read my feedback about this? In particular what about my remarks > on expiration date? I would like to have an answer on that, it's > particularly important in my opinion. Thanks! > > Cheers > Goffi > > > ___ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > ___ ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XMPP Council Minutes 2018-06-20
Hi, Le samedi 23 juin 2018, 13:24:22 CEST Tedd Sterr a écrit : > 3) Advance XEP-0363: HTTP File Upload > Kev: [on-list] (without the agenda in advance, failed to look at this > again) Sam: [on-list] (still nervous about the http headers stuff being > too restrictive) Daniel: +1 > Dave: [pending] > Georg: [pending] Did you read my feedback about this? In particular what about my remarks on expiration date? I would like to have an answer on that, it's particularly important in my opinion. Thanks! Cheers Goffi ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] LAST CALL: XEP-0363 (HTTP File Upload)
Hi, I'm developer of Salut à Toi and HTTP Upload is implemented there, here are my feedbacks: > 1. Is this specification needed to fill gaps in the XMPP protocol > stack or to clarify an existing protocol? Well it's hard to answer. I would say no because Jingle is already doing that in a better way. On the other hand, HTTP libraries are more common that Jingle libraries, making the implementation more easy for HTTP upload. At the end, I don't think it's really filling a gap, but its existence make sense in a way. > 2. Does the specification solve the problem stated in the introduction > and requirements? The problem stated in introduction is not true, it's absolutely possible to use Jingle to send a file to multiple resources or to make it work offline, we do it in SàT with a server side component. But HTTP Upload implementation is truly easy on client dev perspective, supposing we have already HTTP libraries + certificate checking facilities in the used programming language (which is most of time true). That's the main interested of this XEP. > 3. Do you plan to implement this specification in your code? If not, > why not? already implemented > 4. Do you have any security concerns related to this specification? my main concern is about file deletion. We have no way to know which files are already uploaded, for how long and how to delete them. I think this specification should return the expiration date of the file, in the same way as it returns max-file-size in section 3 and example 4. About user request of file deletion, this could probably be done in an external XEP, but it's an important missing part in my point of view. > 5. Is the specification accurate and clearly written? yes, redaction is good and spec is well explained. additional notes: - there is no validation schema in section 11 - there is no short name ++ Goffi ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Thoughts on MIX adoption (and will MIX ever happen?)
Le jeudi 10 mai 2018, 10:36:17 CEST Steve Kille a écrit : > Having made the latest round of MIX edits, I felt it was time to share > some thoughts on MIX. > > It has been a number of years since work was started on MIX, and > implementations are thin on the ground. It seems sensible consider when > and if this will change. > [SNIP] Interested in implementing MIX in SàT, but not a priority (and lacking resources). We have already blogging, comments, shared files and pictures based on pubsub/jingle. Goffi ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0394: too weak to replace XEP-0071
Hi I'm the main dev of Salut à Toi Le vendredi 16 mars 2018, 10:08:12 CET Dave Cridland a écrit : > Neither Movim nor Salut à Toi etc need to stop using XHTML embedded > into XMPP (usually, in their case, via Atom). That's right, we both (Movim and SàT) use full XHTML (even if XEP-0277 recommand XHTML-IM, this mention should be removed from the XEP now), and we do sanitization before displaying it. We probably need a XHTML sanitization good practice XEP and I may work on it with anyone interested but not before a while, I'm too busy for now. I was personnaly against deprecating XHTML-IM in the previous thread (and I see some arguments coming back here), but I now think it's OK to do it as XEP-0394 is a clean and extensible alternative. I'm still against XEP-0393 because of its mixing of text and markup, and I think we can achieve similar result by using XEP-0394 on the wire, and whatever markdown developers want to use on clients. Time will probably set this up. Anyway, and above the disagrements, thanks to everybody working on that (even for XEP-0393 that I dislike :) ) and trying to find the best solution to satisfy everybody or at least most of people (developers and users). Cheers Goffi ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Call for Experience: XEP-0048: Bookmarks
Can't make a detailed review today, so here's quickly: the XEP is implemented in SàT using both private XML storage (XEP-0049) and PEP. There are several issues with this XEP, the most important being the race condition can be specially bad as all bookmarks are saved in the same item. Also I've tried to use it to bookmark pubsub nodes (blogs) using xmpp: URIs, but as it is not explicitly mentioned in the XEP, some clients just remove the links (don't remember which ones right now, I've tried years ago). Also on the practical side, the XEP is lacking way to classify links, like keywords, hierarchy, or anything else. We have been thinking for a while with Edhelas about writting an alternative proposal for bookmaks actually, but that's an other topic. Goffi Le mercredi 7 mars 2018, 20:17:24 CET Jonas Wielicki a écrit : > The XEP Editor would like to Call for Experience with XEP-0048 before > presenting it to the Council for advancing it to Final status. > > > During the Call for Experience, please answer the following questions: > > 1. What software has XEP-0048 implemented? Please note that the > protocol must be implemented in at least two separate codebases (at > least one of which must be free or open-source software) in order to > advance from Draft to Final. > > 2. Have developers experienced any problems with the protocol as > defined in XEP-0048? If so, please describe the problems and, if > possible, suggested solutions. > > 3. Is the text of XEP-0048 clear and unambiguous? Are more examples > needed? Is the conformance language (MAY/SHOULD/MUST) appropriate? > Have developers found the text confusing at all? Please describe any > suggestions you have for improving the text. > > If you have any comments about advancing XEP-0048 from Draft to Final, > please provide them by the close of business on 2018-03-21. After the > Call for Experience, this XEP might undergo revisions to address > feedback received, after which it will be presented to the XMPP > Council for voting to a status of Final. > > > You can review the specification here: > > https://xmpp.org/extensions/xep-0048.html > > Please send all feedback to the standards@xmpp.org discussion list. > ___ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > ___ ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] OBSOLETED: XEP-0071 (XHTML-IM)
Le mercredi 7 mars 2018, 19:21:45 CET Kozlov Konstantin a écrit : > Thank you for your reply. Yes, I know about those two. As for XEP-0394, I > feel so bad the XEP idea, so I don't even want to discuss the XEP > itself. Out of curiousity, what do you dislike in this XEP? I actually find the idea really good, it's a clean separation between content and style, which means that there is not need to send a text version as we have too with XHTML-IM. XEP-0393 on the other hand is totally mixing style and content, that's why I really dislike it. Goffi ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] [XEP-0234] Jingle File Transfer, Last Call and File Sharing
Le lundi 26 février 2018, 17:20:15 CET Simon Friedberger a écrit : > Don't you in most cases want hashes anyway to ensure the integrity of > the files? It's calculated during transfer yet, but I don't want to calculate hashed of all the files I'm sharing before sending them. > > It's also not actually that resource intensive to calculate the hash of > a file. Definitely negligible to transferring it. I'm not talking about the file transfer here (the hash it always calculated during transfer), but about the information needed to retrieve a file in a list returned by XEP-0329 potentially big. Goffi ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] [XEP-0234] Jingle File Transfer, Last Call and File Sharing
Le lundi 26 février 2018, 15:48:49 CET Tobias M a écrit : > If XEP-0329 would also share the hashes, you could use the hash to to > fetch things via Jingle FT, similar to what XEP-0385 does. My problem is that I don't want to always calculate hashes, it's resource intensive if I have large files and/or a lot of files. Using path or UUID would be a good solution, but we need to be able to specify them in XEP-0234 (either by allowing "/" in name, or by using an other element). Goffi ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] [XEP-0234] Jingle File Transfer, Last Call and File Sharing
Hi Tedd, thanks for your feedback Le dimanche 25 février 2018, 21:19:16 CET Tedd Sterr a écrit : > The requestor should ask for the full path to the file, not the bare > filename, so as long as you don't have two files with the same name in > the same directory, there shouldn't be a conflict. Treat the node name > as an opaque identifier for the file, so a request for a bare filename > simply won't match any of the shared files (except in the case where the > file is shared without any containing directory, but this should still > be the only file with that name.) Well the XEP states that "/" SHOULD NOT be used in name (XEP-0234 §5 and §12), so I'm not sure that putting the path there is a good idea. If so it would simplify things, but wording should be changed. > 'path/filename' should be a unique identifier, otherwise how do you know > which they are requesting? Also, if you can give all files a unique ID, > that unique ID could just as easily be the hash value itself. I may use versioning in the future, so path/filename may not be unique, that's why I would like to use UUID. > > 4) if there are several file conresponding to a file request (e.g. only > > name is given), what should we do ? Return the first one or send a > > "conflict" stanza error? > > As above; this shouldn't happen - you should not offer to share two files > with the same path+filename. My question is if we have only the filename or the hash (even if payload will be the same with single hash, metadata like name or date can differ) > The XEP hints at the possibility of requesting a file by name only (sans > path), but only when this will be unique; I suggest the request MUST > include the path to avoid any confusion. But there is no way to include the path at the moment. Goffi ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] [XEP-0264] thumbnails: we should be able to transmit them with XEP-0234
Le samedi 24 février 2018, 18:25:26 CET Kim Alvefur a écrit : > On Sat, Feb 24, 2018 at 09:12:30AM +0100, Goffi wrote: > > currently thumbnails are transmitted using http(s) or BoB (XEP-0231). > > But with resolutions we can have todays even on small screens, size of > > images is growing. Transmitting them using BoB can block the > > connection and is a useless waste of bandwidth. > > What size thumbnails are we talking here? At what point does it become a > problem to BoB them and what quality do people expect from thumbnails? And other issue I forgot to mention : with BoB I have to send data through the server, while in my use case data will in many cases stay on the same local network. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] [XEP-0264] thumbnails: we should be able to transmit them with XEP-0234
Le samedi 24 février 2018, 18:25:26 CET Kim Alvefur a écrit : > On Sat, Feb 24, 2018 at 09:12:30AM +0100, Goffi wrote: > > currently thumbnails are transmitted using http(s) or BoB (XEP-0231). > > But with resolutions we can have todays even on small screens, size of > > images is growing. Transmitting them using BoB can block the > > connection and is a useless waste of bandwidth. > > What size thumbnails are we talking here? At what point does it become a > problem to BoB them and what quality do people expect from thumbnails? It 's not only the size, it's also the quantity. I'm thinking about a photos album, say you have 50 pictures/page and so 50 thumbnails, with XEP-0234 you can get all thumbnails out of band in the same session, with BoB you have to greatly increase the bandwith and number of requests. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] [XEP-0264] thumbnails: we should be able to transmit them with XEP-0234
Hello, currently thumbnails are transmitted using http(s) or BoB (XEP-0231). But with resolutions we can have todays even on small screens, size of images is growing. Transmitting them using BoB can block the connection and is a useless waste of bandwidth. I'm thinking about P2P transmission, so http is not an option here. As XEP-0234 is able to transmit several files in the same session, it would be a good candidate for that. Doesn anybody see an issue with using XEP-0234 for that? If no I'll propose the change on the XEP. Goffi ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] [XEP-0234] Jingle File Transfer, Last Call and File Sharing
Le vendredi 23 février 2018, 10:16:49 CET Goffi a écrit : > Le vendredi 23 février 2018, 10:02:15 CET Jonas Wielicki a écrit : > > On Freitag, 23. Februar 2018 09:47:00 CET Goffi wrote: > > > 1) XEP-0234 is in Last Call which is supposed to be finished, what > > > the > > > status about that? > > > > The Council vote isn’t over yet (but from what it looks like, > > advancement will be rejected since Daniels feedback has not been > > addressed; it looks like it will stay in Experimental). > > Thanks. Where is this feedback? I found a mention on it in council > minutes from 2018-02-07 but can't find it. Is it this? https://mail.jabber.org/pipermail/standards/2017-May/ 032610.html ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] [XEP-0234] Jingle File Transfer, Last Call and File Sharing
Le vendredi 23 février 2018, 10:02:15 CET Jonas Wielicki a écrit : > On Freitag, 23. Februar 2018 09:47:00 CET Goffi wrote: > > 1) XEP-0234 is in Last Call which is supposed to be finished, what the > > status about that? > > The Council vote isn’t over yet (but from what it looks like, advancement > will be rejected since Daniels feedback has not been addressed; it looks > like it will stay in Experimental). Thanks. Where is this feedback? I found a mention on it in council minutes from 2018-02-07 but can't find it. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] [XEP-0234] Jingle File Transfer, Last Call and File Sharing
Hello everybody, As mentioned in my last message, I'm currently working on file sharing. I have a couple of remarks with that: 1) XEP-0234 is in Last Call which is supposed to be finished, what the status about that? 2) for file sharing, I need more metadata, for instance the path needed to identify the file gotten from XEP-0329 : I don't want to always calculate hashes of all files I'm sharing to avoid consuming too much resources, and the name alone may not identify uniquely the file. How can I transmit them? Should I use a separate namespace (that would make sense), or would it possible to add this specific metadata to XEP-0234? 3) for the same reason, I would like to optionnally give an unique ID with my files, this way I can identify them without calculating hash. Would it be possible to have an uuid metadata? 4) if there are several file conresponding to a file request (e.g. only name is given), what should we do ? Return the first one or send a "conflict" stanza error? 5) there is not URI format specified in the XEP, that would be nice to add (there was one for XEP-0096: https://xmpp.org/extensions/ xep-0096.html#registrar-querytypes) Beside that this XEP is really usable. Thanks Goffi ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] undefined state in XEP-0050
Le mercredi 21 février 2018, 19:50:17 CET Florian Schmaus a écrit : > But this is unlikely to change ever. So here is how I understand it: > > - 'execute' always gets you into the next stage, and iff 'next' is an > allowed action, then 'execute' is equivalent to 'next', or otherwise it > is equivalent to 'complete'. > > I've submitted https://github.com/xsf/xeps/pull/591 > > Discuss :) Nice to see this post is not forgotten even after years :) As XEP-0050 is a draft standard and widely deployed, I also think it is very unlikely that it is changed, so your proposition seems a reasonable fix. Goffi ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] feedback on file sharing with XMPP [XEP-0135] [XEP-0214] [XEP-0234] [XEP-0329]
Hello here, I'm currently implementing file sharing over XMPP, and I thought a feedback could be interesting. First my use cases: I want progressively to 1) upload files to a component, and find them later, with permission handling 2) share directory (virtual or real) with a contact (or several with permission handling) 3) share photo albums 4) allow to manipulate files (delete, rename, change permissions, etc.) Once XEP-0234 (Jingle FT) is implemented, it's really easy to do as file request is specified (https://xmpp.org/extensions/xep-0234.html#requesting). I have checked available XEPs to share a structure, the 3 of interest are: XEP-0135: it's using disco and SI File Transfer (XEP-0096) to retrieve files PROS: - we can retrieve whole tree at once with a tree.xml CONS: - based on deprecated technologies, so discarded XEP-0214: it's using pubsub to share files metadata, with a mirror list, and using SI File Transfer as main way to retrieve file PROS: - Pubsub based, so we have subscription, access models and search (via MAM) for free. - handle revisions - handle mirrors, even non XMPP (e.g. ftp, http, torrent) CONS: - tedious to implement in current Pubsub ecosystem state - Pubsub Collections Nodes (XEP-0248) are in my opinion unusable, as the access model of the collection node override leaf nodes access models (but it would be a good XEP if this was fixed) - using deprecated technologies (but this can be fixed easily) - seems a bit over-engineered, not sure to see widespread implementations I've tried to contact the author to see if he still wanted to work on this without success XEP-0329: it's using a simple IQ request, where node is the requested directory, which return XEP-0234 file informations, sufficient to request the file with jingle. There is a way to create a P2P channel to retrieve big repository (or to encrypt metadata) PROS: - simple and easy to implement - based on good technology stack (jingle) - can use a separate channel for signal, allowing large amount of data and metadata encryption CONS: - no subscription mechanism (we need to poll to see if there are new files) - no search/filtering - no file revisions That's the one I've chosed for its simplicity. There are small annoying stuff that need to be fixed though (I don't like that sometime we can send just the name, sometime a whole bunch of metadata, and that directories can't be empty), but it's doing the job quite well for basic use cases. With XEP-0234 and XEP-0329 I can do my 1) and 2) uses cases. 4) can be done with ad-hoc commands (XEP-0050), even if this would need a XEP to specify well known nodes. For 3) (photo albums), I need other features: I) I need to be able to filter by mime-type, to retrieve only photos, or photos/vidéos II) I need to retrieve thumbnails if available III) I want to allow users to comment any file For I) as far as I know, there is no solution at the moment For II) XEP-0264 can be used (Jingle Content Thumbnails) For III) I want to use XEP-0277 (microblogging over XMPP) as we have already advanced implementations. But I don't want to have to request one node per file when most of files will probably not have any comment. My current plan is to let the file sharing component handling the nodes, so it can return the number of comments with file metadata, and I can request comments only if needed. Any better suggestion welcomed. My current implementation will be available in next release of Salut à Toi (or soon in dev version for the most adventurous ones). If other people are willing to work on this field, please contact me. Goffi ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Council Agenda 2018-02-14
Le mardi 13 février 2018, 18:28:02 CET Dave Cridland a écrit : > As such, I'm thinking of writing something for XEP-0001 that imposes a > last-call-like period for comments - Intent To Deprecate/Obsolete > perhaps - and imposing that on ourselves. That's a really good idea! > Dave. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Adding logo to MUC and PubSub node
Le jeudi 8 février 2018, 16:59:47 CET W. Martin Borgert a écrit : > For e.g. Movim both a logo for service and for a node seems to be > useful. icons for service and node are useful indeed > > > I think specifying avatars for each PubSub *node* could be tricky. For > > services (which I assume you meant) see below. > > If there were a "magic" item on a node, it never must be removed > automatically, but only on user request, right? I find this thing awfull, it's mixing metadata with main data. I think we would do better by implementing a notification mecanism for config options, as notification may be useful not only for avatar/icon. We could use the same sementic as for nodes, but with a different namespace. Goffi ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XMPP Council Minutes, 2018-01-17
Le jeudi 18 janvier 2018, 11:36:22 CET Daniel Gultsch a écrit : > 2018-01-18 11:07 GMT+01:00 Goffi <go...@goffi.org>: > > Hello everybody, > > > > Le jeudi 18 janvier 2018, 09:28:33 CET Dave Cridland a écrit : > > > 6) https://github.com/xsf/xeps/pull/557 > > > > > > Council decided to vote in the absence of further list discussion. > > > > > > All present in favour, Kev to vote on list. > > > > Was this discussed on list? > > Yes. > https://mail.jabber.org/pipermail/standards/2017-December/034023.html > > And I even bumped the thread about a week ago. OK for this one, thanks for this. The remark is general though, just to request people to be careful about that. Goffi ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XMPP Council Minutes, 2018-01-17
Hello everybody, Le jeudi 18 janvier 2018, 09:28:33 CET Dave Cridland a écrit : > > 6) https://github.com/xsf/xeps/pull/557 > > Council decided to vote in the absence of further list discussion. > > All present in favour, Kev to vote on list. Was this discussed on list? It starts to be a problem for me that discussions are spanning on 3 differents places (this mailing list, XSF MUC room, and now on github P.R. comments). I'm not really following discussions on Github, and I would expect to have any important subject (like Pubsub) being discussed on this mailing list. Same for the MUC room : I have a daily job which has nothing to do with XMPP, and so I've no time to follow every discussion there. It's not a good thing IMO to discuss important subjects there, or it you do please post a summary on the mailing list which is far more easy to follow for my point of view (as a matter of fact, I was actually present for this dissussion on this particular P.R., but other people where not). I take this P.R. as an example, but it's a general remark. Thanks Goffi ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Styling
Good morning/evening/day eveybody Le mercredi 15 novembre 2017, 09:54:07 CET Dave Cridland a écrit : > Conversations is following an existing trend. Sam has merely documented it, > and we're trying to ensure that the downsides of this approach - and I > don't think anyone pretends there aren't any - are mitigated. > > This is not ideal, it is not perfect, but I think we're well into von > Clausevitz territory[1], and the question should be whether we can control > the inevitable damage. So shouldn't the type of the XEP (if it becomes one) be "informational" instead? At least this show this is not a good practice supported by the community. And please if it really do through the official number, add on "opt-in" mechanism as previously discussed (this is still not in the protoXEP). Thanks Goffi ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] 2017-11-08 XSF Council Minutes
Le 2017-11-08 20:20, Jonas Wielicki a écrit : On Mittwoch, 8. November 2017 20:02:24 CET Goffi wrote: I was in favor of making formatting characters mandatory in styling, but if there is markup and attribute, I think it's not needed anymore. It is, for clients not supporting markup at all. No you don't get what I mean: I was suggesting to force client supporting style to always display the formatting characters to avoid content change, and to be able to safely ignore the style XEP. But if the message can be explicitely marked as not styled (e.g. when sending the output of a shell command), it is not a problem anymore that client supporting style remove formatting characters (on the rendering, I'm not talking about the content of the ). ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] 2017-11-08 XSF Council Minutes
Le mercredi 8 novembre 2017, 17:56:26 CET Jonas Wielicki a écrit : > On Mittwoch, 8. November 2017 17:49:26 CET JC Brand wrote: > > jonasw asks that the previously rejected ProtoXEP "Body Markup Hints" be > > reconsidered as a means to bridge the above two ProtoXEPs. > > > > https://xmpp.org/extensions/inbox/bmh.html > > Sorry, to correct: This is not what I said (or at least not what I meant to > say), and not what I hope BMH to be in this context. > > I was proposing BMH as an opt-in mechanism for Styling, because Styling with > opt-in is essentially BMH with a specific markup. > > It won’t play any role in bridgin Markup and Styling. > > kind regards, > Jonas It seems that there is a strong pushing for styling, so would not it be possible to 1) make styling dependant of markup 2) remove escaping from styling 3) if styling is used: * force use of markup to declare the styling * use an additional attribute in as "opt-in" ? I think this would be a satisfory solution for everybody, and this would be trivial to implement. I was in favor of making formatting characters mandatory in styling, but if there is markup and attribute, I think it's not needed anymore. And please don't use BHM, it's using markdown with all the issues I have already expressed + it's open to any formatting which is bad idea. Styling fixes those issues. Thanks Goffi ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Styling
Le mercredi 8 novembre 2017, 11:18:51 CET Jonas Wielicki a écrit : > I think we also have to acknowledge that there are use-cases for much richer > text, for example within the Social Network and Blog Federation interest > groups (sorry if that name doesn’t quite fit). Those use-cases were covered > by XHTML-IM before, and fail to be covered by BMH and Styling. Message > Markup can cover those use-cases, if it gets extended into that direction, > while helping to prevent the security issues of XHTML-IM. Please see the > other thread for considerations about plaintext fallback. I forgot to mention here: XHTML-IM is not sufficient for blogging, SàT and Movim use XHTML that we clean. I think in addition to current markup debate, we need a XEP for full XHTML implementation with security consideration, but that's a different story. ++ Goffi ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
