mirror of
https://github.com/xtr-dev/rondevu-server.git
synced 2025-12-09 18:33:24 +00:00
Bas van den Aakster
fe912e6a94
- Added hash-id.ts utility for SHA-256 content hashing
- Offer IDs now generated from hash of {sdp, topics} (sorted)
- Removed peerId from hash (inferred from authentication)
- Server generates deterministic IDs for idempotent offer creation
- Updated SQLite and D1 storage implementations
- Removed optional id field from CreateOfferRequest
- Same offer content always produces same ID
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
48 lines
1.8 KiB
Markdown
48 lines
1.8 KiB
Markdown
# Rondevu Server Development Guidelines
|
|
|
|
## WebRTC Signaling Best Practices
|
|
|
|
### ICE Candidate Storage
|
|
|
|
**IMPORTANT: Store ICE candidates as raw JSON without enforcing structure.**
|
|
|
|
When handling ICE candidates in the signaling server:
|
|
|
|
- ✅ **DO** store candidates as `JSON.stringify(candidate)` in the database
|
|
- ✅ **DO** retrieve candidates as `JSON.parse(candidate)` from the database
|
|
- ✅ **DO** use generic types like `any` in TypeScript for candidate data
|
|
- ❌ **DON'T** define strict types for ICE candidate structure
|
|
- ❌ **DON'T** validate or modify candidate properties
|
|
- ❌ **DON'T** assume you know what properties clients will send
|
|
|
|
**Why?** The server is just a relay - it doesn't need to understand the candidate structure. Different browsers and future WebRTC versions may include different properties. By keeping the server agnostic, we maintain maximum compatibility.
|
|
|
|
### Server Role Filtering
|
|
|
|
The server MUST filter ICE candidates by role:
|
|
- Offerers receive only answerer candidates (`WHERE role = 'answerer'`)
|
|
- Answerers receive only offerer candidates (`WHERE role = 'offerer'`)
|
|
|
|
This prevents peers from receiving their own candidates, which would cause connection failures.
|
|
|
|
## Security
|
|
|
|
- Always validate authentication tokens before allowing operations
|
|
- Verify ownership before allowing modifications
|
|
- Rate limit API endpoints to prevent abuse
|
|
- Clean up expired offers regularly
|
|
|
|
## Performance
|
|
|
|
- Use transactions for batch operations (SQLite)
|
|
- Index frequently queried columns (offer_id, role, created_at)
|
|
- Set appropriate TTLs for offers
|
|
- Implement pagination for large result sets
|
|
|
|
## Code Quality
|
|
|
|
- Handle errors gracefully with informative HTTP status codes
|
|
- Log important events for debugging
|
|
- Use TypeScript types for API contracts, but keep data types generic
|
|
- Write tests for critical paths
|