jdev - 2022-12-22


  1. TMM

    Hello! I got sent here by Jonas Schäfer on Mastodon for sending angry messages about rocket.chat 🙂

  2. Zash

    Welcome. Not sure if this is the place to be angry about rocket.chat either, but maybe there's some other suitable topic ;)

  3. TMM

    Oh, I got sent here for making angry noises about rocket.chat and saying I was going to write my own chat server

  4. jonas’

    hi!

  5. jonas’

    on my phone right now, but welcome!

  6. TMM

    Specifically, I'm currently using rocket.chat in my company to basically fill the role of slack, that is to say it has quite a few enterprisey knobs that I kind of need in order to be compliant with NDA contracts with customers and stuff. There's a bunch of stuff that I think? XMPP can't do right now at least based on my somewhat brief research, XMPP is a little overwhelming... * SAML authentication, I can only find SASL (I know the two things only sound similar but have nothing to do with each other) I don't think there's a SASL mech for SAML, I found one for Oauth but it requires some client cooperation that I don't think is standardized which might make XMPP lose some of its benefits. * "Forcing" users to join particular MUCs, I have groups for different customers/projects that get mapped into channels/MUCs on rocket.chat. My employees can't leave those groups, nor can they decide to join one they aren't a part of. This is required for a variety of compliance reasons. I also forcibly eject people from rooms if they lose a group membership. * creating thumbnails for images / transcoding videos on upload to make them work on browsers (I think this can probably be done without a XEP or anything) * server-side link previews

  7. jonas’

    for the auth stuff, MattJ has been working on things

  8. jonas’

    I'm not sure if and how SAML or OAuth fits in there

  9. MattJ

    Yes, standardized OAuth flows will be my focus in early 2023 ( https://docs.modernxmpp.org/projects/auth/ )

  10. jonas’

    forcing users into groups will require client cooperation obviously, but can be done

  11. jonas’

    mod_groups_* of prosody may be a starting place

  12. jonas’

    server side link previews need extension of both server and client to look nice, but certainly doable and there's interest by others in that, too

  13. TMM

    I had a look at that yeah, the need for client cooperation again makes XMPP not that attractive. If I can only support one client then I'm not sure what benefits XMPP really gives me? I'm looking to be sold on using XMPP by the way, I'm not here to poopoo it at all.

  14. jonas’

    well you can reuse existing software and protocols others already thought about and modify/extend it instead of starting fully from scratch

  15. jonas’

    and a community of folks who know what you're talking about if you run into issues :)

  16. flow

    TMM, how would forcefully joining a chat not require client cooperation?

  17. jonas’

    you need client cooperation with any system for forcing people into rooms (clients could just discard / hide messages)

  18. flow

    its fundamentally different from forecfully ejecting users from a chat (which does not require client cooperation)

  19. jonas’

    note that many clients will already happily follow "suggestions" (invites) from servers already

  20. flow

    for the better or worse ;)

  21. pep.

    flow: yeah that's terrible..

  22. jonas’

    note that many clients will already happily follow "suggestions" (invites or injected bookmarks) from servers already

  23. pep.

    (auto accepting invites)

  24. TMM

    I guess it might be okay to ship a web client that does all of the things I need and a mobile app based on some existing XMPP client that does as well. If people insist on using their own I guess they are knowledgeable enough to not get into trouble

  25. jonas’

    TMM: yup

  26. TMM

    Well, this is a fundamentally different usecase than IRC 🙂 My users don't exactly CHOOSE to be on my server insofar as that they are there because I pay them

  27. pep.

    That's a corporate use-case I get that, IRC or not

  28. flow

    TMM basically everything you ask for can be done, and actually is done, in XMPP (even though, sometimes by pseudo-propertiary non-XEP extensions), they key, is, as always to control the used software

  29. flow

    e.g. the Openfire / Spark suite was build with that in mind

  30. TMM

    Is OpenFire still around? I think I might have used it like 15? years ago?

  31. flow

    of course, that was over a decade ago, so has some antiquated touch to it

  32. TMM

    I think MattJ might have convinced me not to write an XMPP server about 10 years ago as well

  33. flow

    I think the fundamental problem is that you ask for corperate use-cases, while many (active) xmpp projects are build for the public internet

  34. flow

    of course you could pay someone to developer tailored xmpp software for your needs, but I doubt that you will be willing to pay for it

  35. flow

    of course you could pay someone to develop tailored xmpp software for your needs, but I doubt that you will be willing to pay for it

  36. TMM

    Yes, I understand, Would there be an interest theoretically at least for XEPs that address the kind of usecases that Slack is basically filling for most projects now?

  37. flow

    my person opinion is that XEPs are cheap (free even) and that one could never have enough of them

  38. TMM

    I'd be willing to pay for that in principle. I pay for rocket.chat now, I'm not at all averse to paying for software. I AM averse to paying for software that has a certain featureset only to set the features cut and the price quadrupled 😛

  39. flow

    but just because something is XEPified doesn't mean that it gets actually implemented

  40. pep.

    I doubt the problem is specs really but willingness to implement them. If they're interesting to projects out there they'll probably put them on a Todo su l'est

  41. pep.

    I doubt the problem is specs really but willingness to implement them. If they're interesting to projects out there they'll probably put them on a Todo at least

  42. flow

    I think, but would be happy to be proven wrong, that many XMPP-ish things, like federation, just do not really play a role in corperate use cases these days

  43. Maranda

    > <TMM> Specifically, I'm currently using rocket.chat in my company to basically fill the role of slack, that is to say it has quite a few enterprisey knobs that I kind of need in order to be compliant with NDA contracts with customers and stuff. There's a bunch of stuff that I think? XMPP can't do right now at least based on my somewhat brief research, XMPP is a little overwhelming... > > * SAML authentication, I can only find SASL (I know the two things only sound similar but have nothing to do with each other) I don't think there's a SASL mech for SAML, I found one for Oauth but it requires some client cooperation that I don't think is standardized which might make XMPP lose some of its benefits. > * "Forcing" users to join particular MUCs, I have groups for different customers/projects that get mapped into channels/MUCs on rocket.chat. My employees can't leave those groups, nor can they decide to join one they aren't a part of. This is required for a variety of compliance reasons. I also forcibly eject people from rooms if they lose a group membership. > * creating thumbnails for images / transcoding videos on upload to make them work on browsers (I think this can probably be done without a XEP or anything) > * server-side link previews Afair the only thing actually supported is the GSS-API authentication and the only implementation I know is M-Link. Nothing supports SAML, maybe they're working on OIDC for SSO.

  44. TMM

    The slack main driver of their paid for plans is actually slack to slack federation

  45. flow

    so you could just ignore the complexity that federation brings and create producs like slack, discord etc

  46. TMM

    The slack main driver of their paid for plans is actually slack to slack federation, of Slack, that is

  47. flow

    uh, that slack federates is interestting, that's news to me

  48. flow

    uh, that slack federates is interesting, that's news to me

  49. pep.

    TMM: don't forget their complete control over you history records

  50. jonas’

    TMM: specs are always great

  51. pep.

    flow: it's some kind of weird feature, not exactly federation

  52. TMM

    Oh yeah, there's a reason I'm not using Slack, you don't have to sell me on on-prem software 🙂

  53. jonas’

    TMM: I prefer such closed systems to at least cooperate on the spec level over each doing their own proprietary extensions

  54. TMM

    yeah, it's not "federation" in the sense of running your own slack server, but it's a way for you to have a "workspace" with channels from different slack users on it. It's so you don't have to have multiple browser tabs open if you have multiple people to talk to on Slack

  55. TMM

    It's basically one of those "You can pay us for to solve the problem we created for you" type deals

  56. jonas’

    TMM: in other words, I'd vote in favor of efforts to get such features covered by the protocol

  57. flow

    not a bad monetization approach

  58. Zash

    Buy Product™ Classic®

  59. TMM

    You're not allowed to solve the problem for yourself by the way, the slack APIs forbid you from making your own clients to solve this issue

  60. TMM

    It's great

  61. mathieui

    TMM, the main issue I think would be the SAML auth; that requires knowledge about the IDP dance and implementation of the workflow (which is often web-based afaik) into the client, as well as the required bits in the server

  62. TMM

    Anyway, slightly off-topic at this stage I think 🙂 Assuming I go the XMPP route what would your recommendations be? The way I see it is basically: * Probably write some extensions for prosody to do some of the things I want * Write/fork an existing XMPP javascript client, add Oauth and/or SAML to it and somehow plumb that into prosody * Fork an existing XMPP android and iOS client and do the same * Write XEPs for my stuff and hope that eventually others see some benefits to it

  63. flow

    as alternative to forking, there is also the "get developers on board" idea

  64. flow

    as alternative to forking, there is also the "get developers on board" approach

  65. TMM

    I'd be happy to fork as in create pull requests back to the main repo

  66. flow

    but yes, it boils down to co-develop the spec and the implementation

  67. mathieui

    "Forcing" users into MUCs /should/ be a somewhat simple modification in most clients, and the link previews and thumbnails stuff is not too hard to put together if you do not expect to be federated, imo

  68. flow

    depending on the extent of the changes, such PRs have a higher chance to get actually merged if upstream is early involved in this and if the design is coordinated with upstream

  69. TMM

    That's true, but I have to admit I'm not really looking for people to try to convince me that in fact I don't need the features I want

  70. flow

    sure, the alternative is that you have the burden of maintaining a dozen code bases alone

  71. flow

    both alternatives aren't easy, but if this would have been easy, then somone would probably already done so ;)

  72. TMM

    Well, I *was* going to just start from scratch originally 😛

  73. Zash

    "Forcing" users into group chats is easy since all will generally follow bookmarks and invites today.

  74. Zash

    Modifying a client to restrict leaving etc ought to be fairly easy too

  75. flow

    yep, server-synthesized auto-join bookmarks are probably the way to go

  76. flow

    and I hope invites are not…

  77. TMM

    Maybe a way to resend the invite if the user leaves, and maybe a XEP to inform the client to not offer a "leave" button

  78. TMM

    Peter Waher perhaps! Do you have a similar need?

  79. TMM

    I probably still shouldn't write my own XMPP server though should I? 😛

  80. Zash

    If you really want to, nobody can stop you

  81. Zash

    I would venture a guess that starting with an existing server and extending it would be better business sense, unless the goal is to own all the copyrights or somesuch.

  82. TMM_

    No, there's no business interest in this whatsoever other than not wanting to pay rocket.chat, slack, or mattermost for their half-useful software

  83. TMM_

    My business interest is spite

  84. TMM_

    It's a powerful motivator 😛

  85. Link Mauve

    TMM_, a client can always ignore any message you send it, that’s true for any protocol. If it thinks it isn’t joined in a room it may not display it, and there is nothing you can do to force it not to.

  86. Zash

    pay xmpp developers to own the slacks

  87. trần.h.trung

    i think you can "force" your users by other way that has nothing to do with technology but finance.

  88. Trung

    i think you can "force" your users by other way that has nothing to do with technology but finance.

  89. Trung

    there's also a mod_firewall in prosody which you can limit your users to only communicate in whatever MUC or address you specified.

  90. Link Mauve

    Trung, it’s much easier to manage access rights directly in the MUC.

  91. TMM__

    Trung that's true to an extent but people accidentally closing a channel and then not being able to find it again is a support burden I don't want. Not all of my users are very tech savvy

  92. Link Mauve

    TMM__, with the solution Zash mentioned (Prosody modules managing bookmarks instead of the users), a simple restart of the client will be enough to “repair” that.

  93. Zash

    Link Mauve, itym jonas’ ?

  94. TMM__

    Would that basically just force the channels back on the user's roster?

  95. Trung

    closing a chat doesn't delete it from roster

  96. TMM_

    I guess I don't really understand what a bookmark is then 🙂

  97. Zash

    Today, it's basically a roster for group chats

  98. Zash

    Might as well consider it a part of the roster, even if it's technically a separate thing in the protocol.

  99. Trung

    > Trung, it’s much easier to manage access rights directly in the MUC. You can't quite force them in the MUC though lol they can just throw their phone in the river.

  100. Zash

    They can even ... quit!

  101. Trung

    TMM_: also Conversations can do certificate log in if you don't want password.

  102. TMM_

    Yes, the computer can't force people to participate, but it CAN make sure that the user is in the correct groups they need for their work and preventing them from making errors

  103. TMM_

    Trung The main usecase for SAML/Oauth is just the single sign-on. I only have one login system; keycloak, and nothing else at all.

  104. Trung

    oh i see i miss read. IGNORE MEEEE

  105. techmetx11

    who's this read guy?

  106. techmetx11

    and why is he ignoring you?

  107. Trung

    best to fork a client and modify it then i guess if you really need it.

  108. TMM_

    Thanks for all the help so far, I'll reevaluate my options. XMPP doesn't seem as silly an idea now as before

  109. TMM_

    (For this usecase, I never thought XMPP was silly on the wider internet)

  110. jonas’

    TMM_: glad we could be of help :)

  111. jonas’

    mathieui: SAML2 can actually work browserless

  112. jonas’

    OpenStack uses it for one variant of its federation support and it can work fully transparent on the CLI

  113. jonas’

    OpenStack uses it for one variant of its federation support and it can work fully transparent on the commandline

  114. jonas’

    OpenStack uses it for one variant of its federation support and it can work fully transparently on the commandline

  115. Zash

    Isn't SAML an unholy union of XML and X.509 ?

  116. TMM_

    Yes!

  117. TMM_

    From a user perspective it's a bit faster than Oauth2 though, I'm not sure why exactly

  118. TMM_

    But logging in with SAML seems to only take about a quarter of the time as with oauth2

  119. TMM_

    It *seems* that it does far fewer redirects when already logged into the idp

  120. TMM_

    But I guess that might be because SAML has a backchannel between the idp and endpoint whereas oauth2 has to schlep all the data back and forth through the client

  121. TMM_

    I use keycloak so I can use either, but I prefer to use SAML if I can for that purpose

  122. Zash

    OAuth in XMPP is also very awkward, since most XMPP clients are native, not web browser based.

  123. TMM_

    I wish we had all just stuck to Kerberos for the web 😛

  124. TMM_

    browser SPNEGO was fine