Testing the Multi Wiki Server Plugin

[pmario]

@well-noted

Is this default behavior, or a bug that I’ve stumbled across?

From my point of view that’s a bug. Since it should be mulit-user, multi-device it should work with the same user an several devices too.

Same as if you would access gmail from 2 devices at the same time

[jeremyruston]

@well-noted

Now that I’ve got delete, filter tiddlers, and move tiddlers between bags, I’ve made another attempt using my primary wiki and noticed, when I tried to log in on a second device, it logged me out of my first device. Is this default behavior, or a bug that I’ve stumbled across? Anyone else getting this?

I think this is definitely a bug (although I agree it could be useful behaviour in some situations). I’ve made a ticket here:

MWS: Logging into one browser/device also logs users out of other browsers/devices

[jeremyruston]

@JanJo

I guess administrative Tools like that become absolutely necessary given a certaike number of users. @jeremyruston How do you treat these questions at anna freud?

Anna Freud use Xememex, a multi-user implementation of bags and recipes for TiddlyWiki that I developed in 2016/17. It is based on Amazon Web Services and the serverless architecture. It has a separate admin screen with the ability to list and modify bags, recipes, spaces and users. There will be something similar for MWS in due course.

[well-noted]

@well-noted

This leads me to wonder if the bag field is truly vestigial at this point.

Some further testing confirms that moving tiddlers between bags has no effect on how their bag value is displayed (I didn’t really expect it to, since I didn’t tell it to do that when I set up the button, but thought it worth confirming).

My question is – when we move from a source-bag to a target-bag, should we update the bag field of each tiddler to the value of target-bag? Is it truly vestigial at this point, or is there some intention for it in the future?

My instinct on this is to update the value so that when it’s displayed in the wiki someone could reference its origin – as long as that wont interfere with any bigger-picture plans down the line.

[jeremyruston]

@well-noted

This leads me to wonder if the bag field is truly vestigial at this point.

Hi @well-noted where are you seeing a “bag” field?

[well-noted]

I’m talking about the bag field in the tiddler info, within the wiki.

These are my old tiddlers rather than newly created ones, so it could just be a value that’s carried over.

I could imagine times where one might want to be able to filter within wiki by source bag, which is what got me wondering if it should be included in the move-betwren-bags operation

[jeremyruston]

@well-noted

These are my old tiddlers rather than newly created ones, so it could just be a value that’s carried over.

I think that is what has happened. MWS itself doesn’t use a bag field, but it was used by some earlier TiddlyWiki-based server systems such as TiddlyWeb/TiddlySpace.

[well-noted]

Got it, was chasing my own tail

Thoughts (anybody?) on introducing the bag field to tiddlers when they are created moved into MWS bags? The architecture is already there to keep the field hidden, and it would be simple to instruct that the the database update the bag-field when tiddlers are created or moved.

I can imagine client-side situations where, inside the wiki, one might want to group tiddlers according to the bags to which they belong – and while that could be achieved through adding some other tag or field, it seems to me that bag is a value that already exists and might as well be utilized.

[jms19]

My current single-file setup with Apache and WebDAV serves me well and is such that access requires no noticeable authentication

• from my home (IPv4 and 6) addresses
• or from my devices which use a key in the URI (shortcuts on mobile devices’ home screens)
  otherwise can use HTTP authentication (for use on any other random computer/location)

The configuration has this

    <RequireAny>
    Require ip a.b.c.d 2a0d:blah:blah/48
    Require expr "%{QUERY_STRING} == 'somethingorother'"
    Require user myusername
    </RequireAny>

Is there a neat way to do this with MWS or does it have to be coded up ?

Ta,

Jon

[jeremyruston]

@well-noted

Thoughts (anybody?) on introducing the bag field to tiddlers when they are created moved into MWS bags?

Hi @well-noted the earlier TiddlyWeb server side did rely on a “bag” field, and it turned out to be quite inconvenient, and lead to extraneous, unwanted bag fields on any tiddler that had ever been synced to the server.

In MWS, the client side sync process use two JSON state tiddlers to track the server side revision and bag of all known tiddlers:

• $:/state/multiwikiclient/tiddlers/bag contains the bag names
• $:/state/multiwikiclient/tiddlers/revision contains the revision numbers

This information can be accessed using the index syntax (eg {{$:/state/multiwikiclient/tiddlers/bag##HelloThere}}) or via the JSON operators.

As I think we’ve discussed elsewhere, moving a tiddler between bags would currently require two separate API calls. I would like to explore approaches that would let us perform that operation in a single API call.

[jeremyruston]

@jms19

Is there a neat way to do this with MWS or does it have to be coded up ?

Hi @jms19 MWS currently only supports form-based authentication with session cookies. Authentication schemes are not currently pluggable but the intention is that it will be possible to extend the built-in authenticators with custom ones which could handle the schemes you mention.

In the meantime, you may be able to use an external program such as nginx to implement the IP address-based authorisation.

[well-noted]

I have been noticing something recently that suggests to me I may have a misunderstanding of MWS – discrepancies between the same tiddler when it is represented in different recipes.

For example, my TODO items are in one bag that is shared between two recipes – in one recipe, I tag an item as “Done” and am surprised to find that it is not also tagged as done in the context of the other recipe.

After some investigating, I discover that by changing the tag in one context, it creates a new tiddler in the top bag of the recipe to be used in the place of the same tiddler in the bag of lower items in the recipe.

Is this expected/desired behavior?

It was my sense that modifying a tiddler that is in one bag should preserve its place in that bag if modified, rather than creating a new tiddler in the first bag of the recipe in which it is being viewed

[pmario]

@well-noted

Is this expected/desired behavior?

It was my sense that modifying a tiddler that is in one bag should preserve its place in that bag if modified, rather than creating a new tiddler in the first bag of the recipe in which it is being viewed

That’s desired behaviour.

You may have a closer look at a reply at an other thread, where I do point out some “gotchas” for new users.

Low-cost multi-wiki solution for D&D game?

From my point of view, that multi-wiki-server MWS plugin still is highly experimental. Especially the access handling is still in flux and subject to change in backwards incompatible ways. I think your usecase can be solved with MWS, but you would be an early adopter.Which means there will be breaking changes in the code, which may set you back several steps, or even to “sqare one”. The access control list (ACL) configurations in TW is “role” based. But at the moment this system only knows how…

Cloning content into “higher level” bags has an advantage in the long run. – The main problem at the moment is, that we do not have any visual indication, what’s going on.

If you would have had the possibility to move the “new tiddler” and “overwrite” the “lower level” one in a convenient and visible way, it would have been an obvious feature.

Because we are still in early stages, it is an issue.

[JanJo]

Could this be cured with an overwritten tiddlers table where the overwritten tiddlers are listed per bag perhaps with a sort of automatized temporary renaming mechanism.

(Zut alors ! It sounded easy in the beginning….)

[well-noted]

Interesting. I will need to get my head around this somewhat.

In my case, I would like to have a general TODO list that stores all the TODOs from all my various wikis – it has access to all the bags of TODOs from the relevant recipes, and I had expected that I could interact with the TODO list and have those changes reflected across all the other recipes: instead, checking off a TODO item only generates a clone in the TODO List page template bag, which is not as useful to me, especially in the context of tracking projects.

@pmario

If you would have had the possibility to move the “new tiddler” and “overwrite” the “lower level” one in a convenient and visible way, it would have been an obvious feature.

I would propose going a step further and say allowing users to select from multiple handling depending on filter conditions would be most helpful.

For example, I don’t mind if my TODOs get shuffled into other bags, but ultimately I do want them to all aggregate toward the TODO-items bag.

Likewise, I want all my Index and Idea tiddlers to end up in my KnowledgeBase and my Sources to end up in my References.

@pmario

Cloning content into “higher level” bags has an advantage in the long run

State tiddlers are the only obvious example I can think of, in my case, for this, but perhaps I’ve overlooked something.

[well-noted]

Any input on how realistic some kind of contextual filter for recipes would be?

I’m thinking “If this tiddler is being reviewed in the context of this recipe, then reveal this content”

This may actually link back to this previous thought:

@well-noted

Thoughts (anybody?) on introducing the bag field to tiddlers when they are created moved into MWS bags? The architecture is already there to keep the field hidden, and it would be simple to instruct that the the database update the bag-field when tiddlers are created or moved.

[jeremyruston]

@well-noted

It was my sense that modifying a tiddler that is in one bag should preserve its place in that bag if modified, rather than creating a new tiddler in the first bag of the recipe in which it is being viewed

This is the behaviour of the original TiddlyWeb design back in 2008 - see https://tiddlyweb.com/. We saw several advantages with this approach:

• Simplicity. End users do not have to be aware of the bag and recipe mechanism
• Flexibility. An advantage of routing all changes to the top bag is the ability to later explicitly push those changes down to the intended bag, giving a process akin to pull requests

There were similar discussions about whether recipes should be nestable, so that a recipe would be a list of intermingled subrecipes and bags. Our conclusion was that this additional complexity wasn’t worth it, and users could achieve the same effect by dynamically (re)building the recipe list, for which there was a simple API. Our biggest concern was again making the platform too complex. Programmers are used to dealing concepts like hierarchical nesting and indirection, but they can be unfamiliar and confusing for end users. Our belief was that the server should be as dumb as possible, with a preference for implementing flexibility and hackability within the TiddlyWiki client.

[well-noted]

Nice to hear from you, @jeremyruston

I agree with the decision about not having sub-recipes, for the reasons you state.

I have modified my working-edition so that, if a tiddler already exists and is saved, it gets saved back to the bag from which is already was.

For me, this has some major and obvious advantages:

1. I can sort from my existing wiki all tiddlers that match my Idea and Index tags and sort them into my knowledge database, for example
2. I can then know that in any context I want to see and interact with my knowledge-database tiddlers, I just have to include that bag in my recipe

3. I can
   a. Access and do data entry on my (much smaller and faster) knowledge database recipe and still
   b. View and modify those tiddlers in any other context they appear, knowing that those changes will be consistently reflected across all spaces.

Another context in which this is useful: Todo Lists:

Since making this change, I have been able to have all my todo items, calendar items, and projects in individual bags, which are all included in a recipe exclusively for accessing and interacting with scheduling/planning/itemizing.

This allows me to have an extremely small, simple, lightweight wiki that I am able to interact with in a way that allows me to replace, for example, google tasks/calendar. I can run that in my sidebar, or as a PWA on Android, alongside navigating my daily life and other wikis, without all the bloat of all of the context that I get from mixing together more complex recipes.

When attempting to do this with the core version, marking items as done in one context would essentially make a copy of it without updating the original context. This obviously does not work.

The idea of pushing changes down to other bags is interesting. Since the only mechanism I’ve seen for shuffling between bags is my improvised method, there may be some conceptualized form of this that would appeal to me. Would love to hear more about what the vision for that would be… Though I would hope it would include some controls for “Always sync changes from this context”

[joshuafontany]

@well-noted

The idea of pushing changes down to other bags is interesting. Since the only mechanism I’ve seen for shuffling between bags is my improvised method, there may be some conceptualized form of this that would appeal to me. Would love to hear more about what the vision for that would be… Though I would hope it would include some controls for “Always sync changes from this context”

Imagine 2 wiki/recipes

MyCoolRPG-Dev
Description: Draft mode of RPG rules (v0.1.3, private)
Recipe (last bag wins):
MyPlugins-bag
MyCoolRPG-bag
MyCoolRPG-Dev-bag

MyCoolRPG
Description: Published RPG rules (v0.1.2, public)
Recipe (last bag wins):
MyPlugins-bag
MyCoolRPG-bag

From the MyCoolRPG-Dev wiki interface, you have full access to the current “published rules”, but then any changes/updates to existing tiddlers from the published edition only exist in the Dev wiki. Until you “commit and publish” (change the bag for all “committed” tiddlers). One of these could be the “version” tiddler, so that publishing it auto-updates the version " in prod" to (for example) v0.1.3, and then bump the “dev” version automatically to v0.1.4.

I also see cases where updated tiddlers should be “auto committed” back to the bag they started from - especially for ToDos, etc.

[well-noted]

Interesting. But to take a step back, what does the actual interface for this look like? Does it take place from within the wiki or from within the MWS Index UI?

Like I said, there’s currently no form of bag shuffling I know of other than my hacky solution