Summary
Silo should support two kinds of household members:
- Managed profiles for guests, children, and temporary users.
- Independent Silo accounts that retain their own login, account settings, integrations, and personal data while appearing in a household's account switcher/home context.
A household owner should be able to invite an existing Silo account or invite someone to create one. Existing profiles should have a one-time claim or conversion path into an independent account so their eligible personal media state is not lost.
Leaving a household should remove the member account from the household's account switcher/home context without deleting the member's account or personal data. Library access should remain governed by the account's existing user and access-group permissions; changing those permissions is a separate explicit action.
User value / why v1
Profiles currently have personal watch state and profile-scoped Trakt/Simkl-style watch-provider connections, but they are not independent identities. They cannot own a Silo login, API keys, plugin account settings, external authentication, or other account-level integrations.
This is sufficient for guests who remain under the account owner. It is a poor fit for family members who may eventually need their own account, such as children who move out. Without this capability, their history and preferences remain attached to the original account, and there is no clean way to take that identity with them.
The v1 household model should establish the long-term distinction between managed users and real household accounts before the API becomes additive-only.
API surface
The following are proposed native API surfaces; exact payloads can be finalized during design:
GET /api/v1/household — return the current household, member type, membership status, and granted library/access summary.POST /api/v1/household/invitations — invite an existing Silo account or invite a person to create one. Household membership is separate from authorization; the destination account's user-level and access-group permissions determine its library access.POST /api/v1/household/invitations/{id}/accept — accept an invitation and join the household using the invitee's own account.DELETE /api/v1/household/members/{id} — remove household access while preserving the member account and personal data.POST /api/v1/profiles/{id}/claim — begin a one-time conversion of an eligible managed profile into an independent account, returning a migration preview/status.POST /api/v1/profile-claims/{id}/accept — accept the profile claim from the destination account.- A capability endpoint must advertise household membership and profile-claim support for clients.
The design must define which profile-owned state transfers, how primary profiles are handled, how collisions and active sessions are resolved, and how external provider credentials are reauthenticated rather than copied where appropriate.
Account identity must remain separate from managed-profile identity. Household membership must not be conflated with the server-wide administrator role or the profile is_primary flag. Profile restrictions cannot expand the access granted to the account by its user-level and access-group permissions.
Client impact (android / apple / web)
- Web: household member management, invitations, account acceptance, member switching, profile claiming, migration status, and leaving a household.
- Android: account invitation/acceptance, household member selection, independent-account sign-in, profile claiming, and leaving a household.
- Apple: account invitation/acceptance, household member selection, independent-account sign-in, profile claiming, and leaving a household.
- Jellyfin-compatible clients: review parity for independent accounts and preserve the existing managed-profile/PIN behavior where possible.
Rough size (server-side)
L
AI harness
Codex desktop app
AI tool(s)
Codex exec_command, web.run, GitHub CLI
AI model(s)
GPT-5
AI involvement
AI-assisted
Independent or adversarial review
The repository was reviewed for account/profile ownership, authentication and session boundaries, profile-scoped watch providers, invitations, storage backends, and related client/API work. Existing issues were searched by household, home member, external account, profile transfer, account linking, login, Trakt, and Simkl terms. No duplicate request for this capability was found. This issue proposes architecture and API direction; implementation-level adversarial review should occur during design and PR review.
Related work
Summary
Silo should support two kinds of household members:
A household owner should be able to invite an existing Silo account or invite someone to create one. Existing profiles should have a one-time claim or conversion path into an independent account so their eligible personal media state is not lost.
Leaving a household should remove the member account from the household's account switcher/home context without deleting the member's account or personal data. Library access should remain governed by the account's existing user and access-group permissions; changing those permissions is a separate explicit action.
User value / why v1
Profiles currently have personal watch state and profile-scoped Trakt/Simkl-style watch-provider connections, but they are not independent identities. They cannot own a Silo login, API keys, plugin account settings, external authentication, or other account-level integrations.
This is sufficient for guests who remain under the account owner. It is a poor fit for family members who may eventually need their own account, such as children who move out. Without this capability, their history and preferences remain attached to the original account, and there is no clean way to take that identity with them.
The v1 household model should establish the long-term distinction between managed users and real household accounts before the API becomes additive-only.
API surface
The following are proposed native API surfaces; exact payloads can be finalized during design:
GET /api/v1/household— return the current household, member type, membership status, and granted library/access summary.POST /api/v1/household/invitations— invite an existing Silo account or invite a person to create one. Household membership is separate from authorization; the destination account's user-level and access-group permissions determine its library access.POST /api/v1/household/invitations/{id}/accept— accept an invitation and join the household using the invitee's own account.DELETE /api/v1/household/members/{id}— remove household access while preserving the member account and personal data.POST /api/v1/profiles/{id}/claim— begin a one-time conversion of an eligible managed profile into an independent account, returning a migration preview/status.POST /api/v1/profile-claims/{id}/accept— accept the profile claim from the destination account.The design must define which profile-owned state transfers, how primary profiles are handled, how collisions and active sessions are resolved, and how external provider credentials are reauthenticated rather than copied where appropriate.
Account identity must remain separate from managed-profile identity. Household membership must not be conflated with the server-wide administrator role or the profile
is_primaryflag. Profile restrictions cannot expand the access granted to the account by its user-level and access-group permissions.Client impact (android / apple / web)
Rough size (server-side)
L
AI harness
Codex desktop app
AI tool(s)
Codex exec_command, web.run, GitHub CLI
AI model(s)
GPT-5
AI involvement
AI-assisted
Independent or adversarial review
The repository was reviewed for account/profile ownership, authentication and session boundaries, profile-scoped watch providers, invitations, storage backends, and related client/API work. Existing issues were searched by household, home member, external account, profile transfer, account linking, login, Trakt, and Simkl terms. No duplicate request for this capability was found. This issue proposes architecture and API direction; implementation-level adversarial review should occur during design and PR review.
Related work