用 Beagle 登录

身份本该像现实生活一样运作

用户在网络上的行为和足迹，应该像现实生活一样：有据可查，有信可查。你走进一家店，店主看得见你来了、怎么来的、待了多久——但他拿不走你的钥匙，也要不到你的密码。

这才是改变社交软件和平台生态的必有之路，更接近生活，而不是一个把身份吞掉的孤岛。Decent Network 应有的样子，是各有各的角色、各有各的身份，而不是某一个 App 独占登录。

身份不归自己所有时做不到、归自己所有后就能做到的四件事：

• 认识自己的用户 —— 他们从哪条路来、叫什么、怎么联系、参加过哪场会。
• 可以给奖励 —— 没有出席和贡献的记录，就发不出积分、代币或席位。
• 也可以拒绝服务 —— 这是店主决定为谁开门，不是平台没收钥匙。
• 设定接收用户的条件 —— 指定地域、持有某种代币、持有某个 NFT。条件写在你这边，核验用的是用户出示的身份。

Beagle Meet 已经是这样一个跑在线上的案例：开会的人不把钥匙交给会议室，会议室记下签到与出席，主持人可以奖励、可以拒绝、可以加门槛。把这套做法带到你的服务里——我们一起改。

服务方应该记录什么 —— 线上真实案例

Beagle Meet 不存私钥、不存助记词、不存密码。它存的是一个人使用这项服务时出示的样子，以及在这里做过的事。正是这份记录，才使奖励和拒绝成为可能。

主持台把这些呈现为出席、成员、登录记录、准入四个视图，每一行都带 Carrier 地址 —— 于是主持人可以发消息、加好友、发奖励，而始终没有碰过对方的密钥。

搬到交易站、商店或论坛里，要抄的形状很短:验证进来、记录使用、可选拒绝、永不持有密钥。

接收用户的条件

检查按顺序执行，第一个拒绝生效：先是服务级拒绝，然后是房主的封禁名单，最后才是你自己写的门槛。门槛拿到的是用户出示的身份 —— userid、已存的资料、从哪条路来、进哪个房间 —— 返回放行或一个理由。

registerRoomGate(async (ctx) => {
  if (!inRegion(ctx))
    return { ok: false, error: '该房间在你所在地区不可用', code: 'region' };
  return { ok: true };
});

registerRoomGate(async (ctx) => {
  if (!holdsToken(ctx.userid, ctx.profile))
    return { ok: false, error: '需要持有会员代币', code: 'token' };
  return { ok: true };
});

新服务接入清单