XSF Discussion - 2022-06-02

  1. thndrbvr

    Bridges and bots. i.e. streamlabs type stuff. discord <-> twitch. (Ew but so useful. Greatly adds to the experience)

  2. Guus

    Is there any concern that would prevent xep-0431 from progressing?

  3. Guus

    I believe it primarily standardizes a field name for functionality that is already implemented in various servers (Openfire, EJabberd and M-Link, from my old notes).

  4. Guus

    I got in another "oh we can't use it because the XEP says you shouldn't do this in production" argument that I'd like to avoid in the future. :)

  5. MattJ

    I don't like it as-is, but it shouldn't be hard to fix

  6. MattJ

    And I say this every time it comes up

  7. Zash

    Write down what and why, post it to the list?

  8. MattJ

    We need to standardize two fields: one that guarantees no interpretation (the input is always treated as literal text) and another that allows implementation-defined syntax

  9. MattJ

    If we only standardize one, it should be the former, but this XEP currently says it is the lattet

  10. MattJ

    If we only standardize one, it should be the former, but this XEP currently says it is the latter

  11. MattJ

    Which makes it painful for interop, useful only for closed deployments

  12. MattJ

    I'd be interested to know what current implementations are doing

  13. MattJ

    If they're all doing simple search then we should just adjust the semantics of the current field, if not then we should define a second one

  14. Guus

    Openfire currently takes the value, and will process it as a Lucene index query.

  15. Guus

    eg: "experiance" (SIC) yields 2 results from 11 million archived messages, while "experiance~" yields 500, which is a little bit more than the literal search for "experience"

  16. MattJ

    Right, exactly what I feared 🙂

  17. MattJ

    I will attempt a PR if you attempt to prevent me forgetting

  18. Guus

    Sure, thanks.

  19. Guus

    feasible timeline after which pokes are in order?

  20. Guus

    (hours, days, weeks?)

  21. MattJ

    Poke me early next week

  22. Guus


  23. arc

    So.. meeting today?

  24. MattJ

    arc, what do you think? :)

  25. MattJ

    Guus, is the Openfire search code public? Can you share a link to it if so?

  26. arc

    I think that once again I came to the scheduled meeting to find no one here

  27. moparisthebest

    arc: https://i.imgflip.com/6id83h.jpg

  28. arc

    That's a pretty huge compliments to compare me to sanders

  29. Guus

    > Guus, is the Openfire search code public? Can you share a link to it if so? MattJ: Yes, it is part of the Monitoring plugin for Openfire (where the MAM implementation lives). It's in this repo: https://github.com/igniterealtime/openfire-monitoring-plugin

  30. Guus

    I can give more details when I am near a pc again. I am on mobile now.

  31. MattJ


  32. MattJ

    Guus, https://matthewwild.co.uk/uploads/xeps/xep-0431.html + https://github.com/xsf/xeps/compare/master...mwild1:xep-0431-v0.3.0?expand=1

  33. MattJ

    This closes all my personal open issues with full-text search in MAM

  34. guus.der.kinderen

    MattJ: wow, that's quite an addition. I wonder if we're edging towards overkill, but I don't have any objections to that.

  35. guus.der.kinderen

    Is having a registry of search syntax types going to be practical, when alternatives start to pop up for the same syntax type, but with a different version identifier, or somesuch? We can certainly maintain a registry - but should we?

  36. MattJ

    I'm open to not, but I think it's helpful if most people are going to be using the same engines (there aren't an infinite number of them)

  37. MattJ

    It just gives clients even more of a chance to offer some sane UI around this feature, but I expect most won't anyway

  38. Guus


  39. Zash - an appreciator of XEP-0122 - wonders if XEP-0122 could be used to signal such stuff

  40. MattJ

    Zash: which stuff exactly?

  41. Zash

    The _stuff_ !!

  42. MattJ

    I didn't think that language/syntax fitted as validation, so I made custom elements

  43. Zash

    Here, probably inventing a datatype per engine.

  44. Zash

    Language does indeed not quite fit into that without further fiddlery.

  45. MattJ

    guus.der.kinderen: if you think the proposed additions might be overkill... now that you've seen them, what would you cut out?

  46. MattJ

    Only the syntax?

  47. MattJ


  48. Zash

    Hm, `xml:lang`

  49. Guus

    MattJ: even though your update is a lot more feature rich, I wonder if the added complexity hinders adoption more than it adds any real world value through implementation. Like you said: most probably won't implement the details anyway. With that in mind, I would be fine with the previous version of the XEP.

  50. Guus

    I personally don't plan to implement the 'simple' search, as I expect that it would not be that easy to do, while the added benefit to end users is negligible.

  51. MattJ

    Guus, I don't think it's negligible - many such engines will silently interpret words like "and", "or" and "not" with unexpected results

  52. MattJ

    and who knows what else

  53. MattJ

    and every server would do it slightly differently, so it's not something a user could just learn

  54. Guus

    MattJ: I don't think that you're wrong.

  55. MattJ

    My preference is strongly for simple searches, and if we were going to cut anything out, it would be the advanced searches. But I'm not arguing for that because 1) it's already implemented 2) it likely is actually useful in many cases (especially when client and server are controlled)

  56. MattJ

    If you actually read the Lucene query syntax, there are so many ways it could trip up an unsuspecting user who thinks they can just enter arbitrary text strings to search for

  57. MattJ

    Will post to the list tomorrow about my proposed changes. Good night!