Could gh host TW for multi user?

[Mat]

Is this even hypothetically possible with the current version of gh:

To host a TW on gh, i.e in the way so it is presented as a usable wiki (not as merely files), and multiple users can have user rights to make contributions (i.e modifications) directly to it... but there's also some way to restore stuff if misused?

...and to have a native TW gh saver - the existing one or another - be what "uploads" the modification?

...from a single file vanilla TW?

I.e the goal would be that someone can put up a TW and other users (with enough rights) can really use any TW with the right saver to upload stuff to it. Conflicts magically handled by gh. And the other users are NOT familiar with gh other than that they have registered as a user there.

<:-)

[PMario]

On Tuesday, July 14, 2020 at 6:19:16 PM UTC+2, Mat wrote:

Is this even hypothetically possible with the current version of gh:

 

I think, there could be a workflow, that would allow several users to contribute to 1 "master" TW.

 

To host a TW on gh, i.e in the way so it is presented as a usable wiki (not as merely files), and multiple users can have user rights to make contributions (i.e modifications) directly to it... but there's also some way to restore stuff if misused?

GitHub is designed that you create your own "fork" from the master repo. You modify this fork and create a pull request. ... This allows the "owner(s)" of the "master wiki", to prevent "misuse". ... IMO it would need a similar workflow.

 

...and to have a native TW gh saver - the existing one or another - be what "uploads" the modification?

That should be possible.

 

...from a single file vanilla TW?

Should be possible too.

 

I.e the goal would be that someone can put up a TW and other users (with enough rights) can really use any TW with the right saver to upload stuff to it.

As I wrote. Contributors have to work from their own fork. Merging is done by the master

 

Conflicts magically handled by gh.

That's not possible atm. Conflicts have to be resolved by contributors.

 

And the other users are NOT familiar with gh other than that they have registered as a user there.

This would mean, that TW would have to be a "full blown" Git-client with a lot of "magic". ... I'm not sure if we want to go that route.

-mario

[Mat]

Thanks for replying PMario.

This would mean, that TW would have to be a "full blown" Git-client with a lot of "magic". ... I'm not sure if we want to go that route.

Why?

My main point was if it is possible to eliminate the need for the user to face gh - other than possibly the initiator/owner of the repo (but ideally not even that person). For example, the steps currently required for making PRs for the TW docs (as opposed to code) is "too much gh" for what I'm asking about.

It would not be a problem that a "full blown Git-client" has a lot of magic because the intended user (i.e the vast majority of TW users) would not need to understand nor fiddle with the internals of it anyway. The user is reasonably presumed to be interested in TW and the collaboration project he takes part in, nothing else.

<:-)

[Jed Carty]

Magically taking care of conflicts is going to be the big sticking point.

We may be able to do something like you are describing that lets you see the conflicts and handle them manually with a reasonable interface, but that is a very significant project by itself.

[Mat]

Jed Carty wrote:

Magically taking care of conflicts is going to be the big sticking point.

But not if the repo owner handles it right? (Just so I don't misunderstand).

Does gh otherwise have a 'conflict handler' or does it fully rely on manual handling for this?

We may be able to do something like you are describing that lets you see the conflicts and handle them manually with a reasonable interface, but that is a very significant project by itself.

Yes, but it would open up a LOT of possibilities for the community and also outside of it.

<:-)

[Jed Carty]

I think that something like twederation would be a much easier thing and a lot of the work is already done.

[Mat]

Jed Carty wrote:

I think that something like twederation would be a much easier thing and a lot of the work is already done.

Forgive me, but what is the status with twederation? 

<:-)

[TonyM]

Mat,

I  relation to collaborative tiddlywikis

I have considered this a serious problem since TW5 never dealt with it, although there are options like bob and federation they do not extend to the single file wiki which can be served anywhere. The server solutions also quickly become fragile for people without the background knowledge, skill or experience with various aspects of the technology outside standard tiddlywiki.

I have remained focused as a superuser, not solving problems via external knowledge or JavaScript intentionally.  This allows me to understand the scope of design possibilities within tiddlywiki rather than going outside it to git hub, or node commands etc.

The positive view

I believe there is a way already using the tiddlywiki core and possibly a few tweaks that can be done at the application level of tiddlywiki. An example would be saving a users changes into a separate file that can be overlayed onto the core wiki, with an "owner" (checked out) who can merge either with intentional review or automatically. On top of a per tiddler saver like node this would be easy to also save users tiddlers in a separate namespace and use them to change control the source of truth.

There are as yet un-simplified possibilities discussed here and there, from libraries to content pull methods. 

The not positive view

I love the opportunities node gives us but it fails in one very particular way, it is not an internet ready server of folder wikis. True Jed is at the leading edge on this but their remains complexity and technical issues for everyday user. This is one reason I use folder wikis internally, and single file wikis externally. An example would be an Apache tiddlywiki, php server which are readily available everywhere, alternatively if it was easy to host docker packages one could be built that users customise. Amazon is another platform on Which Jeremy has succeeded in delivering a large amount of information but Its not clear the level of collaboration available an even as an IT Professional this implementation assumes a lot of subject area specific knowledge that makes it a long journey for me.

Also

• I think TW federation may be a solution if it can be unshackled from the Node Server?
• I find it difficult to understand the underlying principals and possibilities of TW Federation (My bad)
• I also agree that GitHub is not suited to serving more than file based wikis (except for developer collaboration) and thus not an open collaborative platform, especially given its need for subject specific knowledge.
  

I am happy to be corrected or "shown the light" but this is my current understanding and I am fairly well informed.

Regards

Tony

[Jed Carty]

TWederation works between single file wikis without node or anything else, and it has been functional for something like two years.

So tiddlywiki has had federation between wikis without a server for years.

It works but aside from some interest Mat there has been practically no interest in building anything with it.

[TonyM]

Jed,

If I may speak plainly. I have tried to use TW Federation, and I blame myself, but I have found it hard to uncover how it works and how to use it. I can try again but not sure I can find the time unless I can be confident I can find my way.

I think a lot of people like the idea and value your work on this, not least some of the key team members. 

What I do know of TW Federation it sounds like a great tool. I suggest any apparent lack of interest you perceive, is more a lack of confidence in making use of it. 

I myself tried to understand it but did not get far enough to help others, I think TT/Johsua got more involved. You deserve help and support promoting it, but people must understand it to promote it. You need to help us dumb-asses get started and the community will run with it.

Perhaps many have not realised how revolutionary it can be 

Yours sincerely

TW Tones.

[Jed Carty]

People not speaking plainly has been one of the biggest hurdles to making things people ask for in tiddlywiki, so yes, please show respect for both me and you and our time and speak plainly.

I made a new gitlab page for the federation core, it has all the same documentation and the same example in it. I am not sure what else to put.

https://ooktech-tw.gitlab.io/plugins/federationcore/

[TonyM]

Jed,

Thanks, I will put some concerted effort into it.

I am getting some certificate errors of something on your link, however the documentation looks simple and easy to understand, but perhaps that is because I understand more.

Recently there was a thread, I believe you were in, the subject was libraries and I know you publish one. Perhaps given the library is structured and separate files of tiddlers, aka plugins, could we publish a library and TW Federation (or another tool) could also pull tiddlers from the library? This would allow the versions to be used to determine updates and provide an interface into the library only the user has chosen to publish. The advantage being a smaller file size as well.

I believe a number of the savers can now let an export filename be set or zip files to be generated that could also simplify library generation. Similar to recent improvements in exporting static sites.

Non the less TW Federation offers a more direct and generic solution in many ways.

Thank you.

Tony

[Jed Carty]

In an attempt to be 'useful' google for some reason made the target of that link something other than the link that I pasted into the message.

This is the link that you should use, and I guess yay google?

https://ooktech-tw.gitlab.io/plugins/federationcore/

[Mat]

Jed Carty wrote:

TWederation works between single file wikis without node or anything else, and it has been functional for something like two years.

OK, I assumed you were referring to the system you continued with after the single file version. But yes, the original TWederation system could probably cover a lot of what the OP in this thread brings up. If I recall, there are a few less-than-optimal aspects - please correct if I mis-remember anything:

1) A https hosted wiki will not fetch from a http hosted wiki, which for a normal collaboration projects would mean "everyone use http XOR https".

2) Both the fetching and the serving side need the plugin installed. This means all parts have to intentionally participate, which is a natural thing in a collaboration project - but it does mean that single individuals have "no" use for it because ain't nobody to call. (This is probably a strong reason why there isn't much interest in it.)

3) Fetching fairly quickly became slow as more collaborators (i.e wikis) joined. This might be because a general "fetch", fetched from all collaborators. 

For a small collaboration project this may still be useful.

Regarding (2) - was is at all possible to remove this condition, i.e so that one can fetch from any wiki without it having the plugin? That way one could subscribe to wikis and just use a filter so check if anything is new.

<:-)

[Mat]

To put it totally plainly:

@Jed, if possible, could you please make is so that only the fetching side is required to have the plugin?

<:-)

[Jed Carty]

iframe sandboxing makes having only the pulling side need the plugin at best a very difficult task and quite likely impossible given browser restrictions.

All of the restrictions you mention, aside from some parts of the https one, are also present in any solution involving GitHub collaboration.

To make the equivalent thing to what you describe each participant just needs to fetch from whoever has the administrator role. the admin would have to fetch from each contributor wiki but if that becomes an issue the admin wiki gets a node backend like Bob that can handle the workload better than a browser. A back-end for the admin would also handle the problems with http vs https as long as the admin was on a server with https.

All in all you are giving more restrictions to what would be an acceptable in-house tiddlywiki solution than you are to a GitHub-based solution.

[Mat]

Jed Carty wrote:

To make the equivalent thing to what you describe each participant just needs to fetch from whoever has the administrator role. the admin would have to fetch from each contributor wiki but if that becomes an issue the admin wiki gets a node backend like Bob that can handle the workload better than a browser.

Could an admin host a Bob on gh?

And could this be set up to handle fetching automatically? E.g at timed intervals?

...and...

 

A back-end for the admin would also handle the problems with http vs https as long as the admin was on a server with https.

...so it could fetch from tiddlyspots? (http) 

<:-)

[Jed Carty]

Unless GitHub had added new features I don't know about no, it couldn't be hosted on GitHub. What would GitHub add in this instance? it is just another moving part to handle.

The backend could do whatever you want it to do, so yes you could do timed fetches.

And yes, that is what I meant when I said that having the back-end server would take care of https-vs-http 

[Mat]

So, the admin-host-wiki has to be updated manually if TWederation is to work on GitHub. As we know this doesn't work very well.

And the admin-host-wiki can be updated automatically if TWederation is hosted on another service. Could work IF there is such a service.

Jed, you've generously offered your Ooktec server to the community for TW projects previously, even if I'm not aware of anyone picking up on it. Does this still stand? (Fully understandable if it doesn't. It would also be understandable if you said you needed to charge for it, even if involving money has side effects of course, or any other condition.)

<:-)

[TonyM]

Mat et al

You make the point that unless we have someone to call it does not serve much use, but it would be trivial if single file wikis can provide this service, that we could build a nascent network. Starting a loose network starts with a single node. Of course initially we will have a test network or node.

I have started experimenting, but getting some errors.

I believe I understand where you are coming from, are you hoping to ensure openness and connectivity? Are you looking for a Tiddlyverse network?

If I recall correctly Jed's original example and vision was a peer to peer or networked messaging platform and this is a valuable and serious application of TW Federation, personally my priority is first to enable my own controlled wikis to intercommunicate, then perhaps publish content through subscription service and later build a more open and generic network. I have always felt this part of the lack of progress with TW Federation, is we are not taking the intermediate steps first, Although Jed has enabled this.

As Jed put mixing Https and http could be a hard security restriction, I can not only live with it, but think it an important limitation and similarly on the need for a client/server component. If my site is https I would not want someone pulling content out of it in clear text http. If I have http site anyone can pull it in clear text. Https can only work if both nodes participate in it.I also like the idea that unless I install the server component I have not made the ability to "query and extract" my wikis content open to a more programmatic extraction process (although it is easy to achieve by other means). I am not saying that we can't allow a generic non plugin way to access tiddlywiki, only that it can be defeated, some wikis I may not want to leak.

I believe approaching the "Tiddlyverse network" is a logical or configuration standards problem not a technical one. Basically publishing "that a particular content type is available at particular endpoint" and listing in, or managing a directory etc... is a matter of "policy and practice". The idea would be to develop some defacto standards that on adoption may one day be dejure standards, is the way to go with larger networks. I want to build the internet, not facebook (if that makes sense).

My idea her is, lets get the "pull" mechanism working (by this I mean establishing practices, examples and further how to's and some defacto standards), then two nodes pulling from each other, like imagine I pull standard messages from your wiki and it tells me you have blog posts I can pull from your wiki, then I pull them and republish them? Then we look at a central exchange wiki for a/each network and the journey continues. A step at a time.

Not unlike my suggestion about libraries being a mechanism I see value in letting a wiki publish a subset of its content for consumption by other wikis rather than needing to load the whole wiki (efficiency) and arguably being able to pull anything from the wiki (selective publishing).  The advantage of a separate file or folder is I can apply access security to each published content feed allowing private as well as public interchanges.

With the http/https issue it may be possible to build a server that can act as a gateway between the two protocols where http and https sites can exchange tiddlers. Making clear to https users that the later leg will not be https.

Regards

Tony

[TonyM]

Reply Script

I just want to add, if a single file wiki, can be configured to save selected tiddlers externally on the same server (I believe it can) a user may make changes on a wiki that are saved to a user changes file, which can be subscribed to by the wiki, we may have a foundation for multi-user single file wikis. It makes sense to do this with federation as well.

Regards

Tony

[Jed Carty]

My vision had nothing to do with a federated messaging platform, that was the simplest application we could built that was immediately understandable. So we made it and it works, but we only had 4 or 5 people who were actually interested in it which isn't enough to sustain it so it has been sitting unused for the past few years.

My original use for it was to get content from other wikis on my computer so I could do things like searching other wikis and sharing content between my own wikis.

That is not at all what I said about http vs https, and that is not how either works. The server that provides the information determines the level of security, so http vs https, the requesting node makes very little difference. Otherwise a browser would not be able to access both http and https sites. Everything with TWederation is done in the browser.

The security restriction is that if you have a page hosted on a server using https you can not make requests to pages that are served using http. If you are on a page being served by http you can make requests to https sites with no trouble.

and what you describe in your standards thing is a nice description of what twederation is and how the network works. It isn't a description of things to come, it is where we are.

For your suggestion about making subsets available for easier consumption, you are describing exactly what a plugin library does. Which we can do, but it requires more than just a single file on a static file server to accomplish.

And to be clear, your second post about getting tiddlers from the same server, is exactly the point of twederation and the first application of it that I gave when I released it years ago.

So what you describe, about a multi-user wiki with single file wikis, was always the point and was achieved years ago.

This is what has been so frustrating for me with this, over half of the suggestions I get for features are features that already exist or I get requests to extend it that describe exactly what it currently does. And that is more aggravation that I want to deal with in my life.