jdev - 2022-01-06

For IBB XEP-0047 (IBB) section 2.2 says that if the sequence number has been used we return unexpected-request. It also says that if anything is received out-of-sequence to close the bytestream. If you get a sequence number larger than expected, is there no error? Just a cleanly closed bytestream?

I feel like the same error should be sent no matter what if you get a bad sequence, not just "close the bytestream as described in the next section"

That was probably the intent, I guess

yep, we should probably "Because the sequence number has already been used or is larger than expected" write there

Or just remove the whole paragraph about closing it if the sequence number is wrong

My two client instances aren't announcing devicelists to each other (and therefore bundles either), can i clarify what exactly triggers pubsub to send updates?

Your client must implement disco (XEP-0030), caps (XEP-0115) and advertise support for the feature '<node name>+notify'

https://xmpp.org/extensions/xep-0163.html#example-4 and surrounding text

MattJ: So, I already do send out `<feature var="eu.siacs.conversations.axolotl.devicelist+notify"/>`, with a caps ver that is just set to the current time so it's always fetched fresh, but in response, nothing comes back? That's the server's duty no?

Also ``` <identity category='account' type='registered'/> <identity category='pubsub' type='pep'/> ``` is missing from my disco result, maybe its that

from your account?

Yes

Apparently it's not mattered til now

wait what

> caps ver that is just set to the current time u wut

https://xmpp.xa0.uk:5281/upload/QJSdwi8Q0cO6dgjt/20220106_190217400_4f8d.jpg

https://xmpp.xa0.uk:5281/upload/ROc4TtlZ_hzfvVnM/20220106_190235490_9292.jpg

Hate me :p

It was a debug build hack that ive yet to correct

Didnt seem to break anything either, til perhaps now

ah, node, not the actual `ver=`?

Oh

or

OR

why is there a screenshot of code here

To show the logic

I build the node from http://weechat.org# + current time with zeros padding + =

Tldr it means the server always disco requests me, aiui

Thanks I hate it

🙃

Right, so im ok on the identity thing, thats the disco for the bare jid, and it returns correctly, with pep

qy: I don't know without looking, but if you're not doing XEP-0115 then I don't know if you can count on it working correctly in Prosody at least

Understandable. It didn't break so far, and all the other features work, so i've not been in a rush to sort that

Consider this incentive to not spam the XMPP network with disco queries and responses 😉

Conscious of the fact that that part of my code has the line `// This is utter bullshit, TODO: anything but this` too anyway 👀

:)

JDev doesn't have a MUC Avatar :(

😜

https://aria-net.org/_matrix/media/v1/download/aria-net.org/PYJDZOmjxvokbVlLtFfoQEaV

I don't see it, is that a clientside hack

sort of

all the cool MUC have a MUC Avatar

Doesn't appear in Conversations 😶

Right, caps vaguely sorted. No more spam at least

So, iqs are going through with unique ids and to and from, devicelist sets are getting a response, but my two clients arent sending each other devicelists, not sure what's up

Your clients don't "send each other" devices lists

pep.: The server does, right?

Yes

With devicelist+notify

That

Yeah, thing is, thats not happening

You can test with something else that's not devicelist maybe. Try avatars?

Well, i kinda have, "urn:xmpp:chat-markers:0" is on and that works... do you mean if i have "urn:xmpp:avatar:metadata+notify and i update my avatar i should see it too?

As a new presence

0084? urn:xmpp:avatar:metadata+notify

Yeah

Not as a new presence

https://xmpp.org/extensions/xep-0084.html#process-subnotify

You do have presence subscription to that jid right?

I'm honestly not sure anymore

(Otherwise they'll likely never check your caps, or won't be able to, and you won't get notified) ✏

(Hang on, ive a feeling im missing something obvious)