Local Storage on 5.1.20

[AnthonyMuscio]

Folks,

I love the potential unleashed with the local storage plugin and at less than 15KB I would like to suggest it be distributed with the empty.html, with the the plugin enabled but the "Use browser local storage" unchecked or if necessary provide another edition with this.

This would allow any tiddlywiki hosted online as read only to have local storage switched on thus allow users to return to see their last story river, set default tiddlers, minor customisations etc...
If necessary the filter that determines what is stored in local storage could also be changed (and saved in local storage).

Why in empty? because it would be an advantage to the whole community if most readonly wikis found in the wild could be activated to use local storage, because then such a useful features can be activated in most cases unless someone intentionally removes the storage plugin. This even allows a plugin to be installed in a read only Wiki to test compatibility. For example we could drop a plugin on Tiddlywiki.com and confirm it runs there with access to all its content for test cases.

I would be keen to include an indicator when local storage is in use and an easy opportunities to do the following;

• clear it and revert to the original loaded wiki.
• save all local storage to json for reimport
• save the base wiki plus local storage to a new wikifile

To me this will make TiddlyWiki start to approach the idea of a Progressive WebApp out of the box.

[AnthonyMuscio]

PS A nice addition to the next release of TiddlyWiki.com

[Jermolene]

Hi @AnthonyMuscio I share your enthusiasm for the local storage plugin, and I really like that it is enabled on tiddlywiki.com/prerelease for quick experimentation.

I think you're suggesting three things:

• First, making it possible to have the plugin in a dormant state on a site until a user chooses to explicitly enable it. It is an interesting idea; obviously, in it's dormant state the plugin would still need to inspect local storage to see if it should be enabled
• Second, adding it to empty.html with the rationale that it would be useful if the plugin was ubiquitously used on published wikis for those of us who like to experiment. Putting a plugin into empty.html is a big deal; we don't currently ship any plugins, and that's so that people can start empty and gradually add what they need. I've found that people like the simplicity of a truly empty empty.html. So, there's a pretty high bar for changing that. In this case, I think the benefit is not universal, it's only a tiny proportion of TW users who would need this, and they have alternative mechanisms to accomplish the same thing
• Thirdly, improving the UI for the local storage plugin. Those are reasonable improvements. The one I'm most interested in is an explicit indicator that tiddlers were loaded from local storage

[pmario]

I'm not happy with an "always on" local storage. IMO most users will think, there is a server backend involved. So if the open the site with a different browser, all the changes are gone, since they are stored with a browser profile on the harddisk.

My second and biggest concern is, that local storage is completely unpredictable. It's not clear how much information is stored, where and when it is deleted. ... Every browser handles this in a different way.

If I check the browser settings, the local storage is listed at:

Privacy & Security: Cookies and Site Data

As you can see, it uses 1.1 GByte on my PC. Most of the time I just click "Clear Data" to get rid of the crap. IMO many other users will do just that. And "boom" some valuable notes may be lost.

Some uses may have "Delete cookies and site data when FF is closed" activated, which makes the plugin bloatware.

[twMat]

@pmario presents convincing arguments against the OP. However, we should not forget that "most users" expect saving to be a non-issue. I fully assume we're currently losing community members because of the saving hassles so this is no small issue. My hope is for this plugin to be extended into a solution that makes saving automatic or at least trivial. Until then it should probably remain a plugin.

That said, I think we could modify GettingStarted in empty to inform about this basic matter and promote the plugin. Again, it's purpose is more fundamental than other plugins so maybe even a direct download-plugin button can appear directly in GettingStarted.

[Jermolene]

Hi @twMat

@pmario presents convincing arguments against the OP. However, we should not forget that "most users" expect saving to be a non-issue. I fully assume we're currently losing community members because of the saving hassles so this is no small issue. My hope is for this plugin to be extended into a solution that makes saving automatic or at least trivial. Until then it should probably remain a plugin.

Sadly, browser local storage isn't a universal panacea. The problems mean that right now it's one of a panoply of options, and it takes some discernment for users to figure out which option will best work for them.

That said, I think we could modify GettingStarted in empty to inform about this basic matter and promote the plugin. Again, it's purpose is more fundamental than other plugins so maybe even a direct download-plugin button can appear directly in GettingStarted.

Good point. Perhaps we might step back and rethink that tiddler, it is very out of date, and could do more pointers and suggestions to get people started. I have also considered a "GettingStarted" plugin that would guide the user through a setup wizard, right down to choosing background colours etc. And then once the user has things set up how they want they could delete the plugin. If such a plugin existed one could make a case for inclusion in empty.html because I think it would meet the criteria of being universally useful.

[twMat]

I have also considered a "GettingStarted" plugin that would guide the user through a setup wizard, right down to choosing background colours etc. And then once the user has things set up how they want they could delete the plugin. If such a plugin existed one could make a case for inclusion in empty.html because I think it would meet the criteria of being universally useful.

Do I understand you right; A deletable plugin that comes along in standard distro!? That could be a superior idea! Minimalists would be happy but we'd also provide an additional "entrence" that we could much more easily modify to meet identified needs, even for different user groups. The idea really triggers some ideas and I'll start a new thread for it.

[Jermolene]

Hi @twMat the trouble is that it might trigger requests for other plugins to be shipped in empty.html. My response would be that anything in empty.html needs to be of universal value, serving the needs of nearly all users.

[twMat]

My response would be that anything in empty.html needs to be of universal value, serving the needs of nearly all users.

Why, if things are easily deletable?

[twMat]

Or, let me rephrase that into something that is more in line with my intended new proposal:

Could the download mechanism be extended to allow downloading empty.html plus optional additional plugins?

Regarding:

anything in empty.html needs to be of universal value

...this is 100% utopian theory. I never touch half or more of the current controlpanel settings. Even most of the sidebar tabs are extremely rarely touched. IMO, they are included purely based on guess, not actual user statistics. The fantastic thing with TW is the customization and if some optional additions could be moved upstream to the download moment then it would simplify a lot of things. Particularly so for new folks who, btw, might be at the sensitive evaluation stage where it makes sense for TW to be as immediately useful as possible for them.

[Jermolene]

Hi @twMat

Could the download mechanism be extended to allow downloading empty.html plus optional additional plugins?

Yes, we could incorporate build something that packed plugins into the downloaded wiki. But we'd still keep the wiki at https://tiddlywiki.com/empty.html as an empty wiki.

...this is 100% utopian theory. I never touch half or more of the current controlpanel settings. Even most of the sidebar tabs are extremely rarely touched. IMO, they are included purely based on guess, not actual user statistics. The fantastic thing with TW is the customization and if some optional additions could be moved upstream to the download moment then it would simplify a lot of things. Particularly so for new folks who, btw, might be at the sensitive evaluation stage where it makes sense for TW to be as immediately useful as possible for them.

Perhaps better phrased as "universal utility"; obviously I don't mean that all users will use all features that are included in the core. I just mean that the features in the core would be of universal utility. So, most users presumably don't explore the tag manager, but that doesn't alter my contention that it is of universal utility, because it serves the needs of anyone who creates tiddlers.

There are other factors at work but "universal utility" remains my key criteria for inclusion in the core.

[twMat]

(@AnthonyMuscio - I've totally hijacked your thread but then I have a feeling we're on the same page here so I'll continue ;-) )

Yes, we could incorporate build something that packed plugins into the downloaded wiki. But we'd still keep the wiki at https://tiddlywiki.com/empty.html as an empty wiki.

Great! I'm only concerned with the explicit download feature presented to the visitor. I'll formulate my proposal according to this info then.

universal utility

OK I'll leave this question for now. (It is probably related to the in-person discussions the two of us have had about how a tiddler should be defined where I think it depends on the context but you, if I recall, say there is a ubiquitous set of properties as reflected in the standard tiddler fields. A very profound and stimulating problem, almost about the nature of reality.)

[AnthonyMuscio]

All Please let me respond to my original request. To clear up some misunderstanding and support what I think is a very strong case. Sorry for the length but it is I believe needed to put my case and in response to the comments.

I did not want the local storage plugin activated, although enabled. This would allow a visitor to a tiddlywiki site with the know how to be able to activate the local storage plugin to use local storage at their own risk. By adding it to empty.html we provide this facility to anyone visiting any site built from empty html unless this has being specifically removed.

When Mario mentioned Most users will think, there is a server backend involved this will not be the case as unless the user specifically turns local storage on. this means they must know what they are doing. By the way I think many users may already think even a read only wiki is backed by server given its interaction, new tiddlers etc...

Also I suggest the default filter used for local storage just maintain the temp-files and user settings and not new tiddlers. Ideally an attempt to leave the wiki would still advise you are about to loose your modified tiddlers.

With my requested feature, users in the know, can go to any tiddlywiki site (so configured), activate local storage, change the filter to [all[]] install a plugin, drop test data on a wiki, change the default tiddlers, reload and test the plugin. Still with no impact on anyone but themself. It is they who take on these nebulous risks of the loss of local storage. This is idea for TiddlyWiki.com as it is our standard with documentation, and any demo or plugin site would benefit by providing user to persist changes. In addition a lot of wikis would provide a lot more functionality out of the box with just a few bytes of persistent storage.

As it stands at the moment tiddlyWiki promises to keep the visitors changes by accepting settings and new tiddlers on any wiki not designed to look as read only, it is when they leave the site they are suddenly confronted with needing to save everything and enter the more complex zone of choosing savers. I suspect many just loose their changes rather than take this sometime complex path. All I ask is that it be a standard practice to allow local storage to be activated. Perhaps for designers that wish, a checkbox "Save Changes in Browser Session", could be presented to users. A complementary button would be to save the whole wiki to file/download with the served wiki + local changes in the file, so they can persist it even further.

I have a number of motivations for this feature, I hope you can all intuit the possibilities. If you need more please ask.

So I ask

• The local storage plugin come with the empty.html, enabled but not activated
• or have it close to hand (Empty+localstorage) edition so that it is installed if not activated in most cases, with advice to encourage its adoption as much as possible.

As raised before elsewhere I think empty.html serves a purpose as a minimal build and needs to be maintained, but for most new and regular users we need a minimal but feature rich edition, from which to build most wiki's, and encourage feature adoption.

Regards
Tony

[AnthonyMuscio]

Post Script

If Tiddlywiki.com had local storage installed, the plugin enabled, but not active, I could drop a json bundle on it that activated local storage, installed a bundle of plugins and tiddlers that provided a tour through the whole wiki. It would persist (but if lost can be done again) we could think of this as a tiddlywiki overlay bundle. It makes it easier for us to test plugins on tiddlywiki.com and provide optional tutorials slideshow that sit on top of the actual published website.

I believe this is way too compelling to ignore.

Regards
Tony

[pmario]

Let me play the devils advocate. ...

• Assume I do create a simple e-mail client plugin, that allows you to use an e-mail service of your choice to send mails using TW.

• Assume you throw it onto tiddlywiki.com to test it

• Assume it works and because you like it, you keep it

  • Or you forget about it and you didn't delete it

• After eg: 2 month I decide to create a nice image viewer plugin

• You test it with tiddlywiki.com

  • The image viewer plugin contains some example images from <you don't know the service, because it uses cryptic URLs> or google image store, which also has cryptic URLs
  • Some of the images are tiddlers and stored in the local storage.
  • Everything works as expected nothing special happens.

• After an other 2 months I create an image-mosaic plugin

  • Because you trust me already, you throw it on tiddlywiki.com to test it.

• Now the magic happens.

  • several images stored in your local storage contain some steganographically hidden info that can be used by the mosaic software.
  • several other images contain a little bit of code, which combined using the diff-match-patch tool form the core are injected into the e-mail client
  • The image viewer sends some pings to servers that spin up throw-away e-mail servers.

• Now the e-mail client can send all the info contained in the local storage to an e-mail system, that I control.

I'm not sure, what your local storage contains, but it may be interesting at all.

Just some thoughts.

[sukima]

Just to be clear localStorage is not universal and it requires extra messaging to convince a user when it is and is not in use. In many other applications/websites I've worked on I've had to fend off many false positive bug reports of users upset that their work is lost and it is because localStorage while using Private/Incogneto modes. Users like them but are dismayed when localStorage does nothing or outright blows up like in the case of Safari.

My personal opinion is that localStorage use should be an opt-in then an default.

[AnthonyMuscio]

Folks,
I appreciate support and criticism of this suggestion, can I ask you please consider the added value to designers and users of tiddlywikis in general. Sure we may need to provide messages popups and options to forestall some potential issues. It is also critical to understand not only is this a international trend in apps but increasingly persistent storage is being used in PWA's (Progressive Web Apps) for these very reasons. Further at the moment I am only asking to make it possible to activate, not actually activate it.

Jeremy said

Hi @twMat the trouble is that it might trigger requests for other plugins to be shipped in empty.html. My response would be that anything in empty.html needs to be of universal value, serving the needs of nearly all users.
I do not think the issue of setting a precedent important here, because the argument for placing local storage plugin is about enabling additional functions live on top of a read-only published Wiki. If there were other plugins offering such value by being installed, but not active then perhaps they should be considered for inclusion, however more of this nature are unlikely to exist.

Sukima,

I am only proposing an opt-in, but if the plugin is not present and enabled you can never opt in on online tiddlywikis that are read only to you. You need to save to local storage to activate a plugin.

Again, if the plugin is installed, and enabled, but not active it is possible to opt-in to using local storage by finding your way to the plugin and activating it. Unless it is available like this, it is NOT possible to have even simple settings retained for a site, across multiple visits. I think we should make this opportunity available on as many wikis as possible by building it into empty, however it is somewhat hidden away, and easy to remove all together. Even the wiki owner may benefit by activating Local storage, applying changes online, save to file and re-upload to their host. This simplifies their work flow, and can be done retrospectively if the local storage plugin is already there.

If the owner or designer of the wiki wishes to activate local storage for all users then they have to handle the appropriate messaging. In many cases local storage may only hold an updated story river, a theme choice or stared tiddlers - in this case if local storage dies, it is trivial.

Remember also that the local storage filter can be altered not to save anything but user status information.

Mario
An on PAGE indicator that local storage is in use, A info page listing the tiddlers within it and a quick method to clear some or all and reload may be sufficient to stop what you say occurring. Users could even be provided a filter that detects and indicates if they have made changes to anything other than temp, state and config tiddlers and warn them this is so. eg you have unsaved or is that "uncommitted changes"?

On one hand, If I am using tiddlywiki.com and activated the local storage plugin for testing it should be within my understanding to clear it of changes before doing another test to ensure a standard built,
on the other hand I may want to test two plugins at once for compatibility. Remembering that this modified tiddlywiki.com exists only in a particular browser, and does not touch the server. The online wiki is always the latest published, I find it at the url and I do not need a copy on disk for testing.

To suffer the problems of something remaining in local storage for two months would be an indicator that local storage persists, and to me, makes it more compelling.

Just installed on the pre-release will have many advantages for testing. Perhaps we should demonstrate it there?

Regards
Tony

[AnthonyMuscio]

Note: Local storage is installed and enabled in the Pre-release.

[AnthonyMuscio]

Note: The ability to activate Local Storage will also enable the comments plugin to be installed, activated and provide the ability add comments, then export them to file, for subsequent import for consideration.

[sukima]

To clarify:

1. I was not trying to provide a counter to this proposal. I was just providing some experience about the concerns of localStorage itself. As use of it comes with some programming caveats that if not handled cause breakage on the internet. In other words localStorage is a poor API in general.
2. If enabled by default there are limitations that an average user or new user might very well not know about nor should be expected to know about.
3. If I understand the thread here so far the real argument is not that localStorage should be enabled but just to have the code available. See User Stories below.

User Stories

If I am to understand this proposal correctly then I would offer the following User Stories:

User Story One

As a page owner of a TiddlyWiki page statically hosted I can make a change that persists across browser sessions, so that I can work on changes incrementally then perform one bulk save when ready

User Story Two

As a user with some experience with TiddlyWiki I can make changes to a statically hosted TiddlyWiki page that persists across browser sessions, so that I do not have to save the TiddlyWiki

With User Story Ono the answer is pretty simple in that the owner of the site knows and wishes to use the localStorage plugin and is capable of installing it themselves.

However, with User Story Two I can see the interest to have user state persistent by default. However, I can also see how this is likely not a universal expectation across the board. I think that it would require some focus group testing to get the research needed to determine if in deed having a persistence mechanism by default was universal or not.

An aside coming from my own personal understanding of the TiddlyWiki philosophies is that the base line (which arguably is empty.html) assumes only one saving mechanism which is the save button. Everything else has been built up around that core concept. Saving to localStorage is a slight departure from that base. Although useful, it does present a different saving mechanism.

The reason for the muddy waters here is that TiddlyWiki is centered around tiddlers irregardless of those tiddler roles. Since all tiddlers are the same in regards to saving and management despite what role or intent they serve (content, user settings, temp states, plugins, etc.) the use of any persistence is also a saving mechanism.

Given both the implementation and User Story Two the actual proposal here is if TiddlyWiki core should include the localStorage plugin as a default (i.e. empty.html) or offer it as an option (current behavior).

For contrast the current solution for User Story Two is that the user downloads (saves) a copy of the static wiki to their local device and installs the localStorage plugin to their local copy.

Opinion

I have mixed feelings about this. On one hand I see the benefit of having the option to use functionality available across the board. On the other hand I see how adding a feature like this into core (which is the same concept as included in empty.html) is out of scope of the role for core functionality.

For me I would want to see more evidence that users do indeed need or want such functionality out of the box before I would be convinced it should move from a plugin to core.

[Jermolene]

Just a thought, but another way to meet some @AnthonyMuscio's goals might be to (finally) make it possible for TW5 to restart itself after loading a plugin, without requiring the page to be reloaded. Then one would be able to visit an existing wiki, drag-and-drop a plugin, and then do a "soft restart" to re-initialise the wiki.

The "restart" procedure would be something along the lines of:

1. Save all tiddlers into a JS object
2. Clear/delete all the storage associated with TW (ie, recursively delete everything reachable from $tw). This is, of course, the tricky bit
3. Restore the tiddlers to a JS array called $tw.preloadTiddlers, and suppress loading of tiddlers from the DOM by setting $tw.boot.tasks.readBrowserTiddlers to false.
4. Invoke TW5's boot kernel again to restart the wiki

[AnthonyMuscio]

Jeremy,

This sounds like a possibility, can the resulting wiki + Plugin be saved to file (with all inclusions) even if the plugin installed was not the local storage plugin? Your proposal also has great potential. Whilst this would make possible that which is not currently possible, it is not as strait forward as the OT.

With the local storage plugin enabled, and able to be activated, If the local storage plugins default save (to local storage) filter were set to remember basic navigation, config settings, theme pallet etc.. it could go a long way to making TiddlyWikis online more interactive and user friendly. It is this I am hoping to encourage. But if your recent suggestion works perhaps local storage could be placed in a new edition perhaps an "interactive" empty wiki.

My point raised before is empty.html is a great source for designers wanting a minimal version, it is not the best version for a new user to use, not to encourage adoption of many possibilities. Perhaps inclusion of local storage (not activated) in empty.html would make sense.

Or if we released a new edition called minimum.html and made it prominent on the website. We could possibility even cut minimum.html back even further.

Regards
Tony

[dubiouscript]

We could possibility even cut minimum.html back even further.

a little off topic but..
i was intending to ask how the size of empty.html breaks down % wise
eg what components of
empty.html
take up what space
like
empty.html = core.things + other.things + ???

is this documented some place i have missed ?
or do anyone know of some method find this info

---

-edit-

# git clone https://github.com/Jermolene/TiddlyWiki5
du -h   ./TiddlyWiki5/core/ | sort -h -k1
find ./TiddlyWiki5/core/ -type f -exec du -b {} \;|sort -k1 -n  #D 

[pmario]

empty.html content is really small: about 90 kByte
core.js about 1.9 MByte ... zipped: 331 kByte (on windows machine)

tw5.com.html content: 3.9 MByte ... zipped: 1.9 MByte
core.js + plugins: 1.9 MByte ... zipped: 336 kByte

Be aware of MByte and kByte !!!

[sukima]

@Jermolene being able to add a plugin via a bookmarklet would be amazing!!!! I would 💯 support that effort.

Also the soft reboot you describe would make integration with other applications much easier (removes some of the fancy footwork I do in tw-bookcase).

[bimlas]

Local storage causes RSOD on some browsers:

I use the Vivaldi browser (2.5.1525.46, stable channel), a Chromium-based browser on Windows that uses Chrome/74.0.3729.172 at time being. I downloaded TiddlyWiki prerelease and when I tried to open it from the filesystem, it showed the following error message:

Uncaught SecurityError: Failed to read the 'localStorage' property from 'Window': Access is denied for this document.

Same results on older Android (5.1.1) + Brave (Chromium 72.0.3626.121).

I wanted to try it out on the desktop Brave, but I couldn't install the browser because It was constantly failed to install. (-_-')

I've tried it in Chrome (74.0.3729.169) and Chromium (https://download-chromium.appspot.com/, 76.0.3808.0) and Opera (Chrome/73.0.3683.103), it worked well there.

[bimlas]

Just found the solution for the aboves:

This exception is thrown when the "Block third-party cookies and site data" checkbox is set in Content Settings.

https://www.chromium.org/for-testers/bug-reporting-guidelines/uncaught-securityerror-failed-to-read-the-localstorage-property-from-window-access-is-denied-for-this-document

[Jermolene]

Hi @bimlas thanks for the heads up, I'll push an update with better error checks shortly

[Jermolene]

Just to add that the crash reported by @bimlas is a good illustration of one of the pitfalls of local storage: based on user settings, browsers may choose to not make it available at all. When that happens it's extremely difficult to guide the user to figure out why, and what they can do about it, because the instructions would be browser specific. With local storage, what people sometimes call the "happy path" is very smooth and straightforward, but once the user is forced off that path they face a landscape more complex than if local storage hadn't been offered in the first place.

[AnthonyMuscio]

Folks,

Lots of good ideas in this thread. What ever the delivery method I would hope we can provision TiddlyWiki as a PWA Progressive Web App.

• I concede that "local Storage" as a technology rather than a descriptor is of limited value - however simply to maintain temporary and state info for a user in a wiki, where if lost there is no harm is compelling.
• As far as installing this as a plugin in empty.html what If I said it was a saver?, we do provision tiddlywiki for multiple savers built in?, surely this is just another? Never the less Jeremy's suggestion TW5 to restart itself after loading a plugin, without requiring the page to be reloaded could replace this request. I already deliver my own modifications in Bundles to avoid a reload, adding plugins would be even better. This would also help testing, for example drop my new plugin on TiddlyWiki.com and test it.
• However I can see that persistent storage locally is now possible typically through IndexDB and javascript can request it.
• For those wanting to use a high level of privacy and disallow cookies, local storage etc... in their browser they can choose to do this and loose the features, or as is possible in Chrome, at least they can make an exception to a given site.
• Without going into too much detail, reliable or persistent storage opens up a range of new possibilities, not yet imagined. For example I am developing a method where multiple users edit the tiddlers in the same single file wiki online, all their changes are "stored in local storage" independently. Users can then request a checkout of the document so they can Commit their changes to file, this would permit a tiddler by tiddler review and commit process. A second user could then checkout the file when the other relinquishes it, and make his/her own commits to file. Possible conflicts can be managed with a little smart code, including maintaining versions of any tiddlers where more than one user attempts to commit a change. This can be smoothed even more with users "owning" the tiddlers they create.

Regards
Tony

[twMat]

We should not forget that @danielo515 's NoteSelf fully relies on the browser storage and I think it works perfectly fine.

[Jermolene]

We should not forget that @danielo515 's NoteSelf fully relies on the browser storage and I think it works perfectly fine.

But it doesn't work perfectly fine, it suffers from exactly the same problems that we've discussed here and elsewhere: that local storage isn't available in some configurations (e.g. private browsing), and that the browser can unceremoniously dump stored content.

Using browser storage for anything that can't be reconstituted is like crossing a busy road with your eyes closed -- only worth the risk if it's your only hope for survival.

[AnthonyMuscio]

Just an update this conversation has led to a few improvements over a number of releases, it has been quite productive.

I have come to the argument that it should not be in empty.html however I have realised a simple compromise;

A number of core plugins have wikis with only themself installed online see Plugin Editions

• These are maintained at the latest latest tiddlywiki release version
• They are in effect empty.html + the named plugin

I would suggest we add two more editions using the same method;

• Local Storage plugin wiki, with the plugin installed but not active
  • This means there will be an empty+local storage available online if needed, a good scratch wiki
• A full copy of tiddlywiki.com + Local storage plugin (not active) so there is an online source of the documentation with the option to activate local storage and save annotations in local storage.

Once in place and tested we could then document it a little more, it would allow people to play with tiddlywiki online and save the changes to local storage without needing to download and configure savers.

If these recommendations are adopted I think we can close this thread.

[Jermolene]

Thanks @AnthonyMuscio – I just answered essentially the same points over in #7344 (comment) – perhaps at this point it might be clearer to close both tickets, and create a new ticket with a concise summary of the current thinking, referencing these two tickets for the history.