Alternative for saving TW

[Bauwe Bijl]

Hello People

The latest TiddlyWiki saving issues and increased browser security
changes are worrying and could interfere with your workflow.
Instead of debugging saving issues and doing experiments some of us
might prefer to continue working with TW. (or at least have an extra
saving alternative)

"TWS" (from Poul Staugaard) might be a good solution and to make sure
we don't forget, here my post on what it is, how it works and how I
use it.

TWS : ( https://github.com/PoulStaugaard/TWS )
From the readme:
"
TWS is a very basic TiddlyWiki server written for Node.js
It serves as an alternative to using TiddlyWiki's built-in methods for
saving your content.
"

I've been using TWS for quite some time now since it allows me to edit
TW with chrome on linux.
Of course any server like TiddlyWeb or Tiddlyspace could do the same
but to install these local seems like overkill...for only saving
tiddlers...
TWS is "just enough server" to help you going and installation is,
compared to the big ones, pretty simple.

Installation:
Install node.js (if you don't already have)
...installation of node is a single click installation in most cases
(win mac linux)...
http://nodejs.org/

Download TWS:
https://github.com/PoulStaugaard/TWS/zipball/master
and unzip (change that folder name to what you like ... like "TWS")
Place this folder somewhere on your system (I have it in my /home
folder)

Start:
browse to your TWS folder...and start the server with the command:
node tws

This will start a process that launches the server on http://localhost:1337/
.... and starts Google Chrome automatically (in browser.js you can
change chrome start with other browsers) but also http://localhost:1337/
can be opened manually in browsers.

Once started you'll find an empty.html TW in the list which you can
start editing (user name and backup folder needs to be set...just as
"normal"...in your tw :)
Other TiddlyWiki's can be copied to the TWS folder and replace the
existing TW.

That's it.

----
Some thoughts:
----
Benefit:
- once familiarized with node.js you might start checking how node is
used for building TW or TW5 (and all the other great things you can do
with it :)
- using chrome on linux is possible

Discussions:
You might have concerns about using a "helper" system to save
tiddlers...
....wasn't that saving.jar and java also a helper?

Missing:
backstage functionality like import
----

Have fun!

Bauwe

[Poul]

This is exactly why I wrote TWS (besides getting a feel for node.js). It actually already has a mention on TW.com, but in the context of hosted options, which is not really it's raison d'etre.

The way it works does of course break with the accepted paradigm of how you work with documents on your own computer, but other than a full branch of Chromium or Firefox to get around their security concerns, I see no better way.

/Poul

[Mark S.]

Two and half years ago I asked what the future for TW was, given that browser manufacturer's were trying to shut down the back-doors that allow TW to save to the local hard drive:

  https://groups.google.com/d/topic/tiddlywiki/5AS-lPmTCbw/discussion

No one provided a realistic solution other than to suggest a web server.   The web servers suggested were large. After that I kind of lost interest in TW.

Something like your solution seems like a candidate. But it means that TW is no longer a run-anywhere solution.

What are the security issues with running the node.js server? Can people from the outside access it and possibly write to your computer?

Thanks,
Mark

[cdent]

On Oct 16, 1:49 am, "Mark S." <throa...@yahoo.com> wrote:
> No one provided a realistic solution other than to suggest a web server.
> The web servers suggested were large. After that I kind of lost interest in
> TW.

This seems an opportune moment to remind folk that using TiddlyWeb +
TiddlyWiki doesn't have to be either hard or large, it's just gained
that reputation somehow. This response isn't a reaction to TWS: that
sounds awesome and very convenient.

TiddlyWeb has been built in a way to allow people to build tools that
could make it extremely easy to use. That is rather than being
initially easy to use it is designed so that interested parties can
make versions of it that are extremely easy to use in different use
cases. Unfortunately there haven't been many of these other versions.
This could mean several different things:

* My assertion about the tools that TiddlyWeb provides is not true.
* There aren't any interested parties.
* There are interested parties and there a people who can do the
building, and these people are disjunct.

Each of these statements have persisted in the TiddlyWiki universe
since early on. The noun "TiddlyWeb" can be replaced with a variety of
names for plugins, verticals, server-sides. I'm not sure what this
means or why it is. Any ideas?

In any case, on a computer that has a healthy Python installation
(many Linux machines and many Macs) the following small number of
steps creates an operational tiddlywebwiki installation on which you
can run as many tiddlywikis as you like:

virtualenv --no-site-packages tweb
cd tweb
source bin/activate
pip install -U tiddlywebwiki
twinstance tweb
cd tweb
twanager server
open http://0.0.0.0:8080/recipes/default/tiddlers.wiki[1]

I recognize that for many people that is complete gibberish and having
a "healthy Python installation" is a non-starter, so my point is not
that people should have to do that, but rather that _someone_ could
make a thing that encapsulates the complexity for a particular
environment (such as Windows) and by so doing make a very positive
contribution to getting tiddlers into people's hands.

If TiddlyWiki is a useful to you (the general you) because of its
standalone-and-save-itself nature, then tools like TiddlyWeb,
ccTiddly, giewiki probably don't matter; but, if what you care about
is tiddlers then each of those tools (especially TiddlyWeb if I may be
so bold) provide huge scope[3] for doing interesting things. Each of
those projects is open source, meaning they rely on community to make
them their best, yet (as far as I can discern) each has only ever had
a very small number of contributions from outside their core
developer.

Why is that?[2]

[1] It can actually be shorter than that. That list is for running the
service in a virtualenv, wherein you don't need to root access to
install packages, and the packages don't clobber other installations.
If you are root you can:

sudo pip install -U tiddlywebwiki
twinstance tweb
cd tweb
twanager server
open http://0.0.0.0:8080/recipes/default/tiddlers.wiki[1]

[2] The TiddlyWiki community has always had a unique approach to Open
Source. Community members build around the core product, not in or on
it. This has resulted in a very diverse and exciting plugin ecosystem
but not much in the way of collaboration on shared goals. And things
look quite alien to people who are used to open source collaboration
in its common forms.

[3] Of course that scope comes with the cost of initial complexity but
like with most computer oriented things complexity can be ameliorated
with work: abstraction and encapsulation to the rescue. What can be
done to get more people involved in that work?

[Poul]

I don't think there are any security problems to worry about in using node.js for a server as long as it listens only on 127.0.0.1 (the loopback interface), as it is not exposed to outside connection.

But as the browsers are becoming increasingly unhappy with java applets, I do believe it is just as much run-anywhere as a solution that relies on the java applet: Windows, Mac, Linux. And certainly more secure.

Node.js on Android or iOS, anyone ?

/Poul

[Poul]

I certainly sympathize with Chris's disappointment in the ability of server-based TW solutions to gain developer support. But then, I am not a Python believer, and if I were to invest a serious amount of effort in the problem, I would most definitely go the Node.js path. As it is, I am more likely to just pick the fruits of whatever is useful from tweb in the context of giewiki (like server-side wikifiers).

But I must take some time to look into what Jeremy is doing with TW5.

/Poul

[Måns]

Hi Poul

I run into problems with malformed text when I create a new document
with danish characters in it:
Same thing happens when I save an already existing document with
danish characters..

What can I do to make it work?

http://tinyurl.com/9k9vz3r

Cheers Måns Mårtensson

> >   openhttp://0.0.0.0:8080/recipes/default/tiddlers.wiki[1]

>
> > I recognize that for many people that is complete gibberish and having
> > a "healthy Python installation" is a non-starter, so my point is not
> > that people should have to do that, but rather that _someone_ could
> > make a thing that encapsulates the complexity for a particular
> > environment (such as Windows) and by so doing make a very positive
> > contribution to getting tiddlers into people's hands.
>
> > If TiddlyWiki is a useful to you (the general you) because of its
> > standalone-and-save-itself nature, then tools like TiddlyWeb,
> > ccTiddly, giewiki probably don't matter; but, if what you care about
> > is tiddlers then each of those tools (especially TiddlyWeb if I may be
> > so bold) provide huge scope[3] for doing interesting things. Each of
> > those projects is open source, meaning they rely on community to make
> > them their best, yet (as far as I can discern) each has only ever had
> > a very small number of contributions from outside their core
> > developer.
>
> > Why is that?[2]
>
> > [1] It can actually be shorter than that. That list is for running the
> > service in a virtualenv, wherein you don't need to root access to
> > install packages, and the packages don't clobber other installations.
> > If you are root you can:
>
> >   sudo pip install -U tiddlywebwiki
> >   twinstance tweb
> >   cd tweb
> >   twanager server

> >   openhttp://0.0.0.0:8080/recipes/default/tiddlers.wiki[1]

[Mark S.]

That's a lot of stuff to set up.

At this point, TW is no longer the light-weight, run-anywhere personal wiki solution. There are already information and wiki systems that can run on a USB stick with no install and no significant memory restriction. For that matter it would be easier just to carry a copy of FF 3.6.

What needs to happen, if TW is to remain viable for the masses, is for someone to develop a TW plugin that will reduce security restrictions on specific TW files that you indicate. A "FF3.6 mode" plugin. Or a TW-data-transfer-mode plugin. Such things must be possible via plugins because there are already plugins that save to the local drive.

Mark

[Eric Shulman]

> someone to develop a TW plugin that will reduce security restrictions on
> specific TW files that you indicate.

There is NO WAY to "reduce security restrictions" via a TW Plugin.
The Firefox methods for gaining local filesystem privileges have been
deprecated. As of FF15, they have removed the confirmation dialog
("... may be unsafe... are you sure..."), and always reject privileges
for new files. Existing files that were already granted filesystem
access still have that permission (via the prefs.js declarations).
However, as of FF17, the entire "enablePrivilege()" functionality will
be GONE from Firefox. Thus... NO javascript code will be able to
request on-the-fly privileges.

Fortunately, Jeremy has ALREADY created a solution for FireFox that
will work moving forward:
https://addons.mozilla.org/en-US/firefox/addon/tiddlyfox/

Note that this is NOT a TW plugin.... it is a FireFox add-on. It's
purpose is to sit in the background and detect when a TW document is
loaded. Then, it automatically patches the existing TWCore file I/O
functions to invoke I/O functions from within the add-on. By
definitions, browser add-on run as privileged code. Thus, the file I/
O provided by the add-on does not require 'enablePrivilege()'
functionality, and will work in the current (and future) versions of
FireFox.

Unfortunately, this doesn't address ALL instances where the TWCore
uses the enablePrivilege() function. Specifically, the backstage
Import function also requires file I/O privileges. I am currently
working on changes to that TWCore subsystem, to try to eliminate the
use of the deprecated functions (or at least wrap them in try/catch
handlers so they don't create failure points).

enjoy,
-e
Eric Shulman
TiddlyTools / ELS Design Studios

HELP ME TO HELP YOU - MAKE A CONTRIBUTION TO MY "TIP JAR"...
http://www.TiddlyTools.com/#Donations

Professional TiddlyWiki Consulting Services...
Analysis, Design, and Custom Solutions:
http://www.TiddlyTools.com/#Contact

[chris...@gmail.com]

On Fri, 19 Oct 2012, Mark S. wrote:

> That's a lot of stuff to set up.

That's part of my point. It looks complex, and to some extent it is,
but it is considerably less complex than what is happening under the
covers when you do something like install a web browser. The
difference is that the work to create the covers (an installer) on
TiddlyWeb has not been done.

This is, in large part, because of lack of engagement with people who
bridge that gap between folk like me and Poul and potential users on
the various architectures.

So my questions surround the single question of: Where are those
people?

> At this point, TW is no longer the light-weight, run-anywhere personal wiki
> solution. There are already information and wiki systems that can run on a
> USB stick with no install and no significant memory restriction. For that
> matter it would be easier just to carry a copy of FF 3.6.

If the part of tw that matters to you is the "light-weight,
run-anywhere personal wiki" then I agree that carrying around a copy
of FF 3.6 is probably a very good solution.

What tools like TiddlyWeb and gieWiki provide is flexible reuse of
content. The tiddler concept taking onto the net.

--
Chris Dent http://burningchrome.com/
[...]

[chris...@gmail.com]

On Thu, 18 Oct 2012, Poul wrote:

> I certainly sympathize with Chris's disappointment in the ability of
> server-based TW solutions to gain developer support. But then, I am not a
> Python believer, and if I were to invest a serious amount of effort in the
> problem, I would most definitely go the Node.js path. As it is, I am more
> likely to just pick the fruits of whatever is useful from tweb in the
> context of giewiki (like server-side wikifiers).

When TiddlyWeb was started nodejs was still a glimmer. At the same
time TiddlyWeb was meant to operate as a reference for a tiddler HTTP
API, so I figured a language that is highly readable was a good
choice. The hope, at the time, was that there would be developer
engagement and parties interested in other environment would port the
API to those environments. As far as I know that hasn't happened.

Except that at one point I did start working on node port of
TiddlyWeb, tiddlynode[1], but it didn't get too far because of...

...lack of engagement from interested parties.
...real users and real life on TiddlySpace demanding more time.

Also since it was created in early node days, the idioms are ugly, so
the code is rather hard to read and use. It did, however, drive some
improvements to the testing infrastructure for the Python version.

> But I must take some time to look into what Jeremy is doing with TW5.

I posted in tiddlywikidev[2] suggesting that making a tw5 serializer
for TiddlyWeb was a great way for someone to get involved in making a
big contribution to the TiddlyVerse. The only person who responded was
Jeremy, agreeing with me.

That, to be blunt, is not a great sign. What needs to be done?


[1] https://github.com/cdent/tiddlynode
[2] https://groups.google.com/d/topic/tiddlywikidev/BIRuexV0g-U/discussion

[Måns]

Hi Poul

At last I managed to make tws (with node.js) run/startup as a service on my linux boxes.

It's great to be able to create and save TWs without any hazzle whatsoever :-)

Thanks a lot for making this available - for all platforms..

>I don't think there are any security problems to worry about in using node.js for a server as long as it listens only on 127.0.0.1 (the loopback interface), as it is not exposed to outside connection.

I'm using Etherpad Lite and TWS on my local network (changed 127.0.0.1 to 0.0.0.0)  -

 Just for adding a little security I'd like to add a login feature to the server.

In Etherpad Lite's settings.js file I noticed this, which is used by it's server.js file:

  "users": {

    "admin": {

      "password": "change1",

      "is_admin": true

    },

    "user": {

      "password": "change1",

      "is_admin": false

    }

  },

How would I implement something similar in the tws.js file?

 

Cheers Måns Mårtensson