|
|
@@ -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.
|
KernelDeimos