-
pep.
singpolyma, poking here as you're not in movim@, I'm curious what's the use for 0033 in Movim.
-
pep.
Or this isn't MUC-related at all?
-
pep.
Just some unspecced-group thing?
-
singpolyma
It could be used in MUC, though it's more common to just put the jid in presence and make the client look it up that way. We do use it outside of MUC context as well yes
-
singpolyma
For the email and MMS bridges (MMS is just email anyway so these are similar)
-
nicoco
Is this correct? (not a quizz, just want to make sure I get it right ^^) > I am a pubsub server; I should keep track of which event I've sent to which entity. When an entity comes online, I should only send them events that I haven't sent them previously. Related question: how bad is it if I send all my pubsub events everytime an entity comes online, not keeping track of whether I've already sent them the same event? (in practice, this is about PEP avatars (metadata) and nicknames)
-
MattJ
Only send the last published item
-
MattJ
https://xmpp.org/extensions/xep-0163.html#notify-when
-
MattJ
See those two sections
-
nicoco
the last item, no matter if I've already sent it before? xxx@xxx/dinoYY comes online 50 times in a row, I sent the pep nickname 50 times, that's OK? I guess this makes sense because I have no guarantee that dinoYY is actually the same client, and also it may have cleared its local cache between two "getting online" events.✎ -
nicoco
the last item, no matter if I've already sent it before? xxx@xxx/dinoYY comes online 50 times in a row, I sens the pep nickname 50 times, that's OK? I guess this makes sense because I have no guarantee that dinoYY is actually the same client, and also it may have cleared its local cache between two "getting online" events. ✏
-
MattJ
Yes, you send it anyway
-
MattJ
https://xmpp.org/extensions/xep-0312.html is an optimization for that, but nobody uses it
-
nicoco
Thanks MattJ, I think this the section I needed to read indeed. XEP-0312 is the type of optimisation I feared was part of pubsub or pep. Cool! Less keeping track of stuff, and easier to comply to the spec than I feared :)
-
MattJ
:)
-
pep.
singpolyma, could be used in MUC but server/component-side, no?
-
singpolyma
You mean it would need component support? Yes
-
pep.
I mean the benefits of 0033 to me are the possibility to send one instead of multiple payloads
-
pep.
Movim doesn't need to be exposed to 033 at all
-
singpolyma
0033 always has a server and a client component
-
singpolyma
The client sees who the other recipients of the message are and what the ofrom/replyto/replyroom etc addresses are
-
singpolyma
Very similar to SMTP, which is why it maps so well for SMTP and MMS gateways
-
pep.
hmm ok that's not what I had in mind for MUC usage. I would have had the component put 0033 for users on the same server and have the server split it
-
pep.
Which is why I was confused
-
singpolyma
Yes, sure, that is the server part
-
pep.
Well this doesn't require client support
-
singpolyma
But the client still gets the context of who the stanza was delivered to
-
pep.
Which client
-
Zash
ones understanding '33
-
singpolyma
It doesn't require it if your client UX doesn't care about any of the other addresses sure
-
pep.
singpolyma, well in MUC "it knows" already
-
singpolyma
Sure, in MUC mostly the client would only care about ofrom or replyto stuff likely
-
singpolyma
But this is down to the UX of the client dev
-
pep.
Yes. Actually disclosing who else on their server is receiving the message is probably some kind of leak
-
singpolyma
You mean if you used 0033 for groupchat from semianon? Yeah, that wouldn't work
-
pep.
Well yes it would, for the use-case I said. Just that the component needs to ensure server support
-
pep.
The client never needs to know 0033 was used
-
singpolyma
It would not because it would leak, as you say
-
pep.
I also said the server would split it
-
singpolyma
Unless you write an extension to 0033 to tell the server not to pass the 0033 payload along
-
pep.
Send one message from the MUC to serverX, deliver 10 messages to serverX users
-
pep.
Yes this
-
singpolyma
Sure, that's something new then
-
pep.
You may have said it in what you just said, but I still don't understand the other use-cases
-
pep.
SMS/MMS ok but that's because there's no protocol support so it's just informational I guess
-
singpolyma
So, for example, the one I have in my movim PR is just ofrom. That is to say, "this is the jid that really sent this message, I'm just a relay"
-
pep.
The original JID being.. +0123456789@gateway?
-
singpolyma
For an MMS case, yes. Or for SMTP email\40server@gateway
-
pep.
Actually my use-case for optimizing MUC traffic is already specified, with @type='bcc'
-
singpolyma
Or in a MUC case the true jid of the sender. Etc etc
-
singpolyma
pep.: oh right, I forgot BCC was speccd
-
pep.
Why would one leak their own JID voluntarily in a MUC
-
singpolyma
It would be a non-anon MUC obviously
-
pep.
So duplicating info given by MUC?
-
singpolyma
Or, probably. I mean, I always want my JID attached. I would leak in semi anon if it was a option
-
Zash
small private group chat without a MUC component
-
singpolyma
The info would be given by the MUC I would assume. It's just not the timeline we ended up in and we use presence for that instead of 0033
-
pep.
Zash, yeah, but that's not MUC
-
pep.
And yeah that's a use-case
-
singpolyma
Zash: sure, that's a possible use case but needs more than ofrom
-
pep.
Does prosody support 0033 cc?✎ -
pep.
Does prosody support 0033 bcc? ✏
-
singpolyma
There's a community mod iirc
-
Zash
https://modules.prosody.im/xeps.html#xep0033
-
pep.
Ok
-
pep.
https://hg.prosody.im/prosody-modules/file/f66a08f208ad/mod_addressing/mod_addressing.lua "-- IQ stanzas makes no sense" why?
-
pep.
You can still split the stanza at the server level
-
pep.
You've gained multiple stanza over one stream (component->server)
-
Zash
No, does not make sense
-
Zash
Multiple child tags of iq are illegal. Only one request and one response is allowed.
-
pep.
hmm
-
pep.
That's meh
-
Zash
'33 violates symmetry enough as it is
-
singpolyma
0033 for iq I'm not sure how replies would work. All with the same I'd?✎ -
singpolyma
0033 for iq I'm not sure how replies would work. All with the same ID? ✏
-
pep.
singpolyma, 0033 would have been stripped so the recipient would just sent to the original sender, the MUC
-
pep.
But yeah I forgot the one-child constraint of iq
-
pep.
send*
-
Zash
singpolyma, how do *errors* work with 33?
-
singpolyma
Zash: from the client you mean?
-
pep.
I'm not sure what's so complicated. 0033 is just an optimisation over one or multiple streams no? :/
-
Zash
one of the CC's bounce. ????
-
singpolyma
> one of the CC's bounce. ???? Would be the same as a normal non 33 . message ↺
-
singpolyma
from is the sender not the relay
-
singpolyma
Send error back to them directly
-
Zash
wait are you talking about using 33 to optimize 45?
-
singpolyma
pep. is
-
Zash
missed that