Wojciech, you worked on something very similar not long ago. Please have a look at it. Could we make modifications to your recent work to support this optional RFC feature?

There is already a ticket for pre-approving subscription (#1590) planned for the next version.

However your case is a bit different (extends aforementioned) because it entails automatic setting of pre-approved flag.

We implemented a while back something similar - automatic approving subscription and adding contact to roster but again it's not exactly what you need (it doesn't respect others party subscribing to our request and sending request on it's own), you can control it with following settings, either turning it on for particular plugin:

sess-man/plugins-conf/jabber\:iq\:roster/auto-authorize=true
sess-man/plugins-conf/presence/auto-authorize=true

or for bot plugins at one time

sess-man/plugins-conf/auto-authorize=true

Enabling it results in:

• upon sending by the user subscription request - adding contact to user roster with subscription both, adding user's contact to contact's roster with subscription both, exchanging presence information of contact and user so they can see each other online;

• upon sending presence with type either unsubscribe or unsubscribed follows rules defined in RFC regarding processing of such stanza (i.e. adjusting subscription type of user/contact) but without forwarding such unsubscribe/unsubscribed stanza to receiving entity to avoid any notifications for the client; however a roster push is generated to reflect changes to presence in user roster in a seamless manner;

• simply adding item to the roster (i.e. with <iq/> stanza with correct semantics) will also entails automatic subscription between user and the contact in a matter explained above.

(above description use RFC notions for the following terms: user - owner of the roster, contact - item added to the roster).

Bottomline - to meet your description we still need to implement #1590 - pre-approved state and then extend aforementioned mechanism of automatic subscription.

Thanks for the updates! This "automatic subscription" is really cool. In fact, we also tried to implement this, and I wish we had known this plugin early!

The only step missing here for us is the "contact" has to approve such subscription, then it becomes "both" immediately, therefore, as you said, it seems that "pre-approval" is the only missing step here.

Maybe I should describe our final goal here clearly, so there might be another route to achieve it. It's basically something like Facebook (Linked In) friending and de-friending process.

Basically, we should like our system to avoid the roster to be in the states of one-way-subscription, e.g, neither "to" nor "from". If two person becomes buddies, then only state must be "both" at the end. We are able to tweak our clients, so there is no problem to have multiple interactive steps between clients and server to reach the "both" or "none" states, with only one manual approval from one side to become friends. No approval is needed for de-friending.

1. user can INVITE or REMOVE friends,

2. contact must MANUALLY approve upon invitation to become friends, and AUTO subscript back to the user

3. user's client must AUTO approve on the subscription request back from the contact (more user friendly)

4. Eventually, system has rosters for anyone only in the state of subscription="both" or "none"

5. Important: XMPP clients have the restrictions of "memoryless" and "network disruption", for example a web BOSH client. The client has to rely on the roster status provided by the server to make decisions. It is completely okay for the client to do many retries to attempt to bring the roster to the final desired state (e.g., any stanza can be lost in either directions).

Based on original XMPP protocol, even without "pre-approval", it is totally fine for the contact client to automatically subscribe back to the user, and user's client can automatically approve, based on some roster states.

However, as due to the network disruption and memoryless of the client, I am stuck in the ambiguous roster state of "subscription=to | from". I am not sure whether this roster state is the middle of subscribe-and-approve process, or it is simply unsubscribed intentionally. Therefore there is no way for the client to automatically bring roster state to either "both" or "none", without customer manual interaction.

This is the main reason I came to ask about the "pre-approval" feature, as I feel this attribute can help the client to distinguish between the aforementioned ambiguous states. But I assume that "pre-approval" allows the roster to switch from "none" to "both" immediately upon the approval of contact (to eliminate any intermediate "from" or "to" states), is this true?

We would appreciate if you have any suggestion or advise to achieve our goals. The end results are pretty simple, just like what's Facebook friending (and de-friending) process: everything is two-way, with a manual approval on one side only. But it seems that XMPP is lack of a simple solution to achieve this popular goal?

Many thanks in advance!

For the moment you could tweak method tigase.xmpp.impl.Presence.processInSubscribe() to actually forward subscription request to the user and remove automatic generation of subscribed stanza (with automatic authorization turned on). This should result in desired behaviour.

Otherwise to have simpler authentication flow implementing pre-approved (#1590) is needed.

As for the ambiguity of subscription - when the contact is in the middle of subscription process roster item has additional attribute @item ask='subscribe'@.

Is it completed yet? if not how much work it needs to be completed?

Not yet, this is blocked by #1590. Upon finishing it, adding this functionality should take around 4h to implement.

I've proposed a patch, please see https://projects.tigase.org/issues/1590#note-22

Is duplicated by #1590.