[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

Branch

ashoat/farcaster

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.