File System Access API and saving locally

I have been reading about updates to browsers and I think that the new file system api may allow us to once again save single file wikis without any external requirements, at least in Chrome and Edge.

Has anyone tried this yet? I did some quick tests and the API seems to work, but I haven’t made a file system adapter yet.

1 Like

I have my eye on this as well. Will need to read up, is this specific to Chrome/Chromium?

Yes, basically.

You can read Mozilla’s position, here:

I’m pretty much in agreement with the views expressed by this person.

The situation has changed. As of earlier this year, WebKit on iOS, iPadOS and macOS added some support for the File System Access API:

But, their implementation includes this ominous note (my emphasis):

Based on the implementation of different browsers, one entry in the origin private file system does not necessarily map to an entry in the user’s local filesystem — it can be an object stored in some database. That means a file or directory created via the File System Access API may not be easily retrieved from outside of the browser.

That would seem to preclude the ability to edit TW files in place in the device file system, which perhaps makes this implementation closer to a custom API on localStorage.

1 Like

That actually sounds like they are leaving the spec open to write to the OS accessible file system OR another filesystem (like Fission WNFS?). I think the keyword there is MAY, i.e. it is outside of the spec and up to each app implementation whether to use the FS api to access the OS filesystem.

1 Like

I suppose there may be different methods deployed to achieve varying levels of local file system use;

  • To store the core single file tiddlywiki and save it
  • To store files along side or below the tiddlywiki eg favicon, images folder or with file uploads plugin
  • To access files the wiki knows about OR also enumerate contents
  • Then accessing and enumerate other locations outside the apps own store

If we can sniff the browser or device type (perhaps even manual selection) we should be able account for these differences, but even if we only start with the top item in the above list, we enable a lot. Each additional level we can address, will add value, but let us “not get something”, if we “can’t get everything”.

@slaymaker1907 implemented a plugin for this: TW5 browser nativesaver

I implemented a simple web page which uses the custom saver feature and doesn’t require any plugins: TiddlyStow - stow TiddlyWiki files locally using the browser file system api

@btheado this is great and easy to use, for naive users it could be documented differently and could there be ways for them to bookmark the local wiki for reopening?

It seems clear now we have the technology, all that remains is to package and promote.

In other threads I have recently established window management, cookie controls and other methods of obtaining and using tiddlywiki that I would like to fold a “better saver” into, primarily for local, single file and no saver/server installation issues.

Unfortunately I am not “yet” so well versed in the tech issues relating to File System Access API to be able to customise it to my use, but thanks for sharing.

Opening a file requires the browser to request permission for file access. The browser will not permit any requests for permission unless triggered by direct user interaction. In other words, a file cannot be opened directly on page load. Such attempts result in this error in the console:

DOMException: User activation is required to request permissions.

The page has to load and the user has to click a button before a file can be opened.

Theoretically a hash url parameter could point to a previously opened file handle, but it would still have to first display a button for the user to click to open the file. With that being the case, I don’t see much benefit of that compared to having a single bookmark to the tiddlystow page. That page contains buttons for all recent file handles.

Yes. Sorry I realised later you efectivly provide the links via buttons for previous files.

Good suff

Hi - apologies for waking up an old thread, but I noticed the demo of this API from Text Editor allows you to specifically save / open files (for me on Linux at least with Chrome) from the filesystem directly. Wouldn’t this be the perfect thing for TiddlyWiki to support by default?

The tutorial of this seems to have been updated fairly recently: The File System Access API: simplifying access to local files - Chrome Developers.

1 Like

Have a closer look at this response: File System Access API and saving locally - #7 by btheado

There are already 2 projects that use this mechanism.

Yep I saw those… I’m just curious why this isn’t a part of the core distribution so new users don’t have to hunt down how to install a plugin. It seems like it would give a nicer first impression of TiddlyWiki.

1 Like