There is a fundamental tension between the design goals of TiddlyWiki and the nature of the Web.
A simple answer to the quote above, is “Well, just use Tiddlyhost.” And Tiddlyhost is wonderful, no doubt about it, even with the occasional instability lately. But the first two bullets on the first tiddler most new users see are these:
- TiddlyWiki stores its data and code in a single HTML file, requiring no installs, no external dependencies, just a web browser
- TiddlyWiki lets you choose where to keep your data, guaranteeing that in the decades to come you will still be able to use the notes you take today
(If you haven’t looked lately that first bullet is relatively new.)
“Wait, you say that, and then want me to store my data in some centralized service run by a single guy I’ve never met?”
Well, perhaps. That is probably the single easiest way for a brand-new user to try things out and maybe fall in love with the most feature rich tool of its kind. But this is definitely in conflict with the statements above. Partly it’s the centralized/decentralized tension, but it’s also the notion of needing to save a backup.
But all the savers out there are part of a larger conflict. Since JavaScript was introduced, there has been a pendulum over how to serve content over the web: depending more on the server or more on the client. It feels to me as if the last three or four years has seen a push back to the server, after a long stretch of single-page apps on the client. Swinging along with this pendulum is the question of just how much browsers should be allowed to do. TiddlyWiki’s notion of saving the current wiki on the user’s machine is often in tension with the Web’s Security constraints.
Most of the other tools out there don’t try this, serving content instead from server-side databases. They won’t have a Firefapocalypse (sp?) when a browser changes the rules that had allowed their saving mechanism. When Chrome decides that they need to update a specification in order to restrict the ad-blockers cutting into their profit, these other tools are less likely to break.
But the security concerns that often stymie TiddlyWiki are not imaginary. Allowing the user to easily save web content is an invitation to malware. So Tiddlywiki’s saving mechanisms have had to adapt over the years, as the Web community decides that certain mechanisms are unsafe. This latest one sounds more like Chrome trying to restrict ad-blockers, but it’s likely of similar effect.
The good thing, as @Quine mentioned, and as discussed in a Timini issue, is that this can easily be patched. But it would be great if someone who understands the code would be willing to take over as maintainer, if Riz is no longer interested. @YakovL, might that be you?
I’m having no such issue. With Airbnb as well, I’m guessing this is something local to you.
) and the community has no fix for it, he has a legitimate gripe. Of course, in an unpaid, open-source community, a fix has to interest someone who can perform it. If we don’t come up with something, it would be very sad to see Dave leave us.