From 7980aafbd973d7e15c4549a1f8e892b11bd47a7d Mon Sep 17 00:00:00 2001 From: KernelDeimos Date: Thu, 17 Oct 2024 01:19:06 -0400 Subject: [PATCH] doc: add devlog from puter.js --- src/puter-js/doc/devlog.md | 49 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 49 insertions(+) create mode 100644 src/puter-js/doc/devlog.md diff --git a/src/puter-js/doc/devlog.md b/src/puter-js/doc/devlog.md new file mode 100644 index 00000000..d50ca160 --- /dev/null +++ b/src/puter-js/doc/devlog.md @@ -0,0 +1,49 @@ +## 2024-10-14 + +### Letting Puter Desktop Control Client FS Cache + +#### Move Context to `putility` + +The Filesystem module for puter.js will need to check `puter.env` to determine +whether it's delegating client FS calls to Puter's API or Puter's Desktop via +postMessage. `env` was already being passed to the Filesystem module via its +constructor but the constructor had no reference to it; having only looked at +the constructor itself and not where its initialized, I didn't realize this +and started working on another way to pass it. + +I decided to add Context which will allow us to incrementally migrate all the +modules to a situation where the things available to modules generally is one +piece of information in the code, and doesn't need to be repeated for each +constructor call manually. + +### What happens when apps make FS calls to Puter's desktop? + +I'm going to describe a problem that I overlooked before I started working on +this. If `env` is `"app"`, then we delegate filesystem calls to Puter's desktop +so that caching is centralized and all apps can benefit from the cache. Okay, +that's great, but... **Puter Desktop has user privileges, not app privileges.** + +With this, I see a couple of options: +- Puter desktop makes the call to check ACL + - we don't expose this yet + we need to ensure it doesn't expose the existence of files for which the + actor does not have "see" permission. +- Apps maintain their own cache + +In either case, apps need to be able to subscribe to filesystem events for +cache invalidation. This means the file/location relevant to the event needs +an ACL check either way. It seems there is no choice but to allow Puter Desktop +to expose ACL. + +I thought about adding this to `/stat` - i.e. Desktop can pass an app ID and +get information about what kind of access the app has - but that would incur +additional database calls for no reason, especially if Desktop really does +have that entry cached already. + +This will require a new endpoint then: `/auth/check-app-acl`. I'll put it in +PermissionAPIService for now. It seems a little out of place there but it +also doesn't seem to make sense to create a new service for it. +This method may eventually be deprecated if we find out apps need to be +able to perform ACL checks on behalf of delegate apps, in which case we might +create a more general-purpose `/auth/check-acl` endpoint that can cover +both cases.