Hi!
I’m working on a retro XMPP server enabling old machine (and by extensions old clients) to connect and chat. I’m stumbling on an issue where some clients assume that jabber:iq:agents exists and just waits and waits for a response. Is jabber:iq:agents support removed from the code base or is there any way to re-enable it?
Thanks!
That namespace seems to correspond to XEP-0094: Agent Information. That one is so old, that I’ve never actually seen it. 
I do not think that Openfire ever had support for this.
Adding support should not be to hard, by writing a plugin that is an IQHandler for that namespace.
Thanks for the answer! I’ll have to learn some Java and have a look at it I guess
Hehe, yep, that thing is old, but then again, so is Openfire. 
Interesting! I wonder if it would be a hard task to implement these in one (or two) plugins.
Never wrote a single line of Java before, but I might give it a shot.
Any help is greatly appreciated! 
I am curious why you are up to this task. Is it out of personal interest or is this is paid gig?
I’m knee deep in the retro computer scene, hence the question in the first place.
Trying to get as much “current” technology to older computer platforms (focusing on Classic Mac OS and Amiga). XMPP clients running on those platforms havent been updated in 15-20 years in some cases and only support these now legacy XEP’s. Many of the clients wont even authorize properly without the “Agent list” being transferred from the server. I used to run a jabberd14 server hosting services with spectrum2, but since the project died I moved to OpenFire which I have grown to like quite a lot.
So no, it’s not a payed gig. Just a very passionate hobby project
Is there anyone willing to help me out with this? I would gladly pay for your effort. Would help the retro computer community in general quite a bit.
Thinking of adding the functionality to OpenFire again through a plugin, much like Non-SASL Authentication is added through a plugin. Is a feasible task to undertake by a novice or am I more or less doomed?
It took a while, but I got around to it: GitHub - igniterealtime/openfire-agentinformation-plugin: This plugin implements the (obsolete!) XEP-0094 'Agent Information' specification for service discovery using the jabber agents namespace.
And here’s the other one: GitHub - igniterealtime/openfire-jabberbrowsing-plugin: This plugin implements the (obsolete!) XEP-0011 'Jabber Browsing' specification for service discovery using the jabber browse namespace.
Wow! An enormous THANK YOU to you, @guus and the OpenFire team for pulling this off.
I’m stunned.
Will give it a go right away. Thank you again! 
Let me know how things fare. Those protocols are depredated for a reason. I had to make some compromises while implementing things. Also, I didn’t have any client to test this with, so YMMV.
It works, but in the answer from the server when requesting the list of agents using jabber:iq:agents, the returning list doesn’t include the “register” child as per XEP-0094: Agent Information so the transports can only be unregistered and not registered. Otherwise it works like it should from what I can see. The agents/transports can listed correctly etc 
EDIT: I see now that the search services doesn’t get the “service” jabber:iq:agents child either, so something is wrong with the populating of the extended information.
I haven’t had an opportunity to test Jabber Browse yet.
To add some information about the problem, @guus.
This is the what my client is sending:
<iq to="my.xmpp.server" id="E8077E8EEDEBC012" type="get">
<query xmlns="jabber:iq:agents"></query>
</iq>
This is the answer I’m getting back:
<iq type="result" id="E8077E8EEDEBC012" from="my.xmpp.server" to="username@my.xmpp.server/Resource">
<query xmlns="jabber:iq:agents">
<agent jid="facebook.my.xmpp.server"><name>Facebook Chat</name></agent>
<agent jid="discord.my.xmpp.server"><name>Discord</name></agent>
<agent jid="skype.my.xmpp.server"><name>Skype</name></agent>
<agent jid="telegram.my.xmpp.server"><name>Telegram</name></agent>
<agent jid="icq.my.xmpp.server"><name>ICQ</name></agent>
</query>
</iq>
Hope this helps in narrowing down the issue.
Thanks again for all your hard work
I’m thinking that this is caused by a combination of factors:
We can probably work around both, by simply forcing some features being advertised on things like transports. It’s probably a safe bet that for every transport, there is some kind of registration feature.
@Knezzen are you able to build and test these plugins from source? I’m happy to add improvements, but getting some feedback faster than only after a release would be helpful.
That could be true, I’m not sure how Spectrum2 does things, but I know that “registration” was avaliable in the jabber:iq:agents implementation when I ran the service on jabberd2.
@guus I have no experience in compiling Java applications, so I’m not sure where to begin even.
Does the “Snapshots” on the plugin download page get compiled using whatever code is avaliable through github? I could use that function to test it out if that’s the case.
Is your Spectrum2 instance exposed to the outside world? If so, I could try to query it, to see if it returns the responses that the code expects.
We can work with the snapshot releases. Those get automatically populated when a change is merged in the main branch of the source code repository.
That would be helpful: also, can you enable trace logging, and see what gets logged when a request is made?