Practice Buddy login: there is no sign-in screen, by design.

Because adding accounts would have been a feature that did nothing for the user and added a real obstacle for the operator. The whole product is one form, one human review, one intro email, and one permanent Google Meet link per pair. Nothing else needs gating. A login screen would only protect a personal dashboard that does not exist on this site, and the operator (Matt) does not want a dashboard sitting between a meditator and their sit. The unauthenticated flow also matches the spirit of the tradition: courses run on dana, signups are read by a human, and the relationship that does the work is the one between you and the buddy you got matched with, not between you and a profile screen.

Your email address, plus single-use tokens that get written into emails sent to that address. The signup form at /practice-buddy stores your email in the waitlist_entries table. After that, every endpoint that mutates anything about your row checks one of two things: either it accepts an email and looks up the row by email (status checks), or it accepts a token from the URL and looks up the row by that token (everything else, including yes/no on a match, the redirect to your buddy's Google Meet link, and unsubscribing). Tokens are unguessable strings written once when an email is sent and validated on click. Possession of the email inbox is treated as proof you are the row.

Four endpoints, in this order. /api/waitlist (POST) creates your row when you sign up; no auth, validated by email format and basic name sanity. /api/waitlist/lookup (GET) takes ?email= and returns your status, name, time zone, sit times, and frequency, with no header check at all. /api/confirm-match (GET) takes ?token=... and ?response=yes|no, and validates the token against matches.person_a_token or matches.person_b_token. /api/unsubscribe (GET) takes ?token=... and validates against waitlist_entries.unsubscribe_token. The /meet/[token] route validates against meet_links.token, logs the click, and 302-redirects to the actual Google Meet URL. Five surfaces, four token columns, zero session cookies.

The endpoint is unauthenticated, and you can paste a stranger's email and see their first name, city, time zone, sit times, and old-student status. Email and last name are not returned. The reasoning is that those fields are already shown publicly on the waitlist table at /practice-buddy under 'Who's Waiting' for any pending row, so the lookup endpoint is not surfacing anything more than the public waitlist already does. It exists so a returning practitioner can prefill the signup form without retyping every preference, not to gate access to private data. If that trade-off ever stops being acceptable, the endpoint becomes the obvious place to add a magic-link step. As of this page it has not been added.

You sign up again with the new email. There is no profile to migrate, no badge to keep, no streak to recover. The cron's prior-pair guard works on row IDs in the matches table, so the new row is treated as a separate person at the matching layer. If you previously confirmed a match (status = 'ready') under the old email, that flag does not transfer; the new row starts as 'pending'. The two real consequences are that any old confirmation tokens already mailed to the old address become useless once that match expires, and any /meet/[token] link tied to the old row stops being yours. The Google Meet URL itself still works for your buddy because Google Meet's URL is independent of our token.

Nothing stops a person who already has the token, which is exactly how email magic links work everywhere. The defense is that the token is sent to one inbox, is unguessable (UUID-grade), and is single-use for state changes. /api/confirm-match marks the row as 'engaged' on first 'yes' click and refuses to flip the state again. /api/unsubscribe is idempotent: a second hit on an already-unsubscribed token redirects to the success page without re-firing emails or PostHog events, which is in the route at lines 36 to 39. So the threat model is the same as any password-reset link: if your inbox is compromised, the attacker can act on your behalf, and there is no second factor here. For a free, donation-funded peer-pairing tool serving meditators, that has been deemed proportionate.

It does not need to. Each matched pair gets a permanent Google Meet URL written into the meet_links table once, at confirmation time. Each person also gets their own /meet/[token] redirect URL, which is what shows up in their intro email. Every morning, you click that link, the route reads the token, logs a row in meet_clicks (so the operator can tell whether anyone showed up this week), and 302s you to the same Google Meet URL as yesterday. There is no session, no daily login, no auth state to refresh. Bookmark the redirect, add it to a phone home screen, and the daily flow is one tap.

No. Nothing on vipassana.cool teaches the technique. The S.N. Goenka tradition reserves transmission of the technique for authorized assistant teachers inside 10-day residential courses at dhamma.org. This page describes the authentication model of one tool that helps old students sit together. Any question about how to sit, how to work with a sensation, how to handle difficulty on the cushion, or how to structure a daily practice goes to dhamma.org and to an authorized assistant teacher at a 10-day course, not here.