Explain how two people on different machines try reciprocal practice before staging

Abierto Apto para principiantes
  • ¿Algo no está bien?
#646 1 comentario 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
1/5
Tiempo estimado
1-3 horas
Aptitud para principiantes
88/100
Tipo de issue
Documentación
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
cloud, github, rust, sqlite
Área
documentation, networking

Línea de trabajo

Empieza con la comprobación de aceptación existente en docs/peer-interviews.md y añade una nota breve para probar la práctica recíproca antes del staging. Explica por qué localhost y una dirección LAN no funcionan para una persona colaboradora remota con acceso al micrófono, y por qué ambas personas necesitan el mismo servidor y la misma sala de espera. Describe el requisito de compartir el origen HTTPS y de que coincida la callback de OAuth, con un túnel como ejemplo opcional y una nota de que cualquiera que tenga su URL puede acceder al servidor expuesto.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

docs/peer-interviews.md assumes a staging deployment: its acceptance check uses "two real GitHub accounts in separate browser profiles, headphones and a staging deployment". It does not say how two people on different machines try reciprocal practice when the server runs on one person's computer, which is what a teaching assistant or a contributor does first. Three things each cost us time while doing so (at 5e00eab):

  1. 127.0.0.1:3000 is reachable only from the machine running the server. A partner who opens the same address reaches their own machine.
  2. Binding to a LAN address and opening http://192.168.x.x:3000 loads the page, but the browser does not expose the microphone outside a secure context (HTTPS or localhost), so the room has no audio.
  3. Two people each running their own server with the same LiveKit credentials do not see each other in Available partners. Pairing lives in each server's SQLite ("HTTP and SQLite own membership, roles, clocks, snapshots and feedback"), so sharing a LiveKit project does not share the lobby.

What worked: one person runs the server, exposes it over HTTPS with cloudflared tunnel --url http://127.0.0.1:3000, sets the OAuth App's callback to the tunnel origin plus /api/callback, and both people open the tunnel's /peer-lobby and sign in with different GitHub accounts.

Intended correction: a short "Trying it with a partner before staging" note in docs/peer-interviews.md that states the three constraints above and the requirement that both people use one server over HTTPS. It does not need to endorse a particular tunnel; naming one as an example, with the caution that it exposes the server and its provider quotas to anyone holding the URL, is enough.

Reader outcome: someone with a working local server knows, before inviting a partner, that they need one shared HTTPS origin and a matching OAuth callback.

Related: the OAuth App setup steps are #645 and the single-redirect-URI behavior is #643; this issue is only about reaching one server from two machines.

Lenguaje dominante
Rust
Estrellas
228
Forks
150
Merge medio
1 d 3 h
PR fusionados (30 d)
230

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de sysprog21/codetrial

Todos los issues de sysprog21/codetrial

Issues similares

Más issues de Rust

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.