Browserified Fedwiki

[jbenet]

I'm very interested in running Federated Wiki entirely as a front-end application inside of a browser. We can do this on top of IPFS, which gives us first-hand content versioning and distribution. This requires some adaptation of some parts of the information flows, and expectations, but i think it would be a very valuable thing to do.

Benefits:

• federated wiki becomes totally distributed, decoupled from physical locations
• anyone can try running a fed wiki node with just one click
• fedwiki could work offline
• easier to operate a fedwiki node
• easier to use fedwiki to build other applications
• p2p sharing of resource loads

Key challenges;

• understanding how the data model would look on top of ipfs instead of at a specific location (i.e. are there any location-specific addresses (i suspect lots of URLs) and which could be changed)
• understanding how authentication + identity would be managed (i suspect pub/private key pairs)
• adapting server + client code to these
• browserifying a lot of the code from the server

Questions I have:

• What URL schemes are followed?
• What are all types of content addressed?

We have described the url scheme in other issues. We've prepared a simplified version for federating foreign servers

• When does a host's domain come into play?

Pages are rendered from the page json alone. We remember where that was retrieved in order to display a flag (favicon) and the sitemap to be added to the neighborhood. The source could be a domain name or the symbols 'origin', 'local', 'view'. In some cases null is used as a synonym for 'view' which means to choose 'origin' or 'local' as appropriate.

• How is identity defined right now?
• Who (precisely) gets to create/edit pages on a given host?

We treat domain names as identities. Convention has the welcome-visitors page further identify the owner as that owner sees fit. We distinguish between sites, servers and hosts. The site is responsible for authenticating and authorizing users which has been delegated to the server. We have a 'claim' process where a new site learns of the credentials its owner will use for authentication. There is currently a project underway to provide modular authentication.

• Is there interest in allowing users to sign their edits?

Yes. We would expect a page be signed at multiple points in its history by multiple authors, each of which can be verified by a well known, independent and public trust network.

Notes:

• there is a way to use DNS domains with IPFS, so that we don't need to change URL formats much, if at all. just the "host" might be virtual, instead of an actual server listening.

I would suggest we just start outlining the stuff for the data model + auth/identity first. We're working on some changes to ipfs at the moment which will make it waaaay easier to just use JSON natively to build arbitrary data structures (at that point importing a fed wiki datastructure might be as trivial as storing all the json.

[davidar]

Who (precisely) gets to create/edit pages on a given host?

Possibly relevant: ipfs/notes#40

[WardCunningham]

Wiki is both a browser and an editor.

As a browser, wiki does not expect to find a traditional address in a link. Rather, the link refers to a title (reduced to a slug) that admits multiple realizations. The browser then choose a preferred realization from available information and presents it, along with some alternatives, to the user. The lineup display removes some tedium from the process of probing for the most desirable alternative. The probing and judging process creates selective pressure on editors.

As an editor, wiki enables aggressive modification to found content. Items can be freely reorganized and this new organization returned to the federation as original work with appropriate attribution. This attribution is included within the title to become more evidence enabling future browsing to have more choices.

Wiki as currently implemented supports two storage mediums, server and browser. The server form expects a server to offer a version of the client code suitable for editing content stored on that server once the user of that server has proven that they are the one owner of that content to the server's satisfaction. The browser form does not require proof of ownership. The browser form supports the same aggressive refactoring from many sources but does not share any of this back to the federation.

We have seen successful integrations of additional storage mediums with different models for sharing, specifically NDN, but this code did not make it back into the primary codebase because it sacrificed full interoperability with the existing federation. We found no roadblocks to this integration other than the coding time to do it.

Note that browser storage piggybacks on server storage because the latter is the only storage that supports federation. One question is, should the IPFS federation piggyback on the current server federation or should it be its own IPFS only federation with its own selection of editing options for reorganization and corresponding attribution and discovery mechanisms.

I hope this helps define the problem ahead of us.

[WardCunningham]

I have suggested a layered architecture for the core client's interaction with storage based on our experience with NDN integration.

http://ward.fed.wiki.org/three-layer-storage.html

At level three IPFS would be just one more way of storing pages. We would expect level two to understand the unique properties of IPFS in order to express sound policies for its use in a mixed storage architecture. The expression of policy could become complex if all of browser, server, NDN and IPFS were simultaneously available.

Mastering policy complexity will require accumulation of experience. When I read the final paragraphs of the architectural note I feel that we are today much more experienced than when it was written 11 months ago. Be encouraged.

[almereyda]

@opn currently approaches the issue by versioning the data directory of federated wiki within a git repository and projecting the latter into the IPFS namespace, from there republished via IPNS to make the raw data available permanently to arbitrary consumers.

[almereyda]

Thanks to @paul90 we have another example of a broswer wiki via dat, as documented in https://paul90-dat-wiki.hashbase.io/federated-wiki-on-dat.html