Hi,

Please note that in the context of my incoming work on reducing metadata 
exposure in XMPP (https://nlnet.nl/project/ServerlessXMPP/) I'm planning to 
work on roster and pubsub, the main goal being to enable the use of e2ee with 
roster data, while also adding extra information without breaking backward 
compatibility.

It could be something that fits your use case.

Best,  
Goffi


Le samedi 8 novembre 2025, 18:50:28 heure normale d’Europe centrale Philipp 
Hörist a écrit :
> Hi,
> 
> Both XEPs are only implemented by one client, so before we go on maybe we 
should ask if these XEPs actually solve a problem in a good way.
> 
> My opinion on this would be a definitive, no.
> 
> Putting a pin element into bookmarks never made much sense, this was pointed 
out when the XEP was published, and when i recall the conversation back then, 
the author was sadly not aware that bookmarks are only for group chats.
> 
> The chat notification XEP is kind of fine, it just misses a place where we 
> can 
use it. It feels like it should be part of a bigger spec that defines where to 
store these kind of settings.
> 
> I would first start with gathering requirements what we would expect from a 
chat settings/pinning XEP.
> 
> The most important for me would be, I want to set settings for all entities, 
this means every JID, independent if they are in my roster or not, or if they 
identify as group chat or whatever else.
> And i want to get them form a single location, not merge multiple sources 
into one.
> 
> Pubsub would be the logical place for me to implement something like that.
> 
> Regards
> Philipp
> 
> On Sat, Nov 8, 2025, at 16:59, Thilo Molitor wrote:
> > Hi all!
> > 
> > With XEP-0469: Bookmark Pinning and XEP-0492: Chat notification settings we 
now 
> > have two XEPs that allow syncing pinning and notification settings across 
> > clients on the same account using the <extensions/> element of XEP-0402: 
PEP 
> > Native Bookmarks.
> > 
> > Unfortunately, this now means that normal 1:1 chats (that are synchronized 
as 
> > roster items) lag behind.
> > 
> > I'm volunteering to write a XEP adding an <extensions/> element alongside 
the 
> > <group/> element to allow arbitrary extensions for roster items. This 
would 
> > bring 1:1 roster items on-par with bookmarks2 and immediately allow 
XEP-0492 
> > and XEP-0469 to be applied to roster items as well.
> > 
> > But before I start I want to ask especially the server developers on this 
> > list: would you consider implementing this?
> > If the answer is no or "some day far far in the future", it might be worth 
to 
> > try to invent some other mechanism that could be deployed faster.
> > 
> > In my opinion, however, extending the roster items is by far the most 
elegant 
> > and simplest solution.
> > 
> > What do you think?
> > 
> > -tmolitor


Attachment: signature.asc
Description: This is a digitally signed message part.

_______________________________________________
Standards mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to