XSF Discussion - 2022-06-03

Thanks MattJ - I was already asleep by that time. We can do bikeshedding over what type of search query would be expected by many users, but that won't matter much anyway. Having slept on it for a night: would it make sense to make the 'simple' variant just another flavor, instead of a distinct different field? I would not expect any UI to sensibly offer two different fields to the end-user. On top of that, I suspect that most flavors will allow for some kind of syntax that will make them do simple/exact matching.

To be clear: I'm not objecting this to move forward as-is - but maybe the above would be a bit of an improvement.

That means if a server only supports advanced queries, and a client doesn't support the UI for that, a simple search couldn't be performed

How do you mean?

The whole point of the simple search is to have a sensible common baseline for interop

That's the point of standard protocols in the first place - interoperability, and knowing that sending a certain thing will cause a certain outcome. With arbitrary search syntax, that doesn't happen and it's bad for an open ecosystem.

Standardizing the field is almost pointless if nobody knows how to use it

Not a hill for me to die on, but I'd argue that search fields are used successfully all the time, without the majority of the users realizing what specific syntax they could use in search queries.

But you're absolutely right in that behavior wouldn't be completely consistent across implementations.

Such search fields generally don't accept regex and weird syntaxes like `foo^3`

I'm only not sure if that's to big of a deal in the vast majority of cases. We effectively have that situation now.

We don't have that situation now because the vast majority of clients don't implement this

It seems to me it is only being used in closed deployments, where interop is not an issue

Maybe you're right - I personally have no much use for search, apart from through our administrative interfaces.

In any case, you seem to feel more strongly about this than me, and I'm happy to go either way.

I think most clients store and search history locally anyway, rather than using server-side search. Particularly when E2EE is in use a lot of the time anyway.

But there are use-cases where it would be handy, in MUCs for example

agreed.

Searching the logs of this very room could be nice

Email sent

Thanks MattJ

Does anybody know of an existing implementation of XEP-0383 (burner JIDs)?

Nope. I think I'd be interested in one though..

I still really want to get rid of semi-anonymous chat rooms and just do 'if you want to be anonymous, ask the much for a burner JID and use that to join'

Ask the MUC, even.

i agree

The MUC gives you `room@muc.host/nick`. Such a difference!

Sam, so.. unburrying full-anonymous MUCs finally? :P

Zash: which is the XMPP equivalent of NAT :p

And you should hate NAT (hint)

yeah, we all know how well NAT worked out as security...

And you advocate more NAT?

I disagree with this comparison though

no i'm likening burner JIDs to IPv6

(Or I think I do)

pep.: howso?

Burner JIDs would still expose the service the person is coming from, tho – so I like the current solution better for channels. Tho I assume burner jids could be used in private channels with E2EE which is something I'd like.

Also, I actually like NAT.

https://upload.phryk.net/file_share/0dff4fd4-1b38-446b-b88e-4304641161df/ipv6nat.png

Just use separate accounts

i.e., per public identity

Burner JIDs would take quite some work to prevent correlation (e.g. via OMEMO fingerprints)

That's not user friendly. I want the service to do as much of the heavy lifting for privacy/opsec as possible. Good opsec is notoriously hard and I'd like to lessen the burden of that.

Mhh, right. Clients implementing burner JIDS and E2EE should probably generate new keys for every burner JID…

It's not clear to me from the XEP whether it is just about identities, or more like a temporary account

Outsourced opsec?

Zash, :P

I mean, MUCs hiding JIDs are essentially that.

Personally I'm mostly happy about the property where it doesn't make it trivial to jump into a public channel, scrape all the JIDs and then send spam to them.

Not like I don't use the same nickname, profile picture, language, typing patterns, time of activity everywhere (that you know of)

Aye.