XSF Discussion - 2021-01-16

Zash, MattJ is it somewhere written down what the avatar conversion module logic is

regarding respecting access controls of pubsub

when someone querys a vcard-temp

It essentially translates the vcard request to PEP requests, so the access control is the same

so if your PEP node(s) are contacts-only, only contacts will be able to query vcard-temp

for example

ok for requests this is probably easy

what about publishing, what if i publish with vcard-temp an avatar

would that change my pubsub access-model to open?

i guess not

https://hg.prosody.im/trunk/file/tip/plugins/mod_vcard_legacy.lua#l157

If the node doesn't exist, it will be open by default (because that's the traditional behaviour of mod_vcard)

But if it is configured, the existing settings will not be overwritten

yeah sound sane

I ask because i was talking about it with Holger, because ejabberd does not have that logic yet

so its basically, if a node exists apply access control also to the vcard-temp module

if not, just do as always

Yep. It helps to consider that the vcard-temp module is now doing nothing except translating the request to a PEP request

or a save to a PEP save

Sounds also easier than maintaining 2 storages and trying to sync them

Definitely

So temp is going to not be temp soon

Except now it's used for MUCs as well.

And participant avatars in MUC are weird

I have a PEP question, would it be possible to expose PEP nodes on a server’s JID, and would it be a protocol violation to allow multiple publishers there (e.g. server admins)?

mathieui, isn't that just plain ol' pubsub then?

or, how much of the automagic subscription stuff do you need from PEP?

Zash, well, I guess that’s just pubsub, I’m only interested in the +notify

(and discoverability)

Depending on how much PEP is just pubsub with some sensible defaults... tho a big thing is being attached to your account

Except for +notify, at least with Prosody, you pretty much get that by loading mod_pubsub on a normal host.

The only thing is that this is something I would like to have easily implemented in clients as a receiver role, so it’s better if it does not require more features

but I guess that canb be specified without too much of a hassle

(publishing is another matter, but this could be an adhoc command too for all I care)

> would it be a protocol violation to allow multiple publishers there (e.g. server admins)? no, not a protocol violation, just a matter of how much of pubsub you support

Does PEP even mandate the affiliation management parts of pubsub?

Huh!

> A PEP service MUST: > - Support the "open", "roster", and "whitelist" access models.

I thought 'open' and 'whitelist' were optional.

another question would be; is a pubsub node on the base server JID something possible at all in current implementions? ✏

Prosody can. Ejabberd docs doesn't seem to say you can't, but don't know.