In February when English Wikipedia (and a few months later, all of Wikimedia) banned usage of archive.today (aka archive.is), there was a bit of a crisis in needing to find alternative archives.
For reasons, archive.today was especially good at archiving some difficult websites that weren't available in the Wayback Machine. I know a lot of people used it to bypass paywalls, and for related or unrelated reasons, there was an FBI investigation into the site.
Wikipedia editors have started discussing what a better solution to archiving webpages could be, with much of the discussion focusing on copyright.
As far as I know, no solution has actually materialized, so I thought I'd at least write down my idea. I am not actually planning to implement this, so feel free to steal this idea, my only ask is that you give it a hella sick name.
Unlike most other archives I know of, I would have users upload the archived content. By treating the archives as user-generated content, we get to take advantage of a number of legal protections, like Section 230 in the U.S.
Editors would install a browser extension that when asked, would capture a WARC (or similar) of the URL, and then upload it to the archive. It would be nice if there's some cryptographic way to verify the request wasn't tampered with (e.g. looking at the TLS connection?) but even without that, uploads would still be associated with specific editors, so if someone was caught falsifying, we'd be able to track it, just like you would deal with on Wikipedia.
This also conviently works around the drastic increase in scraper blockers that have started to lock down the internet by doing it in the user's browser. For some very dynamic content, we might also want to capture a screenshot, so if it relies on some complex JS or APIs, we can at least display what it looked like.
The biggest change would be that editors need to annotate specifically which part of the webpage is being cited. I think this is a good practice for citations in general.
But because we'd only publicly display the limited snippet, it would work around the archive being used to bypass paywalls. Displaying a limited amount greatly works in our favor for a fair use claim; to quote Wikipedia:
In general, the less that is used in relation to the whole, the more likely the use will be considered fair.
We'd need to develop some system to keep these snippets in sync with the on-wiki citations; I don't imagine it would be that complex to figure out.
While the snippets are sufficient for readers, editors might want to reference back to the full text for the purpose of expanding an article or just doing a more thorough fact check. I think we can still discourage the paywall bypass use-case by requiring editors to pay a small fee for access.
But instead of charging money, editors can pay with Wikipedia edits, e.g. 5 edits per URL. I think this would provide a small bit of friction that editors would only use it when they actually need it, but not enough to actually stop someone who genuinely needs access.
And of course if someone did choose to "game the system" to use it to bypass paywalls, they'd only be able to do so by actually contributing to Wikipedia, so... still a win.
I think it's quite difficult to launch a new site that accepts user-generated content, since you need to have a plan for content moderation. By building a Wikipedia-focused archive, we can piggyback on the existing Wikipedia community processes to help with this.
If you get blocked on Wikipedia, then you're blocked on the archive too. Have advanced administrator permissions on Wikipedia? We can automatically give you extra permissions on the archive. And so on.
I'm not sure if that would be sufficient long-term or just a temporary thing to help while it bootstraps and gets established.
I think the social and legal parts of this are far harder to get right; in comparison the technology seems pretty straightforward. I think it would be beneficial to have this be a separate LLC (i.e. not part of the Wikimedia Foundation) to isolate risk and allow for more flexibility.
While I think I've covered the primary legal bases, IANALY of course, it's entirely possible I've missed something. This is also a rather conservative proposal, and may have the consequence of shifting legal risk from the archive to individual users (though arguably that's how Wikipedia is already set up).
There are probably refinements to be made, or if you think I'm totally off, please, pitch your own proposal!
As part of Boba Quest 🧋, I'm trying and reviewing a new boba shop each week whenever I have time.
After nearly seven years of conducting boba reviews, I have built up a decent ability to predict if the boba will be good or not. I will always get a drink so I'm not merely judging a book by its cover, but it's rare that I'm surprised.
The Alley in Montreal genuinely surprised me with its excellent boba tea. From the very first sip, I could tell this wasn't merely good boba, it was fantastic.
(Admittedly, I mostly picked this place because the anonymous Montrealer had declared it the king of Montreal boba...so it's really on me for being shocked at how good it was.)
Just two blocks over from my previous review, The Alley is right next to the Green Line's Guy–Concordia station. There used to be a New York City location that opened in 2019, but best I can tell, it's since closed down.
Boba: 4/4 just perfection. Nicely sweet and exactly the correct chewiness. My first thought was that I had clearly forgotten how good boba could be and should probably downgrade some other places' scores.
Tea: 4/4 excellent; it melded smoothly with the boba without overpowering it.
Bonus: 1/1 the atmosphere in the store was really nice (there's even a tree inside!), I would've stuck around for longer if I had the time. I appreciated the deer iconography, I was initially quite impressed at how Canadian it all seemed (spoiler: it is not).
Total: 9/10. For those keeping track, The Alley is the fourth boba shop to earn a complete score. Whenever I'm next in Montreal, I'll make sure to visit again to see if it can earn the coveted tenth point for consistency.
About those deer...
The Alley is a Taiwanese chain, and the deer are also Taiwanese and endangered. TIL that Taiwan has deer; my sources tell me that they're even on the currency in Taiwan.
I'm slightly disappointed that the deer theme wasn't a Canadian thing, but I can't complain with boba this good. 🇨🇦
The next alpha version, 0.2, of my "do-the-work" Git repository viewer is now available; you can try it out on git.legoktm.com.
My previous post explained the rationale behind it; in short: this viewer is entirely client-side, which means it takes very minimal server resources to host. The clickbait version of this headline would call it scraper-proof.
You can obtain the newly rebranded "gib" 0.2 (aka git-in-browser) from git.legoktm.com. A signed build for WEBCAT (more on this later) can be downloaded from GitHub.
I've written up a mostly complete changelog, the highlights are:
Render markdown files and images
Support downloading snapshots (tarballs)
Support downloading patches of commits
Display git notes
Rewrite names and email addresses per .mailmap
Support blame
Potentially faster git log lookups
Options to control how a diff looks
It's still nowhere near feature completion, but a lot closer to cgit. There was a lot of internal refactoring and in general just testing to verify behavior is as close to git as possible.
There is a little bit of performance work in this release, such as support for commit-graph, but for a number of operations it's quite bad on what I'd consider to be a medium-sized repository. For a personal git host with mostly small projects, it's efficient enough!
I would like for 0.3 to spend a lot more time on performance.
Git uses a forked version of the xdiff algorithm for diffs, patches, blame, etc.; a standalone build is available as part of the libgit2 project.
Best I can tell, no one has actually done a 1:1 port to Rust. GitOxide uses a forked version of imara-diff (which AIUI is slightly different but pretty close), and there's a separate crate that statically links to xdiff.
Turns out it was relatively straightforward to compile the C code to WebAssembly, so I too punted on a Rust port. Never thought I'd be so happy to use C code instead of Rust.
WEBCAT is a project by Freedom of the Press Foundation (where I work!) to verify the integrity of in-browser, client-side applications to ensure they haven't been tampered with by the host. For example, CryptPad would sign their build, so you could be confident that the random hosting provider you're using hasn't tampered with it.
This is intended to be used by a future version of SecureDrop, so I wanted to get more familiar with it. In theory gib is fully compliant with what WEBCAT needs, but it's still a little buggy.
But if someone else did set up another gib instance, and properly registered the domain with WEBCAT, you could automatically verify they haven't tampered with it. There isn't that much practical advantage to doing so, since the hoster could merely tamper with the Git repositories themselves, but hey, it's cool!
gib is currently ~38k lines of code; probably 10% of it (and shrinking) was written by hand. I would've never been able to build something like this by myself in such a short amount of time.
I've largely used this as my "how far can I push LLMs" experimentation project; it's been interesting and just a little bit addicting. I think it certainly helps that I'm trying to reimplement well known functionality in a very different backend stack, rather than coming up with something novel.
I spot check the code and ocassionally tweak things by hand; I think the code quality is not terrible? The comments I missed rewriting/cleaning up are usually quite bad.
Nothing, most likely. I worked on gib solely during vacation time, and now that school is starting up again, I would expect the project to go on hiatus.
Machi Machi sits squarely between the Green Line's Guy–Concordia station and the Orange Line's Lucien-L'Allier station. For those not willing to make the trek up north just for some boba, there's also a location in Manhattan's Koreatown.
"Hello cutea. It's not just about a drink, but it's a way of life." Truer words have never been written on a boba cup.
Bonus: 0/1 she had wanted to give them half a point because of the cute cup and logo, but Boba Quest doesn't allow half points so she declined to give them a full bonus point.
Bonus: 0/1 agreed that it was nice but not exceptional.
Total: 7/10.
Just from walking around, the boba scene in Montreal looks far richer than I remember it being. Hopefully we'll have the opportunity to try a few more places before our boba vacation ends.
I've tried my best to use only free software as part of going back to school, and for the most part I've been pretty successful.
I picked up a new Framework 13 right before school started. I appreciate having USB-C charging options on both sides and being able to move the HDMI port to either side depending on the configuration of the room.
Really I just like the orange color scheme I picked out for myself.
I installed Fedora Silverblue on it; I'm a really big fan of the whole atomic OS concept, it works quite well. I've been able to use Flatpaks for nearly everything.
Firefox: not much to say here, it just works.
LibreOffice: I take all my notes in LibreOffice, which is good enough as it's mostly just bullet points and a few tables here and there. All of our writing assignments are required to be submitted in .docx format, so my final step on every assignment is to convert my .odt to Word format. I think, but am not actually sure, Word may have better support for formatting and managing citations than LibreOffice. Its on my todo list to see what it would extra functionality writing an extension would give me.
Signal: our cohort's main group chat is in Signal, and so is my study group's. It wasn't even a thing I had to push for, it was the default that others chose! The only downside is that a number of people have set their profile name to a single letter or gibberish, so I've slowly had to set nicknames for everyone.
draw.io: I really like using draw.io to make a diagram version of my study guide, and my friends were pretty impressed with how nice they looked. During my first semester I used the website, but I've now switched to the offline Electron version.
Nextcloud: I store all of my school work in a self-hosted Nextcloud instance. I tried using the flatpak version of the desktop client but it had enough issues that I went back to the RPM version, which integrates with Nautilus much better.
Kiwix: one of my professors had a rule that if we were going to use our laptops, we had to be offline. I found myself wanting access to a dictionary to look up latin and archaic terms, so I downloaded the latest ZIM of English Wiktionary and used Kiwix to access it in class while staying offline.
KeePassXC: for reasons that make zero sense, our login sessions on Brightspace (LMS) and other CUNY websites expire after an hour, which is far too short, so you have to keep logging in, over and over again. It would be pretty hard to design a system to get people to hate 2FA more than this one. KeePassXC (and other password managers to be clear) lets me store a TOTP seed in the database and generate codes. So logging in becomes a dance of: Ctrl+B (copy username), Alt+Tab, Ctrl+V, Tab, Alt+Tab, Ctrl+C (copy password), Alt+Tab, Ctrl+V, Enter, Ctrl+Tab, Ctrl+T (copy TOTP), Alt+Tab, Ctrl+V, Enter.
Thunderbird is unfortunately not on this list because my school uses Outlook and they restrict OAuth access so I can't get it to work. Using webmail is actually awful, I can't believe that people have to deal with this for all their other email.
At some point in high school we read the Odyssey, and I really enjoyed it. I did not like Christopher Nolan's version.
Rating: 4/10
It really felt like he had read all of the different scenes in the story, figured out how to film them and then just shipped it as a movie. Anytime you base a movie off an established book (or poem!), there's a higher bar to clear to make it an engaging story, which wasn't met here.
Emily Wilson's critique resonated with me a lot. I can think of no good reason why you wouldn't include the whole "no man" gambit with the cyclops (and the cyclops didn't even look like what I imagined cyclopses look like).
It's funny that my main critique of a three-hour film is that it felt abridged and didn't go into suffient detail. Should've been a trilogy.
