The last word in Saving?

[TonyM]

Folks, (edited)

This post is seeking input from the community to overcome what I perceive to be the last big issue in saving. It may seem only suited to experienced users but perhaps you know something we don't, so please be brave and contribute.

This thread is about Single File Tiddlywikis, Please See The penultimate words on saving - multi access and multi user for server based solutions.

Alternative thread Title: "TiddlyWiki Encounters of the First Kind"

• First = Initial single file wiki on internet
• Second = Single File or read only wiki published on a server
• Third = Delivered on a platform that permits multi-access or multi-user (simultaneously) see The penultimate words on saving - multi access and multi user

I may have an opportunity in coming months to work with a team of videographers in their off season. They do "things for good" and my thought was to build a nice application (on tiddlywiki) for people to explore how they or their business can participate in reaching the Sustainable Development Goals (SDG's). This will promote the SDG's, their work, my work and the power of TiddlyWiki, but there seems to me, to still be an elephant in the room - saving.

How do we enable saving tiddlywikis for naive and casual users?

To be sure, I am across most saving mechanisms, and some are very good and quite easy to set up a very sophisticated solution, I use Timimi, TiddlyServer, TiddlyDesktop and Bob.exe 

Imagine someone visits my SDG app online

• They could use it and apply changes but not save it
• With local storage and save some changes in the browser but they may be lost later
• They Can download it easily enough, even with their in browser or local storage content
• But if they wish to open it again, make changes and save they then need to consider this https://tiddlywiki.com/#GettingStarted - scary for many.

Basically I think tiddlywiki is brilliant and we have lots of wonderful options for saving, once someone gets involved with the ecosystem, I believe any nodeJS solution is hard to secure on the internet and like NoteSelf we have to manage the server, but it seems we are so close to a better single file solution (My Opinion).

 

I know some saving mechanisms come close to helping naive and casual users however their remains a need to take unfamiliar steps, that can be quite fragile, especially to those not overly computer literate. Saving under downloads folders, running batches and installing local apps are all impediments to naive and casual users in my view, as this becomes Operating system dependant, demands more trust, will not work in many locked down cases and more.

I am starting this thread to try and inspire some serious creativity to overcome this barrier. Here are some ideas floating in my head but I am keen to hear from you.

• Any idea is a good idea
• A diversity of ideas in needed
• We may need to "think outside the box"
• Can an existing solution be better engineered to meet these goals?

Some of my own musings

• One approach may be to never download the whole wiki, but store the changes in a separate file that is automatically loaded over the in browser one, and saved only by saving changes back to the nominated file.
• Building all the necessary content to install Timimi or another saver from the single wiki (No other document or external info required) Not yet chrome and IE
• A Form of bob.exe/TiddlyDesktop that can be loaded with a custom tiddlywiki that shows only that wiki unless some settings are changed in the control panel. Ie a single local installable.
• A Way of packaging a TiddlyWiki with Node.exe and hosting on a port that will not clash with other server hosts, perhaps an packaged extension of TiddlySaver.
• I was inspired to open this up to the community after playing with bookmarklets and Jeremy's solution because javascript can be loaded into bookmarks I wonder if it could be used to save changes to local tiddlywiki files and reimport on click. 
• I also looked at solutions such as https://en.wikipedia.org/wiki/IMacros which suggests there may be other ways to achieve the desired results.
  
• IPFS, BeakerBrowser, CouchDB or saving to a MYSQL or even a wordpress database?

All I want for Christmas is a simple way for naive and casual users to save their tiddlywiki (again and again)

Yours Sincerely

Tony

[TonyM]

Things that we can assume users are comfortable with or know?

• Downloading a file and saving or moving it to a folder they can find again eg the documents folder
• Dragging a link to the bookmarks/favorites
• They know the browser they are using (We can test for this) and the default browser
• others?

More Ideas

• It is possible to test using the contents of $:/info/url/full when a wiki is running at another location, from that where we published it. We can also test if it is in the original location this could be used to identify when we only save the changes.
• It is possible to retrieve the contents of a shadow tiddler after it is overwritten, and the fact it has being tells us something about the state of the wiki.
• It is possible to add additional save buttons that will save different combinations of tiddlers, or wiki content.
• You can make a new tiddler button or buttons that actually creates a users tiddlers in a namespace or on import adds a prefix to all imported tiddlers, I wonder if we could use the https://wikilabs.github.io/editions/uni-link/ to make peoples own tiddlers with their own prefix appear as if they are the only tiddlers.

What do you think could help solve this key issue

 a simple way for naive and casual users to save their tiddlywiki (again and again)

Regard

Tony

[TiddlyTweeter]

TonyM

Very good posts, I think! Its not new territory, but its a good overview on the conundrum to get TW working for end-users who just want to use it, not get bogged down in its mechanics of saving.

There are a few things I can comment, though I can't give you a final answer. More a series of issues and observations ...

1 - IF end user needs their TW to work between devices then a CLOUD solution would likely be best? 

Advantages 

• Fits a common paradigm of usage now. 
• Multi-user is easier as some functions can be largely devolved to the Cloud Server. 

Disadvantages

• Still not "out-of-the-box" easy. 
• Perhaps a way here is to pre-configure for a subscribing user so they don't have to grapple with arcane setup on distant machines? But someone would have to think that through. (I think a reason NoteSelf take-up has been relatively low is precisely for this reason?)

2 - TiddlyDesktop could be a solution for all major Desktop platforms in theory. One could wrap TWD with component TW into a single click installer. 

Advantages 

• User does not need to know its a wrapped browser (Chrome). So it resembles a normal app. I think that is a real plus!
• Its interface can be customised.

Disadvantages

• Current version is somewhat behind on TW releases
• Internally you cannot currently enforce relative addressing of component wiki in TWD. You can make the address of the settings be at a relative address. But you can't make component wikis at relative addresses. Unfortunately that breaks possibilities of: (a) true portability; (b) integrated install (i.e. a package of TWD with wikis won't work reliably)
• We need a few examples of how to customise the interface.

3 - Android IS a good example of a potential approach

Advantages 

• Both Quinoid & Tiddloid leverage the good inter-working of components mobile phones have
• It should be possible to use either to not just be able to run TW but also WRAP TW's on install
• Saving would be seamless

Disadvantages

• Learning how to re-package Android Apps reliably with content wiki. 

That is the first part of my thoughts, based largely on my understanding of what we have already.

Best wishes

TT

[bimlas]

TonyM,

The main problem is that there are different operating systems and browsers, so you can't create a "generic" saver plugin: each system will need different code to automatically save the wiki, and not all of them can be implemented (because of restrictions to access the filesystem).

I think the Timmimi plugin (or similar) should be upgraded to work in every browser, as this is the easiest solution to use: just open the wiki and it saves the changes automagically. Of course, the problem is that it only works on the desktop, for example, you may not be able to install browser add-ons on Android.

Another option is to write the wiki to a location that is accessible on all systems: this is browser local storage, but it is not perfect either.

The third option is to save it to an online location (GitHub, GitLab) because it works with all browsers and operating systems, but this requires the Internet, and you may not even want to save your notes online.

I'm afraid that the main problem, not with TiddlyWiki, but with the interoperability of browsers and operating systems, is something we can't change. To improve this, TiddlyDesktop was created, which is only available on desktop, not on Android.

Anyway, this is a problem for which there is no solution, because the limitations are outside our system.

[TonyM]

TT/Bimlas

Thanks for your thoughts.

I agree the various os platforms and sometimes the browser gives rise to complexities.

However I am not prepared to accept there is not an answer to this yet. Some complexity could be reduced through browser plugins and easy install scripts built it. But I believe there are as yet undiscovered possibilities hence this thread. This is not wishful thinking as I have clues but no final answer. If you look at what Microsoft can do with o365 and hand off to installed apps the technology exists and Google's progressive web apps is another.

I am confident more clues are in the heads of community members and the value of creative solutions to overcome the status quo is a fact.

Tony

[TiddlyTweeter]

TonyM wrote:

All I want for Christmas is a simple way for naive and casual users to save their tiddlywiki (again and again)

Ciao TonyM

My second post. Your focus in the question is on "saving" in general. A way to make it seamless.

I think you overlook a USEFUL LIMITING FACTOR. 

As far as I can see commercially successful TW initiatives are not so much about system in principle as CONTENT in practice. 

What I mean is, APPS for specific purposes. A limited, but active, market fragment that can agree on ONE method for its needs.

So, I think, the issue is also about WHICH Users for WHAT Purpose? That may simplify the HOW? 

That the focus might delimit the problem to something solvable more easily sometimes (e.g. "we want cloud"; "we only use Desktop"; "all our work is on Android now")? 

Whilst that might read like a complication, it might actually be a simplification that helps.

Thoughts

TT

[TiddlyTweeter]

Ciao TonyM

I am NOT of the view that it can't be done. 

But I think Bimlas' reply was good in underlining that, sooner or later, in one way or another, you will have to deal with cross-OS issues even if browsers work the same wherever. The universal browser will not solve it once the OS gets a grip.

I AM of the view that the CAVEATS I described in my first post are the major barriers that come up, and I gave suggestions on possible resolutions. They were just broad comments, but maybe not so far off the point?

TT 

[TiddlyTweeter]

Ciao Bimlas

The main problem is that there are different operating systems and browsers, so you can't create a "generic" saver plugin: each system will need different code to automatically save the wiki, and not all of them can be implemented (because of restrictions to access the filesystem).

"Generic" is as generic does. TonyM is looking for a minimal route where a user could rely on SOMETHING that looks the same on all platforms. So there are TWO issues ...

1 -- Universal USER experience

2 -- BACKEND probable OS variations

I think the Timmimi plugin (or similar) should be upgraded to work in every browser, as this is the easiest solution to use: just open the wiki and it saves the changes automagically. Of course, the problem is that it only works on the desktop, for example, you may not be able to install browser add-ons on Android.

Riz did a great job on that. I think its very unlikely (he's a busy doctor) he would ever have time to extend it. 

He'd probably be happy if someone else could help :-)

Another option is to write the wiki to a location that is accessible on all systems: this is browser local storage, but it is not perfect either.

Right. The new TW plugin for that underlines the issues. Backup of Wiki would offset the issues ... but then you back in OS territory making that?  

The third option is to save it to an online location (GitHub, GitLab) because it works with all browsers and operating systems, but this requires the Internet, and you may not even want to save your notes online.

A CLOUD solution seems excellent. NoteSelf, for instance, is proven very good in architecture, but daunting to set up. 

I don't think there is an issue that sometimes you are offline. Decent Sync deals with that. 

I'd say the issue is this: there is, as yet, no TW Cloud Provider that is "Click-n-Go". 

Thoughts

TT

[TonyM]

TT

I agree with what you say in general such that cloud is likely to be a common delivery.

However, I am still looking to simplify the ability for a user to make a wiki there own, a single file that they save and can edit.

I believe we are yet to uncover a hack or trick or minimal viable method, that will not be the answer to everything, but reduces this first step.

not multiuser, not cross device just easy and reliable.

Regards
Tony

[TiddlyTweeter]

Ciao TonyM

Got it. 

I think you will hit an impasse on that thought between Desktop and Mobile that can't be bridged?

You might solve it by dividing the issue into DT & Mobile solutions?

It might also be interesting to work back from a mobile solution to the DT to see IF there is a trick in common.

FYI, as you know, Mark S. & I created POLLY for desktops that has powerful automation---but NOT suitable here as it would need too many steps and would be limited to desktop only. Yet Polly shows that some TW issues can be solved well by using OS basic batch run commands rather than TW directly. 

So I think its partly a matter of finding a common-core that is cross-OS.

Maybe, "in-browser saving" linked with OS mediated safety backup could work for your aim?

But necessary safety restore of in-browser stored TW, so far as I know, does not exist yet. 

And I think you would need that.

Thoughts

TT

TonyM wrote:

... I am still looking to simplify the ability for a user to make a wiki there own, a single file that they save and can edit.

[TonyM]

TT

Full agreement.

A little speculation

For mobile if tiddloid could be installed from the wiki or play store and passed the url to the published wiki It would be localised and savable.

Desktop a downloadable installer for all OS or local storage save and restore to file (If nessasary) changes only mechanism.

Store changes in a bookmarklet or browser add-on.

Regards
Tony

[TonyM]

A minimal cross platform file server that can be installed with single exec on a known port that tiddlywiki can detect and save to load from. E.g. on node.

[TiddlyTweeter]

Ciao TonyM

IF that could be installed seamlessly so the user would not need to have ever deal with what a "port" is ... ???

Do you think that is possible? How would you install it? Setup setup (sic.) executables for all platforms ???

My query: isn't this already heavily OS implementation specific?

Doesn't seem to match the OP :-)

TT, x

[Mark S.]

Even on the desktop, TiddlyDesktop has complications that most every-day users would find unacceptable.

If you close out a single-file window, the only way to get it back is to close out ALL your windows, and the

instance (which may need to be killed with the process manager), and then restart. That's too much,

when all you wanted was to clear the clutter out of your toolbar.

There is no universal solution because each solution attempts to put a round peg into a polygonal hole, in some regards.

Javascript is the peg, and the various platforms and approaches are the holes. A solution that works for one, won't

work for another.

What we really need is a hacked browser that doesn't have the save limitation built in. In essence, that's

what you're doing on Android with the Android savers. Perhaps the browser would be prevented from

browsing the web (because that is dangerous), but it would open up all the other possibilities you get

when using a browser.

Actually, it's probably just a tiny part of the 32 million lines of code in modern browsers that regulate

how saving works. And there's multiple projects based on hacking current browsers.

-- Mark

[Jeremy Ruston]

Hi Mark

> Even on the desktop, TiddlyDesktop has complications that most every-day users would find unacceptable.
> If you close out a single-file window, the only way to get it back is to close out ALL your windows, and the
> instance (which may need to be killed with the process manager), and then restart. That's too much,
> when all you wanted was to clear the clutter out of your toolbar.

I think you're talking about one of the limitations of using wiki folders with TiddlyDesktop (which is rather experimental); windows of single-file wikis can be closed/reopened as expected.

Best wishes

Jeremy

[Mark S.]

Oh yes -- I got it backwards. I guess then perhaps it could be the single-file, desktop solution. Though

you still have to go into the process manager and kill off several nw.exe processes. I don't mind too

much, but I think it would be too confusing for people who only use computers minimally.

Thanks!

[Mark S.]

We could look at how the big players, like Evernote, solve this problem.

They solve it with lots and lots of money! They create solutions for the cloud and for each and every platform.

We could do something similar, specify the best solutions for every Platform/method choice.

It seems that it might be possible to declare the "definitive" solution for each combination of

platform/OS/type.

e.g.

Desktop / Mac-Windows-Linux / Single-file : TiddlyDesktop

Desktop / Mac-Windows-Linux / Data folder: Bob, node.js, Tiddlyserver

Android / v5+ / Single-file: <-oid>

Android / v5+ / Data folder: Termux/TiddlyServer

Cloud/non-private / * / Single-file: Tiddlyspot

I think we need to be browser-agnostic. Asking people to install a special browser just

so they can run TiddlyWiki is probably too much.

If we had to mandate a browser, we could just specify an old version of FF with tiddlyfox.

Edit: TiddlyDesktop is a bit out of date, but that only matters (much) for data folders, not the single-file wiki..

On Sunday, November 17, 2019 at 7:03:52 PM UTC-8, TonyM wrote:

Folks,

This post is seeking input from the community to overcome what I perceive to be the last big issue in saving. It may seem only suited to experienced users but perhaps you know something we don't, so please be brave and contribute.

Tony

[bimlas]

I don't know yet if it's really usable, but maybe something similar could be done to make the same system a saver on all platforms:

https://flutter.dev/

"Flutter is Google’s UI toolkit for building beautiful, natively compiled applications for mobile, web, and desktop from a single codebase."

I don't know if it has file system access, but if so, we could merge TiddlyDesktop and Tiddloid / Quinoid applications.

[TiddlyTweeter]

TiddlyDesktop is OOD because everything else progressed around it already.

Give me a release of TWD with relative pathing to Wiki and within a recent version of TW....

TT

Mark S. wrote:

Edit: I didn't realize how out of date TiddlyDesktop was. I guess it's back to the default download saver.

[bimlas]

I don't know if it has file system access, but if so, we could merge TiddlyDesktop and Tiddloid / Quinoid applications.

... it has: https://flutter.dev/docs/cookbook/persistence/reading-writing-files 

[bimlas]

Another similar option: A mobile, desktop and website App with the same code

Article: https://medium.com/@benoitvallon/a-mobile-desktop-and-website-app-with-the-same-code-dc84ef7677ee
Code: https://github.com/benoitvallon/react-native-nw-react-calculator

[bimlas]

I have another idea: we may not be able to find a solution that works on all platforms, but since the only goal is to save the file, there may already be a workaround that others have already done and we just need to use. I am thinking of Google Drive, Dropbox, Syncthing (which is open-source): they can handle even if the user is offline, so they can also be used to explicitly use them offline. I don't know if it is possible to make a request to the apps from a browser, so far this is just an idea.

[Mark S.]

None of these solutions will copy from one place on your hard drive to another place on the same hard drive.

That's why we made Polly -- which automatically copies files saved in the download folder back to their original home.

It's possible that there are other automatic file movers/relocators that could be configured to do something similar.

[bimlas]

Mark S,

None of these solutions will copy from one place on your hard drive to another place on the same hard drive.

That's why we made Polly -- which automatically copies files saved in the download folder back to their original home.

But as I know the problem is, saving to the file system is not easy enough, it is relatively complicated for beginners. Where to store files on your hard disk is less important to me than being able to automatically save the wiki from your browser to your hard disk without using the file selection dialog.

As I understand it, Polly (which I haven't tried before, so I might have misunderstood) also requires manual backup (so that you press the "Save changes" button yourself), so it is as foreign to the new users as the built-in default download saver (EDIT: after turning on $:/Config -> Saving -> Download Saver -> Permit automatic saving, I think I understand Polly's purpose). The opening comment is that this type of backup mechanism (saving their wiki via dialog) scares people who are just getting to know TiddlyWiki (as it did with me first) because it seems overly complicated. I envisioned using the above mentioned applications as a separate saver and new users would have to do just one setup (saver selection) so they could easily use Tiddly.

I'm sorry, but I'm going to get a little out of the original topic:

Let's see who uses TiddlyWiki for the most part: scientists, teachers, technical people, programmers, so intellectuals. I do not think this is a coincidence, because the use of TiddlyWiki is basically not easy to understood for average users. TiddlyWiki is not for those who want to create a point-and-click notebook, but for those who want to manage, search, and reuse their notes, knowledge, and data at a higher level. I think that's what brought this "high quality" community to life, because only people who see the opportunities in TiddlyWiki are committed to it. Those who just want to categorize their notes will skip cognition because they find it too complicated.

I don't really know if it would be useful to make TiddlyWiki as easy as possible. If it would be so easy to handle that a five year old would understand, I'm afraid this community wouldn't be as great as it is now. I think the difficulties that we are trying to solve in this and similar topics provide a natural filter: only people who overcome these obstacles will use Tiddly because they really need Tiddly.

[Mark S.]

On Monday, November 18, 2019 at 1:19:54 PM UTC-8, bimlas wrote:

Mark S,

None of these solutions will copy from one place on your hard drive to another place on the same hard drive.

That's why we made Polly -- which automatically copies files saved in the download folder back to their original home.

But as I know the problem is, saving to the file system is not easy enough, it is relatively complicated for beginners. Where to store files on your hard disk is less important to me than being able to automatically save the wiki from your browser to your hard disk without using the file selection dialog.

Really? You don't care where the file is saved to? In that case, just set up a special profile for Firefox (or Chrome, maybe), set your "root" wiki download directory, and use PMario's file-backups.

Now when you need TW, just launch FF with the profile, and you're all set to go. You can still use this for regular browsing, but it won't use the default download directory.

Set up different profiles for various "home" directories.

Don't know if Chrome has profiles that work this way.

Now that I've suggested it, guess I need to go try it ...

[TonyM]

Thanks all for your continued feedback

A point I would like to reinforce here, can be a response to Bimlas

I don't really know if it would be useful to make TiddlyWiki as easy as possible. If it would be so easy to handle that a five year old would understand, I'm afraid this community wouldn't be as great as it is now. I think the difficulties that we are trying to solve in this and similar topics provide a natural filter: only people who overcome these obstacles will use Tiddly because they really need Tiddly.

• I agree that the current audience for tiddlywiki has possibly being refined by selecting for those with the knowledge and experience to both see its potential and make use of it.
• However I have to disagree here because those with expert skills need a way to provide easy access interactive solutions to the broader audience. Simple use is not mealy a gap for the designers it is a gap for delivery of the results to the public.
• I am not asking here for the ultimate answer just a minimalist path to user interaction, such as if FireFox is on every OS platform then a firefox solution that is easy to follow would be a sufficient extension to the default save mechanism.

My vision includes the development of focused solution tiddlywikis that work when you discover them online, can interact with them immediately and make them your own. Local storage allows more than one change to be stored in the wiki, it is then possible for the wiki to be downloaded even using the default saver, most browsers permit you to set the download location or you can copy paste it from the download folder to a documents folder (This is standard user practice).

The Wiki can be reopened easily into any browser, but It is the next step that we suddenly get the complexity. 

This is when the saver becomes necessary and the Operating System and Browser comes into the formulae.

So Consider The Wiki can be reopened easily into another app as well

One avenue I have toyed with is saving tiddlywiki files with the .tw extension and installing a local binary, that on open it loads it into a "TiddlyDesktop like app" with no additional chrome or wiki selection, just that wiki. Of course this solution will need a multi-os install binary. The advantage with this is you are not loosing the knowledge it is a tiddlywiki file by keeping it as a tw file so it does not just revert to the default browser. The wiki then becomes a "document" that the Operating system associates with the local binary.

So in the above model  when online we provide an "offline" backup, of changes, and the opportunity to download, where it becomes a document with a helper app available if you want edit locally and full access to the local machine, which typically is what you expect after downloading a document, not reverting back into the online browser where security is a concern and a barrier to us.

Regards

Tony

[TiddlyTweeter]

Ciao Bimlas

Though I understand where you are coming from on this ...

bimlas wrote...

TiddlyWiki is not for those who want to create a point-and-click notebook, but for those who want to manage, search, and reuse their notes, knowledge, and data at a higher level. 

I don't think that is correct in principle, though it might tend that way in terms of actual usage (but lacking data on wider usage of TW I'm not sure on that). 

Point-&-click for many apps could be easily built in TW. 

The issue would be defining "what is the app. for"? In other words its a developer's job to design for use cases. 

I don't think TW has any inherent requirement that it be used for anything in particular. It seems, rather, a kind of self-changing mini development environment.

So let's not confuse "development" with "final app." 

In this group discussion naturally tends to focus on tweaking, understanding TW's coding, its syntax and example results.

But that isn't the same as what an end-user would have to deal with for an app. written in TW.

Its exactly the same issue, in a way, as conventional software. I use Word, I don't need to know how its code works.

Best wishes

Josiah

[TiddlyTweeter]

Ciao TonyM

Couple of footnotes to this ... 

TonyM wrote:

One avenue I have toyed with is saving tiddlywiki files with the .tw extension and installing a local binary, that on open it loads it into a "TiddlyDesktop like app" with no additional chrome or wiki selection, just that wiki. Of course this solution will need a multi-os install binary. The advantage with this is you are not loosing the knowledge it is a tiddlywiki file by keeping it as a tw file so it does not just revert to the default browser. The wiki then becomes a "document" that the Operating system associates with the local binary.

I'd say that software on mobile phones is rather good at "wrapping" the TW "document". I assume its still using a "browser" inside Quinoid, Quine & Tiddloid (?) but they provide examples of the near seamless experience you are referring to.

And the issue with a "wrapper" for TW on main desktops I think is broadly solved by TiddlyDesktop (though there are issues on its portability that would need solving).

It might be worth experimenting with TD to see if it can be tweaked to fully match your objective?

Best wishes

Josiah

[okido]

Hi Tony,

Let me share my experience as a long time TW user.

I started with TWclassic on a usb stick and Firefox portable.

This gave me a lot of freedom, it was easy to move the files around between Linux and Windows systems without needing admin rights.

Read, write actions to the file system was easy and I made some TWc’s that relied on this heavily.

More restrictive browsers made me think how to overcome the the problem of restricted access to the file system as some of my TWc got broken.

Secondly whenever I promoted TWc as a tool to make work lighter and easier I stumbled over the saving issue’s.

I tried most savers but was not satisfied, in most cases they did not run out of the box. TiddlyDesktop came close to what I needed.

However, I use only TWc and I did not want to have the TW5 code overhead in TiddlyDesktop.
So I decided to switch to NW.js and wrote a saver for TWc, access to the file system is very easy.

I can move the TWC files between Linux and Windows again and all functionality is restored, the same functionality as when I started years ago. In one instance of NW.js you can open as many TWc’s as you need, they run in independent windows. I must say that NW.js runs stable and it is fast.

Still there is file structure dependency, you cannot put your file in any location and run it from there. Files in folders downstream from the NW.js application work out of the box.

For me the way to go is to make use of the relation between file extension and default application.

A file with an extension like .tw will be opened by the default application that in my use case will be NW.js.

For me TWc has become a framework now that I use in NW.js. This delivers me flexible applications for note taking, project management, data analysis and report creation.

Browsers I hardly use anymore for TWc.

Have a nice day, Okido

[TonyM]

Thanks Okido.

This points it one direction I have being thinking about. A simplified node install perhaps. Do you control which wiki is hosted with scripts?

can you see a version of your solution being easy to setup for new users?

Thanks for your perspective.

Tony

[TiddlyTweeter]

Where is BOB is this discussion?

Just wondering. It seems very pertinent.

Node based, or node wrapped in EXE, with CLOUD possibilities.

Best wishes

TT

[David Gifford]

Hi Tony

Could there be a second version of tiddlywiki.com/empty.html that when you click the download button, you download a zip file with the saver file included, and a popup in empty.html with brief instructions? That way there could be a dead simple download with a saver, and a lighter download with no saver for those who just need a TW file.

Dave

[Mark S.]

Ok. This seems to be working. Knock on silicon. It's about as easy as it's going to get.

1. Install firefox (ignore what I said about browser-agnostic)

2. Create a profile for TW files and boot with it the following steps

3. In the settings, set your download dir to the the root of your system (usually C:\)

4. Reboot FF with profile

5. In the add-ons, look for PMarios' file-backups. Install.

6. Reboot FF with profile

7. Create a short-cut for the FF with profile, if desired.

Now any TW files inside your main file system will use the file-backups to save. You can make

other profiles if you have other drives (e.g. flash drives) where you need to save. Note that if you

change your download directory, you may have to reboot FF.

Think of FF-with-profile as its own app.

No executables are required except FF. No additional servers or processes running. No configuration files.

[TonyM]

Mark

Thanks for finding another method, this is out of the box as they say. I wonder if the setup can be automated.

I am sure you can see this is minimalist as far as its changes to the users computer but not minimalist as far as the complexity to a new user.

Great response though
Tony

[TonyM]

David,

Your suggested approach looks similar to other installs and uses a path many will be familiar with so it has merit. Now lets think what saver we include.

By the way I would like to see the zip contain the online wiki with content including user changes and the saver so they continue working. Or something similar.

Regards
Tony

[Mark S.]

I think it's also as minimalist as it's going to get for users. Most users can install software. Most users know how to use a browser and install extensions.

There is no save mechanism with TW. That's the simple fact. Any attempt to work around that fact will add complexity one way or the other.

So the next best thing is to come up with a process that uses steps the user is already familiar with.

[TonyM]

Mark,

I am however keen to see if there is an easier way. Timimi is easy to install and currently works on FireFox and the following oS

• Debian based systems - Debian, Ubuntu, Elementary, Mint etc
• Arch based systems - Arch Linux, Antergos, Manjaro etc
• Windows 7 and later.

If we could find a way, perhaps even crowdsource its development on other key browsers then we should have a fairly universal solution.

Currently Timimi needs Firefox, an Add on and 

Part of its universality comes from the fact Timimi allows tiddlywikis to be treated as documents on any platform, thus leveraging the basic computer skills most users have. Using a .tw file would help further, adding an association to a browser such as FireFox with the Timimi add on whether or not it is the default for html files.

[TonyM]

All,

This is proving to be a great repository of ideas, savings mechanisms and exploring the possibilities.

One method I have being wondering about is how TiddlyServer handles single file wikis. Clearly it makes use of node for the folder based wikis and the wikis appear at http:/ipaddress/virtual/folder but this requires the somewhat cumbersome settings.json file.

I wonder if an executable install of a subset of TiddlyServer/or Node, to save tiddlywikis at a standard location eg Documents/TiddlyWiki and a link to eg:  http:/ipaddress:8081/ where Documents/TiddlyWiki is the root folder and supporting files like node installed elsewhere, such that it serves single File Wikis (at least). With a custom association perhaps we could Double click a tw file and it will open at http:/ipaddress:8081/twname.tw or http:/ipaddress:8081/foldername/twname.tw

In this case it is one install script per Operating system and this is minimised using node and a fixed tiddlywiki folder. This would be mostly browser independent.

The ability to be online in a wiki and and some how use the download or default save, to save a wiki to the above documents/tiddlywiki would make access to and saving future wikis and editions simple.

Just further ideas

Tony

[TonyM]

Further to Timimi use

In FireFox I can browse to a folder location such as file:///C:/Data/TW5/Development and see the files there, such that clicking on empty5.1.19.tw would open that file in the browser and Timimi is engaged and works. This means both explorer (other platforms equivalent) and directory browsing in the browser provide a file manager for tiddlywiki files. Especially if we set a standard folder such as documents/tiddlywiki or in windows file:///C:/Users/username/Documents/tiddlywiki/

Regards

Tony

[PMario]

Hi,

Tiddlywiki is an .html file and I don't see a reason to change the extension. This will only cause problems in the future.

html is html is html.

-mario

[Arlen Beiler]

Tony, 

I've read most of this thread and find it quite interesting. Yes, we really do lack a simple way to save TiddlyWiki5 years after the FireFox Apocalypse. But there are many more options available that have not been put to use yet, or fully fleshed out. Why? I think it is funding. I personally could write all the solutions you could ever need but I do not have the funding to support myself while I do it. I know there are a couple of others here that might be similarly skilled but might not have the funds. I don't know what other people's schedules are like, but mine is fairly ad-hoc and I could probably make room for it in my work week. 

Now, what solutions are there? There are quite a few. 

TiddlyServer does support saving single-file wikis as well as data folders. Not sure why that wasn't mentioned earlier. And you could easily fit TiddlyServer into Electron if you really wanted to so it would be its own app, but that's not necessary. 

A Chrome/Firefox/Edge plugin that connects to a program installed on the user's computer and allows wikis to be saved. It would definitely have to have some safety controls built-in, such as only allowing local files to save and only allowing them to save back to their own file, but it is a very viable option. It's probably the closest way to match the abilities of mobile apps. 

Mobile works so well because apps can include a browser window directly in the app and communicate with that window through various pathways. So mobile is actually much easier to solve, and the technology is already in common use. It's possible to run TiddlyServer on Android, but not iOS (that I could find). 

Cloud connectors have been made by myself and others, but they have not been maintained, mostly because of lack of funds or interest, I suppose. They are, however, a very good option for single-file wikis and could be set up for data folders as well, though this is much more complicated. But for highly mobile users who store their stuff online (a lot of business people do), this is a pretty good option. 

There are different ways we could use cloud connectors. We could store them in the wiki, or host them on github.io and allow you to access your Dropbox or other online storage accounts. We could also hook up a wiki to GitHub to track revisions directly from GitHub. I don't know how this works but I'm sure it would be easily possible. The options are almost as limitless as the cloud storage platforms available to use. 

I recently came up with a system where the core and other large plugins can be loaded from the web, which requires a dependable internet connection, but in these scenarios works perfectly fine. And a bonus is that the plugins are cached after the first use so a subsequent page load can be a lot faster. 

I would say as a community we have barely implemented half of the available options. We've probably implemented the easy half. The other half is easy for people that are experienced with web frameworks and web development but it just takes time to build solutions. 

I know there are a few people here that know as much and more about software development than I do, and there are people here that have poured even more their own free time into TiddlyWiki than I have and I am very grateful to those people. So I hate even mentioning money. But that really is what holds me back from implementing some of these more advanced solutions. A year ago I didn't have much time, but I do have more time now, as I'm no longer living in China. So I'm not begging for funds or asking anyone to donate to my cause. Rather, I do believe that is the main reason more advanced solutions have not been implemented. With TiddlyServer, I did a lot of the R&D for a work project, and a lot of the grunt work I did during a week of school because I needed a better way to organize my notes. Recently I did a major rewrite in my spare time, but it's not easy for me to do that. 

I know there are others here who are very qualified to get paid for their work, and I'm not wanting to turn this community into a marketing campaign at all. I value the free sharing of ideas and often contribute myself. I also know that there are plenty of people here who use it for work and sometimes I wonder (as a freelancer does) if some of them might be willing (as many business people are) to pay for some more advanced solutions or at least help support their development. 

Just my thoughts. I welcome other perspectives on these things.

Arlen

--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/57d70753-639f-4c09-ada1-b128b3963513%40googlegroups.com.

[Mark S.]

I understood the question to be, not "What is a good saving mechanism for TW?" but "What's the best solution for the non-technical person?". TiddlyServer

might be the best over-all solution (hypothetically), but it's not simple. You have to install and configure node. You have to download a version of TS. You

have to unzip, You have to copy a configuration file and then edit it with an editor. You have to make sense of weird-sounding parameters.

Then you have to remember to launch it and you have to know howto navigate on the url bar. I've typed 127.0.0.1 thousands of times.

It doesn't look strange to me. But it does to noobies. Configuration issues are also

why Bob isn't in the running, IMO. But I would be curious to see how it works with the new single file saver.

The same logic applies to Polly, which requires configuration.

These concerns would be relegated mostly to Mac and Windows. I figure anyone on Linux would not find these issues difficult.

These days, I think we can assume that users know how to download and install regular, certified software like Firefox. There is hand-holding

built into these activities already. You don't have to know much about file structure, for instance. Once firefox is up, then you can install

extensions just by clicking on an icon and searching for a name. Not too technical. After that there's only one small configuration issue --

you have to specify the root drive for downloads. If this is your only FF instance, then all a person has to do to launch a TW file is to

right-click and select "Open with Firefox".

The problem I see with a Plugin that connects to a program on the drive is installation of the file and certification. It really needs to a

certified app so that the user doesn't get these dire messages and so that the IT department doesn't throw a fit. Then someone will

have to maintain an extension on Edge, FF, and Chrome -- a constantly changing target.

Perhaps you should put together an estimate of how much work / money it would take to make an all-in-one single file solution.

On Wednesday, November 20, 2019 at 11:28:37 AM UTC-8, Arlen Beiler wrote:

Tony, 

I've read most of this thread and find it quite interesting. Yes, we really do lack a simple way to save TiddlyWiki5 years after the FireFox Apocalypse. But there are many more options available that have not been put to use yet, or fully fleshed out. Why? I think it is funding. I personally could write all the solutions you could ever need but I do not have the funding to support myself while I do it. I know there are a couple of others here that might be similarly skilled but might not have the funds. I don't know what other people's schedules are like, but mine is fairly ad-hoc and I could probably make room for it in my work week. 

Now, what solutions are there? There are quite a few. 

TiddlyServer does support saving single-file wikis as well as data folders. Not sure why that wasn't mentioned earlier. And you could easily fit TiddlyServer into Electron if you really wanted to so it would be its own app, but that's not necessary. 

A Chrome/Firefox/Edge plugin that connects to a program installed on the user's computer and allows wikis to be saved. It would definitely have to have some safety controls built-in, such as only allowing local files to save and only allowing them to save back to their own file, but it is a very viable option. It's probably the closest way to match the abilities of mobile apps. 

Mobile works so well because apps can include a browser window directly in the app and communicate with that window through various pathways. So mobile is actually much easier to solve, and the technology is already in common use. It's possible to run TiddlyServer on Android, but not iOS (that I could find). 

Cloud connectors have been made by myself and others, but they have not been maintained, mostly because of lack of funds or interest, I suppose. They are, however, a very good option for single-file wikis and could be set up for data folders as well, though this is much more complicated. But for highly mobile users who store their stuff online (a lot of business people do), this is a pretty good option. 

There are different ways we could use cloud connectors. We could store them in the wiki, or host them on github.io and allow you to access your Dropbox or other online storage accounts. We could also hook up a wiki to GitHub to track revisions directly from GitHub. I don't know how this works but I'm sure it would be easily possible. The options are almost as limitless as the cloud storage platforms available to use. 

I recently came up with a system where the core and other large plugins can be loaded from the web, which requires a dependable internet connection, but in these scenarios works perfectly fine. And a bonus is that the plugins are cached after the first use so a subsequent page load can be a lot faster. 

I would say as a community we have barely implemented half of the available options. We've probably implemented the easy half. The other half is easy for people that are experienced with web frameworks and web development but it just takes time to build solutions. 

I know there are a few people here that know as much and more about software development than I do, and there are people here that have poured even more their own free time into TiddlyWiki than I have and I am very grateful to those people. So I hate even mentioning money. But that really is what holds me back from implementing some of these more advanced solutions. A year ago I didn't have much time, but I do have more time now, as I'm no longer living in China. So I'm not begging for funds or asking anyone to donate to my cause. Rather, I do believe that is the main reason more advanced solutions have not been implemented. With TiddlyServer, I did a lot of the R&D for a work project, and a lot of the grunt work I did during a week of school because I needed a better way to organize my notes. Recently I did a major rewrite in my spare time, but it's not easy for me to do that. 

I know there are others here who are very qualified to get paid for their work, and I'm not wanting to turn this community into a marketing campaign at all. I value the free sharing of ideas and often contribute myself. I also know that there are plenty of people here who use it for work and sometimes I wonder (as a freelancer does) if some of them might be willing (as many business people are) to pay for some more advanced solutions or at least help support their development. 

Just my thoughts. I welcome other perspectives on these things.

Arlen

On Tue, Nov 19, 2019 at 10:02 PM TonyM <anthon...@gmail.com> wrote:

All,

This is proving to be a great repository of ideas, savings mechanisms and exploring the possibilities.

One method I have being wondering about is how TiddlyServer handles single file wikis. Clearly it makes use of node for the folder based wikis and the wikis appear at http:/ipaddress/virtual/folder but this requires the somewhat cumbersome settings.json file.

I wonder if an executable install of a subset of TiddlyServer/or Node, to save tiddlywikis at a standard location eg Documents/TiddlyWiki and a link to eg:  http:/ipaddress:8081/ where Documents/TiddlyWiki is the root folder and supporting files like node installed elsewhere, such that it serves single File Wikis (at least). With a custom association perhaps we could Double click a tw file and it will open at http:/ipaddress:8081/twname.tw or http:/ipaddress:8081/foldername/twname.tw

In this case it is one install script per Operating system and this is minimised using node and a fixed tiddlywiki folder. This would be mostly browser independent.

The ability to be online in a wiki and and some how use the download or default save, to save a wiki to the above documents/tiddlywiki would make access to and saving future wikis and editions simple.

Just further ideas

Tony

--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.

To unsubscribe from this group and stop receiving emails from it, send an email to tiddl...@googlegroups.com.

[Jed Carty]

I am a bit curious what configuration Bob requires that prevents it from being useful here? If you use BobEXE than you just download it and open it.

There are undoubtedly bugs in the saver because so far I am the only one who has used it, but once Bob is running and the saver plugin is installed you just open an html file normally by double clicking on it and then as long as Bob is open it will save to the same file that you opened. There shouldn't be any browser restrictions or anything other than you have to have Bob running.

[Arlen Beiler]

Researched a bit, and we're not the only ones that want to edit desktop files. Web apps are becoming more common and Chrome and Firefox are working on a solution to this problem. So the solution for desktop single-file wikis should be somewhat simpler a year or two from now. 

There is one solution that doesn't use any kind of major integration but instead would establish a secure session between the extension and a Node executable listening on a certain port. You could copy a key from the Node console and paste it into a text box in the extension settings page and it would be securely connected. The only permission needed would be the ability to listen on localhost on a user-defined port. This would take about 20 hours to implement a basic TiddlyFox saver or to integrate a regular configuration page for TiddlyServer which allows the user to browse the file system and select folders from TiddlyServer point of view. This would make TiddlyServer much easier to use in my opinion. 

Also, just saw on the Quine forum today that Quine 2 is in the works, so some support there would probably help, I'm sure. Quine 2 is going to have support for the Files app, though I don't know what all that entails. Quine is for the iOS platform. 

Bringing the Electron prototype I already have up to speed would probably take about 20 hours. 

Putting TiddlyServer into Electron would justify a number of additional features that are hard to justify using Node for security reasons. That would probably be a much larger project. Say 60 hours or so. The same features could also be implemented using a browser extension and the secure channel I mentioned above, which would take less time and still allow users to keep their other extensions such as Grammarly. 

Arlen

To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/bc2d6016-c882-4536-ae30-8d400d848d86%40googlegroups.com.

[Jed Carty]

Your description of the node executable listening on a port is exactly what the BobSaver does. So that part already exists. At the moment the security is that it just accepts connections on localhost, I don't think that saving files locally makes sense for a remote connection.

[Arlen Beiler]

There are different scenarios being considered here. TiddlyServer already does what you mentioned, however there are some more advanced options we could implement. What I'm referring to is that file:// urls can be saved back to the filesystem via TiddlyFox calling Extension calling a Save Handler on a localhost listener with a preshared key allowing only the extension and nothing else.

On Wed, Nov 20, 2019, 17:01 Jed Carty <inmy...@gmail.com> wrote:

Your description of the node executable listening on a port is exactly what the BobSaver does. So that part already exists. At the moment the security is that it just accepts connections on localhost, I don't think that saving files locally makes sense for a remote connection.

--

You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/3a52e5ec-f8c2-4bbe-8b31-2d22b6a1e9c7%40googlegroups.com.

[Arlen Beiler]

Actually, I just looked it up, and you're right, it is quite similar. The difference in my scenario is it installs the plug-in in the browser instead of the wiki. I will definitely look into this more. 

[TonyM]

Thanks all for your continued feedback,

If I may make a few comments in regards to some replies specifically. It is not that I proclaim to be an expert of the person that decides which idea is a good one, it is just an attempt to try and coral your wonderful feedback towards the objective of the Original Thread OT.

I will do a second post on funding.

To all, Thank you, you have all contributed much.

Okido/Mario,

The key value of the use of a .tw file is simply to differentiate it from other html files, which will only ever open in the default browser unless you use open with which is a clumsy requirements. Tiddlywiki could open in a default browser without the saver available and work be done before it is discovered it will not save. Keep in mind the .tw file remains a html file as defined in its content and most browser open it successfully. This is not unlike the already possible saving as a .hta (IE Windows only?) and .aspx such as on sharepoint servers. This is in my view important when treating a tiddlywiki as a document by a given name, less so if naming it index.html on a host.

TT,

You make a point between Mobile and Desktop, there are good reasons for these to be treated differently, installing an app is common place. One advantage of Tiddliod including lite is you paste in a internet hosted tiddlywiki and it is "installed" into tiddloid. It would be nice if we could provide the following workflow for existing apps;

• On an internet published wiki, To place this Tiddlywiki on your mobile install "appname" then share this URL with "appname" and it will download your own copy to you phone.
• Jed has suggested Bob.exe can do something similar on desktop, and has extended it for single file wikis - I will review at my earliest.
• TT you have a lot of good ideas there and I will consider them in more detail, I think you hint at something I would like and that is an andriod or iphone app that is a shell in which you can fit a single tiddlywiki and distribute as an app in the app stores. I would pay for this because it may have an immediate return on sales. It may give those seeking some returns an opportunity as well.
  TT the idea of TW as content is in effect why I want to see the content openly available to "drive by" use on the internet. I want many content instances to be available to make your own so we can all start publishing more widely.
• TT as you say Maybe, "in-browser saving" linked with OS mediated safety backup could work for your aim? I think this may be the first step yes, I will outline my thoughts in this below in First save post
  

Bimlas,

• I think if TiddlyDesktop was installed and we had a way to share a url within the browser which it downloaded a given tiddlywiki "edition". It already solves many of the issues including browser and OS, we just to make it less than a hop, skip and jump. Imagine an option to send to TiddlyDesktop.
• I agree cloud solutions may be the most common and popular approach at some point in the future as tiddlyspot already is. I would like to see gitub publishing of TiddlyWiki's similar to the core so people can raise issues and changes to specific editions. But to me this is beyond this initial experience problem.
• Your suggestion once again out of the box such as flutter is great, but I suppose only a few here can consider the possibility of this. I too think trying to adopt PWA Progressive web App standards would be great, they in effect address the issues in the OT however we may not meet some of the load time criteria initially, but do we have to. 

Jed/Bob

• I think JED is right in noting we have missed how we can use bob, he has created the single file plugin I am keen to test. Bob is so rich with features it has been hard to confirm exactly what can be done with it.

Jeremy/TiddlyDesktop

• Good OS platform support, easy install, would work well if .tw files could be associated with it, and or we could open in, or share to TiddlyDesktop from Internet etc.. 

All the rest of you Mark, Arlen Bimlas, Jed, Mario, David etc.. Lots to work through thanks

Regards

Tony

[TonyM]

The First Save idea

I am wondering if installing the local storage and rather than provide a download you tiddlywiki we just provide a save your changes button, a backup of changes only that can be restored if the browser looses this storage. I imaging this could smooth the simple drive by but want to save there changes crowd.

Regards

Tony

[Arlen Beiler]

Can we somehow pin this?

--

You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/5b453d02-e774-4356-82fb-74e6c09e5336%40googlegroups.com.

[TonyM]

Funding,

Arlen, Jed in the past and others raise the thorny issue of funding. I will too. I would be dropping money on Arlen and Jed , bimlas and others if I were not (mostly) unemployed. I too have a number of ideas and changes, I think most people would like be compensated where possible, I want to contribute a lot more as well but find it hard to justify my effort when if I do not earn money soon my partner may kick me out (only half in Jest). I recently thought of running some small campaigns to seek funding for my own work, but I would urge those already seeking funding to persist and promote.

I think we are all very careful and polite on this when often people are generous and understand that time and skills are money, Perhaps we can start a seperate thread on this?

Regards

Tony

[TonyM]

Arlen

On mobile at least you can pin it for yourself, see top right in thread. an admin needs to do it for all.

Tony

[PMario]

On Thursday, November 21, 2019 at 2:23:27 AM UTC+1, TonyM wrote:

The key value of the use of a .tw file is simply to differentiate it from other html files, which will only ever open in the default browser unless you use open with which is a clumsy requirements. Tiddlywiki could open in a default browser without the saver available and work be done before it is discovered it will not save.

TiddlyWiki will save! ... There will always be the "default saver".

The only disadvantage is: inconvenience. Browsers add "(1), (2) .. (x)" postfixes to the file names. BUT TW will save as a .html file.

It should be possible to let the default saver open an info tiddler, that explains, what's going on and present a "Save As" button, instead of the OS specific default "Save File" or "Open With" dialogue.

So may be we can make the default saver workflow "more convenient". So the newbie user can understand what's going on.

-mario

[Jed Carty]

Creating and maintaining a set of browser plugins is far more complex than required considering all the browsers that need to be supported. Adding the BobSaver to the core and using either Bob or something else that can use the same saver. It doesn't have to be Bob, or even written in node, anything that can accept http POSTs can work. Then it works in any browser and doesn't require maintaining any browser plugins or anything like that.

Creating a simple iOS application that handles saving using the same saver wouldn't be too difficult. I haven't done any significant android development but I imagine it would be simple as well, it is just a server that accepts POSTs and saves the received file. In both cases I think that handling file permissions is the hardest part.

[TonyM]

Jed

I think that is a good idea. Perhaps we can find an existing one that available. I am keen to see if we can identify a simple work flow from in browser discovery to making it your own and being able to save and reopen in a trusted location. I love the multiple wiki bob, TD and TS but there is no harm of providing a single wiki at a time solution. Once someone uses a for purpose tiddlywiki a large percentage will start to use it as a platform, look at its possibilities and the the multi wiki solutions.

I am just keen to make the initial use and private data very simple.

As Mario says a big part is presenting information to the user that guides them.

I think the more generic the solution the better and a side effect may be a more useful tool. I wonder if such a saver/server could be delivered as a progressive web app then tiddlywiki leverage that, in effect allowing install of the saver on desktops and mobiles without having to turn tw into PWA but giving it the local saving features of one.

REGARDS
TONY

[Jed Carty]

These keeps coming up so I am going to say this again.

A progressive web app can't save to the locally in the sense used in this thread. it saves to the browser cache, it has no more access to the local file system than we already have. if it did then we would use that mechanism to save and none of this would be a problem.

Delivering tiddlywiki as a progressive web app is going backwards as far as saving is concerned, tiddlywiki is set up so that you can always use the download saver, PWAs save to the localStorange which is just dressing up the browser cache.

LocalStorage is NOT the local file system, it is the browser cache. It doesn't solve anything about our saving problems. Progressive web apps don't have any privileges than tiddlywiki doesn't already have.

Tiddlywiki can either 1 - put the save in the core like all of the other savers it already has in the core or 2 - put the saver in a plugin and use the plugin library mechanism to distribute it.

The server component CAN NOT be delivered as a progressive web app because if it could you could directly put things on the file system from a browser and we would just use that mechanism to save and none of this would be a problem.

[TonyM]

Jed,

Thanks for clarifying this for all. 

My Suggestion on a PWA is only because my own reading and someone else's post have talked about getting reliable local storage (if not still within the browser) for PWA's.  

The need for this continues to be something a lot of designers and developers want and there are suggestions that such reliable storage mechanisms may be made available soon (see below). 

As you say if reliable browser local storage becomes available across browsers we may be able to use this directly from Tiddlywiki, however it may only become available to PWA's or versions there of which include a config file containing resource needs. Other community members have suggested other limitations to Tiddlywiki's mechanisms that would prevent it from becoming a PWA itself. Thus the speculative idea of having an independant PWA saver, if reliable local storage becomes available, and only if reliable local storage becomes available.

For example at this link we can see Safari and Edge do not have a cache eviction process thus browser local storage may be more reliable

Browser	Eviction Policy
Chrome	LRU once Chrome runs out of space
Firefox	LRU if the whole disk gets full
Safari	No eviction
Edge	No eviction

The above was found here https://developers.google.com/web/fundamentals/instant-and-offline/web-storage/offline-for-pwa

and includes a section;

Current and future offline storage work If offline storage interests you, the efforts below are worth keeping an eye on

Of course a PWA could be storing the data on a cloud service as well.

I expect there may be limitations to one tab communicating with another tabs PWA's.

Regards

tony

[TonyM]

All,

An example of a new User Tiddlywiki adoption work flow is raised by me here https://groups.google.com/d/msg/tiddlywiki/yebQtlKZMWg/t9QfADgCBwAJ

This example would make use of either Bob.exe and BobSaver Plugin or Timimi. 

Regards

Tony

[Jed Carty]

Tony,

A very large part of my confusion about what you are saying here is that local storage and localStorage can be very different things. I can not tell when you mean saving to the local file system vs saving using localStorage in the browser cache.

Another part is that the PWA standards that google is presenting are descriptive, a progressive web app is simply a classification for a website that uses the technologies present in the way described by google. Being a progressive web app doesn't give a website any privileges or access that aren't available to sites that don't follow the proposed standard. Nothing about the technologies listed on the page you linked are specific to websites that would be classified as a progressive web app.

I have used most of the storage technologies referenced in the linked page and none of them require anything other than html and javascript loaded in a browser like any other webpage.

All of the technologies are being developed completely independently of googles standards for what makes a PWA, they are not in any way dependent on matching those standards for usage.

[Stefan Pfister]

Hi,

# The Goal and big question:

 a simple way for naive and casual users to save their tiddlywiki (again and again)

I read this thread with much interest. In my opinium there is still one big aspect, which should be mainly considered. As a casual and non-technical user of tiddlywiki and as a teacher, who wants to show the students at school something with tiddlywiki I want to say:

The easiest way to use a tiddlywiki is to double-click on a file with a tiddlywiki in it. I doesn't matter which ending this file has. If it is "html", "tw" or something different. If the user can simply click on it and it opens in a way which makes it possible to use it without struggling with the saving mechanism.

This works with the so called hta-hack under Windows really well. Simply changing the ending of the tw-file to "hta" and you have a simple working one-file-tiddlywiki with saving mechanism. This is really usable. For me as the user the inner mechanism is not my point of interest. I can simply us this in class but only with windows devices. Something more universal and platform independent would be great.

A single TW-file with a working saving mechanism in it which opens per doubleclick in a browser or even in a separate portable program like TW-desktop (something which organises the saving) would be a great progress in usability for the non technical and casual user of tiddlywiki. This is the normal behavior of programs and files. The most simple users know this. This is an easy workflow. I use this kind of workflow every day. I simply don't want to install or configure something special in order to be able to save my work. But it is in most cases not much of a problem to install a app or a program in order to use it. I know there are restricted environments but for the normal user: The normal way to use a programm is to install something a *.exe or under linux a *.deb and simply use it.

Just my two cents.

Regards,

Stefan

[TiddlyTweeter]

Ciao Stefan

Great post. To the point.

Fully agree that the POINT in all this should be to enable users to do TW with the same level of simplicity they have for other apps. 

Basically, nowadays standard, it comes down to one approach for mobiles and one approach for desktops.

IMO we have, actually, MINOR, issues between now and full cross-platform unity of approach. So close. Yet so far off.

One thing, largely OVERLOOKED in this thread, with its (necessary) focus on mechanisms, is that end-users are primarily interested in CONTENT. 

They don't care HOW they get it, just so long it's simple enough. I wish "Desire for Content Delivery" would matter more here as it is a vital piece of understanding the issue ...

I really believe that normal end user working practice is central to this discussion. The issue is, I think, just this ...

• ... a person who wants to get something done, using conventional, recognisable, common, methods.

My 2 cents.

Best wishes

TT

(Footnote: Unfortunately TiddlyDesktop is not properly portable yet [it currently uses absolute addressing to wikis] so its not yet ideal.)

[Arlen Beiler]

I think the bob saver can be expanded to use a browser plugin. This can address some of the security concerns with having a freely available saver listening on the network. And it’s also simply installable as you say. I must have heard enough complaints about corporate networks that I thought those environments have all the trouble, but maybe I was wrong. I guess putting a simple working solution in place first and then improving it would get us a long way. 

--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/dabe0b3f-9095-45d0-86c5-65fd29a1441c%40googlegroups.com.

[Miha Lunar]

Hi there!

I've only skimmed previous posts so forgive me if this came up already, but I wanted to throw in my 2c.

Most of this is from the context of accessing TW from more than one device. Before I can talk about why having TW support PWA features would be a good idea, I want to give some background.

The ideal setup for me personally looks like this:

1. Central server running TW and acting as the source of truth and storage of all my tiddlers.

2. The tiddlers are versioned for easier maintenance and fewer worries around deleting or changing things.

3. The tiddlers are regularly backed up to protect against hardware failure and malware / accidental deletion. 

4. I can access TW from any device via a browser or other more appropriate means.

5. The local TW running on device is connected to the central server so that the tiddlers are shared between devices and not siloed.

6. The device-local TW can run offline, which means that there needs to be local storage that gets synced with the server once the device comes back online.

With these I could really use TW anywhere robustly and reliably.

I have a large part of it figured out, but there are still some system and UX level gaps. I will describe what my current setup and possible implementations can be for each of the points above:

1. Central server. I have the vanilla TW nodejs running in a Docker container on my Synology server and so far it seems great. The vanilla server saves tiddlers as files already, so I just mount that save dir as a volume, so tiddlers persist outside of Docker on the host.

2. Versioning. Based on a blog post I found, my tiddler files are part of a git repository. To commit I'm running a modified gitwatch that looks for changes to tiddler files and commits automatically after a few seconds. History in git is stored as deltas and compressed, so the history might take _less_ space than the working copy at the beginning at least. Reverting / looking at history is a little inconvenient as it's not integrated into TW, but that can be improved with a plugin and a server-side service.

3. Backup. Since tiddlers are saved as files on the server host and I'm running nightly backup on it, this comes by default. Any backup service that works on the filesystem level would work here however.

4. Device access. This already seems to work pretty well on desktop and mobile. The UI is pretty responsive and works well on small screens for most things.

5. Central tiddlers. This also works pretty well. The vanilla nodejs server has a REST API and the TW client that it serves connects to it and uses it as the default saver. So all the data is persisted on the server and not locally.

6. Offline mode. I don't have a solution that I really like for this yet. There are some attempts to do this, most notable seems NoteSelf. It syncs to a CouchDB database however and for now I prefer having tiddlers stored as files, due to the advantages that brings for points 1., 2. and 3.

Expanding on 6. Offline mode:

I believe this is the only context where PWAs make sense. If the app is already offline (served from the local file system, saving via browser plugin, or running offline as a native app), then the concept of a PWA doesn't make sense, since afaik the core problem they solve is offline mode.

In the context of an online TW (like described in the setup above), it would make sense for it to support PWA features (localStorage, offline service worker responsible for sync, etc.). This way you could open up a website hosting your TW at any point, even when you're offline and it would store all the changes in the browser cache, then sync them up when you connect back to the central server.

This would solve 6. without having to create a separate application for each OS just to handle the offline, caching and syncing problem. In Chrome you can even install these kinds of websites as system apps, so they open up in their own window and act like native apps to a certain degree, on both desktop and Android. For example, the Home Assistant client does this and it works great.

I believe a proper syncing / diffing system is the only big roadblock that currently stands in the way of having true offline mode and sync. I know there is some effort being put into the diffing part (there's a macro for diffing tiddlers), though I'm not sure how far TW currently goes wrt sync with the nodejs REST API.

Obviously expecting everyone to run the same setup as I am is unreasonable, especially if you just want to try it out or if you don't want to manage servers and so forth. If you use more than 1 device regularly though, I would think you'd want some form of syncing between them and that's why 6. would be beneficial, even if you connect to the cloud, where someone else runs a variation on 1., 2., 3. for you.

I'd be interested if anyone has a better solution for any of the parts of this system or a better one entirely.

Best,

Miha

To unsubscribe from this group and stop receiving emails from it, send an email to tiddl...@googlegroups.com.

[TiddlyTweeter]

Ciao Arlen

I think part of the issue is not the tools you and Jed developed. It may be the "wrapper", the "marketing" as well? 

So much here we are concerned with fundamentals. But the GG group goes nowhere other than the readers.

I think that "promotion" for TW matters & is seriously under-achieving. 

The result is that neither you nor Jed get volume feedback (as fr as I can see). 

At a certain point development & feedback interact importantly. 

Do you feel you have enough feedback?

I agree with your "money" points. IMO a solution COULD be charged for, especially on MOBILE, where it is established practice. 

It Is the issue of getting volume (mini charge at volume) v. donations (better gifts, low volume).

Best wishes

TT

To unsubscribe from this group and stop receiving emails from it, send an email to tiddl...@googlegroups.com.

[Jed Carty]

Arlen,

Please do not spread misinformation about the security of what I make. The saver server part of Bob does not listen on the local network, it only accepts requests from localhost. At least that minimum security is a requirement for everything I make, that is why I put so many warnings in Bob about allowing access on the local network and why I made the secure server component that has proper https and token-based authentication and access controls.

People repeatedly requested to be able to use Bob on the local network which is why it is possible, but the person using has to explicitly enable that and there are warnings about what that means. If someone modifies the saver to listen on the local network  that is not something I can change.

[Arlen Beiler]

I have not followed your work, unfortunately, but it sounds like you and I are on the same page then. I was only referring to a way I thought of yesterday to make it pretty much bulletproof using a browser plugin, but it sounds like I would have done it exactly as you did for a TiddlyWiki plug-in if I had made one. 

So yeah, great, glad you’re thinking about it, as anyone should. TiddlyServer has all those same scenarios to consider as well, so we’re pretty much in the same boat.

--

You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.

To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/48afcba5-6e47-4bee-992d-4ed1305244fc%40googlegroups.com.

[Arlen Beiler]

Just realized that’s worded badly. You definitely have your bases covered. 

[Stefan Pfister]

I'm very impressed by the bobsaver-plugin for single wiki files. It could be really simple for saving with single files. But it needs manual starting of a bobexefile. If this start of the bobserver could be automated as background demon or service at system startup this would be really simple for the non-technical casual tiddlywiki user. Just install a software as a permanent server in the background of your system which starts every time when your system boots and double click every single tiddlywiki-file for editing and secure saving without any hassle.

You only have to install some kind of software and forget it. After the installation of the single-file-Bobserver as a background service you can simply use every single tiddlywiki file without installing any plugins or another kind of tiddlysaver. You can use different kind of browsers. This could be a solid and simple solution for the desktop use of tiddlywiki single files. You need different versions of the single-file-Bobserver for windows, linux, mac.

This is the usual and normal way which a simple user can handle. Install some kind of software with a installation routine and after this use files like you know it.

[TonyM]

And again all thanks for the continuing input, carefully considered feedback is very valuable and your efforts are recognised.

It seems to me we are getting close to a first use "ease of use" then making tiddlywiki your own, basically save back to a tiddlywiki on your own drive.

I hope we can finalise this.

I see some wandering into the broader savings issues such as cross device, consolidated servers which is ok but in some ways it is the next step. Using the Bob file saver plugin with bob.exe for example is already introducing server services However the key initial reason for bob.exe in my view is the possibility of a simple adoption process.

From my original topic, I am really keen to refine the first engagement steps because I believe this can and must be simplified to not just support new users but support designers publishing work to general audiences (starting with read only html publishing).

It is my view while we should keep in mind more sophisticated implementations like server, cross device, multi access and multi user etc. . the next critical step in my view is controlled editing. The first being serial editing especially starting with single file wikis but later extending this to authorised editing.

Serial editing
Single file wikis typically save the whole wiki into a single file so two similtaniouse edits users or tabs, will overwrite one set of changes with the other.

To enable serial editing to stop this potential loss we need to introduce a login/out mechanisium in single file wikis or check-in or checkout. This is to handle the case where more than one user has update/save rights.

I have researched this deeply. And will not detail it here but the trick is to reload a wiki with a checkout request in uri or temp storage and save the wiki with the checkout details only if sucessful, perhaps with another reload to confirm the checkout. This may be prohibitive on large wikis so a wrapper wiki to control edit of another wiki may be needed.

This type of mechanisium will also support the use of multi device via cloud shares, overwrite protection on tiddlyserver, node, tiddlydesktop and more. Bob already has some protection.

Check in and out in single files would open the smart document possibilities by permitting edit control and multi user (serial) to take place in documents that are sent around physically or functionaly to multiple users. A concept I like is the idea of documents with a document management system built in.

Your thoughts please

Is serial edits the next step as I believe?
Are there other ways to achieve this?

yours sincerely
Tony

[ILYA]

Just wanted to say that I agree with Lunar, about the vision.

My current setup:
1. Bob based server (I use Caddy in front to provide https) on android phone using termux
2. Script to watch creation of new directories and create new git repository per wiki
3. Script which watches every directory and commit files on each change.
4. Script which creates nightly backup to my NAS server
5. I added phone.local entry into /etc/hosts on my linux PC and MAC.
6. I have save as file button in every wiki so I can export any wiki as single html file to share with friends. It is not ideal since it is not easy to get their changes.

This setup has a number of problems:
- I cannot access my wiki on the phone from PC if I am connected to guest wifi
- There is currently no way to see different versions of the tiddler or its history from TW itself
- Hard to setup
- Bob stops saving when I migrate from one network to another (IP address change) which means I loose my work quite often
- sharing with friends is not easy

In my opinion the requirements are:
- a single file executable which does either
- opens default browser connected to local server on random available port
- uses one of the desktop app frameworks
- electron
- flutter
- https or local unix socket for transport
- ability to use remote server
- store changes in browser local storage when server is not awailable
- rely on p2p network to discover the IP address of remote server
- support multiple clients with conflict resolution
- tw based UI to show diff between local and remote version of a tiddler (something like https://codepen.io/Sphinxxxx/pen/grVvjG)
- compare different historical versions of any tiddler
- ability to look at consistent snapshot of the wiki at a given time ( git supports it already )
- display all versions of a tiddler
- automatic sync of changes between browser local storage and server or multiple servers
- visual indication when server is not connected

Here is my vision on how to build it on the current art.

1. Replace title with tiddler_id in TW code (to support tiddler versioning)
2. Generate unique values for tiddler_id
3. Use caption instead of title
4. Implement new saver using one of
- PouchDB (can be taken from NoteSelf)
- This approach would require a custom server which implements CouchDB replication protocol but stores data in git
- dat protocol
- kern/filepizza
- jvilk/BrowserFS
5. Write storage backend using language which can produce statically linked binaries or embed nodejs
- rust
- golang
6. Update TW to access historical versions of tiddlers
- <tiddler_id> - current version of tiddler
- <tiddler_id>/<version_id> - to point to old version of tiddler

Best regards,
iilyak

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

[TonyM]

Illyak

As in my last post I feel we need to approach this a little more gradually. I thing serial editing could help you.

In relation to your current problems

- I cannot access my wiki on the phone from PC if I am connected to guest wifi

This is the design of guest networks. Device isolation. Either connect but not as guest or consider direct Wi-Fi

- There is currently no way to see different versions of the tiddler or its history from TW itself

There are versioning solutions available. Search around noteself is a good example but there are others. It you design the save actions you can do it yourself.

- Hard to setup
I think you have chosen a more complex approach

- Bob stops saving when I migrate from one network to another (IP address change) which means I loose my work quite often

I suggest move the wikis not the server or have a separate server setup that accesses the same folders

- sharing with friends is not easy

Sharing is really dependant on a multitude of factors including if it includes the need for input. There are a number of ways to address this but I do think single file wikis enabled for serial editing or smart documents is a good start. Such wikis can originate from server implementations.

Thanks for sharing you methods and views.
Tony

[Arlen Beiler]

My setup is basically:

1. TiddlyServer is basically an expansion of the NodeJS TiddlyWiki Server. It's designed like a static file server such as apache, but adds features for TiddlyWiki, such as saving single-files, and loading data folders in place, so you can have multiple data folders running on the same server instance with different paths. Back then the TiddlyWiki server didn't have any way to upload external files from the browser. If it had, I probably would never have written TiddlyServer, but I use it all the time now. 

2. My main wikis are stored in Dropbox so I just reference their folder inside the Dropbox folder, and Dropbox automatically saves changes immediately. I've heard there is some kind of versioning as well in the Pro version, which I have. 

3. Dropbox takes care of this for folder wikis, and TiddlyServer can also be configured to save a backup of all single-file wikis on every save. 

4. Browsers are browsers, some are just more sandboxed than others, which is part of the reason I made TiddlyServer -- so I didn't have to make sure all devices could use file:// urls, which was always a pain. 

5. Everything is central. 

6. I used NoteSelf for this for a while, but eventually I dropped that and just used Dropbox. 

I really like the TiddlyWiki concept and it's a lot easier than installing MediaWiki on my computer, which is what I had done before. I'm still working out a few problems with mobile access and the like and also trying to come up with a more usable layout for regular notes. Something like Google Keep, maybe. So that's my setup. 

To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/60b58373-13e8-427a-b7c8-c50f5597b496%40googlegroups.com.

[TonyM]

Arlen

Thanks for sharing your use of tiddlyserver which I also use a lot. All my tiddlywiki file locations are in my ts index. I have a wiki I open for generating wikis using the the big green button to save into a folder that I then browse with ts.

This keeps maintaining an index to wikis very easy. I also use it along side timimi and sometimes bob and tiddlydesktop.

It would be nice to preconfigure tiddlyserver to a standard setup and zip it into a executable zip file to ease its deployment. Is there a minimal configuration we can use? It would also be nice if we could add paths ports and addresses to the setup file via a tiddlywiki, reducing the errors. Generating the settings file rather than a copy of a text file.

Love your work
Tony

[PMario]

On Sunday, November 24, 2019 at 12:27:50 AM UTC+1, TonyM wrote:

And again all thanks for the continuing input, carefully considered feedback is very valuable and your efforts are recognised.

It seems to me we are getting close to a first use "ease of use" then making tiddlywiki your own, basically save back to a tiddlywiki on your own drive.

....

Hi Tony,

I think with this post, you open a completely new topic about multi-user setups.

So may be this should be a new thread.

Just my 2 cents.

-m

[Miha Lunar]

Hi y'all,

Thanks for these really good ideas and insights, here's a wall of text dumping some of my thoughts :)

TonyM,

I agree that the most important first use case is having a simple one-file one-user one-device way of saving. There are many solutions to this already, though it seems like most still require _some_ configuration. I think as a first time user (not aware of quines, browser extensions or servers) I would first just look for a desktop version, which could be an electron app that would mostly just wrap the nodejs server and present a client that connects to it. Alternatively it could also just wrap the html quine and handle saving of the html file.

If I understand your original use-case of a team of people sharing multiple documents amongst each other, it's more of a multi-file multi-user setup. I think having a central nodejs server there is probably the simplest solution if there is one person that can manage it.

I'm not sure how you could have a check-in/check-out workflow in the context of passing wiki document files around i.e. how does my pc know that you opened a document and checked it out on your pc? You'd need a central server or some other way to transfer this state. In which case you could just use the nodejs server to host the wiki in the first place. If you don't have this check-out state synchronized, you end up having multiple people edit the same wiki/fle, having to merge them after the fact.

In the context of having check-in/check-out as part of a central server, it's probably the easiest way to solve the multi-user editing scenario. For me personally that would bring a lot of friction and manual synchronization within the team (who checks out/in what and when?). This is also similar to non-distributed version control systems like Perforce, where this is often used for files that are hard to merge (media assets, etc.), so it's a necessary evil, so to say.

Anyway, the crux of the matter for multi-user wikis is really synchronization and merging between several sources which change over time. This is clearly a complex problem, but I believe it has been essentially solved by Operational Transforms (Wikipedia, OT Explained). This is essentially how Google Docs and similar have been doing collaborative editing with no check-in/check-out and no manual merging. This doesn't necessarily make it simple to implement, but I believe it's the way to go for server-hosted TW on nodejs.


Ilya,

That's an interesting setup. So essentially it's a phone-first wiki with everything hosted on the phone and then you just access it from your PC when you need to. Sounds like an extreme way to solve the offline problem, but it's probably the best way right now :)

As a first step, saving changes to localStorage would be a good idea in combination with a server. This is independent of having a desktop app, since it would benefit both. Service discovery is probably only relevant from the point of view of an app, something like DNS-SD could be used.

The end goal for conflict resolution is probably Operational Transforms as described above. In the mean time a 3-way diff view (base, mine, yours) with an edit box where you merge the result manually might be the easiest to add. Recent TW versions already have diff-text functionality, so it's mostly a matter of plumbing.

Compare different historical versions & snapshot of the wiki: I've experimented with implementing the former with a plugin and service to access git file history and present it in the UI directly and I think it's a good way to go. The snapshot is also easy to achieve by checking out a different git commit as you said already (presenting this in the TW UI might be a bit tricky, as the whole state of the wiki would change under you). I agree that some sort of a sync and sync status indicator is needed.

For the implementation, I would try to reduce the complexity and number of moving parts as much as possible. So I wouldn't change any core TW mechanics in the first versions as they aren't really required, because git already tracks changes in files and renames as well. Having an actual ID for a tiddler might be a good idea at some point though. I don't see the added value in having a separate saver for this as the file-based saver and the REST API that's already there is good enough for maintaining the current state.

For historical versions, I've experimented with having a Go service that just serves git file history and the proof of concept seemed to work well, now that I think about it, an even better way to go would be to just have it as a server-side plugin for the nodejs version of TW.

Arlen,

I've actually tried TiddlyServer first and it seemed neat for serving multiple wikis. I stuck with vanilla though, as you mentioned if you don't have a use for multiple wikis, most of the functionality is in the TW core now. 

I think having the wikis in a Dropbox folder is definitely one of the best ways to have a backed up versioned wiki. I think integrating git would be a good way to expand on that functionality and for better integration. Clearly a lot more effort required on that front though.

I like that since Dropbox is also available on mobile, you could probably hack together a solution that used that sync too. But it would be more of a hack than anything I guess.

Sorry if I exceeded someone's bandwidth cap with the brain dump above, but I didn't have time to make it shorter ;)

Best,

Miha

[TonyM]

Miha,

Thanks for your feedback and reference which I will review in further detail.

First however I want to clarify the check in and out facility I propose is effectively a file lock mechanisium to ensure a single editor at a time on a single file wiki.

Such a mechanisium can be used on a server delivered document or on one that is passed around and edited on a simple fileshare. Such check in and out is even useful beyond its technical values its all so about ownership, work flow and more. The act of emailing a document is creating or forking a new document but if all you are seeking is a document review. Then there are ways to merge changes back to the source, but you need to always ensure one editors changes do not overwrite another's.

I will start a new thread on multi access and multi user saving, please use that for the discussion of those ideas.

Thanks for your contribution
Tony

[TonyM]

All, 

Please See The penultimate words on saving - multi access and multi user for server based solutions.

TiddlyWiki Single file solutions using cloud drives etc.. also belong in this thread.

Regards

Tony

On Monday, November 18, 2019 at 2:03:52 PM UTC+11, TonyM wrote:

Folks,

This post is seeking input from the community to overcome what I perceive to be the last big issue in saving. It may seem only suited to experienced users but perhaps you know something we don't, so please be brave and contribute.

I may have an opportunity in coming months to work with a team of videographers in their off season. They do "things for good" and my thought was to build a nice application (on tiddlywiki) for people to explore how they or their business can participate in reaching the Sustainable Development Goals (SDG's). This will promote the SDG's, their work, my work and the power of TiddlyWiki, but there seems to me, to still be an elephant in the room - saving.

How do we enable saving tiddlywikis for naive and casual users?

To be sure, I am across most saving mechanisms, and some are very good and quite easy to set up a very sophisticated solution, I use Timimi, TiddlyServer, TiddlyDesktop and Bob.exe 

Imagine someone visits my SDG app online

• They could use it and apply changes but not save it
• With local storage and save some changes in the browser but they may be lost later
• They Can download it easily enough, even with their in browser or local storage content
• But if they wish to open it again, make changes and save they then need to consider this https://tiddlywiki.com/#GettingStarted - scary for many.

Basically I think tiddlywiki is brilliant and we have lots of wonderful options for saving, once someone gets involved with the ecosystem, I believe any nodeJS solution is hard to secure on the internet and like NoteSelf we have to manage the server, but it seems we are so close to a better single file solution (My Opinion).

 

I know some saving mechanisms come close to helping naive and casual users however their remains a need to take unfamiliar steps, that can be quite fragile, especially to those not overly computer literate. Saving under downloads folders, running batches and installing local apps are all impediments to naive and casual users in my view, as this becomes Operating system dependant, demands more trust, will not work in many locked down cases and more.

I am starting this thread to try and inspire some serious creativity to overcome this barrier. Here are some ideas floating in my head but I am keen to hear from you.

• Any idea is a good idea
• A diversity of ideas in needed
• We may need to "think outside the box"
• Can an existing solution be better engineered to meet these goals?

Some of my own musings

• One approach may be to never download the whole wiki, but store the changes in a separate file that is automatically loaded over the in browser one, and saved only by saving changes back to the nominated file.
• Building all the necessary content to install Timimi or another saver from the single wiki (No other document or external info required) Not yet chrome and IE
• A Form of bob.exe/TiddlyDesktop that can be loaded with a custom tiddlywiki that shows only that wiki unless some settings are changed in the control panel. Ie a single local installable.
• A Way of packaging a TiddlyWiki with Node.exe and hosting on a port that will not clash with other server hosts, perhaps an packaged extension of TiddlySaver.
• I was inspired to open this up to the community after playing with bookmarklets and Jeremy's solution because javascript can be loaded into bookmarks I wonder if it could be used to save changes to local tiddlywiki files and reimport on click. 
• I also looked at solutions such as https://en.wikipedia.org/wiki/IMacros which suggests there may be other ways to achieve the desired results.
  
• IPFS, BeakerBrowser, CouchDB or saving to a MYSQL or even a wordpress database?

All I want for Christmas is a simple way for naive and casual users to save their tiddlywiki (again and again)

Yours Sincerely

Tony

[Chuck R.]

Ok I'll just throw this out.

Beaker Browser is a P2P browser where you can edit your own websites using Markdown. It relies on the DAT protocol, but you also have to have your BB (Beaker Browser) running if you want people to see your HTML pages. https://beakerbrowser.com

Pros:

1. Markdown is easy to use even for beginners. The learning curve is short.
2. Hashbase.io can be used to host sites so you don't have to have BB running all the time.

Notes:

1. Unknown support for multiple users editing documents. I doubt there is support for that at all. It's still in beta.

[TiddlyTweeter]

Ciao Chuck

The issue with BB is mostly HOW to get it to publish public IF you need that. Otherwise its excellent if you happy just working in the protocol with others using it.

BTW, TW can work in it well. Its "BB-ready". Mr Ruston, originator of TiddlyWiki, did quite a lot of work to ensure that.

Best wishes

TT 

[TonyM]

Chuck,

Thanks for reiterating the potential value of beaker browser. Such new approaches to interacting on the internet stand to offer great value. Of course my original post on this thread asks How do we enable saving tiddlywikis for naive and casual users? perhaps needing a special browser and introducing new concepts may be a "bridge too far" for such users.

I am myself an IT professional with decades of experience and I still struggle to grasp the best ways and future values we may be able to gain from the use of the beaker browser in general and specifically for tiddlywiki. So far I can only see its value as a way of publishing read only or forkable tiddlywiki, but I suspect I need to spend more time on this. 

Perhaps a new thread on making use of the beaker browser would be a good move, I would love to learn about workflows, futures and speculation of where we can take these two technologies (TW&BB).

I expect in time The beaker browser and P2P models will become better understood by a general audience smoothing peoples transition to it , however I think as TiddlyWiki enthusiasts it would be good if we could explore its advantages and tricks and tips with "making use of it" so we can help tiddlywiki users know when to take that path. That's why I suggest a new thread. Would you consider stating one please, and sharing what you know in more detail?

Thanks

tony

[TonyM]

Original Post updated with 

Alternative thread Title: "TiddlyWiki Encounters of the First Kind"

Tony

[Mark S.]

You have to install a browser. Create a site. Load a tiddlywiki into the site. Then set up the site to synchronize with a given place on your hard drive (assuming you want your data to be backed up). Then repeat for each tiddlywiki you want to access.

That doesn't sound beginner friendly. Or even regular friendly.

I feel like Beaker is a solution looking for a problem ...

[TonyM]

Mark,

I agree for most new users what you say is true, In part this is why I suggested this should move to another thread, however once setup, from memory there is a way to fork an existing Site very easily. Perhaps one day this will be the future?

Regards

Tony

[Thomas Elmiger]

Hi all,

I think there is one solution missing here: Glitch.

(I read most of the posts but not all.)

Personally I went with this solution by Jonas some time ago: https://glitch.com/~tiddlywiki-stuff

Pros

• pure online solution, no local installation at all (use any browser you already have)
  
• accessible from anywhere with any device (as long as you are online)
• pre-configured solutions can be made available and ready to copy (remix in Glitch terminology)
  
• relatively fast to set up compared to other server/online solutions
  

Cons

• not beginner friendly if you e.g. want to restrict editing
• not too fast (server goes to sleep and needs time to wake up)
• there might be others ...

I will have to experiment more and as stated above, I am just a user (remixer) not the author.

Just wanted to let you know.

All the best,

Thomas

[Mark S.]

Does it work offline?

Is it private? Secure?

Thanks!

[TonyM]

Mark,

At Glich.com https://glitch.com/~tiddlywiki-stuff it reads

Go to the .env file if you wanna control who can has read/write access to the TiddlyWiki. Maybe change the SERVEROPTS-line to something along the lines of:

SERVEROPTS="readers=(anon) writers=joe username=joe password=bloggs"

But like with different username and password probably. See https://tiddlywiki.com/static/WebServer.html for details and more options.

[TonyM]

Folks and Jed,

I will soon publish a Demo "First Encounter" Wiki and would love your feedback.

The details are as follows;

• Single File HTML file hosted on a readonly (To visitors) internet facing server.
• Browser Local storage activated, 
• Default save hidden.
• A Save Changes button that will save only recent changes and local storage items to a file
• Bob Filesaver installed and active (but will not do anything if no bobserver running).
• Advice on installing BobEXE from Jed's releases page
• Observation Windows says Unknown Publisher when installing Bob, I wonder how to stop this?
• For windows 10 I have described at least one way to load BobEXE at User login to windows.
• Once installed the internet facing wiki can be saved with the default saver to any location if the browser permits. Or  (Download and Move).
• I then want to leave a reminder that they saved a copy to file in the online local storage, and possibly the ability to save a link to the local copy.
• Double clicking the file will open in the default browser and saves will now be permitted.

Jed,

As you know BobEXE loads at 127.0.0.0:8080 with its default wiki, and my Downloaded single file wiki at file://C:/path/tiddlywiki.html on Bob saver server running on 127.0.0.1:61192

When Using the Bob saver plugin

• For someone intentionally installing bob for all its features it is good that the default wiki loads
• In this case of the Bob saver plugin it would be nice if it did not load, but the downloaded wiki could instead provide the link to the default wiki.
• I am concerned for new users they will get confused thinking the default bob wiki is the one they downloaded, as its the only one that opens by default.
• I can't however see a way around this unless there was a different bobEXE or a command line parameter

What do you think Jed?

Thanks all 

Tony

[Jed Carty]

Tony,

The purpose of Bob is that you download BobEXE and run it and it works without any configuration. Adding required configuration is not something I am going to do. I am also not going to create multiple versions that behave differently and add that confusion on top of everything else.

Having someone use Bob and not explaining that it is running a server on their computer with all of the associated warnings about what that means when Bob opens the first time is exactly the opposite of what I want to do.

While proper informed consent isn't always possible or practical because many/most people don't have the background to understand what any of it means or don't care about the risks that has to be something that they decide. They are taking a risk of some sort, if they want to move forward with that even if they don't understand the details that is their decision, but having Bob start up without explicitly informing them that there can be some element of risk is not something I am willing to do.

As it is I need to add more explanation of the saver server to the default Bob edition.

The single file saver part of Bob is very simple, if you want it wouldn't be difficult or take much time to re-implement it I c++ with QT5 or something similar to make properly compiled native binaries for different systems and give it a taskbar icon and all that fancy stuff. I am working on adding a wrapper on BobEXE to make it a proper app bundle in OS X and looking at different options for it in Linux. In my experience windows doesn't play well with others so something for windows may have to come from someone else.

[TonyM]

Jed,

I did ask "what you think" so thanks for replying, I had no intention of making any work for you. I hoped I was providing you with an observation that this may act as a barrier to providing a simple tiddlywiki adoption path. You are right its beautiful that BobEXE installs with no configuration. I am actually trying to reduce confusion for the new user as well.

Please let me try and explain what I see as the user experience more precisely. 

For a user installing BobEXE to make the the New Bob File Saver plugin work (Which is a brilliant piece of work on its own port etc...) the naive users will get the bob master wiki open up, before they try and download the online wiki (COntaining the Bob Filesaver plugin) that promoted the install of BobEXE. I fear many may go off on a tangent and not download/open the file of there downloaded wiki. This is likely to occur on every Operating system.

I would in no way expect you to compromise your standards and the informed consent etc.. Perhaps this informed consent could even be added to the Bob Filesaver plugin?. 

My Intention was to then provide (in the downloaded file based wiki) the steps for the user to open Bob Master and why and how to use it. Kind of an easter egg, when they suddenly discover the value of Bob in their use of Tiddlywiki. I thought this may turbo charge the adoption of Bob. Once installing BobEXE to enable the Bob File Saver Plugin they could just work on their saved site, but here we can point to if they want to make it available on the local network, multi-user etc... how to migrate the single file wiki into Bob.

I simply raise these for you to consider, if there were a way to do this while meeting your architecture and design principals. Perhaps you can solve this perceived issue another way?

In the meantime I will see how we can get help from a windows developer/install script writer. 

Regards

Tony

[Ste Wilson]

Speaking of saving i just found this possibly forgotten gem from the amazing tidgraph person

https://ihm4u.github.io/twexe/

[TiddlyTweeter]

Ste Wilson wrote:

Speaking of saving i just found this possibly forgotten gem from the amazing tidgraph person

https://ihm4u.github.io/twexe/

An understatement professor. Whoa! Holy-Moly Batman! KAPOW!

Most interesting! I'm seeing if it still works.

TT 

[Stefan Pfister]

On linux mint Sarah: First start was okay. The second produces an error:

 _______        _________  _______  

|_   _\ \      / / ____\ \/ / ____| 

  | |  \ \ /\ / /|  _|  \  /|  _|   

  | |   \ V  V / | |___ /  \| |___  

  |_|    \_/\_/  |_____/_/\_\_____| 

  Single File TiddlyWiki executable 

  Version: 0.5.34

------------------------------------

                                    

 [ Sat. 14:43:10 ] - Creating shadow: /tmp/e78b42e942b6f16c8020e6fb2151a2a6_

                     twexe.twx/_exe/_twexe -z "/path/tiddlywiki-twe

                     xe/twexe"

 [ Sat. 14:43:10 ] - Zip header found at: 1185360

 [ Sat. 14:43:10 ] - Copying '/path/tiddlywiki-twexe/twexe' to '/tm

                     p/e78b42e942b6f16c8020e6fb2151a2a6_twexe.twx/_exe/_twex

                     e'

ERROR: Unable to create '/tmp/e78b42e942b6f16c8020e6fb2151a2a6_twexe.twx/_ex

       e/_twexe': Exception: Unable to copy '/path/tiddlywiki-twexe

       /twexe'  to '/tmp/e78b42e942b6f16c8020e6fb2151a2a6_twexe.twx/_exe/_tw

       exe' : EAccessViolation: Access violation

ERROR: Unable to start shadow: Unable to copy '/path/tiddlywiki-twe

       xe/twexe'  to '/tmp/e78b42e942b6f16c8020e6fb2151a2a6_twexe.twx/_exe/_

       twexe' : EAccessViolation: Access violation

 [ Sat. 14:43:10 ] - Stopping server at 'http://127.0.0.1:8080'

 [ Sat. 14:43:10 ] - Restarting '/path/tiddlywiki-twexe/twexe' ' -s

A simple and working solution for the casual user can be:

On the other side. The bobsaver plugin is very simple. You could provide a emtpy TiddlyWiki-File with the bobsaver-plugin installed and a installation routine for bob.exe as a program which is loaded invisible at system start. It starts the bobserver, which is listening on 127.0.0.1:8080 or 8081. There is no danger in it. It runs only on your local pc. Even the other clients in your local network can't access your server. You can open, edit and save your html-files with tiddlywikis in it. I'm running it at the moment on my surface go and on my linux pc. Even with the same html-files on my nextcloud space. It works platform independent. It works with many singlefile wikis. You don't have the additionell terminal window, if you don't want it. The bobexe works discret at the background and is not in the way of your daily working environment. It is common behaviour to install a program with an installation routine. You need to install one local program. And can simply use the html-files with tiddlywikis in it. This could be a dream of a simple user experience. If there a persons who want to write a simple install program for different platforms. Command-line parameters for the bobexe would simplify this task.

Twexe looks very cool. But you have to start a separat server instance through an exefile for every wiki you want to work with. One installed bobserver can serve multiple single-file wikis at the same time. But twexe ist really cool for portabel use. But you are fixed on a software platform. You can't use the same file on linux and go with this file to a windows pc and start your wiki.

In comparison with the bob tiddlywikisingleexe it does nearly the same. At the point of the user experience you start an exe and a wikifile is opening in your browser.

Just my two cents.

Regards,

Stefan

[TonyM]

Ste/ Stephan

• I have just tested twexe and it works well, using the latest tw 5.1.21 on Windows 10, it opens in my default browser (fireFox) at http://127.0.0.1:8081/
• The fact you can pack any single file based wiki is impressive, and on save it is repackaged into the exe itself is a brilliant piece of work. 
• I understand the same method works on Linux it would be interesting to test it on OSX
• Whilst it would not take long to teach a new user to package such wikis, it is certainly a nice way to prepare, package and distribute a completed tiddlywiki that user can use as a local app (Whilst still leveraging the browser). 
• The same source tiddlywiki.html could be published on line with an opportunity to download the exe for each platform. But of course online changes will not carry over to the local exe, and changes can be made once running.

Questions,

• Would a similar solution with its own browser like tiddlydesktop uses chromium be even better I wonder?

Searching for the source https://github.com/ihm4u/twexe and notes

I stumbled on this

https://github.com/welford/twexe

Tiddlywiki widget to run batch/exes on a local machine. Intended for an hta flavoured TW, not suitable for anything online.
Which I have not yet tested, it may work within tiddlydesktop and as suggested should work in HTA files, next test aspx files on SharePoint

Regards

Tony

[TonyM]

Post script,

It should perhaps be rebuilt again with tiddlywiki 5.1.21 rather than 5.9

My attempts to attach an empty.exe tiddlywiki v 5.1.21 for Windows in a zip file, has failed hence the deleted messages in this thread (bug related)

note it is now less than 1MB, you will have to make your own

I tested my 11MB+ Tiddlywiki, it took some time to load but it was reduced to 4Mb

Regards

Tony

[Mark S.]

Oh yeah. You can't attach anything executable, even if it's in a zip file. You can put it on google drive and share it, though.

Edit1: The twixie takes a long time to boot the first time -- I thought it had failed. And that was with a fairly small file. I think it was the first-time compile.

Edit2: I had to open an admin box in order to generate the twixie. There were insufficient rights otherwise.

Edit3: Once I had generated the exe, it could be run as a standard exe.

Edit4: It needs a terminal box open, just like other node.js products

Edit5: If you close it, you will need to kill it in the process manager in order to start again (just like with TiddlyDesktop).

Edit6: There is an undocumented option -t that will let you set a port, in case you want to run more than one tiddlywiki file.

[Mark S.]

Repeating for mail users who wouldn't see the edits.