Summary
Phase 3 of #167. Connect a community profile to the factions it belongs to, tying the social layer into the existing faction data and the Faction Leaderboard (pages/leaderboard.tsx).
The hard part (read before scoping)
There is currently no link between a website identity and a faction. The Faction entity (dpc-api) carries only aggregate fields — name, serverId, memberCount, description, serverIp, discordLink, timestamps — and no member identities. Factions are written by Medieval Factions servers via the sync path (POST /api/v1/factions); the site has no idea which UserAuth user is which in-game player. So this issue is not a simple join — it first needs a mechanism to associate a User with a faction. Options, roughly in increasing cost:
- Self-declared, unverified: a user picks factions on their profile from the synced list. Cheap; no proof.
- Claim + verify: a user proves control of an in-game player (e.g. an in-game
/dpc link <code> command in MF that posts the code to dpc-api), then membership is resolved from MF. Requires an MF-side change and the sync to carry member→player data it does not today.
- Sync member identities: extend the faction sync contract to include per-member player UUIDs, then map those to linked accounts. Largest change; touches the MF↔dpc-api contract (faction-wipe-sensitive — see the sync safety guards).
Suggested first cut
Ship Option 1 (self-declared) behind a clearly "unverified" label: a UserFaction link table (User ↔ Faction), authenticated POST/DELETE /api/v1/profile/me/factions/{factionId}, the chosen factions shown on the public profile (#181) linking into the leaderboard. File the verification path (Option 2/3) as a separate follow-up, since it requires an MF-side change and a contract review.
Why it matters
It connects the two halves of the site — the community layer and the faction data that is its reason for existing — and makes profiles meaningfully tied to gameplay.
Dependencies
Filed as a Phase 3 decomposition of #167; drafted by Claude on behalf of Daniel Stephenson. Claims verified against the Faction entity (no member-identity fields), FactionController, and pages/leaderboard.tsx.
Summary
Phase 3 of #167. Connect a community profile to the factions it belongs to, tying the social layer into the existing faction data and the Faction Leaderboard (
pages/leaderboard.tsx).The hard part (read before scoping)
There is currently no link between a website identity and a faction. The
Factionentity (dpc-api) carries only aggregate fields —name,serverId,memberCount,description,serverIp,discordLink, timestamps — and no member identities. Factions are written by Medieval Factions servers via the sync path (POST /api/v1/factions); the site has no idea which UserAuth user is which in-game player. So this issue is not a simple join — it first needs a mechanism to associate aUserwith a faction. Options, roughly in increasing cost:/dpc link <code>command in MF that posts the code todpc-api), then membership is resolved from MF. Requires an MF-side change and the sync to carry member→player data it does not today.Suggested first cut
Ship Option 1 (self-declared) behind a clearly "unverified" label: a
UserFactionlink table (User↔Faction), authenticatedPOST/DELETE /api/v1/profile/me/factions/{factionId}, the chosen factions shown on the public profile (#181) linking into the leaderboard. File the verification path (Option 2/3) as a separate follow-up, since it requires an MF-side change and a contract review.Why it matters
It connects the two halves of the site — the community layer and the faction data that is its reason for existing — and makes profiles meaningfully tied to gameplay.
Dependencies
Filed as a Phase 3 decomposition of #167; drafted by Claude on behalf of Daniel Stephenson. Claims verified against the
Factionentity (no member-identity fields),FactionController, andpages/leaderboard.tsx.