Facebook 用于个人宣传，Discourse 基于主题，Twitter 则发布短消息。至于其他平台，我就不太确定了。
1 个赞
我讨厌 Facebook，但似乎又离不开它。最近我只用它来参与我加入的“社群”。我尽量避开任何负面或充满戏剧性的内容！我完全理解你为什么想远离它！
3 个赞
确实——有大量证据表明，Facebook 等平台是当今我们目睹的极化加剧的重要源头：Why Social Media Makes Us More Polarized and How to Fix It | Scientific American
4 个赞
我使用 Discourse 的时间还不久，非常感谢 @pfaffman 帮我为我的小型公司搭建了一个社区。因此，我对这个优秀平台的方方面面还不完全熟悉。不过，我曾管理过几个基于 Facebook 群组的支持论坛，也运营过一些。
值得注意的是，对许多人（包括我）来说，留在 Facebook 的唯一原因就是群组。如果没有群组，我几年前就已经弃用 Facebook 了。事实上，如果我现在加入的两个群组迁移到 Discourse，我会毫不犹豫地离开 Facebook。因此，许多人与 Facebook 之间的联系其实非常脆弱。
我注意到以下几点：
- 用户希望以“一键加入”的方式加入群组，他们不想处理注册、登录或密码等繁琐流程。
- 帖子和评论的编辑界面必须无缝且简洁。Discourse 功能非常强大，但在认知负担上对许多用户来说过于复杂。必须让用户在极少干扰的情况下轻松发帖。
- 信息流固然重要，但真正驱动它的其实是 Facebook 所采用的具有成瘾性的通知系统。
也许我们并不需要复制 Facebook 那种成瘾机制。或许我们真正应该追求的是轻量级的联邦化模式。通过 DiscourseHub 让加入各个 Discourse 社区变得更加便捷，让通知获取更加简单，然后看看中期会带来怎样的效果。
6 个赞
我强烈推荐观看 The Social Dilemma 。对于不了解的人来说，这部影片揭示了 Facebook 如何凭借其平台的成瘾性机制运作。这让人联想到那些寻找 Reddit 替代方案的用户，例如 /r/watchredditdie 或 /r/redditalternatives 等子版块。最终，许多人会推荐 ActivityPub 等去中心化替代方案，但这又是另一个话题，适合在另一个线程中讨论。
3 个赞
今天我与一位尝试用 Discourse 替换 Facebook 但未能成功的安装客户进行了沟通。我建议可以尝试以下方法：
- 将 Facebook 群组设为只读
- 设法在 Facebook 群组中发布指向 Discourse 话题的链接
- 配置 Facebook 登录功能
我推测 Facebook 群组应该比我在 Facebook 动态中看到的那些“讨论”要好一些，但对于后者，几乎无法追踪整个对话。每当我看到想读的话题或线程时，几乎总是因为要点击两次才能看到每条消息而放弃。
5 个赞
以下是人们在 Facebook 上花费时间的四个主要领域：
-
与朋友聊天。 = Discourse 已支持。
-
Facebook 页面。 = Discourse 尚未支持。
*目前，在 Facebook 上你只能关注 30 个页面以在置顶通知中获取更新。 -
Facebook 群组 = Discourse 胜出
-
从个人主页发布帖子 = Discourse 已支持。
与 Facebook 相比，我更喜欢 Discourse。
在 Facebook 上，如果你拥有 4000 多位好友，很容易错过朋友的更新；但在 Discourse 上则不会。
在 Facebook 上，你无法像 Discourse 那样进行搜索。
在 Discourse 中，你可以查看用户活动（创建话题、点赞、回复），但在 Facebook 上则无法实现。
2 个赞
但除非你能说服他们迁移到你的 Discourse 服务器，否则你永远无法在 Discourse 上拥有那 4000+ 位朋友。这才是最难的部分。
2 个赞
因此，正如您已指出的那样，通过 Facebook 登录 Discourse 的想法至关重要。
3 个赞
不错！任何 OAuth 系统都应该是可配置的，这很合理。当然，让用户去检查“又一个网站”也是个问题。Facebook 经过多年积累，已经拥有了庞大的用户基础。
1 个赞
我上个月刚开了社区中心。由于种种原因，我的 Facebook 群组还远未达到“蓬勃发展”的状态……而我的初衷是，Discourse 能在以下几个关键方面超越 Facebook：
- 我可以设置公开和私密区域；
- 用户可以选择昵称，从而获得一些 Facebook 官方不允许的隐私保护！（我们讨论情感类问题，因此对姓名的隐私保护非常重要——而匿名模式对我们的社区来说真的非常有帮助！）
我相信有些团组的品牌形象和宗旨天然带有 Facebook 的风格。但对我们要来说，Facebook 是与品牌背道而驰的。它阻碍深度交流，还会主动隐藏指向 Facebook 外部内容的链接。
至于相关话题的讨论，Discourse 可以发挥惊人的作用。
想快速浏览？在 Facebook 的长评论中试试：你必须展开阅读对方写的内容，而且其格式非常受限。回复也被隐藏或嵌套，难以查看。
诚然，我投入了大量时间和精力来搭建新的 Discourse 社区，至于它能否成功，谁也无法预料。不过，既然我还有一个邮件列表，我正在做以下事情：
- 在社区中心发布新活动，无需登录即可查看，但鼓励需要注册后才能回复；
- 将 latest.rss 的 RSS 订阅源接入我的社交媒体发布平台（Publer），然后选择将新话题的帖子安排发布到我的页面和群组中；
- 识别那些渴望参与我们社区、且对 Facebook 持反对态度的人，帮助他们共同在 Discourse 的各个分类中营造互动氛围。
谢谢！也欢迎其他建议！
4 个赞
这里有很多与 Facebook 相关的话题，我也至少参与过其中一个。但我觉得这个议题也值得跟进。
重申并澄清问题
总体而言，我认为 Facebook 是一个功能繁杂但质量欠佳的单一平台。因此，当我们将其视为一个整体来讨论时，虽然并非完全错误，但我认为这会让讨论焦点模糊——甚至造成混淆。Facebook 的某些功能，Discourse 并不具备，而且在我看来也不应该尝试去实现（例如“好友”、“主页”等概念似乎超出了我们的范围）。但 Facebook 的某些功能实际上与 Discourse 有着相似的基本目标，只是执行得不够好。我主要指的是“群组”（Groups）。
问题在于，Facebook 让每个人（至少起初）都能轻松上手。对用户而言，加入群组、在已常访问的动态消息中跟进群组更新、以及通过评论或发帖进行互动，都非常便捷。它的界面熟悉，通知集中，甚至还有某种“智能”过滤功能。例如，我加入的那些每天发布数千条内容的群组，并不会完全淹没我的 Facebook 主信息流。
对管理员/社区建设者来说，Facebook 同样便捷。创建群组免费且只需几分钟，而且你在那里拥有一个现成的、相对“固定”的受众（例如你现有的 Facebook 好友）。他们只需点击几下（最少只需一次点击“加入”，如果你不要求用户先审阅规则）即可加入你的社区。
Facebook 的这些优势，尤其是对管理员而言，很难克服，或者超出了 Discourse 作为产品和团队可能希望提供的范围（例如为所有人提供免费托管）。但我们可以，而且我认为应该尝试解决用户端的问题，因为如果没有这种内置的受众基础，更少的主管会在第一时间选择 Facebook 群组。
我们都同意 Discourse 优于 Facebook 群组。然而……仍有许多非常成功且活跃的群组。这是我们作为 Discourse 用户、管理员、社区建设者，乃至开发团队本身，都应该认真思考的问题。因为那些 Facebook 用户并非认为这是讨论他们感兴趣话题的最佳方式，或能获得良好（呃）讨论的地方。他们大多是因为其便利性，正如上面许多人所讨论的那样。
所以，忘掉“好友”概念，忘掉"Facebook 是以人为中心而非以话题为中心”的说法。那仅适用于 Facebook 的部分功能。在群组中，帖子话题就是焦点，而非个人。就像 Discourse 一样。这使得它成为 Discourse 的竞争对手。一个很糟糕的竞争对手，但拥有不公平的优势。我希望我们能共同努力，随着时间的推移瓦解这种优势。
可能的解决方案
那么我们能做些什么呢？嗯，大多数可能更好（或至少最明显）的解决方案在这个话题中已经提出过了。我们需要找到一种统一认证的方法（基于自愿原则），并为管理员和用户都提供控制选项（例如，为用户设置“自动登录到属于联邦 Discourse 的 Discourse 实例”）。确定一种或多种在多个 Discourse 实例间统一通知的良好方法，并确保其跨平台，包括桌面端。甚至或许可以创建一个统一的“类似 Facebook 动态消息”视图，将多个论坛的话题呈现在单一列表中，理想情况下包含话题预览。这些确实是我们能够且应该讨论、思考，并 hopefully 着手解决的最低限度要求，以克服 Facebook 的惯性。
但也许我们可以走得更激进。个人而言，我正在研究将 Discourse 帖子注入 Facebook 动态消息的可能性。不是通过 Integromat 等工具将帖子发布到 Facebook，而是通过浏览器插件直接“黑客” Facebook 动态消息。
如果这真的可行（仍在调查中，我知道这听起来可能很疯狂），我愿意为此投入一些资金。所以我只想说，我言行一致。如果我能通过任何方式支持上述更专注于 Discourse 改进的努力，我也很乐意去做。
编辑：抱歉 @RickThrivingNow，我本意并非直接回复你的帖子。
7 个赞
有趣的想法。
有一件事会非常有用，而且相当激进：
一个 Facebook 群组迁移工具。它可以具备以下功能：
- 完整帖子和讨论的迁移
- 自动设置账户并集成 Facebook 登录
- 更优秀的移动端通知应用
有了这三项功能，再加上一个易于设置的免费增值云服务（已存在！），就能提供一个极佳的 Facebook 群组替代方案。
目前 Facebook Groups API 对于迁移来说相当有限。这时，浏览器插件就能派上用场。具体来说，你需要的不是对旧内容的全面迁移，而是迁移群组的元数据以及用户邀请。旧的对话内容可以保留在 Facebook 中。
将 Discourse 注入到 Facebook 中？在我看来并不可取。将用户迁移到一个更好但又不那么陌生的新环境中，才是更好的选择。
3 个赞
我们尝试过，但失败了。
7 个赞
Facebook 显然让人们很难从其平台迁移到其他任何平台。在你看来，最大且最困难的障碍是什么？
3 个赞
我同意将用户迁移过来是理想方案，然而，即便我们实现了上述 Discourse 中提到的所有解决方案：简化的设计、跨 Discourse 实例的统一通知等……它仍然是一个需要用户单独登录查看通知的独立应用或网站。Discourse 无法取代 Facebook，它仅适合作为 Facebook 中“群组”这一小部分功能的替代方案。因此，人们仍会留在 Facebook 上，许多人也不愿去应付另一个独立的平台，即使登录已与 Facebook 集成，即使界面看起来熟悉且简洁，等等。这终究只是“又多了一件事”。你明白我的意思吗？正因如此，我才在研究 Facebook 信息流注入的概念。
3 个赞
我明白你的意思。但是，Facebook 很可能会关闭你并封禁你用来执行此操作的账户。你需要以某种方式注入他们的系统吗？必须遵守服务条款。
2 个赞
Facebook 永远不会知道，这一切会在用户的本地机器上发生。目前已有多个 Chrome 插件可以操控 Facebook 动态消息，且它们都未被关停。
4 个赞
您是指类似于 Mozilla Firefox 的 Facebook 容器吗？
1 个赞