jdev - 2023-03-19

singpolyma, poking here as you're not in movim@, I'm curious what's the use for 0033 in Movim.

Or this isn't MUC-related at all?

Just some unspecced-group thing?

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

For the email and MMS bridges (MMS is just email anyway so these are similar)

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)

Only send the last published item

https://xmpp.org/extensions/xep-0163.html#notify-when

See those two sections

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. ✏

Yes, you send it anyway

https://xmpp.org/extensions/xep-0312.html is an optimization for that, but nobody uses it

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 :)

:)

singpolyma, could be used in MUC but server/component-side, no?

You mean it would need component support? Yes

I mean the benefits of 0033 to me are the possibility to send one instead of multiple payloads

Movim doesn't need to be exposed to 033 at all

0033 always has a server and a client component

The client sees who the other recipients of the message are and what the ofrom/replyto/replyroom etc addresses are

Very similar to SMTP, which is why it maps so well for SMTP and MMS gateways

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

Which is why I was confused

Yes, sure, that is the server part

Well this doesn't require client support

But the client still gets the context of who the stanza was delivered to

Which client

ones understanding '33

It doesn't require it if your client UX doesn't care about any of the other addresses sure

singpolyma, well in MUC "it knows" already

Sure, in MUC mostly the client would only care about ofrom or replyto stuff likely

But this is down to the UX of the client dev

Yes. Actually disclosing who else on their server is receiving the message is probably some kind of leak

You mean if you used 0033 for groupchat from semianon? Yeah, that wouldn't work

Well yes it would, for the use-case I said. Just that the component needs to ensure server support

The client never needs to know 0033 was used

It would not because it would leak, as you say

I also said the server would split it

Unless you write an extension to 0033 to tell the server not to pass the 0033 payload along

Send one message from the MUC to serverX, deliver 10 messages to serverX users

Yes this

Sure, that's something new then

You may have said it in what you just said, but I still don't understand the other use-cases

SMS/MMS ok but that's because there's no protocol support so it's just informational I guess

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"

The original JID being.. +0123456789@gateway?

For an MMS case, yes. Or for SMTP email\40server@gateway

Actually my use-case for optimizing MUC traffic is already specified, with @type='bcc'

Or in a MUC case the true jid of the sender. Etc etc

pep.: oh right, I forgot BCC was speccd

Why would one leak their own JID voluntarily in a MUC

It would be a non-anon MUC obviously

So duplicating info given by MUC?

Or, probably. I mean, I always want my JID attached. I would leak in semi anon if it was a option

small private group chat without a MUC component

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

Zash, yeah, but that's not MUC

And yeah that's a use-case

Zash: sure, that's a possible use case but needs more than ofrom

Does prosody support 0033 bcc? ✏

There's a community mod iirc

https://modules.prosody.im/xeps.html#xep0033

Ok

https://hg.prosody.im/prosody-modules/file/f66a08f208ad/mod_addressing/mod_addressing.lua "-- IQ stanzas makes no sense" why?

You can still split the stanza at the server level

You've gained multiple stanza over one stream (component->server)

No, does not make sense

Multiple child tags of iq are illegal. Only one request and one response is allowed.

hmm

That's meh

'33 violates symmetry enough as it is

0033 for iq I'm not sure how replies would work. All with the same ID? ✏

singpolyma, 0033 would have been stripped so the recipient would just sent to the original sender, the MUC

But yeah I forgot the one-child constraint of iq

send*

singpolyma, how do *errors* work with 33?

Zash: from the client you mean?

I'm not sure what's so complicated. 0033 is just an optimisation over one or multiple streams no? :/

one of the CC's bounce. ????

> one of the CC's bounce. ???? Would be the same as a normal non 33 . message ↺

from is the sender not the relay

Send error back to them directly

wait are you talking about using 33 to optimize 45?

pep. is

missed that