jdev - 2023-08-20

  1. Guus

    I've taken my RAA feedback to the mailinglist.

  2. lovetox

    im a fan of embedding info into messages

  3. lovetox

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

  4. lovetox

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

  5. lovetox

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

  6. lovetox

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

  7. lovetox

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

  8. lovetox

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

  9. lovetox

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

  10. lovetox

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

  11. lovetox

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

  12. lovetox

    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

  13. Guus

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

  14. Guus

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

  15. lovetox

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

  16. Guus

    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?

  17. lovetox

    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.

  18. lovetox

    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

  19. Guus

    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.

  20. lovetox

    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

  21. lovetox

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

  22. Guus

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

  23. Guus

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

  24. lovetox

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

  25. lovetox

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

  26. lovetox

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

  27. lovetox

    worse even, have to send queries

  28. lovetox

    delay the message, etc

  29. Guus

    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.

  30. lovetox

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

  31. lovetox

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

  32. lovetox

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

  33. Guus

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

  34. lovetox

    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

  35. lovetox

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

  36. lovetox

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

  37. Guus

    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.

  38. lovetox

    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

  39. lovetox

    thats probably trivial to implement

  40. lovetox

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

  41. Guus

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

  42. Guus

    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.

  43. lovetox

    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

  44. Guus

    I believe that's a fair concern.

  45. qy

    This is already the case, though

  46. Guus

    how do you mean, qy?

  47. qy

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

  48. lovetox

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

  49. lovetox

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

  50. lovetox

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

  51. Guus

    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.