XSF Discussion - 2023-05-06


  1. singpolyma

    Hmm, I wonder why pubsub#notification_type is part of the node configuration instead of the subscription configuration

  2. nicoco

    Is there any reason why the "XEP-0319: Last User Interaction in Presence" payload could not be included in an "unavailable" presence?

  3. nicoco

    Relatedly, are <status>es forbidden in "unavailable" presences?

  4. MattJ

    They are not foebidden

  5. MattJ

    They are not forbidden

  6. nicoco

    OK, I thought so but I wonder if there was tribal knowledge about it that I should be aware of :). FWIW I'm asking because gajim parses neither the status nor the <idle> when ptype=unavailable, or at least it does not display it in the UI.

  7. nicoco

    OK, I thought so but I wondered if there was tribal knowledge about it that I should be aware of :). FWIW I'm asking because gajim parses neither the status nor the <idle> when ptype=unavailable, or at least it does not display it in the UI.

  8. lovetox

    does the server store extended infos in an unavailable presence?

  9. MattJ

    I don't know about current implementations, for example Prosody does not (though probably there is a plugin...). I know that in the past some servers definitely did.

  10. MattJ

    It was possible to sign off with a status like "on vacation", and your contacts would see it while you were offline

  11. MattJ

    With the shift to everyone being online all of the time, that became relatively uncommon of course

  12. mjk

    splitting '478 hairs here... what if a server advertizes max-bytes < 10000? assume max-bytes == 10000? ignore it? </stream>? dos the server until it's fixed?

  13. Zash

    Undefined Behavior, here be dragons, dunno

  14. pep.

    Why would 10000 be a special value when the server can advertize its maximum?

  15. Zash

    I suppose it would be best to respect that.

  16. Zash

    Like, what are you supposed to do if max-bytes = 1

  17. mjk

    pep.: the RFC says so 🤷

  18. pep.

    mjk, extensions do many things that aren't in the RFC :)

  19. Zash

    XEPs can override what the RFC says, so eh.

  20. mjk

    > XEPs can override what the RFC says, so eh. what a blasphemt

  21. Zash

    Doing so without some kind of negotiation is meh tho

  22. mjk

    > XEPs can override what the RFC says, so eh. what a blasphemy

  23. Zash

    And this is advertising, rather than negotiation, if there's such a distinction

  24. mjk

    right

  25. Zash

    What are the options anyway? Ignore, get </stream>, vs respect and maybe not work right?

  26. Zash

    Best to respect the RFC when it says > A _deployed_ server's maximum stanza size MUST NOT be smaller than 10000 bytes

  27. pep.

    Why would a server advertize 1 anyway? What would that achieve apart from not being able to communicate

  28. Zash

    Because silly admin configures it that way?

  29. pep.

    Yeah and they'll realize sooner or later that their users can't use the service

  30. pep.

    I'd rather have it fail explicitely this way than ignore the issue and let the admin believe their config is alright

  31. Zash

    Does the XEP need to forbid such configuration/deployment?

  32. Zash

    I don't remember any text explicitly saying that you're free to advertise max-bytes <10k, the RFC says don't put the limit there, so one could argue that that shouldn't happen.

  33. pep.

    I guess you can SHOULD/RECOMMEND a minimum value (same as the RFC?) But if there's a way for servers to advertize their max limit I'd vote for respecting it

  34. mjk

    tl;di (too long, didn't implement)

  35. cal0pteryx (wurstsalat)

    0060 ?