Chat (XMPP)

Ways for UCOM to connect to a chat service:

1. As point to point using UCOM's identity as the sending party (possibly on behalf of a sending entity)
2. As a participant in an existing multi-party chat (MUC in XMPP parlance)
3. As a participant in a temporary multi-party chat that UCOM creates on the fly (to capture a conversation)

Having UCOM act as a straight chat proxy is impractical since upstream clients aren't connecting to it as a chat service, they use the SFI. Having UCOM masquerade as the actual user would require UCOM to be aware of the user's chat credentials.

In terms of incoming messages from the XMPP service, only one connection will need to be maintained (get chat) and the receiving process will need to be smart enough to route the incoming chat message appropriately. This could work as the receiving process extracting expected meta-data into the FlowFile for processing by a downstream genericized routing processor.