“你能检查一下这个用户是否在高级计划中吗？”
“我在Mr.Bean上有一个支持工单，说他无法登录……你能看看吗？”
“今天我们有多少个订阅？”
作为Twenty.com（开源CRM）的高级软件工程师，我经常遇到这些问题。每天我都需要在Postgres中检查一些东西，但我得等30秒让DBeaver加载，或者跟pgAdmin的界面斗智斗勇。所以我创建了Paul。是的，我们的数据库配置对那些客户来说有太多架构（3000个架构），但这不是Postgres的错，而是客户端无法处理。
Paul是一个原生macOS应用，体积小（<20MB），启动只需2秒。你可以想象，与我打开DBeaver时需要等待5分钟相比，它的速度有多快……
我没有深入研究数据库管理员的功能，也没有过多关注用户界面。我保持Paul的简单性：你可以浏览表格、过滤和排序。
几个特点：
- Paul默认是只读的：你必须在设置中明确切换到编辑模式，才能允许INSERT、UPDATE或DELETE。这使得在生产环境中使用时更加安全。
- 我添加了一个代理模式（只读），可以更快地与数据库交互，而无需SQL知识。功能不复杂，基本上是对openAI和Anthropic SDK的封装。对于一些我不常用的SQL公式，这仍然很有用。
当然，它是免费的，不需要账户。也可以离线使用。
我很希望能收到关于缺失功能或改进建议的反馈。这是一个个人项目，我首先是为自己构建的，但如果有人觉得可以使用，我也乐意添加新功能。
返回首页
最新
你好，HN，
我在过去大约8个月里一直在开发一款名为Kiyeovo的桌面P2P消息应用程序，并且我刚刚发布了它的测试版。
简单的背景故事：它最初是我研究生论文的命令行应用程序，我试图制作一个尽可能安全和私密的消息应用程序。随后，我将其转变为桌面应用程序，增加了“清网”支持，并添加了一系列功能。
简要总结：
该应用程序运行在两种完全隔离的模式下：
- 快速模式：中继/DCUtR -> 更低延迟，支持通话
- 匿名模式：Tor消息路由 -> 更慢，匿名
这两种模式使用不同的协议ID、DHT命名空间、发布/订阅主题和存储范围，因此它们之间没有数据交叉。
当双方都在线时，消息通过点对点方式发送，但当其中一方不在线时，会回退到DHT“离线桶”。为了确保可靠性，消息在被读取后会进行确认（ACK）并删除。
群聊使用GossipSub进行实时消息传递。群消息也会保存到离线桶中，以便离线用户在登录时能够读取。踢出/加入/离开事件也通过DHT进行传播。群组元数据和所有离线数据当然是加密的。
其他功能：聊天是端到端加密的，支持文件共享，支持一对一音频/视频通话（不过仅在快速模式下，使用WebRTC）。
权衡：Tor有明显的延迟，离线交付并不立即保证，而是“最终一致”；测试版尚不支持群组通话。
我非常欢迎反馈，这也是我发布测试版的原因。
代码库： [https://github.com/Realman78/Kiyeovo](https://github.com/Realman78/Kiyeovo)
在你诚实的看法中。
我简直不敢相信这一切。在经历了一个非常繁琐的过程后，我终于成功验证了我的商业账户，原本很高兴能够使用Stripe的服务，但没想到却发生了这样的事情。
我向客户开了6或7张软件服务的发票，在他们支付后，Stripe却认为我的账户存在高风险，并将其暂停。即使在请求复审后，他们也没有改变主意，并表示交易将会被退款。
他们退款了所有发票，除了其中一张大约3500美元的发票。我尝试联系他们的客服，但没有得到任何回复，于是我通过投诉表单提交了投诉，他们的回复如下：
“摘要：
您已联系Stripe，表达了对您账户关闭的担忧。
我们的审核详情：
我们进一步审核了您的账户，决定仍然无法支持[公司名称]继续使用。您的账户关闭符合Stripe的服务协议：https://stripe.com/ae/legal/ssa#termination
请注意，通常情况下，符合条件的卡支付退款将在账户拒绝之日起5天内发放。超过5天后，我们将不再退款。如果在所有退款处理完毕后，您的账户中仍有余额，根据Stripe支付的服务条款，该余额将不会提供给您。
我们知道这是令人失望的消息，我们很抱歉我们无法做更多的事情。”
——
我该怎么办？我的公司注册在阿联酋。
大家好，我是Colton（YC S21，前Acorns），Postquant Labs的创始人之一。我的联合创始人Richard是一位来自Draper Labs和DARPA的密码学家。我们正在构建Quip.Network，这是第一个分布式量子计算网络。我们刚刚开放了测试网络，想在这里分享一下。
基本问题是：量子硬件已经问世，并且在某些优化问题上具有竞争力，但对于大多数人来说，无法访问这些硬件。这些机器的成本高达数百万，而硬件和研究则被拥有它们的公司所限制。
此外，量子计算提供商经常会有机器闲置，因为需求并不稳定，这造成了问题，因为许多架构需要在接近绝对零度的条件下冷却，不能随意关闭。目前还没有类似于按需云实例的量子计算解决方案。
因此，我们正在构建这样一个平台。Quip.Network是一个现货清算所和市场，量子提供商可以贡献多余的计算能力，开发者可以将他们最好的求解器部署到开放库中，任何人都可以提交工作负载并获得结果，而无需拥有或理解硬件。传统计算设备（CPU、GPU、TPU）也可以参与求解和验证。
第一个量子子网是在与全球领先的量子计算公司D-Wave紧密合作下构建的。它专注于优化问题，这类问题在金融、物流和制造等领域普遍存在。该子网运行在退火量子处理单元（QPU）上，并在解决方案质量、速度和能耗成本方面相较于传统计算方法表现出竞争力。挖矿协议围绕这些基准设计，因此参与者竞争以寻找更好的解决方案。
在启动之前，我们大约有13,000个注册用户。代码库是完全开源的，因为我们认为量子优势应该是一个可验证的结果，而不是市场宣传。我们希望人们能够运行节点，挑战我们的实现，并提交针对他们自己硬件优化的工作证明。
与GPU集群中增加一个处理器带来的线性改进不同，向集群中添加一个QPU的价值是指数级的。仅仅成为AWS、GCP或IBM是不够的。为了攻克最棘手的问题，我们希望将地球上每一个处理器连接在一起，使它们作为一个巨大的量子系统运行。这就是我们认为分布式系统是正确方法的原因，这也是我们致力于构建全球量子计算机的使命。
欢迎提问！
文档：quip.gitbook.io/docs | GitHub：github.com/quipnetwork