# ActivityPub 支持：第一阶段 RFC

**URL:** <https://meta.discourse.org/t/activitypub-support-phase-1-rfc/132624>\
**Category:** Feature\
**Tags:** rfc\
**Created:** [2019年十一月5日 08:38 UTC](https://meta.discourse.org/t/activitypub-support-phase-1-rfc/132624 "2019-11-05T08:38:55Z")\
**Posts on this page:** 1\
**Showing post:** 50

<div class="post-metadata">

**Author:** ![Mevo](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/mevo/32/187732_2.png) [@Mevo](https://meta.discourse.org/u/Mevo)\
**Post date:** [2021年一月19日 13:43 UTC](https://meta.discourse.org/t/activitypub-support-phase-1-rfc/132624/50 "2021-01-19T13:43:23Z")

</div>

感谢 @aschrijver，这非常有帮助。  
从第一段中，我领会到“明智地使用”这一理念。  
关于第二段，当我提到“ActivityPub”时，我更关注的是它所带来的功能或实现的效果，而非协议本身。比如你提到的“分享/链接内容”或“将内容从服务器边界中解放出来”这样的概念。

某种控制权或权力转移的想法很有意思：社区所有者将不再真正掌控“他们的”用户、“他们的”内容（至少是他们托管的内容）、访客来到他们的平台时能访问什么、信息如何组织和归类等等。用户将拥有更多控制权，更自由地选择他们想要的内容、来源，并打造属于自己的“菜单”。

我能理解这从用户视角来看可能很有吸引力，但从社区所有者的视角来看，可能会让人感到些许不安或担忧。

用餐厅来类比的话，我承认我之前的观点可能有点走得太远，比如把多个地方合并在一起。但我觉得你的类比过于温和：在我看来，这远不止你所描述的那样。这更像是去一家餐厅，却能够点另一家餐厅的菜品，由那家餐厅的厨师制作。这自然会引发一些问题（这也是我观点的核心部分）：为什么那位支付高薪、可能费尽周折才吸引并留住这位厨师的餐厅老板，会愿意不再拥有让顾客选择自己餐厅的明确理由？你的回答大致是：从顾客的角度来看这很棒。是的，当然，我同意。

不过无论如何，你在这点上可能是对的，而我提出的观点看起来很像过去企业对开源技术所抱有的担忧。

---

_[View the full topic](https://meta.discourse.org/t/activitypub-support-phase-1-rfc/132624)._