India Orders GitHub to Remove Jack Dorsey’s Bitchat Repositories Under IT Act

The CyberSec Guru

Updated on:

If you like this post, then please share it:

Buy me A Coffee!

Support The CyberSec Guru’s Mission

🔐 Fuel the cybersecurity crusade by buying me a coffee! Why your support matters: Zero paywalls: Keep the main content 100% free for learners worldwide.

“Your coffee keeps the servers running and the knowledge flowing in our fight against cybercrime.”☕ Support My Work

Buy Me a Coffee Button

The Indian government has directed GitHub to remove public repositories associated with Bitchat, the decentralized Bluetooth mesh messaging application created by Jack Dorsey through his Permissionless Technologies initiative. The order, issued by the Indian Cyber Crime Coordination Centre (I4C) under the Ministry of Home Affairs (MHA), requires GitHub to disable access to three repositories within three hours under India’s intermediary liability framework.

Unlike previous takedown orders involving websites, social media posts, or mobile applications, this notice specifically targets the open-source code repositories that host Bitchat itself. That distinction makes the action particularly noteworthy. Rather than blocking access to a deployed service, the government has instructed an intermediary to remove the software’s publicly accessible source code hosted on GitHub.

The official notice, dated 23 July 2026, invokes Section 79(3)(b) of the Information Technology Act, 2000, read together with Rule 3(1)(d) of the Information Technology (Intermediary Guidelines and Digital Media Ethics Code) Rules, 2021. According to the document, GitHub, as an intermediary, must disable access to the identified repositories while preserving evidence related to the hosted content.

The repositories identified in the notice include:

  • permissionlesstech/bitchat
  • permissionlesstech/bitchat-android
  • permissionlesstech/bitchat-android/releases

Screenshots of the notice were later shared publicly by Jack Dorsey, drawing widespread attention from developers, privacy advocates, and the cybersecurity community.

Here’s a mirror to the source code of bitchat: Bitchat Source

The Government’s Reasoning

The official notice provides considerably more detail than a typical takedown request. Rather than simply identifying allegedly unlawful content, it explains why authorities believe the underlying technology presents challenges for law enforcement.

According to the notice, Bitchat enables decentralized peer-to-peer communication over Bluetooth mesh networks without relying on mobile operators, internet connectivity, or centralized servers. It further states that the application does not require mandatory user registration, phone number verification, or centralized logging of communications.

From the government’s perspective, these characteristics significantly impede lawful interception, subscriber attribution, and criminal investigations because there is no central service provider capable of producing subscriber records, server-side logs, communication metadata, or stored messages in response to lawful requests.

The notice also argues that decentralized communication platforms could be misused during situations involving public disorder, organized crime, terrorism, riots, misinformation campaigns, and internet shutdowns because communications can continue without dependence on conventional telecommunications infrastructure.

It is important to note that these statements represent the rationale presented by the Indian government in its official notice. They should not be interpreted as evidence that Bitchat has been used unlawfully in any particular case.

The legal foundation for the notice rests primarily on Section 79 of the Information Technology Act, 2000, which grants intermediaries conditional protection from liability for third-party content hosted on their platforms.

This protection, commonly referred to as “safe harbor,” is not absolute.

Section 79(3)(b) states that once an intermediary receives actual knowledge through a lawful court order or a notification issued by an authorized government agency, it must act expeditiously to remove or disable access to the specified information. Failure to do so may result in the intermediary losing its statutory protection for that content.

The order also cites Rule 3(1)(d) of the Information Technology Rules, 2021. This provision requires intermediaries, upon receiving a valid reasoned intimation from an authorized government agency, to remove or disable access to unlawful information within the prescribed time while preserving evidence.

Additionally, the notice references Sections 43, 84B, and 84C of the Information Technology Act along with Sections 61, 196, and 197 of the Bharatiya Nyaya Sanhita, 2023, stating that the repositories contain information prohibited under Indian law.

Whether GitHub removes the repositories globally or limits access only within India remains to be seen. GitHub’s published Government Takedown Policy explains that when it receives legally valid government requests, it generally attempts to geographically restrict access where possible, while notifying affected repository owners and publishing the requests through its transparency process.

What Makes Bitchat Different?

Understanding the government’s concerns requires understanding how Bitchat actually works.

Bitchat Interface

Nearly every modern messaging platform depends on centralized infrastructure.

Applications such as WhatsApp, Signal, Telegram, Messenger, and iMessage all require servers that authenticate users, maintain account information, distribute cryptographic keys, synchronize conversations, and determine where messages should be delivered. Even if message contents are protected by strong end-to-end encryption, the infrastructure responsible for transporting those messages remains centralized.

Whenever a WhatsApp message is sent, for example, the encrypted payload still passes through Meta-operated servers before reaching the recipient. Signal follows a similar model using Signal-operated servers. These providers generally cannot read encrypted message contents, but they remain responsible for routing communications and maintaining essential network infrastructure.

Bitchat was designed to remove that dependency almost entirely.

Instead of routing traffic through internet-connected servers, every smartphone running Bitchat becomes part of the network itself. Each device simultaneously functions as a messaging client and as a relay capable of forwarding encrypted packets for other nearby users.

Rather than asking a server where another user is located, devices discover one another directly using Bluetooth Low Energy (BLE).

Bluetooth Low Energy: The Foundation of the Network

Bluetooth Low Energy, commonly known as BLE, was originally designed for low-power wireless communication between nearby devices such as smartwatches, wireless sensors, medical equipment, and IoT devices.

How Bitchat Works

Unlike traditional Bluetooth Classic, which focuses on maintaining continuous high-bandwidth connections for audio or file transfers, BLE emphasizes minimal power consumption and short bursts of data exchange.

Devices continuously broadcast small advertising packets announcing their presence. Nearby devices scan for these advertisements and establish connections when compatible services are detected.

Bitchat builds its networking model on top of this discovery mechanism.

Instead of discovering a smartwatch or wireless keyboard, a Bitchat client discovers another nearby Bitchat client advertising its presence over BLE.

Once neighboring devices discover one another, encrypted packets can begin flowing directly between them without requiring Wi-Fi, cellular data, DNS resolution, or internet access.

The communication never leaves the local radio environment.

Building a Mesh Network

The real innovation lies in what happens after two devices establish contact.

Conventional Bluetooth communication is usually point-to-point. Device A connects directly to Device B, exchanges data, and the communication session ends.

Bitchat extends this concept into a mesh network.

Every participating device acts as an independent forwarding node. When a user sends a message that cannot reach its destination directly, neighboring devices automatically relay the encrypted packet onward until it reaches the intended recipient.

Instead of following the familiar client-server model,

Alice → Internet → Server → Bob

communication becomes a chain of local wireless hops:

Alice → Device B → Device C → Device D → Bob

Each relay simply forwards encrypted packets to neighboring devices.

There is no master server coordinating routes.

There is no cloud infrastructure determining the optimal communication path.

Instead, routing decisions emerge dynamically as devices discover nearby peers.

If a participant leaves the area, new paths are automatically established through other nearby devices.

Because every smartphone can function as a relay, communication distance becomes significantly greater than Bluetooth’s normal operating range. Individual Bluetooth links may only span tens of meters depending on environmental conditions, but messages can travel much farther by hopping across multiple participating devices. Public documentation for Bitchat describes messages propagating across multiple relay hops, with devices extending the network for one another.

Packet Forwarding and Network Routing

Unlike internet routing protocols that rely on routers maintaining large routing tables, Bluetooth mesh networks operate quite differently.

When Bitchat generates a message, it encapsulates the encrypted payload into packets containing metadata required for forwarding. These packets include unique identifiers and a Time-To-Live (TTL) value that limits the maximum number of relay hops.

Each relay device maintains a short-term cache of recently processed packet identifiers.

When a packet arrives, the device first determines whether it has already forwarded that packet. If it has, the duplicate is discarded to prevent endless forwarding loops.

If the packet is new and its TTL has not expired, the relay decrements the TTL value before rebroadcasting the encrypted packet to neighboring nodes.

This process continues until either the destination receives the message or the TTL reaches zero.

The mechanism is conceptually similar to packet propagation techniques used in other decentralized mesh networking systems and prevents broadcast storms from consuming excessive wireless bandwidth.

Why No Internet Is Required

The most striking aspect of Bitchat is that the internet becomes optional rather than essential.

Bitchat vs Traditional Communication Apps

Traditional messaging applications require several pieces of infrastructure before a single message can be exchanged. A device typically needs an IP address, DNS resolution, connectivity to remote servers, and authentication with an online service provider.

Bitchat eliminates each of these requirements for nearby communication. Messages move exclusively through Bluetooth radio transmissions between neighboring devices. Since no internet gateway participates in message delivery, communications remain possible even when cellular service is unavailable or internet connectivity has been intentionally disabled.

This architectural decision has attracted growing attention globally as governments increasingly impose temporary internet shutdowns during elections, civil unrest, and political crises. Reuters previously reported increased adoption of Bitchat in countries including Uganda and Iran, where users sought alternatives during internet restrictions.

Current project documentation also indicates that newer versions of Bitchat support an optional decentralized transport using the Nostr protocol when internet connectivity is available. In that model, Bluetooth mesh remains the preferred local transport, while Nostr relays can extend communication beyond local radio range without depending on a single centralized messaging provider. The application can queue messages until either Bluetooth peers or Nostr relays become available, allowing communications to resume automatically when connectivity returns.

Why This Architecture Concerns Law Enforcement

The same characteristics that make decentralized mesh messaging attractive from a resilience and privacy perspective also create challenges for traditional digital investigations.

Most online investigations begin by identifying service providers. Investigators may obtain subscriber information, account registration records, IP address logs, login histories, message routing metadata, or cloud backups through lawful legal processes.

In Bitchat’s architecture, much of that infrastructure simply does not exist. There is no central authentication server maintaining account databases. There are no phone numbers tied to user identities. There is no cloud service responsible for storing communication histories, and no centralized routing server maintaining records of which users exchanged messages.

Consequently, investigators cannot rely on conventional provider-based evidence collection techniques. Instead, investigations must shift toward endpoint forensics, physical device seizures, Bluetooth traffic analysis, and other evidence sources located closer to the communicating devices themselves.

This distinction forms the foundation of the concerns expressed in the government’s notice and explains why the architecture itself, rather than any specific message exchanged through it, became the focus of the takedown order.

Security Model: Privacy by Removing Centralized Infrastructure

Most secure messaging applications focus on encrypting communications while continuing to rely on centralized infrastructure for account management and message routing. Services such as Signal and WhatsApp use strong end-to-end encryption, ensuring providers cannot ordinarily read message contents, yet their servers still authenticate users, distribute cryptographic material, route messages, and maintain limited operational metadata necessary for service delivery.

Bitchat takes a different approach by attempting to minimize the role of infrastructure altogether. Rather than relying on servers to coordinate communications, devices discover one another locally over Bluetooth Low Energy and exchange encrypted packets directly. Since there is no central server responsible for storing conversations or maintaining user accounts, there is also no central database that could be compelled to disclose message histories or subscriber information.

Current public documentation indicates that the application encrypts communications before they are transmitted across the mesh. Relay devices forward encrypted packets without needing access to their plaintext contents. Their primary role is to move packets through the network rather than interpret or process the underlying messages. This approach resembles the forwarding behavior seen in several peer-to-peer networking systems, where intermediary nodes facilitate transport while remaining largely unaware of the information they carry.

Unlike traditional messaging services, Bitchat also avoids mandatory registration using phone numbers or email addresses. Devices generate their own local identities rather than relying on subscriber databases maintained by a service provider. Consequently, there is no equivalent of a centralized customer directory linking users to verified personal information.

Decentralization Does Not Mean Anonymous in Every Situation

The absence of centralized infrastructure should not be confused with complete anonymity.

Although Bitchat reduces the amount of information stored by service providers, participating devices still emit Bluetooth radio signals that can be detected by nearby hardware. Bluetooth transmissions contain protocol-level information necessary for establishing wireless communication, and forensic investigators equipped with specialized radio equipment may be able to observe aspects of nearby wireless activity depending on the circumstances.

Likewise, the communicating devices themselves remain valuable sources of evidence. A smartphone seized during an investigation may contain locally stored conversations, cached message fragments, cryptographic material, application databases, timestamps, or other artifacts useful for forensic analysis. The exact data available depends on how the application stores information locally and whether messages have been deleted or securely erased.

Consequently, decentralized messaging changes where evidence is collected rather than eliminating digital evidence altogether.

Digital Forensics in a Decentralized Network

Traditional cloud-based messaging investigations often begin by serving legal requests to a service provider. Investigators may obtain subscriber information, IP addresses, account registration records, login histories, message routing metadata, or cloud backups through established legal processes.

That investigative workflow becomes substantially more difficult when no centralized provider exists.

Instead, investigators must increasingly rely on endpoint forensics. Modern forensic tools are capable of examining application databases, encrypted storage containers, notification artifacts, operating system logs, Bluetooth pairing information, and other residual evidence preserved on individual devices. Depending on implementation details, investigators may also recover deleted artifacts through file system analysis or examine volatile memory if devices are acquired while powered on.

Bluetooth traffic itself may also become an evidentiary source. Specialized monitoring equipment can capture radio transmissions within physical range, although encrypted payloads remain protected unless investigators possess the appropriate cryptographic material or can otherwise lawfully access decrypted data from an endpoint.

Physical surveillance also becomes more significant. Since Bluetooth communication occurs only across relatively short distances, investigators may focus on identifying individuals physically present within a particular area rather than tracing internet-based communications across telecommunications infrastructure.

These techniques are generally more resource-intensive than obtaining centralized server records, helping explain why law enforcement agencies view decentralized networking architectures as operationally challenging.

Why Internet Shutdowns Remain a Major Concern

One of the government’s central arguments concerns Bitchat’s ability to continue functioning during internet disruptions.

Traditional messaging platforms depend upon remote infrastructure. Even if users remain physically close to one another, communication generally stops when internet connectivity becomes unavailable because messages cannot reach centralized servers responsible for routing traffic.

Bitchat’s Bluetooth mesh architecture removes that dependency.

As long as participating devices remain within relay distance of one another, encrypted messages can continue propagating through the local mesh without relying on mobile operators, Wi-Fi networks, or internet service providers.

This capability has attracted interest beyond India. During previous internet shutdowns and periods of network disruption, decentralized communication applications have periodically gained attention because they allow nearby users to continue exchanging information despite broader connectivity failures. Supporters argue that such capabilities are valuable during natural disasters, humanitarian emergencies, and infrastructure outages where conventional communications become unavailable. Governments, however, have also expressed concerns that the same resilience may complicate lawful efforts to restrict communications during situations involving public safety or national security.

The technology itself is neutral. Its societal impact depends largely on how it is used.

Why GitHub Received the Notice

The government notice is directed toward GitHub because GitHub operates as the intermediary hosting the repositories identified in the order.

Under India’s intermediary liability framework, online platforms may retain statutory protection from liability for third-party content provided they comply with applicable legal obligations. Section 79 of the Information Technology Act establishes this safe harbor while also requiring intermediaries to act upon lawful government notifications.

GitHub therefore becomes responsible for determining how to respond to legally valid requests issued by governments operating within their jurisdictions.

Historically, GitHub has published many government takedown requests through its transparency reporting process. Depending on applicable law and the scope of the request, GitHub has sometimes restricted repository access only within a specific country rather than removing content globally. Repository owners are also generally notified unless prohibited by law, allowing them to understand the legal basis for the restriction and, where appropriate, challenge the request through available legal mechanisms.

Whether access to the Bitchat repositories is ultimately blocked only within India or removed more broadly depends on GitHub’s legal assessment of the notice and any subsequent developments.

A Growing Regulatory Challenge

The Bitchat case reflects a broader shift occurring across the technology industry.

For decades, governments developed lawful interception frameworks around centralized service providers. Telecommunications companies, internet service providers, email platforms, and cloud services all maintain infrastructure through which communications pass. This architecture provides identifiable organizations capable of responding to lawful court orders and government requests.

Decentralized software challenges that assumption. Projects built around peer-to-peer networking, distributed identity systems, blockchain technologies, federated services, and mesh communication intentionally reduce reliance on centralized infrastructure. In many cases, there is no single organization controlling message routing or storing communications.

This creates an increasingly complex regulatory landscape. Existing legal frameworks often assume that an identifiable service provider exists somewhere within the communication chain. As decentralized architectures become more common, policymakers around the world will likely continue examining whether existing laws remain adequate or whether new regulatory approaches are required.

The Bitchat notice illustrates that this debate has already moved beyond theory. Governments are now applying existing intermediary liability provisions to open-source repositories hosting decentralized communication software.

Balancing Privacy and Public Safety

The debate surrounding Bitchat extends well beyond a single application.

Privacy advocates generally argue that decentralized communication strengthens civil liberties by reducing surveillance risks, eliminating centralized data collection, and improving resilience during emergencies. From this perspective, removing single points of failure improves both privacy and network reliability.

Law enforcement agencies view the issue through a different lens. Investigators frequently depend upon subscriber information, provider logs, and communication metadata to identify suspects, reconstruct criminal activity, and prevent serious offences. When communications occur without centralized infrastructure or mandatory user identification, many established investigative techniques become substantially more difficult.

Neither position eliminates the other.

Strong privacy protections and effective criminal investigations have long existed in tension, and advances in cryptography and decentralized networking continue to reshape that balance. The Bitchat case represents another example of this ongoing technological and legal evolution.

Conclusion

India’s order directing GitHub to remove repositories associated with Bitchat is significant not only because it targets an open-source project, but because it reflects the growing intersection of decentralized technologies, cybersecurity, digital privacy, and national security policy.

According to the official notice issued by the Indian Cyber Crime Coordination Centre, Bitchat’s Bluetooth mesh architecture, absence of mandatory user registration, lack of centralized logging, and ability to function independently of internet connectivity create substantial challenges for lawful interception and criminal investigations. Acting under Section 79(3)(b) of the Information Technology Act and Rule 3(1)(d) of the Information Technology Rules, the government instructed GitHub to disable access to three repositories associated with the project.

From a technical perspective, Bitchat demonstrates how advances in Bluetooth mesh networking and decentralized communication are changing the assumptions that have historically underpinned internet services. By eliminating centralized servers, the software reduces dependence on traditional infrastructure while simultaneously altering the methods available for digital investigations. Although endpoint forensics, radio analysis, and physical evidence collection remain viable investigative techniques, the absence of centralized service providers fundamentally changes how evidence is obtained.

Whether similar technologies become more common will depend on both technological adoption and future regulatory responses. As decentralized applications continue to evolve, governments, developers, courts, and civil society are likely to face increasingly complex questions about how to balance privacy, resilience, open-source innovation, and legitimate public safety concerns. The Bitchat takedown is therefore more than an isolated repository removal—it marks another milestone in the ongoing debate over the future of secure, decentralized communications.

Buy me A Coffee!

Support The CyberSec Guru’s Mission

🔐 Fuel the cybersecurity crusade by buying me a coffee! Your contribution powers free tutorials, hands-on labs, and security resources.

Why your support matters:
  • Writeup Access: Get complete writeup access within 12 hours
  • Zero paywalls: Keep the main content 100% free for learners worldwide

Perks for one-time supporters:
☕️ $5: Shoutout in Buy Me a Coffee
🛡️ $8: Fast-track Access to Live Webinars
💻 $10: Vote on future tutorial topics + exclusive AMA access

“Your coffee keeps the servers running and the knowledge flowing in our fight against cybercrime.”☕ Support My Work

Buy Me a Coffee Button

If you like this post, then please share it:

News

Discover more from The CyberSec Guru

Subscribe to get the latest posts sent to your email!

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Discover more from The CyberSec Guru

Subscribe now to keep reading and get access to the full archive.

Continue reading