The current user model (Administrator/Editor/Author/Contributor) works for a single-site blog but won't scale to multi-tenant or permission-delegation use cases.
The plugin capability manifest system is well-designed for plugin authZ. The gap is in user/content authZ — e.g. "user A can edit posts in collection X but not Y", or "user A can delegate draft review to user B".
A Zanzibar-style tuple-based authZ model (subject, relation, object) maps cleanly onto D1 and would complement the existing session layer without replacing the authn design.
Proof of concept: zanzojs feat/better-auth-plugin
Question: is the authZ layer intended to be pluggable, or is the 4-role model a fixed design decision?
The current user model (Administrator/Editor/Author/Contributor) works for a single-site blog but won't scale to multi-tenant or permission-delegation use cases.
The plugin capability manifest system is well-designed for plugin authZ. The gap is in user/content authZ — e.g. "user A can edit posts in collection X but not Y", or "user A can delegate draft review to user B".
A Zanzibar-style tuple-based authZ model (subject, relation, object) maps cleanly onto D1 and would complement the existing session layer without replacing the authn design.
Proof of concept: zanzojs feat/better-auth-plugin
Question: is the authZ layer intended to be pluggable, or is the 4-role model a fixed design decision?