wednesday, august 15

it rained hard and fast late tuesday afternoon
long after midnight now, water drips off the needles of the trees
and rises off the streets in tracers of fog to
mingle with the haze of the fires burning further west
i can hear the old cat, muttering in his sleep on
a chair in the living room
a motorcycle on the otherwise-deserted highway
and the frogs in the trees across the street

:: p1k3 / 2018 / 8 / 15

Wednesday, August 1

some notebooks i have known and loved

The little tear-off notepads with the MoorMan’s Feed logo on them in the faux-leather vinyl covers that were everywhere when I was a kid, emblematic of a just-bygone era in corporate swag.
The spiral-bound-at-the-top diary calendars with ag co-op logos on which my grandmother kept decades of notes.
The half-full college student chemistry notebook, spiral bound, with little manila pockets and graph paper that I found in a curbside “FREE” pile in Boulder, and used to jot nerd ideas for years thereafter.
The blocky, softcover, trade-paperback-sized recycled-paper sketchbook that is the only place I ever really made any progress in learning to draw anything. I’ve sought its like in craft store art supply sections for the better part of 15 years now, to no avail. Google is no more help. It is that specimen of a consumer artifact which seems never to have existed, so far as the network is concerned.

:: p1k3 / 2018 / 8 / 1

Thursday, July 26

feed discovery and live bookmarks should not be removed from firefox

tl;dr: Mozilla are removing RSS feed discovery and display features from Firefox in an upcoming release. This is an unfortunate decision which will actively harm the open web, and should be reversed. It is also part of a larger pattern of unfortunate decisions by browser makers which contribute to a user-hostile network.

I am writing this post first in the hopes that it will be read by people at Mozilla, and secondly for users of Firefox who may not know about useful tools that they’re about to lose.

☆

RSS and Atom (usually referred to just as “RSS” because naming stuff is hard) are related standards for publishing feeds of stuff on the web so that users can subscribe to updates. If you see a little icon that looks like this:

…it’s usually a link to a feed. Feeds are just files that describe a set of entries along with publication dates and other metadata, and feedreader software can usually display the full text of entries, or link to them for reading in a browser. This works especially well for things like blogs or social media streams, but it’s also the technology underlying podcasts. There’s a standard for linking a web page to its corresponding feed, so that browsers can display a feed icon and you can click it to subscribe.

Firefox has had this feature for most of its existence, along with the ability to subscribe to feeds as “Live Bookmarks” that update with the contents of a feed.

Back in 2011 the feed subscription button was removed from the default set of toolbar buttons. As of this writing, you can add it back in by right-clicking the toolbar or clicking on the menu button (the three little lines towards the upper-righthand corner), clicking “Customize…”, and dragging the “Subscribe” button to the toolbar.

☆

That’s the casual background. Now I’ll try to lay out the substance of my belief that feeds should be a first-class citizen of the modern web, and that organizations like Mozilla should devote resources to supporting and improving the feed ecosystem.

Feeds are a direct channel of communication outside the control of silos like Facebook, Google, Twitter, and reddit. As such, they empower publishers to communicate and end-users read the web without the mediation of hostile algorithms and the imperatives of surveillance capitalism.
Though imperfect, the existing feed standards are stable, established technology with library support in nearly every major programming language. They offer straightforward publishing at a tiny fraction of the implementation overhead demanded by other tooling that modern browsers devote vast resources to supporting. They’re also accessible to anyone with the resources to configure a static site generator or a WordPress site.
Work like JSON Feed (and probably various microformats), though also obviously imperfect, suggests that there are paths forward for feed-like tech that map pretty well to the existing abstractions.
Unmediated syndication helps small businesses and independent publishers reach their customers without paying rent to social media platforms. It helps governments be more transparent, journalists more informed, and web platforms more open without paying heavy costs to integrate with manipulative, closed-source systems. It bolsters archiving and sharing of work across systems. It offers a clean alternative to spammy, personal-information-hoarding e-mail newsletter subscription lists.
Unmediated syndication helps users make their own choices about the attention economy instead of wading through the click-maximizing behavioral engineering that now dominates web platforms.
Accessibility: Feedreaders are now one of the few modes of consuming web publishing that don’t rely entirely on client-side JavaScript, which is a huge boon to people with any of low-end hardware, constrained bandwidth, or an entirely reasonable paranoia about running giant blobs of arbitrary code.
Feed discovery and live bookmarks are differentiating features at a time when Firefox’s userbase has massively declined relative to Chrome, a browser built by a monopoly corporation which first enclosed and then destroyed a substantial part of the web syndication infrastructure in pursuit of its own interests. (A browser built by a monopoly corporation which effectively controls a massive percentage of the client devices and operating systems, just in case anyone missed the 1990s the first time around.) Crudely put, following Chrome’s lead in pushing syndication entirely out of the browser to plugins removes a competitive advantage, while such advantages are in short and dwindling supply.
Moving this functionality to plugins isn’t satisfactory for the simple reason that visibility is everything and defaults matter. If people know that feeds are a going concern, a percentage of people will use feeds, and the internet will be better for it.

These are for the most part positive statements about feed-related features and what they offer. To briefly be more negative, I also want to address the reasoning laid out in the draft blog post linked in bug 1477667:

What’s more, these parts of Firefox aren’t offering features users want. Live bookmark doesn’t really have a concept of “read” state (it uses history visit state as a proxy, which doesn’t work for redirects), it doesn’t work well with sync, and arguably shouldn’t be part of our bookmarks implementation in the first place. It’s also not available on either Android or iOS and so has no mobile integration. Finally, podcasts are more successful than text-based feeds, but neither our feed viewer nor live bookmarks have good integration for them.

Usage data from Firefox shows that 99.9% of our users don’t actually use either the feed viewer or live bookmarks. Furthermore, the usage of feeds outside of Firefox doesn’t justify it, either - RSS/Atom has been slowly losing popularity, and various tools and companies have dropped support years ago (Apple Mail, Google Reader, …), stopped existing if they were focused on feeds (e.g. FeedDemon) or changed focus (e.g. NetVibes).

There’s a pattern at work here, and it’s one I find frustrating just about every time I encounter it as a user. (I’m also well aware I’ve been guilty of it myself in the past, but I’m mostly trying to do better.)

It doesn’t mean much for the purposes of evaluating these features that the data doesn’t show heavy usage, because they’re features that were deliberately obscured from the user population something like seven years ago. I would be surprised if more than a tiny fraction of the current userbase of Firefox is aware that they (still) exist. I was prompted to write this post itself by conversation with a technical professional who already uses feeds and 3rd-party feed discovery tools and didn’t know that they were already built into the browser.

Leaving that aside, argumentation from Google’s actions around Reader and their knock-on effects is essentially poisoned. RSS/Atom hasn’t simply been passively losing popularity; to the contrary it’s still remarkably popular given that it’s been so aggressively deprecated by a broad swath of industry powers whose commercial and structural interests run contrary to its purpose.

☆

I’m making an effort to write this in good faith. I have concerns about Mozilla’s funding model and the attendant (dis)incentives. I thoroughly despair, in general, about the fate and nature of the web as a whole. But none of those things override my sense that Mozilla is a good organization doing necessary work and staffed by well-intentioned people. I’m grateful for the work that goes into Firefox, and I’ll almost certainly keep using it for the foreseeable future.

I don’t believe there’s an anti-RSS/Atom conspiracy, as such. Nor do I necessarily think that feed discovery was deliberately hidden in Firefox with the conscious intent that once hidden its removal could eventually be justified when enough people had forgotten about it. Nevertheless, in the general case there’s a kind of broad emergent conspiracy, if you will, of industry consensus and action at work, and it manifests in small individual actions like this one.

Mozilla is the kind of organization with copy like “We’re the not-for-profit behind products, technologies and programs that make the internet healthier for everyone” prominently displayed on its home page. I don’t begrudge anyone the desire to simplify and improve legacy systems. I’ve written enough code by now to know that deleting the stuff is just about the happiest interaction a programmer can have with the stuff. Nevertheless, I’d ask you, a hypothetical Firefox developer reading this plaint, to consider that this really may not be a decision that makes the internet healthier.

Thanks.

firefox, panopticon, syndication, technical :: p1k3 / 2018 / 7 / 26

Sunday, June 24

code.p1k3.com

Here’s code.p1k3.com, which is (provisionally) where I’m planning to host my own projects from here on out. This was precipitated by the Microsoft-eating-GitHub thing, but now that I have it feels like something I should have set up a while ago.

For the moment, it’s running Gitea, a sort of GitHub-lite in terms of interface, which is written in Go and distributed as a single binary. This feels like a good piece of software in many ways, although some of the decisions to straightforwardly copy GitHub features feel kind of arbitrary. It’s talking to a local PostgreSQL instance, although it’s also capable of using SQLite. At the volume of traffic I’m likely to get, SQLite would probably be fine.

I decided to put Gitea in a subdirectory and write a minimal front page for the site, so as to avoid locking myself into one piece of third-party tooling. I’ll experiment with other ways to view the repositories stored there, and probably with other version control systems, like the SQLite-backed Fossil.

code.p1k3.com is a $5/month DigitalOcean droplet with a gig of memory and 25 gigs of storage, running Debian 9.4.

I’m using Nginx to serve the front page, and as a reverse proxy for the Gitea installation, with the following configuration:

server {
  root /var/www/html;

  # Add index.php to the list if you are using PHP
  index index.html index.htm index.nginx-debian.html;
  server_name code.p1k3.com; # managed by Certbot

  listen [::]:443 ssl ipv6only=on; # managed by Certbot
  listen 443 ssl; # managed by Certbot
  ssl_certificate /etc/letsencrypt/live/code.p1k3.com/fullchain.pem; # managed by Certbot
  ssl_certificate_key /etc/letsencrypt/live/code.p1k3.com/privkey.pem; # managed by Certbot
  include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
  ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot

  location / {
    ssi on;
  }

  location /gitea/ {
    proxy_pass http://localhost:3000/;
  }
}

server {
  if ($host = code.p1k3.com) {
    return 301 https://$host$request_uri;
  } # managed by Certbot

  listen 80 ;
  listen [::]:80 ;
  server_name code.p1k3.com;
  return 404; # managed by Certbot
}

You can see source for the front page in the p1k3 repo.

I used Let’s Encrypt / Certbot to get a certificate for the site (note all the # managed by Certbot comments above). I still have not set up a cron job to renew the cert.

For copying repos over from GitHub, I used Jonas Franz’s gitea-github-migrator, with a command like the following:

gitea-github-migrator migrate-all \
    --gh-user brennen \
    --gh-token $GH_TOKEN \
    --url https://code.p1k3.com/gitea/ \
    --token $GITEA_TOKEN \
    --owner 1

On GitHub, you can get an API token under Settings / Developer Settings / Personal access tokens, and on a Gitea installation under Your Settings / Applications.

I’m not sure whether I’m going to continue mirroring existing repos to GitHub or not. In terms of discoverability, archival resilience, and continuity for anyone who has something cloned from there, it makes sense. On the other hand, it continues lending force to GitHub’s near-monopoly. Maybe I’ll just add some disclaimers to READMEs.

Fortunately, no one actually uses any of my code, so it’s all kind of academic.

❀

The above is a pretty haphazard writeup, and it’s missing a bunch of detail about installing golang and configuring Gitea. As I refine the setup, I’ll try to document the whole thing more effectively in code, so that it can be mostly reproduced by running a script or something.

gitea, github, self-hosting, technical :: p1k3 / 2018 / 6 / 24

Wednesday, June 20

Dara Ann Klopfenstein — July 20, 1957 – June 13, 2018

:: p1k3 / 2018 / 6 / 20