jdev - 2022-09-20

how can we query chat history between two user from react.

dpes, are you a client, connected as one of these two users? If so, have a look at XEP-0313, or a library which implements that.

So what is is there in the “MUC reliability kit“ apart form.. resyncs? 0410?

Ah 0045 says MUCs may also ping participants sometimes to ensure they're still there. So.. it goes both ways? :-°

A MUC could probably do that after a while of not forwarding stanzas. Otherwise, whenever I start typing in a large but calm room, I see dozens of users get kicked due to s2s errors from delivering my typing notification ;)

Also for 410, I still need to check whether the requestor is joined or would be able to, to answer anything useful. So I actually know if they're joined and I could reply something more useful than <item-not-found/> if they've pinging the wrong nick because another resource changed it

But I also don't know if that ping was meant to check if they're still connected because there's nothing to indicate intent..

Ge0rG, well, it’d increase resource consumption by a lot for mobile users who are in many MUCs, especially at night.

Except 410 gladly overwrites the behaviour of pinging participants (even for non-supporting clients) so it might make sense just to return a prsence from another occupant with a successful pong

Is it an issue to see them get kicked on a chatstate?

I am trying to use xep-0172 (user nicknames) and I can't seem to get it right. the context is that I want "puppet JIDs" for a bridge component to be able to set and update their nicknames. how should this be implemented? should I rely on the xmpp server's pubsub component? or should my bridge component act as a pubsub component itself?

nicoco_, the component should.

thanks Link Mauve. Does that look good like a good "new nickname" stanza https://paste.sr.ht/~nicoco/fa6310b495528200b667522c132a986f6c179ffd ? clients don't seem to receive anything. I'm having trouble understading the PEP basics

I basically just used slixmpp's `xmpp.plugin["xep_0172"].publish_nick(n, ifrom=some_puppet_jid)` but I am probably missing something, probably trivial, to wrap my head around how this all works.

nicoco_, you should remove the @to.

Currently it’s the client sending to itself.

It should send to its account instead.

As that’s where the PEP service “resides”.

Ah, but that’s for publishing your own nickname, while you’re actually interested in broadcasting said node’s content to other people.

Is your component already handling presence subscription properly?

If so, you should be receiving caps in the presence of users subscribed to your fake accounts. You then query their disco#info from the caps node, and if they have the http://jabber.org/protocol/nick+notify feature in there you send them a PubSub event containing your nickname.

I force push puppet jids item into the xmpp user's roster with "subscription": "both", that should work, shouldn't it?

See example 6 of the XEP (without addresses, no one uses that nowadays).

nicoco_, if you receive presences from the XMPP user, then yes.

this works, yes

so, example 6, but isn't that something that pubsub.localhost is supposed to send? what the bridge component must "forge and send" is Example 5 isn't it?

No, it’s the account JID of your fake user which should implement PEP.

PEP is basically PubSub on a user’s account.

(It originally was a small subset of PubSub, but implementations kept adding stuff until it required basically full PubSub support.)

hum ok, so prosody's pubsub.localhost never comes into play?

No, it doesn’t.

oh ok I misunderstood your first answer then.

My first answer was based on that I thought you wanted to publish the nick, as you originally asked about.

I didn’t notice you actually want to be a PubSub implementation.

Possibly just for events for now, so that’s quite simple.

great, it seems to work! https://paste.sr.ht/~nicoco/eb3d02e0abe2e3890cd70ae8cc5ba1abeac312cc → gajim and movim both update the puppet nickname. thanks a lot

:)

You probably want to make it type="headline" though.

oh OK, good to know ✏

is it going to be similar for xep0084 (avatars), again, nothing to do with prosody's pubsub component? ✏

Yes.

Except you’re going to have to also handle requests for avatar:data, not just notifications to avatar:metadata+notify.

thanks for the clarification, I was reading the XEP again and it seems like it is going to be substiantially more work than the nickname thing. notably I should make sure to base64 encode a png version of the image if I read it correctly.

so if I understood correctly, I should send events just like the nickname thing for the avatar hash, and then respond to avatar:data requests with the actual image data

nicoco_, correct.

Avatar hash, format, width, height, etc.

thanks for your help Link Mauve! slidge migration from 'vcard-temp' to 'user avatar' is not going to happen tonight I fear, but at least now I understand the basics.

Yay!

Die vCard-temp, die!