Why Nostr? What is Njump?
2024-02-18 08:14:57

CXPLAY on Nostr: 快一年下来, 用完了一部分新社交媒体, 写了一个简明的指南. ...

快一年下来, 用完了一部分新社交媒体, 写了一个简明的指南. 基本用户体验以 #Twitter 为基准. 参加比较的有 #Threads, #Fediverse, #Bluesky, #Nostr.

如果你不在意开不开放与自不自由, 只是想找个 Twitter 的替代, 那么选择 Meta 的 Threads.

如果你在意开放与自由, 也还想找个 Twitter 的替代:
- 如果你为了社交而愿意去维护服务器和持有域名(时间和金钱都是持续消耗, 即使是代托管), 那就选 #Mastodon, 嫌前者太重了那就 #Pleroma.
- 如果你不打算维护服务器和持有域名, 但是还想进入 Fediverse. 那么最难的地方在于选择和信任一个实例, 这点和不托管自己的电子邮件服务是一样的. 可以基于「瘦死的骆驼比马大」原则, 你还需要综合考虑的因素包括实例域名管理局, 实例幕后运作的情况, 实例用户协议和隐私协议.
- 如果你不打算维护服务器和持有域名, 也并不局限于 Fediverse. 那么就选 Bluesky. 在未来它会变成一个强化版本的 Fediverse, 但现在它还没准备好, 因此现阶段加入只能选择官方实例(有效排除选择困难).

Fediverse 基于一个美好的但未经协议制定者实践的协议 ActivityPub, 它目前事实上的「标准」是 Mastodon 兼容性协议, 如果有任何 Fediverse 软件不选择兼容它, 那就会失去和 Fediverse 用户量总和最大的实例软件的链接, 失去互操作性. 并且 Mastodon 背后是一个非盈利组织在运作一切, 受到的资金支持和社会舆论支持更加充足. 基于这些问题, 大多数的商业或非盈利组织实例优先选择的都是 Mastodon, 或者基于它之上进行改进.

Bluesky 受到 Twitter 前 CEO 的资金支持和他的社交媒体软件设计哲学的指导, Bluesky 使用新的协议 AT Protocol, 缓解了 ActivityPub 的一些问题(用户身份标识, 内容审查权利, 实例互操作性等). 协议和官方协议实现的幕后开发方向明确或者说权力很集中(俗称「大教堂式」开发).

如果你在意开放与自由, 也并不在意是否有 Twitter 同等的体验, 不想维护服务器, 不想持有甚至也不想依赖任何域名:
那就只能选 Nostr 了. 它同样受到 Twitter 前 CEO 的资金支持和他的社交媒体软件设计哲学的指导, 但是它并不是一个专用于社交媒体设计的协议, 它是个通用消息传输协议. 你需要有基本的计算机技术基础知识才有可能适应现阶段的客户端体验. 它的幕后开发非常自由(俗称「社区舆论式」开发), 协议标准的确立并不会影响软件具体实现. 除了用户体验外, 另外一个问题是 Nostr 内外有大量的 Web3 内容和拥护者团体.

最后提供给团队运营单一社交媒体账号的提示:
Threads, Fediverse, Bluesky 都可以适应多人运营单一账号. 但是 Nostr 无法做到, 因为它是唯一一个以密钥对为用户实体基础的协议, 私钥无法轮换无法吊销(即使已经有舆论进程但始终未实现), 如果暴露了私钥等于已经失去了账号内的一切.

如果依旧觉得选择困难, 那留在原地依旧是种选择. 如果在社交网络中您的角色转变为受众或追随者, 那么可能根本没有选择, 只能去您喜欢的博主在的地方并适应它, 或者说服他们去哪里.
Author Public Key
npub1gd8e0xfkylc7v8c5a6hkpj4gelwwcy99jt90lqjseqjj2t253s2s6ch58h