Roster: say why a subscribe came pre-approved, so the app can tell an accepted invitation's auto-approval from a token's or a gateway's #22

New issue

Open

opened 2026-11-07 08:55:41 +00:00 by fmodf · 1 comment

fmodf commented

2026-11-07 08:55:41 +00:00

Split from another-im/anotherim-swift#28 (reported by @asemeniv on 2026-11-06). The app's part, the confirmation's wording, is done there; this is the part that needs libtacky.

After roster accept_invite, libtacky keeps an expectation for the inviter (roster.tcl :786 EXPECT_TTL 604800, Expect :838) and approves the inviter's reciprocal subscribe when it comes (OnSubscription :553-558, TakeExpected), emitting roster <Subscribe> -preauth 1. QA asked that the app tell the user when this happens ("Presence sharing with X was enabled automatically based on a previously accepted invitation").

The app cannot word that: -preauth 1 is also emitted when someone uses our invitation token (:559) and for XEP-0100 gateway users (TransportApprove, :597), so a notice on preauth would also fire for those.

Asked: say why a subscribe came pre-approved, e.g. <Subscribe> … -preauth 1 -reason expected|token|transport (or a separate event for a consumed expectation), documented in TackyWire. The app would then show the notice for expected only, once the subscription is both ways.

> Split from another-im/anotherim-swift#28 (reported by @asemeniv on 2026-11-06). The app's part, the confirmation's wording, is done there; this is the part that needs libtacky. ## A notice when a subscribe was auto-approved: libtacky does not say why After `roster accept_invite`, libtacky keeps an expectation for the inviter (`roster.tcl` :786 `EXPECT_TTL 604800`, `Expect` :838) and approves the inviter's reciprocal subscribe when it comes (`OnSubscription` :553-558, `TakeExpected`), emitting `roster <Subscribe> -preauth 1`. QA asked that the app tell the user when this happens ("Presence sharing with X was enabled automatically based on a previously accepted invitation"). The app cannot word that: `-preauth 1` is also emitted when someone uses *our* invitation token (:559) and for XEP-0100 gateway users (`TransportApprove`, :597), so a notice on `preauth` would also fire for those. **Asked:** say why a subscribe came pre-approved, e.g. `<Subscribe> … -preauth 1 -reason expected|token|transport` (or a separate event for a consumed expectation), documented in TackyWire. The app would then show the notice for `expected` only, once the subscription is both ways.

fmodf referenced this issue from another-im/anotherim-swift

2026-11-07 08:55:58 +00:00

[iOS · UX · Invitations] Explain delayed automatic approval of reciprocal subscription requests #28

ann referenced this issue from a commit

2026-11-07 17:20:10 +00:00

roster: <Subscribe> -reason says why a subscribe came pre-approved, expected (an accepted invitation's inviter), token (one of our invitation tokens) or transport (a gateway's user), "" with -preauth 0 (#22)

asxpi referenced this issue from another-im/interop

2026-11-07 17:28:33 +00:00

Verify libtacky bugs from the AI interop runs (v1.2.0-rc2, 71 found) #1

ann referenced this issue from a commit

2026-11-07 22:27:34 +00:00

HANDBOOK: regenerated for the #21 and #22 schema changes (ChatEntry, roster <Subscribe> -reason)

ann commented

2026-11-07 23:13:23 +00:00

Owner

Added in libtacky v1.2.1 (https://dev.another.im/another-im/libtacky/releases/tag/v1.2.1): roster <Subscribe> now carries a -reason of expected, token or transport ("" when it is a plain preauthorized subscribe with no cause), so the app can tell an accepted invitation's auto-approval apart from a token's or a gateway's. It is documented in the TackyWire schema.

Please check with v1.2.1 or newer.

Added in libtacky v1.2.1 (https://dev.another.im/another-im/libtacky/releases/tag/v1.2.1): roster `<Subscribe>` now carries a `-reason` of `expected`, `token` or `transport` ("" when it is a plain preauthorized subscribe with no cause), so the app can tell an accepted invitation's auto-approval apart from a token's or a gateway's. It is documented in the TackyWire schema. Please check with v1.2.1 or newer.