theExpeditionarium Ideas as technology.

Immutability Hell

Among the immense promise of so-called “Web3.0” is that of a decentralized and “permanent” web, with the linchpin of either quality being something like finality. In other words would we cite the irreversibility of, say, transactions or contracts or, more generally, interactions, as well as the intractability of the information entailed as characteristic of this paradigm; implicit here is the immutability of the record of occurrence as well as consensus upon the preservation of such as the necessary criteria for the achievement of said finality. While all of this should undoubtedly prove integral to any concerted and consequential effort toward the decentralized infrastructure characteristically sought after under such a paradigm, it is also among its most intimidating when it comes to publishing challenging work or anything which might be construed as contentious, let alone anything personally revealing by means of that paradigm’s associated infrastructural ecosystem. (its network protocol or stack)

While this is a feature of great utility for ensuring posterity and resilience against censorship or any such loss of context, it may also, for good or ill, preserve in all likelihood a berth of mistakes and infractions or occurrences otherwise regrettable or damning. Again, this may be considered a feature in terms of preserving context (such as for a public grievance or exchange of any sort), but even in relative obscurity, it may come to seem as though an albatross around one’s neck in the very best of unfortunate cases, or else in the worst of cases as practically a death knell.

One might argue that denizens of the Internet at large have indeed proven in dire need of a rigorous course of discipline under the considerably less auspicious realm of permanence intrinsic to the new paradigm–a sort of social-engineering for the next epoch of digital interconnectivity. And while certainly on some levels might this school of hard knocks approach prove a necessary and even desirable shift to contend with, there are ways in which to alleviate the collateral damage of what I term immutability hell and sufficient reason to do so.

The Freedom to be Forgotten

This is a rather young and contentious concept, the so-called freedom to be forgotten1 but an important one to balance in consideration of maintaining individual autonomy upon a backdrop of persistent and pervasive transparency. In our own case, we are dealing with a matter of consensus in terms of common control over a common ledger (as opposed to public constraints over a private data hoard and the transmission of its particulars), but we should not underestimate the degree to which this consensus is come by in a passive yet, in equal measure, fickle manner; by which is meant that though the average user will care little about the particular nuances of the ruleset under which they participate, this should not be mistaken for authentic consent but, rather, a frivolous sort of trust, intrinsically precarious by the almost uniform heedlessness of its granting.2

This may sound strange or inappropriate: that users would allot trust in regard to what is so often fundamentally trustless infrastructure, but while such infrastructure operates and exists almost purely by mere consensus in practical terms, such infrastructure may live or die by the broadness of such consensus (its claim upon legitimacy3). Like all things, disintermediated and otherwise decentralized platforms and protocols alike are subject to market forces and, thus, success therein to stay aloft the oblivion of vaporware; this, at the very least, means a sufficiently active user-base, but it likely also means a reliable network on one or more levels. Without trust, marketability or, more accurately, any claim upon legitimacy suffers, regardless of any inherent or perceived level of trustlessness, which can never preclude or substitute for the desire and expectation of trustworthiness. This goes as much for adherence to standards both documented or inferred, even if some such inferences happen to contradict the documentation or intent of design.

Ironically enough, even one of the chief protocols endemically associated with the emerging paradigm of “web permanence” facilitates a hefty degree of impermanence by design: IPFS, for instance, practically automates the discarding of unsupported content, with nothing more than a unique hash to indicate any prior existence, if even any record of that hash were itself preserved. What we here encounter is a suggestion for just how to mercifully retire information which garners no attention (or else remains unsupported, under-served, or what have you) and hence serves no context. What then remains to discern is how such retirement might be facilitated without imposition.

Moderation and Iteration

Iteration, moderation, and, for that matter, self-moderation are all too often taken for granted in the intrinsically centralized commercial approach of “Web2.0,” epitomized most glaringly in the form of contemporary social media. The commercial viability of one approach over another can be as deterministic and trivial as “the customer is always right,” which usually results in the user wielding carte blanche privilege over editing and/or deletion and “damn all else.” But of course the “customer” is always some amalgamation of the userbase (itself some atomized aggregate), advertisers, and data-miners of whatever other sort, and nowhere is this commitment’s dynamics so clear as in the usual manner of such platforms’ usual wielding powers of moderation; this last point perhaps goes some ways to explain the apparent lack of ambivalence with which the foremost social media enterprises prosecute the matter of iteration and moderation.

Decentralized approaches, on the other hand, find little luxury in so easily abating such considerations to mere matters of profit and must ultimately reflect a general will in a way which mitigates unease as well as the sort of damage of the sort such platforms prove increasingly capable. For instance, how might one preserve context when either iteration or deletion might be levied toward its distortion? Or how might deletion be represented or even accomplished in the face of permanence (that of the swarm and/or the distributed ledger, say) if not at the expense of such context?

It would surely prove no trivial matter to resolve such in a way which does not sow confusion or violate trust. One approach, however, might be discerned by simply attempting to authenticate, in as unobstructed a manner as possible, the mess of social interactions which underlie their digital representation, rather than trying to pave them over, whether in the sense of a smoothing over or even as a veritable fossilization (or preserved as though in amber) or enshrinement of the history of such interactions. (immutability for its own sake)

“We live in a society.” (or “Hell is other people.”)

The manner in which we publish can either signal intent, or it can fail to do so. Carving an innocuous thought into a brick wall cannot but rob that thought of any such innocuousness, rendering it firmly a provocation in whatever regard. Were such an inscription to later be paved over or otherwise defaced for either the sake of re-inscription or simple redaction (or beautification, for that matter), the original provocation would either be abated (in the case that no new context had proceeded from its original inscription) or else deepened (in the case of its expunging or distorting whatever context had indeed emerged of the original). The question then most appropriately falls to the matter of dominion over that brick wall, particularly as a medium of public discourse to be managed as such if allowed to persist under whatever domain.

For whatever reason, the public (for lack of a better term) tends to inflict upon itself (or acquiesces to) certain limitations in exercising agency over whatever medium of discourse might be regarded (however erroneously) as outside its domain, despite the actuality of that discourse occurring precisely within the public domain (emergent in and of the general intellect, cultural memory, and so forth). Considering this might we imagine, let us say, a wall which is publicly owned and managed–designated for just such a purpose of inscribed discourse. How might the public manage such a thing? Who decides? Indeed might we ponder ceaselessly at what manner of arbitration be brought to bear in deciding just who is to be empowered toward the purpose of alteration and redaction and in what context, let alone any other manner of moderation which might strike the public’s fancy.

One thing seems certain: The less any resolution to such matters leans upon centralized intermediation, the more alike it might seem to an actual community of any sort–particularly one considerably less generally mediated. Let us consider a moment, for instance, just what sort of mediation occurs in the contemporary form of DLT. (Distributed Ledger Technology)

When something occurs on a typical blockchain, it is not simply permitted to occur in the sense of some vested authority or executor in effect acting as proxy in doing the deed, rather does it happen because it can happen–because it meets the criteria of having happened. Now clearly any such criteria, in order to be met, must needs make reference of the ledger hitherto and must itself be committed to that selfsame ledger in order to bear consequence. (i.e., to be referenced as having happened)

Interestingly, transactions facilitated by a blockchain and its respective network, take on many of the characteristics of a cash transaction with the innovations upon that manner of transaction including worldwide permeation and the lack of distinction between a transaction and its receipt. Nevertheless, the lack of any need for an intermediary means that such transactions bear similar counterparty risk, owed to their fundamental intractability, meaning that any discrepancies must be handled rather personally–a circumstance seldom seen among other manners of electronic payment. Yet, it is true that even personal disputes usually occur and resolve (or fail to do so) under communal context of some sort, and that context always augments such disputes–renders them more than personal–with each party in their own position beholden firstly to the community if at all to any entity.

Community can pose a hell unto itself, however, and so must it fall to any given community to mediate and mitigate its own hell that it might persist and thrive (thriving as itself a condition of persisting) as a community. Whether etched centrally as into brick, or inscribed widely into hot silicon, a community must find a way to persist in spite of its permanence–in spite of its perpetual casting of its own death masks–if that community is to remain living through its immortalization, rather than perish of it.

This is perhaps the very crux of our matter and why it would behoove any such community as might emerge under this new paradigm to contend seriously with the encroachment of immutability hell and to get in front it.

  1. Relating here generally to the underlying concept and implications of the “Right to be Forgotten” as it appears in the GDPR, though we do not here deal implicitly with the law or any specifically legal matters of inquiry.

  2. Relevant to this is a particular insight from a piece regarding the Byzantine Generalization Problem: “Blockchain technology claims to be trustless, in the sense that individuals don’t have to trust intermediaries or more powerful single actors in order to act and interact. The technical system off-loads authority onto a transparent and public consensus history, created and validated by the protocol and some of its users. The technical system could be considered a “trustless,” multiauthored actor in its own right, with the however unlikely and expensive scenario of its own validators’ collusion. “We don’t need to trust each other before we can begin to collaborate,” blockchain technology claims. Through the massively poor media reporting on blockchain, this claim can come to be misinterpreted, as today’s dominant connotation of trust suggests something interpersonal and chosen. The term “trustless” skims over that what may have been previously defined as “trust”—as in trusted institutions—and in many scenarios may not refer to voluntary, cultivated relationships but instead arise as a result of contingency and lack of alternatives. In this light, trust was the network effect of rumors around consolidation of power.” [emphasis added]

  3. Legitimacy is meant here with special emphasis upon Vitalik Buterin’s own sense of the term.

The Road to Decentralization pt.1

It is certainly a prejudice intrinsic to the project of rapidExpedition, or rExpd, to favor distributed and decentralized means of information dispersal and sourcing–in line as such with the general trajectory and perhaps the most virulent will and destiny of the Internet at large. However shy of that destiny we might have seen this beast to which we have collectively hitched our wagons veer in the interim, we’re bound and determined to take the damn thing by the horns and stake our claims by whatever means we may.

We could perhaps refer to these means collectively as hyper-participatory or at least as following protocols of such nature. Already does rExpd observe such protocols by its reliance upon git version control and explicitly in an open-source fashion, supported by what might be called a hyper-collaborative platform, GitHub, which acts as somewhat of a CMS for our purposes.

Some History

Now to explain why our use of these platforms, systems, and models qualifies as hyper-participatory rather than simply participatory, as most projects are in some respect, I will need to provide some context: This project began its life on a variety of wiki platforms and most appropriately settled on the most standardized such platform, MediaWiki, the chosen platform of the venerable Wikipedia project. Already it should become apparent that open collaboration is in the very DNA of rExpd.

However, though certainly there are efforts and projects aimed at backing up and replicating Wikipedia in some distributed and decentralized manner, it should be noted that these efforts are tertiary to any intrinsic feature of its platform, however much in accord with its underlying principles–really, amendments and fanfare of a static nature, more than a concerted and explicit effort toward decentralization4. This is in part due to the specialized dynamic design of the MediaWiki platform and its treatment of static content as almost circumstantial to its CMS-centric interface. In a sense, it’s no less of a walled garden for all of its efforts as a public treasure with its dedicated versioning and mark-up syntax and account management, especially considering the vast resources necessary to replicate a project like Wikipedia and its spin-offs in any functional fashion.

While a smaller project like our own might be orders of magnitude easier to replicate functionally, it would still be too resource intensive on a platform like MediaWiki to be considered in any way resilient or permanent, nor would it scale easily to serve a wide audience; as such did we require a lighter and more portable platform to meet this criteria–criteria which is perhaps essential to the very philosophy behind and espoused within the work of rExpd.

And so in comes git, GitHub, and Markdown to end what might have proved an endless vetting process of all MediaWiki alternatives (though certainly we forwent some notable stand-outs). But though as simple and elegant as this battery of solutions may be, there are some caveats to maintaining a degree of autonomy and portability on top of a centralized platform like GitHub, and those we will address later. Suffice to say that with these elements, we have achieved in near-totality our criteria of permanence and resilience toward something which might better qualify as hyper-participatory.

On Hyper-Participation

This warrants some further explanation beyond juxtaposing our project’s approach with similarly principled projects. We must return here to what we earlier termed, hyper-collaboration, in order get a better picture of what exactly hyper-participation entails.

GitHub fits the bill as hyper-collaborative in striking a balance between crowd-sourced and autonomous content management. This is accomplished by way of its primary mode of collaboration, forking. In this way, any contribution to any project may be volunteered publicly and permanently insofar as desired but also accepted or not at the sole discretion of the project originator. While this might begin to seem centralized with such discriminatory privilege allotted to a project’s originator, there is actually very little to prevent a project’s fork from taking up the mantle or a life all its own which might very well continue to intersect with the original at times or not at all.

This level of portability and collaboration goes deeper than the GitHub platform, as git itself facilitates most of the infrastructure necessary to handle this level of collaborative distribution on other platforms or even outside of any purpose-built platform at all.

However, it is important here to note that both, git and GitHub, were built more or less by coders and for coders, but it is fortunate perhaps that code is but a subset of text and also universally requires some amount of documentation to boot (and more yet than is typically in evidence). And by the dual blessings of character-encoding and hypertext markup standardization, we are able to take the same approach to documentation as to code–as well as to use code alongside documentation to shape the way in which one might interact with that text in a given context (i.e., via a web browser).

And yet none of this alone qualifies this project as hyper-participatory. The collaborative dimension is certainly off to a running start, but it is largely in how the content is served that we stumble into a potentially crippling dependence on centralized services (to the notable ire of Harry Tuttle). But in keeping the project as portable as possible, we reduce the chance of this to being practically negligible, and yet we keep striving for totality as a matter of principle, incidentally in-line with the specific statement of the work represented.

This brings us to what perhaps finally does qualify the project as hyper-participatory, and that is the very philosophy in and around it. More deeply than in rExpd, itself, we have a motivating ethos1 which includes some emphasis on the importance of infrastructure, industry, and culture in service to individual growth2. More specifically would we hold the reliability, efficiency, and resilience of those aspects as the rubric by which to determine their potential for such service. On all counts might we consider the decentralization and distribution of any such aspects as crucial for enhancement therein. And the work by which we explore all of this is no less intrinsically bound to such a rubric, being neither above or otherwise extraneous to its very analysis and assessment.

Now this is not to say that every project under rExpd and bearing the mark of its core principles would or should be so thoroughly hyper-participatory; instead, we might say that rExpd purports to provide an ever-more hyper-participatory wrapper around all else which might spring forth from it, at least in the outset of any such project, but with some confidence in how that lineage will resonate through the lifespan of any hypothetical outgrowth, ideally enhancing rExpd’s own ability to better fulfill its stated rubric.

Stepping Out

It was perhaps natural, given the trajectory of this project, that it register some pings with the blockchain and other novel decentralized protocols by proxy. Though however seemingly a natural fit, blockchain technology is yet without much precedence (yet with much promise) beyond the narrow scope of cryptocurrency, but one older piece of technology, BitTorrent, gives us a more flexible and better established means of true decentralization aptly termed as the swarm.

One service which has caught onto the potential of such decentralization is IPFS which, as it so happens, combines aspects of git and BitTorrent to create a distributed and decentralized standard which serves as an alternative to HTTP–in our own terms, a hyper-participatory hypermedia protocol; which is to say that one can publicly host files and serve them in tandem with the IPFS swarm and not only files but directories. This allows for the possibility of hosting websites as well as even git repositories, and in terms of the latter, much work is being done to make git work in a fully featured manner over IPFS3.

While other relevant and competitive projects with similar ends and features exist–one of which, Swarm, natively functions on the Ethereum blockchain (even currently compatible with a name service on that very blockchain)–IPFS seems to best fit the bill as a non-monetized, voluntary means of hosting and archiving hypermedia content (take a look at our own case-in-point). At any rate, it is our chosen onramp to the permanent web.

So far though, making a traditionally hosted static site available on IPFS (or any comparable protocol) is not such a straightforward feat, as it requires total relativization of all internal links and site-mapping. In any case, we’ve solved it for the time-being (again, as you can see in our first release) and will be posting a write-up on how and what’s next for improving upon our method. It’s a start, anyway.

Next Up

Some of this work will happen as a matter of course on theExpeditionarium, but most of the loftier work we will do in regard to this will begin more specifically on wayPoint where we will identify and target very specific needs. These needs will be simultaneously those of the project and those which from within the project we determine to be of general necessity or utility beyond its scope; indeed, if they do not prove to be so generalized, they should not be considered as necessary to the project, and that concept itself is a whole ‘nother can of worms which brings us closer yet to the core of what rapidExpedition is all about. That so just happens to warrant another article for another time, however. In the meantime, stay tuned for part two where we will discuss our use of IPFS and what we envision for it.

  1. Xenanthropy, the philsophy of new humanity, was the original concept behind rapidExpedition and still in development under the broader scope of its successor as well as remaining intrinsically at the heart of all ideas and efforts therein.
  2. In xenanthropic terms, Ultrahumanism is the manner in which the individual is joined to the whole by labor and more specifically by the manner in which, in one’s own labors, one vaults off of the labors of others past (building upon or utilizing them) or present (typically collaboration or cooperation of some kind). This is in contrast to Transhumanism, in which one reaps the benefits and internalizes the fruits of such labors for personal growth, and Superhumanism in which one employs and expresses that growth to its fullest extent–incidentally toward the ultrahumanistic.
  3. Some relevant efforts are detailed in the following links: git on IPFS and references, Mango: git Completely Decentralized. These don’t seem to include any explicitly collaborative interface, however, and so only replace a service like GitHub to a limited extent. Certainly a couple more items to keep an eye on would be IPVC and, perhaps to some extent relevant to IPVC, GVFS.
  4. There are, however, emerging examples of Wikipedia alternatives which seem at least quite promising: Everipedia and Lunyr, for instance.