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社区。在未来，开发者创建的数据，可以归属在开发者门下。