Oficina is getting a video-calling app, working name Meet. Its core gesture is the one every calling product has: make a meeting, send the link, the other person clicks and is in the call. Under the doctrine as written, that gesture is forbidden, and it needs a ruling before the app's spec can be written.
Where it collides
Ruling 15 gives an item three rungs plus one orthogonal capability: a read-only link. It then says every write has a named actor, a member or a guest who signed in and took a grant. Anonymous link editing was rejected by Sheets ruling 12 and rejected again in revision 3.
Sheets built the strict reading of that into code. internal/sheets/handlers_link.go renders a link viewer the scriptless table rather than the live grid, so a link holder is never in the fan-out, and Sheets §8.3 rules that a link viewer gets no presence cursor and no name in the presence stack, because presence is a write to shared awareness state.
A participant who arrives at a call by link publishes a camera and microphone track, a display name, and chat messages, to everyone in the room. Every one of those is a write to shared state. Presence in a call is not a side feature; it is the product. So a read-only link buys a call nothing, and the only shape ruling 15 permits is the Docs commenter link: the link carries you to sign-in, sign-in mints a guest grant, and from there you are a named actor.
The two shapes on the table
A. Sign in to join. The doctrine allows this today with no amendment. Every participant, member or outsider, signs in before joining. An outsider takes a guest grant scoped to that one meeting. The link is a capability to obtain that grant, exactly how Docs builds its commenter link. Cost: the product loses "click and you're in". A person you are meeting for the first time has to complete a magic-link round trip on their phone before they see your face. Benefit: no new vocabulary, every participant has a name the team can trust, ruling 9 holds without a footnote, and the roster and custody rules apply unchanged.
B. An ephemeral participant. A new shape, ruled here and cited by Meet: a link to a live session may admit a participant who is named only by what they typed, for the life of that session, and nothing they write survives it. That is the honest description of what every calling product does. It would need the doctrine to say what makes a session ephemeral (no write outlives the room), how the team sees such a participant (a display name marked as unverified, never on a roster, never a directory row), and that a host admits them (a waiting room), so the write has a named actor at one remove. Cost: a fourth kind of actor, and the first place the doctrine describes state that is not at rest. Benefit: the product works the way people expect a calling product to work.
What Meet would do under each
Under A, the join page is the sign-in page with the meeting sqid as the return path, and the P2P media plane is unchanged. Under B, the join page is the pre-join screen, the host sees a knock, and the signalling server holds the participant's chosen name only in memory.
Neither changes the media plane, the P2P design, or the platform questions filed beside this on carlos/platform. This is purely a doctrine question, and it is the one decision the app's spec cannot be written without.
What I recommend
A, with the waiting room built anyway. It keeps the doctrine whole, and a magic link on a phone is a smaller cost than it sounds when the alternative is a fourth actor kind that only one app uses. If B turns out to be the product Paul wants, it should be ruled as a numbered ruling with its own row in §1 and an Appendix A entry, not inferred by Meet.
---
Filed by 🤖 from the Meet brainstorming session. Meet is not started; this blocks its spec.
amadan