The new standard requires that arbitrary <extension> data MUST be preserved. Currently, the only preserved 'extension' data is ext_gajim_minimize. I think we don't want to store all of these data in the struct bookmark_t. For modifying bookmarks, we could retrieve the complete entry and upload the updated data.

The current implementation in Profanity only supports XEP-0048 with the legacy "Private XML Storage".

I think we should follow the backward compatibility strategy that Gajim has implemented:

https://dev.gajim.org/gajim/gajim/-/blob/master/gajim/common/modules/bookmarks.py#L144

• If PubSub is not supported at all (which should be rare), use (legacy) Private XML storage bookmarks
• (Use native bookmarks if forced by a user option)
• If the server announced compatibility between PEP storage and PEP Native Bookmarks (XEP-04-02) (via the urn:xmpp:bookmarks:1#compat feature), use PEP Native Bookmarks.
• If conversion between Private XML storage and PEP storage (announced via the 'unofficial' urn:xmpp:bookmarks-conversion:0 feature) is supported, use PEP storage.
• As a fallback, use XML private storage.

Implementation roadmap

Fortunately, the data structures in all three versions are almost the same. Thus, most code can be reused. The most complicated logic is the method choice.

• First remove the 'external Gajim option', since it is not used any more even by Gajim
• Finish the implementation of PEP Storage Bookmarks (XEP-0048) (currently #if 0-ed) and use PEP storage whenever conversion between legacy XML storage and PEP storage is announced (via urn:xmpp:bookmarks-conversion:0)
• Implement Native PEP bookmarks (XEP-0402)
  • Use it by default if the compatibility to XEP-0402 is announced (urn:xmpp:bookmarks:1#compat)
  • For full compliance with XEP-0402, store the optional <extensions> stanza. I don't know though whether other clients are actually using this.

For XMPP server devs it takes effort to maintain two sets of bookmarks and protocol translation between them, and they will eventually move on and completely drop XEP-0048.

Seems so far not even supported by ejabberd ;)

Well then, so we have a lot of time before this becomes critical :)

Would be good not to miss the boat when it does though.

Sure. But if servers didn't even implement it yet it's not like we need to be afraid that the will drop support anytime soon ;) So this "eventually" is quite far in the future.