Matthew M opened 1 decade ago
|
|
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:
or for bot plugins at one time
Enabling it results in:
(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.
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 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. |
|
Referenced from commit 1 year ago
|
Type |
New Feature
|
Priority |
Normal
|
Assignee | |
RedmineID |
1696
|
Version |
tigase-server-8.0.0
|
Estimation |
4h
|
Does Tigase support this feature of pre-approve in roster? http://xmpp.org/rfcs/rfc6121.html#sub-preapproval
I would like to solve this problem. User A sends a subscription request user B. Once B approves, B would like to add A as buddy too to become mutual friends, e.g., roster type ="both". I think in the real world, most likely two person would become "mutual" buddies.
So it would be nice for A to pre-approves B, while sending subscription request to B, so that A does not have to approve again (manually) when B sends back another subscription request.
Do you know if Tigase supports this? If not, what would be the best way to achieve this: skipping user A's manual approval of subscription from B?
See discussion: https://projects.tigase.org/boards/4/topics/1084
Thanks!