On Tue, Nov 11, 2025 at 6:57 PM Florian Schmaus <[email protected]> wrote:
> On 08/11/2025 16.59, Thilo Molitor wrote: > > I'm volunteering to write a XEP adding an <extensions/> element > > alongside the > > <group/> element to allow arbitrary extensions for roster items. > Extending roster items is tempting and seems like an ideal fit at first, > but there is a reason this isn't usually done (probably besides some > internal deployments): > > It's fragile, inefficient, and there are better alternatives. > > There is a good summary of the problems that come up in the "Bookmarks 2 > extensibility" thread from Nov 2019. I'll try to come up with a link > (assuming this is still accessible somehow). > > Basically, things you have to keep in mind include: you have to avoid > clients overriding unknown extensions when re-submitting things. You may > end-up with having to resubmit extensions even though you did not modify > them (which is ineffective). You may want to distinguish between > extensions that have been synthesized by the server. I think Philipp somewhere else in the thread brought up a valid concern with regards to wanting to store information for people not in the roster; However the unsupporting clients overwriting extensions is something we can easily fix. The server needs explicit support for it anyway. So on roster push a lack of an <extensions/> wrapper element would mean the client either doesn’t support them or doesn’t want to modify them. (An empty <extensions/> would indicate delete.) This solves both non-supporting clients and avoids the traffic issue that Florian brought up. (However in most deployments you are not constantly editing individual roster items anyway. That’s only on add, delete and occasional name changes). There are potentially some overlapping problems with Bookmarks 2 but accidental overwrite is not one of them. All in all I’m more or less in favor of this although we should consider what Philipp wrote wrt annotations for conversations not in your roster. WRT extensions synthesized by the server. We can just address this if we feel we need that feature. cheers Daniel _______________________________________________ Standards mailing list -- [email protected] To unsubscribe send an email to [email protected]
