Show federated user profiles on local instance instead of redirecting externally #8

New Issue

GKaszewski · 2026-06-30T01:14:06Z

GKaszewski commented

2026-06-30 01:14:06 +00:00

This was generated by AI during triage.

Summary

When a federated entry appears in the activity feed, clicking the username currently opens the remote actor's profile on their home instance (external redirect). Instead, the local instance should render a federated profile page at /users/{user_id} using data already stored locally.

Current behaviour

Feed entries with is_federated: true link to the remote actor URL (e.g. https://movies.gabrielkaszewski.dev/users/…) in a new tab
Before this workaround was added, clicking the username caused a 404 on the local instance because /api/v1/users/{user_id} has no record for the synthetic user ID

Expected behaviour

/users/{user_id} works for both local and federated users. For federated users, the backend detects that the ID is synthetic, resolves the actor URL from stored reviews, looks up ap_remote_actors, and returns a profile response. The SPA shows their handle, display name, bio, avatar, and their locally-stored federated reviews — all without leaving the instance.

Data already available locally

Source	Fields
`ap_remote_actors`	`handle`, `display_name`, `bio`, `avatar_url`, `banner_url`, `outbox_url`
`reviews WHERE remote_actor_url IS NOT NULL`	all federated reviews by this actor

The synthetic user_id is UUIDv5(actor_url) so the actor URL can be looked up via SELECT remote_actor_url FROM reviews WHERE user_id = ? AND remote_actor_url IS NOT NULL LIMIT 1.

Implementation sketch

Backend:

In GET /api/v1/users/{user_id}: if no local user found, query reviews to find remote_actor_url, then look up ap_remote_actors
Return a profile DTO covering both local and federated users (handle, display name, bio, avatar, federated reviews, basic stats)
New application use case users/get_federated_profile + new port method on the federation query side

SPA:

/users/{user_id} already navigates correctly — no route changes needed
Profile page needs to handle the federated variant of the DTO (no local stats like watch-time, show handle + instance badge instead)
actor_url on ReviewCard becomes a fallback only for actors not yet cached in ap_remote_actors

ap_remote_actors table populated during Follow/Accept flow and actor fetch
reviews.remote_actor_url column links reviews to their remote author
Synthetic user IDs computed in review_handler.rs on_create

> *This was generated by AI during triage.* ## Summary When a federated entry appears in the activity feed, clicking the username currently opens the remote actor's profile on their home instance (external redirect). Instead, the local instance should render a federated profile page at `/users/{user_id}` using data already stored locally. ## Current behaviour - Feed entries with `is_federated: true` link to the remote actor URL (e.g. `https://movies.gabrielkaszewski.dev/users/…`) in a new tab - Before this workaround was added, clicking the username caused a 404 on the local instance because `/api/v1/users/{user_id}` has no record for the synthetic user ID ## Expected behaviour `/users/{user_id}` works for both local **and** federated users. For federated users, the backend detects that the ID is synthetic, resolves the actor URL from stored reviews, looks up `ap_remote_actors`, and returns a profile response. The SPA shows their handle, display name, bio, avatar, and their locally-stored federated reviews — all without leaving the instance. ## Data already available locally | Source | Fields | |--------|--------| | `ap_remote_actors` | `handle`, `display_name`, `bio`, `avatar_url`, `banner_url`, `outbox_url` | | `reviews WHERE remote_actor_url IS NOT NULL` | all federated reviews by this actor | The synthetic `user_id` is `UUIDv5(actor_url)` so the actor URL can be looked up via `SELECT remote_actor_url FROM reviews WHERE user_id = ? AND remote_actor_url IS NOT NULL LIMIT 1`. ## Implementation sketch **Backend:** 1. In `GET /api/v1/users/{user_id}`: if no local user found, query reviews to find `remote_actor_url`, then look up `ap_remote_actors` 2. Return a profile DTO covering both local and federated users (handle, display name, bio, avatar, federated reviews, basic stats) 3. New application use case `users/get_federated_profile` + new port method on the federation query side **SPA:** - `/users/{user_id}` already navigates correctly — no route changes needed - Profile page needs to handle the federated variant of the DTO (no local stats like watch-time, show handle + instance badge instead) - `actor_url` on `ReviewCard` becomes a fallback only for actors not yet cached in `ap_remote_actors` ## Related - `ap_remote_actors` table populated during Follow/Accept flow and actor fetch - `reviews.remote_actor_url` column links reviews to their remote author - Synthetic user IDs computed in `review_handler.rs` `on_create`

GKaszewski closed this issue

2026-07-10 15:18:29 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: GKaszewski/movies-diary#8