-
dpes
how can we query chat history between two user from react.
-
Link Mauve
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.
-
pep.
So what is is there in the “MUC reliability kit“ apart form.. resyncs? 0410?
-
pep.
Ah 0045 says MUCs may also ping participants sometimes to ensure they're still there. So.. it goes both ways? :-°
-
Ge0rG
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 ;)
-
pep.
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
-
pep.
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..
-
Link Mauve
Ge0rG, well, it’d increase resource consumption by a lot for mobile users who are in many MUCs, especially at night.
-
pep.
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
-
Link Mauve
Is it an issue to see them get kicked on a chatstate?
-
nicoco_
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?
-
Link Mauve
nicoco_, the component should.
-
nicoco_
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
-
nicoco_
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.
-
Link Mauve
nicoco_, you should remove the @to.
-
Link Mauve
Currently it’s the client sending to itself.
-
Link Mauve
It should send to its account instead.
-
Link Mauve
As that’s where the PEP service “resides”.
-
Link Mauve
Ah, but that’s for publishing your own nickname, while you’re actually interested in broadcasting said node’s content to other people.
-
Link Mauve
Is your component already handling presence subscription properly?
-
Link Mauve
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.
-
nicoco_
I force push puppet jids item into the xmpp user's roster with "subscription": "both", that should work, shouldn't it?
-
Link Mauve
See example 6 of the XEP (without addresses, no one uses that nowadays).
-
Link Mauve
nicoco_, if you receive presences from the XMPP user, then yes.
-
nicoco_
this works, yes
-
nicoco_
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?
-
Link Mauve
No, it’s the account JID of your fake user which should implement PEP.
-
Link Mauve
PEP is basically PubSub on a user’s account.
-
Link Mauve
(It originally was a small subset of PubSub, but implementations kept adding stuff until it required basically full PubSub support.)
-
nicoco_
hum ok, so prosody's pubsub.localhost never comes into play?
-
Link Mauve
No, it doesn’t.
-
nicoco_
oh ok I misunderstood your first answer then.
-
Link Mauve
My first answer was based on that I thought you wanted to publish the nick, as you originally asked about.
-
Link Mauve
I didn’t notice you actually want to be a PubSub implementation.
-
Link Mauve
Possibly just for events for now, so that’s quite simple.
-
nicoco_
great, it seems to work! https://paste.sr.ht/~nicoco/eb3d02e0abe2e3890cd70ae8cc5ba1abeac312cc → gajim and movim both update the puppet nickname. thanks a lot
-
Link Mauve
:)
-
Link Mauve
You probably want to make it type="headline" though.
-
nicoco_
oh OK, good to now✎ -
nicoco_
oh OK, good to know ✏
-
nicoco_
is it going to be similar for xep0084 (avatars), again, nothing to do with the prosody's pubsub component?✎ -
nicoco_
is it going to be similar for xep0084 (avatars), again, nothing to do with prosody's pubsub component? ✏
-
Link Mauve
Yes.
-
Link Mauve
Except you’re going to have to also handle requests for avatar:data, not just notifications to avatar:metadata+notify.
-
nicoco_
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.
-
nicoco_
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
-
Link Mauve
nicoco_, correct.
-
Link Mauve
Avatar hash, format, width, height, etc.
-
nicoco_
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.
-
Link Mauve
Yay!
-
Link Mauve
Die vCard-temp, die!