[付费] 将 Discourse 论坛转变为 Messenger 应用

你好,

我希望我的用户拥有:(1) 一个论坛;(2) 一个私人即时通讯工具。

关于私人即时通讯,我们是否可以充分利用 Discourse API 的私信功能,以打造出色的用户体验?

最终网站顶部应提供两个选项:论坛和聊天。当用户点击“聊天”时,所有私信应像 web.whatsapp.com 那样展示。这是否可行?如果可行,这将实现论坛与即时通讯工具的最佳结合。

我可以支付 1000 美元或更高费用。请通过私信发送预算方案给我。

为了更清晰地说明:我是一名拥有 5 万多名成员的 Telegram 频道管理员。我计划将所有成员迁移到 Discourse 平台,并制定相应的论坛内容规划。但为了让社区真正活跃起来,我需要为他们提供个人消息功能。

在私信中,主题需要隐藏(可以自动从消息内容中提取)。私信的显示方式应遵循前几个固定字符,就像 WhatsApp 显示消息开头部分那样。私信列表的展示效果需要做得非常酷炫,类似于 WhatsApp 或 Telegram 中聊天列表的呈现方式。

供参考,Discourse 可通过 Discourse Chat Integration 与 Telegram 集成:speech_balloon:

1 个赞

既然用户仍然需要使用 Telegram,迁移他们的目的是什么呢?:blush:

我的社区非常垂直。我希望为他们提供带有自定义表情、自定义贴纸、GIF 动图等的消息服务。Discourse 是开源的,为实现此类定制提供了机会。

我不希望用户被通用聊天功能分散注意力。我的社区是一个专注于特定生活方式的垂直社区,让用户专注于社区本身会更好。

所以,您不希望首页显示内容,只显示分类链接和个人消息?

您不喜欢个人消息的展示方式吗?

您有明确的截止日期吗?

您好,我已附上桌面端和移动端的截图。感谢您的耐心。我是一名非技术背景的业务人员,以下是我偏好 Discourse 的私信系统而非 Telegram 等即时通讯工具的原因:

  1. 适合拥有自定义表情、自定义贴纸和自定义 GIF 的垂直社区。
  2. 即时通讯应用容易浪费时间,因为人们倾向于发送简短且无关紧要的消息;而在私信系统中,用户会更认真地撰写内容。我个人认为 WhatsApp 和 Snapchat 是巨大的干扰和时间浪费。
  3. 我网站的默认视图将是论坛,并提供聊天选项。因此,我希望推广基于论坛的文明讨论,同时根据需要允许聊天功能。
    截止时间:
    我会慢慢推进,此事并不紧急。我将使用个人储蓄,整个项目预算约为 1000 至 2000 美元。我计划通过将 Telegram 用户迁移过来来构建这个社区,这主要源于个人热情,而非商业目的。

我会花几周时间收集反馈,或者直到满意为止,然后开始着手这项工作。对我来说,了解他人是否认为我正在采取正确的社区建设方法非常重要。

好的,这可以理解。

感谢大家在本帖或通过私信的回复。我与几位朋友交流过,大家对此类社区的需求似乎非常巨大。我们正计划集资开发一款可扩展性强、质量上乘的应用。

我乐意使用其他支持自定义表情符号和 GIF 的聊天应用。论坛方面我们可以使用 Discourse,聊天方面则可以使用任何支持与 Discourse 单点登录(SSO)集成且支持社区自定义的消息应用。该聊天应用应仅允许我的社区用户之间进行通信。

欢迎大家就开发一款集论坛与聊天功能于一体的社区应用提出建议。

你看过 Babble 插件吗?

顺便提一下,这已经变成了一个支持主题。

1 个赞

是的,我之前看过 Babble 插件。但我在寻找一个更便捷的方案,就像 web.whatsapp.com 那样。

既然有人有预算进行定制开发,为什么还要说这是支持线程呢?

从零开始独立开发类似 Babble 的系统,如果直接委托定制,由于界面高度自定义的复杂性,成本将高达数千美元。如果还需要作为独立系统运行并配备用户账户管理功能,费用会更高。如果您有这笔预算,那当然很好,但这确实是一个庞大的项目。

Babble 相当方便:它直接嵌入在 Discourse 应用内部,无需单独管理一套用户账户,因为已实现完全集成。千万不要低估单独管理账户会带来多大的麻烦。

您也可以考虑 Mattermost 或其他常见的聊天服务。Mattermost 是个不错的选择,因为它开源且易于自行部署,还能在手机上作为独立应用出现在主屏幕上。

您可以查看类似 Auth0 的服务,以维护单一的用户账户源,避免在两个地方分别管理。Pavilion 可以在这方面为您提供帮助。

另一个不错的选择是 Discord。已有现成的插件支持 Discord 登录并同步用户角色,这些功能还可以进行定制。

这是一个支持性话题,因为目前很多讨论都在谈论现有的替代方案,而非明确的需求规格。不必担心,如果版主认为有必要,他们可以移动该话题。

5 个赞

在我看来,这更像是一场公开的范围讨论。因此,如果 @saura901 决定采用现有集成而非尝试构建定制方案(我同意定制方案的成本会极高),我们将转向其他地方。

5 个赞

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.