jdev - 2020-11-07

hm that avatar conversion XEP did not really think about clients that want to support vcards

it seems the thought was, vcard is only used by legacy clients so they set their avatar with the vcard and we convert it

do we need a XEP about the thing Prosody does with vcard-temp → vcard4 conversion?

but how do is set a avatar, if i want to support vcard and iam not a legacy client

Use XEP-0084?

yeah i just did

and what happens is, i publish with 0084, afterwards publish my vcard

ups my avatar is gone now

no i have to now publish my avatar with 0084 and at the same time have to put it into the vcard

fantastic

and all because of anonymous mucs

we really should have gone the way, yeah anonymous means anonymous, so no vcard, no avatar, nothing

thats what anonymous means

to be pedantic, we already got rid of anonymous mucs, what we have is semi-anonymous :)

omg i want to deactivate that conversion

With Prosody, you can. Tho you may get nice enough behavior by publishing vcard as vcard4 instead of vcard-temp

why because there is no conversion yet?

actually i want to switch to vcard 4

but we dont need conversion there really do we?

a client that supports vcard 4 is not legacy, and can do his own avatar publishing

Interop with legacy clients

yeah but for example i want to publish my vcard 4 with access=presence

but my avatar with access=open

You can, if you talk PEP directly

yes i know i can

but what does the conversion mod then?

Nothing

The prosody legacy vcard compat module syntesizes a vcard-temp from vcard4+pep avatar on request.

And it respects the access modes on each of those, so if you configure the vcard with access=presence you get a vcard-temp with only the avatar.

ok thats nice

It is a problem that you have no way of knowing this tho

and is there a conversion happening from vcard4 -> pep avatar?

There are older vcard compat modules that only re-publish the avatar but it's still vcard-temp natively

No

ok thats good

mental note, never implement something like that

ok so that means

i can use vcard4 and publish my vcard without avatar

and the server will not delete my 0084 avatar

thank god !

Hehe, part of the goal of this was to make vcard4 more attractive :)

vcard4 is attractive enough only because of the fact that you can make the data private

Yeah, that is nice

ok thanks, means more work needs to be done now, but at least there is a sane path

Maybe the lack of privacy controls in vcard-temp is why so many clients these days only use it for teh avatar

My issue with vcard4 is that it still isn’t fine-grained enough.

It’s either available to some entity or not.

I think that's an issue with PEP as a whole

Yes.

And maybe PubSub

goffi added an extension to fix that in his server, but he never wrote the spec.

oneSocialWeb had something like this as well

Link Mauve, why there is whitelist or not?

but to be honest, it seems a bit too complex for the normal user to manage who can see his vcard

lovetox, for instance I might want my email address shared with all my contacts, but my home phone number only with the family group, and the work phone number only with the work group.

haha

ok thats insane

If the prosody vcard/avatar conversion mod finds that the requester does not have access to the vcard4 node, it checks if they can read the nickname node and if so, adds that to the vcard-temp

lovetox, instead of insane, I’d say mandatory for most usecases.

you want per field access

Yes, pretty much.

i just think about the UI, and i would not even want to start it :)

Try https://linkmauve.fr/xmpp-account-manager/build/en/ for a UI example.

it shows a loading icon

then nothing happens

ah wait

jid was wrong

but its probably not hard to do with vcard4

you can add a custom attribute <roster-group> to the items

and then the server has to do the rest

IFF the server advertises support

lovetox, seen this thread? https://mail.jabber.org/pipermail/standards/2020-February/037073.html

hm xep 0292 does not use pep?

i always thought the IQ is just a legacy access method

but we use pubsub for vcard4

i wondered about this a few times

i just publish the vcard4 to pubsub

i dont use the IQ

The iq was added for the MUC use case.

Except, it doesn't work.

community consensus is that storage via IQ is more backward-compatible with XEP-0054, and that publish-subscribe is more appropriate only for event notifications.

vcard-temp only works in MUC because of an undocumented hack that all servers implement.

i interpret this sentence as "You should not publish a vcard via pubsub, use IQ "

So you would need to do the same for vcard4 and/or PEP

The Prosody mod_vcard4 is just a very thin layer over the PEP get/set methods.

ok so thats what i thought, i just use pubsub, and it should work as expected

It can act as a bandwidth optimization I suppose.

Or if you have a client that does not support PEP (are there even any?) then it's probably easier to use the vcard4 iq

vcards are rarley changed, so there is no need to be efficient

https://xmpp.org/extensions/xep-0292.html#self-iq-retrieval vs https://xmpp.org/extensions/xep-0060.html#subscriber-retrieve-requestall

So, yeah, not much of a difference