Page MenuHomePhabricator
Differential D11639

[lib] Add farcaster friend fids to sqlite
AbandonedPublic
Actions

Authored by will on Apr 11 2024, 10:46 AM.
Tags
None
Referenced Files
F5357359: D11639.diff
Wed, Apr 9, 11:40 AM
Unknown Object (File)
Wed, Apr 2, 10:06 AM
Unknown Object (File)
Tue, Apr 1, 3:58 PM
Unknown Object (File)
Tue, Apr 1, 8:51 AM
Unknown Object (File)
Mon, Mar 31, 6:24 PM
Unknown Object (File)
Fri, Mar 14, 11:49 PM
Unknown Object (File)
Feb 27 2025, 7:25 PM
Unknown Object (File)
Feb 27 2025, 7:25 PM
View All 60 Files
Subscribers
tomek

Details

Reviewers
ashoat
ginsu
atul
Summary

Depends on D11672

Test Plan

Tested with local prod keyserver build with physical iOS device.

Connected my farcaster account and confirmed auxUserStore was populated with farcaster mutuals:

Logs:

LOG  dispatching with [{"farcasterID": "388441", "userID": "AF283B63-D6E4-4C16-A10C-ECB96CC975FF", "username": "ginsu-test4"}, {"farcasterID": "389335", "userID": "0FD9CF89-17D9-4DDA-B457-6E4FC1571786", "username": "electrichack"}]

Went on to Warpcast and unfollowed both Ginsu and Varun and upon reconnecting Farcaster account, confirmed they were both null values

On following Ginsu or Varun individually, only one of them is added to auxUserStore.

Diff Detail

Repository
rCOMM Comm
Branch
farcasterAuxUser
Lint
No Lint Coverage
Unit
No Test Coverage

Event Timeline

will created this revision.Apr 11 2024, 10:46 AM
Herald added a subscriber: tomek. · View Herald TranscriptApr 11 2024, 10:46 AM
Harbormaster completed remote builds in B28179: Diff 39067.Apr 11 2024, 11:02 AM
will requested review of this revision.Apr 11 2024, 11:02 AM
will planned changes to this revision.Apr 11 2024, 11:46 AM
will edited the summary of this revision. (Show Details)Apr 16 2024, 2:35 PM
will added a parent revision: D11671: Makes fid optionally null so that we can delete the fid later.
will updated this revision to Diff 39165.Apr 16 2024, 3:21 PM

update to use commFCUsers and also clear prior fids

will edited the summary of this revision. (Show Details)Apr 16 2024, 3:25 PM
will edited the test plan for this revision. (Show Details)
will added a parent revision: D11672: create new aux user store action for clearing fids.
will edited the test plan for this revision. (Show Details)Apr 16 2024, 3:27 PM
This comment was removed by will.
will removed a parent revision: D11671: Makes fid optionally null so that we can delete the fid later.EditedApr 16 2024, 3:29 PM

Given that we're already checking farcaster friends in a useEffect, should we consider adding a syncing action type that not only adds new farcaster friends but also removes farcaster friends that we've unfollowed as well?

Currently, the "sync" only happens by having a user reconnect their farcaster account, clearing all their prior farcaster friends, and readding everything

Harbormaster completed remote builds in B28254: Diff 39165.Apr 16 2024, 3:37 PM
ashoat requested changes to this revision.Apr 17 2024, 6:33 AM

Back to you with questions:

should we consider adding a syncing action type that not only adds new farcaster friends but also removes farcaster friends that we've unfollowed as well

Doesn't the current approach (clearing and adding the current ones) achieve the same thing?

Currently, the "sync" only happens by having a user reconnect their farcaster account, clearing all their prior farcaster friends, and readding everything

Interesting... looking at the code, won't this get triggered on every app start?

Separately, thinking about this a bit more... is the purpose of putting FIDs in the aux user store so that we can show Farcaster accounts on user profiles in Comm? If so, shouldn't we fetch FIDs for all users in the UserStore, and not just for Farcaster friends?

This revision now requires changes to proceed.Apr 17 2024, 6:33 AM
will added a comment.Apr 17 2024, 8:40 AM

Separately, thinking about this a bit more... is the purpose of putting FIDs in the aux user store so that we can show Farcaster accounts on user profiles in Comm? If >> so, shouldn't we fetch FIDs for all users in the UserStore, and not just for Farcaster friends?

Might have misunderstood the spec then. I originally believed this would be used for storing farcaster info for farcaster friends. If it's the case that we want to do this for all users in the UserStore, we'd need another identity rpc that when given a list of userIDs, returns all their associated farcaster infos.

I'll check with @ginsu

ashoat added a comment.Apr 17 2024, 9:08 AM

we'd need another identity rpc that when given a list of userIDs, returns all their associated farcaster infos

After you sync with @ginsu, let me know and we can discuss the best next steps here. I'm curious about the cost here, and what our alternatives might be if the cost is too high.

Going forward, let's make sure we're thoughtful about starting from concrete product use cases when scoping work.

will added a comment.Apr 17 2024, 10:22 AM

Updated linear project with new tasks: https://linear.app/comm/project/farcaster-sqlite-followups-a2415120f443.

Canceling this task as we don't want to dispatch on just friends but on all users with farcaster integrations in our UserStore.

will abandoned this revision.Apr 17 2024, 10:23 AM
will mentioned this in D11672: create new aux user store action for clearing fids.Apr 17 2024, 10:31 AM

Revision Contents
Changeset List

PathSize
lib/
components/
16 lines

Diff 39067

View Options

lib/components/farcaster-data-handler.react.js

  • This file was added.
// @flow
import type { CommunityInfo } from 'lib/types/community-types.js';
import { dbQuery, SQL } from '../database/database.js';
import { Viewer } from '../session/viewer.js';
type ServerCommunityInfoWithHolder = {
...CommunityInfo,
+id: string,
+blobHolder: ?string,
};
tomekUnsubmitted
Not Done
Inline Actions
import { Viewer } from '../session/viewer.js';
- type ServerCommunityInfoWithHolder = {
+ type ServerCommunityInfoWithHolder = $ReadOnly<{
...CommunityInfo,
+id: string,
+blobHolder: ?string,
- };
+ }>;
async function fetchCommunityInfos(

We should make this readonly because spreading a type makes it writable.

tomek: We should make this readonly because spreading a type makes it writable.
async function fetchCommunityInfos(
viewer: Viewer,
): Promise<$ReadOnlyArray<ServerCommunityInfoWithHolder>> {
if (!viewer) {
return [];
}
const query = SQL`
SELECT c.id, c.farcaster_channel_id as farcasterChannelID,
c.blob_holder as blobHolder
FROM communities c
INNER JOIN memberships m
ON c.id = m.thread AND m.user = ${viewer.userID}
WHERE m.role > 0
`;
const [result] = await dbQuery(query);
const communityInfos = result.map(row => {
return {
id: row.id.toString(),
farcasterChannelID: row.farcasterChannelID,
blobHolder: row.blobHolder,
};
});
tomekUnsubmitted
Not Done
Inline Actions
const [result] = await dbQuery(query);
- const communityInfos = result.map(row => {
- return {
+ const communityInfos = result.map(row => ({
id: row.id.toString(),
farcasterChannelID: row.farcasterChannelID,
blobHolder: row.blobHolder,
- };
});
return communityInfos;
tomek:
return communityInfos;
}
export { fetchCommunityInfos };