Incorrect assumption about user's Pod and URL (incl. path) -- inconsistent UI behaviour for SolidOS

[renyuneyun]

I'm experiencing this issue since the beginning of me attempting it (i.e. Feburary 2022). It actually happens on all status of mashlib -- SolidOS Web App, https://solidcommunity.net and my custom CSS with mashlib recipe set up. It is most noticeable with a CSS set up, compared to https://solidcommunity.net (or other similar services). This is because on https://solidcommunity.net, each user's pod is on a (sub-)domain (hostname), not on a sub-directory under a hostname.

My CSS server has user pods in different (sub-)directories, and there is no "root" pod account. Assume the server's address is https://MY_SERVER, and the user is MY_USER.

Open https://MY_SERVER, after logging-in, the UI is (seemingly) in the expected state, as seen in the figure below.

However, the user is not redirected to its own pod (https://MY_SERVER/MY_USER/), but is still on the root of the server (https://MY_SERVER/). This can be verified by clicking on "your storage", which will list all files and folders under the root folder https://MY_SERVER/ (in this set-up, there is only one account, i.e. MY_USER).

This is not very intuitive, but still acceptable.

After manually navigating to https://MY_SERVER/MY_USER/, the UI appears as if it's browsing the folder only:

However, because this is the actual pod of the user MY_USER, I would expect it to show the same set of navbar/menubar as seen in the first figure, with "your stuffs" and other menu items.

This can (almost) be obtained by clicking on "your stuff" from the user icon's menu (on the top-right corner).

However, this is still not exactly the same as in the first figure: the navbar with icons is still missing (see the figure below which highlights the missing part). I did not find a way to make them appear.

So, in conclusion, it seems mashlib is only showing the full UI (as seen in the first figure) when on the root of the hostname (e.g. https://MY_SERVER/). This has an assumption that the user pod is on the hostname, which is incorrect in many CSS set-ups.

[jeff-zucker]

When you login on pageX, SolidOS redirects you to pageX. That is the expected behavior and unlikely to change. The page you start on is the top of your folder tree and treated as "home". The home menu and buttons only appear on the home page. So they are not expected to appear on any subfolders of the folder tree.

You say that the server is making an incorrect assumption - it is not incorrect to treat the top of the folder tree as home. This is different from assuming that the user owns the server root, it only says, the user wants to start looking at the folder tree at the server root. To test whether it actually makes the assumption that the user owns the server root - login at the server root and select "edit your profile". I think you will see that it is your profile, not the server root profile. So no assumption is made about the owner of the server root, only that you want to look at it.

Does this make sense?

[renyuneyun]

@jeff-zucker Thanks for the explanation. I may have phrased that incorrectly. By "user owns the serve root", I mean the "user's home / starting-point is the server root".

To put it in a nutshell, "home" should be the user's own place, not the server's base (document root).

You say that the server is making an incorrect assumption - it is not incorrect to treat the top of the folder tree as home.

For CSS, it is incorrect to assume that. For most predefined CSS configurations, the user pods are not at the server root (except for one potential "root" user), and they are at the sub-folders of the folder tree (from the server's document root).

A Solid server can and will have lots of users. Therefore, in the current behaviour, when the user opens the "folder"/"storage" view, it will see lots of folders from other users, and would need to spend time looking for its own folder, if that is ever findable within a short period of time. If the user wants to avoid that and put https://MY_SERVER/MY_USER/ to the address bar, then mashlib will only display "file management" and most UIs are gone (i.e. Figure 3).

If the above still does not directly demonstrate the problem, I would draw an analogy:

The current behaviour is like starting a shell (on Unix) with fixed starting directory to / (or /home/) instead of /home/MY_USER/, and the user has no way to change that. What's worse, in a shell, you can cd into your directory while everything else works without problems. In current mashlib, if you cd into your directory (opening https://MY_SERVER/MY_USER/), lots of commands are gone (many parts of the UI disappear).

Surely, both settings will work and can accomplish same tasks. But the current behaviour is quite cumbersome.

You argued that the profile is correct and the rest of the functionalities are correct. I agree with that. But that is a different question. "It functions correctly" means the environmental variables are correct (and the underlying logic works). But the problem is with the unintuitive starting location and missing commands after cd.

Functionality and user experience are different things.

When you login on pageX, SolidOS redirects you to pageX.

I understand that. In my mind, I would suggest adding a button (e.g. to the user icon's menu) to "go to me home" (probably replacing "your stuffs" and/or "your storage").

[jeff-zucker]

This is not an issue of SolidOS, it is an issue of the server. If the server wants to expose all its users , it should be able to.

I would suggest adding a button (e.g. to the user icon's menu) to "go to me home"

That is, in fact what NSS on solidcommunity.net and inrupt.net do. If you login to the server root, you get a button to your pod root. The host (whomever hosts an instance of a server) is responsible for what a user sees at server root.

Basically there is no reason to ever login at the server root except the first time after you sign up. Why would you want to do that? If you decide to login at the server root instead of your own pod, it's not the software's job to say "oh you probably didn't mean to do that".

As to the notion of "home" - I would agree that the current behavior does not fit very well with a full notion of what a pod home could be. The SolidOS team team is actively pursuing that and we'll hopefully have some big changes pretty soon.

[jeff-zucker]

Because of the way authentication currently works you MUST be authenticated on the domain you want to access. If you authenticate at server root and it is on a different domain from your pod, the authentication will not apply to your pod. So really, you should never login to server root except when you are first signing up or when you have a single-user server.

[renyuneyun]

This is not an issue of SolidOS, it is an issue of the server. If the server wants to expose all its users , it should be able to. Basically there is no reason to ever login at the server root except the first time after you sign up.

I believe there are some misunderstanding. This issue is not arguing whether the user should click log-in at server root or its own pod. I agree with everything you say about that part. (Problem re-explained later.)

That is, in fact what NSS on solidcommunity.net and inrupt.net do. If you login to the server root, you get a button to your pod root.

Yes there is. But the reason it works without issues is because of the assumption that my pod is on the hostname (sub-domain) -- same problem as I was trying to get through earlier in this issue.

As to the notion of "home" - I would agree that the current behavior does not fit very well with a full notion of what a pod home could be.

That sounds like great news. But I'm not sure if we are talking about the same problem, so I'll summarize my problem again, after the discussions and points-of-view being brought in.

---

The problem is with the behaviour of SolidOS/mashlib. It is not an issue with the server -- unless you say "an assumption made in a client app must be satisfied by all servers, otherwise it is the server's issue".

Problem

Again: SolidOS/mashlib should not assume that the user's pod IS the server's root, in all cases, in anywhere.

At the moment, part of it does not have this assumption (the environmental variable analogy), while part of it has (the starting location analogy).

Behaviour

From the suer's perspective, SolidOS/mashlib should work in the same way regardless of the server's choice. But at the moment, it does not. It should have the same UI as in Figure 1, regardless of if I visit https://MY_SERVER/MY_USER/ or https://MY_SERVER/ . But at the moment, it only gives Figure 3 if I visit https://MY_SERVER/MY_USER/. And, in that case, there is no way to get a UI like Figure 1.

Solution

This can be "fixed" on mashlib, to make it show the full UI for all URLs (folder levels), or to have a way to show the full UI (e.g. a toggle). Or, a more cleaver method may be developed, if there can be a standard to specify the "user's home" (or whatever). This may be complicated, as you mentioned,, if the user's authentication is not on the current server, and/or when the same WebID is associated with multiple pods.

[jeff-zucker]

Yes there is. But the reason it works without issues is because of the assumption that my pod is on the hostname (sub-domain) -- same problem as I was trying to get through earlier in this issue.

That is really not what is going on. What is going on is that CSS does not supply any UI for its server root. ESS and NSS both have a UI that prevents the user from seeing the container at the server root and CSS instead lets you look at the actual container. There aren't currently any actual production level CSS servers. When there are. I suspect that they will have a UI to also prevent seeing the root. If they don't, it is not the business of software to prevent that.

As I mentioned we are working on a completely different solution for user home that will divorce it from it's dependence on the folder tree. I believe it will make the issue you mention go away but not by altering the server root behavior.

This may be complicated, as you mentioned,, if the user's authentication is not on the current server,

No, it's not complicated, it's impossible. You can't login on domain A and expect to access domain B without logging in again.

[jeff-zucker]

I do agree with you that there is a problem but I disagree that it has anything to do with domains (the same problem would occur on NSS if it didn't have a UI to prevent it) or with server root. It has to do with the fact that currently SolidOS conflates "home" and "top of current browsing tree". That is what needs to be fixed and once that is fixed, the other problem will go away.

[renyuneyun]

Hi. I learned that this is expected to be fixed by also a change in servers:

• Servers add the home (root of pod) information in the response header; and
• SolidOS picks up that information and renders accordingly.

Just wondering what is the current status for that? Has CSS or NSS already support that header?

[bourgeoa]

Hi. I learned that this is expected to be fixed by also a change in servers:

Have you some links ?

[ewingson]

this affects me on solidweb.me and I follow attentively. FYI: doing a curl -i https://solidweb.me no longer reveals info about the root of the tree. I solved it by redirecting to https://solidweb.me/somewhereelse/index.html

what can I do to gather info, recherche or somehow help ?

[renyuneyun]

Have you some links ?

Unfortunately no. It was from a discussion with Tim last month. IIRC, he mentioned the introduction of home location was on the task board.

[ewingson]

@jeff-zucker @RubenVerborgh @bourgeoa @joachimvh @madnificent @timea-solid @SharonStrats @timbl ?

where is the Server's root pod (normally, default) stored in the filesystem ? is that just the root of the tree (so /var/www/ ) ?

trying to understand.

I have redirected the root pod to https://URI/somewhere/index.html but now am working on another instance.

I am trying to offer a login button. on solidweb I have only a sign-up link in the custom index.html but I have the feeling a login button (to mashlib=to SolidOS) belongs there, too