feat: unified social identity layer (local + federated interop) #12

New Issue

GKaszewski · 2026-07-10T03:55:12Z

GKaszewski commented

2026-07-10 03:55:12 +00:00

Currently local users and federated remote actors are handled through completely separate code paths. Every social feature (following, watchlists, goals, activity feed) has to be implemented twice — once for local users, once for remote actors. This makes collaborative features like shared watchlists (#11) harder to build.

Problem:

UserId (local) and remote actor URL (federated) are different types with no common abstraction
Queries like "get this person's watchlist" branch on local vs remote
Adding any social feature (shared watchlists, group watch parties, recommendations) requires dual implementation

Proposal:
Introduce a SocialIdentity abstraction in the domain layer that unifies local users and remote actors:

enum SocialIdentity {
    Local(UserId),
    Remote { actor_url: String, handle: String },
}

Social features would operate on SocialIdentity instead of branching on local/remote. The resolution layer maps a SocialIdentity to the right repository (local DB vs AP fetch).

Benefits:

Shared watchlists (#11) work with any mix of local + remote users
Future features (recommendations, group watches, mentions) get federation for free
Simplifies the presentation layer — one handler per feature instead of two

Scope:
This is foundational infrastructure, not a user-facing feature. Best done before #11 so collaborative features build on top of it.

Open questions:

Where does SocialIdentity live? Domain value object?
How to handle capabilities (remote actors can't do everything local users can)?
Caching strategy for remote actor data?

Currently local users and federated remote actors are handled through completely separate code paths. Every social feature (following, watchlists, goals, activity feed) has to be implemented twice — once for local users, once for remote actors. This makes collaborative features like shared watchlists (#11) harder to build. **Problem:** - `UserId` (local) and remote actor URL (federated) are different types with no common abstraction - Queries like "get this person's watchlist" branch on local vs remote - Adding any social feature (shared watchlists, group watch parties, recommendations) requires dual implementation **Proposal:** Introduce a `SocialIdentity` abstraction in the domain layer that unifies local users and remote actors: ```rust enum SocialIdentity { Local(UserId), Remote { actor_url: String, handle: String }, } ``` Social features would operate on `SocialIdentity` instead of branching on local/remote. The resolution layer maps a `SocialIdentity` to the right repository (local DB vs AP fetch). **Benefits:** - Shared watchlists (#11) work with any mix of local + remote users - Future features (recommendations, group watches, mentions) get federation for free - Simplifies the presentation layer — one handler per feature instead of two **Scope:** This is foundational infrastructure, not a user-facing feature. Best done before #11 so collaborative features build on top of it. **Open questions:** - Where does SocialIdentity live? Domain value object? - How to handle capabilities (remote actors can't do everything local users can)? - Caching strategy for remote actor data?

GKaszewski referenced this issue from a commit

2026-07-10 15:11:05 +00:00

feat: unified social identity layer — SocialIdentity, ports, use cases, adapter

GKaszewski closed this issue

2026-07-10 15:11:05 +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#12