Difference between revisions of "XMPPComponentProtocol"
Jump to navigation
Jump to search
Neustradamus (talk | contribs) m |
Neustradamus (talk | contribs) m |
||
| Line 1: | Line 1: | ||
== XMPP Component Protocol == | == XMPP Component Protocol == | ||
The | The XMPP network has long included a wire protocol that enables trusted components to connect to XMPP servers. This has since been documented in the [https://xmpp.org/extensions/xep-0114.html Jabber Component Protocol specification (XEP-0114)]. This page documents arguments for and requirements of a superseding protocol. | ||
=== Arguments === | === Arguments === | ||
Revision as of 02:22, 17 December 2020
XMPP Component Protocol
The XMPP network has long included a wire protocol that enables trusted components to connect to XMPP servers. This has since been documented in the Jabber Component Protocol specification (XEP-0114). This page documents arguments for and requirements of a superseding protocol.
Arguments
Arguments for wanting a replacement component protocol:
- Have XMPP 1.0 XML Streams
- More intricate XEPs that require access to user information like roster and presence. An example is the Personal Eventing Protocol (XEP-0163).
- Handle several JIDs through one connection
Links
Current discussions
The most likely approach to improve the protocol is:
- First define a simple API of target operations.
- Propose an XMPP formalism for the API using "adhoc commands" that can be handled by the server.
One of the first target in the API is roster item addition (with nickname and subscription) and deletion.
Restrictions to remove
We discussed the removal of the restriction in XEP-0114 that prevent a component to send packets on the behalf of a user of the server itself.