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
When an entity sends a disco#info request to a bare JID (<account@domain.tld>) 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.