-
Guus
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.
-
Guus
To be clear: I'm not objecting this to move forward as-is - but maybe the above would be a bit of an improvement.
-
MattJ
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
-
Guus
How do you mean?
-
MattJ
The whole point of the simple search is to have a sensible common baseline for interop
-
MattJ
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.
-
MattJ
Standardizing the field is almost pointless if nobody knows how to use it
-
Guus
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.
-
Guus
But you're absolutely right in that behavior wouldn't be completely consistent across implementations.
-
MattJ
Such search fields generally don't accept regex and weird syntaxes like `foo^3`
-
Guus
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.
-
MattJ
We don't have that situation now because the vast majority of clients don't implement this
-
MattJ
It seems to me it is only being used in closed deployments, where interop is not an issue
-
Guus
Maybe you're right - I personally have no much use for search, apart from through our administrative interfaces.
-
Guus
In any case, you seem to feel more strongly about this than me, and I'm happy to go either way.
-
MattJ
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.
-
MattJ
But there are use-cases where it would be handy, in MUCs for example
-
Guus
agreed.
-
Zash
Searching the logs of this very room could be nice
-
MattJ
Email sent
-
Guus
Thanks MattJ
-
phryk
Does anybody know of an existing implementation of XEP-0383 (burner JIDs)?
-
pep.
Nope. I think I'd be interested in one though..
-
Sam
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'
-
Sam
Ask the MUC, even.
-
qy
i agree
-
Zash
The MUC gives you `room@muc.host/nick`. Such a difference!
-
pep.
Sam, so.. unburrying full-anonymous MUCs finally? :P
-
qy
Zash: which is the XMPP equivalent of NAT :p
-
pep.
And you should hate NAT (hint)
-
qy
yeah, we all know how well NAT worked out as security...
-
Zash
And you advocate more NAT?
-
pep.
I disagree with this comparison though
-
qy
no i'm likening burner JIDs to IPv6
-
pep.
(Or I think I do)
-
qy
pep.: howso?
-
phryk
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.
-
phryk
Also, I actually like NAT.
-
phryk
https://upload.phryk.net/file_share/0dff4fd4-1b38-446b-b88e-4304641161df/ipv6nat.png
-
MattJ
Just use separate accounts
-
MattJ
i.e., per public identity
-
MattJ
Burner JIDs would take quite some work to prevent correlation (e.g. via OMEMO fingerprints)
-
phryk
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.
-
phryk
Mhh, right. Clients implementing burner JIDS and E2EE should probably generate new keys for every burner JID…
-
MattJ
It's not clear to me from the XEP whether it is just about identities, or more like a temporary account
-
Zash
Outsourced opsec?
-
phryk
Zash, :P
-
phryk
I mean, MUCs hiding JIDs are essentially that.
-
Zash
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.
-
Zash
Not like I don't use the same nickname, profile picture, language, typing patterns, time of activity everywhere (that you know of)
-
phryk
Aye.