[keyserver] Send farcaster_mutual UPDATE_RELATIONSHIP message when establishing Farcaster relationship
ClosedPublic
Actions

Authored by ashoat on Apr 21 2024, 4:57 PM.

Details

Reviewers

atul
ginsu

Commits

rCOMM1548889e36d8: [keyserver] Send farcaster_mutual UPDATE_RELATIONSHIP message when establishing…

Summary

This is developed from my Hackathon commit 7024301fcda748efefa900bd952cd8e127aac87d, but updated to reflect changes @atul has made to allow us to include FID:

Updates to the structure of the UPDATE_RELATIONSHIP message
Updates to the FARCASTER_MUTUAL API

Note that I also updated the code to avoid creating KNOW_OF relationships between the viewer and themselves.

Test Plan

I tested this during the Hackathon, but haven't tested the updates since then. Will try to test this in the office this week

Diff Detail

Repository

rCOMM Comm

Lint

No Lint Coverage

Unit

No Test Coverage

Event Timeline

ashoat created this revision.Apr 21 2024, 4:57 PM

Herald added a subscriber: tomek. · View Herald TranscriptApr 21 2024, 4:57 PM

Harbormaster completed remote builds in B28347: Diff 39329.Apr 21 2024, 5:14 PM

ashoat requested review of this revision.Apr 21 2024, 5:14 PM

atul mentioned this in D11712: [lib] Shim unsupported messages for `web`/`desktop`.Apr 22 2024, 10:13 AM

Change looks good, but we should probably land something like D11712 first so web/desktop clients receive shimmed UNSUPPORTED messages?

This revision is now accepted and ready to land.Apr 22 2024, 10:16 AM

Makes sense – I'll defer landing this

ashoat added a parent revision: D11712: [lib] Shim unsupported messages for `web`/`desktop`.Apr 26 2024, 5:41 PM

atul mentioned this in rCOMM4c5a86dbda62: [lib] Shim unsupported messages for `web`/`desktop`.May 1 2024, 4:54 PM

I haven't landed this yet because I'm having trouble testing it while tethering and don't have access to Wi-Fi right now. Will hopefully find some Wi-Fi tomorrow

Finally got to testing this and found some issues:

The list of userIDs passed to createPersonalThreads is not filtered through fetchUserInfos, which can lead to validateCandidateMembers throwing when createThread is called. This issue was present with relationshipActions.FRIEND as well. I addressed it by adding a third parameter to createPersonalThreads that passes in the filtered list of userIDs.
We weren't filtering the viewer out before calling createPersonalThreads. (This one wasn't affecting relationshipActions.FRIEND; it's specific to relationshipActions.FARCASTER_MUTUAL.)
We aren't specifying dontPrefixCreator when shimming UPDATE_RELATIONSHIP messages. Will address in a separate diff.