XMPP Service Operators - 2024-01-29


  1. array

    i host a dendrite instance and use matrix a lot more than xmpp

  2. Polarian

    I feel sorry for you...

  3. Polarian

    having to use Matrix

  4. array

    lol why i perfer it over xmpp

  5. Polarian

    well then you are simply wrong 🙃

  6. array

    ミ⁠●⁠īšâ â˜‰â ãƒŸ

  7. Sam

    I do really wish we did this in XMPP land. Not the way it's done in Matrix, which is just wasteful, but if we queried our own servers for history on other servers, then they passed through those requests, it would allow eg. caching of really popular rooms, media, etc. which would be nice.

  8. Sam

    Many public servers would probably just continue to pass stuff through and not do any caching, but it would give you the option.

  9. moparisthebest

    Sam: nothing actually stops servers from doing that now tough?

  10. moparisthebest

    Sam: nothing actually stops servers from doing that now though?

  11. Sam

    Fair point, I guess just because a stanza is addressed somewhere else doesn't mean they couldn't do that. Maybe I'll experiment with an implementation.

  12. Polarian

    imo theres no point

  13. Polarian

    its their server thus they control the data

  14. Polarian

    if their server goes down boo hoo its down

  15. Polarian

    we shouldn't spread a servers data across half the internet, do you want privacy or not?

  16. moparisthebest

    Those aren't really related

  17. chunk

    I do not like the caching idea, one because it's bad action for sake of privacy, two it's unlike a mature protocol to hoard data for frivilous reasons, and three because that's wasteful anyways, whichever way, and some people don't even like having MAM enabled for a good reasons, as well it wouldn't be so minimal then and possibly lead people into worse ideas along the same thread, thus corrupt the userbase of xmpp to thinking of wrong things as the norm

  18. chunk

    i would H A T E my chats cached, and once seen that, remove MAM, make members only

  19. chunk

    the data occuring where it occurs is owner of wher eit occurs, not consented cached anywhere else

  20. moparisthebest

    I have bad news for you, your chats are cached

  21. chunk

    whodunnit

  22. moparisthebest

    On all clients of everyone joined to them

  23. chunk

    your client? NSA?

  24. chunk

    oh, that's fine, they're part of the chat, that's consented

  25. moparisthebest

    Adding a server to reduce load on your server isn't actually affecting anything

  26. chunk

    lol sounds redundant

  27. moparisthebest

    Yea this would only be servers that connected clients connect through

  28. chunk

    sounds like a mitm

  29. chunk

    can u elaborate?

  30. chunk

    no, and i don't blame u

  31. chunk

    i better leave now, bye

  32. chunk

    actually sounds like s2s, what is this sorcery

  33. moparisthebest

    chunk: right now to get history of this MUC your client sends a MAM query that your server sees and passes along, and then your server passes the data back to you, your server *could* cache it and when your other client sends the same query, serve it from local data, that's all

  34. chunk

    right

  35. chunk

    i didn't think of that

  36. chunk

    but it shouldn't

  37. chunk

    and furthermore offer that data outside the realm of the most obvious consenting

  38. chunk

    which would be muc and occupants only

  39. chunk

    transient nodes, do transient tasks only

  40. chunk

    i would call this unethical actually

  41. chunk

    cuz yea there's the technical realm, and the people's realm, which differ slightly, and what is that cached data useful for to the transient nodes if not for transient functions only? is unethical, imo

  42. chunk

    because it's not the people's realm, i hope im making sense, its possible, likely even, i am not

  43. chunk

    also, what if e2ee was introduced

  44. chunk can of worms explodes so he runs away

  45. Menel

    Just stumbled over https://github.com/acmesh-official/acme.sh/issues/4659 Acme.sh users before mid 2023 = rce https://www.cve.org/CVERecord?id=CVE-2023-38198 Do update your clients, and preferably use the non root method. moparisthebest, you once said never update this script, so I'm pinging you directly. 🙂 It not bad *as long as you can trust your choosen CA* but I think it's bad enough.

  46. Licaon_Kter

    Menel: that was mentioned here iirc

  47. Menel

    I didn't find it in my history so I mentioned it now. If it was already mentioned, then sorry for everyone reading it twice z for the rest : this is the reminder

  48. MattJ

    If you're upgrading, consider switching to dehydrated (formerly letsencrypt.sh) which doesn't have weird partnerships with CAs

  49. Licaon_Kter

    Menel: june 09 by mopar

  50. Martin

    Am I the only one just using certbot?

  51. MattJ

    People seem to think certbot is the alternative to acme.sh, or that acme.sh is the only simple client, but there are quite a few

  52. MattJ

    Martin, no, I use certbot on quite a few servers running Debian that I want to "just work", because if you install the right packages and use one of the supported web servers, it does

  53. Polarian

    > If you're upgrading, consider switching to dehydrated (formerly letsencrypt.sh) which doesn't have weird partnerships with CAs I was considering writing a client

  54. Polarian

    acme protocol isnt _too_ big

  55. Polarian

    me do something useful would be a miracle though...

  56. Stefan

    > Am I the only one just using certbot? no

  57. Menel

    I prefer dehydrated, but only acme.sh comes with an automated dns challenge hook for my dns service. Since I'm no coder I can't simply adapt that script for dehydrated. It might be not too hard.

  58. Menel

    Polarian: better contribute to an existing one? As you see there are enough that are not super robust or featurefull 🙂

  59. Polarian

    > Polarian: better contribute to an existing one? As you see there are enough that are not super robust or featurefull 🙂 Its mainly because I want to understand it more... not because I want another production ready client

  60. Trung

    >> Am I the only one just using certbot? > no +1

  61. roughnecks

    me too

  62. Martin

    OK, seems the users of the scripts just talk more about it and the silent majority sticks with certbot. 😂

  63. moparisthebest

    Menel: yes I'd heard about it thanks, I used dehydrated when it was letsencrypt.sh and switched to acme.sh for reasons long since forgotten, probably DNS challenge related if I had to guess

  64. chunk

    i had an issue for a while using certbot and it becoming a failed service til I realized it needs to delete unused domains (broken DNS) and since then i'm still a fan.

  65. agris

    > Sam: > 2024-01-28 06:03 (CST) > I do really wish we did this in XMPP land. Not the way it's done in Matrix, which is just wasteful, but if we queried our own servers for history on other servers, then they passed through those requests, it would allow eg. caching of really popular rooms, media, etc. which would be nice. I don't want to be catching for other servers. Usually services that have a million caches are fundamentally screwed up *cough WordPress cough modern website*

  66. agris

    I'd rather see development in a revised version of stanza compression that just doesn't compress authentication stanzas but compresses everything else.