jdev - 2022-09-21

I think I've managed to forge a correct metadata publish thing, but for some reason xmpp clients don't seem to try and retrieve the actual avatar data. Can someone spot what's wrong in these 3 stanzas from the gajim XML console? Could it be I am missing a disco#feature thing? https://paste.sr.ht/~nicoco/0f9051db51f6c39739eb4f06c74cf3728a79f4dc

Run gajim -v and it will tell you what's wrong

thx for the idea lovetox: > Disco info malformed: dummy.localhost Caps hashes differ: I+de1e1XDUWqmfsV2dQlfugNNOk= != UYVitpA8UsRh8d2G0/8fsVQ9+Sc= damn these caps/disco/pubsub/pep things are sooooo hard to get right

lovetox, in these stanzas, the @to Gajim sends the disco#info to is wrong, right?

Why is it asking the domain instead of the account?

The second stanza should be to="baba@dummy.localhost" instead of to="dummy.localhost".

Link Mauve: dummy.localhost also has its own avatar, so I think it's OK that gajim sends this too?

Oh right.

But then that’s unrelated to baba@dummy.localhost’s avatar.

And might be your issue?

neither dummy.localhost's nor baba@dummy.localhost's avatars are requested. maybe the stanzas I posted were not cleverly selected by me, I apologize. it's still not clear to me which entity between the gateway component and "puppet JID" (baba@) needs to advertise which caps/disco. I'm trying to get rid of this caps hash warning for a start, but it feels I'm completely misusing slixmpp for some reason. ✏

nicoco_, I tested it using xmpp-rs’s generate-caps example, it returned ParseError("Required attribute 'type' must not be empty.")

See https://xmpp.org/registrar/disco-categories.html#gateway

Those are the allowed gateway types, you might want to add some once you support their services.

See XEP-0030 section 10.2.1.

hehe well, gateway types are pretty outdated, let's try and pretend this is AIM then :)

nicoco_, that’s why I said you may want to ask the registrar to add the ones you want to support.

thanks for the suggestion but I don't feel comfortable asking for anything "official" since all these disco/nodes/caps/pubsub/pep concepts are VERY blurry in my mind. up until now I had hacked something with vcard-temp and pushing roster items with their alias for nicknames, but now that I start trying to follow the "modern" XEPs, I'm starting to lose self-confidence. I need to do some reading probably ✏

Caps aren’t only for PEP, they tell other entities everything you support, so it’s quite important to get it right.

Otherwise, other entities won’t be able to tell what you support, and either send you things you don’t understand, or more likely send stuff that adhere to the very baseline of XMPP they think every other entity supports.

Basically disabling everything advanced in their UI.

nicoco_, with type="aim", xmpp-rs says your caps should be <c xmlns='http://jabber.org/protocol/caps' hash="sha-1" node="http://slixmpp.com/ver/1.8.2" ver="LzPKML/zA6ZRJRXL7xsQA4kemhE="/>.

And the intermediate string, after concatenation, is gateway/aim//The great legacy network (slidge)<http://jabber.org/protocol/caps<http://jabber.org/protocol/chatstates<http://jabber.org/protocol/commands<http://jabber.org/protocol/disco#info<http://jabber.org/protocol/nick+notify<http://jabber.org/protocol/nick<http://jabber.org/protocol/shim#SubID<http://jabber.org/protocol/shim<jabber:iq:oob<jabber:iq:register<jabber:iq:search<jabber:x:data<jabber:x:oob<urn:xmpp:avatar:data<urn:xmpp:avatar:metadata+notify<urn:xmpp:avatar:metadata<urn:xmpp:carbons:2<urn:xmpp:chat-markers:0<urn:xmpp:fasten:0<urn:xmpp:forward:0<urn:xmpp:message-correct:0<urn:xmpp:message-retract:0<urn:xmpp:reactions:0<urn:xmpp:receipts<urn:xmpp:reply:0<

yes, I managed to have caps correct, at least for the puppets, by accident after a lot of trial and error a while ago, and did not want to touch this part of the code anymore since then - clients send chat states, presences, markers, it was all good so it's a perfect time to break it all now =) but adding PEP support forces me to look at this stinky part of the code again, which is probably going to be a good thing in the end, but boy it is painful. it's probably extra confusing for a gateway that does not only have its own JID, but also puppet JIDs, and these puppet JIDs need to have some "puppet resource", then where do the "node" concept fit in this hierarchy is not clear to me, and well, maybe slixmpp's modules were not built with this extra complexity in mind too.

I hope that helps you debug your issue, if you don’t know what to do with these don’t hesitate to ask me for a more in-depth explanation!

nicoco_, PEP is only on the account, so on your puppets’ bare JID.

Their resources don’t appear there.

thanks for your help! I think I should not bother trying to generate the caps verstring myself, but try and understand how to do it properly with slixmpp's helpers, so maybe I'll shout some questions in slix's muc instead

Sure!

>nicoco_, PEP is only on the account, so on your puppets’ bare JID. hum ok that's interesting, because I remember having to advertise caps *with a resource* for clients to send markers and composing/paused chat states, but this is different for PEP, I did not realize that.

I’ve never used slixmpp for component, I usually write its plugins with only clients in mind, but XEP-0030 and 0115 predate my involvement by a lot. ^^

nicoco_, conceptually, a resource is a connected client (even if it’s fake in your case), a user can have multiple of those connected at a same time, each with a different featureset, so with different caps.

But PEP is entirely handled by the server, with no involvement of connected clients (that way your contacts can see your avatar even when you’re offline, for instance), so it lives on your bare JID.

Note also that in the case of avatars, it’s not about your puppets’ caps, but about their contacts’ caps.

So actual XMPP users.

They are the ones having the +notify.

slix's xep0030 and xep0115 are pretty hard to understand for my "hobbyist dev" brain. but I think I'll have to dive into them to implement some sort of "disco#items" access control to get things right in a "gateway with multiple users" context. although maybe not with what I understood about PEP yesterday. but maybe. but maybe not. ✏

"that way you contacts can see your avatar even when you're offline" which is funny because the audience of avatars is sometimes used to indicate offline-ness. Or maybe it's only in MUC because there is makes some sense of you don't keep a cache

MUC doesn’t really have the concept of offline participants, they are not participants any longer.

nicoco_, oh no I was wrong, the actual caps string is: gateway/aim/en/The great legacy network (slidge)<http://jabber.org/protocol/caps<http://jabber.org/protocol/chatstates<http://jabber.org/protocol/commands<http://jabber.org/protocol/disco#info<http://jabber.org/protocol/nick+notify<http://jabber.org/protocol/nick<http://jabber.org/protocol/shim#SubID<http://jabber.org/protocol/shim<jabber:iq:oob<jabber:iq:register<jabber:iq:search<jabber:x:data<jabber:x:oob<urn:xmpp:avatar:data<urn:xmpp:avatar:metadata+notify<urn:xmpp:avatar:metadata<urn:xmpp:carbons:2<urn:xmpp:chat-markers:0<urn:xmpp:fasten:0<urn:xmpp:forward:0<urn:xmpp:message-correct:0<urn:xmpp:message-retract:0<urn:xmpp:reactions:0<urn:xmpp:receipts<urn:xmpp:reply:0<

I forgot to copy the xml:lang="en" from the iq.

Link Mauve, can you confirm that I am getting things right here: - `baba@dummy.localhost/slidge` should have `http://jabber.org/protocol/chatstates`, `urn:xmpp:message-correct:0`, etc. in its `disco#items` for clients to send all the cool modern IM features and not just message bodys. - `baba@dummy.localhost` (bare) should have `urn:xmpp:avatar:metadata`, `urn:xmpp:avatar:data`, `http://jabber.org/protocol/nick` in its disco#items and nothing else (well vcard, user gaming, geoloc at some point, but let's try and get avatars working first) - `baba@dummy.localhost` (bare) will send to `test@localhost` (the actual XMPP user physical person, I heard there are still some left on earth) the `pubsub#event/avatar metadata` thing - hopefully, if everything's done right, movim/gajim/conversations/whatever will retrieve the actual avatar with an iq to `baba@dummy.localhost`, which `dummy.localhost` will receive -- this is where I'm stuck right now, this does not happen, but probably related to the disco/caps thing. - `baba@dummy.localhost` should send the iq reply with the base64 encoded avatar

about the caps string, I think slixmpp should handle that, and I should not have to generate it myself... but the xep_0030 module works in mysterious ways

It’s the xep_0115 module which generates it I think.

indeed, you're right

but I hope that if add all the disco features and call `await xmpp.pluging["xep_0115"].update_caps(jid=contact.jid)`, It'll work 🤞 ✏

but I hope that if add all the disco ~features~ items and call `await xmpp.pluging["xep_0115"].update_caps(jid=contact.jid)`, It'll work 🤞 ✏

nicoco_, first - you’re right. Second - no, the account JID should have a pep identity, an account identity, and the relevant PubSub features (those from the http://jabber.org/protocol/pubsub# namespace) but not the avatar and nick stuff.

Avatar and nick are for PubSub to expose, not for disco#info.

Third, fourth and fifth - are correct.

It’s likely that clients won’t talk PubSub to your account JIDs if they don’t advertise they are PubSub services.

>Avatar and nick are for PubSub to expose, not for disco#info. >clients won’t talk PubSub to your account JIDs if they don’t advertise they are PubSub services. I think this is the part I completely missed in my attempts to get this working so far. sounds like I've got some experiments to run with this in mind now. thanks again

i think you are all confused

if a client requests avatars or nick from pubsub, does not depend on any disco info

lovetox, it could check that it’s an actual PubSub service.

what? pubsub events come from the account

if i disco the account, i will not get a pubsub service disco back

You will actually get a category pubsub type pep identity, and various pubsub features.

the issue here is, his component sends a pubsub event to gajim, and gajim does not react like he wants

no disco will fix that

Link Mauve, ?! if i disco link@mauve.net i will get back type=pep?!?

Yes.

ah damn, we disco the resource, nobody discos the account

ok, yes gajim doesnt do this, i would also dont know why it should

if i get a event, i act on it

either on the other side is a pubsub service or i get an error

lovetox, a PubSub service could support the http://jabber.org/protocol/pubsub#presence-subscribe feature but not the http://jabber.org/protocol/pubsub#retrieve-items one.

But yes, handling an error is also fine.

your discussion got me even more confused, but stanzas are better than words aren't they? I fixed the caps verstring nonsense and to try and start simple, I am just trying to get the bridge component to correctly use 0084 for its own avatar (we'll see puppet JIDs later) gajim logs show that the pubsub#event seems correctly parsed ("Received avatar metadata: dummy.localhost - ...") but gajim does not try to "retrieve" the actual avatard data movim on the other hand, makes 2 iq gets: urn:xmpp:avatar:data and urn:xmpp:avatar:metadata, but for some reason the :data one is missing the "item id" so I guess there is still something wrong with identity/disco/namespaces or something any idea what's wrong with this? https://paste.sr.ht/~nicoco/f73001f408de0d46f386b6c69ed05f2a893e04c4 ✏

nicoco_, does Gajim support gateway avatars?

Where does it show it?

with vcard-temp, definitely!

https://upload.slidge.im:5281/file_share/Wi5sj8z8RB7J6yTOySVbpPHw/753b8ae3-24b3-4cc3-b12e-05d7ef77be7c.png

Ok.

this is with vcard-temp

edhelas, you may want to fix the missing item id in the urn:xmpp:avatar:data query.

gajim doesn't react at all, but movim seems to attempt to download the thing

nicoco_, why does Movim also iq get urn:xmpp:avatar:metadata? Didn’t you just send it an event with it?

I did, it does not make sense. I wonder if movim behavior is abnormal, or if my abnormal (?) stanzas trigger this abnormal behaviour

abnormal is the word

I’d expect the former, as your stanza from earlier looked correct.

any way, it's the million dollar question everytime I try to implement something: "is it my component or the clients that are non conform?"

ok let's try to reply to movim even if the retrieval request is non conform and see if it displays the avatar correctly

nicoco_, in the second stanza in your log, Movim actually requests all items on the urn:xmpp:avatar:data, it’s perfectly valid.

And you then should reply with all the avatar versions you have, possibly just one.

See XEP-0060 section 6.5.2.

ok let me try to reply correctly to movim then, thanks

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

the avatar is updated in the movim ui, yeehaa! not in gajim, though, I am unsure what's missing for gajim to retrieve the avatar. lovetox you're saying the component behavior is non conform and that's why it won't work in gajim?

no i didnt say that

i said you should read the log

but then you posted something about disco, which you found in the log, which was unrelated to the whole issue

oh ok well this other wild bug of my thing appeared out of the blue ^^

anything you see in this debug log that would explain why gajim doesn't try to retrieve the avatar? https://paste.sr.ht/~nicoco/4be6088c71a03e7a00f99ca63fa7fa42684511a2

yes it says

Avatar already known: dummy.localhost 238694fd6478dfe0a17297ff5758efb6fa6c47f0

thats why we dont download it, because its not new

why it is not displayed, maybe a caching issue, or you played around too much

try removing ~/.cache/gajim/cache.db ✏

and restart gajim

is the component added to the roster?

yes it's in the roster. it's probably the cache thing indeed, since my component responded with incorrect stuff before, it messed things up probably. will try with a clean profile and removing all gajim cache

and it seems to work. thanks a lot for your help!

i think the idea that you can have alternate formats in your user avatar is rather hard to use

the problem arises, because the id of the node = sha of the image/png content type

so you need to save that to know when the avatar changes

but if you dont use image/png, you download something else

which has a different hash

and then it becomes a problem, of how do i know i downloaded this already?

now you need to save in some db, the node id hash side by side with whatever you downloaded

hash i usually good to check if a file is really that file

but this is broken in this scenario

it becomes a, lookup that hash in some db that maps to the actual hash of some file

adding to that is that people thought the XEP actually want to provide a way to upload different resolutions of the same content-type

but this is not the intention of the XEP, its always about different content-types, not different resolutions of the same

if we look back now, how many clients actually implement pubilshing multiple types, and downloading multiple types?

probably none

and, if i think about, how would you add or update a content-type which is not image/png

you are not allowed to change the node id, because it always is the hash of the image/png type

so you cannot communicate updates

ah no that works, because the hash is inside the info element

so you simply have to ignore the node id

and check all the info items

FWIW, I've taken the "let's make everything a PNG" road, since I needed the conversion for the hash anyway, I figured let's keep things simple. premature optimization blablabla ✏