Demo Re-enabled

Fix chunking
Enable Data Chunking
Improved accuracy of packetization & fragmentation
Added new request methods
updated request method params
Organize Docs
Update Docs
Remove old docs

docs/packetDesign.md

@@ -1,84 +1,80 @@
-## Universal Web Socket - PACKET DESIGN
-
-Keep in mind packet design is in flux and is subject to constant changes until v1 RC.
-
-Definitions
-Multiple - Emplies that the property name may be used more than once inside a single packet. This is expected to change as property single character names are chosen.
-
-#### PACKET OVERVIEW
-
-|          ARRAY           |
-| :----------------------: |
-|         Headers          |
-| Encrypted Data End Index |
-|      Encrypted Data      |
-
-#### Additional Data
-
--   Nonce
--   Socket ID (CLIENT/SERVER)
-    -   May indicate which server to send to for load balancing
-    -   May indicate which domain to send to for virtual hosts
-    -   May be entirely random
+# Universal Web Socket: PACKET DESIGN
+
+[
+  // HEAD
+  {
+    connectionID
+  },
+  // BODY
+  {
+    method
+    data
+  },
+  // FOOTER
+  {
+
+  }
+]
+
+#### UDSP HEADERS (MSGPack Object)(OPTIONAL ENCRYPTION)
+
+- Nonce
+- Socket ID (CLIENT/SERVER)
+ : May indicate which server to send to for load balancing
+ : May indicate which domain to send to for virtual hosts
+ : May be entirely random
 
 ---
 
-#### ENCRYPTED DATA
-
--   id - Connection ID (MANDATORY)
--   api - API function that is requested (OPTIONAL)
--   Watcher (OPTIONAL)
--   Identity Certificate (OPTIONAL)(REQUIRED FOR HANDSHAKE)
--   Head (OPTIONAL Multiple)
--   Body (OPTIONAL Multiple) (MSGPack Object)
--   Pid - Packet ID (MANDATORY)
--   Status - Status Code (OPTIONAL)
-    -   If status is left blank it defaults to 200 or is considered a success
--   end - Kill connection (OPTIONAL)
--   Puzzle - Solve a puzzle to continue (OPTIONAL)
--   ReKey (OPTIONAL)
--   scid - Server connection ID (OPTIONAL)
--   cid - Client connection ID (OPTIONAL)
+#### PROPERTY NAMES & MEANINGS
+
+- id: Connection ID
+- ccid: Client Connection ID
+- scid: Server Connection ID
+- method: Request methods such as GET, PUT, DELETE but in lowercase
+- Watcher: Something used to watch completed data as it comes over the wire
+- Head: UDSP Headers or Request/Response headers in a message
+- evnt: (Event related to application level events)
+- Body/Message: Is the main payload of a packet or the full data from a request
+- Pid: Packet ID
+- sid: Stream ID Essentially a Request ID unique to each request
+- State: Connection/Request UDSP State Code
+- Status: status Code similar to HTTP
+- readyState: request readystate similar to XHR/HTTP requests
+- end: Kill connection
+- last: the last packet
+- Puzzle: Solve a puzzle to continue
+- ReKey
+- scid: Server connection ID
 
 ---
 
-#### HEADER LAYERS
+#### UDSP LAYERS
 
 |  IPv6 HEADERS  |
 | :------------: |
-|  UDP HEADERS   |
+|      UDP       |
 |  UDSP HEADERS  |
-| PACKET HEADERS |
-| STREAM HEADERS |
+|  UDSP MESSAGE  |
+|  UDSP FOOTER   |
 
+The UDSP Header, Body, & Footer are all part of one array structure encoded with msgpack.
 ##### IPv6 HEADERS
 
--   Version
--   Traffic Class
--   Flow Label
--   Payload Length
--   Next Header
--   Hop Limit
--   Source Address
--   Destination Address
+- Version
+- Traffic Class
+- Flow Label
+- Payload Length
+- Next Header
+- Hop Limit
+- Source Address
+- Destination Address
 
 ##### UDP HEADERS
 
 These are the standard UDP headers sent over:
 
--   Source Port Number
--   Destination Port Number
--   Length
--   Checksum
-
-##### MAIN HEADERS
-
-Main Headers are public and typically none encrypted but the application can choose to encrypt certain headers such as connection IDs.
-
-##### PACKET HEADERS
-
-Packet headers are encrypted and are typically sent only once and are considered priority data they must fit into a single UDSP packet. An example of packet headers that would be sent once are security related headers such as content origin policy. If in a browser this header is attached to all other requests or placed as a meta tag in the head. This avoids the constant re-sending of these headers when they only need to be sent once. This also avoids processing on the server and client for redundant security headers.
-
-##### STREAM HEADERS
-
-STREAM headers are request specific and may be sent over first prior to the encrypted body being sent over. Headers are treated as priority data in terms of execution of the request.
+- Source Port Number
+- Destination Port Number
+- Length
+- Checksum

packetActions.md → docs/requestMethods.md

@@ -1,13 +1,13 @@
-# UDSP Methods
+# UDSP Request Methods
 
-Methods have two formats one which is numerical for compression and one which is string based. Preferred is numerical but not standard or implimented yet. Some of these are planned but not implimented but are reserved and planned as part of a feature.
+Methods have two formats one which is numerical for compression and one which is string based. Preferred is numerical but isn't standard nor is it implimented yet. Some of these are planned but not implimented. However, they're reserved and planned.
 
 - open
 - connect
 - close
-- subscribe
+- subscribe (sub)
 - leave
-- publish
+- publish (pub)
 - delete
 - save
 - update
@@ -32,6 +32,7 @@ Methods have two formats one which is numerical for compression and one which is
 - alive
 - login
 - logout
+- auth (authenticate)
 - rekey
 - fsync (filesystem sync)
 - live (live stream)

docs/udspCryptoSecurity.md

@@ -0,0 +1,25 @@
+# UW:// & Universal Data Stream Protocol security
+
+UW:// First acquires a domain certificate which it requests from the Domain Information System. The connection to the DIS is encrypted  using pre-provided certificates. The root pre-provided certificates help clients to verify and connect to a DIS server. The DIS is a distributed decentralized network designed for certificate distribution. Certificates rely on blockchain technology and a certificate authority to establish trust in certificates distributed by the DIS. Encryption occurs starting with the first packet by relying on the Domain Certificate to provide all required details to establish and initial connection without having to negotiate any perameters. UDSP has Perfect forward secrecy and uses a total of 3 or more keypairs to setup a connection. Depending on the optional security options listed within the Domain Certificate UDSP could be fine tuned for its own balance of performance & security. The initial ephemeral client public key generated for connection establishment could be encrypted using a onetime throw away keypair and the server's public key listed in the domain certificate.
+
+##### Connection IDs
+
+This alone removes the need to have a domain based server name identifier because smart server connection ids can be indicated in the domain certificate. The domain certificate  can tell a client what to include in the server connection id to allow it to effectively route all packets to the correct server and or instance. However, IPv6 would solve that issue anyway by routing requests to a specific IP instead of a shared single IP. A model where this is most useful is for shared hosting or shared servers which are hosting multiple sites on the same IP. They need to inteligently route packets to their end destination and smart connection ids do that. Smart Connection Id's are most useful for load balancers handling large amounts of connections and servers. They can even route packets to a specific instance, hardware, core, and so on running a server.
+
+##### Encrypted Connection IDs
+
+Connection ID's for both the server and the client can be encrypted or only one could be encrypted which is determined by the Domain Certificate. The connection ID's to the server or the client could also be encrypted with a separate keypair allowing Servers to have middleware or hardware (example: loadbalancer) with their own keypair used to decrypt and process smart connection IDs. This means that the machines that sit between the client and server could have the unique keypair they use isolated which means if for some reason that hardware was compromised it would not provide the keypair used in the domain certificate nor would it allow an attacker to decrypt any of the priority data within a packet. This model allows efficient seperation of concern, security, and allows a load balancer to decrypt and route packets to their appropriate destination without having access to any keypairs that could decrypt the packets data. This ensures an isolated security policy for the network protecting potential breaches of network hardware to a minimum when it comes to keypairs.
+
+##### Permitted unencrypted first packet
+
+All data sent to and from the server are encrypted in the standard security model. However, a server can permit a client to send an unencrypted first packet that is requesting the server's domain certificate. None the less all subsequent packets would be encrypted with an AEAD algo. The server first responds with an ephemeral public key which is encrypted by a onetime throw away public key paired with AEAD encryption. A limited encrypted connection is then established and then the server sends over its certificate or provides instructions on how to request it from the DIS.
+
+##### Same connection unique keypairs per Request
+
+Different keys per-stream means that if a connection is established and multiple requests come over the wire each request could use its own keypair to encrypt that specific stream aka request. For example if there are two GET requests over a single connection each could utilize its own keypair for its own related packets. WHile all new GET requests would use the initial client keypair and the server's second public key which it created for that unique client connection. Although UDSP is setup to permit unique keys per-request it's typically not used and seen as overkill.
+
+### UW:// Security Compared to HTTP
+
+UW:// is encrypted by default & offers options for far greater encryption, privacy, and anonymity than HTTP/s while remaining as performant as possible. UW:// enforces the latest standards in encryption and is not designed for nor does it permit older encryption schemes such as RSA. Even in cases like HTTP3 UW:// offers varios encryption strategies for data that is typically sent in the clear such an encryption public keypairs during the connection handshake. Encrypting connection ids as well as permitting typically other plain text data to be encrypted starting from the first packet. UW doesn't rely on another layer to handle the encryption process like HTTP with TLS. All the magic happens within a single layer as to be as performant yet secure as possible.
+
+##### SUBJECT TO CHANGE (WIP)

udsp/base.js

@@ -1,5 +1,4 @@
-import { construct, UniqID } from '@universalweb/acid';
-import { actions } from './server/actions/index.js';
+import { construct, UniqID, each } from '@universalweb/acid';
 import { cryptography } from '#udsp/cryptography';
 import dgram from 'dgram';
 import { randomConnectionId, randomBuffer } from '#crypto';
@@ -32,9 +31,9 @@ export class UDSP {
 			this.packetOverhead = packetInitialOverhead + this.encryptPacketOverhead + this.connectionIdSize;
 			this.maxPayloadSize = this.maxPacketSize - this.packetOverhead;
 			this.maxPayloadSizeSafeEstimate = this.maxPayloadSize - 10;
-			this.emptyPayloadOverHeadSize = 16;
+			this.emptyPayloadOverHeadSize = 16 + 19;
 			if (!maxDataSize) {
-				this.maxDataSize = this.maxPayloadSize - this.emptyPayloadOverHeadSize;
+				this.maxDataSize = this.maxPayloadSize - this.emptyPayloadOverHeadSize - 7;
 			}
 			if (!maxHeadSize) {
 				this.maxHeadSize = this.maxPayloadSize - this.emptyPayloadOverHeadSize;
@@ -71,10 +70,16 @@ export class UDSP {
 			console.log('Before Exit', code);
 		});
 	}
+	addMethod(methods) {
+		const thisContext = this;
+		each(methods, (method, methodName) => {
+			thisContext[methodName] = method.bind(thisContext);
+		});
+		return this;
+	}
 	connectionGracePeriod = 30000;
 	maxPacketSize = 1280;
 	connectionIdSize = 8;
-	actions = construct(Map);
 	stateCodeDescriptions = ['initializing', 'initialized', 'failed to initialize'];
 	state = 0;
 	/*

udsp/decodePacket.js

@@ -23,8 +23,10 @@ export async function decodePacketHeaders(config) {
 		isServerEnd,
 		isServerClient
 	} = destination;
-	if (packetEncoded.length > 1350) {
-		failed(`WARNING: Packet size is larger than max allowed size 1350 -> ${packetEncoded.length}bytes over by ${packetEncoded.length - 1350}bytes`);
+	const packetSize = packetEncoded.length;
+	if (packetSize > 1280) {
+		console.log(packetEncoded);
+		failed(`WARNING: DECODE Packet size is larger than max allowed size 1280 -> ${packetSize} over by ${packetSize - 1280}`);
 	}
 	let encryptConnectionId;
 	if (isServerEnd) {
@@ -33,7 +35,7 @@ export async function decodePacketHeaders(config) {
 		encryptConnectionId = cryptography.config.encryptClientConnectionId;
 	}
 	const client = config.client;
-	info(`Packet Encoded Size ${packetEncoded.length}`);
+	info(`Packet Encoded Size ${packetSize}`);
 	const packet = decode(packetEncoded);
 	config.packet = packet;
 	info(`Packet Decoded Array Size ${packet.length}`);