很棒的服务，没有付费计划么。

@BYDH 这应该就是一个很典型的端端加密文件分享场景，可以用 service worker 。https://new.space 就是这么用的。

@yann123 不是点对点，可以传到支持 S3 协议的对象存储。只是如果使用 S4 ，多一些独有功能，更安全，效率也更高。
@esxlin 不是很了解 P2P 共享存储这个东西，短期应该不会。
@starxg 这是一个 DEMO

@uIPC 欢迎体验，控制台有群二维码

@uIPC 没有实现，但实现一下也很容易。
@gongquanlin 后端就一个 S3 的预签名接口，可以看 Readme 指向的另外一个仓库。然后没有其他的后端依赖了。

@kkk9 是哦，都开源了还不恭恭敬敬把东西喂你嘴里，现在玩开源的人真是太把自己当回事了。

另外，什么是内容农场啊？哪里都 Copy 一遍全文才叫内容农场好吗？

yc news 、techmeme 全是外链，也是内容农场？

然后打开方式 也可以是类似于 github.dev 的方式来做 (github.dev 套的是 vscode)，例如： https://github.write.dimstack.com/user/repo

@Peiiii 很有意思，期待继续完善，视觉和交互细节更好一点，也包括大量目录和文件的时候

另外，有计划支持 github 和别的存储吗，例如 s3 ？

@Peiiii 可以提交回去吗？

@jy02534655 有没有可能把返回结果数设置为 20 条或 50 条的时候就有了呢？

还是支持一下 op ，反对这种技术行业的“官僚”主义。

@moving80kg
另外 casdoor 项目用起来小问题，这也很大程度打击我们的使用信心。这个跟需求是无关的。
原本我以为是我们的错觉，但看到 https://www.v2ex.com/t/1021725 发现同样有人提到（缺乏测试）。

再提一次之前说过的声明，如果他们出了 SAAS 服务，我觉得可以一用，因为有服务，小问题只要甩给他们就可以解决。自部署开源版本，建议慎用。

@moving80kg
1. 我没用 logto
2. 所以 8 楼和 9 楼分享了自己的判断，帮助其他人更明确需求
3. 并且受 10 楼邀请在 17 楼做了一些说明和补充
4. 然后因 18 楼的误解在 20 楼又做了说明和补充
5. 最后因 24 楼的莫名奇妙在 25 楼做了一次梳理

请问有什么问题吗？

@pseudo 我没说 Logto 和 Casdoor 简单，反而是说：我们的需求很简单，他们太复杂（然后又容易引入一些小问题）所以才决定自己写。

所以这些只和 casdoor 有关吗？ logto 是不是已经做得非常健壮、安全、完整了？是否可以支持上有自定义需求的一键登录行为了，我不知道，你知道吗？

现在 rust 都这么普及了，我们自己早就用自研的东西把 Nginx 系、dnsmasq 系这种简单的组件替代掉了，再替换掉 Redis 这种简单的工具替代掉有什么奇怪的吗？

其他的，你就别跟我扯什么耶稣上帝了，跟我没关系，跟你也没关系（你这杠真的有必要抬到把 Redis 一个简单的工具跟整个前端、机器学习这种大生态的行业强行做对比吗？）。

@cydian 本身希望非常简单地接入使用，结果还是遇到很多磕磕绊绊。实际使用之后发现整体比较复杂，比较难在短时间搞熟。另外也不排除有一些小问题小 bug ，我们自己还修改了代码，这个时候已经有了一些不满（原本就是为了自己可以不亲自处理这方面的东西），但由于使用场景目前也非常简单，自己修了 2 个 bug 后倒也相安无事，就继续用。

后在使用其他服务需要用到一键登录的需求时，发现又不能直接使用（结果还得自己写了个中转接口）。最后痛定思痛，觉得因为想解决一个小问题引入了一套复杂的东西实在得不偿失，而且连最初的目的都达不到（成为账户中心，方便接入）。
@xiaohanyu 我们也是在自己修了几个小 bug 之后其实也是真切体会到，这套东西实际真的很简单，但之前被一个个的名词和一套套的协议给吓到了。本质就是一个特别简单的东西，不值得引入复杂的不确定性因素。当然使用云服务，有专业支持的话，问题可能不大。现在自己写了，接入什么都很容易实现，灵活度和可靠性大大提高。

@wuyuandev 用了 casdoor 之后也坚定了自己写的决心。

这些年用了很多，真的就是 Framer 最好用了。
如果想导出代码只是为了（自部署）加速，可以用我们的 Framer 加速服务。
如果导出代码是强需求，可能就是 webflow 。

欢迎用我们的服务来优化 Framer 在大陆地区的速度： https://framer.bitiful.com/