No homepage when not creating a root Pod

[woutermont]

Trying to work with a file backend in v2.0.0, I noticed that there are now two preset file configurations: file.json and file-no-setup.json. However, neither seems to provide the same experience as the v1.1.0 file configuration, where a new account could easily be created from the homepage.

It would be nice to have at least one preset import initialize-prefilled-root.json, preferably the file.json one used in the start:file script by default. People who want to setup a headless server are i.m.o. more likely to change the config anyway.

[RubenVerborgh]

However, neither seems to provide the same experience as the v1.1.0 file configuration, where a new account could easily be created from the homepage.

That should still be the case. Could you walk us through your experience?

file-no-setup.json should give you the exact v1.1.0 experience; and file.json should give you that after a setup step.

[RubenVerborgh]

I have tried file-no-setup.json myself and it serves the current folder as expected. New accounts can be registered from http://localhost:3000/idp/register/

[woutermont]

Ah, well, then something goes wrong in both cases:

• The v1.1.0 file.json creates an .acl, .meta and index.html in the root. When I browse to the root URL, it serves me the index.html.
• The v2.0.0 (main) file.json initially creates nothing. When I browse to the root URL, it redirects to the setup URL. If I click "Complete setup", it congratulates me saying "You can now visit its homepage." When I (re)visit the root URL (by following the homepage link), however, I get a 403: "No ACL document found for root container".
• The v2.0.0 (main) file-no-setup.json creates an .acl and a .meta , but no index.html, in the root. When I browse to the root URL, I simply see a page saying "Contents of localhost:3000". The setup URL, for obvious reasons, returns a 404.

[RubenVerborgh]

* If I click "Complete setup",

Did you choose to create a root pod though?

[RubenVerborgh]

* The `v2.0.0` (`main`) `file-no-setup.json` creates an `.acl` and a `.meta` , but no `index.html`, in the root.

@joachimvh Do we want to create the HTML file there too? It might be confusing to do so, because that would disable the listing.

[woutermont]

• If I click "Complete setup",

Did you choose to create a root pod though?

No. I find it unintuitive that a root pod should be necessary to serve the homepage: I see the homepage as a static feature, independent of the question whether or not I can access the root URL as a pod. Even more so, when lacking a root pod, one cannot add a homepage oneself, so the option to have one set up is especially important.

[joachimvh]

If you want behaviour similar to 1.1.0 using setup, you need to check the Expose a public root Pod checkbox. This will create the root acl. Note that this is different from registering an account and choosing to have your storage be the root container instead of its own namespace. Perhaps phrasing could be better for that option. One of the main reasons for having the setup is to not immediately write public acl resources to folders on a users disk just because they started the server.

• The v2.0.0 (main) file-no-setup.json creates an .acl and a .meta , but no index.html, in the root.

@joachimvh Do we want to create the HTML file there too? It might be confusing to do so, because that would disable the listing.

The difference between the initialize-root and initialize-prefilled-root options currently is indeed only a single index.html file. The file-no-setup config has the first, while the default (memory) config has the second (and of course file has neither and uses setup).

First, the reason for file being the one with setup is because new users are more likely to use that one. And new users are specifically those we want to target with the setup. Which is why the "no setup" versions are the special ones instead of the reverse. I was initially planning to not even have those no-setup ones since they can be made by changing 1-2 imports 😅 .

The reason file-no-setup does not have the index.html is because we made the assumption that if you decide not to need a setup, you probably are also an advanced enough user to not need an index.html explaining you how everything works. Eventually the plan is to eventually have more resources in the prefilled option besides that index.html, see #957.

In the end there's a limit to how many default configurations we can provide. The idea was always that users could fine tune a config to their specific requirements and the default ones are there to help them along, and provide the most common cases we assume might be needed.

If I click "Complete setup", it congratulates me saying "You can now visit its homepage." When I (re)visit the root URL (by following the homepage link), however, I get a 403: "No ACL document found for root container".

I don't disagree that this is not perfect, related discussion here: https://github.com/solid/community-server/pull/951#issuecomment-926441171

[woutermont]

Hm, I read your reply twice, @joachimvh, and it feels like we're arguing past eachother.

First, the reason for file being the one with setup [...]

No problem with that; totally agree.

The reason file-no-setup does not have the index.html [...]

Again, we're of the same mind here.

What I do argue, is that when using file.json (like you said: the one that targets new users), after the user has done the setup, the user should not be invited to "visit [the server's] homepage" and then get a 403 instead. So either we change the setup's confirmation message, or we add the index.html and .acl files. Keeping in mind those new users who, even with the changed message, should totally be forgiven for intuitively browsing to the root URL after setup, I would opt for the second option.

Before you repeat that they "need to check the Expose a public root pod checkbox": even if that option would be phrased better, there is still a difference between:

• exposing the root to public read and write access, which is what that option does, but which we definitely don't want to enable by default for new users; and
• enabling read-only access to a single static index.html homepage, which new users would i.m.o. totally benefit from being the default.

(I do realise that while I mentioned the v1.1.0 experience in the OP, this is actually not entirely what I'm asking here. What I meant was indeed the beginner-friendly subset of its defaults, enabling a visual guide to non-root pod creation.)

[RubenVerborgh]

So either we change the setup's confirmation message

That's an option; it does make the template conditional etc., so a bit more programming work than just changing it.

or we add the index.html and .acl files.

That is not an option, because that requires a pod to exist. And the user has just opted not to have one.

The danger here, which we should all be very well aware of, is that this configuration writes things to the user's actual disk. So things might be overwritten etc. We are erring on the side of carefulness.

* enabling read-only access to a single static `index.html` homepage, which new users would i.m.o. totally benefit from being the default.

But then it wouldn't be a pod, they'll want to change it, they will ask for help here, etc.

Not to mention that they can still create a root pod after setup.

A single static index.html is possible, it's just a question of how we'll wire it. Maybe indeed, when "no root pod" is chosen, a small static in-memory root pod could be wired?

---

TL;DR: fixing the link is easiest.

[joachimvh]

(I do realise that while I mentioned the v1.1.0 experience in the OP, this is actually not entirely what I'm asking here. What I meant was indeed the beginner-friendly subset of its defaults, enabling a visual guide to non-root pod creation.)

I guess it makes sense we're talking next to each other if we're starting from a different premise 😄 .

The idea (hope?) is that users get enough information from the setup page and the confirmation page afterwards to help them along.

@RubenVerborgh

Not to mention that they can still create a root pod after setup.

Not sure if I interpret this correctly but this is not true. If you choose not to make the root accessible during setup there is no way at all to still create something in the root afterwards, besides editing the file system manually of course.

Maybe indeed, when "no root pod" is chosen, a small static in-memory root pod could be wired?

This sounds a lot more complex than writing a read-only acl to the root together with an index.html when no root option is chosen during setup. Then users can still remove it if they want to by removing the files from the file system. This is still not ideal though since this should preferably never be needed.

[joachimvh]

Setup is being removed in https://github.com/CommunitySolidServer/CommunitySolidServer/pull/1677 and all configs will have some form of intro page.