Typecho MCP Workbench 开发手记 05：图床、文件床和 v1 之前的安全边界
Typecho MCP Workbench 开发手记 05：图床、文件床和 v1 之前的安全边界前四篇基本把项目的骨架讲完了。第一篇讲为什么做：不是再造一个 Typecho 后台，而是把远程博客变成一个本地可控、AI Agent 可操作、远端尽量轻量的发布目标。第二篇讲怎么够到远端：SSH zero-touch，自动探测 Docker 里的 Typecho，部署一个很小的 PHP agent，用 stdin/stdout 做受控调用。第三篇讲 AI 被允许怎样操作：MCP 工具不是裸数据库函数，而是一组有策略、有快照、有审计的本地工作流。第四篇讲人类入口：localhost Web UI 只是原型，长期目标应该是一个类似 Obsidian 或 Typora 的本地桌面工作台。这一篇想把素材和安全模型收一下：图片、附件、外部 URL、图床、文件床、对象存储、桌面打包和 v1 路线，最后都要回到同一个问题：AI 可以帮我把内容准备到什么程度，人类又必须在哪些地方保留边界。为什么第 5 篇要讲素材博客文章不只有文字。一篇真正要发布的文章，里面会有截图、架构图、流程图、下载文件、外部链接、以后可能还有视频或大型附件。它们不一定都适合放在 Typecho 服务器上。Typecho 自己的上传目录很稳定，默认会把文件放到类似这样的路径：usr/uploads/YYYYMM/对于小图、普通截图、兼容性测试，这很好。第一版工作台也已经支持 typecho.media.upload：把文件上传到 Typecho 本地媒体目录，注册附件记录，再返回 Markdown。但如果所有图片和文件都塞进博客服务器，就会遇到几个现实问题：博客服务器磁盘不一定大。大文件会拖慢备份和迁移。热门图片会吃掉站点带宽。有些用户本来就有图床、文件床、对象存储或 CDN 工作流。AI Agent 插入素材时，需要知道这个链接来自哪里、是否可访问、是否应该被允许。所以这里不能只做一个“上传按钮”。更合适的抽象，是 asset provider。local media 和 external URL 是第一组边界当前项目里已经有两种最基础的素材路径。第一种是 typecho-local。它把文件上传到 Typecho 自己的上传目录，并注册成 Typecho 附件。优点是兼容、直观、不需要第三方配置。缺点也很明显：它消耗博客服务器存储和带宽，不适合大文件，也不适合把 Typecho 当成通用文件仓库。第二种是 external-url。它不上传文件，只注册一个已经存在的外部 URL，然后把它作为图片或文件链接插入 Markdown。这个 URL 可以来自图床、文件床、CDN、OpenList/AList、R2/S3，也可以是用户手工上传到别处后复制过来的链接。这两种能力看起来简单，但它们给后续 provider 系统定了一个重要形状：文章正文里插入的是 Markdown，工作台内部要保留 provider、URL、类型、来源和可检查状态。未来无论资源来自哪里，返回结果都应该长得差不多：{ "provider": "external-url", "media": { "filename": "diagram.png", "url": "https://cdn.example.com/diagram.png", "mime": "image/png", "external": true, "kind": "image" }, "markdown": "![diagram.png](https://cdn.example.com/diagram.png)" }这样 MCP Agent 和人类工作台不需要关心底层是 Typecho 上传、R2、S3、WebDAV，还是 OpenList。它们只需要知道：这是一个可插入文章的资产，它属于哪个 provider，它是否是外部链接，它应该怎样被审计和检查。asset provider 不是图床配置页如果把这个功能做窄一点，它很容易变成一个普通的“图床配置页”：填 endpoint、填 token、点上传、复制 URL。但在 Typecho MCP Workbench 里，asset provider 应该是发布工作流的一部分。因为 AI Agent 会参与写作，它不只是帮你复制图片链接。它可能会做这些事：根据文章内容建议需要哪几张图。把本地截图上传到默认 provider。把已有 CDN 图片注册到文章资产列表。检查 Markdown 里所有图片链接是否可访问。在发布前报告哪些资源是 Typecho 本地媒体，哪些是外部 URL。发现某个外链图片返回 404 后提醒人类替换。这时 provider 就不能只是“能上传就行”。它至少要回答几个问题：这个资源会不会公开？这个资源会不会消耗博客服务器空间？这个 URL 是否适合直接出现在公开文章里？凭据存在哪里？AI 是否有权上传这个大小和类型的文件？失败后能不能从 operation ID、audit log 和 debug bundle 里查到发生了什么？换句话说，asset provider 不是一个孤立功能，而是 Content、Review、Media、Operations 四个工作区之间的一条线。凭据必须留在本地素材系统里最不能含糊的是凭据。如果未来支持 S3、Cloudflare R2、WebDAV、OpenList/AList，用户会配置 access key、secret、token、endpoint、bucket、public base URL 这些信息。这里的原则应该很硬：Provider credentials stay local. Never store object storage secrets on the Typecho server. Do not put secrets in article Markdown, audit body, or debug bundle.远端 Typecho 不应该知道 R2 secret，也不应该代替工作台去上传对象。远端 PHP agent 的职责仍然要窄：处理 Typecho 文章、附件记录和必要的站点读写。素材上传、provider 凭据、URL 检查和策略判断，应该尽量留在本地工作台。这和前面几篇的架构是一致的：远端轻，本地重；远端执行，本地控制；远端不新增公网 API，本地保留策略、快照、审计和诊断。对于外部 URL，默认也不应该让 Typecho 服务器去代理下载。文章里插入的是公开 URL，发布前由本地工作台检查它是否可访问。这样既减少远端复杂度，也避免把博客服务器变成一个不受控的资源中转站。Operation Policy 也要管素材前几篇一直在讲 Operation Policy，主要围绕 publish、rollback、delete、plugin/theme/settings 这些高风险动作。但素材也需要策略，只是风险等级不一样。上传一张小截图，通常是 medium risk：它创建了远端对象，但一般可控、可替换、可删除。注册一个外部 URL，也可以是 medium risk：它会让公开文章依赖一个站外资源，需要记录来源和可访问性。删除媒体就更危险。因为一个看起来没用的附件，可能还被旧文章引用；一个外部 URL 如果被批量替换，也可能破坏历史文章。到了这一步，它就不再是“媒体管理”，而是会影响公开内容的写操作。所以我更希望 Operation Policy 以后能覆盖这些动作：assets.upload medium assets.register_url medium assets.rewrite_urls high media.delete high / critical provider.configure high provider.delete high provider.credential.write critical这不是为了给每个小动作都加弹窗，而是为了让系统能区分：哪些操作可以由 AI 准备，哪些操作必须人类确认，哪些操作需要先出报告，哪些操作永远不能静默执行。发布前检查应该看见资产prepare_publish 现在已经是这个项目里非常关键的动作。它不是发布按钮的一部分，而是 AI 和人类之间的一次安全握手。前面的版本里，它已经会检查标题、slug、正文、分类、标签、状态、图片链接等信息。到了 asset provider 这一层，它应该继续变得更具体：文章引用了多少张图片。图片分别来自 Typecho local 还是 external URL。外部图片是否返回 200。是否存在 http 明文链接。是否存在 localhost、内网地址、临时签名 URL。是否存在空 alt 或明显不合适的 alt。是否存在过大的文件或不适合公开的下载链接。是否存在 provider 凭据泄漏到正文的迹象。这些检查不一定都要一开始完成，但方向很明确：发布前，人类应该看到“这篇文章会把哪些素材公开出去”。这也是工作台区别于普通 Markdown 编辑器的地方。普通编辑器只关心 Markdown 能不能渲染；Typecho MCP Workbench 还要关心这段 Markdown 一旦发布，会对远端博客、外部存储、读者浏览和未来回滚造成什么影响。桌面打包让素材工作流更自然第四篇说过，长期入口应该是 Tauri 桌面应用，而不是永久停在 localhost 页面。素材系统会让这个判断更明显。浏览器页面当然可以选择文件、上传图片、插入 Markdown。但真正顺手的写作工作台，应该能做更多本地事情：记住每个站点的默认 asset provider。用系统文件选择器挑选截图和附件。把本地草稿目录、图片目录和远端文章 cid 绑定起来。把 debug bundle 导出到用户选择的位置。用本地安全存储保存 provider 凭据引用。在菜单、命令面板和快捷键里提供插入图片、注册外链、检查资产这些动作。这正是 Tauri 方向的价值：UI 可以继续复用现在的 Web renderer，但桌面壳逐步接管窗口状态、菜单、文件选择、凭据存储、日志目录、profile 和本地路径。短期的 Node local-service 仍然很重要。它是 MCP、CLI 和当前 Web Workbench 的参考后端，也承载了已经跑通的 SSH、local-ops、policy、cache、snapshot、audit。项目不应该为了桌面化而大爆炸重写。更稳的路线是：Web Workbench renderer -> WorkbenchBackend adapter -> HTTP backend today -> Tauri invoke commands later -> same policy / snapshot / audit semantics也就是说，桌面打包不是换一个壳就完事。它真正要完成的是：让人类入口变成长期可用的本地应用，同时不绕过已有的安全核心。v1 之前，先把边界说清楚这个项目已经能做很多事情：连接远端 Typecho，读文章，创建草稿，更新文章，上传媒体，注册外链，准备发布报告，显式确认后发布，写快照，回滚，记录审计，导出 debug bundle，还有第一版桌面壳方向。但越是接近可发布版本，越不能把话说满。当前真实链路优先跑通的是 SQLite Typecho。远端 agent 可以检测数据库类型，但不能因此宣称所有数据库都完整支持。MySQL/MariaDB 应该先做只读兼容和能力报告，再谨慎进入写支持。当前核心写路径集中在 posts 和 media。Pages、taxonomy、comments、plugins、themes、settings、users、permalinks 都可以逐步进入工作台，但应该先 read-only inventory，再决定哪些操作值得开放写入。当前 publish 默认需要人工确认。未来可以有 trusted agent mode，甚至 autopublish，但它们必须建立在更强的 readiness checks、客户端身份、限额、审计、回滚和策略配置之上，而不是把 confirm=true 偷偷藏起来。所以 v1 之前的路线，我更愿意写成一组清晰的门槛：1. SQLite-first release candidate 2. reliable SSH zero-touch setup 3. posts/media core workflow stable 4. publish and rollback review/confirm stable 5. asset provider baseline: local media + external URL 6. Operation Policy visible across Web / CLI / MCP 7. Debug Bundle and typed errors useful enough for real troubleshooting 8. Tauri desktop alpha can open the workbench and preserve the same safety model 9. database compatibility boundary stated honestly 10. broader Typecho operations stay read-only until policy/preview/audit/backup are ready这听起来比“马上 v1”慢一点，但我喜欢这种慢。一个 AI 可以操作的发布工具，最危险的不是功能不够多，而是功能看起来够多、边界却没有讲清楚。这个系列真正写下来的东西写到第 5 篇，我发现这个系列其实不是在记录“我做了一个 Typecho 客户端”。它记录的是一个 AI 时代的小型软件应该怎样长出来：先把远端系统变成可控工具目标。再给 AI 一组语义明确的 MCP 工具。再把危险动作收进策略、快照、审计和确认。再给人类一个能长期使用的本地工作台。最后再让素材、外部存储、桌面打包和 v1 路线全部服从同一条安全边界。这条路的重点不是让 AI 替我发博客。恰恰相反，是让 AI 能做越来越多准备工作时，我仍然知道它做了什么、要改什么、会发布什么、出了问题到哪里查、需要回滚时从哪里恢复。这也是 Typecho MCP Workbench 到目前为止最核心的产品判断：AI 负责加速。 本地工作台负责秩序。 人类负责边界。下一步五篇连载写完以后，项目就可以从“开发手记”进入更公开的 README、截图、release checklist 和桌面 alpha 打磨。后面如果继续写，我可能会把它拆成两个方向：一个方向写产品化：Tauri 桌面 alpha、安装包、站点 profile、默认 provider、发布报告和 debug bundle。另一个方向写更硬的工程边界：数据库兼容、Typecho Hook、comments/plugins/settings 的只读盘点、trusted agent mode 和 autopublish policy。如果说前五篇是在搭骨架，那后面就该开始回答一个更具体的问题了：这个工具怎样从“我自己的博客能用”，变成“别人也敢拿来接自己的 Typecho”。
Typecho MCP Workbench 开发手记 04：localhost 只是原型，真正目标是本地人类工作台
Typecho MCP Workbench 开发手记 04：localhost 只是原型，真正目标是本地人类工作台上一篇写到 MCP 工具层：AI 不应该直接拿 SSH 或数据库，而应该通过一组有语义、有策略、有快照、有审计的本地工具来操作博客。到这里，项目已经有了一条比较清晰的秩序：先预览，再保存；先检查，再发布；先快照，再回滚；先记录，再排查。这篇想继续往人类端推进一步：当前的 localhost Web UI 能证明方向，但它不是终点。真正的目标，是一个类似 Obsidian 或 Typora 的本地人类工作台。localhost 能跑通链路，但不能回答日常使用问题http://127.0.0.1:4783 对早期开发非常好。前端可以直接改，后端 API 可以直接接，CLI、MCP、Web UI 都能复用同一套 local-ops。出问题时，打开浏览器、看控制台、看请求日志，很快就能知道链路断在哪里。但 localhost 页面只能回答一个工程问题：这条链路能不能跑通。它还没有回答一个更日常的问题：我明天、下周、半年后，愿不愿意每天打开它写东西？写作不是一次性的调试动作。它有草稿、素材、上下文、窗口布局、快捷键、预览习惯、发布前焦虑，以及出了问题之后必须能快速排查的安全感。长期使用时，人更希望打开的是一个稳定的本地工作空间，而不是“某个还开着的浏览器标签页”。所以这一步的判断是：Web UI 是很好的 renderer 原型，但产品形态不能停在浏览器里。这不是普通后台，也不是自动发布按钮如果只是为了管理文章，Typecho 官方后台已经能做很多事情。这个项目并不是要把官方后台换个皮肤重新做一遍。普通后台的中心是“人点按钮管理内容”。Typecho MCP Workbench 的中心是“AI 准备，人类审阅，人类授权，本地记录”。这两种心智模型差别很大。普通后台关心 CRUD 页面：新建、编辑、删除、设置、保存。这个工作台更关心一次操作是否可预览、是否有快照、是否被策略允许、失败后是否可诊断、事后能不能追踪。普通后台默认远端是主场：登录后台，修改远端状态。这个项目默认本地控制面是主场：SSH、缓存、审计、快照、策略、Debug Bundle 都留在本地；远端 Typecho 尽量轻，只接受窄而明确的 agent 调用。所以它更像一台本地写作驾驶舱。AI 可以整理、生成、检查、准备；人类负责判断、取舍、确认和追责。为什么最终应该像 Obsidian / Typora写作软件和管理后台的感觉不一样。Obsidian 或 Typora 给人的感觉是“我的本地工作空间”。它们有稳定的窗口、熟悉的快捷键、文件和草稿的归属感、长期沉淀的布局偏好。你打开它，不是在“登录一个系统”，而是在回到自己的写作现场。Typecho MCP Workbench 也应该往这个方向靠。它需要承载的不只是一个编辑框：本地草稿和远端文章之间的同步状态。AI Agent 准备好的修改建议和发布报告。保存前的 Diff Preview。发布前的 Prepare / Review / Confirm。回滚前的 Snapshot Preview。媒体、图床、文件床和未来 asset provider。request log、audit log、debug bundle。多站点 profile、窗口布局、命令面板、系统菜单和快捷键。这些东西如果都塞进一个后台页面，就会越来越像“按钮堆叠”。但如果按本地工作台设计，它们可以变成稳定的信息架构。工作台空间应该怎样组织我现在更倾向于把界面拆成几个长期稳定的区域。顶部栏放站点、host、同步状态、命令面板入口和全局状态。左侧 Activity Bar 不直接堆功能按钮，而是切换工作模式：Content、Review、Media、Operations、Site、Settings。Sidebar 服务当前模式。写文章时，它是文章列表和筛选器；看媒体时，它是素材来源和资产分组；排查问题时，它是日志和诊断入口。主区域永远优先给写作和审阅。Markdown editor、Preview、Diff、Snapshot Review 都应该在这里发生。右侧 Inspector 放 metadata、slug、tags、categories、publish context、snapshot context、policy context。它不应该打断正文，而应该像一个随时可看的上下文抽屉。底部 Operations Panel 放 request log、diagnostics、audit、cache、debug bundle。这些东西很重要，但不应该抢走写作主场。底部状态栏则负责低噪音地显示 host、cache freshness、selected post、dirty state、prepare state、last operation ID 和 policy state。这套布局已经在现在的 Web Workbench 里切出了第一版：Activity Bar、Writing/Split/Preview、Inspector、Operations Panel、Status Bar、Publish Review Sheet。它还不完美，但方向已经从“调试页面”转向“桌面工作区”。发布不是一个按钮，而是一段可解释流程这一点是工作台区别于普通后台的关键。发布不应该只是一个蓝色按钮。它应该是一段可解释的流程：Prepare -> 检查标题、slug、正文、分类、标签、图片链接、当前状态 Review -> 展示 blockers、warnings、images、external links、diff、freshness Confirm -> 展示 Operation Policy、risk、host、post、snapshot 行为、audit 行为 Result -> 展示 post URL、snapshot ID、operation ID、audit event、rollback 入口prepare_publish 是 AI 和人类之间的一次安全握手。AI 可以把文章准备好，可以告诉你标题是否为空、slug 是否合理、图片链接是否可访问、正文有没有明显问题。但 warning 是否可接受，最终应该由人判断。同样，rollback 听起来像安全动作，但它也是一次真实写操作。它会把远端文章恢复到某个历史快照。如果没有看清楚当前版本和目标快照之间的差异，回滚本身也可能造成内容丢失。所以发布和回滚都应该从“一次 confirm”升级成应用内 Review/Confirm。人类在确认之前能看到足够上下文，确认之后能拿到 operation ID、audit event 和回滚入口。Diff、Snapshot、Policy、Audit、Debug 是同一条信任链这些能力单独看都不复杂。Diff Preview 解决“我将要改什么”。Publish Prepare 解决“这篇文章能不能公开”。Snapshot Preview 解决“我要恢复成什么”。Operation Policy 解决“这个动作为什么需要确认”。Audit Log 解决“事后如何追踪”。Debug Bundle 解决“失败后如何把上下文交给人或 AI 继续排查”。但它们合在一起，才是一条完整的信任链。安全感不是藏在后端代码里的规则，而是每一次危险动作前，人类都能看见足够的上下文。这也是为什么我越来越不想把这些功能简单地叫作“调试功能”。它们其实是 AI 发布工作台的核心产品能力。变宽，但不要变成泛后台后来我又回头看了一遍 Typecho 官方文档。Typecho 后台当然不只有文章和媒体，还有页面、分类、标签、评论、插件、主题、用户、设置、永久链接等等。这提醒我：这个项目最终不应该只是“远程写文章工具”。它可以慢慢变成一个更完整的 Typecho 本地控制面。但节奏必须克制。Posts 和 Media 是当前核心，因为它们直接服务写作发布。Pages、Taxonomy、Comments 可以作为下一阶段 read-only inventory 进入工作台：先看清楚远端状态，再决定哪些操作适合加入。Plugins、Themes、Settings、Users、Permalinks 这类操作风险更高。它们更适合先做诊断和只读摘要，未来如果要支持写操作，也必须走 preview、policy、audit、backup，甚至要考虑 Typecho Hook 兼容性。一句话：项目可以变宽，但不要退化成普通后台复制品。写作优先、可见性优先、危险写操作延后。AI 项目里的项目记忆这次开发还有一个很有意思的变化：我不再只把 AI 当成“写代码的人”。我们开始把任务拆成不同方向：主线工程、UI 规划、文章素材、官方文档校准、开源项目调研、公开 README 包装。不同 Agent 负责不同部分，而我的主线程更像项目经理，负责路线、边界、合并和纠偏。这时文档就不再是写完代码后的说明书，而是多个 Agent 能继续工作的项目记忆。docs/ai-agents/ 记录项目方向、当前状态、安全边界、Roadmap、协作方式；docs/series/ 记录文章素材和开发故事；公开 README 则把项目包装成别人能理解、能试用、能贡献的开源入口。这其实也很符合这个项目本身的主题：AI 负责加速，人类负责边界。这一篇之后，入口更清楚了到第四篇，项目形态更明确了。MCP 是 AI 的主入口。CLI 是调试和恢复入口。local-ops 是安全核心。Web Workbench 是快速迭代 renderer。Tauri 桌面应用，才是长期的人类入口。这不是为了把人类从流程里拿掉。恰恰相反，它是为了让 AI 的连续操作能力，落在一个人类能理解、能审阅、能确认、能追踪的空间里。下一篇我想写素材和安全模型：Typecho local media、external URL、未来 R2/S3/WebDAV/OpenList provider，以及图床、文件床、凭据、本地策略和审计之间应该怎样组合。
Typecho MCP Workbench 开发手记 03：把博客操作变成 AI Agent 能安全调用的工具
Typecho MCP Workbench 开发手记 03：把博客操作变成 AI Agent 能安全调用的工具上一篇写到 SSH zero-touch：本地工作台通过 SSH 自动找到 Docker 里的 Typecho，部署一个极轻的 PHP agent，然后用 stdin/stdout 调用它。这篇自然接上：远端 agent 只是执行器，真正的控制面在本地 MCP 和 local-ops。如果说第二篇解决的是“怎么安全地够到远端”，那第三篇解决的是“够到之后，AI 到底被允许怎样操作博客”。为什么 MCP 是主入口最直接的做法，是把 SSH、数据库路径、Typecho API 或某个管理接口直接交给 AI。这样当然也能完成任务，甚至短期看起来更快。但这条路的问题也很明显：它把能力暴露得太原始了。AI 如果直接拿 SSH，它看到的是一台机器；如果直接拿数据库，它看到的是一堆表；如果直接拿远端 API，它看到的是一组远程写入口。这些接口都太接近底层状态，缺少“写作流程”本身应该有的约束。我想要的是另一种边界：AI Agent 只调用本地 MCP 工具 本地 MCP 工具表达编辑意图 local-ops 负责策略、快照、审计和缓存 远端 PHP agent 只执行很窄的原子操作这样 AI 拿到的不是“服务器权限”，而是一组有名字、有语义、有确认策略、有审计记录的工具。它可以写文章，但不能绕开发布确认；它可以预览修改，但不能跳过快照；它可以请求回滚，但必须明确确认。这就是 MCP 在这个项目里的定位：不是“多一种 API 封装”，而是给 AI Agent 设计的本地安全控制面。工具名要贴近编辑流程我不希望 MCP 工具长得像数据库函数，比如：contents.insert contents.update_status metas.attach relationships.delete这些名字对机器很友好，但对真实工作流不友好。写博客不是在操作 contents 表，而是在经历一套编辑动作：先看站点和文章列表。打开一篇文章。创建草稿。预览这次修改会改变什么。保存前生成快照。发布前做检查。明确确认后发布。必要时从快照回滚。所以现在的 MCP 工具更接近这个节奏：typecho.posts.list typecho.posts.get typecho.posts.create_draft typecho.posts.preview_update typecho.posts.update typecho.posts.prepare_publish typecho.posts.publish typecho.posts.rollback媒体也一样，不是“写附件表”，而是：typecho.media.list typecho.media.upload typecho.media.register_external_url而围绕安全、诊断和可观测性的工具，则是另一组辅助控制面：typecho.audit.list typecho.cache.status typecho.cache.clear typecho.snapshots.list typecho.snapshots.get这些工具名的目标，是让 AI 在调用之前就能理解动作的风险。preview_update 听起来就是预览；prepare_publish 听起来就是发布前检查；publish 和 rollback 则天然应该被策略系统盯住。工具不是数据库函数，而是可审计工作流一个好的 MCP 工具，不应该只是把远端方法暴露出来。它应该把一次操作拆进工作流。比如更新文章，看起来只是改标题和正文，但实际链路应该是：posts.preview_update -> 对比当前远端文章和目标修改 posts.update -> 强制读取远端最新状态 -> 创建本地 snapshot -> 调用远端 agent 写入 -> 写 audit log -> 失效相关缓存发布文章也是：posts.prepare_publish -> 检查标题、slug、正文、分类、标签、图片链接 -> 给出 blockers / warnings posts.publish(confirm=true) -> 检查 Operation Policy -> 创建 before_publish snapshot -> 调用远端 agent 发布 -> 写 audit log这就是“工具层”和“远端执行器”的差别。远端 PHP agent 可以有 posts.update 这种原子能力；但本地 MCP 暴露给 AI 的，不应该只是一个裸写入口。它必须把快照、策略、审计、缓存失效这些事情纳入默认路径。发布和回滚必须有确认策略发布和回滚是两个特别值得单独拎出来的动作。发布会改变公开世界。草稿变成公开文章后，RSS、搜索引擎、订阅器、读者都会看到。它不是一个“普通状态字段更新”。回滚则更微妙。它听起来像安全动作，但其实也是写操作：它会把当前远端文章恢复到某个历史快照。如果用户没有看清楚“当前版本”和“目标快照”之间的差异，回滚本身也可能造成内容丢失。所以这个项目里，发布和回滚都不应该被 AI 静默执行。它们必须经过 Operation Policy，要求明确确认：publish -> confirm=true rollback -> confirm=true这不是形式主义。它让工具层可以区分“AI 准备好了一个发布建议”和“用户真的批准了发布”。未来评论删除、插件启停、主题切换、批量修改分类，也应该纳入同一套风险等级和确认系统。Diff、Snapshot、Policy、Audit、Debug 合在一起才是边界单独看这些能力，每一个都不复杂：Diff Preview：保存前看看改了什么。Snapshot Preview：回滚前看看要恢复什么。Operation Policy：对高风险动作做确认和限制。Audit Log：记录谁在什么时候做了什么。Debug Bundle：出问题时导出诊断、日志、审计、缓存和环境摘要。但它们合在一起，才构成真正的安全边界。Diff Preview 解决“我将要改什么”。Snapshot Preview 解决“我将要恢复什么”。Operation Policy 解决“这个动作现在能不能做”。Audit Log 解决“事后如何追踪”。Debug Bundle 解决“出问题后如何把上下文交给人或 AI 继续排查”。这也是我越来越明确的一点：AI 工具的安全感，不是靠一句“请谨慎操作”得到的，而是靠每一次危险动作都有可见前置、明确确认、可回滚依据和可追踪记录。本地控制面也服务人类界面虽然这一篇讲 MCP，但它并不只服务 AI。最终的人类工作台会是一个独立桌面软件，应该更像 Obsidian 或 Typora，而不是一个临时 localhost 页面。但无论界面是什么形态，它都应该复用同一套本地控制面。人类点击“保存”，底层也应该走 preview_update 和 update。人类点击“发布”，底层也应该走 prepare_publish 和 publish(confirm=true)。人类打开“诊断”，底层也应该拿 Debug Bundle。这样 Web 原型、未来桌面端、CLI、MCP Agent 都不会各自发明一套博客写入逻辑。它们只是同一套 local-ops 的不同入口。这一篇之后，项目更像一个工作台了到第三篇，项目的轮廓已经比较清楚：第一篇讲的是：为什么要做一个 local-first Typecho MCP Workbench。第二篇讲的是：如何通过 SSH zero-touch 把远程 Typecho 接成本地可操作目标。第三篇讲的是：为什么本地 MCP 工具层才是 AI 操作博客的主入口。现在它不只是“能远程写文章”，而是开始有了工作台应有的秩序：先预览，再保存；先检查，再发布；先快照，再回滚；先记录，再排查。下一篇我想写本地人类工作台：为什么当前 localhost Web UI 只是原型，最终目标会是一个独立桌面软件；以及编辑器、媒体、预览、发布报告、回滚面板和 AI 协作入口应该怎样组合在一个日常可用的写作空间里。
Typecho MCP Workbench 开发手记 02：SSH 零操作，把远程博客接成本地工作台
Typecho MCP Workbench 开发手记 02：SSH 零操作，把远程博客接成本地工作台上一篇写的是这个项目为什么存在：我不想再做一个“更漂亮的 Typecho 后台”，而是想把远程博客变成一个本地可控、AI Agent 可操作、远端尽量轻量的发布目标。这篇继续往下走，讲最关键的一段链路：SSH zero-touch deployment。所谓 zero-touch，不是说系统里没有部署动作，而是说远端不需要人手工登录后台、安装插件、改配置、开公网接口。用户给本地工作台一个 SSH 目标，本地侧自己完成探测、部署、健康检查和后续调用。远端 Typecho 仍然是原来的 Typecho，只是多了一个很小、可审计、可移除的 PHP agent。为什么不用 Typecho 插件起步一开始很容易想到“写一个 Typecho 插件，暴露 JSON API”。这条路并不奇怪，甚至很自然：Typecho 是 PHP 应用，插件机制也在那里。但它有几个我不太喜欢的前提：用户要先登录后台安装插件。远端要新增一个公网可访问的 API 面。鉴权、限流、日志、撤销策略都要在博客服务器上承担。如果 AI Agent 误操作，远端插件会直接站在第一现场。对于一个面向写作和发布的 MCP Workbench，我更想要的边界是：MCP 留在本地，远端只做被调用的最小执行器。AI Agent 不直接碰服务器，不直接连数据库，也不拿到一个公网管理 API。它只调用本地 MCP 工具；本地工具再走统一的策略、快照、审计和 SSH 调用链。所以当前方案变成了：AI Agent / 人类工作台 -> 本地 MCP / local-service -> SSH -> 远端 PHP agent -> Typecho 文件和数据库这条链路看起来绕了一点，但每一层都有清楚的职责：本地负责控制和安全，SSH 负责传输，PHP agent 负责很窄的 Typecho 操作。第一步：先找到 Typecho 在哪里zero-touch 的第一件事不是上传文件，而是探测。很多 Typecho 博客不是标准的一台机器一个目录。有的人放在 /www/wwwroot，有的人放在 public_html，也有人用 Docker、Dockge 或别的面板把 Typecho 跑在容器里。这个项目当前优先支持的真实场景就是 Docker 里的 Typecho：本地通过 SSH 进宿主机，再找到能够执行 PHP 的容器。探测逻辑不会全盘扫服务器，而是看一组高价值线索：config.inc.php index.php var/Typecho/ var/Widget/ usr/themes/ usr/plugins/这些标记组合起来，比单独看一个 index.php 靠谱得多。探测结果会带上候选根目录、置信度、运行模式和可用执行方式。如果只有一个高置信候选，本地可以自动选择；如果有多个候选，未来工作台应该让用户确认。这个设计的重点是克制：探测只回答“这里是不是一个 Typecho，以及应该怎样执行它”，不顺手做写入，不修改站点，也不猜测业务配置。第二步：部署一个很轻的 PHP agent找到 Typecho 之后，本地会准备远端 runtime。理想位置是 Typecho 根目录下的：.typecho-mcp/如果站点目录不可写，后续也可以退到用户 home 目录下的项目私有路径。无论放在哪里，原则都一样：只写项目自己的目录，只删除项目自己的目录，不碰主题、插件、上传文件和 Typecho 核心文件。PHP agent 本身也保持小。它不是一个常驻服务，不监听端口，不对公网开放。它只在本地通过 SSH 触发时运行一次，从 stdin 读 JSON，请求完成后把 JSON 结果写到 stdout，日志走 stderr。这条约束很重要：stdout 只能是协议 JSON stderr 才能放日志因为本地侧要把远端执行看成一个可组合的函数调用。如果 stdout 里混入 warning、debug 或 HTML，协议就会变脏。把协议输出和日志输出分开，后面做 MCP 返回、审计、错误分级都会轻松很多。第三步：通过 SSH/stdin/stdout 调用Docker 场景下，最终调用大致长这样：ssh sg1 "docker exec -i typecho-php-1 php /app/.typecho-mcp/current/agent.php"本地把请求写进 stdin：{ "jsonrpc": "2.0", "id": "op_xxx", "method": "posts.get", "params": { "cid": 87 } }远端把结果写回 stdout：{ "jsonrpc": "2.0", "id": "op_xxx", "result": { "post": { "cid": 87, "title": "Typecho MCP Workbench 开发手记 01..." } } }这不是让远端 PHP agent 变成 MCP Server。MCP Server 仍然在本地，负责给 AI Agent 暴露工具；远端 agent 只是本地服务通过 SSH 调用的执行器。这个分工让我比较安心：AI Agent 看到的是 typecho.posts.create_draft、typecho.posts.prepare_publish、typecho.posts.publish 这样的本地工具，而不是一把 SSH key 和一个数据库路径。第四步：把写操作收束到本地策略里真正危险的不是“能不能连上服务器”，而是“连上之后谁有权做什么”。所以项目里所有写操作都要走 local-ops：创建草稿可以直接执行，但要写审计日志。更新文章前要先做本地快照。发布文章前要经过 publish policy。回滚、删除、评论、插件启停这类高风险动作必须显式确认。这次第 2 篇文章的发布也走了同一条路径：MCP 工具创建草稿，MCP 工具做发布前检查，最后带 confirm=true 和明确的 client 标识发布。也就是说，连这个系列本身也在用它正在讲的系统发布。这种自举很有意思。它会逼项目面对真实问题：分类和标签能不能写进去？图片能不能走 Typecho 媒体路径？发布前检查能不能发现空 slug、空分类、失效图片？发布后能不能回读验证？如果这些路径在写项目文章时不顺手，那它也很难真正服务日常写作。第五步：远端轻，未来才好扩展SSH zero-touch 还有一个好处：它给后续客户端留出了空间。今天的入口是本地 Web workbench 和 MCP stdio；以后可以是桌面应用、菜单栏工具、移动端审核器，甚至是多个 AI Agent 的协作工作流。但这些入口都不应该各自发明一套远端写入方式。它们应该共享同一个本地服务、同一套策略、同一份快照和审计记录。远端 PHP agent 越轻，本地控制面就越容易演进。要加缓存、请求日志、发布报告、图床策略、回滚预览，都可以在本地层完成。远端只需要稳定地执行少数 Typecho 原子操作。这也是我现在越来越喜欢这个架构的地方：它没有试图把 Typecho 改造成一个现代 API 平台，而是尊重它已经是一个成熟博客系统，然后在本地给它接上一层适合 AI 协作的控制面。这一篇完成后的状态到这里，项目已经从“有一个想法”走到了“远程博客可以被本地 MCP Workbench 操作”：SSH 可以发现 Docker/Typecho 执行目标。远端 PHP agent 可以通过 stdin/stdout 执行受控方法。本地 MCP Server 可以把这些能力包装成 AI Agent 工具。草稿、媒体、预发布检查和发布都走项目自己的路径。发布动作有策略、快照和审计记录，而不是直接写数据库。下一篇会写 MCP 工具层本身：为什么工具名和参数要设计得像编辑流程，而不是像数据库函数；以及 AI Agent 创建草稿、更新文章、准备发布报告、发布和回滚时，哪些约束必须放在工具边界里。
Typecho MCP Workbench 开发手记 01：从一个想法到能被 AI 推送的博客
Typecho MCP Workbench 开发手记 01：从一个想法到能被 AI 推送的博客这篇是《Typecho MCP Workbench 开发手记》的第一篇。它不是一篇正式的产品发布稿，更像是一份边做边记的开发日志：我们从一个很朴素的愿望开始，把一个远程 Typecho 博客改造成可以被本地工作台和 AI Agent 一起操作的写作系统。我准备把这个过程拆成 5 期：从需求到架构：为什么不是再做一个博客后台，而是做本地控制台加 MCP。SSH 零操作部署：本地连接服务器、自动探测 Typecho、自动部署轻量 agent。MCP 工具层：让 AI Agent 能创建草稿、更新文章、发布、回滚。人类工作台：Markdown 编辑、预览、媒体插入、审计和发布确认。图床、文件床和安全策略：让图片文件走外部存储，同时保留审计、快照和权限边界。这个项目想解决什么传统博客后台更适合人手动写文章：打开网页、登录后台、点新建、写正文、传图、预览、发布。这个流程很稳定，但当 AI Agent 开始参与内容生产之后，它就有一点别扭了。Agent 更擅长连续操作：整理素材、起草大纲、补充章节、检查错别字、生成摘要、给旧文补链接。它需要的是一组可靠的工具，而不是一个必须用鼠标点击的后台页面。所以这个项目一开始没有被定义成“漂亮一点的 Typecho 客户端”，而是被定义成：让 Typecho 成为一个本地可控、AI 可操作、远端尽量轻量的发布目标。人类界面负责检查、微调和确认；MCP 负责主要操作；远端服务器只需要 SSH，不额外暴露公网 API。第一版长什么样先看本地工作台。它不是一个花哨后台，而是一个能快速完成写作和审核的控制面：左边看文章和媒体，中间写 Markdown，右边预览，下面能看到快照和审计记录。这个界面只是入口之一。更关键的是，所有核心能力都下沉成了本地操作和 MCP 工具。也就是说，人可以点按钮，AI Agent 也可以直接调用工具完成同样的事。架构：本地重一点，远端轻一点当前方案分成三层：本地工作台：给人看的 Markdown 编辑和审核界面。本地 MCP Server：给 AI Agent 调用的工具入口。远端 PHP Agent：通过 SSH 自动部署，只在需要时执行。我喜欢这个结构的一点是，它没有要求远端 Typecho 改造成一个新系统。远端不需要手动安装插件，也不需要长期跑一个新服务。第一次连接时，本地程序通过 SSH 探测 Typecho 目录，识别 Docker 或宿主机 PHP 环境，然后上传一个很小的 agent。在这个真实环境里，Typecho 跑在 Docker 里，站点目录挂载到容器的 /app，SQLite 数据库是 /app/usr/typecho.db。本地只需要知道 SSH 主机别名 sg1，剩下的探测、部署和调用都由工作台处理。这次 vibe coding 做到了哪一步目前第一版已经跑通了一条真实链路：通过 SSH 连接远端服务器。自动识别 Docker 里的 Typecho。自动部署远端 PHP agent。读取站点信息和文章列表。创建草稿、更新文章、发布文章。发布前写本地快照。支持回滚。支持上传 Typecho 本地媒体。支持注册外部图床和文件床 URL。本地记录审计日志，方便回看每次操作。这篇文章本身，也是用这套流程创建出来的：先把配图通过媒体工具上传到 Typecho，再由 MCP 创建草稿。发布这一步默认需要显式确认，所以我先把它留在草稿状态，让人类最后看一眼。为什么第一步先做 MCP因为这个项目真正的主角不是编辑器，而是 Agent 工作流。如果只是做一个本地 Markdown 编辑器，那它和很多现成工具差别不大。但如果 Typecho 能被 MCP 工具稳定操作，AI 就能完成更多连续任务：创建系列文章、维护标签、插入外部图片、检查旧文、补链接、发布前生成摘要。更重要的是，MCP 把“能做什么”和“怎么展示”拆开了。人类工作台可以继续变好看，CLI 可以继续变顺手，AI Agent 也可以直接调用同一组能力。它们不需要互相抢主入口。这版里最重要的安全边界我不想让“AI 能发博客”变成“AI 一不小心就发出去了”。所以第一版里有一个很硬的默认策略：创建草稿可以直接做。更新文章前先写本地快照。发布必须显式确认。发布、更新、上传媒体都会写审计日志。回滚从本地快照恢复，不依赖人脑记忆。这套策略目前还很朴素，但已经足够支撑一个重要原则：Agent 可以帮我做很多事，但最后一步必须有清晰边界。下一篇写什么下一篇会拆 SSH 零操作部署这一层：本地如何探测远端目录，如何识别 Docker 容器，为什么让 agent 通过 stdin/stdout 通信，以及这样做比公开 HTTP API 更适合一个私人博客工作台。这个系列不会写成宏大的发布稿。我更想保留真实开发过程里的纹理：哪里顺，哪里踩坑，哪里临时折中，哪里突然发现“这条路可以继续往前走”。
别再只让 AI 写代码了：给编程助手接上浏览器和 MCP，效率直接上一个台阶
如果你最近还在把 AI 编程助手当成“会补全代码的聊天框”，那真的有点亏。2026 年的开发者工具热点，已经从“让 AI 写函数”变成了“让 AI 看到真实运行环境、读到项目上下文、调用外部工具，然后自己验证结果”。简单说：AI 编程助手正在从副驾驶，变成能干活的实习同事。这篇就聊一个特别实用的方向：把 AI coding agent 接上浏览器、MCP 和项目规范，让它不只是写代码，还能帮你调试、审查、跑测试、查文档。先说结论：这套工作流适合谁？如果你有下面任意一种场景，就很值得试：经常改前端页面，但反复截图、刷新、查控制台很烦；项目文档、数据库、云服务、Issue 分散在不同地方；想让 AI 帮你改代码，但又怕它胡写、瞎猜 API；你维护的是个人博客、小工具、Docker 服务、管理面板这类“东西不大，但杂活很多”的项目；希望 AI 帮你做重复任务，比如写测试、整理 PR、查日志、补文档。核心思路只有一句话：不要只给 AI 一个问题，要给它工具、上下文和验收标准。最近为什么突然火？1. 浏览器调试终于能交给 Agent 了Chrome DevTools for agents 1.0 已经发布。它的重点不是“又多了一个聊天助手”，而是把浏览器调试能力开放给 AI coding agent：看页面、查 DOM、跑 Lighthouse、做设备模拟、定位内存泄漏。这对前端和全栈开发特别关键。以前 AI 写完页面，只能靠你描述“这里歪了、那里不对”。现在它可以自己打开页面、观察结果、再回去改代码。2. MCP 变成 AI 工具接入的通用插座MCP，全名 Model Context Protocol，可以理解成 AI 连接外部工具和数据源的一套开放协议。Anthropic 最早开源后，现在越来越多工具围绕 MCP 做集成。你可以把它想成 USB-C：GitHub、Postgres、浏览器、文件系统、云服务，都可以做成 MCP Server；AI 客户端作为 MCP Client，按权限调用这些工具；你不用为每个 AI 工具重复写一套私有插件。 3. 云厂商也开始给 Agent 准备“安全栏杆”AWS 最近发布 Agent Toolkit for AWS，把 MCP Server、Agent Skills、插件和 IAM 权限边界放到一起。这个信号很重要：企业不是不想用 AI Agent，而是怕它乱动生产环境。所以未来真正好用的 AI 开发工作流，一定不是“给 root 权限让它随便跑”，而是：能查文档；能读日志；能在沙箱里执行；能跑测试；能被权限和审计限制住。一套个人开发者也能落地的配置清单下面这套不追求玄学，适合个人项目、小服务器、博客、Docker 应用。第一步：给项目写一份 AGENTS.md很多 AI coding agent 都会读取项目里的说明文件。你可以在项目根目录放一个：# AGENTS.md ## 项目说明 这是一个 Typecho + Docker Compose 部署的个人博客。 ## 常用命令 - 查看容器：docker ps - 查看日志：docker logs --tail=100 <container> - 检查 Compose：docker compose config ## 修改规则 - 修改数据库前必须备份 - 不要在生产服务器安装新软件 - 所有文章发布前检查标题、slug、分类关系 ## 验收标准 - 页面 HTTP 200 - 首页能看到新内容 - 图片和 iframe 不被过滤这东西看起来朴素，但非常有用。它能把你的偏好和安全边界变成 Agent 每次都会参考的“项目说明书”。第二步：把浏览器接进调试流程如果你做前端，建议至少准备一个能让 AI 观察页面的环境。官方示例里，Chrome DevTools for agents 支持 MCP Server、CLI 和 Agent Skills。它能让 Agent 做这些事：打开页面并截图；检查控制台报错；模拟移动端窗口；跑 Lighthouse；检查可访问性和 SEO；调试复杂的浏览器状态。这一步的价值很大：AI 不再只听你说页面错了，它能自己看。第三步：只开放必要工具，不要一上来给全权限这是很多人会踩的坑。别为了省事直接给 AI：sudo su chmod -R 777 /opt 把生产数据库直接给它随便改更推荐这样拆：# 只读观察 ssh myserver "docker ps && docker logs --tail=80 app" # 修改前备份 cp data.db data.db-before-change-$(date +%Y%m%d-%H%M%S) # 改完验证 curl -I https://example.com让 Agent 有能力，但不要让它没有边界。第四步：把任务写成“可验收”的小块坏提示词：帮我优化一下网站。好提示词：帮我检查首页移动端布局。要求：打开本地页面，截图确认没有文字重叠；如果改 CSS，改完跑一次构建；最后给我列出改了哪些文件。这就是 AI Agent 的正确打开方式：任务越具体，它越像同事；任务越玄学，它越像抽奖。我建议你马上做的 5 件事给每个长期项目加一个 AGENTS.md；把“启动、测试、构建、备份、回滚”命令写进去；给 AI 的 SSH 权限单独分层，不要默认全权生产；前端项目一定让 AI 看到页面，不要只让它猜；所有数据库直写任务都先备份，再验证页面。最后说句实在的AI 编程助手最强的地方，不是替你写一段漂亮代码，而是接手那些“你会做，但很烦”的流程：查日志、看页面、跑测试、整理文档、复现问题、生成小补丁。未来的差距，可能不在于谁会不会用 AI，而在于谁更会给 AI 配工具、立规矩、拆任务。会用聊天框，只是入门；会搭 Agent 工作流，才是真正的生产力。参考资料：OpenAI: Codex for almost everythingChrome Developers: Chrome DevTools for agents 1.0Anthropic: Introducing the Model Context ProtocolAWS: Agent Toolkit for AWS本文是面向个人开发者和小团队的实用技术向整理，适合作为 AI Agent 工作流入门清单。
AI 行业一周观察：从 Google I/O 到内容溯源，AI 正在从“会聊天”走向“能落地”
最近几天 AI 圈最明显的信号，不是某一个模型参数又涨了多少，而是“大模型开始进入产品、创作工具、搜索、开发者工具和内容可信体系”的速度越来越快。换句话说，AI 仍然在卷能力，但真正值得关注的是：它正在变成基础设施。1. Google I/O 2026：AI 从功能点变成整套产品语言Google 在 I/O 2026 上集中发布了一大批 AI 相关更新，官方甚至整理成了“100 things we announced at I/O 2026”。最值得普通用户关注的，是 AI 不再只是一个单独入口，而是被塞进搜索、购物、创作、工作流、眼镜等场景里。这件事的含义很直接：未来我们接触 AI 的方式，可能不是“打开一个聊天框”，而是在搜索、写文档、剪视频、写代码、逛商品页面时，顺手让 AI 替你完成一段判断、生成或执行。2. 生成内容越来越多，可信来源会变成新刚需OpenAI 最近也在强调内容溯源和真实性问题。随着图片、视频、音频都能被模型高质量生成，“这是谁做的”“有没有被改过”“能不能追踪来源”会越来越重要。这不是一个只属于媒体公司的问题。普通博客、教程站、独立开发者和小团队，未来也会遇到类似需求：当 AI 内容越来越像真人产物时，清楚标注来源、引用、生成方式，反而会成为一种信任资产。 3. Anthropic 收购 Stainless：AI 公司开始补“工程落地”的短板Anthropic 收购 Stainless 也挺有代表性。Stainless 的方向是帮助公司生成和维护 SDK、API 文档等开发者基础设施。这个动作说明一件事：模型公司不仅要拼模型本身，还要让开发者更容易把模型接进真实业务。如果说过去两年 AI 的主角是“模型能力”，那么下一阶段的主角很可能是“可用性”：API 是否稳定，SDK 是否顺手，文档是否清楚，成本是否可控，部署和监控是否成熟。我自己的判断接下来一段时间，AI 行业大概会有三条线并行推进：模型继续升级，多模态、长上下文、Agent 能力都会往前走；大厂把 AI 深度塞进已有产品，普通用户感知会更强；内容可信、开发者工具、企业集成这些“无聊但关键”的基础设施会变得更重要。对普通人来说，最值得关注的不是每天追一个新模型名字，而是观察：哪些 AI 能真正进入自己的工作流，帮你少做重复劳动，或者让原本做不了的事变成可操作。参考链接：Google: 100 things we announced at I/O 2026OpenAI: Advancing content provenanceAnthropic acquires Stainless这是一篇通过数据库直写发布的测试文章，用来验证 Typecho 发文、图片和视频嵌入是否正常。
宝塔面板解决反向代理与SSL冲突的方法
需要注意2点：先申请SSL后再设置反向代理，或者将反向代理暂停后再申请SSL再开启；申请完证书后，通过如下代码将.well-known目录伪静态化，使得该目录可以被外部访问，即可实现自动续签。[hide]location /.well-known/ { }[/hide]
Transfer Files Between Any Devices Using Piping Server-转载
This guide teaches you how to easily and securely transfer files between any devices using Piping Server from command line and via a web browser. You can transfer any kind of data infinitely with Piping Server. It could be a directory, a text file, an audio, video, or anything. Also, It doesn't matter which OS or device you're using. Sharing files with Piping Server is quite easy and straight forward.A brief introduction to Piping ServerPiping Server is a free web service used to share any data between any devices over HTTP/HTTPS. The data can be transferred either from the Terminal using curl program or via a web UI. No sign-up or registration required! You don't even need to install any extra software. All you need is either curl command line program or a modern web browser, which are pre-installed in most operating systems.The Piping Server transfers the data securely with end-to-end encryption. It never stores your data in any central location or public cloud. Piping Server uses peer-to-peer method to relay data from one device to anther.It can able to share data between multiple devices at the same time. Just send a file from one device and receive it from multiple devices. If a file or folder is too big to share, simply compress it and send it.The developer has also created a few more applications and scripts that uses Piping Server:Text stream chatShare Drawing via Piping Server with End-to-End EncryptionTerminal screen sharingPiping UI - A web interface to easily and securely share data between devices over HTTPSPiping-ssh-web - SSH over HTTPS via Piping Server on Web browserPiping-vnc-web - VNC over pure HTTPS via Piping ServerThe link to the aforementioned applications are given in the Piping Server main GitHub repository.Transfer files between any devices using Piping Server from commandlineSharing files between multiples devices with Piping Server is very easy! First, we will see how to share data between two systems using curl program.For example, I am going to share a text file named ostechnix.txt from my Fedora system and receive it in Ubuntu system.On the sender node (i.e. Fedora in my case), type the following command to share the file:$ curl -T ostechnix.txt https://ppng.io/ostechnixNow go to the receiver node (i.e. Ubuntu in my case) and download the file using command:$ curl https://ppng.io/ostechnix > ostechnix.txtIt's that simple. The file will be downloaded in the current directory.Transfer Files Between Any Devices Using Piping Server In LinuxHere, https://ppng.io/ostechnix is the file upload URL. You can use different secret path at the end of this URL. For example, the secret path can be /mymessage or /text123 or anything you want. A sender and receivers who specify the same path can transfer. Both the sender and the recipient can start the transfer first. The first one waits for the other.You can also pipe the contents of a text file and then share it. On the sender node, run the following command to share a text file named ostechnix.txt:$ cat ostechnix.txt | curl -T - https://ppng.io/ostechnixGo to the receiver node and get the above text file using command:$ curl https://ppng.io/ostechnix > ostechnix.txtAs soon as the receiver run the above command in his/her, the shared file will start to download in their system.Here is the sample output. I've shared the oxtechnix.txt file from my Ubuntu system to the Fedora system via Terminal.Transfer Files Between Any Devices Using Piping ServerTransfer directories using Piping ServerIf you want to share a directory, just archive or compress it and share it.Archive a directory using tar and share it using Piping Server:$ tar zfcp - ~/mydirectory | curl -T - https://ppng.io/ostechnixCompress a directory using zip and share it using Piping Server:$ zip -q -r - ~/mydirctory | curl -T - https://ppng.io/ostechnixShare textAs stated already, you can send any kind of data, even text messages. Let us share a text message between two systems.On the sender node, type the following:$ echo "Welcome to OSTechNix" | curl -T - https://ppng.io/ostechnixOn the receiving node, you can get this message by typing the following command:$ curl https://ppng.io/ostechnixShare text between systems using piping serverQuite easy, isn't it? It comes handy when sharing URLs and clipboard between systems.If you want to append the text message to a file, simply do:$ curl https://ppng.io/ostechnix > ostechnix.txtThe above command will save the text in a text file instead of printing in the standard output.Encrypt filesTo encrypt and send files with Piping Server, run:$ cat ostechnix.txt | openssl aes-256-cbc | curl -T - https://ppng.io/ostechnixTo decrypt and download the file:$ curl https://ppng.io/ostechnix | openssl aes-256-cbc -dTransfer files to multiple receivers using Piping ServerIn the above cases, we shared the file to only one recipient. As soon as the recipient, the download link will expire, so you can't download the same file from any other devices.Even if someone tries to access that file, they will get the following message:$ curl https://ppng.io/ostechnix [ERROR] The number of receivers has reached limits.If you want to transfer files to more than receivers, for example 5, use ?n=5 parameter at the end of the URL like below:$ cat ostechnix.txt | curl -T - https://ppng.io/ostechnix?n=5Now the above file can be accessed by 5 recipients (or 5 times in a system) using the following URL:$ curl https://ppng.io/ostechnix?n=5Please note the URL. You must give the exact URL as mentioned in the sender's node. After the file is received by all receivers, the link you will see a successful message in the senders node:[INFO] Waiting for 5 receiver(s)... [INFO] A receiver was connected. [INFO] A receiver was connected. [INFO] Start sending to 5 receiver(s)! [INFO] Sent successfully! [INFO] All receiver(s) was/were received successfully.Transfer files using Piping Server via web browserIf you don't want to receive the file via Terminal, just copy the download URL and paste it in your browser's address bar to download it.Transfer files using Piping Server via web browserTransfer files from Piping Server Web UIAs mentioned already, you can send and receive them either via terminal or a web browser in Unix-like operating systems. If you are not comfortable with command line options or if you are suing other operating systems like Windows, you can use the Piping Server's web UI for transferring files. Piping Server has the following two web interfaces for those who prefers GUI over CLI:https://ppng.io/https://piping-ui.org/ (a more modern UI with encryption option)Go to any one of the above links and choose the file you want to share, enter the secret path, and click Send button. If you use the second UI (i.e. piping-ui), there is an option to password-protect files. Now a file upload URL will be generated. You can use this URL to download the file from any system.Transfer files from Piping Server Web UITo download the file, just paste the URL which you copied in the earlier step in GET tab in Piping Server web interface. You may need enter the passphrase to unlock and download the file.Install Piping Server LocallyCurrently, a few public servers are maintained by the Piping Server developer(s) to transfer files. You can also self-host it using docker or using the portable executable file.If you prefer to use Docker, run the following command to run a local Piping Server instance:$ docker run -p 8080:8080 nwtgck/piping-serverPoint your web browser to http://localhost:8080 URL to access the Piping Server.if you prefer to use portable executable file, download its latest version from the official releases page:$ wget https://github.com/nwtgck/piping-server-pkg/releases/download/v1.1.0/piping-server-linuxMake it executable:$ chmod +x piping-server-linuxAnd run the Piping Server local instance with command:$ ./piping-server-linuxYou can now access the Piping Server web UI from URL http://ip-address:8080.Self Host Piping ServerThere are also a few more ways to deploy Piping Server in your local machine. Refer the project's GitHub link to know how.Getting helpTo display Piping Server help section, run:$ curl https://ppng.io/helpResource:Piping Server GitHub RepositoryRelated read:Share Files Between Multiple Devices Using Snapdrop Via Web BrowserShare Files Between Linux Desktops With WarpinatorPSiTransfer – A Simple Open Source Self-hosted File Sharing SolutionHow to Setup A Basic File server Using simpleHTTPserverAn Easy And Fast Way To Share Files Over Internet From Command LineOnionShare – Share Files Of Any Size Securely And AnonymouslyAirDroid – Access and manage your Android device from Computer