近日，一封来自印度内政部下属网络犯罪机构的正式通知，悄无声息地穿过监管系统，落在了全球最大的代码托管平台之一 GitHub 桌面上。通知明确援引《IT法》第79(3)(b)条，直接点名由 Jack Dorsey 支持的离线通信与比特币交易工具 Bitchat，要求平台在3小时内移除该项目的三处代码仓库。Bitchat依靠蓝牙网状网络在设备间建立点对点链接，用户无需传统账户注册，通过加密消息与比特币交易完成交互，这种“脱离互联网、脱离账户、脱离可见身份”的技术路径，被印度官方在通知中概括为“阻碍合法监听与溯源”的工具类型，从而被纳入需要审查乃至下架的对象。过去，《IT法》第79条更多出现在打击虚假信息、仇恨言论和违法内容的场景，用来划定中介平台的删除义务与责任豁免边界，如今同一条款被用来要求代码托管平台在极短时间内处理一个加密通信与比特币工具的源代码，使GitHub在印度被清晰地归类为必须服从删除指令才能维持中介豁免的主体。置于近年来印度频繁的网络与数据管控背景下，这一针对源代码的执法动作，将离线加密工具与主权监管、合法监听诉求直接撞在一起，也给所有在印度司法辖区内运营或被访问的代码托管平台和隐私型加密项目敲响了警钟：它们正在进入一个合规门槛更高、审查窗口更快、更容易被纳入安全审查的监管新阶段。
印度动用IT法79条：从假信息到加密通信
在这次对Bitchat代码动刀之前，《IT法》第79条一直是印度处理中介平台责任的“安全阀”。条文一方面承认社交网络、视频平台乃至代码托管服务只是“中介”，只要履行政府要求的尽职义务，就可以享受责任豁免；另一方面又在79(3)(b)中埋下强制开关：只要主管部门发出通知，中介就必须在限定时间内删除指定内容，否则豁免失效、责任自负。过去，这一机制主要被用在传统互联网场景——打击仇恨言论、违法内容、虚假信息传播，中介只要快速配合删帖、封号，就能留在“合法服务”的一侧。
对Bitchat的通知，标志着79(3)(b)第一次被明确伸向“加密通信工具本身”。内政部下属网络犯罪机构直接把GitHub认定为《IT法》意义上的中介，要求其在3小时内移除三处Bitchat代码仓库，并在通知中引用“阻碍合法监听与溯源”作为理由。监管逻辑从“删除有问题的信息”，走到了“删除承载信息的工具”：Bitchat依托蓝牙网状网络实现离线设备通信，不需要传统账户注册，用户以加密消息和比特币交易交互，这种既脱离互联网、又削弱身份绑定的设计，正好踩中了印度近年来不断强化网络与数据控制、强调可监听、可溯源的红线。在这样的思路下，选择由Jack Dorsey支持、功能集中于离线通信与交易的Bitchat作为技术审查对象，是监管机构发出的一个清晰信号：只要被视为削弱国家在信息流和资金流上的监控能力，哪怕还停留在源代码阶段，也会被纳入79(3)(b)的快速下架链条之中。
Bitchat离线比特币通信踩中监管红线
Bitchat的设计几乎是反向对着监管清单逐条拆除：用户进入系统不需要传统意义上的账户注册，没有手机号、电子邮件、实名信息这些常见的身份锚点，设备之间通过蓝牙构建离线网状网络，消息可以在一条条“人肉基站”之间跳转，而不必碰触任何运营商基站或互联网服务节点。更关键的是，它把加密消息传递和比特币交易绑在一起，聊天界面本身就是资金交互的入口，在一个统一的通道里完成信息和价值的同步流动。这种“离线 + 去账户 + 信息与交易捆绑”的组合，让项目在技术层面看上去只是一个由Jack Dorsey支持的实验性工具，却天然具备绕开传统通信和支付体系的能力。
对印度监管者而言，这套能力直接指向他们最在意的三根“安全支柱”：身份识别、流量监控和交易溯源。没有注册流程，就难以将具体行为人锁定在可被问责的账户之下；蓝牙网状网络绕开电信和互联网基础设施，意味着传统依赖运营商、ISP日志进行的流量取证和态势感知被削弱；而加密消息与比特币交易的结合，则让信息内容与资金流在同一通路中交织，增加了分拆、追踪单一维度证据的难度。在这样的风险叙事下，印度官方在通知中以“阻碍合法监听与溯源”为由，将Bitchat一类离线加密工具归入IT法第79(3)(b)下的高风险目标，不再只关注传播什么内容，而是开始针对“天生削弱国家监控能力”的技术形态本身划定新的监管红线。
GitHub中立性被撕裂成监管前线
在印度《IT法》的语境下，GitHub原本被视作典型的技术中介服务提供者：只托管代码，不对具体项目的用途作价值判断，依靠第79条的责任豁免维持“技术中立”身份。但当内政部下属网络犯罪机构在通知中明确援引第79(3)(b)条，要求其在3小时内删除三处与Bitchat相关的代码仓库，这种中立空间被迅速压缩，中介平台一旦不按要求执行删除，就可能失去豁免地位，转而承担潜在法律责任。法律条文原本主要用于应对虚假信息和违法内容，如今却直接作用于一类“削弱监听与溯源能力”的技术形态，GitHub不得不在印度境内从被动托管者转身为执行监管命令的前线节点。
3小时的下架时限，本身就是对全球开源协作节奏的重构信号。对于跨时区维护的加密与隐私项目来说，这意味着监管通知不再是可以慢慢协商、评估的“合规工单”，而更像随时可能触发的紧急断流开关：平台极难在如此短的窗口内核查项目的技术细节，更不可能组织充分的法律抗辩，只能优先保护自己的责任豁免。结果是，代码平台在遵守当地法律与维护代码自由之间形成新的张力——若一味快速配合删除，将削弱开发者对平台“只做托管、不做裁判”的信任；但若选择延迟执行或公开对抗，则必须面对被认定为不合规中介的风险。围绕这种选择困境，日后每一次类似通知都会在平台与开发者之间刻下一道裂缝，逼迫双方重新定义“开源代码可以被托管到何种程度”的边界。
印度开发者与比特币项目面临的新合规门槛
在印度这样既拥有庞大开发者群体又有活跃加密用户市场的环境里，内政部网络犯罪机构这次动用《IT法》第79(3)(b)点名 Bitchat，并要求 GitHub在极短时间内移除相关仓库，相当于对本地技术社群发出了一个清晰信号：去中心化、隐私强化的比特币工具不再只是“中立代码”，而是可能被视为“阻碍合法监听与溯源”的审查对象。过去第79条更多被用来处理虚假信息、仇恨言论等传统内容风险，如今却直接延伸到离线通信与比特币交易的开源项目，使得印度开发者在设计蓝牙网状网络、端到端加密和免账户注册等功能时，必须预先假设“代码一旦被认定影响执法能力，就可能被要求下架”，合规不确定性被显著拉高。
在项目层面，这意味着围绕代码公开程度、节点分布位置以及为用户保留多少匿名空间，每一个技术选择都被重新纳入风险权衡：仓库继续托管在 GitHub 等中心化平台上，能换取协作效率和全球贡献者，但也更容易直接落入《IT法》下的中介删除链路；若将通信和交易逻辑拆得更分散、尽量减少对单一托管平台的依赖，则在提高抗封锁能力的同时，也需要思考是否会被监管视为有意“规避中介责任”的架构设计。对终端用户而言，看到一个由 Jack Dorsey 支持、提供离线比特币交易与通信功能的开源项目被官方点名，他们可能会更早考虑迁移到其他工具，或在获取和更新代码时转向更分散的分发方式，以降低因平台接到删除通知而突然失去访问入口的风险，而这种预防性迁移正是在印度监管边界收紧后开发者与用户共同面临的新现实。
离线加密通信与主权监管的持久战
印度此次借《IT法》第79(3)(b)条向 GitHub 发出下架通知，把原本主要用于虚假信息、违法内容治理的中介责任条款，第一次有针对性地压到一类“阻碍合法监听与溯源”的离线加密通信工具头上，同时也把代码托管平台拉入技术审查的正面战场，这一动作事实上把离线网状网络、端到端加密与比特币交互工具纳入主权监管的优先问题清单。事件发生在印度多次断网、不断强化数据与信息控制的政策脉冲之后，对全球开发者和隐私技术社区释放的信号是：只要被认定影响国家对信息流的掌控，中介平台与工具开发者都可能被要求在极短时间窗口内配合删除或限制传播。接下来，其他司法辖区会如何回应这种平台责任模式，将成为下一轮博弈的关键变量——部分国家可能参照印度做法，把代码托管方视作必须主动过滤“不可监听”的工具，也可能有监管者刻意与之保持距离，以维护源代码和通信技术的开放边界，但无论是哪种路径，对比特币相关的离线支付与通信生态都会形成连锁反应，从项目选址、代码托管到用户获取方式都将不得不重新评估合规暴露面。目前公开报道中尚未出现 GitHub 或 Bitchat 团队的详细官方回应，印度方面后续是否会扩大同类通知、是否会在法院层面接受对《IT法》适用范围及中介责任边界的挑战，都是仍然空缺的坐标点，在这些时间点与变量明朗之前，离线加密通信与主权监管的拉锯战只会在不确定中持续延长。
加入我们的社区，一起来讨论，一起变得更强吧！
AiCoin专属Hyperliquid福利：https://app.hyperliquid.xyz/join/AICOIN88
AiCoin专属Aster福利：https://www.asterdex.com/zh-CN/referral/9C50e2
链上电报（Telegram）社群：https://t.me/AiCoinWhaleData
链上社区：https://www.aicoin.com/link/chat?cid=N6OVMor5g
AiCoin链上推特：https://x.com/aicoinwhaledata
免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。
