#article #read
Building Bluesky: a Distributed Social Network (Real-World Engineering Challenges)
[...] Today, the Personal Data Servers are bare-metal servers hosted by cloud infrastructure vendor, Vultr. Bluesky currently operates 20 and shards them so that each PDS supports about 300,000 users. [...]
[...] **Owning your own infrastructure instead of using the cloud seems a rational choice.** Bluesky found large savings by moving off AWS once they could forecast the type of load they needed. Jake Gold, the engineer driving this transition, has been vocal about how cloud providers have become more expensive than many people realize. Speaking on the podcast, Last Week in AWS, he said:
> “With the original vision of AWS I first started using in 2006, or whenever launched, they said they would lower your bill every so often, as Moore’s law makes their bill lower. And that kind of happened a little bit here and there, but it hasn’t happened to the same degree as I think we all hoped it would.” [...]
https://newsletter.pragmaticengineer.com/p/bluesky
#Bluesky #AWS
via Nostr@cxplay_clip
Building Bluesky: a Distributed Social Network (Real-World Engineering Challenges)
[...] Today, the Personal Data Servers are bare-metal servers hosted by cloud infrastructure vendor, Vultr. Bluesky currently operates 20 and shards them so that each PDS supports about 300,000 users. [...]
[...] **Owning your own infrastructure instead of using the cloud seems a rational choice.** Bluesky found large savings by moving off AWS once they could forecast the type of load they needed. Jake Gold, the engineer driving this transition, has been vocal about how cloud providers have become more expensive than many people realize. Speaking on the podcast, Last Week in AWS, he said:
> “With the original vision of AWS I first started using in 2006, or whenever launched, they said they would lower your bill every so often, as Moore’s law makes their bill lower. And that kind of happened a little bit here and there, but it hasn’t happened to the same degree as I think we all hoped it would.” [...]
https://newsletter.pragmaticengineer.com/p/bluesky
#Bluesky #AWS
via Nostr@cxplay_clip
Pragmaticengineer
Building Bluesky: a Distributed Social Network (Real-World Engineering Challenges)
Bluesky is built by around 10 engineers, and has amassed 5 million users since publicly launching in February this year. A deep dive into novel design decisions, moving off AWS, and more.
#article #read
## Bluesky v1.90 对于审核(moderation)功能的改进 (2024.08.29)
1. 贴文的引用(quote)转发次数被独立显示, 总的转发次数仍然计入引用转发次数.
2. 允许贴文发布者将贴文从已经被其他用户引用的贴文中「分离(detach)」出来, 分离之后将无法从对应引用转发贴文中查看被引用到的自己的贴文, 会为后续访客显示 "已被作者删除", 但已被分离的引用转发不会减少转发计数.
3. 允许贴文发布时和发布后关闭引用贴文的转发功能.
4. 允许贴文发布者隐藏贴文线程下的回复, 被隐藏的回复以及该回复之后的子节点会被折叠到线程中的 "被隐藏的回复" 中. 隐藏操作可以对自己或对所有人(仅贴文发布者)生效.
5. 关注时间线只会显示至少两个或以上已经关注的用户之间的对话, 对话将会始终显示的回复者和贴文发布者的对话上下文(中间节点将被折叠). 因此, 对关注时间线的设置中中不再有 "仅已关注用户" 和 "按点赞数" 过滤选项.
6. 可以设置定时失效和仅用于未关注用户的屏蔽关键词.
7. 通知过滤器中可设置仅接收来自已关注用户的通知.
8. 屏蔽用户将会同时屏蔽用户创建的列表(入门包和(用户)列表).
- https://bsky.social/about/blog/08-28-2024-anti-toxicity-features
- https://bsky.app/profile/bsky.app/post/3l2s5luwyg22t
- https://gigazine.net/news/20240829-bluesky-anti-toxicity-features/
#Moderation #Censorship #Bluesky
via Nostr@cxplay_clip
## Bluesky v1.90 对于审核(moderation)功能的改进 (2024.08.29)
1. 贴文的引用(quote)转发次数被独立显示, 总的转发次数仍然计入引用转发次数.
2. 允许贴文发布者将贴文从已经被其他用户引用的贴文中「分离(detach)」出来, 分离之后将无法从对应引用转发贴文中查看被引用到的自己的贴文, 会为后续访客显示 "已被作者删除", 但已被分离的引用转发不会减少转发计数.
3. 允许贴文发布时和发布后关闭引用贴文的转发功能.
4. 允许贴文发布者隐藏贴文线程下的回复, 被隐藏的回复以及该回复之后的子节点会被折叠到线程中的 "被隐藏的回复" 中. 隐藏操作可以对自己或对所有人(仅贴文发布者)生效.
5. 关注时间线只会显示至少两个或以上已经关注的用户之间的对话, 对话将会始终显示的回复者和贴文发布者的对话上下文(中间节点将被折叠). 因此, 对关注时间线的设置中中不再有 "仅已关注用户" 和 "按点赞数" 过滤选项.
6. 可以设置定时失效和仅用于未关注用户的屏蔽关键词.
7. 通知过滤器中可设置仅接收来自已关注用户的通知.
8. 屏蔽用户将会同时屏蔽用户创建的列表(入门包和(用户)列表).
- https://bsky.social/about/blog/08-28-2024-anti-toxicity-features
- https://bsky.app/profile/bsky.app/post/3l2s5luwyg22t
- https://gigazine.net/news/20240829-bluesky-anti-toxicity-features/
#Moderation #Censorship #Bluesky
via Nostr@cxplay_clip
Bluesky
New Anti-Toxicity Features on Bluesky - Bluesky
Trust and Safety (T&S) affects everything — from community policy and spam detection, all the way to the order that replies show up on a post. At Bluesky, the product team works hand-in-hand with T&S to design features that balance safety, ease of use, and…
#吐槽
刚刚在 #Bluesky 看到有人一口气关注了两万多个人, 叹为观止. 这种超大规模的订阅追随对目前的 #Nostr 来说几乎是不可能的, 因为每多一个追随就要多一个 filter 里面的标签, 刷新一次时间线就要有两万多个标签的 filter 发送到已经连接的中继器里面, 就算客户端做好了分割 filter 的功能, 两万个标签的 filter 请求也是随便就能让客户端和服务端超载的大小, 要么拒绝要么查询失败.
via Nostr@cxplay
刚刚在 #Bluesky 看到有人一口气关注了两万多个人, 叹为观止. 这种超大规模的订阅追随对目前的 #Nostr 来说几乎是不可能的, 因为每多一个追随就要多一个 filter 里面的标签, 刷新一次时间线就要有两万多个标签的 filter 发送到已经连接的中继器里面, 就算客户端做好了分割 filter 的功能, 两万个标签的 filter 请求也是随便就能让客户端和服务端超载的大小, 要么拒绝要么查询失败.
via Nostr@cxplay
#吐槽
Mostr.pub 和 Momostr.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
Mostr.pub 和 Momostr.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
#吐槽
快一年下来, 用完了一部分新社交媒体, 写了一个简明的指南. 基本用户体验以 #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 无法做到, 因为它是唯一一个以密钥对为用户实体基础的协议, 私钥无法轮换无法吊销(即使已经有舆论进程但始终未实现), 如果暴露了私钥等于已经失去了账号内的一切.
如果依旧觉得选择困难, 那留在原地依旧是种选择. 如果在社交网络中您的角色转变为受众或追随者, 那么可能根本没有选择, 只能去您喜欢的博主在的地方并适应它, 或者说服他们去哪里.
快一年下来, 用完了一部分新社交媒体, 写了一个简明的指南. 基本用户体验以 #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 无法做到, 因为它是唯一一个以密钥对为用户实体基础的协议, 私钥无法轮换无法吊销(即使已经有舆论进程但始终未实现), 如果暴露了私钥等于已经失去了账号内的一切.
如果依旧觉得选择困难, 那留在原地依旧是种选择. 如果在社交网络中您的角色转变为受众或追随者, 那么可能根本没有选择, 只能去您喜欢的博主在的地方并适应它, 或者说服他们去哪里.
#吐槽
一个分布式社交网络的 Bridge 实现 Bridgy Fed 开始展现在 #Fediverse 和 #Bluesky 之间, 联邦宇宙的居民和它爆发了大规模的冲突. 无数实例管理员, 实例用户要求退出 Bridge 链接.
反方: https://github.com/snarfed/bridgy-fed/issues/835
正方: https://github.com/snarfed/bridgy-fed/issues/870
一个分布式社交网络的 Bridge 实现 Bridgy Fed 开始展现在 #Fediverse 和 #Bluesky 之间, 联邦宇宙的居民和它爆发了大规模的冲突. 无数实例管理员, 实例用户要求退出 Bridge 链接.
反方: https://github.com/snarfed/bridgy-fed/issues/835
正方: https://github.com/snarfed/bridgy-fed/issues/870
#吐槽
In reply to nevent1q…zswj
_________________________
And is it possible set up #Bluesky bridge on #Fediverse or #ActivityPub?
In reply to nevent1q…zswj
_________________________
And is it possible set up #Bluesky bridge on #Fediverse or #ActivityPub?
