[JMAP] Re: [Jmap] JMAP File Storage extension comments

[Bron Gondwana <[e-mail]>]

On Mon, Apr 28, 2025, at 11:07, Mauro De Gennaro wrote:
> Hi Bron,
> 
> I have (partially) implemented the JMAP File Storage draft and wanted to share a few comments and ideas based on my experience so far:

(Digging up this old email)

> - Section 4.1: I think the mayDelete property should be added to the FilesRights object.

Returning to this as I try to update the spec.  My understanding of 'mayDelete' on a Node is that it's basically 'mayWrite' on the parent directory.  At least, in the "inode" model of filesystems, the directory is a list of names and metadata (including the inode of the data); and when you deferences the last pointer to the underlying data, then it can be garbage collected.

So I'm not sure how I would implement "mayDelete" as a separate property.  I'd just derive it from the parent, as a read-only piece of metadata.

> - Also related to ACLs, it would be helpful if the specification provided some guidance on ACL inheritance when creating a child FileNode. Specifically, should the ACLs of the parent be automatically inherited by the child, or is this entirely left to server implementation? Since we don’t have child specific rights like mayReadItems, mayModifyItems, or mayDeleteItems on the parent object (as we do in other JMAP objects), some clarification on best practices for setting permissions on new child nodes would be nice to have.

I answered this back then, but I'll update the text to say "ACLs are copied from parent on create if not explicitly set".

> - Invalid Parent Set Error: It would be good to define an explicit error condition for cases where a client attempts to create a FileNode under a parent node that has a blobId property (i.e., when trying to create a folder or file under a file, which should not be allowed).

This should, I think, just be an invalidProperties error with parentId as the property; and maybe some description text saying "parentId refers to a non-Directory node".

This might be a good example to put in the spec!

> - Metadata Storage: This is more of a general idea, it might be valuable to allow storing custom metadata within a FileNode, somewhat akin to WebDAV’s "dead properties”. For example, if the extension is used for photo storage, a client might want to store photo location data or other attributes and be able to search for them later. This could also be defined in a separate extension for searchable object metadata in JMAP objects.

This can of worms is still a can of worms.  Particularly if we want to store something that's structured and searchable like GEO data, then we'd need to have server support for using GEO algorithms on the data for things like "within 10km of X,Y", which is definitely not something you could do with a generic metadata system.  It would be much more powerful to have an extension that defined a geo property, and indexed on it.

...

I'd rather not do that in base filenode.  I also did analysis of what Fastmail's existing filestorage had in terms of webdav DEAD properties, and they were all variants on created/updated fields.

So I'd like to do a base filenode spec which gives a bare bones filesystem, and if we want to have a way to store rich, searchable metadata, make that a separate extension.

Bron.

--
  Bron Gondwana, CEO, Fastmail Pty Ltd / Fastmail US LLC
  [e-mail]