Public followers and following pages#491
Conversation
Add `account_owners.following_list_public` (default false) and respect
it in three places that expose the list:
- the ActivityPub `setFollowingDispatcher` returns empty items and a
zero counter when the flag is off, so remote servers can't enumerate
the list either;
- the Mastodon-compatible `GET /api/v1/accounts/:id/following` returns
an empty array when the target is a local account with the flag off;
- `PATCH /api/v1/accounts/update_credentials` now persists
`hide_collections` to the flag (inverse), and `serializeAccountOwner`
exposes `hide_collections` so clients can round-trip the value.
The followers list stays public unconditionally.
Assisted-by: Codex:gpt-5.5
Add a "Make following list public" checkbox to the dashboard's account settings form, alongside the other Privacy toggles, and thread the value through the create and edit handlers so it persists on `account_owners`. Assisted-by: Codex:gpt-5.5
For each profile, expose `/@{handle}/followers` and (when the new
visibility flag is on) `/@{handle}/following` as plain HTML pages with
the same profile card on top and a paginated list of accounts below.
Pages are 100 entries each, ordered by follow-approval time, with a
substring filter over display name and handle backed by the existing
pg_trgm GIN indexes on `accounts.name` / `accounts.handle`. The
filter input uses `ILIKE` with `\\%_` escaped to prevent unintended
wildcard matches. The following page returns 404 when the account's
`following_list_public` flag is off, matching the behaviour already
applied to the ActivityPub collection and the Mastodon API.
Assisted-by: Codex:gpt-5.5
The followers count is now a link to the new `/@{handle}/followers`
page. The following count becomes a link to `/@{handle}/following`
only when the new *Make following list public* flag is on; otherwise
it remains plain text so the URL is never offered when the page would
404 anyway. Both links use a subtle theme-color hover transition,
consistent with the rest of the profile chrome.
Assisted-by: Codex:gpt-5.5
|
@codex review |
|
Codex Review: Didn't find any major issues. 🎉 ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces public 'Followers' and 'Following' pages to user profiles, including pagination and a search filter. It also adds a per-account setting to toggle the visibility of the following list, which defaults to private. When the following list is private, the web page returns a 404, the ActivityPub collection is hidden, and the Mastodon-compatible API returns an empty array. One piece of feedback was provided regarding a variable name in the Mastodon API implementation to improve clarity and consistency with other endpoints.
The Mastodon `/:id/following` handler reused `followers` as the local variable name for the list of accounts being followed, mirroring the adjacent `/:id/followers` handler. Renaming it to `following` lines the variable up with the endpoint and removes the confusion at a glance. fedify-dev#491 (comment) Assisted-by: Claude Code:claude-opus-4-7
|
/gemini review |
|
@codex review |
There was a problem hiding this comment.
Code Review
This pull request adds public Followers and Following pages to user profiles, including pagination and search capabilities. It also introduces a privacy setting to control the visibility of the following list across the web interface, Mastodon-compatible APIs, and ActivityPub federation. Feedback from the review suggests adding a secondary sort key to ensure deterministic pagination and refining the search logic to handle canonicalized handles more effectively.
|
Codex Review: Didn't find any major issues. Hooray! ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
The followers and following pages sorted by `follows.approved` alone, so ties (rows approved at the same instant) could shift between pages under offset pagination and items could be skipped or repeated. Break ties by the other side's account id, which is unique within an owner's follow set. fedify-dev#491 (comment) Assisted-by: Claude Code:claude-opus-4-7
|
/gemini review |
|
@codex review |
|
Codex Review: Didn't find any major issues. Already looking forward to the next diff. ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
There was a problem hiding this comment.
Code Review
This pull request introduces public 'Followers' and 'Following' pages for user profiles, including pagination and search functionality. It also adds a per-account setting to control the visibility of the following list, which defaults to private. The feedback provided identifies an inconsistency in the import pattern for the database connection in the newly added follows page, recommending a named import to align with the rest of the codebase.
Match the convention used by every other non-test file in src/ that pulls in the database handle, including the neighbouring profile route. fedify-dev#491 (comment) Assisted-by: Claude Code:claude-opus-4-7
|
/gemini review |
|
@codex review |
There was a problem hiding this comment.
Code Review
This pull request implements public 'Followers' and 'Following' pages for user profiles, featuring pagination and a substring search filter. It introduces a 'Make following list public' setting (defaulting to off) that gates the visibility of the following list in the web UI, ActivityPub collections, and Mastodon-compatible API endpoints. Feedback was provided regarding the optimization of the database query used for counting entries; specifically, removing a redundant join when no search query is active and capping the total count to prevent performance degradation on large datasets.
|
Codex Review: Didn't find any major issues. Another round soon, please! ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
When the followers / following page has no search query, the count query no longer joins against `accounts`. The `where` clause already filters on `follows` alone, and the join was only there to support the `ILIKE` filter, so the unfiltered count now goes straight against the partial index on `(follower|following_id, approved)`. fedify-dev#491 (comment) Assisted-by: Claude Code:claude-opus-4-7
|
/gemini review |
|
@codex review |
|
Codex Review: Didn't find any major issues. Nice work! ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
There was a problem hiding this comment.
Code Review
This pull request implements public "Followers" and "Following" pages for user profiles, featuring pagination and a search filter. It introduces a "Make following list public" setting that gates visibility across the web UI, ActivityPub collections, and Mastodon-compatible APIs. Feedback suggests documenting the current limitation where these pages only resolve local accounts, as well as improving handle normalization and search query logic for better federation compatibility.
1 participant
Adds public Followers and Following pages to every profile, with pagination (100 per page) and a substring search filter over display name and handle.
The followers list is always public. The following list is gated by a new per-account setting, Make following list public, off by default. When the toggle is off the page returns
404 Not Found, the ActivityPubfollowingcollection reportstotalItems: 0with no items, and the Mastodon-compatibleGET /api/v1/accounts/:id/followingreturns an empty array. The toggle also round-trips throughPATCH /api/v1/accounts/update_credentialsas the standardhide_collectionsfield, so existing Mastodon clients can read and write it.The search filter uses
ILIKEover accounts.name and accounts.handle, with\,%, and_escaped in user input so wildcard characters can't slip through. Queries reuse the existingpg_trgmGIN indexes on those columns, so no new indexes were needed.The schema change is one new boolean column on account_owners,
following_list_public, defaultfalse. The generated migration lives at drizzle/20260517021029_account_owners_following_list_public/migration.sql.Commits
Test plan
?page=N.404 Not Foundwhile the flag is off; toggling it on in account settings makes the page render and the AP collection reporttotalItemsmatching the row count.%and_finds no spurious matches.?page=values (0,-1,abc,1.5,999) all404 Not Found.