@Ericality 直接用 icloud 同步就好了

@nojsja

暂时不行，目前只支持把批注导出到 markdown 。

如果要保存 markdown ，可以试试看 简悦、web clipper 等插件。

@kidexp

已经支持啦。 而且支持导出高亮、笔记到 obsidian 、logseq 、siyuan

@konakona

埋点是故意不做的。 我有一份本职工作， 所以这个产品设计原则为 “不需要维护”。

我特地去掉了所有服务器的依赖，不做 自动更新、不做埋点。

@duckgo991 我有本职工作的，都是下班后开发的。 算是半个独立开发者。

@James369

第一个 commit 是 2021 年 1 月， 从 2022 年 1 月开始正式开发功能。

独立开发者非常难。。

我的项目, 一年就 5 个付费用户 https://www.v2ex.com/t/910295#reply4

我基于 CRDT 和 sqlite 设计了一个分布式的稍后读工具，所有节点可以达到分布式一致性。

1. 以 CRDT 文件作为 single source of truth , 保证向前向后兼容。
2. 以 sqlite 数据库作为缓存。 可以按照需求任意修改 sqlite 的数据库格式 。
3. 不同客户端直接通过点对点同步 CRDT 文件, 修改后把 CRDT 的数据同步到 sqlite 。

可以看这篇文章 https://www.sqlite.org/testing.html


As of version 3.39.0 (2022-06-25), the SQLite library consists of approximately 151.3 KSLOC of C code. (KSLOC means thousands of "Source Lines Of Code" or, in other words, lines of code excluding blank lines and comments.) By comparison, the project has 608 times as much test code and test scripts - 92038.3 KSLOC.


sqlite 的部分测试是不开源、专有的。

我来分享一下我对稍后度的理解.


1. 存下来是为了防止网页消失，读不读没有那么重要。 存之前已经大致读过，在脑中有印象了。
2. 等 chatgpt 成熟了,可以把网页喂给 chatgpt 让 ai 帮我们读。ai 读完以后可以帮我们找出原文。
3. 其实没必要管理网页，只要支持全文搜索就可以了。
4. 需要二次阅读的时候，如果之前保存了。可以按照会议简单筛选网页，然后再人肉回去找，一般都能找到。


基于上述理解，我开发了自己的稍后读软件。 感兴趣的可以看我之前发的帖子。

太长不看版。 两张图片展示主要特色


https://i.imgur.com/V5Fz30H.png



https://i.imgur.com/YujAerk.png

https://github.com/hamsterbase/hamsterbase

是时候来推荐我开发的稍后读软件了～

无需注册账户，无服务器，试试呗。


先说特色

1. 所有功能完全离线，所有数据都在本地，

2. 支持 docker 部署、 支持桌面端（正在发布，明天估计在官网可以下载）。 提供压缩后的源码。

https://github.com/hamsterbase/hamsterbase/issues/7 在这里可以下载到桌面端。 或者等明晚下载正式版的。

3. 目前 beta 期免费， 未来正式版非订阅模式。 正式版发布后，beta 版仍然可以使用。 我保证不加任何鉴权相关逻辑。

4. 关注隐私，不收集任何信息，无任何埋点。 我现在都不知道我有多少用户。

5. 提供 API 和开源 SDK

6. 支持点对点同步

再说功能

1. 支持保存 mhtml 、html 、webarchive 等常见网页快照格式，完美渲染。
2. 支持暗黑模式
3. 支持全文搜索
4.支持直接在快照上批注
5. 支持按照 网站、是否有批注、添加时间 等调节自定义筛选页面。

计费系统不重要，我的软件就是无付费激活模块，先收钱，记录付费用户邮箱。


推荐几个收钱的方式

1. paddle
2. https://www.buymeacoffee.com/
3. 微信转账

1. 分析 ast ，自动提取出 i18n 的 key 和 message

2. 稍后读软件，为了开发一个完美的模板引擎，自己解析 ast 和写解释器。

3. 写 ast 转换器，把 js 翻译成 rust.

4. 解析器，根据代码注释自动生成 API 文档

你这些都不需要 AI ，前端已经用了很久的 eslint 了。

发布之前各种 门禁，卡点，安全扫描，还有强制代码覆盖率。

举几个例子

1. 禁止循环里调用 await

https://eslint.org/docs/latest/rules/no-await-in-loop

2. 代码圈复杂度限制

https://eslint.org/docs/latest/rules/complexity

如果选择闭源，直接改就行了，完全没问题。

我觉得可以联系原作者，问一下能否新增 PR 加功能。 如果他不愿意，你可以选择 fork 。

注意不要删除原来的 license 。

推荐读一下 《大教堂与集市》，第 3.3 章提到了这个问题。

下面是原文

然而，在经历这些变化之后，人们对什么是“自由软件”或“开放源码”仍有着普遍认可的共识，在很多开源许可证中都能发现对此共识的清晰表达，其最关键要素都是一致的。

1997 年，“Debian 自由软件准则”提炼了这些共同要素，并形成了开放源码定义（ OSD ，参见 http://www.opensource.org ）。

定义指出，开源许可证必须保护任何个人或团体无条件修改开源软件（以及发布修改后软件版本）的权利。
所以，OSD （以及与 OSD 一致的版权声明，如 GPL 、BSD 许可证、Perl 的艺术许可证（ Artistic License ））隐含的规则是“任何人能干任何事”（ anyone can hack anything ），没有任何事情可以阻止人们获取任意开源产品（如自由软件基金会的 gcc 编译器）、复制其源码、推进其向不同方向演进，并都可声称是该产品。

这种演进上的分化称为“分支”(fork)，分支最重要的特点是它派生出一个随后不能交换代码的竞争项目，并导致开发社区潜在的分裂。（有的情况看上去像分支但其实不是，如 Linux 存在的多种发布版本。这种伪分支可能会导致不同的项目，但是它们使用的代码几乎相同，并且可以互相受益于对方开发的所有成果，它们在技术上和社会学上都不是浪费，也不会让人感觉到是“分支”。）

开源许可证没有对“分支”做任何限制，更不用说“伪分支”了。人们可能会说这暗中鼓励了分支，但实际上，“伪分支”比较常见，分支却几乎没有发生过。重大项目极少产生分化，如果有，也总伴随着重新命名以及大量的公开解释，很明显，在诸如 GNU Emacs/XEmacs 分化、gcc/egcs 分化，以及从 BSD 派生出的各种分化中，分化者都觉得他们在违背一个相当强大的社区准则

事实上，和“任何人能干任何事”共识相矛盾的是，开源文化有一套严格的但主要是“不允许”类型的所有权惯例。
这些惯例决定了谁能修改软件、在什么情况下可以修改，以及（特别是）谁有权利向社区发布修改后的版本。
文化中的一些禁忌凸显了这些准则，我们在此总结其中一些重要的内容，以便后面使用。


1. 分化一个项目会遇到强大的社会压力，只有在极为必要的情况下才使用，而且要重新命名和做出大量的公开解释。
2. 在没有项目主持人认可的情况下发布更新是令人不悦的，除非是特殊情况（如本质上不重要的移植 bug 修复）。
3. 在项目历史、致谢表或维护列表中移除某个人的名字是绝对不可以的，除非当事人明确表示同意。

在本文的余下部分，我们将仔细研究这些禁忌和所有权惯例。我们将不仅探究这些概念是如何运转的，还将揭示开源社区背后隐藏的社会动力学及激励结构。

如果看英文书时左脑感到紧张不舒服，可以尝试以下方法来缓解：

1. 使用卡片学习方法，先将英文单词和它们的中文翻译写在卡片上，然后每天拿出卡片进行背诵，这样可以让你的大脑更好地记忆单词。

2. 多听英文，可以每天收听英文广播或者观看英文电影，让你的大脑更多地接触英语，这样可以让你的大脑更好地理解英语句子的结构。

3. 尽量避免长时间阅读英文书，如果你已经感到阅读英文书时左脑紧张不舒服，那么可以尝试睡一觉或者做一些放松的活动，然后再回来阅读英文书。

4. 尝试使用中文笔记或者中文字典，这样可以让你在看英文书时能够更好地理解英文单词的含义。

如果你感到阅读英文书时左脑紧张不舒服的程度很严重，那么建议你就医检




上面的文本都是由人工智能生成的，没有任何人为修改。 我觉得写得挺好的，会粘贴上来。