Implementing Liquid Wiki

Holochain provides seemingly an extremely well matched paradigm for the storage of Federated Wiki content. * Federated Wiki behaviour is managed by the browser. * Most behaviour is implemented as client side plugins that are loaded as JSON on page load * Some plugins have serverside components, that are ajax'd by the browser. The server side components are loaded as npm modules into the node server * Transporters are services which run in processes external to the main Node.js process, that are also accessed by REST through ajax calls. * all page edits and forks are stored inside the page's JSON object. This should be ... openned slightly into the Holochain paradigm, and this process is deeply addative to the existing Federated Wiki paradigm, and both fit nicely into each other. (see the (very) draft Entry specifications below) ### High level implementation structure * retain the current node.js/express server for fedwiki, and all the various tools it provides. * extend/alter the express server such that content provenance is managed by Holochain in some way (see the Wiki Page Entry below). * early implementations would hold all the holochain nodes inside one container running on a DO droplet, each node representing some FedWiki site. Creating a new wiki site would push through a request to the Holochain Pre-Incubator, which would create a new Holochain Agent ID, register ports with the OS, and return that data to some intermediary service that can managed interfacing with the Holochain Node rest API's of each Agent/FedWiki site ## Entry Types to back Federated Wiki ### Wiki Page Entry * Monolithic json blob for entire page? * OR each page is an anchor with some fixed hash, onto which the various json objects that make up a wiki page are are added, updated and deleted. * OR some infrastructure where only hashes are stored on holochain, and *all* content is stored on IPFS ### Edit Entry * a public entry that allows interested parties to determine if edits have taken place to pieces of content. ### Fork Transaction Entry * a two party transaction which provides guaranteed provenance of forked wiki content ### Assets assets are large files or sometimes whole applications images and such are loaded into the wiki dom applications are loaded into a separate browser tab at "arms length" * Seems to me that actually the holochain backend wont be aware of the various asset storage specifications, as it is managed by other server side services. * For example, IPFS assets will require that the IPFS local server has hashed and stored the file, and returned that hash to the client, so that the client can display it. That IPFS hash will then be inside some JSON blob.

# Front End Development ## Asset Upload * Front and or back end need to rewrite the `asset/` URL when the IPFS service has completed its journey of hashingtons