jdev - 2022-10-13

I think a proper way forward would be to remove the “simple iq” flow and instead move to proper PubSub everywhere.

If existing implementations don’t even use it as specified, it can be changed with no downside.

vcard4 also ought to not mandate everything be public and have some words on how pubsub access controls can be used

Link Mauve: Is it a valid ‘pubsub flow’ to broadcast an empty item on updates and then return the actual item on retrieval requests, or would this part of the XEP need changing too? In other words, would removing the simple iq flow mean that the full vcard has to be broadcasted on every update? (This is what movim expects atm)

nicoco_, PEP used to only support full notifications, based on +notify in the caps, but nowadays you can change your subscriptions to not include those IIRC.

Modern “PEP” is pretty much the full XEP-0060 as exposed by servers.

Requiring a different payload configuration in this one node doesn’t sound very good though.

In XEP-0163 §5, “A PEP service MUST: […] Default the 'deliver_notifications' configuration option to true (i.e., deliver payloads by default).”

_default_

To not require a special config for ‘full pubsub vcards’, we would need something similar to avatar:metadata and avatar:data, am I understanding this right?

There are XEPs that specify different node configuration, vcard4 could do so too.