jdev - 2022-12-22

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

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

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

hi!

on my phone right now, but welcome!

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

for the auth stuff, MattJ has been working on things

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

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

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

mod_groups_* of prosody may be a starting place

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

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.

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

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

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

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

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

for the better or worse ;)

flow: yeah that's terrible..

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

(auto accepting invites)

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

TMM: yup

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

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

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

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

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

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

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

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

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 ✏

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?

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

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 😛

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

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 ✏

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

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

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

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

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

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

TMM: specs are always great

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

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

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

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

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

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

not a bad monetization approach

Buy Product™ Classic®

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

It's great

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

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

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

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

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

"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

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

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

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

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

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

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

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

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

and I hope invites are not…

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

Peter Waher perhaps! Do you have a similar need?

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

If you really want to, nobody can stop you

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.

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

My business interest is spite

It's a powerful motivator 😛

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.

pay xmpp developers to own the slacks

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

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

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

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

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

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.

Link Mauve, itym jonas’ ?

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

closing a chat doesn't delete it from roster

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

Today, it's basically a roster for group chats

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

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

They can even ... quit!

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

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

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.

oh i see i miss read. IGNORE MEEEE

who's this read guy?

and why is he ignoring you?

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

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

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

TMM_: glad we could be of help :)

mathieui: SAML2 can actually work browserless

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

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

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

Yes!

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

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

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

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

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

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

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

browser SPNEGO was fine