Multi-user TiddlyWiki

[Arlen Beiler]

Hello Everyone,

After making the comment on the documentation, I started wondering exactly what it would require to re-invent the MediaWiki juggernaut as TiddlyWiki. Here is what I came up with. Part of this comes from my experience on Wikipedia, and part from setting up my own MediaWiki installations on my computer. Not that I have a lot of experience, but for what it's worth.

https://docs.google.com/document/d/1Y8qV6I9BI1vgvve5kfThLKUOPu0aeF-FiCNpWvP62Hs/edit?usp=sharing

Feel free to add comments on the document itself or here.

Enjoy!

-Arlen

[Jeremy Ruston]

Hi Alren

Thanks for starting the discussion. I’m going to respond with a few points here to keep the information together.

Firstly, TiddlyWiki under Node.js is specifically designed for multi-user scenarios, but there are some rough edges that make the experience imperfect at present:

* There’s no separation between different users, so they share the same username for signing edits, and share the same state data (much of the state data isn’t synced to the server eg for popups)

* There’s no instant notification of changes made by another user

* There’s no feedback if the edits of another user clash with your own

* There’s no support for multiple revisions

None of those things present any implementation difficulties. The biggest architectural change that I can see is to separate the client wiki from the server wiki, so that they don’t need to be same (with the same plugins etc).

The best approach to the problem you mention of all the tiddlers being shipped to the client is to shift some or all of the processing back to the server. For example, we can ship skinny tiddlers to the client, but handle searches on the server. Or, as you note, we can generate standalone HTML tiddlers on the server. (In that situation I would handle interactivity by swapping in revised definitions for macros like the TOC, or tabs, that use minimal JS to manipulate state in the DOM (like Bootstrap etc)).

As you reflect in the Google doc, there are some security issues with sharing TiddlyWiki content on the server. On the whole, I don’t think they would be a huge problem for a community documentation project.

TiddlyWiki’s strong encapsulation at the HTTP boundary makes it easy to build new and different server sides for it; a simple serverside for TiddlyWiki is a good deal less complicated than TiddlyWiki itself. So I’d always encourage such experimentation.

In my day job, I’ve been doing a lot of work with getting TiddlyWiki running under Amazon Web Services. Rather than a conventional server, I stitch together services like S3, CloudFront and Lambda to build TiddlyWiki HTML files and provide an API for them to use. Personally, I’m a huge fan of not having to run a conventional server, and not having to worry about patches and intrusion attempts :)

Your document strays into some questions around the design collaboration systems. My own view, which evolved before TiddlySpace, is that shared spaces do not work beyond a very small number of users. I’m still an enthusiast for the approach that TiddlySpace took — separate spaces for individual users or small, trusted groups, and space inclusion as the primary sharing mechanism. It’s the same thinking as the current TWederation work.

Best wishes

Jeremy

--
You received this message because you are subscribed to the Google Groups "TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywikide...@googlegroups.com.
To post to this group, send email to tiddly...@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywikidev.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywikidev/CAJ1vdSRNaznTeB1qupTmgzW4bK6%2BNaLFrOv2CUEi7MoZLaiYow%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Hans Wobbe]

Arlen:

I believe you raised the issue of simply using WikiBooks in the Community group.  FYI, now-a-days, I am increasingly aware of the benefits of KISS ( Keep it simple ... ) so I thought I would just add a bit of encouragement that WikiBooks is indeed a find way of developing some relatively sophisticated reading material. 

I am by no means an expert in WikiBooks, but it is sufficient productive that  there are several tasks I prefer to work on as WikiBooks, in spite of having TW as my preferred personal productivity front end.  In fact, I effectively mix the two technologies since I like the way MediaWiki pages let my make use of headings for sections, yet I use TW to get directly to the individual sections of many WikiPedia pages that I weave together to provide the Background information for some Research I publish.  To embellish my book content further, I use Username subPages.  Finally, the ability to easily generate a PDF "book" and down-load it is also very nice and make it easy to print my own copies for those situation in which paper is still preferable.

One last observation; the debate about how to document TW seems to over-look the fact that we can do it in parallel in several different environments.  If one (or more) are preferable, I am sure it will be relatively easier to "port" the content.

Cheers,
Hans'

[Dmitry Sokolov]

Dear All,
thank you for the very interesting topic.

From my experience, better if all the information is collected on a "single page" where it can be found easy for co-editing and reuse.
I am currently working on PBWorks but looking forward to switching to a hybrid P2P platform, yet to be developed, to my understanding.
Here is where all the information on this topic is being collected:
http://confocal-manawatu.pbworks.com/w/page/113792539/MultiUser%20TiddlyWiki

I would like to start working on it's implementation and would appreciate your suggestions:

• where to start from
• how to contibute
• what to focus on

Should TWederation be the solution?

Cheers,
Dmitry

[prog...@assays.tv]

Ciao all,

Though this thread goes a slightly different way I'd just like to bookmark here the related discussion in the #TiddlyWiki forum about documentation: http://tinyurl.com/z6fxvr6.

I'm encouraged that there is real discussion of documentation issues (in the widest sense) happening. But given how Google Groups works I wanna give some flags to ensure we don't lose the history of this and end up doing it again in a few months. That we continue to tease out differentiations needed for a consensus & then make the change needed.

Best wishes
Josiah

[Arlen Beiler]

Hi Dmitry,

I have been thinking about this and I think TiddlySpot and MediaWiki should give us some ideas of where to start. Also there is Tank, but that seems to be basically dead. It may be used by some people though. The Tiddlyweb protocol comes very close to what I am thinking of, but it will still take some work.

https://tank.peermore.com

On Dec 18, 2016 20:57, "Dmitry Sokolov" <dmitry.v...@gmail.com> wrote:

Dear All,
thank you for the very interesting topic.

From my experience, better if all the information is collected on a "single page" where it can be found easy for co-editing and reuse.

I am currently working on PBWorks but looking forward to switching to a hybrid P2P platform, yet to be developed, to my understanding.

Here is where all the information on this topic is being collected:

http://confocal-manawatu.pbworks.com/w/page/113792539/MultiUser%20TiddlyWiki#view=edit

I would like to start working on it's implementation and would appreciate your suggestions:

• where to start from
• how to contibute
• what to focus on

Should TWederation be the solution?

Cheers,

Dmitry

On Saturday, 17 December 2016 11:07:02 UTC+13, Arlen Beiler wrote:

Hello Everyone,

After making the comment on the documentation, I started wondering exactly what it would require to re-invent the MediaWiki juggernaut as TiddlyWiki. Here is what I came up with. Part of this comes from my experience on Wikipedia, and part from setting up my own MediaWiki installations on my computer. Not that I have a lot of experience, but for what it's worth.

https://docs.google.com/document/d/1Y8qV6I9BI1vgvve5kfThLKUOPu0aeF-FiCNpWvP62Hs/edit?usp=sharing

Feel free to add comments on the document itself or here.

Enjoy!

-Arlen

--

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

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

To post to this group, send email to tiddly...@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywikidev.

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywikidev/0b4e7234-830a-4477-9654-4d0a4db1695d%40googlegroups.com.

[Dmitry Sokolov]

Thank you Arlen,
all information on Multi-User TW is being collected here: MultiUser TiddlyWiki
Would you have a link on the "Tiddlyweb protocol", please?
Other suggestions?
Cheers,
Dmitry

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

[Danielo Rodríguez]

If you are collecting promises about multiple users environment it is on the road map of NoteSelf

[David Szego]

I'm talking completely in ignorance, but I've always figured entire sets of Tiddlers could be given a field called "ro-users" and a field called "rw-users" and the Core could just be modified to allow an HTTP Auth login.

At that point, the user could only see and edit what they create, or what Tiddlers other creators add their names to.

It doesn't need to be super secure, if the point is just to work collaboratively while ensuring you're not trampling on each other's work.

[Arlen Beiler]

That's a start. How would you handle edit conflicts where two users can both edit the same tiddler? How about notifying other users that an edit was made? Where do you store the tiddlers? What mechanism do you use and what about server side rendering? How about revision history? Those are the main questions I am wondering right now, and maybe at some point I will answer them. Because that is really all that needs to be done. The answers just need to be decided, really.

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

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

To post to this group, send email to tiddly...@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywikidev.

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywikidev/35064741-1811-4449-9910-91c26fe942e3%40googlegroups.com.

[David Szego]

I think Jeremy has some revision-handling code hiding in the Core (no?).

Certainly revisions could be handled as Tiddlers, even with the same name, where the Core would just pull the latest by "modified" field, or give you an Older/Newer button a lá Apple's Time Machine by pulling the appropriately modified Tiddler and putting some indicator icon next to the title.

Notifications could be either AJAX (doable, see my AJAX plugin in Cardo), or simply let each other overwrite and save the millisecond-stamped revisions - if you use the above scheme where you keep the name the same but just sort by modification, you leave it between the users to figure it out without deleting anything. They can agree on which mod is best and mark it as "latest".

I think it's best to keep it as simple as possible while allowing collaboration - you don't need it turning into SharePoint!

[Arlen Beiler]

I think it's best to keep it as simple as possible while allowing collaboration - you don't need it turning into SharePoint!

True that, but I would love to see it become a platform a little like Wikipedia. However, the mechanisms involved are a bit different, so this could take an interesting twist.

--
You received this message because you are subscribed to the Google Groups "TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywikidev+unsubscribe@googlegroups.com.
To post to this group, send email to tiddly...@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywikidev.

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywikidev/d2157331-ef66-4e53-a950-cbdb340486cf%40googlegroups.com.

[C Pa]

Arlen

>>https://docs.google.com/document/d/1Y8qV6I9BI1vgvve5kfThLKUOPu0aeF-FiCNpWvP62Hs/edit?usp=sharing

This seems to be a complete rewrite of the TW core. It seems to me that the simplest way to create a multi-user TiddlyWiki is as follows:

1. Implement a userspace function in the core
   
1. Based on a directory structure like $:/users/<username>/
2. After loading the root tiddlywiki, loads any tiddlers in the userspace
1. This way each user has their own space (like tiddlyspot)
   
2. but that userspace only contains the tiddlers unique to that user
   
2. Implement a separate plugin for editing functionality
1. Allows read-only vs read/write users
   
3. Implement a login screen on root access that asks for a username or a login
1. Username
   
1. sets the userspace root
   
2. navigates to a user's space
   
3. Loads tiddlers within that userspace
4. Allows visitors to read user's published content
   
2. Username/password
   
1. sets the userspace root
2. navigates to a user's space
3. loads the editing plugin
4. Loads tiddlers within that userspace
5. Allows users to edit their content
   
4. Extend the server filesaver functionality to save new tiddlers to the user's userspace rather than to the root
1. Allows users to update their content
   
5. Implement import functionality that allows users to load tiddlers and plugins from other user's userspace
1. Allows plugins and other content to be maintained by one user and used by others
   
6. Implement a bulletin board to allow users to publish bundles of their tiddlers and plugins for other users to subscribe to
1. Allows folks to know about content
   
7. Implement a user plugin that allows each user to submit extensions to the core
1. Allows users to contribute content that expands the root to hold content agreed on by the community as needed by everyone
8. Implement a test environment to test submissions to the core
1. Allows users to test core extensions before implementing in root
   

[Douglas Counts]

Hello Arlen,

I read your document on Google Docs, You discuss to possibilities of making a huge wikipedia-like site using TiddlyWiki.

TiddlyWiki, the app inside the browser, is designed to stand on its own because all the content is already contained within it.  A user can save the file locally and still run it even offline.  So your discussions there about using a database and building in dependencies upon a website don't really fit the purpose/mindset behind TW.  You are right in your discussion there that no one would want to load all of wikipedia into their computer's memory space all at once, but that isn't the mindset behind TiddlyWiki. 

It would be like driving a square peg into a round hole.  You can even email your entire wiki with TiddlyWiki because it can be saved as a single file.

I recommend having a separate TW for each major area of interest you wish to save information on, you can link to the other TW files and load them smoothly in that manner.  That is what I do.

-Doug

[Eric Shulman]

On Tuesday, April 4, 2017 at 4:32:58 AM UTC-7, Douglas Counts wrote:

TiddlyWiki, the app inside the browser, is designed to stand on its own because all the content is already contained within it.  A user can save the file locally and still run it even offline.  So your discussions there about using a database and building in dependencies upon a website don't really fit the purpose/mindset behind TW.  You are right in your discussion there that no one would want to load all of wikipedia into their computer's memory space all at once, but that isn't the mindset behind TiddlyWiki. 

TiddlyWiki5 natively supports use as EITHER an SPA (Single-Page Application) -- where all tiddler content is loaded at startup, and all changes are local to the browser until the file is saved -- OR as a client-server setup using nodejs -- where tiddlers are stored in separate files that can be updated as soon as they are edited (autosave).

Running under NodeJS, TiddlyWiki5 supports HTTP request protocols that allows you to "serve" your TiddlyWiki in your browser using either a local IP loopback and portID (e.g., http://128.0.0.1:8080) or a true remote host IP and port.  The nodeJS client-server architecture also supports use of "skinny" tiddlers that initially send only the basic tiddler definitions without the actual content (i.e., just the title, created/modified dates, author, etc.), and fetches the tiddler content on demand when actually referenced.  In theory, this permits you to create a TiddlyWiki of virtually any size.  In practice, some issues can arise when working with particularly large data sets.  The upper limit depends greatly on the specific implementation details of your use-case and your system performance/resources but TWs containing many Mb of content (both text and embedded images) is possible.

You can, of course, still save a local stand-alone HTML file from the TiddlyWiki loaded in the browser, and you can also export your TiddlyWiki to individual "static HTML" files that can be be published and served (read-only) from a standard web server, without needing NodeJS.

enjoy,

-e

Eric Shulman

TiddlyTools: "Small Tools for Big Ideas" (tm)

InsideTiddlyWiki: The Missing Manuals

[Douglas Counts]

but TWs containing many Mb of content (both text and embedded images) is possible

That was my point, in that his Google Docs paper discusses building something large like wikipedia using GigaBytes to TerraBytes of data.  Search and many other features would either fail or be painfully slow.  My understanding of search, as implemented, linearly searches through everything and doesn't use saved index trees. If one had millions of records, they could probably take a long coffee break before the search was completed.

I just don't see how TiddlyWiki can scale that high without changing major operational components like search regardless of whether the search is performed within the browser or the server.

-Doug  

[Arlen Beiler]

Thanks for the discussion :)

I am glad to hear other people debate the pros and cons of my ideas :)

I think the most obvious thing to me right now is that I am thinking too far ahead. Here is my thought process:

My goal is to make TiddlyWiki allow more than one person to edit a wiki at the same time. 
Last time more than one person edited a wiki, the list of page titles grew to 70 MB (that's the size of all the title strings put together on English Wikipedia ). 

Therefore I need to make sure that my implementation can handle 70MB of titles, plus the resulting skinny tiddlers.

So that's approximately what led to all that. Obviously that is not preventing us from implementing multi-user, so this discussion has been profitable :)

--
You received this message because you are subscribed to the Google Groups "TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywikidev+unsubscribe@googlegroups.com.
To post to this group, send email to tiddly...@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywikidev.

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywikidev/18b19e8b-0ba5-45d7-905a-a5788f51d537%40googlegroups.com.