在过去的几年里，我尝试了 Notion、Linear、ClickUp 等工具，用于个人和工作相关的项目。这些平台上的任务和文档总让我感到困扰，因为它们似乎是割裂的。当你在任务中深入到 4-5 层时，很容易迷失方向。更糟糕的是，除非你有很多自律，否则很容易丢失知识。例如，当你为一个任务添加上下文和细节，而这些内容似乎与其他内容不够相关时，它们就不会被复制到知识库中。然后在 2-3 个月后，当你需要这些知识时，它们却被埋在数百个其他任务之下，完全消失了。
你有什么建议可以避免信息散落一地吗？
返回首页
最新
大多数“开放金融”项目仅停留在账户聚合阶段。但当你尝试构建保险API时，很快就会发现存在许多空白：没有真实的报价工作流程，没有同意流程，也没有符合FAPI标准的认证。因此，我构建了一个阿联酋开放金融保险测试后端。
它模拟了完整的生命周期：
- OAuth2 FAPI风格的认证（JWT）
- 同意的创建和授权
- 涉及7种保险类型的报价生成
- 报价到保单的转换
- Webhook事件和错误处理
示例流程：
创建同意 → 生成报价 → 接受 → 发放保单。
这个后端是Docker化的，拥有Swagger文档，并且旨在模拟真实的第三方支付机构（TPP）如何进行集成。这是一个测试后端，而非生产基础设施。
我很好奇其他人在集成开放银行/保险API时遇到的最大困难是什么。
嗨，HN，
我一直在研究一种区块链设计，它对51%攻击问题采取了不同的处理方式。与传统系统通过硬件或资本使攻击瞬间变得昂贵不同，这种设计使攻击在结构上执行起来缓慢，从而使其在时间上变得成本高昂且难以维持。
核心思想很简单：(1) 每个节点/身份在工作量证明（Proof-of-Work）过程中限制为约1个哈希/秒，无论硬件如何；(2) 消除并行挖矿的优势（没有工作是可以共享的）；(3) 将影响力转向持续的、持久的参与，而不是单纯的哈希算力；(4) 使生成大量Sybil身份变得缓慢、昂贵且困难。
我构建了一个基于浏览器的最小可行产品（MVP），演示了这一限制工作量证明模型（作为参考实现）：[https://grahambell.io/mvp/Proof_of_Witness.html](https://grahambell.io/mvp/Proof_of_Witness.html)
这里还有一个简短的演示（限制工作量证明）：[https://youtu.be/i5gzzqFXXUk?si=y_Pv5ZDv9SGhRFjY](https://youtu.be/i5gzzqFXXUk?si=y_Pv5ZDv9SGhRFjY)
网站：[https://grahambell.io/](https://grahambell.io/)
我很好奇这种方法对你来说是否听起来有趣，或者是否立刻就被认为是有缺陷的。
祝好！