Hidden node problem

[almereyda]

Scenario

1. I'm running a federated wiki on a local network with a private domain. jon.wiki.lab.
2. This wiki cannot be forked by internet wikis, as they don't see it, neither on DNS nor via IP.
3. Thus I have a hidden node problem.

Possible solution

Mesh networking protocols (like OLSR or Batman) are using relay nodes to distribute data, that cannot reach it's target without additional routing. I'm imagining the client, being a wiki engine itself, to play the relay node and proxy the transmission of the content, i.e. by just creating a new page and uploading the journal from the local storage instead.

The error handling and notificationof the server should then be a little more resilient, though.

[almereyda]

If one takes the federation aspect thoroughly, secure (TLS, SPDY) authentication/authorization (OpenID Connect, WebID) of background tasks of that like might become a topic, too.

[WardCunningham]

We currently support "forking" a page from local storage to the origin server. This is handy when you forget to log into your origin server and end up with edits in local storage by mistake.

I would like to provide similar functionality for forking a remote page into the origin server without requiring visibility of the remote server from the origin. This is a departure from the status quo. We currently send the fork action to the origin server and expect it to retrieve the full json for the page from the remote, server to server. This breaks down when trying to "export" a page from a private server to a public server.

I was working very close to this code recently. The choice of approaches comes down to one if-statement in wiki-client lib/legacy.coffee where the fork-button is handled. github

The server bound payloads are very distinct in these two cases. Both send actions, but in one the whole page is sent as an "item" while the other case just sends the domain name of the remote site.

We GET pages but PUT actions. This is probably premature optimization on my part. There is a low numbered issue here where @SvenDowideit asked if we couldn't make the protocol more RESTful. I've only slowly come to understand the wisdom of his request.

[paul90]

That issue you are thinking of is #42

Thinking about that example. Another possible solution is if you are only ever intending to write to your local private copy. Then the public facing copy could be a static view. Advantage it would only need a dumb server, populated with the content the client expects (pre-rendered html, raw page json, sitemap, etc…) BUT the current URL presents a issue as with the client rewriting it, it does not point directly to something. See #412

[WardCunningham]

Wow. The quality of advice given and ignored in #42 is scary.

[WardCunningham]

@almereyda Thanks for the reminder. This issue has been long solved.