©CC BY-NC-SA 4.0

频道: cx.ms/channel
笔记: cx.ms/memo
博客: cx.ms/blog
剪贴: cx.ms/clip
社交: cx.ms/sns
#吐槽

Mostr.pubMomostr.pink Bridge 继续被滥用:

Fediverse 和 Bluesky 之间的桥被用来向 Bluesky 发送支持特朗普的垃圾邮件, 这些垃圾邮件来自 Nostr. 垃圾邮件是在 Nostr 上创建的, 而 Nostr 通过 Mostr 桥接器与 fediverse 桥接, 后者又可以与 Bluesky 桥接. 虽然所有网络都有许多方便, 开放注册的地方, 但垃圾邮件往往发生在容易大量注册的地方, 而 Nostr 的协议设计使得创建新账户特别容易.
—— https://fediversereport.com/last-week-in-fediverse-ep-69/ (The Fediverse Report)

支持特朗普的垃圾帖子是如何从 Nostr 转移到 Bluesky 的? 首先, Nostr 内容通过 Mostr Bridge 传播到 Mastodon (基于 ActivityPub 协议). 然后, 使用名为 Bridgy Fed 的工具将内容从 Mastodon 推送到 Bluesky. 这一过程的痕迹出现在 Bluesky 版本的帖子中, 其中的账户柄格式为 npub************.momostr.pink.ap.brid.gy. 其中的第一部分(从 npub 到第一个点)是 Nostr 账户的公钥, 而其余部分(momostr.pink.ap.brid.gy)则包含了用于桥接帖子的工具(Mostr 和 Bridgy Fed)的一些说明.
—— https://conspirator0.substack.com/p/federation-and-political-spam (Conspirador Norteño)

#Nostr #Fediverse #Bluesky

via Nostr@cxplay
#吐槽

用完大部分 #Nostr 密钥管理方案了... 浏览器扩展(NIP-07), 远程签名器(NIP-46) Amber 和 Bunker, 以及私钥加密(NIP-49). 唯独最早提出的委托秘钥签署(NIP-26)到现在都没有成熟的实现, 看起来真的要被弃用了. 目前仍然还没有解决的依旧是密钥轮换.
体验最好的当然是原生的签名器(浏览器扩展其实也是种签名器), 然后才是通用的远程 Bunker. 私钥加密本身并不解决签名, 只是提供了对私钥的一层对称加密保护, 应该要和浏览器扩展和远程签名器一起使用.

via Nostr@cxplay Short Text Note by CXPLAY
#吐槽

快一年下来, 用完了一部分新社交媒体, 写了一个简明的指南. 基本用户体验以 #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 无法做到, 因为它是唯一一个以密钥对为用户实体基础的协议, 私钥无法轮换无法吊销(即使已经有舆论进程但始终未实现), 如果暴露了私钥等于已经失去了账号内的一切.

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