Jeremy, Responding to such a question at all are great, no need to be concerned about the time it takes to respond on larger speculative ideas.
I now understand this is not a TWX issue. Very exciting your response, it sounds quite do able if not already done. I suppose the trick here is to convert this design model into something that can be easily communicated, well documented, a little testing and inviting feedback. I am keen to make this a reality, I can put in the effort to do so, however how should I gain the support or help where I do not have the skill?. It is a project, that needs a vision to guide it as the end result aims to be an easy conceptual model that experts and newbys alike can apply. I need a project framework of sorts around it, and acceptance? to promote the vision. I look forward to exploring the 5.1.18 auth changes So would I be correct in thinking that we can/or will be able demand login to edit a wiki (the front end) that also carry's a key or other credentials we could use to authenticate to one or more backends, an example may be login, then when reviewing history tiddlers we have to connect to a history wiki, unless I have the wiki credentials I can not see the tiddlers served by the history wiki? In someways this is an intermediate between secure wikis and secure tiddlers, in effect a secure groups of tiddlers (as served by a wiki), The advantage being I can remove access to select users on the front end wiki at any time, without stopping them access the front end? If the above were so, I would be happy to build a tiddlerlevel process from this to do (as mentioned before) because I would have the infrastructure I need to do so. *In this model there would be no contention for tiddlers, as the ownership exchange process handles this however we could pass a tiddlers ownership to a server, which can be set up to respond with actions to transform the tiddler and return it or another back to the original owner.* Thanks again Tony On Monday, July 9, 2018 at 1:42:14 AM UTC+10, Jeremy Ruston wrote: > > Hi Tony > > Sorry for picking this up so late. > > TiddlyWiki is in fact both the Front End Gui and the backend server in > one. In fact in some ways the server based implementations do in some ways > separate the front and back already, Bob does this even more so with > messages to the server. > > > To be clear, if you run TW5 under Node.js as an HTTP server then there are > two distinct instances of the same TW5 code, one running in the browser, > and one running on the server. They speak to each other via HTTP, and of > course Bob adds a websockets channel of communication. > > > What if TiddlyWiki X (an imagined future version) took this a lot more > seriously? > > Imagine if every tiddlywiki could act as a back-end to any other > tiddlywiki, this would allow one tiddly wiki to store its tiddlers in one > or more other tiddlywikis. Or another TiddlyWiki may host more than one > other TiddlyWiki's tiddlers for it. > > > This is already possible. There is a well defined API through which the > browser instance talks to the server instance, and there's nothing stopping > experimenting with the browser calling multiple serverside APIs, nor with > the server instance of TW5 itself using the API to speak to another > instance. > > That is the front and backend functions could be sub/divided internally > and externally. > > > I think we have already exactly that level of encapsulation between the > two parts. > > Some may immediately see the potential of this but here are a few examples; > > - We could add security (authentication) the the connections to other > wikis rather than for each tiddler. If you have not authenticated you cant > see the tiddlers being served. > > The API does already support wiki-based security (it's enhanced in the > latest v5.1.18). I've no current plans to explore tiddler-based > authentication, but it remains open to investigation by others. > > > - Maybe every tiddler is owned by a wiki and only it can change that > tiddler however the owner can pass ownership to another wiki. If designed > correctly the ownership could be passed back. The receiving wiki could > choose if it wants to accept or reject the tiddler. This may be different > if its a macro, plugin or style-sheet. > > That's pretty much how the API works: tiddlers get synced back to the > server that they came from. > > > - Otherwise a wiki can ask another to store its tiddlers for it, > either with an encryption key or without thus permitting access or > denial of access of the tiddlers by the containing wiki. > > That would be an enhancement to the API as things stand. As it happens I > try to keep encryption and security components outside TW5 so that it is > possible to re-use proven, off-the-shelf implementations, but it's still an > interesting area to explore. > > > - Containing wikis can consolidate tiddlers from multiple wikis, and > display them as well. > > > - A wiki can choose to use an external wikis tiddlers through a pseudo > import process and the external wiki owns and can update them if permitted. > > > - One TiddlyWiki may host tiddlers on behalf of another wiki through > an encrypted exchange, but may even host tiddlers in an encrypted form > such > that the server Wiki cant even look inside the tiddler, just serve them. > - Other front ends could be designed to interrogate the tiddler > server, like display a single tiddler content etc... > > These are the sort of features that could be implemented by the server > side instance of TW5 invoking the API to talk to a different server. > > In this model there would be no contention for tiddlers, as the ownership > exchange process handles this however we could pass a tiddlers ownership to > a server, which can be set up to respond with actions to transform the > tiddler and return it or another back to the original owner. > > > Yes, this is exactly the sort of thing that would be interesting to > explore. As I say, none of this is really about TWX. TWX is about > revisiting design decisions that are too late to change in TW5. The classic > example is that in TWX I want to explore a slightly different data model > for tiddlers that unifies singleton fields with list fields. There's no way > we can change something as fundamental in the context of TW5. But there's > lots of other interesting experiments that can be done with TW5: we can > literally take it apart and rebuild it into multiple different things (as > the recent work on externalising the JS showed). > > Best wishes > > Jeremy > > > Regards > Tony > > -- > 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 [email protected] <javascript:>. > To post to this group, send email to [email protected] > <javascript:>. > 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/712f0a17-f1d4-4c94-8ddc-9789ab6593dd%40googlegroups.com > > <https://groups.google.com/d/msgid/tiddlywikidev/712f0a17-f1d4-4c94-8ddc-9789ab6593dd%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > > -- 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 [email protected]. To post to this group, send email to [email protected]. 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/7866c48a-0aaa-48a4-8e16-637b04812fc5%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
