From 66cf679aabe3d82f54fc7267fb7960945d572727 Mon Sep 17 00:00:00 2001 From: jelveh Date: Mon, 15 Dec 2025 13:59:53 -0800 Subject: [PATCH] Delete devlog.md --- src/puter-js/doc/devlog.md | 49 -------------------------------------- 1 file changed, 49 deletions(-) delete mode 100644 src/puter-js/doc/devlog.md diff --git a/src/puter-js/doc/devlog.md b/src/puter-js/doc/devlog.md deleted file mode 100644 index d50ca1609..000000000 --- a/src/puter-js/doc/devlog.md +++ /dev/null @@ -1,49 +0,0 @@ -## 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.