jdev - 2025-12-14

lovetox, please open an issue https://codeberg.org/jssfr/muchopper/issues with the first page you receive, the follow-up request you send, and the response you receive to that. ✏

Is there an implementation of workgroup queues anywhere? It seems like a nice system to implement website based chat/Support.

(and sales)

Guus, didn't Openfire implement this? ^

erik, cal0pteryx: correct. Its called FastPath

Guus, thanks for your reply! Does anybody use it? I've seen some of it in the context of Ignite Realtime, but nowhere else. Is it a commercial offering or did I just not look in the right places?

erik: give me two minutes

erik: FastPath was initially developed (~2 decades ago) as a paid addition to an open-source server. It is thus quite feature-rich. The company that developed it (same authors as Openfire, same people that actually drafted that XEP) eventually open-sourced everything. That all happened many, many years ago. Ever since, development on FastPath has been ... low to almost non-existant. Today, it's still largely functional, but with some rough edges.

I _think_ you can get a demo version running pretty fast, by starting Openfire in demoboot, then install the fastpath plugin. iirc there's a web-based customer-facing client (Converse-JS based) in a demo website that's part of that plugin. You'll need either an Agent client that understands the protocol (which I think gives you a choice between Spark and nothing else), or you need to interact with the chatbot that's part of the plugin.

ok. that's interesting. From the code base, it didn't seem that way. I think the concept is really close to what you would get when you want to buy a "support chat" functionality for sales and support on your site these days. I figured that since we're already running XMPP, this would be a very nice extension, although I'm not able to spend a lot of money on it, being the size of company that we are.

It's totally free.

It's a bit rough - I guess that it'd benefit from you spending _time_ on it (which at the least would be someone willing to raise structured feedback on bugs, at best a Java-capable developer that applies changes)

I think chatting with the chatbot would be fine. I think the protocol xep is really interesting, because it re-uses many of the concepts we already have in the XMPP spec and customer-facing clients. It's mostly the agent protocol that seems to be the most amount of work -- and that is in FastPath already.

Yup, it's very versatile - including having groups of agents that can be set up in first/second/third layer of supporters, Lucene-based routing of questions based on keywords, transfer of calls to other agents, etc, etc.

It's one of those things that I really wish I had a good excuse to bring back to modern times - but I've got 1001 of those projects :)

I can only recommend that you give it a try

I don't expect that you'll find anything close, with regards to XMPP-based functionality. I've never seen that, anyways.

Yea. I have those too. I'm just wondering what I can do to upgrade my website and attract more attention from the traffic that I *am* getting. I know how to write Java (I did extensive work on ArmedBear Common Lisp - a Common Lisp implementation running on top of the JVM), but it's ages since I last wrote some. I'm pretty sure I'm not aware of the "modern" things that have been added.

it's kind of too bad the xep never made it to be a standard, I think.

That codebase is from 2006 - no need to worry about things being modern. :D

(or did it? I remember that it's still draft or proposal level)

well, I have to set up a demo site for a different tool right now, but with the holidays coming, I can definitely see that I'll want to experiment with it.

thanks!

erik: the status of those XEPs often lags behind considerably - there' splenty of 'experimental' XEPs that are in wide use today.

(although this particular one doesn't see any activity, which probably means that the current state is quite correct)

yea. it doesn't matter as long as the software which supports it, actually works and works well enough.

It's an annoyance though, as people, unsurprisingly, assume that something that's 'experimental' is not production-ready. In our defense: we do strive tot move things along faster, but it is somehwat of an uphil battle.

It depends what "production ready" means to you. Anything experimental you should not assume will ever become a standard and if it does it may completely change more than once before then. So you need to be prepared to handle multiple versions and compatibility shifts etc

erik: jmp.chat uses a different system for customer support you might want to consider too

yes we use https://github.com/chatwoot/chatwoot/pull/5587

which upstream rejected so we just run a fork with that in it

singpolyma, thanks! well, the platform has *way* more functionality than I will ever need (chatwoot). It's interesting to see what it can do, because it looks really extensive. With respect to the "production ready" classification of XEPs: while that's true, the same applies (on my little scale, at least) to using your forked code, because upstream rejected it and I won't know for sure they won't change their software architecture in ways that break your change. I was actually looking at it from the perspective that Guus is: if this can be moved into an "accepted" XEP, then nobody needs to implement it, but at least, it'll be a standard.

It's already a standard, status is meaningless

Guus, any reason why this was developed as an OpenFire plugin and not as a jabber component? The component XEP seems to date back to 2003, so that existed when the work on this thing started, correct?

(I'd expect a thing like this to have greater chances of seeing broad use when it can run on top of lots of servers?)

or if it was super useful maybe it'd have more than 1 implementation or maybe even some users? hard to say isn't it?

some things are super niche and only actually useful to a couple folks

Erik: I don't know, as I was not involved. I _expect_ that the reasons for doing it as a plugin is two-fold: I believe it was a paid thing, at one point, but maybe more importantly, an (external) plugin would have a lot less API accessible to it to integrate with the XMPP server's internals (like user and group management).

I may be completely wrong, though. I do know that in Openfire world, there was a tendency to create everything as a plugin. I suspect that it was just easier to develop / deploy things like that.

that makes sense. I'm thinking that since the xmpp protocol allows creation of MUC rooms and manage invitations anyway, it seems like the required APIs are already available through APIs in other XEPs. (I'm not intimately familiar with the details of those xeps, though, so I'm not sure about the effectiveness of invitations for example.)

A big plus of doing it in the server is that it is easier to hook into the graphical user interface for administrative management.

I think it would probably be possible to do it as a component , but alas here we are.

yea. just wondering. I should look at what we have, not at what we don't.

To add to the earlier conversation, I worked in that space for quite a while, and our implementation simply used MUC without any of the workgroup queues stuff.

In other words, that XEP is not the only way to do this stuff, and maybe it's not the best or maybe it's not necessary at all, and those are valid reasons to not have advanced it