Advanced Message Processing - AMP XEP-0079

The Tigase server 5.1.0 or later offers support for Advanced Message Processing, called AMP or XEP-0079.

This may affect the server performance so it is not enabled by default and there is a couple of things you have to set to get it function properly.

Configuration is not very complex but as the AMP is implemented as a component in the Tigase server it does needs a few settings to get it right.

Here is a first, brief overview of the AMP configuration and later detailed explanation of each parameter.

--sm-plugins=amp,-message,-msgoffline
--comp-name-1=amp
--comp-class-1=tigase.server.amp.AmpComponent
--amp-repo-uri=jdbc:mysql://localhost/tigasedb?user=db_usr&password=db_pwd
--amp-security-level=STRICT
sess-man/plugins-conf/amp/amp-jid=amp@your-domain.tld

First of all: plugins.

Even though the whole functionality is implemented inside the component you need a way to forward messages with AMP payload to that component. This is what the 'amp' plugin does. The 'amp' plugin intercepts all <message/> packets even without AMP payload, redirecting some of the to the AMP component and others processing in a standard way. Therefore you no longer need 'message' plugin or 'msgoffline' plugin. Their all functions are offered by the 'amp' plugin now. Hence you have to switch the 'amp' plugin on and 'message' and 'msgoffline' plugins off:

--sm-plugins=amp,-message,-msgoffline

The 'amp' plugin needs to know where to forward all the AMP packets this is defined by the last line of the example configuration, which forwards all packets to the address 'amp@your-domain.tld':

sess-man/plugins-conf/amp/amp-jid=amp@your-domain.tld

Secondly: component. You configure Tigase to load a component in a standard way, providing a component name 'amp' is the most obvious choice and component class: tigase.server.amp.AmpComponent:

--comp-name-1=amp
--comp-class-1=tigase.server.amp.AmpComponent

Optional parameters:

There is also one parameter shared between the component and the plugin. Connection to the database where offline messages are stored. The AMP component has a dedicated schema for storing offline messages designed for a high traffic and high load installations. It does not use UserRepository for storing messages. By default the same physical database as for UserRepository is used but you can change it and store messages in a completely separate location to reduce performance degradation of rest of the system. You can set a database connection string using following property:

--amp-repo-uri=jdbc:mysql://localhost/tigasedb?user=db_usr&password=db_pwd

The XEP-0079 specification has a Section 9. - Security Considerations. As it describes, in some cases the AMP protocol can be used to reveal user's presence information by other users who are not authorised for presence updates. There are a few possible ways to prevent this.

The Tigase's implementation offers 3 modes to handle AMP requests to prevent revealing user's status to not authorised people:

--amp-security-level=STRICT

In this mode the server performs strict checking. The AMP specification is fully handled. This however involves roster loading for each offline user, hence it may impact the service performance. It may not be feasible or possible to run in this mode for services under a high load with lots of AMP messages.
In the XEP this mode is described in the following way:
Accept the relevant condition only if the sender is authorized to receive the receiver's presence, as a result of which the server MUST reply with a <not-acceptable/> error condition if the sender is not so authorized; this is the RECOMMENDED behavior.

--amp-security-level=PERFORMANCE

Dummy checking is performed, that is no checking actually. It just returns an error response every time there is a chance that the default action may reveal user status without looking into the user's roster. This does not affect performance but it does impact the AMPcompliance. In the XEP this mode is described in the following way:
Accept the relevant condition only if the action is "drop", as a result of which the server MUST reply with a <not-acceptable/> error condition if the action is "alert", "error", or "notify"; this is slightly less restrictive but still unnecessarily restricts the functionality of the system, so is NOT RECOMMENDED.

It does not do any checking. It acts like all people are authorised to receive notifications, even if it may reveal user status to unauthorised people. It does not impact the server performance and it offers full AMP compliance.

--amp-security-level=NONE