People with access lists the same friend twice when my already-shared Bot joins that friend's invite (talk-through grant shown as a share) #383

Summary

On A, Chief > Edit Bot > Sharing > People with access lists the same friend twice:

SelfB0023 (@selfb0023.home)   [Revoke]
SelfB0023 (@selfb0023.home)   [Revoke]

One row is A's real share of Chief. The other is the server's talk-through grant that was created when A's Chief joined B's invite for Helper. The talk-through grant should not be shown as a share (it is filtered correctly when the joining Bot was not already shared, see #342/#178), and People with access should show one row per person in any case.

Environment

• FlyBot main 6d04db6682fa87033e58a176121f878b3ba293ce (About FlyBot describes FlyBot: its repository, stars, links, build and update text #375), core + plugins/social + plugins/tree on @deepseek-ai/dsh@0.2.0-rc.2, Node 24.
• Two fresh installs on one Linux box: A :3090 (owner SelfA0023, @selfa0023.home, own Bots Chief + Scratch) and B :3091 (owner SelfB0023, @selfb0023.home, own Bots Chief + Helper). Bot Social prod https://47-80-69-220.sslip.io.
• Setup: A made an invite for A's Chief, B joined it with B's Chief. Then B made an invite for Helper, A joined it with A's Chief. So A sees friend's Bot Helper, B sees friend's Bot Chief (A's).
• Product self-test, focus D (Social list and + menu), 2026-10-19 00:23–00:35 Asia/Shanghai. Screenshots stayed on the test machine; what they show is written out below.

Repro

1. On A, make an invite for Chief (Chief > Edit Bot > Sharing > Invite to this Bot, or right-click > Copy invite link). On B, + > Add friend, paste it, talk through Chief, Accept invite. (In this run: local API social/create-invite / social/join-invite, 00:28:20.)
2. On B, make an invite for Helper. On A, + > Add friend, paste it, talk through Chief, Accept invite. (00:28:40.)
3. On A, hover Chief in the sidebar, click the gear (Edit Bot), open Sharing, look at People with access.

Actual

• Two identical rows SelfB0023 (@selfb0023.home), each with its own Revoke button. Screenshot: A's Chief Sharing section, People with access with the two identical SelfB0023 rows stacked, each with a Revoke button on the right.
• The local access API for A's Chief (verify/post2-access-chief-a.json) returns two grants for the same grantee:
  • grt_01M57XFF848JSFGSE9M2REVM8F, relationship rel_01M57XFF82CC8RE69TS4HD0MMH (invite 1: A shared Chief with B, the real share);
  • grt_01M57XG2HB5TPSS83YHTNVTMYP, relationship rel_01M57XG2H9WXDQ4BDK2MMSVY6M (invite 2: the talk-through grant on the joiner Bot, A's Chief).
• After step 1 only (verify/post1-access-chief-a.json) there was one grant. B's Chief (which joined invite 1 and was never shared) correctly has grants: [], so Accepting an invite never shows the inviter's Bot to the joiner, and the joiner's Chief lists the inviter in People with access (regression of #178 from #334) #342 does not reproduce.
• Everything else is correct: A sees friend's Bot Helper, B sees friend's Bot Chief (A's).

Expected (per-Bot grants, simplicity)

• A talk-through grant is never listed in People with access, also when the same Bot is already shared with that person.
• People with access shows one row per person (merge grants by grantee), with one Revoke that removes the real share.
• Revoke must not remove the talk-through grant A's Chief needs to talk to B's Helper.

Pointers for the fixer (not verified)

• plugins/social/src/social.js isTalkThroughGrant() matches a grant only when a roster home entry has relationshipId === grant.relationshipId. list_remote_bots on A returns one entry for @selfb0023.home with relationshipId: rel_01M57XFF82CC8RE69TS4HD0MMH (invite 1), while the talk-through grant belongs to rel_01M57XG2H9WXDQ4BDK2MMSVY6M (invite 2). So with two relationships to the same home, the second one's talk-through grant may never be recognised. That fits "only when the Bot was already shared" but needs checking.
• Hunch only: clicking Revoke on the second row may revoke A's talk-through grant and break A's chat with Helper. Not tried.

Related

#342, #178, #138 / #161 (joiner's Bot is not shared back), #336 (talk-through grant semantics), #275 (People with access naming).