先看了你的贴，后看了作者的贴，简单分享下自己的看法。

我们都知道 IPFS ，他的架构和 bt 类似，也具有传统 BT 的问题：
1. 对于版权的侵犯（很多人认为这是个 feature ）
2. 吸血问题
3. 适合长内容点播，不适合短视频和直播

对于问题 2 ，最大的问题是，没有“全局账本”。
PT （传统）虽然进行了改良，但问题是，只有 peer-peer 之间的账本，全局服务器对每个 peer 的工作量来自于各个 peer 自己上报，实际上是可以 spam 的。
两个帖子里讨论的积分，实际上都要换算成“存储*时间”证明和“流量”证明，前者不存在（不讨论 filecoin 等项目），后者可以认为存在。

如果想做一个严肃的项目，解决了问题 2 之后，就需要考虑问题 3 和问题 1 ，你需要一个切入点。我个人不看好泛 NAS 的场景。

技术细节的话，基于 libtorrent 和 webtorrent 改改就好了，再做个分布式的 track ，我都写过，没啥难的。

https://docs.olares.xyz/zh/manual/concepts/network.html

需要鉴权的服务走 tailscale 类 vpn 服务
不需要鉴权，对外公开访问的服务放到 CND 和反向代理后（ Cloudflare Tunnel 最简单）

@dilu 能展开说说 vSwitch 是啥使用场景吗？

想去哪家公司，找到 github 上的 repo ，提交几个有价值的 pr ，他们会主动联系你的

@SmiteChow

跟 w3c did 相关的标准，简单来看有这些：

https://www.w3.org/TR/did-core/
https://www.w3.org/TR/vc-data-model/
https://identity.foundation/presentation-exchange/
https://identity.foundation/wallet-rendering/
https://identity.foundation/credential-manifest/
https://w3c.github.io/vc-data-integrity/
https://w3c-ccg.github.io/ld-cryptosuite-registry/
https://w3c-ccg.github.io/lds-jws2020/

这些协议基本上我都对照着 https://github.com/TBD54566975/ssi-service 看过代码实现，也为这个项目提交过微不足道的 pr 。
我觉得如果我们以上述标准为前提，会有利于达成共识。


具体到 Bluesky 和它的 did 实现，可以参考这篇文章： https://arxiv.org/pdf/2402.03239

1. bluesky 的 registry 是中心化的：plc.directory

2. bluesky 为了用户的易用性在官方的版本里为用户托管了私钥，所以大家可以使用邮箱登录（并进行密码找回）
3.5.3 Authentication. In principle, the cryptographic keys for signing repository updates and DID document updates can be held directly on the user’s devices, e.g. using a cryptocurrency wallet, in order to minimize trust in servers. However, we believe that such manual key management is not appropriate for most users, since there is a significant risk of the keys being compromised or lost.

The Bluesky PDSes therefore hold these signing keys custodially on behalf of users, and users log in to their home PDS via username and password. This provides a familiar user experience to users, and enables standard features such as password reset by email. The AT Protocol does not make any assumptions about how PDSes authenticate their users; other PDS operators are free to use different methods, including user-managed keys.

上述两点，论证了 bluesky 在 did 解决方案方面不是 self generated self owned ，也无法承诺 IDs can be made universally discoverable 。
但作为从业者，我理解 bluesky 这么做取舍的苦衷，所以我本无意跟你讨论去中心化等问题。


我从第一次回复时，想表达的观点就是，bluesky 和 solid 的底层哲学是不一致的

以及最重要的点，如果我没理解错的话，bluesky 团队应该是不希望自己被标榜为 web3.0 的（如果他们官方的 twitter 或者采访有类似的描述，我就不说啥了，一个 web3.0 多种描述也没什么不好）

ps ，多西已经离开 bluesky 了，多西另一个曾经的项目 tbd ，口号是 web5 = web3 + web2

默认职位是研发工程师，我的感受是：

1. 大学里上过什么课程不用写
2. 大学里如果得过相关的奖项可能要写，例如 ACM ，数学建模是相关的，篮球可能是不想关的
3. 学生会和社团活动感觉两可，倾向于不写
4. 相关的证书可以写，例如英语水平，CET4 ，CET6 ，托福雅思是可以写的，驾照不用写

工作经历在描写完职责后，最好简单的列出一两个有两点的项目，项目描述的模版为 star （在什么样的背景，以什么样的目标，你做了啥，取得了哪些可以量化的结果）
个人建议，不要简单的堆砌掌握的技术栈，例如，对前端来说，建立里罗列熟练（精通） VUE3 ，React ，CSS ，乃至 Git 或 vscode 操作就会显得比较。。。。

dht 不是 web3.0 ，就像 ipfs 不是 web3.0 一样。

我只想跟你以及看到这个帖子的大家分享，solid 和 bluesky 在设计哲学上是不一样的，这会造成不同的产品和技术架构设计，但谁更符合时代精神，其实并没有人知道 :)

我大概在 2022 看过 atproto 的文档，之后的关注不是很深入，说的不对地方你可以具体指出我的错误。

去中心化，身份，数据和隐私问题，我不一一展开了，只说身份吧：
1. bluesky 最早选择将 DID 数据放在 ION 网络上（已经从文档里移除了）。我当时的理解会采用 tbd 的 SSI 方案，但时至今日，实际上我不知道 bluesky 是如何处理 DID Registry 的问题
2. bluesky 为了降低用户的使用门槛，在 2023 年的版本是会代替用户保存了私钥的

基本上违背了去中心化身份（ DID ），self-generated and self-owned ，IDs can be made universally discoverable 等基本原则。

所以正是基于对于 bluesky 这个项目的认可，我基本不跟人讨论 bluesky 的“去中心化，身份，数据和隐私问题”：）

bluesky 在架构上是联邦网络（用户不用运行自己的服务器）

solid 我理解还是希望做成 p2p 网络的，每个人有自己的服务器

更细节一些就是：
1. bluesky ，把 blog 发布到 pds 上
2. Blockchain 从业者，把 blog 发到区块链上-_-b

而我觉得，真正的 web3.0 是把 blog 发到自己服务器上。否则如何解决 pds 的费用问题呢? 总不能是没有收入的 public goods

@jiashuaibei 是我们做的，多谢鼓励~

2080TI 22G

带你畅游 gemma2 27b

感谢分享

不过这玩意可以 github 后台配 webhook 的

https://github.com/vrtmrz/obsidian-livesync

或者

seafile

@MFWT 厉害，我收藏下这个需求。

我自己是很轻的用户

https://www.navidrome.org/

这是运行在群晖/nas 上的，可以理解为服务器+网页端。可以找第三方的客户端

follow + rsshub ？

@showgood163

其实这是规范的做法，代价是只能叫自己 source avaiable 而不是 open source 。大的项目里 n8n 是这么做的。

https://faircode.io/
https://www.tisonkun.org/2023/08/12/bsl/
https://www.tisonkun.org/2023/11/01/trans-elv2-meeker/


apache 2.0+禁用商业的扩展或者 agpl v3 都是有点问题的，理解尊重，只是我们不选这么选~

我也调研过这个需求，记录下。


我们希望在边缘节点上搭建一个搜索引擎，需要占用的内存开销比较小，同时当数据比较大的时候，可以有效使用硬盘。


我们一开始选择了 zincsearch ，选择它的原因是对 es 接口的兼容，不过这个团队弃坑了，以及它的权限做的比较糙
https://github.com/zincsearch/zincsearch

Github star 比较多的是：
https://github.com/meilisearch/meilisearch
https://github.com/valeriansaliou/sonic
https://github.com/typesense/typesense

我觉得： https://github.com/manticoresoftware/manticoresearch 可能是遗珠
支持少量付费的话，Algolia 也是一个选择

其实： https://www.meilisearch.com/docs/learn/what_is_meilisearch/comparison_to_alternatives
这篇文档做了对比，可以看看。


最后：
1. 我们文档站用了：Algolia
2. 主项目用了 pg 加一堆插件的方案，整体资源的占用最小。因为我们用了 citus ，未来做云原生支持的时候希望也能容易些

op 1 万多条的规模感觉 meilisearch ，typesense 挑一个就好了

手机客户端上直接开上传？感觉这么干太猛了，不应该吧。。。。