Merge pull request titaniumnetwork-dev#19 from Riftriot/master

Finish up wisp docs, update UV docs, remove useless text on ultraviolet releases, remove flowos
mdoryammilwalrus · Apr 21, 2024 · 4923782 · 4923782
2 parents dee9d80 + 7c19103
commit 4923782
Show file tree

Hide file tree

Showing 10 changed files with 20,394 additions and 2,727 deletions.
diff --git a/.yarn/install-state.gz b/.yarn/install-state.gz
diff --git a/.yarnrc.yml b/.yarnrc.yml
@@ -0,0 +1 @@
+nodeLinker: node-modules
diff --git a/docs/guides/nginx.mdx b/docs/guides/nginx.mdx
@@ -77,20 +77,33 @@ http {
         listen [::]:80 default_server;
         server_name your.domain.com; # replace with your actual domain
 
-        location / {
-                # Upgrade WebSockets
-                proxy_set_header Upgrade $http_upgrade;
-                proxy_set_header Connection 'Upgrade';
-                # Increase header buffer
-                proxy_connect_timeout 10;
-                proxy_send_timeout 90;
-                proxy_read_timeout 90;
-                proxy_buffer_size 128k;
-                proxy_buffers 4 256k;
-                proxy_busy_buffers_size 256k;
-                proxy_temp_file_write_size 256k;
-                proxy_pass http://127.0.0.1:8080; # change this to the port UltraViolet is listening on
+        location /wisp {
+            proxy_pass http://127.0.0.1:8080; # change this to the port of your wisp server. i reccomend epoxy-server for optimal speed and performance.
+            proxy_http_version 1.1;
+            proxy_set_header Upgrade $http_upgrade;
+            proxy_set_header Connection "Upgrade";
+            proxy_set_header Host $host;
+            proxy_set_header X-Real-IP $remote_addr;
+            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
+            proxy_set_header X-Forwarded-Proto $scheme;
+        }
 
+        location / {
+            proxy_pass http://localhost:8081; # change this to the port of your proxy service
+            proxy_set_header Host $host;
+            proxy_set_header X-Real-IP $remote_addr;
+            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
+            proxy_set_header X-Forwarded-Proto $scheme;
+            proxy_set_header Upgrade $http_upgrade;
+            proxy_set_header Connection 'Upgrade';
+            # Increase header buffer
+            proxy_connect_timeout 10;
+            proxy_send_timeout 90;
+            proxy_read_timeout 90;
+            proxy_buffer_size 128k;
+            proxy_buffers 4 256k;
+            proxy_busy_buffers_size 256k;
+            proxy_temp_file_write_size 256k;
             # The small block below will block googlebot
             if ($http_user_agent ~ (Googlebot)) {
                 return 403;

diff --git a/docs/index.mdx b/docs/index.mdx
@@ -191,7 +191,7 @@ Titanium Network is composed of various open-source projects hosted in productio
 
 - [Anura OS](https://anura.pro/)
 - [Holy Unblocker](https://holyubofficial.net/)
-- [Flow Works](https://flow-works.me/)
+- [Nebula](https://nebulaproxy.io/)
 - [Kazwire](https://kazwire.com/)
 - [Ludicrous](https://ludicrous.icu/)
 - [DNS Setup](https://radon.games/)

diff --git a/docs/proxies/ultraviolet.mdx b/docs/proxies/ultraviolet.mdx
@@ -37,11 +37,11 @@ title: Ultraviolet
 
 <img width="200px" align="right" src="https://raw.githubusercontent.com/titaniumnetwork-dev/Ultraviolet-Static/main/public/uv.png" height="250"></img>
 
-Ultraviolet is a highly advanced web proxy used for evading internet censorship or accessing websites in a controlled sandbox. It is designed with security and performance in mind. Ultraviolet intercepts HTTP requests with a service worker, while adhering to the [TompHTTP specifications](https://github.com/tomphttp) and is a leader in innovative web proxy technologies.
+Ultraviolet is a highly advanced web proxy used for evading internet censorship or accessing websites in a controlled sandbox. It is designed with security and performance in mind. Ultraviolet intercepts HTTP requests with a service worker, while adhering to the while using [libcurl.js](https://github.com/ading2210/libcurl.js) or [epoxy-tls](https://github.com/MercuryWorkshop/epoxy-tls) with [Wisp](https://github.com/MercuryWorkshop/wisp-protocol) and is a leader in innovative web proxy technologies.
 
 ## Features
 
-Ultraviolet offers several features that set it apart from its predecessors, including CAPTCHA and hCAPTCHA support, URL encoding settings for added security, client-side configuration via service-workers, high speed compared to other web proxies, blacklist settings and more for easy hosting, leak prevention, regular updates, and improved resource usage and speed for better setups with a dedicated server instance.
+Ultraviolet offers several features that set it apart from its predecessors, including CAPTCHA and hCAPTCHA support, URL encoding settings for added security, full end to send encryption, client-side configuration via service-workers, high speed compared to other web proxies, blacklist settings and more for easy hosting, leak prevention, regular updates, and improved resource usage and speed for better setups with a dedicated server instance.
 
 ## Supported Sites
 
@@ -67,7 +67,7 @@ Some of the popular websites that Ultraviolet supports include:
 
 ## Upgrading
 
-A guide for updating from v1 to v2 can be found [here](./docs/V2-UPGRADE-GUIDE.md).
+A guide for updating from v2 to v3 can be found [here](https://github.com/titaniumnetwork-dev/Ultraviolet/wiki/Upgrading).
 
 ## Older Bare servers
 
@@ -115,8 +115,6 @@ $ npm run build
 
 You can extract the scripts from the NPM package in the [releases section](https://github.com/titaniumnetwork-dev/Ultraviolet/releases). All the scripts you would typically look for (`uv.bundle.js`, `uv.handler.js`, `uv.sw.js`, and `uv.config.js`) are found within the `dist` directory.
 
-If you cannot open the tar.gz (Chrome OS?), use a [converter](https://cloudconvert.com/tar.gz-to-zip). We can only do so much to make the scripts accessible.
-
 ## Installation
 
 > This will provide built files and the JS API to access the path of dist files.
@@ -138,6 +136,35 @@ Package will be named `ultraviolet-X.X.X.tgz`
 
 ## Changelogs
 
+# 3.0.0
+
+-   This version of Ultraviolet has support for using [bare-mux](https://github.com/MercuryWorkshop/bare-mux) transports, allowing for use for other implementations like [EpoxyTransport](https://github.com/MercuryWorkshop/EpoxyTransport), [CurlTransport](https://github.com/MercuryWorkshop/CurlTransport), and the existing implementation [Bare-Client](https://github.com/MercuryWorkshop/Bare-as-module3).
+
+# v2.0.0
+
+-   This version of Ultraviolet has support for Bare server v3
+-   Support for older Bare servers was dropped.
+
+# v1.0.10
+
+-   This version of Ultraviolet fixes an NPM versioning error.
+
+# v1.0.8
+
+-   This version of Ultraviolet improves error messages.
+
+# v1.0.7
+
+-   This version of Ultraviolet correctly sets the `cache` option when making a request.
+
+# v1.0.6
+
+-   This version of Ultraviolet upgrades [@tomphttp/bare-client](https://www.npmjs.com/package/@tomphttp/bare-client). As a result, refreshing can fix errors with the Bare metadata being fetched.
+
+# v1.0.5
+
+-   This version of Ultraviolet fixes a minor bug with `blob:` URLs.
+
 ### v1.0.4
 
 Massive rework for Ultraviolet! Improvements to resource usage, performance and overall site support.

diff --git a/docs/services/flowworks.mdx b/docs/services/flowworks.mdx
diff --git a/docs/tomphttp.mdx b/docs/tomphttp.mdx
@@ -4,6 +4,7 @@ title: TompHTTP
 ---
 
 ## TOMPHTTP Specifications
+# NODE: TompHTTP IS NO LONGER SUPPORTED BY US IN FAVOR OF [**Wisp**](/wisp)
 
 [**GitHub**](https://github.com/tomphttp)
 

diff --git a/docs/wisp.mdx b/docs/wisp.mdx
@@ -0,0 +1,135 @@
+---
+sidebar_position: 1
+title: Wisp
+---
+
+## Wisp Specifications
+
+[**GitHub**](https://github.com/MercuryWorkshop/wisp-protocol)
+
+## What is Wisp?
+
+Wisp is designed to be a low-overhead, easy to implement protocol for proxying multiple TCP and UDP sockets over a single websocket connection.
+
+## What does this have to do with proxies?
+
+Prior to the creation of Wisp, proxy traffic over backends such as the Bare Server or Rammerhead are sent completely unencrypted to the server host. This may work fine if you are hosting your own proxy, but when using public links you obtain from a discord server the risk of the host stealing your tokens from proxy usage might be a problem. 
+
+Since Wisp can proxy all TCP traffic, transports like Epoxy or Libcurl will encrypt your traffic with TLS, making even the server host unable to access any data besides the hostnames of the sites you visit. Wisp's UDP feature also allows for use as a highly censorship-resistant VPN with [Whisper](https://github.com/MercuryWorkshop/Whisper).
+
+## Server Implementations:
+- **[wisp-server-python](https://github.com/MercuryWorkshop/wisp-server-python)** - by [@ading2210](https://github.com/ading2210)
+- **[wisp-server-node](https://github.com/MercuryWorkshop/wisp-server-node)** - by [@ProgrammerIn-wonderland](https://github.com/ProgrammerIn-wonderland)
+- [epoxy-server](https://github.com/MercuryWorkshop/epoxy-tls/tree/multiplexed/server) (Rust) - by [@r58Playz](https://github.com/r58Playz)
+- [WispServerCpp](https://github.com/FoxMoss/WispServerCpp) - by [@FoxMoss](https://github.com/FoxMoss)
+
+## Client Implementations:
+- **[wisp-client-js](https://github.com/MercuryWorkshop/wisp-client-js)** - by [@ading2210](https://github.com/ading2210)
+- [wisp-mux](https://crates.io/crates/wisp-mux) (Rust) - by [@r58Playz](https://github.com/r58Playz)
+
+## Software Using Wisp:
+- [libcurl.js](https://github.com/ading2210/libcurl.js) - A port of libcurl to WebAssembly, for proxying HTTPS requests from the browser with full TLS encryption
+- [epoxy-tls](https://github.com/MercuryWorkshop/epoxy-tls) - An encrypted proxy for browser javascript, written in Rust.
+- [Ultraviolet](https://github.com/titaniumnetwork-dev/Ultraviolet/) - A sophisticated web proxy, which uses either libcurl.js or epoxy. 
+- [Whisper](https://github.com/MercuryWorkshop/Whisper) - A client for Wisp that exposes the connection over a TUN device.
+
+## Packet format
+| Field Name  | Field Type | Notes                                         |
+|-------------|------------|-----------------------------------------------|
+| Packet Type | `uint8_t`  | The packet type, covered in the next section. |
+| Stream ID   | `uint32_t` | Random stream ID assigned by the client.      |
+| Payload     | `char[]`   | Payload takes up the rest of the packet.      |
+
+Every packet must follow this format regardless of the type. Note that all data types are little-endian. 
+
+## Packet Types
+Each packet type has a different format for the payload, which is detailed below.
+
+### `0x01` - CONNECT
+#### Payload Format
+| Field Name           | Field Type | Notes                                                  |
+|----------------------|------------|--------------------------------------------------------|
+| Stream Type          | `uint8_t`  | Whether the new stream should use a TCP or UDP socket. |
+| Destination Port     | `uint16_t` | Destination TCP/UDP port for the new stream.           |
+| Destination Hostname | `char[]`   | Destination hostname, in a UTF-8 string.               |
+
+#### Behavior
+The client needs to send a CONNECT packet to the server to create a new stream under the same websocket. The stream ID chosen by the client at this point will be associated with this stream for all future messages. When the server receives this packet, it must validate this information, and if the payload is invalid, a CLOSE packet must be sent.
+
+Once the payload has been validated, the server must immediately try to establish a TCP/UDP socket to the specified hostname and port. If this fails, the server must send a CLOSE packet with the reason. To reduce overall delay, the client can begin sending data before the any CONTINUE packet has been received from the server.
+
+The stream type field determines whether the connection uses TCP or UDP. `0x01` in this field means TCP, and `0x02` means UDP. UDP support is optional for both the server and the client.
+
+### `0x02` - DATA
+#### Payload Format
+| Field Name     | Field Type | Notes                                                      |
+|----------------|------------|------------------------------------------------------------|
+| Stream Payload | `char[]`   | The data which is sent to and from the destination server. |
+
+#### Behavior
+Any DATA packets sent from the client to the server must be proxied to the TCP/UDP socket associated with the stream ID of the packet. On the server, the received payload must be buffered before being sent to the TCP/UDP socket in order to handle congestion. The size of this send buffer is predetermined and must be the same for every stream. 
+
+Any DATA packets sent from the server to the client must be interpreted as coming from the TCP/UDP socket associated with the stream ID of the packet.
+
+For TCP streams, the server must buffer any packets received from the client in a FIFO queue, and it must keep a separate buffer for each TCP stream.
+
+### `0x03` - CONTINUE
+#### Payload Format
+| Field Name       | Field Type | Notes                                                                    |
+|------------------|------------|--------------------------------------------------------------------------|
+| Buffer Remaining | `uint32_t` | The number of packets that the server can buffer for the current stream. |
+
+#### Behavior
+If the associated stream is a UDP socket, then CONTINUE packets must not be sent, and the client does not keep track of any buffer for the stream.
+
+When the client receives a CONTINUE packet from the server, it must store the received buffer size. When sending a DATA packet, this value should be decremented by 1 on the client. Once the remaining buffer size reaches zero, the client cannot send any more DATA packets, until it receives another CONTINUE packet which resets this value.
+
+The server must send another CONTINUE packet when it has received the same number of packets from the client as its own maximum buffer size. The server should regularly send CONTINUE packets before this point to ensure minimal delays when receiving data from the client. 
+
+### `0x04` - CLOSE
+#### Payload format
+| Field Name   | Field Type | Notes                                  |
+|--------------|------------|----------------------------------------|
+| Close Reason | `uint8_t`  | The reason for closing the connection. |
+
+#### Behavior
+Any CLOSE packets sent from either the server or the client must immediately close the associated stream and TCP socket. The close reason in the payload doesn't affect this behavior, but may provide extra information which is useful for debugging.
+
+#### Client/Server Close Reasons
+- `0x01` - Reason unspecified or unknown. Returning a more specific reason should be preferred.
+- `0x02` - Voluntary stream closure, which would equate to one side resetting the connection.
+- `0x03` - Unexpected stream closure due to a network error.
+
+#### Server Only Close Reasons
+- `0x41` - Stream creation failed due to invalid information. This could be sent if the destination was a reserved address or the port is invalid. 
+- `0x42` - Stream creation failed due to an unreachable destination host. This could be sent if the destination is an domain which does not resolve to anything. 
+- `0x43` - Stream creation timed out due to the destination server not responding.
+- `0x44` - Stream creation failed due to the destination server refusing the connection.
+- `0x47` - TCP data transfer timed out.
+- `0x48` - Stream destination address/domain is intentionally blocked by the proxy server.
+- `0x49` - Connection throttled by the server.
+
+#### Client Only Close Reasons
+- `0x81` - The client has encountered an unexpected error and is unable to receive any more data. 
+
+## HTTP Behavior
+Since the entire protocol takes place over websockets, a few rules need to be in place to ensure that an HTTP connection can be upgraded successfully.
+
+### Server Architecture
+The server must consist of a HTTP and websocket server that conforms to the respective standards.
+
+### Choosing a Websocket URL
+To ensure compatibility with previous wsproxy implementations, the URL of the websocket should always end with a trailing forward slash (`/`) to prevent confusion with wsproxy endpoints. 
+
+For example, a wsproxy endpoint might look like this: `ws://example.com/customprefix/host:port`
+
+Meanwhile a Wisp endpoint would look like this: `ws://example.com/customprefix/`
+
+It is up to the server implementation to interpret the prefix. It may be ignored, or used for gatekeeping in order to establish password-based authentication.
+
+### Establishing a Websocket Connection
+The client must establish the connection by performing a standard websocket handshake. The `Sec-WebSocket-Protocol` header does not need to be set.
+
+Immediately after a websocket connection is established, the server must send a CONTINUE packet containing the initial buffer size for each stream. The stream ID for this packet must be set to 0, which corresponds to the version of the Wisp protocol (0 means Wisp v1). The client must wait for this CONTINUE packet to be received before beginning any communications. The purpose of this packet is to ensure that the client does not have to wait for a CONTINUE packet for the creation of each stream, reducing the overall delay.
+
+The Wisp protocol specifications were written by [@ading2210](https://github.com/ading2210).
-Original file line number
+Diff line change
@@ Expand Up / @@ -4,6 +4,7 @@ title: TompHTTP @@
     ---
     ## TOMPHTTP Specifications
+    # NODE: TompHTTP IS NO LONGER SUPPORTED BY US IN FAVOR OF [**Wisp**](/wisp)
     [**GitHub**](https://github.com/tomphttp)
@@ Expand Down @@