Add support for connecting to either moq-lite or moq-transport-07.

[kixelated]

Breaking wire change. The server needs to be updated first.

[claude]

Claude finished @kixelated's task —— View job

---

PR Review: Backward Compatibility for moq-lite and moq-transport-07

Reviewing this PR for bugs and security issues:

Todo List:

• Examine connection setup and protocol negotiation logic
• Review security aspects of version handling
• Check error handling and edge cases
• Look for potential race conditions
• Verify proper handling of different protocol versions

🔍 Review Results

After reviewing the backward compatibility implementation, I found no critical bugs or security issues. The implementation looks solid with proper error handling and secure protocol negotiation.

Key findings:

✅ Protocol Version Negotiation - Secure bidirectional negotiation where:

• Client sends supported versions: [Lite.CURRENT_VERSION, Ietf.CURRENT_VERSION]
• Server validates client versions against its supported versions
• Connection created with appropriate handler based on negotiated version

✅ Stream Type Validation - Proper validation of stream types with dedicated compatibility values:

• ClientCompat: 0x40 and ServerCompat: 0x41 for backward compatibility
• Proper bounds checking and error handling for unknown types

✅ Error Handling - Good error handling throughout:

• Version mismatch errors with clear messaging
• Stream type validation with proper error responses
• Connection cleanup on failures

✅ No Security Vulnerabilities - Certificate fingerprint validation remains secure:

• Proper hex string validation with length/format checks
• Warning logged for insecure HTTP fingerprint fetches
• TLS certificate hash validation for non-HTTPS connections

Minor observations (not bugs):

• Typo in SteamId (should be StreamId) in /js/moq/src/lite/stream.ts:9 - but consistent usage
• Comment typo "Supported extenisions" in /rs/moq/src/message/setup.rs:36

👍 Recommendation

This PR is safe to merge. The backward compatibility implementation follows secure patterns with proper version negotiation and error handling.

---

[claude]

Claude finished @kixelated's task —— View job

---

PR Review: Backward Compatibility Implementation

Reviewing this PR for bugs and security issues:

Todo List:

• Examine connection setup and protocol negotiation logic
• Review security aspects of version handling
• Check error handling and edge cases
• Look for potential race conditions
• Verify proper handling of different protocol versions

🔍 Review Results

After reviewing the backward compatibility implementation, I found no critical bugs or security issues. The implementation looks solid with proper error handling and secure protocol negotiation.

Key findings:

✅ Protocol Version Negotiation - Secure bidirectional negotiation where:

• Client sends supported versions: [Lite.CURRENT_VERSION, Ietf.CURRENT_VERSION] (js/moq/src/connection.ts:71)
• Server validates client versions against its supported versions (rs/moq/src/session/mod.rs:127)
• Connection created with appropriate handler based on negotiated version

✅ Stream Type Validation - Proper validation of stream types with dedicated compatibility values:

• ClientCompat: 0x40 and ServerCompat: 0x41 for backward compatibility (js/moq/src/lite/stream.ts:13-14)
• Proper bounds checking and error handling for unknown types (rs/moq/src/message/stream.rs:21-23)

✅ Error Handling - Good error handling throughout:

• Version mismatch errors with clear messaging (js/moq/src/ietf/setup.ts:122-124)
• Stream type validation with proper error responses (js/moq/src/lite/connection.ts:156)
• Connection cleanup on failures

✅ No Security Vulnerabilities - Certificate fingerprint validation remains secure:

• Proper hex string validation with length/format checks (js/moq/src/connection.ts:33-42)
• Warning logged for insecure HTTP fingerprint fetches (js/moq/src/connection.ts:51)
• TLS certificate hash validation for non-HTTPS connections

👍 Recommendation

This PR is safe to merge. The backward compatibility implementation follows secure patterns with proper version negotiation and error handling.

---

[claude]

Claude finished @kixelated's task —— View job

---

PR Security & Bug Review

Reviewing backward compatibility implementation for moq-lite and moq-transport-07:

Todo List:

• Examine protocol version negotiation logic
• Review connection setup and stream handling
• Check security aspects of version handling
• Look for potential bugs in error handling
• Verify proper validation of protocol messages

🔍 Review Results

After reviewing the backward compatibility implementation, I found no critical bugs or security issues. The implementation follows secure patterns with proper error handling.

Key findings:

✅ Protocol Version Negotiation - Secure bidirectional negotiation:

• Client sends supported versions: [Lite.CURRENT_VERSION, Ietf.CURRENT_VERSION] (js/moq/src/connection.ts:71)
• Server validates client versions against supported versions (rs/moq/src/session/mod.rs:127-128)
• Connection created with appropriate handler based on negotiated version

✅ Stream Type Validation - Proper validation with dedicated compatibility values:

• ClientCompat: 0x40 and ServerCompat: 0x41 for backward compatibility (js/moq/src/lite/stream.ts:13-14)
• Proper bounds checking and error handling for unknown stream types (rs/moq/src/message/stream.rs:23)

✅ Error Handling - Good error handling throughout:

• Version mismatch errors with clear messaging (js/moq/src/ietf/setup.ts:122-124)
• Stream type validation with proper error responses (js/moq/src/lite/connection.ts:156)
• Connection cleanup on failures

✅ Certificate Validation Remains Secure - Proper security measures maintained:

• Hex string validation with length/format checks (js/moq/src/connection.ts:33-42)
• Warning for insecure HTTP fingerprint fetches (js/moq/src/connection.ts:51)
• TLS certificate hash validation for HTTPS connections

👍 Recommendation

This PR is safe to merge. The backward compatibility implementation is well-designed with proper version negotiation, error handling, and security measures.

---

[claude]

Claude finished @kixelated's task —— View job

---

PR Security & Bug Review

Reviewing backward compatibility implementation for moq-lite and moq-transport-07:

Todo List:

• Set up development environment and examine codebase structure
• Review protocol version negotiation logic for security issues
• Check stream type validation and error handling
• Look for potential race conditions or edge cases
• Verify certificate validation security remains intact
• Run linting/tests if available to check code quality

🔍 Review Results

After thoroughly reviewing the backward compatibility implementation, I found no critical bugs or security issues. The implementation is well-designed with proper security measures.

Key findings:

✅ Protocol Version Negotiation - Secure bidirectional negotiation:

• Client sends supported versions: [Lite.CURRENT_VERSION, Ietf.CURRENT_VERSION] (js/moq/src/connection.ts:71)
• Server validates client versions against supported versions (rs/moq/src/session/mod.rs:127-128)
• Connection created with appropriate handler based on negotiated version

✅ Stream Type Validation - Proper validation with dedicated compatibility values:

• ClientCompat: 0x40 and ServerCompat: 0x41 for backward compatibility (js/moq/src/lite/stream.ts:13-14)
• Proper bounds checking and error handling for unknown stream types (rs/moq/src/message/stream.rs:23)

✅ Error Handling - Robust error handling throughout:

• Version mismatch errors with clear messaging (js/moq/src/ietf/setup.ts:122-124)
• Stream type validation with proper error responses (js/moq/src/lite/connection.ts:156)
• Connection cleanup on failures

✅ No Race Conditions - Proper initialization sequence:

• Wait for initial announcements to prevent race conditions (rs/moq/src/session/mod.rs:65-69)
• Concurrent session management with proper error propagation

✅ Certificate Validation Remains Secure - Security measures maintained:

• Proper hex string validation with length/format checks (js/moq/src/connection.ts:33-42)
• Warning logged for insecure HTTP fingerprint fetches (js/moq/src/connection.ts:51)
• TLS certificate hash validation for HTTPS connections

👍 Recommendation

This PR is safe to merge. The backward compatibility implementation follows secure patterns with proper version negotiation, input validation, and error handling.

---