I am creating custom clients for an IOT setup.
One client uses python xmpppy, the other Blazor SharpXmpp.
All works well for login, presence (udpates, subscriptions), messaging.
I want to implement XEP-50 Ad Hoc Commands. So I started with the discovery service.
However the implementation is fairly simple, when I send a disco#info request from A to B, OF replies instead. The request never reaches B. same behaviour the other way around (B to A).
If I directly send a command request (without a disco#info), OF replies with a 404, item not found.
I am clearly missing something here, I even read the source code, but cannot pinpoint what exactly.
If FO routes the message request, why would it “eat” the discovery or command requests
Any help would be appreciated
This looks like a hard requirement from the service discovery protocol, as defined in XEP-0030: Service Discovery. It states in section 3.1:
When an entity sends a disco#info request to a bare JID (<firstname.lastname@example.org>) hosted by a server, the server itself MUST reply on behalf of the hosted account, either with an IQ-error or an IQ-result.
I suppose that this is done to prevent a client from having to supply the same answer over and over again, for every entity that requests it.
I can understand that part to the extent of the prevention of disco flooding.
But atm the server is replying disco#info with features my client does not support.
I would expect that at some point, OF would send the client a disco#info and then cache it.
I will have a look at XEP-0115: Entity Capabilities which will propably fix my issue,
but I am puzzeld that Discovery as is (without a node) is useless.