Define accountability partner: not a promise, a recurring Meet URL

An accountability partner, on vipassana.cool, is the other human whose email ends up attached to a specific Google Calendar event with a permanent Meet URL and a daily recurrence rule. The event is created exactly once per pairing by createMeetEvent in src/lib/google-meet.ts, with recurrence set to the string RRULE:FREQ=DAILY. The URL does not rotate, does not expire on a fixed schedule, and does not depend on either party remembering it. From the runtime's point of view, the partnership is that URL. Two people who share one are partners. Two people who do not, are not. Every other attribute the dictionary lists, trust, support, check-ins, is a downstream consequence of the URL being clicked on at the same time by two humans every day.

Because a role description is a description, not a predicate. When a program has to create, track, expire, or retire a partnership, it cannot operate on the sentence 'a person who supports your goals.' It has to operate on something in the database. In this code the smallest object that captures the relation is a row that ties two person ids to one Meet URL, plus a calendar event id, plus two per-person tracking tokens in the meet_links table. Defining the partnership as that artifact, not as a feeling, is what lets the system do any automated work about it. The role description is what people write in essays. The artifact is what a matcher, a calendar API, and a Postgres row all agree on.

src/lib/google-meet.ts line 75 sets recurrence to the one-element array ['RRULE:FREQ=DAILY']. That is the iCalendar recurrence rule for a daily-repeating event, with no end date. The Google Calendar API accepts it verbatim and clones the event on every future calendar day until someone deletes or edits it. The choice is deliberate. A weekly recurrence would produce a partnership that is a commitment you keep once a week, which is closer to a call than to a daily practice. A no-recurrence event is a one-time meeting, not a partnership. Daily is the shortest human cadence that matches a sitting practice, and it is also the cadence that lets the URL become background furniture, opened the same way you open a thermostat app.

The URL is generated by a POST to https://www.googleapis.com/calendar/v3/calendars/primary/events with conferenceDataVersion=1 (src/lib/google-meet.ts lines 86 to 96). The calendar API allocates a fresh meet.google.com conference code and returns it in result.conferenceData.entryPoints. That URL is identical for both halves of the pair. What differs per person is only the tracking wrapper. Confirm-match/route.ts lines 106 to 107 insert two rows into meet_links, one per person, each with its own UUID token. Each person's intro email points at /meet/<their-token>. The /meet/[token] route then looks up the meet_url and redirects to the same underlying meet.google.com link. The tracking is per-person. The room is shared.

The /meet/[token] route, at src/app/meet/[token]/route.ts, looks up the token in meet_links, extracts the meet_url, writes one row to meet_clicks with the token, match_id, person_id, meet_url, request IP, and user agent (lines 26 to 29), then issues an HTTP redirect to the Meet URL. From the meditator's point of view nothing visible happens, they just land inside Google Meet. From the database's point of view a heartbeat just occurred. meet_clicks is how the system knows the partnership is still alive. Two rows a day, roughly at the same time, at the same token pair, mean two humans are still opening the same link. Silence in that table for long enough is what lets anyone looking at the admin dashboard see that a partnership quietly stopped, without anyone announcing it.

No, not under normal operation. The URL is written into meet_links once during confirm-match, and subsequent intro emails reuse the same value. The calendar event carries the same conference entry for every instance of the RRULE:FREQ=DAILY recurrence, so the URL you clicked on day 1 is the URL you click on day 400. The only way the URL changes is if Matt (as the operator) manually edits the calendar event or deletes it and recreates one, and that happens only in a recovery scenario. Link permanence is a design choice. Rotating the URL would be a security answer to a problem the product does not have, at the cost of breaking the one habit the product exists to build.

No, it is the artifact that is necessary but not sufficient. Before the URL is created, seven predicates in the matcher have to pass (see /t/accountability-partner-definition for the full list). The URL is the object the matcher produces after both people click 'yes' on the confirmation email. So the full picture is: the matcher's seven predicates define who is eligible to be partnered, and the URL is what turns a would-be pair into an actual pair the moment both confirmations land. This page is about the second half, the artifact; the sister page is about the first half, the predicate.

By the artifact. A coach has a contract, a fee schedule, a stated scope of work, and an office. A therapist has a license, a calendar in a practice-management system, and a billing code. An accountability partner on this site has none of those. The only formal document that exists is a Google Calendar event id, its one attached Meet URL, a row in a matches table, and a token-linked meet_clicks log. There is no bill. There is no session note. There is no intake form beyond the waitlist. The relation is, deliberately, as thin as it can be and still be automatable. That thinness is what keeps the whole thing free in the dana tradition that the site follows, which is a meaningful constraint the SERP definitions do not notice.

Given the definition-as-artifact, a partnership ends when the artifact ceases to be operative. That happens in one of four ways. One, both people stop clicking the /meet/<token> URLs, the meet_clicks table goes quiet, and neither party asks for a new match; the calendar event keeps firing invites but the room stays empty. Two, the operator deletes or edits the calendar event, which breaks the link for everyone. Three, the confirming state times out before both sides click yes; expire-matches/route.ts removes the match after three days of silence, which means the URL was never created in the first place. Four, one person unsubscribes, which does not delete the URL but does remove them from the matcher's eligible pool and puts their partner back on the waitlist for a replacement. Note that nothing in this list is about feelings. A partnership ends when the artifact becomes inert.

The repo is public. The file that defines the recurrence and the URL allocation is src/lib/google-meet.ts, in particular lines 53 to 114 (the createMeetEvent function) and line 75 (the RRULE:FREQ=DAILY string). The file that creates one URL per pair is src/app/api/confirm-match/route.ts, lines 73 to 101 (the Meet event call) and lines 104 to 109 (the per-person token inserts). The file that logs every URL click is src/app/meet/[token]/route.ts, lines 12 to 29. The file that defines the match lifecycle and the three-day confirmation timeout is src/app/api/expire-matches/route.ts. The matcher file that determines eligibility (but not the URL) is src/app/api/auto-match/route.ts. Between those five files every concrete claim this page makes is checkable in under a minute.