u/superdrizzle7

I understand there has been progress in the area, but I do think we should try to brute force this issue with multiple dev teams. We need hardware acceleration.

Here's my idea we use ffpfs and dont compress it into ffpfsc because the compression is slowing us down. Theoretically we can load a ffpfs file with modified shadowmount and kstuff. Even if we load the game through the current methods it should increase speed with less compression. We can also make ffpfsc files that are only slightly compressed which could increase read speeds.

I recently installed a recommended ps5 m.2 internal gen 4 nvme drive. It was very easy, and its fast, transfer speeds around 700mbs from internal to m.2 drive and Spiderman 2 and Assassin's Creed which were not working previously for me both work now on the m.2. Stability is good on known working games, but I keep a backup drive. Dont be scared.

Some of the problems I was having was with my external drives cable, they were too slow to play some games 150mb/sec and unplugging the drives too much causing kp.

Ive been doing some heavy research and Im confident we can integrate i2p and enhance the security features greatly. Other similar programs have recently integrated i2p, so its definitely possible. Obviously we would want this feature with qbits other awesome features, thats why Im not so excited on just using the other project here https://support.tixati.com/i2p

I like qbit but it has some glaring privacy concerns. I think the community needs to fork it in a security and privacy minded direction. So Ive been looking into it and its possible to have a built in wire guard connection between 2 computers that encrypts all data transfered and also encrypts the ip or uses an untraceable vip. Its possible, its needed. You guys are better devs than I am.

Creating a fork of qBittorrent with a built-in "VPN-like" layer for anonymity is a complex but fascinating engineering challenge. To be clear: qBittorrent is an open-source project written in **C++** using the **Qt** framework and the **libtorrent** library.

To achieve true anonymity and end-to-end encryption between peers within the client itself, you wouldn't just be "skinning" qBittorrent; you’d be modifying how it handles the transport layer.

### 1. Architectural Strategy

You have two main paths to achieve this. One leverages existing privacy networks, while the other creates a custom encrypted overlay.

| Method | Approach | Privacy Level | Performance |

|---|---|---|---|

| **I2P Integration** | Routing traffic through the Invisible Internet Project. | **Very High** (Hidden IP) | Slow (High Latency) |

| **Custom WireGuard/VPN Overlay** | Bundling a VPN client (like WireGuard) into the fork. | **High** (Encrypted Tunnel) | Fast (Low Latency) |

| **Onion Routing (Tor)** | SOCKS5 proxying through the Tor network. | **Extreme** | Very Slow (Not recommended for P2P) |

### 2. Technical Implementation Steps

#### A. Integrating an Anonymity Layer (The "Internal VPN")

Instead of a commercial VPN, you can integrate **I2P** (Invisible Internet Project). I2P was built specifically for anonymous P2P.

* **Modification:** You would modify the session initialization in qBittorrent’s source code to force connections through an I2P SAM (Simple Anonymous Messaging) bridge.

* **Result:** Users get a "b32.i2p" address instead of an IP address. The swarm is completely private from the regular internet.

#### B. Enforcing End-to-End Encryption

While BitTorrent already has "Protocol Encryption" (PE), it is primarily designed to bypass ISP throttling, not for high-level security.

* **The Fix:** In your fork, you should modify the settings to **disable all unencrypted legacy connections**.

* **The Code:** You would hardcode the libtorrent settings:

```cpp

// Example logic for libtorrent settings

settings.set_int(settings_pack::out_enc_policy, settings_pack::pe_forced);

settings.set_int(settings_pack::in_enc_policy, settings_pack::pe_forced);

settings.set_int(settings_pack::allowed_enc_level, settings_pack::pe_rc4);

```

#### C. Network Interface Binding (The "Kill Switch")

A "built-in VPN" must never leak the real IP. You can automate the "Network Binding" feature that already exists in qBittorrent so it happens by default.

* **Logic:** Your fork should detect your specific VPN/Encrypted interface and bind the socket to it. If that interface goes down, the client stops all traffic instantly.

### 3. Engineering Challenges to Solve

* **The "Double Encryption" Overhead:** If you wrap BitTorrent’s RC4 encryption inside a VPN’s AES/ChaCha20 tunnel, CPU usage will spike, especially on older hardware.

* **Peer Discovery:** In a truly anonymous fork, traditional trackers (which log IPs) are a vulnerability. You would need to rely entirely on **DHT (Distributed Hash Table)** and **PEX (Peer Exchange)** over the encrypted tunnel.

* **Exit Nodes:** If users want to download from the "normal" web while being anonymous, your fork would need to manage **proxy chaining**, which significantly complicates the codebase.

### 4. Existing Alternatives to Study

Before you start coding, I highly recommend looking at **Tribler**. It is a research-based BitTorrent client that already has a built-in Tor-like onion routing layers for anonymity. Studying their source code will give you a blueprint for how to handle multi-layered encryption in a P2P environment.

**Would you like me to dive deeper into how to modify the libtorrent session settings specifically for this fork?**