XSF Discussion - 2022-06-03

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

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

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

  4. Guus

    How do you mean?

  5. MattJ

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

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

  7. MattJ

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

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

  9. Guus

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

  10. MattJ

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

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

  12. MattJ

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

  13. MattJ

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

  14. Guus

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

  15. Guus

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

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

  17. MattJ

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

  18. Guus


  19. Zash

    Searching the logs of this very room could be nice

  20. MattJ

    Email sent

  21. Guus

    Thanks MattJ

  22. phryk

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

  23. pep.

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

  24. 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'

  25. Sam

    Ask the MUC, even.

  26. qy

    i agree

  27. Zash

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

  28. pep.

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

  29. qy

    Zash: which is the XMPP equivalent of NAT :p

  30. pep.

    And you should hate NAT (hint)

  31. qy

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

  32. Zash

    And you advocate more NAT?

  33. pep.

    I disagree with this comparison though

  34. qy

    no i'm likening burner JIDs to IPv6

  35. pep.

    (Or I think I do)

  36. qy

    pep.: howso?

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

  38. phryk

    Also, I actually like NAT.

  39. phryk


  40. MattJ

    Just use separate accounts

  41. MattJ

    i.e., per public identity

  42. MattJ

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

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

  44. phryk

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

  45. MattJ

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

  46. Zash

    Outsourced opsec?

  47. phryk

    Zash, :P

  48. phryk

    I mean, MUCs hiding JIDs are essentially that.

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

  50. Zash

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

  51. phryk