Node-solid-server: Change handling of root index.html/"homepage" of PODs that have no meta-tag for `solid-allow-automatic-updates`

[megoth]

A solution for updating root index.html/"homepage" of PODs was implemented in https://github.com/solid/node-solid-server/pull/953. The handling this PR introduced might not be optimal, and we should at explore what can be done.

The PR made it so that when you run npm run solid updateindex the following checks are done:

1. No meta-tag for solid-allow-automatic-updates --> do update
2. solid-allow-automatic-updates is set to true --> do update
3. solid-allow-automatic-updates is set to false (or anything beside true really) --> do not update

As discussed in https://github.com/solid/node-solid-server/issues/951, number 1 should might be handled. The problem is when users have done updates to their index.html and aren't aware of solid-allow-automatic-updates.

A proposed solution to this is to check each index.html with the previous version of index.html, and only update if the index.html we want to update is equal to the previous version (i.e. there has been no changes). This intuitively feels like a good solution.

The problem is which version should we check against?

• The version in config: There's a system that copies over template files to a config-directory upon starting the server. This can represent the last version maintained by the POD provider. But this will probably miss a lot of older accounts created before the last upgraded version; this is a good solution if the script is run after each upgrade of the index.html.
• All previous version: The idea is to have a list of all iterations of index.html, and if the current index.html matches one of them, we know that it can be upgraded. The problem with this approach is that it can get a bit cumbersome to maintain the list of iterations and I suspect at some point it will get very performance heavy to iterate _all_ iterations for _all_ users.

The latter solutions requires maintaining a list of index.html, and I don't think this is a good solution. Both solutions require fetching data about the user to generate the file to check against previous version(s). This will increase the performance cost of running the script.

Performance might not be a big problem since these are scripts that should be run seldomly.

Personally I think this is not going to be a big problem, since users that care enough to customize their root index.html will also care enough to find info about solid-allow-automatic-updates (although I understand it's a custom meta-tag, and might not be easily found).

The biggest problem I have with simply updating the file is that it kind of violates the sovereignty of the POD. But I think this is OK for most users, and those who aren't ok with that have a mechanism to prevent it. So although it's philosophically a bit "on the edge", I favor the solution for its pragmatic reasons: I assume most people want to have their "homepage" auto-updated by default. (But, as always, I'm very much open to be challenged and convinced otherwise on this.)

[megoth]

This issue was created right before christmas, so I believe it was forgotten. We need to discuss this further, to find a solution that we are happy with. Maybe @RubenVerborgh , @rubensworks , @joachimvh, @kjetilk or @dmitrizagidulin has some input?

[kjetilk]

Good catch! This is something we need to release 5.0.0, right?

[megoth]

Good catch! This is something we need to release 5.0.0, right?

Yes, and we should have the default behavior sorted out before we deploy the first public release.

(Default behaviour --> What to do when no meta-tag is given at all)

[kjetilk]

"POD sovereignty" is a good term indeed, I think we should talk about it in those terms.

Our goal is clearly that POD sovereignty is an absolute, but I think we should discuss whether we should think about it as an absolute while the server is a prototype. I think that #1057 will help in the sense that we do not have any frontend stuff to update, but we still have the /settings/serverSide.ttl file, and we have issues like this one and #1063 . Perhaps we should have a more open discussion with the community about POD sovereignty while in prototype in the forums? @Mitzi-Laszlo should also be involved, as it is not mostly a technical issue.