-
nicoco
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 clients' behaviour? - 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.✎ -
nicoco
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. ✏
-
nicoco
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
-
edhelas
nicoco https://github.com/movim/movim/blob/master/app/Contact.php#L205
-
edhelas
I don't parse those fields
-
edhelas
But I can
-
nicoco
oh, but the FN field seems parsed
-
nicoco
so there is probably something wrong in iq result I pasted, because I don't see its content anywhere in movim's UI...
-
edhelas
It should
-
edhelas
https://github.com/movim/movim/blob/master/app/Contact.php#L274
-
edhelas
https://github.com/movim/movim/blob/master/app/widgets/Vcard4/_vcard4_form.tpl#L40
-
nicoco
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)
-
nicoco
FWIW, here's what the "contact profile" looks like in movim:
-
nicoco
https://upload.slidge.im:5281/file_share/FadP2ngn4fkYt9iEuIQouylx/6b3918a9-fecc-4a9c-9f6c-5623c659c3cb.png
-
nicoco
and in gajim:
-
nicoco
https://upload.slidge.im:5281/file_share/RDYKuXmbv7ORaFiGH0vuOqEV/e15cb197-ee26-42c4-9d79-4cabdc84343b.png
-
nicoco
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 ^^
-
nicoco
une histoire de bare/full JID ptet?✎ -
nicoco
. ✏
-
nicoco
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
-
edhelas
When you're the first one to implement the standard, YOU ARE THE STANDARD
-
edhelas
:3
-
nicoco
hehe, well. the XEP is "Deferred", I wonder if it's worth bug reporting given that?
-
nicoco
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…
-
edhelas
sure 👌
-
pep.
nicoco, please do report. Deferred means nothing more than "it hasn't been updated in a year", which is actually very commun.
-
pep.
#RemoveDeferred
-
pep.
common*
-
nicoco
alright pep. will do, probably this evening
-
MattJ
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
-
nicoco
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.
-
nicoco
I agree that it's weird ^^
-
edhelas
I don't get this flow
-
edhelas
Movim is doing the basic Pep thing
-
nicoco
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
-
lovetox
nicoco, what for are you doing this? i know nobody who subscribes to vcard events
-
nicoco_
lovetox: my goal is just to provide some sort of ‘user profile information’ for the bridged contacts, that’s all :)
-
nicoco_
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.
-
nicoco_
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
-
lovetox
hm yes, was probably not really reading the XEP
-
lovetox
you probably want pubsub handling stuff on your bridge anyway
-
lovetox
like vcard will not be the last thing
-
lovetox
so much is on pubsub
-
nicoco_
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 ^^