最新

我们一直看到同样的问题：有人想为他们的社区、游戏组或项目创建一个 Discord 服务器，然后花费数小时设置频道、角色、权限和机器人配置。大多数人半途而废，最终得到一个半残破的服务器。 因此，我们构建了一个 AI 代理，能够完成整个过程。你只需输入类似“具有比赛赛程和等级进阶的竞技游戏社区”的内容，60 秒后，你就会拥有一个配置完整的服务器，包含 30 多个频道、角色、权限、欢迎系统、管理、工单——一切正常运作。 这不是一个模板选择器。该代理实际上会考虑你的社区需求——音乐制作服务器与学习小组或创业团队所需的频道和权限是不同的。 让我们感到惊讶的是：人们不仅仅使用一次。他们不断回头，为新的项目、活动或客户创建服务器。现在有一位用户通过它管理着 5 个服务器。 白标版本允许你在自己的机器人名称和品牌下运行这一切，结果发现这是一个没人要求但每个人看到后都想要的功能。 免费试用——无需信用卡。

端口转发通常是访问内部服务（如数据库、管理面板或指标端点）最快的方法。然而，在许多设置中，这意味着需要打开一个公共端口，并依赖防火墙规则或IP限制来确保安全。这些规则往往会随着时间的推移而累积。 我一直在研究现代“代理”端口转发模型是如何工作的。它们不是公开暴露服务，而是依赖于仅出站的连接，并创建仅在会话期间存在的身份范围隧道。 没有持久的入站端口，也没有长期的防火墙例外。 我在这里写了一篇分析，重点关注机制而不是产品宣传： https://www.lynxtrac.com/secure-port-forwarding-without-exposing-services 我很好奇这里的其他人是如何在云环境中处理临时服务访问的。

我正在构建 prod.bd，这是一个轻量级的开源隧道，用于将本地服务暴露到互联网。 我最初制作它是因为在开发过程中，我经常需要在真实的移动设备上测试前端应用。虽然像 Ngrok 和 Tailscale Funnel 这样的工具效果很好，但我想自己动手做一些东西。 你只需一条命令即可安装它，然后运行： `prod 3000 8080` 如果你不想运行不受信任的二进制文件，它也提供了 Docker 容器。 它会立即为你提供两个可公开访问的 HTTPS 子域名 URL。每个端口的子域名都是一致的。它还提供了一个简单的统计仪表板，可以检查 URL、头部和有效载荷。 在底层，它使用了 Cloudflare 的 Workers、Durable Objects 和 D1。如果你愿意，可以部署你自己的版本。 我使用 Kiro 和 Antigravity 来构建它。我想在构建有用的东西时尝试一些 AI 工具。顺便提一下，我正在实验插件系统，以便在保持核心隧道简单的同时添加新功能。如果没有 AI 工具，我根本不会尝试插件系统。 欢迎反馈、建议或改进的想法。

大家好，我最近录制了大量关于我的应用程序或一些教程（比如OpenClaw或其他随机内容）的演示。Screen Studio的导出速度成为了我工作流程中的一个瓶颈。因此，我创建了一个免费的替代品——一款原生macOS应用程序，名为ScreenKite。<p>我的目标是实现大约4倍的导出速度，同时保持类似的功能。<p>欢迎大家尝试！

代理可以在arXiv上查看论文，用户可以对代理的评论进行点赞或点踩。此外，还有最受欢迎的论文和代理的排名列表。请访问：https://clawdreview.ai/

嗨，HN， 我开发了 buildcage，作为我们在工作中加强供应链安全的一部分。我们遇到的问题是：当你在 Dockerfile 中运行 `RUN npm install` 时，该命令可以连接到互联网上的任何地方，而你无法看到它实际连接到了哪里。即使使用了固定的依赖项，受损的包仍然可能在构建过程中泄露构建秘密或与 C2 服务器进行通信。 buildcage 是一个 Docker 容器，它通过内部代理封装了 BuildKit。你只需提供一个允许的域名列表，只有对这些域名的连接会被允许，其他所有连接都会被阻止并记录。你的 Dockerfile 保持完全不变。 如果你使用 GitHub Actions，只需在工作流中添加几行代码即可——请参阅快速入门指南。 <a href="https:&#x2F;&#x2F;github.com&#x2F;dash14&#x2F;buildcage#quick-start" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;dash14&#x2F;buildcage#quick-start</a> 我想坦诚地说——这并不是万无一失的解决方案。如果恶意包通过合法的注册中心传递，连接将会指向一个允许的域名，而 buildcage 无法捕捉到它。你仍然应该固定依赖项、使用锁定文件并扫描漏洞。 我对这个问题的看法是：buildcage 是最后一道防线。如果有东西突破了你所有其他的防护措施，至少它无法与攻击者的服务器进行通信。 正是基于这个思路，我专注于让它易于采用。一个难以设置的安全工具是不会被使用的。使用 buildcage，你只需在 GitHub Actions 工作流中添加几行代码，一切就能正常工作——无需证书注入，无需更改 Dockerfile，也无需特殊的构建标志。 我很想听听你的想法——无论是关于这个方法、局限性，还是它如何融入你的工作流中。

嘿，HN！我是一名长期使用 Arc 浏览器的用户，非常喜欢它的侧边栏将标签页和书签组织成工作区的方式。我想在不失去这种工作流程的情况下切换到其他浏览器。因此，我开发了 Arcmark，这是一款 macOS 书签管理器（使用 Swift/AppKit），可以作为侧边栏悬浮在任何浏览器窗口旁边。它利用 macOS 的无障碍 API 来跟随浏览器窗口移动。 你可以通过工作区来组织链接/书签，支持嵌套文件夹、拖放重新排序和自定义工作区颜色。大部分情况下，我尽量将 Arc 的侧边栏用户体验复制得尽可能相似。 1. 本地优先：所有数据存储在一个 JSON 文件中（~ /Library/Application Support/Arcmark/data.json）。无需账户，无需云同步。 2. 兼容任何浏览器：Chrome、Safari、Brave、Arc 等等。或者可以作为独立的书签管理器使用，带有常规窗口。 3. 从 Arc 导入固定标签和工作区：它解析 Arc 的 StorableSidebar.json，以重建准确的工作区/文件夹结构。 4. 使用 swift-bundler 构建，而不是 Xcode。 在 README 中有一个演示视频，展示了侧边栏的实际使用情况。DMG 文件可以在发布页面找到（适用于 macOS 13 及以上），或者你可以从源代码构建。 这是 v0.1.0 版本，所以还处于非常早期的阶段。欢迎任何反馈或想法。 GitHub: [https://github.com/Geek-1001/arcmark](https://github.com/Geek-1001/arcmark)