LWS access grants (documents under .lws/grants/ that say "agent X may Read /alice/photos/") must add permissions on top of WAC. src/wac/checker.js only consults ACL files; a plugin can store grants but can't make them count.
Proposal
api.wac.registerReader(async({ url, agent, mode, isContainer })=>{// return true to grant, false/undefined to abstain. Readers can only ADD.});
Checker evaluates ACLs first; if denied, consults registered readers in order; any true grants.
Readers can never remove a permission the ACL grants — same rule Jesse applied ("grants only add to WAC/ACP; deleting one revokes it").
Readers are not consulted for .acl resources or for paths under api.reservePath reservations, to keep ACL editing and protocol-pinned paths under core control.
Per-request memo so a reader isn't called twice for the same (url, agent, mode).
Prior art: AccessGrantReader + UnionPermissionReader in jeswr/LinkedWebStorage (PR #124 body describes the constraint semantics — exact non-recursive targets, type filter, client/format/dateTime constraints, foaf:Agent for public).
Related: #604 (api.authorize — a plugin asking the host's WAC). This one is the inverse direction: a plugin adding to the host's WAC decision. Both are needed for LWS access grants on host-pod resources (#621); lwsd's ODRL engine (linkedwebstorage/lwsd lws/access.js) already does the grant evaluation for plugin-owned storage, so this seam is what would let it apply to /alice/… too.
Activity
melvincarvalho commented on Oct 14, 2026
Related: #604 (api.authorize — a plugin asking the host's WAC). This one is the inverse direction: a plugin adding to the host's WAC decision. Both are needed for LWS access grants on host-pod resources (#621); lwsd's ODRL engine (linkedwebstorage/lwsd lws/access.js) already does the grant evaluation for plugin-owned storage, so this seam is what would let it apply to /alice/… too.