Mirall 是一个开源的、端到端加密的点对点（P2P）文件传输工具，专为传输超大文件（TB级别）而设计。其核心理念是“无云端、无中间商”（No cloud. No middleman.），所有数据直接在设备间传输。
核心设计目标
- 直接传输：文件直接从发送者磁盘传输到接收者磁盘，不经过任何服务器。设备通过全球分布式哈希表（DHT）进行发现，并建立加密连接。
- 极致隐私：所有内容都经过端到端加密。加入一个“空间”（Space）需要通过加密方式批准，新成员会获得该空间的内容密钥，没有密钥则无法读取任何文件列表或数据。
- 为超大文件而生：文件原地共享，无需创建副本或暂存上传。传输过程基于内容寻址，每个数据块都会经过校验，并支持断点续传。
- 本地优先：所有数据持久化存储在本地，即使离线也能正常工作。
✨ 主要功能
- 空间（Spaces）：用于文件共享的私有群组。可以创建空间、发送邀请，并由成员批准加入。
- 灵活的共享方式：支持发布整个文件夹，成员可以浏览并选择下载单个文件，或将整个文件夹“镜像”到本地并保持同步（只读，删除安全）。
- 可靠的传输：支持断点续传，当对方离线时自动暂停，恢复后从中断处继续，无需重新下载已验证的数据。
- P2P 自动更新：应用程序的更新也通过其自身的P2P网络分发。
- 多语言与跨平台：支持 macOS（Apple Silicon 和 Intel）、Windows 10/11 和 Linux（x64 和 arm64），界面提供英语、德语、西班牙语、法语和意大利语。
工作原理
- 发现与连接：每个“空间”是一个256位的随机主题，通过 Hyperswarm DHT 进行发现。成员间通过 Noise 协议 建立加密的套接字连接。
- 内容共享：共享文件时，只广播元数据而非文件本身。文件在本地被哈希后，其条目会进入空间内加密的目录中。只有当有人请求时，文件才会从你的磁盘发出。
- 数据层：其数据层基于 Holepunch 技术栈（包括 Hypercore、Hyperbee 等），在一个独立的 Bare 工作进程中运行，由 Electron 承载。
文件传输的终极骗局：你花大钱上传云端的那几TB数据，其实根本不用经过任何服务器
你发过一个500GB的视频给剪辑师吗？上传一整天，云端提示“传输中断”，从头再来！
Mirall直接把数据从你的硬盘送到对方硬盘，不上传云端，不经过任何服务器，不注册账号。就这么简单。但这么简单的逻辑，整个互联网却花了三十年都没搞明白。
为什么上传到云端再下载成了“标准答案”，而这个答案本身就是错的
先算一笔账。你把一个1TB的项目文件上传到某云盘，上传耗时取决于你的上行带宽。国内家庭宽带的上行速度通常只有下行速度的十分之一，500Mbps的宽带，上行可能只有50Mbps。1TB = 8,000,000兆比特，除以50Mbps = 160,000秒，约44个小时。上传两天，对方再下载两天。一个文件折腾四天。
但这还不是最荒谬的。最荒谬的是——这个上传动作本身，在绝大多数场景下完全多余。
你和一个同事在同一个城市，甚至同一栋楼。你们的电脑都连着互联网。为什么数据要先飞到几百公里外的服务器机房，再飞回来？这就像你给隔壁邻居递一张纸条，非要先寄到省会城市的分拣中心再寄回来。
然而过去十年，整个文件传输行业都在告诉你：上传云端是天经地义的。Dropbox这么说，百度网盘这么说，Google Drive这么说。WeTransfer、奶牛快传，全都这个逻辑。没人质疑，因为“云端”这个词听起来高级，听起来科技。
Mirall的开发者Oliver Kohl是在马略卡电影节上听到一群电影人抱怨这个问题才决定动手的。电影后期制作中，一个项目几百GB甚至几TB的RAW素材、剪辑工程、特效文件，靠云盘传？成本高到离谱，时间慢到崩溃，数据泄露风险还悬在头上。那些大型制片厂有自己的专线传输方案，小型工作室和独立电影人只能硬扛消费级云服务的各种限制。
上传到云端再下载，是一个被商业利益塑造出来的“标准答案”，而不是技术上的必然选择。
点对点传输不是新技术，但Mirall把这个老技术做到了你妈都能用
P2P文件传输，BitTorrent做了二十年。但你见过哪个剪辑师用BT给客户发成片？没有。因为BT的使用门槛太高——要制作种子文件，要配置Tracker服务器，要让对方会下载种子、会用客户端。这一套流程走下来，非技术人员直接放弃。
Mirall做的事，就是把P2P传输的复杂度全部吞掉，外面只露出一个长得像微信聊天群的东西。它管这个叫“空间”（Spaces）。
你打开软件，起个名字，点“创建空间”，生成一个邀请链接。把这个链接发给对方。对方打开链接，申请加入。你点一下“批准”。然后你们俩就在一个私密的虚拟房间里了。
接下来你只需要做一件事——把硬盘上的文件夹拖进这个空间。对方立刻就能看到这个文件夹里的文件列表，选择下载单个文件，或者把整个文件夹“镜像”到自己的电脑上。镜像的意思是：你这边更新了文件，对方那边自动同步。
整个过程不需要注册账号，不需要输入密码，不需要绑定手机号。唯一需要的东西是——你们俩的电脑都得开着机、连着网。
就这么简单。简单到你会反问：为什么之前没人这么做？
数据根本不经过服务器，那加密还有什么意义？意义大了去了
Mirall的宣传语是“No cloud. No middleman.”。没有云端，没有中间人。所有数据从你的硬盘直接传输到对方的硬盘。
但“不经过服务器”不等于“裸奔”。Mirall在传输层做了两件事：
第一，设备发现不走中心化服务器。两台电脑怎么在互联网上找到彼此？Mirall用的是Hyperswarm——一个全球性的分布式哈希表（DHT）。每台电脑加入一个“空间”时，会基于这个空间的加密主题在DHT上做广播。其他拥有相同主题密钥的设备就能发现它。整个过程没有一个中心节点在协调。
第二，连接建立后，所有通信走的是Noise协议框架加密的套接字。Noise是一个现代的加密协议框架，支持前向保密和临时密钥——每次连接的加密密钥都是新生成的，历史会话不会被未来的密钥泄露所威胁。
但最关键的加密设计在这里：加入一个“空间”时，空间创建者批准你的请求，同时把空间的内容密钥交到你手上。没有这个密钥，你连空间里有哪些文件都看不到，其他节点也不会给你发送哪怕一个字节的数据。
这就不是“传输过程加密”了——这是“内容本身加密，密钥单独分发”。即使有人在网络层面截获了你的数据包，看到的也只是一堆密文。即使某个节点被攻破，攻击者拿不到内容密钥也读不了任何文件。
加密发生在数据离开你的硬盘之前，而不是在上传到服务器的路上。
断点续传、原地共享、TB级文件——这些词每个都值钱，但Mirall全给你了
传输1TB文件，最怕什么？传了900GB，断网了。传统的云盘传输，从头再来。Mirall的处理方式是：断点续传。
对方离线了？传输自动暂停。对方重新上线？从中断的地方继续。已经验证过的数据块不再重复下载。传输完成后，系统会把收到的文件与原始文件做逐块比对校验，确认完整性和正确性。
再一个关键词：“原地共享”。传统方式要分享一个文件，你得先把它上传到某个地方——这就产生了一份副本。Mirall不复制文件。你共享的就是你硬盘上那个原始文件，别人下载的时候直接从你的磁盘读取发送。没有暂存区，没有中转文件夹，没有“上传中”的状态条。
文件大小有上限吗？文档上写得很清楚：TB级别的文件是设计目标，不是边缘情况。没有按流量计费，没有文件大小限制。
目前Mirall支持macOS（Apple Silicon和Intel）、Windows 10/11、Linux（x64和arm64）。界面提供英语、德语、西班牙语、法语和意大利语五种语言。
你以为竞争对手是百度网盘？错了，Mirall真正的对手是“什么都不做”
如果只比功能，Mirall的对手是Resilio Sync和Syncthing。这两个也是P2P文件同步工具。
Resilio Sync的前身是BitTorrent Sync，使用BitTorrent协议做设备间文件同步。但它的问题是：核心功能闭源，付费版本才有高级特性。一个闭源的P2P工具，在隐私这件事上本身就打了个折扣。
Syncthing是开源社区为了回应Resilio Sync的闭源而写出来的替代品，MIT许可证。它持续同步文件夹，使用块级别的增量传输和端到端加密。但它有两个问题：第一，配置复杂度高，对非技术人员不友好；第二，它主打的是“持续同步”，而不是“一次性传输大文件”。
Mirall在这两个工具之间找到了一个缝隙：它像Syncthing一样开源（AGPL-3.0） ，像Resilio Sync一样用户友好，但它的核心场景是“发送超大文件”而不是“持续同步文件夹” 。
但Mirall真正颠覆的不是这两个工具。它颠覆的是整个“上传云端再下载”的思维定式。
过去十年，文件传输行业的默认答案一直是“用云”。你遇到任何传输问题，解决方案都是“买个云盘会员”“开个超级会员加速”“升级企业版”。整个行业都在教你为“上传”这个动作付费，却没人告诉你这个动作本身可以不存在。
Mirall的答案是：把文件从A点到B点，最直接的方式就是直接从A点到B点。
但Mirall有一个致命问题，所有P2P工具都有
两台电脑必须在同一时间在线。
这是P2P传输的天然限制。云端上传的好处是：你先上传，对方什么时候下载都行，不需要同时在线。Mirall的模式要求发送方和接收方同时开机、同时联网。
这在团队协作场景下问题不大——大家都在工作时间在线。但对于跨时区、异步协作的场景，这就是个硬伤。
Mirall的解决方案是“断点续传”——对方上线后自动从中断处继续。但这解决的是“传输中断”的问题，解决不了“对方根本不在线”的问题。
目前Mirall官方没有提供“离线中转”或“临时云端缓存”的选项。从架构上看，这违背了它的核心理念。但现实是，有些场景就是需要异步传输。
还有一个问题：Mirall需要两个或以上正在运行的实例才能发挥作用。一个人用不了。这是P2P应用的通病——网络效应。
一个电影剪辑师的真实测试：2TB文件夹，两台笔记本，发生了什么
Product Hunt上有个用户报告：他用Mirall在两台笔记本之间传输了一个2TB的文件夹，速度明显快于他平时的工作流程。
为什么更快？因为没有中间服务器限速。云盘的上传和下载速度受制于服务商的带宽配额和流量策略。P2P传输的速度只取决于两台设备之间的网络吞吐量。
另一个用户评论说：“审批制的空间感觉就像正确的默认设置”。这个细节很重要——很多P2P工具把加密和权限做成可选功能，用户不主动开启就等于裸奔。Mirall把“加密”和“审批”做成默认行为。
Oliver Kohl在Hacker News上发帖说，这个项目是他过去四个月里做出来的。四个月。一个柏林开发者，用Holepunch的Pear框架，搭了一个挑战百亿级云存储市场的工具。
Holepunch是什么？2021年，Hypercore协议团队成立了Holepunch公司，目标是加速实现真正的P2P互联网。这家公司的背后支持者是Tether（USDT发行商）和Bitfinex（加密货币交易所）。他们做的第一个产品是Keet——一个P2P加密通信应用。Mirall用的就是Keet同款底层技术。
一个靠稳定币和交易所养着的P2P技术栈，孵化出了一个挑战云存储的文件传输工具。这件事本身就挺有意思。
技术再好，也绕不开一个根本问题：你的上行带宽够吗？
Mirall绕开了云服务器，绕不开物理定律。
你的上行带宽，决定了你发送文件的速度。如果家里的宽带上行只有30Mbps，传1TB还是要70多个小时。Mirall不能帮你变出带宽来。
但它能做两件事：第一，不占用你的上行带宽去做“上传到云端”这个多余动作——省下的就是纯赚的；第二，如果对方和你在同一个局域网，传输走内网，速度直接跑满千兆甚至万兆。
第二点被严重低估了。想象一下：办公室里有五个人，都需要拿到同一个50GB的项目文件。传统方式：一个人上传到云盘（占用上行带宽），另外四个人分别从云盘下载（各占用下行带宽，而且云盘服务商限速）。Mirall的方式：一个人共享文件夹，另外四个人直接从他的电脑下载。如果大家都在同一个局域网，传输速度是交换机决定的，不是互联网带宽决定的。
这就是“原地共享”的威力。文件不离开局域网，速度不受互联网带宽限制，数据不经过任何第三方服务器。
最后说一个让人睡不着觉的实验细节
Mirall的自动更新功能，走的也是P2P网络。软件更新包通过同样的点对点网络分发，不经过中央更新服务器。
这意味着什么？意味着整个Mirall生态系统——软件本身、用户数据、文件传输、版本更新——全部跑在P2P网络上，没有一个中心节点是单点故障。
但这也意味着：如果整个网络里没有任何一个节点在运行某个版本的Mirall，新用户就下载不到这个版本。P2P网络的冷启动问题，在这里一样存在。
Oliver Kohl在Hacker News上说：“希望它能解决你们很多人的问题”。这句话的背后是一个未被回答的问题：如果有一天开发者的服务器关了，Mirall还能独立存活多久？
一个完全去中心化的文件传输工具，它的生死却不完全掌握在用户手里——因为虽然传输是P2P的，但首次下载和初始发现仍然依赖中心化的入口（官网、GitHub Release）。