solid-spec
solid-spec copied to clipboard
solid
Is /public really such a good idea?
This is a spin-off from #127 where we touched upon the /public folder. That discussion has lead me to think that having a default /public folder is misleading.
Take for instance my hypothetical photo collection in my POD - some of those photos are public, some are not, and some photos become public after a while, while others might get hidden at a later time.
Storing my photos under /public indicates that they are, well, public. Does that mean I should move them from the public container once I want to hide them? That would imply that my photos need to change URL every now and then I choose to change their visibility.
You can repeat the same argument for all sorts of thing - leading to the conclusion that you should not provide a default /public container for PODs since an "implementation detail" like access should not be reflected in the URL.
Feel free to close this issue immediately if I am completely off track ...
You're on track. Needless to say, ACL is per resource. It is just that /public/ was deemed to be a convenient location out of the box for... public stuff.
History: we used to use Workspaces (see different ones in pim/space ) but later came to the conclusion that it wasn't overall convenient to work with pre-set (maybe even arbitrary) containers, and along the lines of what you're saying - there was the intention of mimicking desktop directory organisation by some OS. So, something like /public/ is a bit along those lines ie. having a shared/public location as a start-off. Nothing particularly beyond that.
Well, if it is Window's "Public" folder you are refering to, then it seems like a unfortunate choice (retrospectively).
-
You are not supposed to change permissions on the Windows Public folder and it's sub-folders. You can do that in a POD.
-
The Windows Public folder was not intentioned to be linked from other computers, so it doesn't matter much if stuff moves in and out of it. In Solid we want resources to have a stable URL.
Suggestion: if Solid offers a /public root folder by default, then maybe it should also offer another default folder which is for all the stuff you do not intent to share by default (but can share at some later time, so it should not be named /private).
Does that mean I should move them from the public container once I want to hide them?
Normally yes.
Public is just a default folder with permissions for public to read it. You can think of it as a solid equivalent to public_html
You are free to have private folders inside it, change the defaults, or create whole new folders. public is just for convenience.
@JornWildt Shall I move this issue to node-solid-server? As /public seems not to be part of the spec, but rather a convention used there (and you bring good reasons to consider changes).
https://github.com/solid/solid-spec/blob/master/recommendations-server.md#default-containers
Mmm, search missed this. So we should think about it here first.
The spec only recommends and does not mandate, but I think recommending is too much. It can suggest at best; otherwise clients will start relying on hard-coded paths.
Having /public etc gives the wrong impression about permissions from a UI perspective.
Having /public etc gives the wrong impression about permissions from a UI perspective.
In what sense? I thought it was just a place to put files you want to share with the whole world?
@JornWildt I didn't refer to any specific OS or their inner functionality. It was about the general notion of having a "public" read space that's close to what some systems to do. It evolved out of the experience on Workspaces.
In the absence of a container's own .acl, it will inherit the policies from parent containers to its own resources. So, /private/ (or /foo/) by default would be private. Again, it was about convenience to have a public space (with its ACL set as such) by default. The naming is ultimately irrelevant.
I have been assuming that all items in a pod have a url not tied to a folder (the graph node approach) in that you can have the same item in many different folders. So for the initial question, you could have a "contain" to a public folder while you want the picture public while that same picture might be in many other folders. You simply delete the "contain" for the public folder when you want to remove it from public view without adjusting any other contains associated with it.
By default, my pod approach uses integer based nodes for data that simply increment up as things are added. (eg: https://frederick.graphmetrix.net/node/153 ) giving complete freedom on what that item is and where it can live in the container structure.
In what sense? I thought it was just a place to put files you want to share with the whole world?
Yeah, and that's what @JornWildt seems to be pointing out.
It creates the perception that Solid permissions are based on the folders you put things into, which is of course not true. It also means that you would have to decide upfront what permission you would want a file to have. As you wrote:
You are free to have private folders inside it, change the defaults, or create whole new folders. public is just for convenience.
So this creates the following usability questions for newcomers:
- Are files in my public folder always public?
- Can I have private files in my public folder?
- Is everything in my private folder private?
- Can I have public files in my private folder? Which even makes it a security matter (if a lack of usability makes people accidentally do insecure things).
Such questions do not arise if we do not put suggestions regarding permissions in folder names. It's at least worth considering.
If not already specified somewhere, what needs to be (better) documented is along the lines of:
- storage root is set to private.
- unless new containers specify their own policy, they will inherit from parent.
- profile, public, private, foo, bar, baz... has policy x,y,z by default, but they can be changed at container or per resource level.
- ..
As far as a "spec" is concerned, it shouldn't prescribe any location as fixed. It can of course exemplify, but the location of containers/resources, and their ACLs, for the most part is ultimately implementation specific. So, what goes into the spec is a common agreement / practice on the basic defaults eg. root is private, stuff inherits. Move the template-based information into implementation's own documentation. That way, the solid-spec is not revolving around node-solid-server but a broader consensus on the core mechanisms across implementations.
I think the language can be changed a bit.
So firstly it says recommendation, meaning it's optional, not required. That's good. However w3c specs are also RECs, so that's quite strong in terminology.
What is needed is a minimalist Solid web server spec that you can, say, just point at a file system. There are many web servers out there, that you can just do that. What it will do is serve files, respect headers, respect .acls, allow globbing and allow the web sockets. All the core stuff.
Then we need a spec for those solid servers that will also be a webid provider, and provide space, with default folders -- ie account creation. That can be a modular spec that is an optional extra.
You can have a spec as a social and app provider with default folders and the like. Sort of like an Ubuntu type layer on top of the bare core.
Then finally you can have a spec that will be an identity provider too.
But having a core solid spec that is minimal and people can implement as a hobby project is a nice way to go. I worry that the spec itself gets gamed, but if we have a core solid spec that adheres to the read write principles that we worked out over 10 years, we can put more optional stuff in extra specs, and that will keep it as relatively pure hopefully for a long time.
I strongly support this idea of layered compatibility.
This applies to various aspects of Solid, for instance, also with regard to vocabularies and footprints.
We all need to agree on one core, and depending on the type of app you are, on one or more optional specs. (Support for specs should be explicitly indicated and discoverable to make this work.)
I also strongly support this idea of layered compatibility.
The simplification would allow somebody like myself, with limited time, to implement and utilize.
Also agreeing here :-) Let the core spec be minimal and leave it to the various "distributions" / POD providers to decide what kinds of folders they find good to create when registering a new account.
My original point about /public should then be closed here and moved somewhere else - probably solid-node-server as that is the only POD provider at the moment.
Thanks a lot for your input.