jdev - 2022-10-11

Hey all! I have been trying to implement XEP0292 (vcard4) for my bridge component. If I understood it right, clients should use `<iq get <vcard` to retrieve vcards and PEP is only used to broadcast the "vcard has been updated" event, but not the actual vcard content. Gajim, instead of using a `<iq get <vcard xmlns='urn:ietf:params:xml:ns:vcard-4.0'`, sends a `<iq get <pubsub <items max_items="1" node="urn:xmpp:vcard4"...`, and expects the vcard to be served as a response to this, wrapped in `<pubsub<items<item id="current"` (I tested, it's displayed as expected in the UI). The spec is not clear (to me at least) on what the answer to this `<iq get<pubsub<items` should be, but I *think* it should only be an empty item with `id=current` and then the client should use the non-PEP `<iq get<vcard` syntax. I also experimented with movim, and it seems to also only use PEP mechanism, no direct iq get>vcard. For some reason, even if movim's iq get>pubsub>items is replied with the same thing as gajim, I did not manage to display the vcard content in its UI. This raises several philosophical questions: - are clients not following the spec or am I not able to understand it right? - should my component strictly follow the spec or have workarounds for various clients' behaviours? - why such a complex mechanism involving both "basic" iqs and "pubsub" iqs for something as basic as a "profile information" for a JID? - should I broadcast the full vcard or just an empty item id="current" when (a) my component gets online, (b) when XMPP clients get online? - what is the meaning of life? Thanks for following my ted talk. ✏

edhelas: before flooding your issue tracker even more than I already did, could you have a look at this iq get/result pair and tell me if you spot something that would explain why I cannot see the given/surname/telephone fields in movim's UI? Maybe you just don't display these fields? https://paste.sr.ht/~nicoco/aa9a2b809038c846ad7d5a00bedc2eebce418e6e

nicoco https://github.com/movim/movim/blob/master/app/Contact.php#L205

I don't parse those fields

But I can

oh, but the FN field seems parsed

so there is probably something wrong in iq result I pasted, because I don't see its content anywhere in movim's UI...

It should

https://github.com/movim/movim/blob/master/app/Contact.php#L274

https://github.com/movim/movim/blob/master/app/widgets/Vcard4/_vcard4_form.tpl#L40

it looks like it fell back to userpart, so the vcard/fn was not parsed for some reason. (btw, shouldn't you fall back to the pep nickname instead? it's inconsistent with the chat list view where the pep nickname is used)

FWIW, here's what the "contact profile" looks like in movim:

https://upload.slidge.im:5281/file_share/FadP2ngn4fkYt9iEuIQouylx/6b3918a9-fecc-4a9c-9f6c-5623c659c3cb.png

and in gajim:

https://upload.slidge.im:5281/file_share/RDYKuXmbv7ORaFiGH0vuOqEV/e15cb197-ee26-42c4-9d79-4cabdc84343b.png

I guess wondering if you can't read a spec, if your implementation is buggy, if the server does something weird, if client X is not following the spec or if you uncovered a bug in client X is just the normal xmpp dev process ^^

. ✏

ok, gotcha movim, you expected the payload to be in the pubsub#event. all in all, as far as I understood, neither gajim nor movim really respect this then: > There is no payload, because this is a pure notification (the receiver needs to retrieve the vCard using an IQ-get as described earlier) * The fun part is that they don't respect it, but in different ways: movim wants the payload in the pubsub#event, and gajim wants to retrieve the payload via iq get/pubsub/item instead of iq get/vcard * https://xmpp.org/extensions/xep-0292.html#sect-idm45669698174224

When you're the first one to implement the standard, YOU ARE THE STANDARD

:3

hehe, well. the XEP is "Deferred", I wonder if it's worth bug reporting given that?

edhelas: I'll definitely add a feature request to your tracker to parse the "telephone" field because I went through all this vcard bulls**t just so that my signal and telegram puppets have their phone number accessible somewhere…

sure 👌

nicoco, please do report. Deferred means nothing more than "it hasn't been updated in a year", which is actually very commun.

#RemoveDeferred

common*

alright pep. will do, probably this evening

nicoco: that vcard4 has a separate IQ flow is weird and it has been brought up before. It's not much extra work to support on the server side, but it's unnecessary

MattJ: the spec is explicit that pubsub#event should not contain the vcard content but just be used as an "update notification" and that the separate IQ flow is *the* way to retrieve the data. I am not even sure that pubsub#retrieve is supposed to return anything, but I may be mistaken.

I agree that it's weird ^^

I don't get this flow

Movim is doing the basic Pep thing

it looks like another way of implementing what avatar:metadata and avatar:data do, but here: - there is no distinction between metadata and data, so servers emit an event that looks like data, but is actually empty, it's just a notification - to retrieve the actual data, clients should not use pep, but the separate IQ flow - vcard payloads should not be that huge, should they? oh right, they can include pictures, so they can be… but that's not the recommended way to set avatars in XMPP

nicoco, what for are you doing this? i know nobody who subscribes to vcard events

lovetox: my goal is just to provide some sort of ‘user profile information’ for the bridged contacts, that’s all :)

It turned out to be more challenging than I expected, but it seems to work now (at least for gajim and movim). I attempted some sort of test-driven dev, but it turned out my tests did not cover what gajim and movim actually needed to retrieve/display the vcard, which was disappointing.

lovetox: for instance, gajim uses iq get/pubsub/items but the spec explicitly describes a non pubsub, iq get/vcard that is meant to be *the way*. The pubsub part is supposed to be here *just* to notify vcard updates. I actually don’t really want that, but gajim forced me :P

hm yes, was probably not really reading the XEP

you probably want pubsub handling stuff on your bridge anyway

like vcard will not be the last thing

so much is on pubsub

Agreed, I want pubsub for other stuff anyway (but I’d have been happy leaving it out for vcards). Can’t wait to implement the gaming XEP with steam and discord bridges and then file feature requests because I don’t think any client implement that ^^