[iOS · UX · Invitations] Explain delayed automatic approval of reciprocal subscription requests #28
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
[iOS · UX · Invitations] Explain delayed automatic approval of reciprocal subscription requests
Type: UX improvement
Discussion priority: Informed consent for presence sharing
Context: TestFlight 1.1.0 (96), manual testing on November 6, 2026. Related to #18.
Summary
After accepting a preauth invitation, a user may receive an automatically approved reciprocal subscription request significantly later, without ever seeing an incoming request card.
The current confirmation dialog explains that the contacts will eventually see each other's presence, but it does not explain that the application stores permission to automatically approve the next reciprocal request from that JID for up to seven days.
This can make the automatic action appear unexpected. During testing, it was unclear why another contact had been approved without a manual decision.
Confirmed example
On testman450@another.im, roster accept_invite was performed twice for an invitation from testman435, at 12:40:27 and 12:40:59 UTC. Mutual subscription was not completed at that time, and the reciprocal request remained pending.
At 13:47:15 UTC, the user of testman435 added testman450 through the normal Contacts flow. testman450 received an incoming subscribe event from testman435 with preauth=true.
The request was automatically approved, no pending request card was shown, and mutual subscription was established after the other side approved at 13:47:40 UTC.
Implementation context
The bundled backend (6f79790cbcf8b8cadc9bcd58eb321a492c3f9003) defines:
EXPECT_TTL = 604800 seconds
When accept_invite is called, the backend sends a subscription request and stores an expectation for the inviter. The first matching reciprocal request consumes that permission and is automatically approved.
The seven-day period applies to waiting for one reciprocal request. Presence updates are not delayed for seven days once mutual subscription has been established.
Requested UX changes
Explain the behavior before accepting an invitation.
The confirmation should state that Add sends a presence subscription request and authorizes automatic approval of a reciprocal request from that JID within the applicable waiting period.
Notify the user when delayed automatic approval actually occurs.
The in-app notification should name the contact and explain why the request was approved automatically.
Apply the explanation consistently to external links and QR invitations.
The missing confirmation in the QR flow is tracked separately in issue #18.
Provide localization.
Support RU, EN, and other supported languages, and display a period consistent with the actual backend policy.
Suggested confirmation text
Add testman435@another.im?
You will send a request to share presence information and allow the app to automatically accept a reciprocal request from this contact within 7 days. Once mutual subscription is established, you will be able to see each other's presence.
Cancel · Add
The wording and duration should be confirmed by Product and Development, especially if the backend policy changes.
Suggested notification
Presence sharing with testman435 was enabled automatically based on a previously accepted invitation.
The notification should be shown after mutual subscription is confirmed.
If only one direction has been approved, the message should reflect the actual state, for example:
The reciprocal request from testman435 was approved automatically based on a previously accepted invitation.
Acceptance criteria
Before Add, the user sees the JID, the presence-sharing implications, and the duration of the automatic-approval permission.
Cancel does not call accept_invite or create a new automatic-approval permission.
A matching reciprocal request received later may be automatically approved according to the accepted policy, and the UI explains the automatic action.
The notification accurately reflects the resulting subscription state; mutual visibility is only stated after subscription=both.
Expired or already consumed permissions are not presented as active.
Normal contact addition and preauth invitations provide explanations appropriate to their actual behavior.
External links, QR invitations, and RU/EN localizations are verified.
Note: The specific stored expectation record was not retrieved from the database. The proposed wording and the seven-day duration as a product policy require confirmation. This is a UX improvement request; no implementation has been performed.
The wording is done in branch
fix/app-issues-25-28(https://dev.another.im/another-im/anotherim-swift/compare/master...fix/app-issues-25-28), commited0d2375: the invitation question (links and scanned codes alike, see #26) now says: "They are asked to share their status with you, and if they ask to see yours within 7 days, that is approved without asking you again. They can message and call you." (ru/uk/et/es too). Note: the 7 days and the auto-approval are libtacky's (roster.tclEXPECT_TTL, an expectation kept on the device that accepted), not the server's. The notice when such an approval happens needs libtacky to say why a subscribe came pre-approved (-preauth 1is also set for our own token's users and for gateway contacts): another-im/libtacky#22.