jdev - 2022-10-13


  1. Link Mauve

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

  2. Link Mauve

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

  3. Zash

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

  4. nicoco_

    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)

  5. Link Mauve

    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.

  6. Link Mauve

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

  7. Link Mauve

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

  8. Link Mauve

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

  9. Zash

    _default_

  10. nicoco_

    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?

  11. Zash

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