User Identity · 用户身份设计(v4,2026-10-15,Jeff Vega,卡 2610.1065)

0. 一句话

One User · One Login · Multiple Identities · Multiple Personas(一个用户、一个登录、多个身份、每个身份多个分身)。 - 用户只有一份,放在 HOOP。邮箱、手机、Apple、Google 认的都是它,登录一次。 - 身份:个人(HOOP 用)、商业(Loop 用)、创作者。开了才有,各有一份资料。 - 分身:每个身份下面可以有几张脸(名字 + 头像),每个群自己选用哪一张。 - 每个 App 决定接受哪几种身份;封号封的是「某个身份在某个 App」。 - 有用户 ≠ 能进某个 App:要有那个 App 接受的身份,而且在那个 App 的状态是正常。

1. Jeff 10-15 定下的规则(按语音整理)

1. Loop 注册 / 登录先到 HOOP 的登录引擎认人;HOOP 没有这个人就当场建用户(07:20、08:01、08:05)。
2. 用户看到的是 Loop 自己的登录页,HOOP 在背后认人;「用 HOOP 一键登录」是另一件事,以后再做(08:01、08:04)。
3. Loop 来的新人不过 HOOP 的邀请门,直接进 Loop;他在 HOOP 有用户,但 HOOP 的门没为他开就进不了 HOOP(08:53)。
4. HOOP 新人自动进官方频道,Loop 来的人不需要(08:53)。
5. HOOP 删号 / 封号只影响 HOOP,Loop 照常;用户留着,只是 HOOP 的状态改成不能进(08:53、08:57)。
6. 没下载或退出 HOOP,他仍是 Loop 会员,资料还在(10:00)。
7. 叫法:One User · One Login · Multiple Identities;身份就是资料;用户主表只记用户的东西(10:05)。
8. 个人身份 = HOOP,商业身份 = Loop(10:07);还有创作者身份;每个身份下面多个分身,为了隐私;三层(10:27)。
9. 每个 App 允许几种身份进来,封掉一个身份它就进不了那个 App;Loop 下面也要有分身(10:32)。
10. 分身只是我自己的名字和头像,和公司无关;是哪家公司的成员是另一回事(10:34)。
11. 数据合并放第二版,第一版只做账号关联;合并用验证码确认、被封的号登不进去合并不了、合并不能撤销、Sparks 合在一起(10:45、10:48)。
12. 这份是整个项目的 User Identity,不是 Loop 的;放 HOOP 和 Loop 两边的知识库,同一份(10:53)。
13. 不可以影响 HOOP 现在的登录;表结构要改,要很谨慎,做好再延伸到 HOOP(10:53)。
14. Jeff 的测试:用他 HOOP 的账号(Gmail)登录 Loop,要看到他所有的朋友 —— 朋友们自己还没装 Loop,但在他的角度要看得到(10:53)。
15. 用户一定只有一份、两边一模一样、而且最完整;放 HOOP 一边还是两边,选维护最好的(10:53)。

2. 三层:用户 → 身份 → 分身

全文只用这三个词。「资料」不是另一样东西,只是身份那一页上写的内容。

外加一张「身份在各 App 的使用状态」(identity_app_access)。

规矩: - 事实放用户层,展示放身份层。 生日、实名只存一份;名字、头像、职业、性格每个身份各填各的,改一边不覆盖另一边。 - 分身只属于一个身份,用哪个是你的自由;每个群自己记住选的哪个。 - 隐私:别人默认看不出两个分身、两个身份是同一个人;公开资料和接口都不露这层关联。只有管理和安全审查看得到。 - 封号三级:一个分身 → 只关它;某身份在某 App → 它在这个 App 的所有分身一起关,别的 App 不跟着封;整个用户 → 全关,只用于最严重的情况。 - 分身不是公司。是哪家公司的成员是另一件事,不写进资料、不给分身任何权限;公司这一层不在这份范围。

2.1 新表(都在 HOOP 数据库)

identities —— 每人每种身份一行 - id(身份 ID)· user_id(外键 users.id;(user_id, kind) 唯一)· kind:personal / business / creator - 按类型的资料:个人(职业、性格……;已有字段仍读 user_profiles,不搬)、商业(业务介绍)、创作者(作品介绍) - created_at · deleted_at · delete_source(admin / member)

personas —— 每个身份几行 - id · identity_id · display_name · avatar_url · is_default · status(active / banned) - 个人身份的默认分身就是 user_profiles,这里不再存一份。群里选哪个分身,沿用 conversation_members.persona_scope(000032)的做法,改成记分身 ID。 - ⚠️ 表名和现有的 personas(000031)撞名,建表时新表另取名或把旧表并进来,H1 定。

identity_app_access —— 某身份在某 App 的状态 - 主键 (identity_id, app);app:hoop / loop · status:active / suspended / banned / deleted · suspended_until

每个 App 接受哪几种身份写在代码配置里(今天:HOOP = 个人、创作者;Loop = 商业),改它不用改表。 上线时给每个现有用户补「个人身份 + 个人身份在 HOOP」,状态照抄今天的 users.status;开发者再补创作者身份。

3. 用户只有一份:放在 HOOP,Loop 不存副本(回答第 1 节第 15 条)

决定(建议):用户、身份、分身、好友关系都只存在 HOOP 一边。Loop 的数据库不存任何一份用户资料,只存 Loop 自己的内容(工作、消息……),每一行挂在身份 ID 上。 - 为什么不两边都存:两份就要同步,同步一定会有一刻对不上(改名、换头像、删号、封号的那几秒),还要多写一套补偿程序。一份就永远一模一样,这正是「最完整」。 - Loop 要用户资料时:Loop 后端调 HOOP 的只读接口(任务 H6),短缓存几分钟;HOOP 改了,缓存过期就是新的。 - 代价:HOOP 的账号服务挂了,Loop 新登录会失败(已登录的人凭证还能用到过期)。所以账号服务要单独看可用性。Google、Meta 那种统一账号是同样的做法、同样的代价。 - ⚠️ Loop 现在的后端自己有一套用户表和注册(从 hoop-core 复制的登录,LOOP记忆.md §6)。按这一节,那一套要停用,改成验 HOOP 的凭证(任务 L1)。

4. 在 Loop 里看到 HOOP 的朋友(回答第 1 节第 14 条)

Jeff 的测试:用 HOOP 账号登录 Loop,要看到他所有的朋友,哪怕朋友们还没装 Loop。

做法:好友关系是用户和用户之间的,只存 HOOP 一份(好友表在 000001_init.up.sql,接口 GET /v1/friends,friend/handler.go:65)。Loop 不另建好友表,直接读这一份。 - Loop 显示好友列表时,每个朋友显示:他在 HOOP 用的默认名字和头像(你在 HOOP 本来就看得到,不算新泄露),以及「已在 Loop」或「还没加入 Loop」。 - 还没加入的朋友:显示成灰色、可以邀请;加入以后他用自己的商业身份出现。 - 隐私:Loop 只给本来就是你好友的人看到这些,陌生人在 Loop 里搜不到你的个人身份。 - ⚠️ 这一条和 v3 不同:v3 写「好友各 App 管各的」,按 10:53 的测试要求改成「好友关系共用、内容(朋友圈、动态)各 App 管各的」。要 Jeff 确认(第 13 节第 1 条)。

5. 登录流程

现有登录入口(backend/internal/domain/auth/handler.go:26-31)不换路径,请求里多一个字段 product(不带 = hoop,旧版 HOOP App 完全不受影响)。

a) 在 Loop 用邮箱或手机验证码登录 1. Loop App 请求验证码,带 product: loop → 发 Loop 品牌的邮件 / 短信(auth.Config.Brand 已能按产品给文案)。 2. 用户填验证码 → 登录引擎核对 → 用邮箱 / 手机号找用户(FindUserByContact,service.go:427)。 3. 没有 → 建用户(CreateUser,service.go:465),跳过邀请门、不跑 HOOP 的建号钩子(官方频道)。 4. 查他的商业身份和「商业身份在 Loop」:没有就建;封禁 / 已删除就拒绝。 5. 发一张只给 Loop 用的登录凭证(第 7 节)。

b) 在 Loop 用 Apple / Google:先按 Apple / Google 编号找用户,找不到再按已验证的邮箱找。Apple 的坑见第 8 节第 1 条。

c) 只有商业身份的人打开 HOOP:认出用户,发现没有个人身份 → 这时才走 HOOP 邀请门;过了就建个人身份、跑官方频道钩子。⚠️ 今天「老用户登录不查邀请门」(service.go:427-432),这一步必须和 Loop 登录同时上,否则 Loop 成了绕过邀请门的路。

d) 已有 HOOP 的人第一次进 Loop(Jeff 的测试就是这条):找到用户 → 建商业身份和它的默认分身 → 进 Loop。默认分身要不要先填上 HOOP 的名字和头像,见第 13 节第 2 条。

6. 每种情况怎么算

表里「个人身份」= 个人身份在 HOOP 的状态,「商业身份」= 商业身份在 Loop 的状态。

注销页让用户选「只注销这个 App」或「全部一起注销」。

7. 登录凭证

今天 HOOP 的凭证是 HS256 的 JWT,没有「给哪个 App」,只验签法和签发者(token.go:24-67)。 - HOOP 的凭证一字不改 —— 现有用户不会被踢下线。 - Loop 的凭证另签:Ed25519,写 aud: loop。HOOP 中间件只认 HS256 + 签发者 hoop,Loop 的凭证到 HOOP 自然被拒;Loop 后端只认 aud: loop。 - Loop 后端只拿公钥(/.well-known/jwks.json),本地验,拿不到任何能签凭证的秘密。 - 续期凭证(refresh_tokens,000001_init.up.sql:133-145)加 product 列:Loop 的续期只能换 Loop 的凭证。 - 每次请求还要查状态:HOOP 查「用户没删且个人身份在 HOOP 正常」(今天查用户状态,blocked.go:163-167);Loop 查「用户没删且商业身份在 Loop 正常」。

8. 要提前知道的坑

1. Apple 登录两个 App 对不上号。Apple 编号按开发者团队分:HOOP CL4ZMA59T6,Loop YZD2N9XXN4(LOOP记忆.md §7);隐藏邮箱的转发地址也不同。对不上的人,登录后给「关联已有的 HOOP 账号」入口(验证码确认)。Google 没这个问题,Jeff 用 Gmail 测试不受影响。
2. 今天的删号、封号改的是用户本身。管理员删号走 auth.SoftDeleteTx(repository.go:611-679),封号走 risk.go:211-221,都改 users.status。不改的话 HOOP 一删号 Loop 就登不上(任务 H3)。
3. 两家公司共用用户资料要写进条款。Loop 的 Apple 账号是 ONECARE WELLNESS SDN. BHD.;两边隐私条款写明「用 HOOP 账号登录」,注册页也写一句。
4. 重复账号(Jeff 10:45 / 10:48 定):
5. 第一版不做数据合并。一个用户可以绑好几种登录方式;HOOP 已有登录后绑 Apple / Google(/v1/auth/apple/bind、/v1/auth/google/bind,handler.go:39-40)。注册时邮箱和已有用户的已验证邮箱一样,就提示「你已经有账号了」。
6. 第二版合并:另一个号收一次验证码确认是本人;被封的号登不进去,本来就合并不了;合并不能撤销;Sparks 合在一起;旧用户 ID 留「旧 → 新」对照。Loop 数据挂在身份上,以后合并只要把身份换个用户挂。

9. 不影响 HOOP 现在的登录:守则(回答第 1 节第 13 条)

1. 只加不改:新表、新列、新接口;不删、不改名任何现有列和接口。迁移号从 backend/migrations/LEDGER.md 取。
2. 默认等于今天:登录请求不带 product 就是 HOOP、走今天的每一步;HOOP 凭证、签发者、密钥都不动,没有人会被踢下线。
3. 先补数据、再换读法:先上表并回填(H1),核对「个人身份在 HOOP 的状态」和 users.status 一行不差,才让中间件改读新表(H2)。
4. 开关:Loop 相关的路(product: loop、Loop 凭证、只读接口)全挂在一个服务器开关后面,关掉就回到今天。
5. 会红的回归测试,每一步上线前跑:HOOP 验证码 / Apple / Google 登录、续期、退出、所有设备退出、邀请门、官方频道、管理员删号 / 恢复 / 封号、用户注销,结果和今天一样。
6. 上线顺序:只走 tools/deploy_backend.sh;先测试环境、再生产;每步可单独回滚。

10. 任务清单

「测试必需」= Jeff 第 1 节第 14 条那个测试之前必须做完。认领人是建议,第 14 节讨论定。

11. Jeff 的测试怎么走

1. 打开 Loop 测试版 → 选 Google → 用他 HOOP 的 Gmail 登录。
2. 不需要邀请码,直接进 Loop;后台看到:同一个用户 ID,多了商业身份和「商业身份在 Loop:正常」。
3. 好友列表:HOOP 里的每个朋友都在,显示 HOOP 的名字和头像;没装 Loop 的标「还没加入」。
4. 打开 HOOP:一切照旧,登录没变,没被踢下线,资料没变。
5. 用另一个只在 Loop 注册的测试号打开 HOOP:被邀请门挡住(证明没有绕过)。 做完这五步,第 10 节标 ✅ 的任务才算交付。

12. 多个身份,这样设计好不好

好,比只加一个「能不能进」的开关更好:Meta 的账户中心就是一个账号、Facebook 和 Instagram 各有主页和封禁状态;HOOP 自己已经有「开发者 = 第二身份」和「分身」;Jeff 定的规则不用写特例就成立。

13. 还没定的

1. 好友共用(第 4 节):好友关系共用、朋友圈和动态各 App 管各的 —— 对吗?
2. 已有 HOOP 的人第一次进 Loop,商业身份的默认分身要不要先填上 HOOP 的名字和头像(他可以再改)?
3. 注销默认「只注销这个 App」还是「全部」?(建议前者)
4. Loop 的后端放哪台机器(LOOP接口方案.md §9 第 1 条)。
5. Jeff 的测试要看到真实朋友,所以 H1–H6 要上 HOOP 生产(都是只加不改、带开关);测试用的是生产的用户和好友数据(只读)。

14. 讨论分工(Jeff 10:53「每一个细节你们各自讨论然后定下来」)

每条讨论定了,就改本页对应那一节和第 10 节那一行;不另开卡,都记在卡 2610.1065。

15. English summary

This is the project-wide User Identity design, not a Loop-only document. HOOP, Loop and every future app identify people this way.

Model. One User · One Login · Multiple Identities · Multiple Personas. The User exists once, in HOOP: email, phone, Apple and Google all lead to it. Identities are personal (used in HOOP), business (used in Loop) and creator; each has its own profile fields. Personas are faces (name + avatar) under an identity, and each group remembers which persona you use. Each app decides which identity kinds it accepts, and a ban targets "this identity in this app". New HOOP tables: identities, personas, identity_app_access. Existing user_profiles, personas and developers map in.

One copy (Jeff: "the user must be one, identical, most complete"). User, identities, personas and friendships live only in HOOP. Loop's database stores no user copy, only Loop content keyed by identity ID. It reads users via HOOP read-only APIs with short caching. Loop's current own user table must be retired (L1).

Seeing HOOP friends in Loop (Jeff's test). Friendship is user-to-user and stored once in HOOP. Loop shows your HOOP friends with their HOOP default name and avatar, marked "on Loop" or "not on Loop yet". This changes v3's "friends per app"; Jeff to confirm.

Login. The existing endpoints gain product (missing = HOOP, unchanged). Loop login finds or creates the User, skips HOOP's invite gate and official channel, and creates the business identity. A Loop-only user opening HOOP must pass the invite gate. Loop tokens are Ed25519 with aud: loop, verified via JWKS; HOOP tokens are untouched.

Do not break HOOP login. Changes are additive only. Requests without product behave as today. Backfill first and verify row-for-row before switching reads. Loop paths sit behind a server switch. Regression tests run before every step, and deployment goes through tools/deploy_backend.sh, test before production.

Tasks. HOOP: H1 tables and backfill, H2 middleware read, H3 per-identity delete/ban, H4 product login, H5 Loop tokens, H6 read-only APIs, H7 persona APIs, H8 login-method binding. Loop: L1 retire own users, L2 login page, L3 friends list, L4 personas, L5 Apple linking. Also D1 knowledge bases, R1 review, T1 Jeff's test. Needed for the test: H1, H2, H4, H5, H6, L1, L2, L3.

Traps. Apple IDs differ per developer team (Gmail testing is unaffected). Today's delete and ban change the User itself. Both privacy policies must say "sign in with your HOOP account". Duplicate accounts: v1 binds several login methods; merging is v2.

Open. Shared friendships? Pre-fill the Loop default persona from HOOP? Default deletion scope? Loop server location? The test needs H1–H6 on HOOP production (additive, behind a switch).