Platform: digital infrastructure that positions itself between users and acts as the ground upon which their activities occur. This positioning, therefore, gives platforms privileged access to record and analyze the activities of users and between users. [Srnicek, N. (2017). Platform capitalism. Cambridge, UK ; Polity.]
Self-platforming: personally hosting one or multiple free/libre, open, web-based applications as an alternative to privatized web-based tools that almost always extract value from people and their labor through surveillance capitalist practices like tracking and profiling. For a collection of examples, see this awesome-selfhosted list by Edward Dickson (Kickball).
I see self-platforming as an expression of my own digital citizenship, and I also see it as my deliberate answer to the call for digital sanctuary. The frequency and extent to which educators urge students onto extractive applications is of great concern. Self-platforming offers opportunities to benefit from the collaborative, hyper-textual, asynchronous, and distributed qualities of the web, while diminishing the costs — often hidden to us — of working on proprietary and extractive platforms.
In the same way all benefit from a Domain of One’s Own, we may all benefit from building and configuring self-hosted applications upon a platform of one’s own. Self-platforming may be best exercised by an instructor on behalf of students. Instructors often hold leverage over students with respect to web-based applications. Therefore, offering instructor-hosted alternatives to extractive web applications is ethically sound, considerate, and a generally more responsible course of action.
An clear example of an instructor-hosted alternative to an extractive platform is the deployment of a WordPress or Grav site for coursework and discussion instead of reliance upon a Facebook group. But there are honestly dozens of potential opportunities when one stops to evaluate nearly any academic workflow.
What I mean by an academic workflow, I’ll confess, isn’t even entirely clear to me. I tend to think of a start-to-finish process beginning with an idea and ending with some digital or tangible output (e.g., an infographic, a digital story, a paper map, a discussion board post or reply, an academic paper, a performance). I also recognize that a lot of scholarly work is iterative and therefore less easily represented by the concept of a workflow. An endeavor may fork, or may merge with another endeavor. When multiple outputs generate from a single genesis is that one workflow or multiple workflows? Please forgive in advance the imprecision of speaking about academic labor like this. Still, I feel it is helpful to atomize my own working across the web, and sharing across and among web-based platforms, in order to find my various points of dependence upon extractive technologies. This is especially important for experts who work within some gestalt of the web and may not be entirely aware any longer of the ways their tools are inter-connected, API’d, and sharing/collecting data.
An Example Academic Workflow
It’s better to work from examples. For illustration, here is how I might think about something I’ll call my ‘Hot Topic‘ workflow.
Imagine that I co-facilitate a class that relies upon current topics in news and entertainment to address issues of power, privilege, and difference. I’ll scan a lot during the week for potential dialogue starters in advance of a weekly class.
This Hot Topic workflow might look something like this:
Using my phone, I see an article shared on Twitter.
Scan the article quickly, and send it to Instapaper via my phone’s “activities”
While waiting in the checkout line later that day, open Instapaper, and read a bit more carefully.
Determine the article is very useful, and send it to Pinboard so I don’t lose track of it.
Two days later, sit down at my laptop to prepare for class. Pull up Pinboard in my web browser, read much more thoroughly, and select the best 2 from among many recently pinned articles tagged #hot-topics.
Use the bitl.y URL shortener for both selected articles as a courtesy to my students.
Post the hyperlinked bit.ly URLs for the readings on a Canvas page.
Send out an alert through Canvas informing students to check the readings before class.
In this example, much of the negotiation occurs across hosted web applications like Canvas, Twitter, Instapaper, and Pinboard. Some applications are licensed by my institution for the benefit of instructors and students. Others, like Pinboard, charge a one-time fee. Instapaper and bit.ly offer ‘Freemium’ accounts and additional functionality for paying customers. Twitter is ‘free’ but monetizes user attention by selling advertising and collecting user data that is utilized by Twitter and resold to 3rd parties.
Nearly all activity within my Hot Topic workflow is mine, by that I mean the instructor’s. Terms of Service, mostly, apply to these various web applications and me. Canvas and bit.ly are the two exceptions.
In the spirit of full disclosure, I admit to using bit.ly in the past. I think shortened URLs are convenient and often polite to offer at conferences, for instance. I appreciate this courtesy from others, especially when trying to type a URL on my phone. But I also think it worth recognizing that bit.ly makes no apologies for the fact that it offers no way for customers to delete shortened URLs they have made. This violates the principle of digital minimalism and a deliberate digital identity, at the very least. But worse still, it corrals students (or others) into a grouping they likely can never leave.
Let’s think for a moment about what is associated with a shortened URL on a platform like bit.ly’s. First, there is the digital item it references. In this case, an article. Second, through it’s service bit.ly can collect information about the referrer, in this case, Canvas. Third, because I’ve shared these shortened URLs with our class, bit.ly can build a social graph. We all share in common at least one thing — our interest in this link. There are several other things that can be gleaned through accessing this shortened URL, including: device type, browser type, quasi-locational data, time of day, and frequency of visits (if you click more than once). Through 3rd party tracking cookies, even more data can potentially be collected about myself and my students.
The single most important consideration here is this: students did not opt-in to use of bit.ly and as their instructor in the above scenario I never asked their consent. The Terms of Service are between bit.ly and me, not bit.ly and these students. Or conference attendees, or trail clean-up volunteers, or activists, or any other association of people clicking on a convenient shared point of interest.
I find the URL shortener to be very illustrative and helpful when talking about the choices instructors make, often unknowingly, on behalf of students all the time. Well-meaning and, in at least one respect, considerate choices made by an instructor to advance a pedagogical objective have unconsidered consequences where surveillance capitalism is concerned.
One answer within my immediate control is self-platformed alternatives. Within the Domain of One’s Own Installatron is an application call YOURLS: Your Own URL Shortener (https://yourls.org). It installs with one click, can live within a subdomain, and is really, really easy to administer and use. Of course, the point of a shortened URL is to be shorter. Acquiring a short domain name (I like name.com as a domain registrant) and dropping it on top of your DoOO makes a lot of sense, too.
I wish to provide a couple caveats: First, shortened URLs have been used to direct the unsuspecting to malicious content on the web. This is done by disguising the sketchiness of target with an innocuous-seeming short link. I wanted to establish a trust relationship with my shortened URLs, so I acquired a domain name very similar to my Twitter handle (@floatingtim). I’ve set up http://floatingt.im/ as my shortened URL domain, so if someone sees this shorter URL on Twitter or elsewhere, and knows about my Twitter handle, it will seem legitimate.
It warrants mentioning that YOURLS also collects minimal metadata on those accessing shortened URLs, but likely nothing to the extent of bit.ly or other similar services. Unlike other services, I can decide when I wish to delete a shortened URL, and whether to make use of the administrative metadata at all (I typically don’t look at it). Maintaining a URL shortener for myself and for use by those with whom I interact, means I can assure the minimum amount of data is collected, and can be disposed of as soon as possible.
Domain of One’s Own as a Platform of One’s Own
It’s possible for me to replace, without a great deal of effort, every web-based tool within the Hot Topic workflow except Twitter. There are a lot of folks out there exploring ways to avoid or greatly limit reliance upon the LMS in favor of WordPress or Grav, so that likely isn’t new ground. I’m pleased I managed to replace my Pinboard account with a self-hosted implementation of Shaarli. It’s not within Installatron’s options, but installation was as simple as unzipping Shaarli’s directories and following a few configuration instructions. I took some extra time to match Shaarli’s stylesheet to my blog’s, but that was mostly for the fun of it. Bringing Shaarli into my blog means I can share publicly many of my pinned links while keeping others private. Social bookmarking may seem like an outdated interest, but when the aim is to model scholarly behaviors and skills I think it deserves a place upon a scholarly platform of my own. I installed my bookmarking app within the subdomain of https://links.simulacrumbly.com so check it out. Or you can just click ‘Links’ in the menubar above.
I also replaced my dependence on Instapaper by installing Wallabag. I did this outside of cpanel using the Cloudron solution now being evaluated by Tim Owens and Jim Groom at Reclaim Hosting. A major motivation for replacing Instapaper is side-stepping the ad tracking and commodification of my reading habits by the Instapaper platform. But other motivations include the potential to model sound information literacy practices (scanning, clipping, culling, tagging, categorizing, etc.). Wallabag, like nearly all F/LOSS projects, invites feature enhancements by the community. Beyond feature enhancements, I am afforded the option to customize my instance of Wallabag as I wish. This could be hacking it’s data store or changing its look and feel.
We all construct our digital workflows. Some I’ve observed are really damn impressive and reveal a mastery of craft. Others are brutally inefficient and leave me hoping for an opening to offer some respectful alternative. And most are somewhere in the middle — good enough to get things done but likely not the fastest or cheapest or simplest or safest or most extensible. Periodically, I drift into “macro thinking” and dream of some IFTTT or Google Apps Script liberation. But these are cruel and fickle gods, and they profit from your labor, too. Instead, I see self-platforming as offering real possibilities for DIY while finding ways to work that are efficient and relatively free of web surveillance. Consider, the power of the hosted extractive platform is derived in great part by our dropping our data right on their doorstep. Contrarily, anyone who has ever tried to leverage cURL or wget, gone down a regex rabbit hole, or attempted to build a crawler or a scraper, knows that what makes these massive extractive platforms work is the free labor we, as users, provide to them while we stuff their databases with our behavioral traces. Self-platforming, if nothing else, will make surveilling my work across the web more expensive and labor-intensive for those who wish to do it.
In the coming months, I’d like to closely analyze my work and document several of these scholarly workflows. Next, I’d like to prioritize which platforms are the most egregious to use and support, either through analyzing their Terms of Service and Privacy Policies, or through other kinds of cost/benefit considerations. Next, I want to ask if using and promoting these tools impacts:
- only me,
- only me and professional colleagues,
- or me, my colleagues, AND STUDENTS
and based on this knowledge, prioritize self-platformed alternatives to anything students use or might use, like the URL shortener, for instance.
While I work, I will share what I learn along the way. I’ll be writing more about the installation and configuration of Shaarli, Miniflux, and Wallabag in future posts. If you are interested in working together, please reach out. I’d love to read your comments and learn your thoughts, too.
Photograph by Rachel Strum CC BY-NC-SA
1 thought on “Self-platforming, DoOO, and academic workflows”
Tim! Great stuff. I look forward to more. I’m definitely thinking about using Yoursl. I hope you’ll consider packaging all this up so that those of us who are less proficient. It would be really cool to “one-touch” set up your own self platform.