王小美 @mashiro@hello.2heng.xin

#SteamTopSellers for week ending 5 February 2023:

#1 - Hogwarts Legacy
#2 - Steam Deck
#3 - Dead Space
#4 - Hogwarts Legacy
#5 - Undisputed
#6 - Hi-Fi RUSH
#7 - Project Zomboid
#8 - Dead Space
#9 - Red Dead Redemption 2
#10 - Call of Duty®: Modern Warfare® II

https://steamdb.info/topsellers/2023W05/

谷歌创始人亲自下场改代码，ChatGPT 让谷歌真慌了
https://www.ithome.com/0/671/563.htm

简单讨论一下将 #IPFS 用于长毛象媒体存储的可行性

如果在用户端用ipfs，要么自带网关，要么走第三方公共网关。前者在站点服务器无法访问时可能用得上，但资源占用、读取速度等还不够理想。后者就称不上是去中心化了。即使实例建网关转成http，那相比现在也没提供什么增益。（如果有其他思路也可讨论）

服务端用ipfs，一种思路是把它当成s3用、直接托管在第三方，另一种则是在已有存储的基础上加入ipfs。前者如果完全依托IPFS交互，延时恐怕控制不住（固定提供商的peers？）。后者是我认为有一定可行性的思路。

现有的机制下，只要媒体文件的路径改了，长毛象就无法自动定位到已清理的外站媒体。如果各服务器的媒体文件都加入了ipfs、缓存外站30d以上或者永久缓存有互动的媒体文件，那么只要该文件的hash记录还在，就能从原站或者有缓存的其他站点找到。即使站点自身的媒体文件彻底灭失，用户找回媒体的可能性和便利性都会大大增加。如果数据库还在的话，重建站点大部分的媒体文件也不是不可能。而且对于寻找旧媒体文件的任务，有一定延时也可以接受。

长毛象对象存储的特点是大量小文件，自建ipfs能否有效应对是个问题。我简单测试了下，参考 https://docs.ipfs.tech/install/run-ipfs-inside-docker/ 建了个docker。通过docker stats查看，平时CPU有一定占用，长时间运行内存会到500MB。加入约10GB（80k）的文件，内存最高到1.6GB。重启并运行一段时间后稳定在600MB左右。已加入的文件通过公共网关访问，未能直接成功。第一次尝试后过一段时间再访问有时能打开，更换默认的4001端口似乎有一定帮助。除了自建，也有 https://web3.storage 这类将文件交给服务商，让服务商加入IPFS的服务。但价格相比已有的s3服务商看起来没有优势。

网关例：https://cloudflare-ipfs.com/ipfs/QmP16cnDGh1NC6DruajXoWvTwFJhgDCDjMsoStYY7e2iBN

顺便一提，对于 Filecoin 这类激励层的设想，我曾抱有人人为我、我为人人模式的期待（去中心化PT）。但目前来看，其挖矿的硬件门槛远超民用级NAS https://lotus.filecoin.io/storage-providers/get-started/hardware-requirements/ ，应该会产生明显的中心化趋势。因此，个人对其前景还有一定疑问。

总的来看，ipfs有望为媒体文件的存储提供一些增益，但暂时还不足以抵消实现中的各种麻烦。期待未来能看到更好方案。