jdev - 2023-08-20

I've taken my RAA feedback to the mailinglist.

im a fan of embedding info into messages

MUC for example, affiliation, hats, etc it should be embedded in every message

the trade up to save a few bytes per message while considerably raising the implementation complexity is not worth it

at lest not for the general use case of average user chatting

especially if you have to embed this exact infos than anyway when sending MAM messages because presence is not available

it just annoying to do this if then else dance on every message depending if it comes from MAM or live

Guus, could not a server do that disco info query when it connects to the domain with the s2s connection

and so strip the aap data if the server does not support it?

i agree i would consider it very annoying when i have to disco / info remote domains when receiving messages

with MUC use cases this is generally not a problem because we disco info the MUC anyway before joining

but in the non-muc use, i think this would be a first for clients, im not aware of any situation where a client would need to disco info a remote server to interpret messages correctly

lovetox: interesting. I was arguing (via mail, mostly) that doing the embedding of RAA (which is a different beast than hats) is what is making things more complex. You're arguing the exact opposite. :)

Doing the disco/info request upon performing a S2S connect certainly is a good approach.

Guus, but why is it a different beast, i just argue for put the info at that place where it is needed

From your last message, it appears that you think that the consumers of RAA info are clients. I was thinking it would be servers instead. I have only very generic thoughts about actual use-cases (something something give automatic voice based on RAA info), so I definitely think this through. I do wonder: what client use do you see for this?

if i want to judge a message, every info i need for that should be in the message, i dont want to depend on data like presence or disco info that i query at a later or earlier point, that makes processing this message harder.

im sorry, i did not read the XEP in full, i just discussed embeding muc hats with MattJ last time, and this seemed a bit related

I get that - but what you have in that message is, by nature, not trustworthy (until you combine it with other knowledge). That's another downside that I see in the approach of embedding.

i just wanted to share my expierence, with especially MUC, where we put much info in presence, later clients need that presence info when receiving a message

and we always have to do this mapping to that other data we received at join, and merge the data

I'm wondering if this particular data (RAA) is going to be used by clients in the first place.

I didn't consider that, so that's something I learned to consider from your feedback.

would it be different for a server though? if we look at the simplest case, a new registered user sends spam

so server receives message, and he needs that info right there at the processing of the message, if this is a newly registered user

why does he need to look up this info now somewhere else

worse even, have to send queries

delay the message, etc

I am not arguing that embedding this data is useless. Not at all. But I do think that it comes with downsides - and I'm not sure if the trade-off is worth it.

i mean you are a server developer, so how would you deal with that situation

you get a message, then you put it into a delay queue or something? and start a query against the domain of the user?

is this something that happens also in other places of server code?

Not in Openfire - unless you're doing something exotic like FMUC

see, but now you would need to do that or? what does this mean for all other code / plugins, you suddenly break the assumption that messages are processed in row and also relayed in the same order

and now consider the alternative, on begin of s2s you query disco info and get if the server supports the XEP

and now you can trust this info it sends, no need to query again

but, if you have not yet checked if the remote server supports that particular feature (for which your 'do disco/info on connect probably is a workable solution, but that could still fail, etc), you'd _still_ have to do such a handshake.

but you have a natural way to disco info the server on beginn of s2s, you simply dont process anything from that server until you have that disco info

thats probably trivial to implement

at least i find this from a naive understanding of server code, much easier to implement than doing it when receivng a message

'trivial' might be overselling it, but it shouldn't be to hard.

for long-lived connections, you'd want to periodically update the information, to take in configuration changes on the remote server - but that's all doable.

just from my view, if any protocol or solution was: "take this message, put it into a side queue, do async query, then reprocess message" i always bailed out immediately, so much in xmpp depends on order in which stuff is received and processed, you would need to design the whole application with that stuff in mind, and it makes a realtvely simple process into a thing that can only be done by experienced developers

I believe that's a fair concern.

This is already the case, though

how do you mean, qy?

Having tried to implement a client, i know full well how much in xmpp in asynchronous and requires that defer dance lovetox mentions

depends on what you deem necessary, you can full well implement a client that does nothing of the sort

its true that for some problems which resulted from a bad spec design, this is often the last resort and solution

but you are currently not forced to do this to have a working client

This account should start to embed RAA info in selected stanzas, and the bare JID of accounts on our domain should be queryable for RAA data, as per the proto-XEP.