You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
paopao-ce/docs/proposal/003-关于Followship功能项的设计.md

3.7 KiB

编号 作者 发表时间 变更时间 版本 状态
003 北野 2022-11-04 2022-11-21 v0.1 提议

关于Followship功能项的设计

Followship是实现类似Twitter Timeline模式关注者模型的时间线信息流广场推文列表的生成将主要与推文时间、用户的关注者相关。Twitter的推文消息流是非常智能的用户体验也非常好这得益于其背后的智能推荐算法以及完善的关注者模型体系当然还有很多其他机制共同作用下的结果。本提按作为一个总纲为paopao-ce引入类似的机制这将是一个持续完善的缓慢过程一切都是为了用户体验用户就是上帝用户需要什么paopao-ce就努力提供什么

场景

  • 站点用户基数达到一定规模,推文总量很多、推文更新很快,需要一种机制更智能的生成广场推文列表改善用户体验;
  • 单纯的想为站点引入关注者模型体系;

需求

基本需求

  • 实现类似于Twitter的追随者关注模式的推文传播模型,使得广场页面可以浏览已关注用户的推文;
  • 提供 关注/取消关注 用户的机制;
  • 浏览 用户关注者 列表的机制;
  • 浏览 用户追随者 列表的机制;
  • 用户主页显示 关注者/追随者 计数,并作为入口进入对应浏览 关注者/追随者 列表的页面;
  • 广场推文页面 依据 关注者模型体系生成个性化推文列表;

可选需求

  • 建立 发现机制(Discover) 为用户 智能推荐 用户可能会感兴趣、值得关注的用户;
  • 同上,广场推文页面可以附带一些被推荐的推文,这些推文不属于关注用户的推文,但是与关注用户相关,比如是用户关注者的关注者、热度用户等;

方案

方案一 (仅使用后端关系数据库MySQL/Sqite3/PostgreSQL满足基本需求)

  • 提供 关注/取消关注 用户的机制 - 前端/后端
  • 浏览 用户关注者 列表的机制 - 前端/后端
  • 浏览 用户追随者 列表的机制 - 前端/后端
  • 用户主页显示 关注者/追随者 计数,并作为入口进入对应浏览 关注者/追随者 列表的页面 - 前端/后端
  • 广场推文页面 依据 关注者模型体系生成个性化推文列表 - 后端
  • 发送推文时,默认可见性为 公开, 公开的语义将是关注者可见, 因此用户如果没有登入或者没有关注任何用户,广场推文列表将只有自己的私密推文或者是空的 - 前端/后端

方案二

在方案一的基础上通过引入 图数据库 实现可选需求。待研究、设计~

疑问

  1. Friendship与Followship这两功能项是否可以共存还是互斥呢
    理论上这两个功能项是可以共存的如果设置成共存就需要同时提供这两个机制的UI交互同时广场推文列表的生成机制也需要做相应适配可能会比较复杂。前期开发将把这两个功能设置为互斥的用户关系模型只能设置为其中之一,待两个功能项都趋于稳定后,再测试这两个功能项共存后的用户体验,如果效果还不错就引入共存机制。

  2. 如何开启这个功能?
    在配置文件config.yaml中的Features中添加Followship功能项开启该功能:

    ...
    # features中加上 Followship
    Features:
    Default: ["Meili", "LoggerMeili", "Base", "Sqlite3", "BigCacheIndex", "MinIO", "Followship"]
    Base: ["Redis", "PhoneBind"]
    ...
    

更新记录

v0.0(2022-11-04) - 北野

  • 初始文档, 先占个位置;

v0.1(2022-11-21) - 北野

  • 添加初始内容;