positioning.md and competition-relay.md credit Relay with RBAC they do not ship #74

New issue

Closed

opened 2026-09-21 18:07:08 +01:00 by cruelacid · 1 comment

cruelacid commented

2026-09-21 18:07:08 +01:00

Owner

Part of #37.

The error

Both documents list role-based access control among the things Relay does
better. docs/positioning.md: "Canvas multiplayer, SSO, role-based access
control, Git sync...". docs/competition-relay.md has it in the "Where Relay is
ahead" table as "Role-based access, private folders | Partial".

Relay does not ship read-only access. Their documentation states it outright,
and enableReaderRole in src/flags.ts defaults to false and is undocumented.
What they actually ship is private shared folders — subsetting which members
of a server may access a folder — which we already have via folder_members.

So we have been conceding a gap that does not exist, in the document that decides
what we say publicly.

Why it matters beyond accuracy

docs/positioning.md frames read-only as "the one weakness to own", with the
argument that "Relay offers RBAC cheaply precisely because their server reads
your notes." That argument is still correct in principle — but the framing
should say that neither product ships read-only today, and that our route to
it (#39 then #62) is a stronger one because it survives the server not being able
to read anything.

What to do

Correct both documents, keeping the existing sourcing discipline: every claim
carries a URL and a read date.
Rewrite "the one weakness to own" to say neither ships it and why ours will be
enforceable when it lands.
Do not overcorrect into claiming we are ahead. We are not, yet — #62 is
unscheduled.

Part of #37. ## The error Both documents list **role-based access control** among the things Relay does better. `docs/positioning.md`: *"Canvas multiplayer, SSO, role-based access control, Git sync..."*. `docs/competition-relay.md` has it in the "Where Relay is ahead" table as *"Role-based access, private folders | Partial"*. **Relay does not ship read-only access.** Their documentation states it outright, and `enableReaderRole` in `src/flags.ts` defaults to `false` and is undocumented. What they actually ship is **private shared folders** — subsetting which members of a server may access a folder — **which we already have** via `folder_members`. So we have been conceding a gap that does not exist, in the document that decides what we say publicly. ## Why it matters beyond accuracy `docs/positioning.md` frames read-only as "the one weakness to own", with the argument that *"Relay offers RBAC cheaply precisely because their server reads your notes."* That argument is still correct in principle — but the framing should say that **neither product ships read-only today**, and that our route to it (#39 then #62) is a stronger one because it survives the server not being able to read anything. ## What to do - Correct both documents, keeping the existing sourcing discipline: every claim carries a URL and a read date. - Rewrite "the one weakness to own" to say neither ships it and why ours will be enforceable when it lands. - Do **not** overcorrect into claiming we are ahead. We are not, yet — #62 is unscheduled.

cruelacid added this to the Backlog - unscheduled milestone

2026-09-21 18:07:08 +01:00

cruelacid added the

area:docs

label

2026-09-21 18:07:08 +01:00

cruelacid modified the milestone from Backlog - unscheduled to Phase 15 - Retention and enrolment

2026-09-21 18:07:45 +01:00

cruelacid added the

parity

label

2026-09-21 18:08:29 +01:00