XSF Discussion - 2022-06-02

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

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

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

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

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

And I say this every time it comes up

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

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

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

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

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

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

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

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"

Right, exactly what I feared 🙂

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

Sure, thanks.

feasible timeline after which pokes are in order?

(hours, days, weeks?)

Poke me early next week

ack

So.. meeting today?

arc, what do you think? :)

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

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

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

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

> 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

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

Thanks

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

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

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

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?

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)

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

¯\_(ツ)_/¯

Zash: which stuff exactly?

The _stuff_ !!

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

Here, probably inventing a datatype per engine.

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

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

Only the syntax?

(+registry)

Hm, `xml:lang`

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.

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.

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

and who knows what else

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

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

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)

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

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