# 不同Discourse实例之间共享账号和统一用户体验

**URL:** https://meta.discourse.org/t/shared-account-and-unified-user-experience-between-different-discourse-instances/308947
**Category:** Feature
**Created:** [2024年五月22日 02:33 UTC](https://meta.discourse.org/t/shared-account-and-unified-user-experience-between-different-discourse-instances/308947 "2024-05-22T02:33:51Z")
**Posts on this page:** 9
**Page:** 1

<div class="post-metadata">

### Author: ![fokx](https://avatars.discourse-cdn.com/v4/letter/f/958977/32.png) [@fokx](https://meta.discourse.org/u/fokx)
#### Post date: [2024年五月22日 02:33 UTC](https://meta.discourse.org/t/shared-account-and-unified-user-experience-between-different-discourse-instances/308947/1 "2024-05-22T02:33:51Z")

</div>

我们已经看到许多项目/公司使用 Discourse 作为讨论论坛。但是，我经常觉得为每个网站注册账户有点麻烦（尽管 SSO 在一定程度上缓解了这种痛苦），并且设置用户个人资料和偏好设置等也很麻烦。

我想知道，就像选择加入“Discourse Discovery”一样，我们是否可以为网站所有者添加一个选项，允许他们选择与 CDCK 共享账户信息？基本上，这可以意味着添加一个类似“使用 Discourse 登录”的 SSO 选项。此外，为了更紧密地集成，我们可以像 Reddit 那样在不同的社区之间共享用户信息和偏好设置。如果用户可以在一个地方访问他们汇总的活动/书签/点赞/回复数据，那就更好了。

另外，是否可以跨不同实例共享通用的 js/css/字体资源，以加快首次加载速度？

---

<div class="post-metadata">

### Author: ![michaeld](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/michaeld/32/1594_2.png) [@michaeld](https://meta.discourse.org/u/michaeld)
#### Post date: [2024年五月22日 05:45 UTC](https://meta.discourse.org/t/shared-account-and-unified-user-experience-between-different-discourse-instances/308947/2 "2024-05-22T05:45:35Z")

</div>

那将是“隐私地狱”，任何 Discourse 实例都将可以访问任何其他 Discourse 实例的所有用户名和电子邮件地址。甚至可能更多。所以这永远是不可接受的。

---

<div class="post-metadata">

### Author: ![JammyDodger](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/jammydodger/32/254611_2.png) [@JammyDodger](https://meta.discourse.org/u/JammyDodger)
#### Post date: [2024年五月22日 06:27 UTC](https://meta.discourse.org/t/shared-account-and-unified-user-experience-between-different-discourse-instances/308947/3 "2024-05-22T06:27:28Z")

</div>

我认为这个功能在这里也被提到了：

> [@mcwumbly](#):
>
> > [@simon](#):
> >
> > 我不确定这是否会与推广去中心化互联网的理念相悖，但或许可以研究一下让该网站充当身份验证提供商的功能。
> 
> 我认为提供更多有价值的中心化服务是值得考虑的。一个可以减轻设置社交登录麻烦的身份验证提供商是一个不时被提及且非常在考虑中的选项。
> 
> 我们只需要注意以一种避免它们成为严格依赖的方式来做，这样网站就可以继续完全独立地运行，并得到社区的全力支持。

---

<div class="post-metadata">

### Author: ![simon](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/simon/32/339122_2.png) [@simon](https://meta.discourse.org/u/simon)
#### Post date: [2024年五月22日 07:17 UTC](https://meta.discourse.org/t/shared-account-and-unified-user-experience-between-different-discourse-instances/308947/4 "2024-05-22T07:17:40Z")

</div>

> [@JammyDodger](#):
>
> 我认为这里也提到了这个功能：

算是吧，但我当时只考虑将 Discourse 作为可选的 OAuth 提供商。也许这是一个滑坡。

---

<div class="post-metadata">

### Author: ![pmusaraj](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/pmusaraj/32/119489_2.png) [@pmusaraj](https://meta.discourse.org/u/pmusaraj)
#### Post date: [2024年五月22日 17:53 UTC](https://meta.discourse.org/t/shared-account-and-unified-user-experience-between-different-discourse-instances/308947/5 "2024-05-22T17:53:55Z")

</div>

> [@michaeld](#):
>
> 那简直是“隐私地狱”，任何 Discourse 实例都可以访问任何其他 Discourse 实例的所有用户名和电子邮件地址。

不一定。未来的“使用 Discourse 登录”服务可以像其他社交登录（Google、Apple、Facebook 等）一样运行。仅仅因为启用了这些登录方式，并不意味着该实例可以访问源头的所有用户名和电子邮件地址。关联账户仅为使用该方法注册/登录的用户创建。

OP 中的请求是我们一直在考虑的事情，这是一个有趣的选项，可以降低加入新的 Discourse 社区的门槛。但这将是一个非常、非常大的项目，到目前为止，我们一直犹豫是否要着手进行。这绝对是我们内部经常提出的一个想法。

---

<div class="post-metadata">

### Author: ![michaeld](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/michaeld/32/1594_2.png) [@michaeld](https://meta.discourse.org/u/michaeld)
#### Post date: [2024年五月31日 04:50 UTC](https://meta.discourse.org/t/shared-account-and-unified-user-experience-between-different-discourse-instances/308947/6 "2024-05-31T04:50:00Z")

</div>

> [@pmusaraj](#):
>
> > [@michaeld](#):
> >
> > 那简直是“隐私地狱”，任何 Discourse 实例都可以访问任何其他 Discourse 实例的所有用户名和电子邮件地址。
> 
> 不一定。未来的“使用 Discourse 登录”服务可以像其他社交登录（Google、Apple、Facebook 等）一样运行。

那些_确实_是隐私地狱……

---

<div class="post-metadata">

### Author: ![awesomerobot](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/awesomerobot/32/142900_2.png) [@awesomerobot](https://meta.discourse.org/u/awesomerobot)
#### Post date: [2024年五月31日 17:29 UTC](https://meta.discourse.org/t/shared-account-and-unified-user-experience-between-different-discourse-instances/308947/7 "2024-05-31T17:29:02Z")

</div>

> [@michaeld](#):
>
> 那些_确实_是隐私地狱……

这些公司特别存在一些隐私问题，但它们的功能也远不止集中式身份验证。

我认为可以论证集中式身份验证本身也伴随着风险，但你最初的说法并不准确，而且与这方面关系不大：

> [@michaeld](#):
>
> 任何 Discourse 实例都可以访问任何其他 Discourse 实例的所有用户名和电子邮件地址

---

<div class="post-metadata">

### Author: ![michaeld](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/michaeld/32/1594_2.png) [@michaeld](https://meta.discourse.org/u/michaeld)
#### Post date: [2024年五月31日 18:43 UTC](https://meta.discourse.org/t/shared-account-and-unified-user-experience-between-different-discourse-instances/308947/8 "2024-05-31T18:43:05Z")

</div>

> [@awesomerobot](#):
>
> 您最初的说法并不准确

我承认我错了。

不过，我认为这很难符合 GDPR 的规定。

---

<div class="post-metadata">

### Author: ![eisammy](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/eisammy/32/528804_2.png) [@eisammy](https://meta.discourse.org/u/eisammy)
#### Post date: [2024年五月31日 19:04 UTC](https://meta.discourse.org/t/shared-account-and-unified-user-experience-between-different-discourse-instances/308947/9 "2024-05-31T19:04:48Z")

</div>

Discourse Auth 以提供数据哈希来启动多实例会话，但我们仅仅信任 Discourse 来保管我们的哈希是去中心化论坛的一个困境。

Lemmy 做了类似的事情，但使用了 ActivityPub，我们都知道那是一场噩梦。
