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

Ouverte Adaptée aux débutants
  • Quelque chose ne va pas ?
#646 1 commentaire 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
1/5
Temps estimé
1-3 heures
Accessibilité débutants
88/100
Type d'issue
Documentation
Clarté
Clairement spécifiée
Activité
Active
Stack technique
cloud, github, rust, sqlite
Domaine
documentation, networking

Piste de recherche

Commencez par le contrôle d’acceptation existant dans docs/peer-interviews.md et ajoutez une brève note pour essayer la pratique réciproque avant le staging. Expliquez pourquoi localhost et une adresse LAN ne fonctionnent pas pour un partenaire distant ayant accès au microphone, et pourquoi les deux personnes doivent utiliser le même serveur et le même lobby. Décrivez l’exigence d’une origine HTTPS partagée et d’une URL de callback OAuth identique, avec un tunnel comme exemple facultatif et une note indiquant que toute personne disposant de son URL peut accéder au serveur exposé.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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.

Langage dominant
Rust
Étoiles
228
Forks
150
Merge moyen
1 j 3 h
PR mergées (30 j)
230

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de sysprog21/codetrial

Toutes les issues de sysprog21/codetrial

Issues similaires

Plus d'issues Rust

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.