1. 社区
1.1. 基本介绍
社区是地球号用户的最高组织单位，也是独立的注册单位。社区的概念是隔绝注册的，用户在一个社区里注册后，只能在这个社区登陆，不能在另一个社区登陆。同一个电话号码可以在A社区注册，也可以在B社区注册。
1.2. 超级社区
地球号内建一个特殊的社区:XdUaDuA，任何人都可以注册这个社区的None角色。从地球号官网注册的用户具备初始角色 dua:God。这个网站将来会开放给开发者注册。目前不会开放。
1.3. 应用绑定
一个应用只能绑定到一个社区，一个应用不能绑定到多个社区。这个设计固化在应用表里,在app表里，每个app有个zone_id字段（这个设计还有回旋余地）。通过这种对应关系，可以看到一个社区的应用授权列表。在这里强调App和Zone的多对1关系，是因为这确实是一个要思考的点。要思考这个问题，我们就一个一个讨论，一共有三种情况。我们分别在下面分析。分析的角度有如下几点：
- APP的登录问题，登录进入哪个Zone。
- APP生成的令牌，令牌里的sub字段只能填写一个app_id。
- APP开发的成本，例如在智慧养老环境下，护工APP和家属APP该如何区分,是同一个APK还是多个APK。同一个APK可以进入APP通过APP内选择不同的按钮来选择不同的token。
- APP要访问算法和数据的时候算哪个社区？
1.3.1. 多应用.v.多社区/单应用.v.多社区
在这种设计下，需要专门的App+Zone的绑定表支持，这种设计会出现多个问题。 问题1：App在设计登录的时候，需要尝试从多个Zone去登录，判断用户和密码。此时，如果多个Zone都有同一个电话号码的时候，就还需要其它机制来决定是按照哪个电话登录。问题2：应用生成的token令牌里的sub(app_id)字段只能填一个，不能满足这个1v多关系。
优点
这种设计好像没有什么优点。
缺点
设计复杂。而且就算是开发多APP,可以在一个APK内通过APP内部机制切换令牌。当然在网页控制台，也可以通过不同入口切换不同的令牌，切换不同的APP_ID。所以在设计上，根本不需要多v多的关系。
1.3.2. 多应用.v.单社区/单应用.v.单社区
在这种设计下，就不需要额外的App+Zone的绑定表支持。每个APP只能登录一个Zone（注意，一个用用可能包含多个APP,只要切换令牌就行。）
1.4. 算法社区
算法访问目前统一放在ALgoALgo社区。在未来，开发者创建的算法，可以归属在开发者门下。
1.5. 数据社区
数据访问目前统一放在DaTaDaTa社区。在未来，开发者创建的数据，可以归属在开发者门下。
[!note] 为什么必须在创建专门的社区供算法和数据用？ 因为
XdUaXDuA社区权限太高了，为了不污染它，专门造就了算法和数据社区。
2. 应用在哪里创建？
应用只能在社区创建，应用不能在店铺和企业创建。这个结论是经过深思熟虑考虑过的，
- 因为登录令牌只能在社区创建
- 因为用户登录是以社区作为隔离的，所以登录令牌里的shop_id必须是社区直辖店铺ID。在某些情况下，我们可能使用企业ID和店铺ID作为登录ID,那样，登录就直接进入店铺，这样的登录方式，我们称为
跃进登录。系统现在支持跃进登录。但不鼓励。 - 假如不支持跃进登录，我如何做一个APP,登录后直接进入店铺。
- 先以社区登录方式登入，紧接着采用
AddLogon方式登续到店铺。 - 这样的方式很不优雅，还是直接登录比较优雅。
- 直接登录的问题是，登录令牌的创建需要应用ID(因为登录令牌中的audience字段)。而这个字段依赖之前必须创建一个应用。
- 而合适创建应用的地方只有社区控制台（开发者）。
- 因为企业和店铺的创建和维护都已经是客户的范围了。
- 你不可能让客户创建企业后，在企业管理界面再创建一个应用。