jdev - 2022-12-02

Hey yarmo, welcome :)

Hey folks! I was having some problems with performing vCard retrieval requests and I was hoping to get some advice here :) I'm sure the problem is between chair and computer

I tested the following with a 404.city account. I set some vCard data years ago and have recently changed it. I'm trying to fetch this data. If I do a vcard-temp request as per https://xmpp.org/extensions/xep-0054.html#sect-idm46197103143648, I get the old data back. I don't understand why, this could be an issue with 404.city, I'm not sure. If I do a vcard4 request as per https://xmpp.org/extensions/xep-0292.html#self-iq-retrieval, I get "no module is handling this". Makes sense since XEP-0292 is deferred. I can get the correct updated vCard data through pubsub but this requires a presence subscription. So far so good. But then, how does something like mov.im fetch vcard data? When I visit my public page on mov.im, it has the updated data so somehow it can fetch the vcard4 data without needing a pubsub subscription. Or am I thinking about this wrong?

If you publish new vcard data (including getting a response saying it was successful) and then you fetch it back and it's still the old data, it's a server bug

The deferral of XEP-0292 (or any experimental XEP) is not a good indicator of much, other than the document hasn't been updated for a while. Various projects are moving over to XEP-0292, and we've been discussing some updates to the XEP that will cause it to leave the "deferred" state

In particular I think we're mostly all agreed that the dedicated iq protocol there should be removed, and you should just fetch the vcard using a normal pubsub item fetch (there's no reason to have two methods for the same thing)

and that leads me to the final thing about whether you need a subscription: you don't, necessarily

One reason behind pushing XEP-0292 forward is that the vcard-temp XEP didn't really discuss much about who should be able to access a user's vcard

One of the benefits of vcard4, or specifically about storing it in pubsub, is that it allows for more flexible permissions, giving users control over who their profile is shared with. ✏

However with XEP-0292 this is explicitly configurable, as pubsub has access control built in

IIRC both XEP-0054 and XEP-0292 says all vcards must always be public for the world, which is one of the things that ought to be changed.

I think most people don't want/expect their vcard to be completely public. From a privacy perspective, profiles should be opt-in, at the very least.

(it does not say that you can't return different vcards to different people in the world though; but yah, that's a lot of client complexity that pubsub already handles)

Sam, the vcard is returned by the server, and there is no protocol for the client to select what should be returned to who - so while things could be selectively disclosed, that would be up to the server implementation/deployment

Pubsub (in the PEP profile used for vcard4 here) defaults to only allowing access to contacts, which is reasonable, but explains your presence subscription requirement.

oh, right, been ages since I've looked at that; ignore me.

Agreed it's imperative that sharing vcard data is/becomes opt-in.

So maybe this is a dumb question, but how does mov.im get my vcard data then?

edhelas, what spec(s) does Movim use for vCards?

The pep based one

vcard-temp or vcard4-over-xmpp?

vcard-temp is not PEP/PubSub

The PEP one would be vcard4-over-xmpp (XEP-0292)

I did a little bit of movim codebase digging but I'll guess I'll need to go in again :)

Tho it gets fuzzy if you have the server convert between them. Dunno if ejabberd has this, but Prosody does.

So just for my understanding: vcard4-over-xmpp through pubsub should require a presence subscription. Movim uses vcard4-over-xmpp, but without needing a presence subscription from the profile it's showing (I don't recall having to accept a movim-related subscription)

yarmo, are you talking about you logging in with Movim into your own account and seeing your own vcard?

No no, without logging in

where and when exactly?

(tho here edhelas probably knows more than me)

I can open https://mov.im/?contact/yarmo%40404.city without being logged in and it will show me my vcard data

(I'm only putting public data in there) ✏

It could be using the vcard-temp data, which is public.

It must be. So then I must be doing something wrong, because if I request vcard-temp data, it's outdated, must be a problem in my request, I'll investigate

When I request your vcard-temp, I don't get what shows on mov.im

Yeah, you get the "This is an OpenPGP proof..." data, correct?

Yep

I'm so confused

Caches? Uh

and when I request your vCard4 from PEP I get a <presence-subscription-required> error

I think we'll have to wait for edhelas to explain where this data is coming from on mov.im

yarmo you decided to put your profile public

https://upload.movim.eu/files/9d94237298995552fa13436420195fbca436dce7/Z1fM6Xf1elNS/image.png

I see that the value is true in the DB

Ok, I think I understand it now. I was still logged in on mov.im in a different browser. So while I wasn't using that browser session, mov.im still uses that session to sync my data. Once I logged out, mov.im's data was getting stale, not showing updated vCard data

Would this make sense?

It's from the cached data yes

Thanks, this solves something that has confused me for a while

Now I'll need to talk to 404.city and ask why their vcard-temp data is years old

Set by an old client and Modern™ clients don't look at it or let you edit it?

I also note that vcard4-in-pubsub requires nothing of the server, it's just another piece of data stored in pubsub. You can put anything there.

(nothing beyond existing pubsub/pep services which are part of xmpp baseline requirements)

Zash, it's not like Prosody (or ejabberd, I think) ever validated vcard-temp contents :)

MattJ, true. But you can't just create another datatype under a different namespace at will, not the way PEP lets you.

Sorry to bother again, but it's not just 404.city 🤔 Take this account on the movim.eu instance: https://mov.im/?contact/danie_vdm@movim.eu and look at the little bio in the top right. If you fetch its vcard-temp data, it's different.

Well, we've established that the data shown on mov.im is not necessarily indicative of anything (it's served from a cache, and from PEP, not vcard-temp)

yarmo, some clients moved away from vcard-temp

means old data is stored there, but not used by anyone, until you log in with some client who uses it

im pretty sure movim uses vcard4

One day in the future, we'll may simply disable all the vcard-temp modules

In the mean time, it's painful transition time.

as for example Gajim, if you edit your vcard on Gajim or Movim, we will only update the Vcard4, the vcard-temp stays old

I understand. Right, so it's not simply a cache issue. vcard-temp data will never be updated again, all clients now update vcard4 data. Ok, that makes sense

Getting away from the "temporary" vcard spec is going to take some time, you will likely see both for a while.

temporary since 2002...