jdev - 2024-03-28


  1. lovetox

    Guus, what data form field does Openfire use to configure archiving in a muc?

  2. Guus

    lovetox, you mean enable/disable archiving of messages in a specific muc?

  3. lovetox

    yes

  4. Guus

    checking... I suspect it's a field defined in 0045

  5. Guus

    why do you ask

  6. Guus

    ?

  7. lovetox

    its not standardized to my knowledge

  8. lovetox

    ejabberd uses different field from prosody, and i want to provide the user with a good default config

  9. Guus

    I believe Openfire uses `muc#roomconfig_enablelogging`

  10. lovetox

    that would be unfortunate because it does not mean archiving

  11. Guus

    I do see that field in XEP-0045

  12. lovetox

    yeah and the description is "Whether to Enable Public Logging of Room Conversations"

  13. lovetox

    keyword is "public" here, so logs public on a webserver for everyone for example

  14. lovetox

    of course i disable this on any private room

  15. Guus

    I'm not sure if I agree with that being a keyword - it's only in the label after all

  16. Guus

    regardless, it is what Openfire is using today.

  17. lovetox

    the label is the only thing that describes the intention of that field in the standard

  18. Guus

    I'd argue that the keyword is 'logging' - but I admit that it's ambiguous.

  19. Guus

    I do not think it's make sense to have a flag for 'make logs public', but not one for 'have logs'.

  20. lovetox

    totally agree, but thats now how it is, and prosody uses a custom one, and ejabberd simply uses a field called "mam"

  21. Guus

    \o/ standardization at its best

  22. Guus

    MAM is optional for Openfire. It has a separate flag to expose the room logs over HTTP, for what its worth.

  23. lovetox

    you mean, separate field in the dataform?

  24. Guus

    sorry, no

  25. Guus

    MAM functionality needs to be installed & configured separately in Openfire (through a plugin)

  26. Guus

    it does look at the dataform field too, by the way - but that same datafield is likely used for the old 'give me X messages upon join' history thing in 0045.

  27. lovetox

    ok it gets worse :D, so now the user can decide between having his logs public on the web, or having no history storage in the MUC at all?

  28. Guus

    By default, Openfire doesn't have 'public' exposure of logs (That too, is an optional feature in a plugin). I assume that the original authors of Openfire thought of 'public' as: "anyone can potentially join the room and see the message history" (not accounting for private rooms at all)

  29. lovetox

    ok, so thats problematic for me as client dev, because i cannot provide the user with a sensible default config, because even if i could set enablelogging (lets forget that ejabberd and prosody use it for something else), then it could mean something different depending on the plugins are installed?

  30. Guus

    in Openfire, if `muc#roomconfig_enablelogging` there's no archive at all. Not in MAM either. If the MAM feature is added through a plugin, it needs to be explicitly enabled (for _all_ rooms with one flag). It will still not record messages for rooms that have `muc#roomconfig_enablelogging` disabled. Only if yet another flag is enabled, then a web endpoint will expose archives for all public rooms that have `muc#roomconfig_enablelogging` enabled (there's no control that allows individual, public rooms with logging enabled to opt in or out of the HTTP exposure).

  31. lovetox

    ok but the plugin does not expose membersonly rooms ever to the web?

  32. lovetox

    doe you mean this by "public" room

  33. Guus

    I don't think that it means anything different? `muc#roomconfig_enablelogging` will control if the collection of messages in a historic storage is enabled. It then depends on the installed server software through what mechanisms that archive is made available (0045, 0136 and/or 0313)

  34. Guus

    `muc#roomconfig_publicroom`

  35. lovetox

    ahh

  36. Guus

    which you're going to argue is for searching only :D

  37. lovetox

    ... no

  38. Guus

    it is nice to agree on something ;)

  39. Daniel

    Imho the question is not what will OpenFire do with that option but what might other servers do

  40. lovetox

    i know, thats why i wrote > (lets forget that ejabberd and prosody use it for something else)

  41. Guus

    what do you mean Daniel?

  42. lovetox

    the problem of course is that i can never enable that option, because prosody / ejabberd will treat it as publishing logs to the web

  43. Guus

    ah, right

  44. Daniel

    Even if OpenFire doesn't actually make the archive public with that option you can't safely set it by default if other servers might do that

  45. Daniel

    If the xep sort of kinda maybe implies that

  46. Guus

    given that ejabberd and prosody each use a distinct field... maybe there's room for a XEP update.

  47. Daniel

    Yes this has come up a bunch of times. I don't know why we never managed to do this

  48. lovetox

    the xep says we just need to write a email to registrar@xmpp.org :D

  49. singpolyma

    You don't need to enable it, just leave it at the default, yeah?

  50. MattJ

    I haven't really figured out what to do with config in MUX

  51. MattJ

    Do we define a new set of config options? Keep the existing MUC ones, but perhaps define them better?

  52. singpolyma

    I'm not sure we need any defined really. You're meant to have sane defaults (on the server) or ask the user

  53. MattJ

    If we define new options, we can also define mappings for translation to/from MUC forms

  54. singpolyma

    Or just use the same names for existing stuff?

  55. MattJ

    I don't think you'll ever convince me that dataforms are the ideal UI, though you've certainly pushed them a lot further than I thought I would ever see :)

  56. MattJ

    So I think allowing clients to map settings to a set of well-known fields is a good thing to have

  57. lovetox

    dataform is not a UI ..

  58. Daniel

    > dataform is not a UI .. Just add more css

  59. lovetox

    it only affects the UI if you talk about dataforms with unknown fields

  60. MattJ

    and some of those configuration parameters are public via disco too, it's good to be able to detect those apart from anything else (is this room going to reveal my JID, is it publicly logged, etc.

  61. lovetox

    > I'm not sure we need any defined really. You're meant to have sane defaults (on the server) or ask the user not sure how you can think that, having options for the user to control is a essential feature every messenger has in groupchats

  62. singpolyma

    Anything you can do with "well known fields" will be literally exactly the same as you could do with unknown fields in terms of UI

  63. singpolyma

    lovetox: yes that's why I said or ask the user

  64. Daniel

    It can't be that hard to pick one of prosodys or ejabberds names for 'this room has MAM' and standardize it

  65. MattJ

    singpolyma, not so, if I want to pluck some specific options out and put them in sensible places in the UI, instead of having every option in one long scrollable form

  66. lovetox

    user dont want to presented a form with 10 options everytime they initiate a group chat

  67. singpolyma

    Hmm, sure I guess if you want to scatter them about on different screens that's easier to do with well known fields

  68. lovetox

    i think the current way to do things are perfectly fine

  69. MattJ

    You say scatter, I say organize :)

  70. lovetox

    it just needs defining some more options that became important over the years

  71. lovetox

    its also important for translation