Migrate Private XML storage data to PEP


Openfire uses Private XML Storage (https://xmpp.org/extensions/xep-0049.html) to keep private data like Bookmarks (https://xmpp.org/extensions/xep-0048.html). The preferred way of handling private data is through PEP.

Openfire should allow users to modify private data through both methods. A user should be able to modify the same set of private data through both means, allowing for older and newer clients to interoperate.




Guus der Kinderen
May 11, 2020, 1:30 PM

Although I readily admit that introduced this issue for you, continuing to discuss it in a closed JIRA ticket isn't ideal. I suggest we move this discussion to the community forum, and raise new issues (that can refer to ) after we identify distinct actions to be taken.

May 11, 2020, 1:21 PM

Thanks Dele, for looking into the issue.

Apart from new LDAP users one of the major issue I have is that:

"The Private storage via PEP service currently is not equivalent to old method of private Storage because the Private data through PEP service does not support data for users who are not already registered on OF"

We need both types of users: local end users (who have valid JID but don't need to login) and to have the use of Private Storage (as in previous versions of Openfire)...

as well as Openfire LDAP users (Authorised Agent users - who can make commands on behalf of such end users) 

Dele Olajide
May 11, 2020, 1:11 PM

This does not look like an easy issue to fix as PEP is based on pubsub and I don't think XEP-0060 allows non-registered users to create pubsub nodes. Maybe the solution would be to find a way to address the issue of why new LDAP users cannot have private storage until after Openfire is restarted.

May 5, 2020, 7:06 PM

My issue is not related to conversions of data in the PrivateStorage but to permissions.

The new PrivateStorage through PEP service does not support data for users who are not already registered on Openfire, and throws an exception:

Request must be initiated by a local, registered user, but is not: <end user JID>

and that is a major blocker for us when switching to the new service in OF later than Release 4.2 and above.




Dave Cridland


Guus der Kinderen