The Lego Mirror - MediaWiki

Wikipedia’s 25th birthday proves the power of free speech

2026-01-15T17:00:00+00:00

Originally published on freedom.press

In the mid-1700s, Denis Diderot published his Encyclopédie in France, collecting the work of more than 140 authors to summarize the Enlightenment. It quickly landed on the Catholic Church's banned books list for including contrarian thoughts, and, at one point, his publisher preemptively censored some content without Diderot's knowledge.

Around the same time, King George III censored the first edition of Encyclopaedia Britannica, requiring the removal of some anatomically correct drawings in an article about midwifery.

So when the 13 newly independent American states ratified the First Amendment a few decades later, it laid the groundwork not only for a free press but also for an encyclopedia that was not censored by an oppressive government.

Today, we celebrate the realization of that dream in the form of Wikipedia, which over the past 25 years has been collaboratively built by unpaid strangers on the internet. Wikipedia went from the source that teachers universally clamored "you can't trust it" to one of the most reliable sources in a world of "disinformation" and AI-generated slop.

Despite not being written by professional journalists (I edit it myself as a volunteer and used to work for its nonprofit host, Wikimedia Foundation), it's still able to set trends and drive narratives. For example, in 2011, Wikipedia editors started collating a list of people killed by law enforcement in the U.S., three years before The Washington Post would win a Pulitzer for its version of the same.

And for better or worse, Wikipedia is most likely the largest single source powering today's AI models. All in all, it's the largest repository of knowledge in human history.

But it's important to understand and appreciate that Wikipedia only exists because of the robust free speech and free press protections that exist in the United States.

Wikipedia has never been actively censored in the U.S., nor has any U.S.-based editor ever been arrested for their edits to Wikipedia. There's never even been a serious threat of censorship of Wikipedia by the federal government. (The FBI once demanded Wikipedia stop using its seal under a law written to stop impersonation of federal agents; Wikipedia's legal team laughed it off.)

The same cannot be said about Wikipedia in other countries. In France, intelligence operatives held a Wikipedia administrator until he deleted an article about a military radio station, under the guise it contained classified information. Agents made this demand even though the information in question wasn't classified at all and was mostly based on a documentary that the French air force had worked on and publicly released.

In India, a court required Wikipedia to remove an article about a news agency because it was supposedly defamatory. To top it off, the court then demanded Wikipedia remove the separate article that was written about the court case and removal order!

This kind of censorship shouldn't happen in the U.S. The Supreme Court ruled the First Amendment protects publishing classified information in a case about the Pentagon Papers. A U.S. court cannot order an article to be taken down, as that would be an unconstitutional prior restraint.

In the U.S., the law known as Section 230 would also protect Wikipedia from defamation claims, and instead require litigants to sue the editor who actually wrote and published the allegedly defamatory content. Those editors would be protected under the First Amendment and the high court's New York Times v. Sullivan decision, which requires defamation claims from public officials — later expanded to public figures — to meet the much higher standard of actual malice to win (nearly every biography on Wikipedia is of a public figure, by policy).

And to state the obvious, the U.S. has never blocked all of Wikipedia, unlike China (since 2015), Myanmar (since 2021), or Turkey, which did so from 2017 until an appeal to the European Court of Human Rights forced that nation to unblock it in 2020. We know of one editor, Bassel Khartabil, who was executed for their online activity, and a few others who are incarcerated in Belarus and Saudi Arabia.

Certainly, there are plenty of people in power who wish they could censor or control Wikipedia. At first, it was through editing: In 2006, a number of Congressional staffers were caught whitewashing their bosses' biographies, and, in 2007, someone at the FBI tried to remove images from the Guantánamo Bay detention camp article.

Then, in 2013, Edward Snowden leaked that the National Security Agency was illegally spying on Wikipedia readers and editors, revealing that the U.S. had adopted the same playbook as China. Wikipedia responded by encrypting all connections using HTTPS a few years later, and (unsuccessfully) sued the NSA for First and Fourth amendment violations.

The attacks against Wikipedia are starting to ramp up once again; last year saw ethically compromised interim U.S. Attorney Ed Martin and Sen. Ted Cruz complain about Wikipedia's supposed left-wing bias, despite the First Amendment prohibiting the government from acting as speech police. We've also seen bits of the First Amendment firewall begin to crumble, with judges green-lighting prior restraints, or bipartisan groups of lawmakers working to repeal Section 230.

It will require a concerted effort by all of us to not just maintain existing First Amendment protections, but to expand them. That's the only way Wikipedia will thrive for another 25 years.

My 2024 Wikipedia editing

2025-01-24T03:08:00+00:00

I racked up 526 edits and created 8 new articles on the English Wikipedia over the past year. 2024 was a relatively quiet year for my editing (in 2023 I had 1,137 edits). I really tried to take the Marie Kondo aproach to it: I only edited if it sparked joy.

The eight article creations, plus one split, in chronological order:

While watching Michigan win the 2023 National Championship, I saw Bill Hancock appear on TV, so I created his article. (Easy guideline: if someone appears on a nationally televised sports broadcast, they're probably notable.)
I ressurrected the article on Project Maven, the Pentagon's project to use AI, etc. that multiple Google employees had walked out over back in 2018. I didn't write the text myself, I took it from the existing article on the Artificial intelligence arms race.
Created Wedding of Anant Ambani and Radhika Merchant, because it was basically on par with British royal weddings. (And then successfully defended it from deletion.)
Learned about Jeep ducking, which of course led to writing a Wikipedia article and obtaining an accompanying photo.
We went to the Montauk Point Lighthouse, which has a nice museum about itself and found there was a whole room dedicated to Giorgina Reid and no article for her.
I submitted this article to be featured on the main page's "did you know" section, to which it received rave reviews from my fellow editors.
Unfortunately I learned about Jack Limpert when he died. He's credited with shaping the "city magazine" format (another missing article I researched but still haven't written yet), but really I was more impressed that he succesfully figured out Deep Throat's identity as Mark Felt back in 1974.
There aren't very many dogs notable enough for articles, but Ben Herbstreit was one; I had known about him for a year now, but only realized he was notable after he died.
The tribute ESPN put together is one of the saddest videos you'll ever watch.
I saw a tweet claiming that China's 12345 hotline was a fantastic government service. I couldn't find any non-state media sources to back it up, but it was notable, similar to the US and Canada's 3-1-1.
Tanking is easily one of the worst parts about professional sports, so I was pretty excited when the PWHL adopted the Gold Plan.

Article writing#

I try to write about subjects I don't already know a bunch about. Doing so helps less of my personal bias and opinions slip in and helps reinforce Wikipedia being an amateur project. I'm far more likely to do a better job at solely summarizing what sources say if that's literally all I know about a subject.

Once I've found a subject, itt usually takes me around two to three hours to write an article from scratch. Most of the time is spent searching for and reading sources and then ~30 minutes to write it all up.

This may seem counterintuitive, but I try to ensure that all the articles I create are incomplete. I don't add infoboxes, categories, WikiProject banners, etc. I'll often leave links to sources that are useful but that I didn't include on the talk page, with editorial suggestions.

I think it's important that there are always easy ways for people to get involved with editing, and leaving "basic" elements of an article out provides an easy pathway. Along the same vein, I'll proofread the article once before saving, but if I spot a minor error afterwards (like, a grammar or spelling error, not a factual mistake), I'll just leave it.

For every new article I created this year, I wrote a short Mastodon post with a link (example), which did a decent job at getting my followers to improve them :)

I've primarily been helping out as an administrator at the Redirects for discussion process, which is perenially backlogged. I find it incredibly interesting because most of the subjects tend to be rather niche, with people trying to assess whether a redirect is useful for navigation or not, in addition to plenty of other factors.

Some fun examples: Bīn, Tighten, Asplode.

gerrit-grr 5.0

2024-08-19T00:00:00+00:00

I recently released 5.0.0 of my grr tool that makes working with Gerrit easier. It is an alternative to git-review; I personally think grr is more straightforward to use, but I also haven't used git-review since 2014 when I first got frustrated enough to create grr.

I had let it bitrot since I wasn't doing as much code review and it seemed like Wikimedia was going to move away from Gerrit but both of those have changed now!

There's no user-facing changes, it was just a lot of internal refactoring that required breaking API changes, and then removing that API entirely because it was blocking further refactoring. Rewriting grr in Rust was one of my first Rust projects and the code really showed that. It's now cleaned up and I also dropped all the dependencies that linked to C code (OpenSSL/libgit2) to make builds easier and more portable.

Fundamentally, grr is a small wrapper around Gerrit's native functionality. I don't think it's widely known that submitting a patch to Gerrit is as straightforward as git push origin HEAD:refs/for/<branch>. And if you want to set a custom topic, you can append %topic=<...>.

So that's exactly what grr executes; but much shorter. To submit a patch just run: grr. (If you need to push to the non-primary branch, use grr <branch>.) And to pull down a patch for review, run grr fetch <id>. There's some more commands documented in the README.

Going back to the %topic= example, grr provides a --topic <...> option that turns into that. If you want to immediately set a Code-Review +2 vote when uploading (e.g. to automatically trigger CI to merge), you can provide --code-review=+2 (turns into %l=Code-Review+2).

To install, run cargo install --locked gerrit-grr. Pre-built binaries and an OCI image are also available.

Building a less terrible URL shortener

2024-07-23T05:33:14+00:00

The demise of goo.gl is a good opportunity to write about how we built a less terrible URL shortener for Wikimedia projects: w.wiki. (I actually started writing this blog post in 2016 and never got back to it, oops.)

URL shorteners are generally a bad idea for a few main reasons:

They obfuscate the actual link destination, making it harder to figure out where a link will take you.
If they disappear or are shut down, the link is broken, even if the destination is fully functional.
They often collect extra tracking/analytics information.

But there are also legitimate reasons to want to shorten a URL, including use in printed media where it's easier for people to type a shorter URL. Or circumstances where there are restrictive character limits like tweets and IRC topics. The latter often affects non-ASCII languages even more when limits are measured in bytes instead of Unicode characters.

At the end of the day, there was still considerable demand for a URL shortener, so we figured we could provide one that was well, less terrible. Following a RfC, we adopted Tim's proposal, and a plan to avoid the aforementioned flaws:

Limit shortening to Wikimedia-controlled domains, so you have a general sense of where you'd end up. (Other generic URL shorteners are banned on Wikimedia sites because they bypass our domain-based spam blocking.)
Proactively provide dumps as a guarantee that if the service ever disappeared, people could still map URLs to their targets. You can find them on dumps.wikimedia.org and they're mirrored to the Internet Archive.
Intentionally avoid any extra tracking and metrics collection. It is still included in Wikimedia's general webrequest logs, but there is no dedicated, extra tracking for short URLs besides what every request gets.

Anyone can create short URLs for any approved domain, subject to some rate limits and anti-abuse mechanisms via a special page or the API.

All of this is open source and usable by any MediaWiki wiki by installing the UrlShortener extension. (Since this launched, additional functionality was added to use multiple character sets and generate QR codes.)

The dumps are nice for other purposes too, I use them to provide basic statistics on how many URLs have been shortened.

I still tend to have a mildly negative opinion about people using our URL shortner, but hey, it could be worse, at least they're not using goo.gl.

Making it easier for Toolforge tools to surface replag

2024-07-12T04:34:04+00:00

A number of tools hosted on Toolforge rely on the replicated MediaWiki databases, dubbed "Wiki Replicas".

Every so often these servers have replication lag, which affects the data returned as well as the performance of the queries. And when this happens, users get confused and start reporting bugs that aren't solvable.

This actually used to be way worse during the Toolserver era (sometimes replag would be on the scale of months!), and users were well educated to the potential problems. Most tools would display a banner if there was lag and there were even bots that would update an on-wiki template every hour.

A lot of these practices have been lost since the move to Toolforge since replag has been basically zero the whole time. Now that more database maintenance is happening (yay), replag is happening slightly more often.

So to make it easier for tool authors to display replag status to users with a minimal amount of effort, I've developed a new tool: replag-embed.toolforge.org

It provides an iframe that automatically displays a small banner if there's more than 30 seconds of lag and nothing otherwise.

As an example, as I write this, the current replag for commons.wikimedia.org looks like:

The replica database (s4) is currently lagged by 1762.9987 seconds (00:29:22), you may see outdated results or slowness. See the replag tool for more details.

Of course, you can use CSS to style it differently if you'd like.

I've integrated this into my Wiki streaks tool, where the banner appears/disappears depending on what wiki you select and whether it's lagged. The actual code required to do this was pretty simple.

replag-embed is written in Rust of course, (source code) and leverages in-memory caching to quickly serve responses.

Currently I'd consider this tool to be beta quality - I think it is promising and ready for other people to give it a try, but know there are probably some kinks that need to be worked out.

The Phabricator task tracking this work is T321640; comments there would be appreciated if you try it out.

#wikimedia-rust Matrix to IRC bridge is back

2024-06-19T20:11:08+00:00

tl;dr: You can now chat in #wikimedia-rust:matrix.org and reach folks on IRC

Nearly a year ago, the official Libera.Chat <-> Matrix bridge was shut down. There's a lot that went wrong in the technical and social operation of the bridge that the Libera.Chat staff have helpfully documented, but from a community management perspective the bridge, when it worked, was fantastic.

But, we now have a bridge back in place! Bridgebot is a deployment of matterbridge, which is primarily used in Wikimedia spaces for bridging IRC and Telegram, but it also speaks Matrix reasonably well.

Thanks to Bryan Davis for starting/maintaining the bridgebot project and Lucas Werkmeister for deploying the change; we now have a bot that relays comments between IRC and Matrix.

12:12:50 <wm-bb> [matrix] <legoktm> ooh, I think the Matrix bridging is working now
12:12:58 <legoktm> o/

And if you look at the view.matrix.org logs, those messages are there too.

So if you're interested in or working on Wikimedia-related things that are in Rust, please join us, in either IRC or Matrix or both :)

"Skip Mobile Wikipedia" add-on available on Android (again)

2023-12-27T05:42:30+00:00

In 2018 I announced the creation of my "Skip Mobile Wikipedia" Firefox add-on, which automatically redirects you to the desktop version of the site. At the time it worked on both standard desktop Firefox and in Firefox for Android, life was great.

Unfortunately at some point, Firefox stopped allowing arbitrary add-ons on Android and it was disabled. It was still usable in the "Nightly" edition, but that wasn't very user friendly.

Anyways, fast-forward to earlier this month, Firefox has re-enabled general add-on support, so "Skip Mobile Wikipedia" is installable and works again on Android. The source code is the same, I haven't had any need to update it since 2020.

I personally use the responsive Timeless skin, which I think provides a nicer viewing and editing experience from my phone. Happy browsing!

2023 Wikimedia Hackathon recap

2023-05-31T23:59:59+00:00

I had a wonderful time at the 2023 Wikimedia Hackthon in Athens, Greece, earlier this month. The best part was easily seeing old friends that I haven't met in person since probably 2018 and getting to hack and chat together. I also met a ton of new friends for the first time, even though we've been working together for multiple years at this point! I very much enjoy the remote, distributed nature of working in Wikimedia Tech, but it's also really nice to meet people in person.

This post is very scattered because that was my experience at the hackathon itself, just constantly running around, bumping into people.

I wrote that I wanted to work on: "mwbot-rs and Rust things, technical governance (open to nerd sniping)". I definitely did my fair share of Rust evangelism and had good discussions regarding technical governance (more on that another time). And some Mastodon evangelism and a bunch of sticker trading.

But before I got into hacking things, I tabulated and published the results of the 2022 Commons Picture of the Year contest, which I think turned out pretty well this year. Of course, the list of things to improve for next year keeps getting longer and longer (again, more on that in a future post).

At some point during conversation, I/we realized that the GWToolset extension was still deployed on Wikimedia Commons despite being, well, basically dead. It hadn't been used in over a year and last rites were administered back in November (literally, you have to look at the photos).

With a thumbs-up from extension-undeploying expert Zabe (and others), I undeployed it! There was a "fun" moment when the venue WiFi dropped so the scap output froze on my terminal, but I knew it sucessfully went through a few minutes later because of the IRC notification, phew. Anyways, RIP, end of an era.

And then Taavi deployed the RealMe extension, which allows wiki users to verify their Mastodon accounts and vice versa. But we went for dinner immediately after so Taavi wasn't even the first one to announce it, Raymond beat him to it! :-)

I spent a while rebasing a patch to bring EventStreams output to parity with the IRC feed that was first posted in April 2020 and got it merged (you're welcome Faidon ;)).

One of the last things I did before leaving was an interview about MediaWiki in the context of spinning up a new MediaWiki platform team (guess which one I am). At one point the question was "What is the single biggest pain point of working in MediaWiki?" Me: "can I have two?"

Reviewed a bunch of stuff:

Add Authorization to default $wgAllowedCorsHeaders - this is something 0xDeadbeef had asked for. Reedy, sitting next to us, verbally approved the security aspect, but since I had already packed away my laptop, I tried to +2 it from Lucas's only to discover he didn't have +2 on his volunteer account. Hence T337014. (And then I +2'd it later and Reedy did backports)
Define merge strategy for ContactConfig as array_plus_2d - me, crying about merge strategies again
Prepare CheckUser pagers for event table migration, Ensure last timestamp is shown when no matches found for an IP - it's nice sitting next to people because I can watch them demonstrate it working on their laptop instead of having to set it all up on mine :)
Add config to control default collapse state of CheckUserHelper - had a good discussion about avoiding (IMO) unnecessary config settings, and then I merged it :p
language: Annotate list() methods as preserving taintedness
Add 'preloadcontent' and 'editintro' in API prop=info - again, nice to sit next to people who have all the test cases ready to go

Probably the most important patch I wrote at the hackathon was to add MaxSem, Amir (Ladsgroup), TheDJ and Petr Pchelko to the primary MediaWiki authors list on Special:Version. <3

Despite having a bunch of wonderful people being there, it was also very apparent who wasn't there. We need more regional hackathons and after a bit of reassurance from Siebrand and Maarten, it became clear that we have enough Wikimedia Tech folks in New York City already, so uh, stay tuned for details about some future NYC-based hackathon and let me know if you're interested in helping!

Final thanks to the Wikimedia Foundation for giving me a scholarship to attend. I really can't wait until the next time I get to see everyone again.

Six months of Wikis World

2023-04-13T03:14:27+00:00

I did a lot of new, crazy things in 2022, but by far, the most unplanned and unexpected was running a social media server for my friends.

Somehow it has been six months since Taavi and I launched Wikis World, dubbed "a Mastodon server for wiki enthusiasts".

Given that milestone, it's time for me to come clean: I do not like microblogging. I don't like tweets nor toots nor most forms of character-limited posting. I'm a print journalist by training and mentality (there's a reason this blog has justified text!); I'd so much rather read your long-form blog posts and newsletters. I want all the nuance and detail that people leave out when microblogging.

But this seems to be the best option to beat corporate social media, so here I am, co-running a microblogging server. Not to mention that I'm attempting to co-run accounts for two projects I've basically dedicated the past decade of my life to: @MediaWiki and @Wikipedia.

Anyways, here are some assorted thoughts about running a Mastodon server.

Content moderation#

I feel like I have a good amount of "content moderation" experience from being a Wikipedia administrator and my conclusion is that I don't like it (what a trend, I promise there are actually things I like about this) and more importantly, I'm not very good at it. For the first few months I read literally every post on the Wikis World local timeline, analyzing to see whether it was okay or problematic. This was, unsurprisingly, incredibly unhealthy for me and once I realized how unhappy I was, I stopped doing it.

Especially once we added Lucas and now AntiComposite as additional moderators, I feel a lot more comfortable skimming the local timeline with the intent of actually seeing what people are posting, not pure moderation.

This is not to eschew proactive moderation (which is still important!), just that my approach was not working for me, and honestly, our members have demonstrated that they don't really need it. Which brings me to...

I've said in a few places that I wanted Wikis World to grow organically. I never really defined what un-organically was, but my rough idea was that we would build a community around/through Wikis World instead of just importing one from elsewhere. I don't think that ended up happening, but it was a bad goal and was never going to happen. We have slightly under 100 accounts, but it's not like all of us are talking to and with each other. Instead, I feel like I'm in a circle of ~5-15 people, largely Wikimedians active in tech areas, who regularly interact with each other, and half of those people host their account elsewhere. Plus the common thread bringing everyone together is wikis, which is already an existing community!

So far I'm pretty happy with how Wikis World has grown. I have a few ideas on how to reduce signup friction and automatically hand out invites, hopefully in the next few months.

It is incredibly empowering to exist in a social media space that is defined on my own terms (well, mostly). We are one of the few servers that defaults to a free Creative Commons license (hopefully not the only server). We have a culture that promotes free and open content over proprietary stuff. And when I encourage people to join the Fediverse, I know I'm bringing them to a space that respects them as individual human beings and won't deploy unethical dark patterns against them.

To me, that makes it all worth it. The fact that I'm also able to provide a service for my friends and other wiki folks is really just a bonus. Here's to six more months of Wikis World! :-)

Wikimedia Foundation layoffs

2023-04-05T10:00:00+00:00

The Wikimedia Foundation is currently going through layoffs, reducing headcount by about 5%. I am disappointed that no public announcement has been made, rather people are finding out through rumor and backchannels.

In February when I asked whether the WMF was planning layoffs at the "Conversation with the Trustees" event (see on YouTube), the response was that the WMF was anticipating a reduced budget, "slower growth", and that more information would be available in April. My understanding is that the fact ~5% layoffs would happen has been known since at least early March.

Consider the reaction to Mozilla's layoffs from a few years ago; the broader community set up the Mozilla Lifeboat, among other things to help find new jobs for people who were laid off. Who knows if such a thing would happen now given the current economy, but it absolutely won't happen if people don't even know about the layoffs in the first place.

Layoffs also greatly affect the broader Wikimedia volunteer community, whether it's directly in that staff you were working with are no longer employed at the WMF or a project you were contributing to or even depending on now has less resources.

I have much more to say about what the ideal size of the WMF is and how this process unfolded, but I'll save that for another time. For now, just thanks to the WMF staff, both current and past.