Critical Futures

Critical Futures is a domain that I bought a few years ago in hopes of starting an original (science)fiction blog. I loved the name, and thought that really, given the way publishing was going, and the way I was expecting to develop my career/etc. at the time, it seemed foolish to not start some sort of fiction project. It turns out that what I had in mind wasn't the right for that moment, but I've (of course) kept the domain name, and I'm interested in using it to do awesome, valuable, good things in the world.

The Present

So CF is sort of, a ?CyborgInstitute like project only for fiction. I suppose, except, it's much more ad hoc, less formal, and more experimental. The main CF-proper project that's even beginning to take form is a wiki. I got in touch with the project-leader of this, via ?ikiwiki, and one thing lead to another, and there you have it. There are other potential projects brewing.

This space should be a node to discuss and plan CriticalFutures projects, and a place to discuss the cyborg-underpinnings of CriticalFutures projects. Because it's there.

Colaborative Wikis and Fiction

This is probably the best place to start, from in the context of the wiki itself, from ?brush

?VersionControl is a tool that programmers mostly take fore-granted, but something that I'm incredibly fascinated with as a writer, and creator of content. Like ?wikis themselves, they serve--largely, I'd posit--to destablize traditional methods of authorship. Particularly in the case of ?git (but in other systems as well) they make it possible to take a work, lets call it a "?text," and create diverging branches at a given point in the history of a text. They make it possible to merge and combine these branches--either into the centralized "master" or into other branches. Not only does this destroy the ?SupremacyOfTheAuthor but it destabilizes the notion of ?LinearProductionOfTexts.

There are a lot of very practical reasons for git's specific feature set, given the distributed and highly collaborative way that programmers tend to collaborate--particularly in open source projects. I have definitely been entranced by the "RadicalPossibilities" of creating written texts using git and this ?DistributedMethdology.

One of these aims of the Critical Future's wiki project, as outlined by ?brush, is to "port" some of these techniques and capabilities to a new way of working with and thinking from the world of computing to the world of texts.

This section of the Cyborg Institute Wiki will contain discussion of these ideas, some thoughts regarding the technological implementation of the future of the Critical Futures Wiki Project. Feel free to split up and move the content around in this section/page as you see fit.

?ProjectGoals

Insert more content here, including goals, intentions design ideas.

?TextualGitWorkFlows

One of the strengths of git, in my mind, is that while it's very flexible and powerful, in practice people use git as a tool to implement a specific workflow that only uses a subset of the possible functionality of git, and there are some features (like remote branches) that don't see a lot of practical applications in the wild. Unlike, say, ?subversion, git, has no "opinions," regarding workflow or the "right way to manage" repositories and workflow.

So while git is capable of a great many things, it's often much better to figure out how you want to work and then figure out a way to allow git to enable this workflow, rather than working backwards from git. This is, I think, a larger problem when you're new to git and everything about it is new and complicated and difficult, and has also been a challenge for me, given that I'm mostly storing text in git.

Text also creates some additional challenges with regards to storing text. Since code is often broken apart into short lines, it's quite easy for git to automatically merge differences between divergent branches of this file. When line length gets longer, and words move about from one line to the next, merges are often much more difficult, and require some manual interference.

Ikiwiki, is sort of a hack built on-top of git--a good hack, but a hack, none the less--so that while there's pretty good support for the "standard workflow," of a wiki, this uses only a small subset of what git is capable of. Ikiwiki itself is largely version-control-system agnostic, so while git may be the theoretically "preferred" version control option, there's nothing that ikiwiki can do with git that it can't do with subversion (svn.) For the most part. There is some additional flexibility you get on the remote end, that you have as a result of using git, but for the most part, the repository that ikiwiki builds from is just a self-updating directory of the file system.

?IkiwikiLimititaions

I actually don't think any of the issues listed below are "show stoppers," but I think having a more firm understanding of how ikiwiki works, and what it's good for, particularly as we work on the technological possibilities.

• Ikiwiki, the program, and the wrappers, have no real concept of whats going on inside of git. So while they're might be multiple git branches, representing more than version or iteration of a text, Ikiwiki doesn't (and, can't really) know about this.

• Indeed, to follow up on this, "remote" branches are something of a bother in git. Though my dataset on this is far from exhaustive, the peculiar mapping of local branches that track remote branches and are then published, is somewhat strange. It's my sense--and this is backed up by the way that services like Git Hub work--that while developers might use git branches locally to test things, as soon as they want to publish something they either merge it into master, or they publish it as a separate repository on their own infrastructure (or infrastructure to which they have access).

• Ikiwiki's wrappers have to write files to the file system, which is going to--at some point--be a limitation in terms of speed. If we want a branched wiki and one "srcdir," I think we're going to run into trouble with ikiwiki regeneration lagging while the wrappers check out the right version of the wiki and then regenerate based on that. This would also present a problem for the editing of files via the web-interface, what if two people wanted to edit in two branches of the wiki concurrently? Also, as I think the main place where we'd need to do the hacking to get this kind of functionality are in the wrappers, there's a lot of security thought as.

  Git is fast, much faster than any other version control system I'm familiar with, but given the fact that we'd need to rely on large file-system operations I'm quite worried about the viability of this many wikis in one repository "design."

?FederationPosibilities

The other option, as near as I can tell, is to have many wikis. There would be many different (and separate instances of wiki,) perhaps all tracking a remote branch, using the same templates, base-config file, but having distinct "SRC directories" (shallow clones?)

This is, I think technologically workable from the file-system issue noted above. While I think there's a limit to how much we can legitimately administer "by hand," (which does put a damper on the amount of branching and separate additions that can happen,) this lets us scale more organically. When one administrator/server team is managing their limit, another person can begin to host more branches. This effectively turns the potentially difficult technological problem above into a human-resources problem. And I think we can address most of the human resources problem by automating human-centered tasks, rather than writing clever software. Mostly, becasue I don't have a lot of faith in my ability to write clever software.

The web, like git, is after all an intensely distributed system. Allowing the "federation" of wikis works with the way that git "wants" to work, and is I think an ideal way to convey freedom is to allow for forking and promote federation. I think there are more arguments that others might be able to submit ?InFavorOfFederation.

I am, however of course worried about the administration and I have the following concerns:

• Each site would need a few things: a srcdir, a config file, an editor, a DNS record (for sub-sub-domains and subdomains). We wouldn't (want to) allow users to be able to create these things on their own without approval, but we would probably want to automate the creation of these things on our end.

  • I'd like to avoid giving distinct bare repositories for each wiki branch, but the git post-update hook will be branch specific, so I'm not sure how to get this to work without breaking publish-on-push.

• We'd need to figure out a way--in the presentation layer--to render links to "this page on other wiki instances," which might require some coordination on how to deal with pages that don't exist in some wikis but do in others. I'm fine having them lead to "create this page," but that's going to be some special configuration mojo.

  Having said that, this would allow each iteration of the wiki to choose (mostly, I think) which wikis existed in their list of "collaborating wikis"

• We'd need to figure out a secure and safe way to promote other people to take on some of the administration burden, over time. How to mentor new sys-admins, etc. How to share our config files without exposing security holes (I think this ought to be fine,) and so forth.

More technicalities

Based on some IRC discussions, there are some potential ways to integrate some of these approaches. The general schema -- yet to be worked out in specific detail -- would involve a single repo, with each of the branches in the repo working off its own directory, which would be a srcdir for ikiwiki. (This may or may not involve multiple ikiwiki "instances", ie. config files.)

In other words, the directory structure would look like:

webroot ->

• -> branch1 -> index -> subdirs a,b,c
• -> branch2 -> index -> subdirs a,c,d
• -> branch3 -> index -> subdirs c,d,e

etc. each wiki srcdir would be the "index" level, which would be the location of the main pages, etc. that ikiwiki is maintaining and updating. however, depending on which branch in the hierarchy is being worked under, the gitweb backend would use that branch of the repo to store files.

Keeping things in one repo makes merging easier -- which is key from the perspective that these various branches are interconnected and mutually updating (based on editor's preference) variants of a single project.

Next steps: talking with other developers (esp. Joey with ikiwiki) to explore implementation details.

Related Ideas

• ?RightToFork TODO get link from ?CommunityWikiPage

• ?EditorsPublishersAndAuthors TODO figure out what I meant when I inserted this page link.

These ideas are all incredibly rough and would benefit from some additional thought. Please if you have anything to offer, do edit as you can. I'll try to be present here as time permits. -- tychoish

Discussion

Based on some IRC discussions, there are some potential ways to integrate some of these approaches. The general schema -- yet to be worked out in specific detail -- would involve a single repo, with each of the branches in the repo working off its own directory, which would be a srcdir for ikiwiki. (This may or may not involve multiple ikiwiki "instances", ie. config files.)

In other words, the directory structure would look like:

webroot ->

• -> branch1 -> index -> subdirs a,b,c
• -> branch2 -> index -> subdirs a,c,d
• -> branch3 -> index -> subdirs c,d,e

etc. each wiki srcdir would be the "index" level, which would be the location of the main pages, etc. that ikiwiki is maintaining and updating. however, depending on which branch in the hierarchy is being worked under, the gitweb backend would use that branch of the repo to store files.

Keeping things in one repo makes merging easier -- which is key from the perspective that these various branches are interconnected and mutually updating (based on editor's preference) variants of a single project.

Next steps: talking with other developers (esp. Joey with ikiwiki) to explore implementation details.