photograph of stacked chocolate chip cookies

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:

a screenshot of an iPhone forwarding an article access within Twitter to the Instapaper app

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 URLs for the readings on a Canvas page.

Send out an alert through Canvas informing students to check the readings before class.

Shortened URLs

YOURLS administration area screen capture

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 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 are the two exceptions.

The privacy policies and terms of use for Canvas are negotiated at the institutional level by, likely, several administrative staff and among them likely a Chief Information Officer or equivalent role.’s, ToS and Privacy Policies, however, are almost certainly not.  This is tremendously important, I think.

In the spirit of full disclosure, I admit to using 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 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’s.  First, there is the digital item it references.  In this case, an article.  Second, through it’s service can collect information about the referrer, in this case, Canvas.  Third, because I’ve shared these shortened URLs with our class, 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 and as their instructor in the above scenario I never asked their consent.  The Terms of Service are between and me, not 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  (  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 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 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 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 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


Four years ago, I submitted a session proposal to a local THATCamp held at Lehigh University.  I had grown pretty enamored in 2012-2013 of Linode’s StackScripts and I was eager to talk with others about automated installation scripts for server ‘stacks’.  I knew they could be adapted and shared with other education technologists and librarians.  I’d seen it happening with hobbyists wanting to run their own Minecraft servers, for instance.  I’d used StackScripts for prototyping library web applications, and sharing what I know about web development with students and staff. Experiencing that, I really felt that these scripts could support broader use of open source platforms suitable for digital learning, librarianship, and digital humanities.  I also thought that the relatively recent emergence of cloud-hosted virtual servers with low costs and metered billing would permit exciting new uses for folks typically locked out by institutional risk aversion, limited staffing, general mistrust, or just plain disinterest of those holding the keys to the server kingdom.

My proposal is still available to read  and its central aim holds up fairly well.  It aligns closely with work I do now around Muhlenberg’s Domain of One’s Own.  In 2013, I was unaware of what awesome stuff was happening at University of Mary Washington through the work of Martha Burtis, Jim Groom, Tim Owens, and others as they originated Domain of One’s Own and found a solid solution to the same essential problem.  My proposal anticipated by a month or so the official release of Docker and the explosion of containerized applications on sites like Digital Ocean that make having your own server(s) easier and cheaper than ever.

Something else happened that day in 2013, too, and it’s really what I want to write about.  Looking back I blame the cheeky tone I take in my proposal announcement regarding campus IT security. I see now, in hindsight, how I was really asking for trouble.  But I’ll never know why my post brought mean spirited, unsought attention.  Just as THATCamp Lehigh Valley was gearing up, THATCamp’s severs were grinding to a halt.  When they came back online 30 minutes later, a hacking collective’s animated splash page pulsed and spun and taunted.  The whole conference website was brought down, and THATCamp (due to its unconference-like design) is particularly reliant upon its website to make the day work.

I felt really embarrassed and responsible.  I had suspicions it was my fault, but I couldn’t prove them.  I still can’t be entirely sure, but a comment posted to my proposal (since removed), erased most of my doubts.  And here is the worst part – because I felt responsible and began the day back on my heels, I was a terrible version of myself all day.  I did all the things I do when I feel insecure.  I spoke too loudly and beyond my knowledge.  I didn’t listen to what was being shared by others.  I stretched, I generalized, I assumed, and I tried too hard in all my interactions.  Because I felt responsible for the day’s poor start, for the embarrassment (real or perceived) of the event organizers, and all kinds of other stuff brought on by the hack, I think I acted like a big jerk.

Over the following weeks, I pretty much decided to take my professional life off the web.  I had maintained my own website for almost a decade (not a blog, but it functioned much like one), and I shut it down.  I also stopped maintaining my feed reader, and I flipped my public bookmarks on pinboard to entirely private.  My personal online life shifted fairly quickly and exclusively to social media platforms like Facebook which I locked down to a circle of well-known friends and family.  I was kinda done maintaining my own web presence, and with engaging strangers online.

Looking back, this was a significant turn. Since my high school days, I thought of the Internet primarily as a way to engage widely and deeply with folks I met there. From Citadel BBS and dial up, through undergrad usenet through IRC and the early web – online meant mixing it up, exploring, and making new acquaintances. It was in the same moment that I joined hosted, proprietary platforms like Facebook that I also began to limit my interactions online. My bad experience during THATCamp Lehigh Valley occurred right when I pivoted onto extractive platforms and toward a kind of insular online experience.

I am reversing those choices.  I’m reconsidered ‘where’ and how I wish to be online, and I see new reasons to move away from large social media platforms and toward my own, self-managed and personally maintained strand of the web.  More importantly, I feel a need to take accountability for myself online. There are things I believe it is very important to share, precisely because my de-platforming means others may access my shared content without fear of my exploiting or monetizing them as they do so. I see this renewed interest in working and sharing publicly as a way to counter robotized disinformation. Part of the new web I wish to engage is a web of trust, credibility, and accountability.

In future posts, I’ll walk through my sense of ‘right action’ as it pertains to working and being on the web, and why I feel it too important to sit it out as I have been. I’ll share what I discover, particularly when I can accomplish something useful upon the Domain of One’s Own platform. I am prioritizing those things I’ve done online that pertain to scholarly work and digital learning, but there may be other stuff, too.

I sincerely appreciate your taking interest in this. Comments are enabled, but I will review before publishing them. Feel free to reach out with questions or suggestions. Thank you!