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
On 23 November 2019 05:57:37 GMT-08:00, Miha Lunar <mlu...@gmail.com> wrote:
>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
>
>On Saturday, November 23, 2019 at 2:50:37 PM UTC+1, Arlen Beiler wrote:
>>
>> 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.
>>
>> On Sat, Nov 23, 2019 at 08:16 TiddlyTweeter <tiddly...@assays.tv
>> <javascript:>> wrote:
>>
>>> 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.)*
>>> Stefan Pfister wrote:
>>>>
>>>> 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
>>>>
>>>>
>>>>
>>>> --
>>> 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 <javascript:>.
>>> To view this discussion on the web visit
>>>
>https://groups.google.com/d/msgid/tiddlywiki/dabe0b3f-9095-45d0-86c5-65fd29a1441c%40googlegroups.com
>
>>>
><https://groups.google.com/d/msgid/tiddlywiki/dabe0b3f-9095-45d0-86c5-65fd29a1441c%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>>
>
>--
>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+unsubscr...@googlegroups.com.
>To view this discussion on the web visit
>https://groups.google.com/d/msgid/tiddlywiki/60b58373-13e8-427a-b7c8-c50f5597b496%40googlegroups.com.
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/tiddlywiki/71E1E073-B955-4B30-B948-2CA82F24B152%40gmail.com.
