Desarrollo de dApp 2.5 de Comunicación P2P

Solicitud de Propuesta (RFP) / Pliego Técnico
Perfil: Ingeniero Senior WebRTC & Web3 Systems / Desarrollador Full-Stack dApp
Proyecto: Infraestructura de Audio P2P Cifrada y Capa de Voz Token-Gated para dApp 2.5
Tipo de Contratación: Freelance / Contrato por Hitos (Fase MVP)
Metodología: Desarrollo Ágil / Entrega basada en hitos (Milestones)
1. Visión General del Proyecto y Arquitectura Objetivo
Buscamos construir una aplicación descentralizada (dApp) en arquitectura Web2.5 que requiere un framework de comunicación de voz peer-to-peer (P2P) en tiempo real basado 100% en internet. El sistema debe omitir completamente el modelo de telefonía tradicional (PSTN/SIP/PBX), reemplazando los números telefónicos convencionales por direcciones de billetera cripto / Identificadores Descentralizados (DIDs).
El acceso a los canales de audio debe estar estrictamente restringido por tokens / roles (token-gated) mediante el estado de contratos inteligentes o firmas en el backend Web2.5, garantizando derechos de comunicación exclusivos para los miembros autorizados.
2. Requerimientos Funcionales y Técnicos Core
A. Control de Acceso Token-Gated y Autenticación (Capa Web2.5)
* Identidad y Autenticación: Implementación de autenticación Web3 mediante wallets EVM/Solana (SIWE - Sign-In with Ethereum o equivalente) integrada con abstracción de login social Web2.5 (ej. Privy, Dynamic o Web3Auth).
* Motor de Validación de Acceso (Gating):
* Verificación en tiempo real del estado de membresía (balance ERC-20/ERC-721, Soulbound Tokens o claims JWT firmados desde el backend) previo a la iniciación de la señalización o el handshake de medios.
* Validación en Contrato Inteligente / API: Patrón Bouncer a nivel de señalización. Los usuarios no autorizados deben sufrir el rechazo automático del intercambio de candidatos ICE y del relay de señalización.
B. Motor de Audio en Tiempo Real (Core WebRTC)
* Protocolos y Códecs: Implementación de WebRTC Audio de baja latencia (códec Opus, bitrate adaptativo dinámico, FEC/DTX habilitados para optimización de ancho de banda).
* Travesía de Red (NAT/Firewall):
* Despliegue y configuración de infraestructura propia de servidores STUN/TURN (coturn) o nodos edge administrados (ej. Cloudflare Calls, LiveKit o Twilio Network Traversal) con soporte de respaldo para NATs simétricos.
* Preferencia P2P: Configuración de conexión directa mesh/P2P; el relay TURN se utilizará estrictamente cuando la conexión directa ICE falle.
C. Capa de Señalización Descentralizada
* Eliminación de servidores de señalización centralizados tradicionales tipo WebSocket SIP/PBX.
* Implementación de un canal de señalización descentralizado/híbrido para el intercambio del protocolo de iniciación de sesión (oferta/respuesta SDP y candidatos ICE) utilizando:
* Opción A: Payload de mensajería P2P con Push Protocol / XMTP.
* Opción B: Canales Pub-Sub con libp2p / Waku mediante enrutamiento basado en tópicos para el descubrimiento de pares.
3. Alcance del Trabajo (Entregables MVP)
[Cliente Auth Web2.5 / Privy] ──> [Verificación Gatekeeper]
│
(Auth Aprobada)
▼
[Señalización Descentralizada: XMTP/Push/libp2p] ──> [Intercambio ICE / SDP]
│
▼
[Peer A (Cliente WebRTC)] [Peer B (Cliente WebRTC)]
(Fallback: Coturn)

* Módulo de Señalización y Handshake: Cliente de señalización WebRTC funcional que utilice direcciones cripto como endpoints de destino en lugar de números telefónicos.
* Componente de Salón de Audio / Llamada: Módulo de interfaz gráfica en React / HTML5 para la gestión del estado de la llamada (Llamando, Sonando, Conectado, Reconectando, Silenciado, Desconectado).
* Middleware de Gated Access: Lógica de verificación de autenticación pre-llamada que impida a los no miembros transmitir paquetes de señalización o unirse a sesiones peer-to-peer.
* DevOps y Configuración TURN: Scripts de despliegue (Docker / Terraform) para nodos STUN/TURN de baja latencia.
4. Stack Tecnológico Requerido y Calificaciones
* Lenguajes y Frameworks: JavaScript / TypeScript, React / Next.js, Node.js o Go.
* Protocolos y Especificaciones: WebRTC (RTCPeerConnection, RTCDataChannel), ICE, STUN/TURN, SDP, WSS.
* Librerías Web3: viem, ethers.js, wagmi, SIWE, Push Protocol SDK o XMTP SDK.
* Seguridad: Cifrado de extremo a extremo (E2EE) nativo mediante WebRTC DTLS/SRTP, además de verificación de payload firmado para mensajes de señalización.
5. Criterios de Evaluación e Hitos de Pago (Milestones)
| Hito (Milestone) | Entregable | Criterio de Aceptación |
|---|---|---|
| M1: Auth & Gating | Autenticación Web2.5 + API Gatekeeper en Smart Contract | El usuario inicia sesión vía Wallet/Social. El sistema retorna un token de llamada válido solo si se cumplen las condiciones de membresía. |
| M2: Señalización P2P | Pipeline de Señalización Descentralizada | Intercambio exitoso de Oferta/Respuesta SDP y candidatos ICE entre 2 direcciones Wallet a través de Push/XMTP/libp2p. |
| M3: Audio & Integración TURN | Llamada de Audio P2P End-to-End | Audio bidireccional nítido sobre códec Opus, respaldo automático a TURN bajo NATs restrictivos, y desconexión automática si el usuario pierde el estado de membresía. |