Tiddlystow version 2. Now supports more browsers

#1

I’ve written version 2 of Tiddlystow. Tiddlystow is a helper web page for loading and storing local TiddlyWiki files. Version 2 is in an alpha state and needs much more testing before relying on it for anything important. Please backup your work.

Tiddlystow v1 is still available at TiddlyStow - stow TiddlyWiki files locally using the browser file system api and is unchanged. Version 2 is brand new and completely different. It is available at Tiddlystow put saver.

Version 2 shares these features in common with version 1:

  1. Works with any single-file TiddlyWiki instance. No plugins required.
  2. Can load and store browser external TiddlyWiki files. This external file feature only works on Chrome/Edge desktop browsers. (Actually I just discovered it also works on my Android chrome browser. I’m pretty sure this is new)
  3. Works offline

Version 2 has these enhancements:

  1. Can load and store browser internal TiddlyWiki files (OPFS). This feature is supported by all major browsers, desktop and mobile since 2023. However, I just discovered Safari’s OPFS implementation is missing a feature I’m using, so iOS will not work :frowning:. I have tried it on Linux and Android Chrome and Firefox.
  2. Each stored wiki has a url which can be bookmarked in the browser or linked to by other stored wikis

Version 1 and 2 have completely different implementations

When a wiki is loaded into version 1, it replaces the page’s contents with the TiddlyWiki. It leaves behind a custom-saver javascript function which will save the file to the external filesystem. Since it uses the built-in custom-saver feature, it is “invisible” to the loaded TW and no special plugins are required.

Version 2 is also “invisible” to the loaded TW. It is implemented as a service worker. It loads and saves local TiddlyWiki files by intercepting HTTP GET and PUT calls in a way that is compatible with TiddlyWiki’s built-in PUT saver.

When the browser issues a GET, the service worker will read the file from the internal or external storage. When TiddlyWiki sends a PUT, the service worker will save the file to internal or external storage.

The service worker is not limited to storing TiddlyWiki files. It is possible, for example, to use @saqimtiaz’s File Uploader PUT version (experimental) to save large attachments to the same browser internal/external filesystem alongside your TiddlyWiki files.

Screenshot of the main page:
tiddlystow-main-page

Screenshot of empty directory contents. Create a wiki:
tiddlystow-create-wiki

Screenshot of the page to populate the wiki:
populate-wiki-contents

Screenshot showing the directory listing is no longer empty:
non-empty-directory-listing

5 Likes
#2

Request bak function

#3

Thanks for your continued efforts, I use Edge on Windows and got the below

{A6BF773D-D4B1-4498-ABCF-69D3BCAE52D6}
{A6BF773D-D4B1-4498-ABCF-69D3BCAE52D6}766×82 3.1 KB

#4

Chrome based browsers don’t give the user the opportunity to explicitly allow the eviction protection. I think Edge is chrome based.

The only way to get the protection is to do things like bookmark the site or interact heavily with the site or add to home screen, etc.

Unless your disk is dangerously low on space, it is ok to click the button “Continue without eviction protection”. You can still get back to the eviction protection page from the directory listing page. After adding bookmark or whatever, the eviction protection should succeed.

Any suggestions for wording or changing the workflow are welcome.

Additional note. If you have Edge/Chrome, you should see both internal and external buttons on the main page. If there is a choice, I recommend “external”. For external you shouldn’t see anything about eviction protection because there is no eviction process for browser external files.

#5

What do you have in mind?

#6

With TiddlyStow 1 you could download the TS file and then use it locally. This means you can use it even if you have no internet connection.

With V2, this doesn’t seem to be the case. I’m guessing we’d have to find some way to serve up the V2 directory to make it local? Or is there some way to make it work locally?

#7

Once you navigate to an external directory, you can’t navigate to a different external directory.

The second time I tried creating an external tiddler, and uploading from a local directory, it gave the message:

“Error saving file: Server responded with 403: Directory Access Unauthorized”

#8

As with tiddlywiki desktop and other tiddlywiki tools, it is essential to make a backup after each edit so that you don’t have to worry about losing a lot of data or not being able to access the tiddltwiki if you do something rash.

1 Like
#9

Yes. A fixed internet or intranet site is required because of the use of pwa technology.

#10

It looks that way. There can only be one local directory.

#11

How to “reset” the directory, for example

c:\temp to c:\tiddlywiki_files

#12

I am able to save and load test wikis. But I do not know where they are saved? I can not find the files. Where do I have to search for them?

I am using FireFox by the way.

#13

With V2 you need an internet connection the first time you use it. After that the site’s html/javascript files are cached in the browser and you can still access the site without the internet. This is what I mean when I say it works offline.

This same offline mode works for V1 (it was added a while after the initial release). But as you mention V1 also works as a single html file which you can use locally. V2 does not support that. A local web server is required

You could clone the git repo and run a local web server (say on http://127.0.0.1:8080) to serve the static files. Connect to it with your browser just once and then never run the server again. It should be accessible at http://127.0.0.1:8080. Think of that as “local offline mode” I guess.

#14

I guess I should find a way to add support for multiple directories. The current implementation is only good for keeping all your tiddlywiki files in the same directory.

For chrome, in the meantime, you can click on this icon:
chrome-remove-directory-access
and click the “remove access” button and you will be prompted again for a directory.

Edit: Oops, this is wrong. It only prompts you for permission to access the same directory again. In order to change the directory you’d need to go into the developer tools and delete the indexeddb key. Not good. Clearly more work is needed here.

#15

Interesting. I’m only able to duplicate this by Removing Directory access (as mentioned in a previous) while on the “Create wiki” page. I couldn’t get it to happen via “normal” use. After that I refresh the “Create wiki” page and it gives me the “Request directory permission” prompt again and it will work after that.

1 Like
#16

When you use the “Internal storage” button (the only one available to Firefox), it stores the files using OPFS which is a browser internal mechanism. There are no user-visible files in the external file system related to this storage.

#18

Thanks for your feedback. I did read a bit more about OPFS and already saw, that we can not see the files.

The main issues I see is, that it looks like as if OPFS files are sent to the server. But in reality they are stored locally and invisible in the browser. For me that’s a bit of a problem. We need to make clear, what’s going on, for both mechanisms.

Also there needs to be some documentation about browser “persistent” storage.

#19

Thanks for your remarks!!!

#20

I made a few minor improvements.

  1. Each file in the file listing page now has a “Download” button. This is especially useful for the internal OPFS storage as it provides an easy way to export a file to outside of the browser. (This could already be accomplished inside each TiddlyWiki via the $:/core/ui/DownloadFullWiki button)
  2. On the file listing page for external files there is now a “Disconnect” button which allows you to disconnect the current external directory so you can choose a new one. Not as useful as supporting multiple external directories, but at least you can switch directories if you attached to a temp directory the first time

If you’ve already visited the site before the above changes, it may take some manual effort to get the new features. In my test, I think I had to

  1. Reload the page (this causes the browser to fetch the new service worker code, but does not start using it)
  2. Close all tab using the site (the browser becomes aware no “clients” are using the old service worker anymore)
  3. Open the site again and now the new functionality is activated

This seems far from ideal. Maybe there is a way to improve the code to make the above more smooth. I have a bit to learn here.

#21

I do like the new button, but I think it should be a “Save File” button. “Download” implies, that it is stored at the URL address, which it is not.

So I think it would be better to use Save File or Save As

Edit: Or may be Transfer to Filesystem