Code Tour: 2024-12-01 to 2026-02-25

[silveradept]

Oh, hi, everybody! It's been a little bit since we did a code tour, hasn't it? But never fear, we're here to walk you through the changes that have happened since the last time we took a tour through the code changes in Dreamwidth.

Let's dive in, shall we?

Have we mentioned lately we love our users?

Issue 3428: update site footer for 2025
Description: Good Godfrey, another year gone, which means we need to update the years on things like the copyright notice.

Issue 3399: set up December points bonus (pull request) and Issue 3457: set up December shop bonus for Dec 2025 (pull request)
Patch by: kareila
Description: Every December, your money nets you 10% more in Dreamwidth points. This requires some manual tweaks to get set up in time, because many of our users appreciate having the bonus while it runs.

Issue 3421: Since the DW shop has its own domain, reserve it as a username. (pull request)
Patch by: pauamma
Description: Now that the shop is on its own domain, that means you can't make a user named shop. That would be bad.

Software Updates

Issue 678: Bump js-yaml from 4.1.0 to 4.1.1 in /api (pull request)
Patch by: dependabot
Description: Wherever possible, we try to keep Dreamwidth code running on the latest version we can support.

Issue 2856: Support Ubuntu 20.04 and MySQL 8 (pull request)
Patch by: zorkian
Description: We'd actually prefer it if Dreamwidth servers could run on a relatively recent version of the underlying operating system and database software. Being a few revisions behind is okay, but we'd rather not be several major versions behind if we can avoid it.

Issue 3356: WIP: Jquery update (pull request)
Patch by: momijizukamori
Description: Wherever possible, we try to keep Dreamwidth code running on the latest version we can support.

Issue 3422: pin Crypt::SSLeay (required by Net::SSL) at version 0.58 (pull request)
Patch by: kareila
Description: …of course, sometimes that means we have to pin software and prevent it from updating because some other piece of software needs that version or won't work with the newest version yet.

Issue 3488: Mark/remove textcaptcha (pull request)
Patch by: zorkian
Description: We used to use textcaptcha as our CAPTCHA service, but it appears that textcaptcha is no more, and so we have to get rid of it from the codebase.

Issue 3493: Basic Config for Github Codespace (pull request)
Patch by: zorkian
Description: Create a basic setup of a Github Codespace which enables folks to run tests with a nifty little automatically managed and set up Codespace on Github. This only runs basic tests as yet because it doesn't support database/apache...

Issue 3494: Remove Procnotify references and related code (pull request)
Patch by: zorkian
Description: Remove older "Procnotify" system which we hadn't been keeping updated and doesn't really serve much purpose in production right now.

Issue 3510: TheSchwartz deprecation [1 of 4] (pull request)
Patch by: zorkian
Description: This migrates some low-risk workers to the new SQS based TaskQueue infrastructure, and yes, 1 of 4.

Issue 3512: Plack Support (pull request)
Patch by: zorkian
Description: This fairly chunky PR makes more than a few changes that enable us to serve the site from inside of something called Plack. Put another way: we can get rid of Apache?!? Perhaps??! Well we'll see. That significantly simplifies development and also lets us start to simplify a bunch of code as soon as we're happy with it. This big PR also enhances what is called the "devcontainer" so that it is fully-featured, supporting memcached and MySQL, letting you fully work on Dreamwidth from within a container. On your Mac, your Windows PC, you name it.

(Oooh, containerized Dreamhacking? That'll make a lot of people happier.)

Issue 3514: Add mysql-client to dependencies-system. (pull request)
Patch by: jjbarr
Description: We need MySQL everywhere, and therefore, instead of pulling it in repeatedly when we're working with containers, we'll do it once instead.

Issue 3520: Remove legacy TheSchwartz ESN workers and ESN_OVER_SQS tunable (pull request)
Patch by: zorkian
Description: Dreamwidth's Event-Subscription-Notification (ESN)system — the thing that sends you emails and inbox notifications when someone comments on your entry, etc. — used to have two parallel paths for processing events: an older one based on TheSchwartz job queue, and a newer one based on SQS. We've been running 100% on the new path for a while now, so this removes the old one entirely along with the 10 worker scripts that powered it. Nothing changes from a user perspective; notifications keep working exactly as before.

Building a strong Foundation

Issue 966: Convert birthdays.tt to use Foundation
Patch by:
Description: Another victory in the continual effort to move our BML material to Foundation!

Issue 3320: Convert /manage/profile to Foundation/TT (pull request)
Patch by: momijizukamori
Description: Another victory in the continual effort to move our BML material to Foundation and/or Template Toolkit!

Issue 3217: Subscribe interface (pull request)
Patch by: kareila
Description: More modernization and removal of BML from the code! Hooray!

Issue 3400: Convert /polls to TT (pull request)
Patch by: momijizukamori
Description: Another victory in the continual effort to move our BML material to Foundation and/or Template Toolkit!

Issue 3408: Convert login (pull request)
Patch by: momijizukamori
Description: Another victory in the continual effort to move our BML material to Foundation and/or Template Toolkit!, this time with the side-bonus of cutting down on the number of different codepaths we had to handle logins (which has the bonus of unblocking future work around login options)

Issue 3418: Add Foundation to a bunch of TT pages missing it (pull request)
Patch by: momijizukamori
Description: Adding Foundation to pages that were already on Template Toolkit.

Issue 3412: some minor whitespace adjustments to converted shop pages (pull request)
Patch by: kareila
Description: We notice, too, when things just don't look right, and so we make adjustments so that it does look right.

Issue 3497: Convert miscellaneous Talk pages to TT (pull request)
Patch by: momijizukamori
Description: Another victory in the continual effort to move our BML material to Foundation and/or Template Toolkit!

Issue 3498: Convert ThemeChooser to TT (pull request)
Patch by: momijizukamori
Description: Another victory in the continual effort to move our BML material to Foundation and/or Template Toolkit!

Issue 3500: Convert misc widgets to TT (pull request)
Patch by: momijizukamori
Description: Another victory in the continual effort to move our BML material to Foundation and/or Template Toolkit!

Issue 3501: Foundationize assorted pages (pull request)
Patch by: momijizukamori
Description: Another victory in the continual effort to move our BML material to Foundation and/or Template Toolkit!

Patchwork, Quilting, and Bitchin' Stitching

Issue 2560: Manage Entries page shows raw HTML (pull request)
Patch by: kareila
Description: Whoops! Sometimes when you do things, your code ends up showing. Now it doesn't.

Issue 2691: revert extra stickies to regular entries when paid time expires (pull request)
Patch by: kareila
Description: Paid time features are awesome, and you should have them, but if that's not the case, we want to make sure that your additional sticky entries stay safe, but properly reflect their newly unprivileged status.

Issue 2883: Fix to order by jitemid, not journalid (pull request)
Patch by: zorkian
Description: In certain circumstances, entries with the same time stamp would be sorted inconsistently, and some items might not have shown up at all - this was because we weren't sorting by the parameter we were supposed to be. That's been fixed, and hopefully there will be consistent sorting and visibility going forward.

Issue 3056: Add "this service is defunct" styling to old user name tags (pull request)
Patch by: cmho
Description: Not every site has the longevity that Dreamwidth has. We don't want to link to dead services, but we also don't want to screw up older entries by blanking out the links to those old services. So, instead, we'll just turn them into styled text.

Issue 3475: Can't remove retired "other sites" from profile (eg. ICQ)
Patch by:
Description: We also had to make it possible to remove those older sites from profiles, since it's no use displaying a defunct contact method.

Issue 3486: ability to transfer points anonymously was inadvertently(?) removed
Patch by:
Description: Whoops! We accidentally removed the ability to anonymously give other people your Dreamwidth points. Once it was noticed, we fixed it with the following patch.

Issue 3214: Restore anonymous transfer checkbox on point transfer form (pull request)
Patch by: zorkian
Description: Hooray! It's now possible to gift points anonymously again! We could before, but while doing a conversion to Foundation, we accidentally left out the checkbox that let you do it anonymously. It's back.

Issue 3265: "current theme" widget got updated for homepage but is now harder to read on /customize (pull request)
Patch by: momijizukamori
Description: Sometimes when we do conversions, the CSS decides to get a little artistic on us and we need to get it back to what we want it to do.

Issue 3310: Beta Entry Page bug fixes (pull request)
Patch by: momijizukamori
Description: The Beta version of the Create Entry page is pretty cool, but occasionally it doesn't do something we want it to - in this case, we couldn't edit a sticky post to un-sticky it in the beta version, but now we can!

Issue 3311: fix failing test t/post.t (pull request)
Patch by: kareila
Description: That change above, where we can now unsticky stickies? It made one of our automated tests complain. This is good, we want that, but we had to also tell the test that everything was fine.

Issue 3314: in user tags, Github profile icon is invisible on black background (pull request)
Patch by: kareila
Description: Github's default user icon is black on transparent. This becomes a problem on any journal with a black background. So, instead, we're now using a black icon on a white background, to make sure that when you reference a GitHub user, you can see that.

Issue 3323: add noindex tags to support/see_request.bml (pull request)
Patch by: kareila
Description: Web crawlers were indexing our support requests. Our users don't particularly like that, so we've added some "noindex" tags to places to politely tell the crawlers not to put the support requests into their indexes.

Issue 3325: @ user mentions for youtube accounts are incorrectly formatted and the links do not work, and Issue 3349: YouTube profile URL format needs update (pull request)
Patch by: kareila
Description: YouTube changed the architecture of their profile pages, and so we had to change our code to point to the new and correct URL for a YouTube page.

Issue 3499: fix plurk user links (pull request)
Patch by: kareila
Description: Our user links for Plurk weren't working, because we didn't include the www in the URL. Now we have, and now they work again.

Issue 3506: update AO3 userhead to use https (pull request)
Patch by: kareila
Description: The Archive of Our Own has started serving their usericons over HTTPS and tossing HTTP requests through a proxy, so we updated our fetcher to get it from them using HTTPS so we can cache the picture and serve it locally, rather than having to hit their servers every time.

Issue 3328: handle RSS parser errors generated by newer feeds
Patch by:
Description: There was a possibility that our RSS parser was behaving badly, but he issue does not appear to have reoccurred since the initial issue, so we're keeping an eye on it in case it reoccurs, but otherwise have closed the issue.

Issue 3355: community admins should not get the "can't buy premium paid time for a paid account" message for their comms (pull request)
Patch by: kareila
Description: Community admins who want to upgrade their communities to premium paid time should be allowed to do so. And now they can. (It'll also catch if someone didn't choose an account tytpe before submitting.)

Issue 3358: shopcart widget shows payment buttons in admin view (pull request)
Patch by: kareila
Description: In the admin pages, don't show the cart checkout buttons when viewing the payment receipt. (Whoops.)

Issue 3370: Manage Circle is differently (more worse?) broken
Patch by:
Description: We had an issue where the Manage Circle page would remove you from every community it could when you clicked "save." (Oops.) It doesn't do that now.

Issue 3371: Edit Tags success message channeling Kool-Aid Man
Patch by: momijizukamori
Description: We've had session message flashing (basically little temporary messages like 'Edit successful!' that show after taking an action, and which vanish when you navigate to a new page) for a while now, but when we upgraded the tag editing page, they got added there, too, and we discovered a bug: they didn't show in journal-styled pages, causing them to appear on the next site-styled page you visited instead, which was generally very confusing. (OH YEAH!) This adds those messages to journal-styled pages.

Issue 3375: HELPURL links broken on shop pages (pull request)
Patch by: kareila
Description: We had some links pointing at the wrong places. They're now pointing at the right places.

Issue 3379: update Gift Paid Time profile link to use new shop url
Patch by:
Description: Because we had to change the shop's URL, we need to make sure all the places that point at the shop use the new URL.

Issue 3376: the phrase "Need fallback text" displays when attempting to choose a delivery date in the shop
Patch by:
Description: Some fun interactions were happening when people of certain account tiers were trying to purchase time from another tier to extend their own (because paid time converts to premium paid time if you're a premium paid user.) Things were sufficiently weird that sometimes the shop would get very confused about what it was supposed to display. It's feeling much better now, thanks to the following patch…

Issue 3468: fix premium conversion error display (pull request)
Patch by: kareila
Description: This fixes the problem where some errors in the shop, most commonly trying to buy premium time for a paid account, were not displaying correctly.

Issue 3384: Manage Tags: automatically convert to lowercase when renaming (pull request)
Patch by: sirilyan
Description: Dreamwidth tags are all in lowercase - so if you capitalize them when you're editing tags, they'll automatically be converted back to lowercase, so they follow tag form properly. Seamlessly. Quietly.

Issue 3390: style selection workaround and Issue 3429: style selection issue still persists
Patch by:
Description: Changing and customizing styles in communities is not as straightforward as doing it in journals, but there are ways of doing it. The support request in the issue has a way of making it work without having to go to a specific and direct link to try and customize community styles.

Issue 3431: Fixes for customizing comms (pull request)
Patch by: momijizukamori
Description: Many months ago, we fixed an issue where trying to set styles and related options (like layout or titles) on comms made them apply to the user's regular journal instead. However, we missed that the issue was present on two pages, and only fixed one of them. This fixes the other page, and also fixes a much more minor issue where the labels for community journaltitles were missing in the customization UI.

Issue 3405: Display error in layout chooser after picking new layout (pull request: Remove debug code causing errors)
Patch by: momijizukamori
Description: It turns out debug print messages do not make valid JSON! Who knew, right? The layout chooser widget now returns valid JSON that does not cause it to spew errors when you select a new layout.

Issue 3425: debug print needs to be removed from shop page (pull request)
Patch by: momijizukamori
Description: Sometimes, devs add extra print statements to try and figure out why something is misbehaving. Sometimes, they forget to remove these once they've fixed the problem. This removes one such instance of this on the shop pages.

Issue 3426: fix "Admin Post" on comments disappearing when edited
Patch by:
Description: We're still wrangling an issue where the "admin" distinction on a comment in a community disappears if the comment is edited.

Issue 3433: possible method call on undefined object when using /admin/rename (pull request)
Patch by: kareila
Description: Computers don't like it when you try to do manipulation of deleted objects. They get very cranky about it, so we put in some ways to try and make sure it doesn't happen in the future.

Issue 3439: Fix label for moderated comms on /manage/circle (pull request)
Patch by: momijizukamori
Description: Fixes an issue where the URL to request membership in moderated comms was incorrect, and also fix TT escaping the link entirely.

Issue 3440: new Edit Profile page does not load birthday month (pull request)
Patch by: kareila
Description: We use beta pages for a reason - sometimes we forget to include things, like birthday months, that we want to include. Now they're present.

Issue 3443: remove anchor from URL when submitting update to profile
Patch by:
Description: If you don't actually tell computers what you want them to do, they'll do fallback actions, and that sometimes means that the browser jumps back to a part of the page that doesn't show any messages about successful updates. Not very helpful.

Issue 3445: user-suggested style fixes for /manage/profile in Gradation
Patch by:
Description: Making sure that our styles work properly across the site. Because we are the kind of people that notice when things are misaligned just so.

Issue 3450: Tweaks to profile pages (pull request)
Patch by: momijizukamori
Description: Making sure that our styles work properly across the site. Because we are the kind of people that notice when things are misaligned just so.

Issue 3446: information not being displayed on Manage Email Addresses page (pull request)
Patch by: kareila
Description: This fixes some conversion issues with the Manage Email Addresses page that didn't show up until you had changed an account's email address at least once.

Issue 3452: Birthday Gift button goes back to homepage due to empty link (pull request)
Patch by: kareila
Description: We didn't use the right method to get the right link for when you wanted to give borthday gifts, and so it went to the site homepage instead of the right page. That's been fixed.

(And now, for a brief focus on the subject of polls and making them work...)

Issue 3438: Error from compile test in poll conversion (pull request)
Patch by: kareila
Description: The code module for the converted poll code contained a duplicate variable assignment - the newer one from the controller and the older one from the original file. This removes the second, older assignment so that the compile test will pass cleanly.

Issue 3453: TT version of poll page no longer allows editing of community polls by all comm admins (pull request)
Patch by: kareila
Description: We had a bug where only the person who posted a poll could close it, rather than other community administrators also being able to close polls posted in a community. We've fixed that.

Issue 3456: at least one report of polls no longer working in "older" browsers
Patch by:
Description: We try to make Dreamwidth as compatible as possible across a wide swath of web browsers and agents, and occasionally they have some real doozies of behavior, especially if JavaScript support is off or old. Thus, the following patch…

Issue 3458: Keep '/poll/' from redirecting to '/poll', which breaks form post (pull request)
Patch by: momijizukamori
Description: We have code that makes it so if a user navigates to dreamwidth.org/somewhere/ , it will redirect them to the 'official' address of dreamwidth.org/somewhere. And mostly this works fine, but it doesn't work when trying to send a form response to the server, because the 'official' address endpoint never actually sees the data. This resulted in polls failing to work when not submitted via Javascript from within a journal entry, and has now been fixed.

Issue 3459: fix another minor poll conversion bug (pull request)
Patch by: kareila
Description: The form variable for a poll submission wasn't being submitted to the LJ::viewing_style_opts function in the correct format. This is fixed.

Issue 3463: on converted poll page, the "ans_extended" mode doesn't work (pull request)
Patch by: kareila
Description: More chicanery with not-Javascript and polls! It's amazing what you'll unearth when you're working on a vodebase like this and there's that one user somewhere who has a completely different setup tahn everyone else, and things that should work smoothly for them instead explode. Therefore, the following patch…

Issue 3465: fix non-JS version of ans_extended mode for poll page (pull request)
Patch by: kareila
Description: Found a bug in some code from 2011 that was using the wrong DBI method name. Fixed this page for non-JS mode, too.

Issue 3473: report of multi-answer polls only recording one answer
Patch by:
Description: Whoops, the multiple-choice polls were only recording the last option ticked on the initial submit. On edit, they worked properly. Now, on initial submission, they'll work properly.

(Poll section over. Aren't they fun?)

Issue 3466: fix rename link in shop (pull request)
Patch by: kareila
Description: Update another link that needed to be fixed to point to the main www site after moving the shop to its own domain.

Issue 3476: Feed entries show multiple authors as ARRAY(...) (pull request)
Patch by: zorkian
Description: Feed entries with multiple authors (which is allowed by the RSS spec) used to display "Posted by ARRAY(0x...)" instead of the actual author names. Now they correctly show something like "Posted by First Author, Second Author".

Issue 3478: Form to "remove some interests" should start out with checkboxes deselected (pull request)
Patch by: zorkian
Description: Fixed a bug on the "add/remove interests" page where all checkboxes appeared unchecked. The page shows your interests (or another user's interests) as a list of checkboxes — checked means you want to keep (or add) the interest, unchecked means remove it. A typo from a previous update broke the checkboxes so they always started unchecked, which meant submitting the form without changes would remove all displayed interests.

Issue 3480: On mobile + beta inbox, folder list will not open after mark read interaction (pull request)
Patch by: zorkian
Description: On mobile, the beta inbox has a "Folders" button that expands and collapses thefolder list. After using any action button (like marking a message as read), the folder buttonwould stop working until you refreshed the page. This was because the action updated the folderarea's HTML behind the scenes, and the new button lost its connection to the toggle behavior. Now the toggle works reliably even after actions are performed.

Issue 3487: Notifications about unscreened comments (pull request)
Patch by: zorkian
Description: When someone replies to your comment but their reply gets screened (because the journal screens comments from people not on their access list), you previously never found out about that reply — even after the journal owner unscreened it. Now, when a journal owner unscreens a comment, everyone who would normally have been notified about that comment will receive their notification. People who were already notified when the comment was screened (like the journal owner) won't get a duplicate.

Issue 3490: Rate Limiting (pull request)
Patch by: zorkian
Description: This adds basic rate limiting functionality that will leverage memcached to enable us to keep track of how frequently certain things are happening and then return the appropriate error code. This is primarily being built for the API, but will probably be useful in other contexts as well, or could be.

Issue 3491: Make "Private message" link on profile page respect $remote's beta-inbox selection
Patch by:
Description: Sometimes the link to your message inbox on your profile page wouldn't respect whether you had chosen to opt-in to the new beta inbox. Now we have code that ensures that you get the inbox you signed up for (or didn't) when you go to your inbox from your profile page.

Issue 3496: update all nonfree files to use nonfree licensing boilerplate text (pull request)
Patch by: kareila
Description: Not everything about Dreamwidth is Free and Open Source material - usually, nonfree is the stuff that's specific to Dreamwidth, like logos, specific themes, and so on. All of that material needs to have the specific licensing statements indicating that it's nonfree. Now all of those pieces have that nonfree statement attached to them.

Issue 3505: proper display of error messages on the editprivacy page (pull request)
Patch by: kareila
Description: This should fix a problem where Edit Journal Privacy displays a page that just says "Error" with no further information if the viewing user is unable to use the feature.

Issue 3509: seen in prod: undef error viewing logged-out account purchase
Patch by:
Description: If you're not logged-in and with proper permissions, you can't see purchases. This throws an undefined error, and generally makes software cranky at us. This has been fixed.

Issue 3511: Move POST-only logic inside did_post guard in Login controller (pull request)
Patch by: zorkian
Description: Fixed some warnings that were printing to the logs! Clean up, clean up!

Spiced Pork and Ham

Issue 2795: restrict visibility of URL link for 10 days on newly created account profiles (pull request)
Patch by: cmho
Description: Robots that do not contribute to our culture often like to promote their immoral, illegal, and usually in poor taste schemes on their profile page. Rather than give them the satisfaction of even one person looking at their schemes, the URL link on a new profile is only visible to people with specific privileges for the first ten days. (Usually by then, they've been spamwhacked if they're not actual people.)

Issue 2824: new page /admin/recent_accounts (pull request)
Patch by: kareila
Description: And to help us in the eternal task of frying spam (not for musubi, regrettably), there's a new page for people with the appropriate privileges to see who the newcomers are.

Safety Features and Anti-Safety Political Requirements

Issue 3337: add child safety restriction: no PMs between over-18 and under-18 accounts (pull request)
Patch by: pauamma
Description: After a long and heavy think, Dreamwidth has decided to implement a restriction preventing people who are under-18 from sending private messages to those who are over-18. There are some legitimate use cases for allowing under-18s and over-18s to get in contact, but they're a bit like betting on 00 and winning compared to all the other possible less-good results. Because Dreamwidth is loud about protecting privacy and challenging overbroad legislation, we also want to make sure our ducks are in a row about user safety.

Issue 3472: Dreamwidth sends a `Referer` header that allows external sites to uniquely identify Dreamwidth users
Patch by:
Description: Information sent to webservers often includes information about what page someone was on when they clicked a link. Since Dreamwidth offers each user a subdomain of their own, when they click on links on their own reading pages, the information sent is the username of the user that clicked on the link, rather than the username of the user who posted the link in their own journal. This has some privacy concerns. The fix is to send information such that it does not identify the user who clicked the link to an external site.

Issue 3495: Add TN state age logic (pull request)
Patch by: zorkian
Description: The state of Tennessee decided they wanted to impose restrictions on minors accessing social media websites, and the least terrible method to comply with their law while it is fought in the courts is to block new sign-ups for anyone under 18 who says they are from Tennessee. This fix implements the requirements to be in compliance with Tennessee.

Issue 3513: Prevent under-18 signup from SC
Patch by:
Description: The state of South Carolina looked at what Tennessee had done and said "Hold My Beer." This patch implements the same restrictions for under-18 signups for anyone who says they are in South Carolina, while the South Carolina law is fought in the courts.

Ooooh, new stuff!

Issue 2206: OpenGraph implementation (pull request)
Patch by: l1n
Description: We now support OpenGraph metadata, so hopefully things that speak that and are looking to index and classify public entries can just take what we're offering, instead of scraping up arbitrary data instead.

Issue 2754: Implement nfagerlund's suggestion: use LJ::Entry->event_html_summary for entry previews (pull request)
Patch by: Copilot
Description: We're making the code a little less low-level everything, using some processes already present to generate cleaned HTML with regard to the "preview" function of an entry.

Issue 3382: Add squidgeworld as a profile page option and usertag (pull request)
Patch by: sirilyan
Description: SquidgeWorld users, welcome to having your own usericon associated with your accounts! And you can be listed as a profile page option.

Issue 3386: Add Spotify to profile/usertag
Patch by:
Description: Spotify users, welcome to having your own usericon associated with your accounts! And you can be listed as a profile page option.

Issue 3387: Add Steam to profile/usertag (pull request)
Patch by: sirilyan
Description: Steam users, welcome to having your own usericon associated with your accounts! And you can be listed as a profile page option.

Issue 3416: max Steam username length should be 32 (pull request)
Patch by: alierak
Description: …and also, we should make sure that Steam usernames are valid and not overlong.

Issue 3404: Add gettyimages.com to embed whitelist (pull request)
Patch by: sirilyan
Description: Only certain sites can have their media embedded on Dreamwidth journals. gettyimaages.com joins the list of organizations we'll let embed on journal entries.

Issue 3437: fix gettyimages embed URL pattern (pull request)
Patch by: alierak
Description: …and then fix the embedding pattern so the images display properly.

Issue 3444: new profile services don't have legacy userprops (pull request)
Patch by: kareila
Description: New services (steam, spotify, squidgeworld) were causing the profile page to die with a database error; this should fix it. (Because adding new things is good, and sometimes uncovers interesting bugs.)

Issue 3449: update code references to offsite status account (pull request)
Patch by: sirilyan
Description: Dreamwidth maintains an off-Dreamwidth status account, so that if the site is down, you can be sure of that by going to the off-site status account. Given the changes made to Twitter, the official off-site account is now on Bluesky. Now all the old Twitter references are now Bluesky references.

There we go! Another year's worth of code commits, issues resolved, and attempts to make Dreamwidth a greater and cooler place to be. And to have it continue working into the future.

(We should do these more often, but volunteers and, well…*gestures broadly around*. So it may be a while before someone has the spoons to do this again, but we're always trying to be more consistent about it.)

Here are the totals for this code tour:

104 total issues resolved.
Contributors in this code tour: Copilot, alierak, cmho, dependabot, jjbarr, kareila, l1n, momijizukamori, pauamma, sirilyan, zorkian

Comments

[etfb]

Nice. Sadly, something you did a couple of weeks ago broke the API so that timmc's fork of ljdump no longer works. I haven't figured out what's wrong with enough accuracy to suggest a possible cause, but if you have any other hints that the API's sessiongenerate endpoint is broken, you can use ljdump to confirm it.

[teres]

Well done on the code tour, especially since I haven't seen you done something like this before! And it's good to see a sum-up of what you've been doing (the continued replacement of BLM is especially nice to watch; I hope you'll be done soon).

For your information, the link to dependabot on Github is broken... and maybe you could spur the developers to update the footer to 2026, as some of the work in this tour has been done in the current year?

In any case, I'm looking forward to see the stuff that hasn't gone live yet go live, and to the further work you'll be doing in 2026!

[yuuago]

Wow, that's a lot. Thanks for listing it all out for us & thanks to everyone who worked on it.

[evildoer]

Thank you for all the detail!

I do have a question re: Copilot coding, is that something that was a one-off for that PR (#2754) or is that something that will be utilized regularly going forward? I have been moving away from software that uses Copilot/Claude/etc. in their development due to the plagiarism and license violations involved in the training of those tools, so I am hoping it's just a one-off. I love DW and don't want to lose it.

[muccamukk]

Great work, everyone! Really happy to see some of these go through <3

Persistent AO3 Userhead Issue

[jesse_the_k]

I always learn something, even though code is ελληνικά to me

I was intrigued to read "Issue 3506: update AO3 userhead to use https (pull request)" because I've seen no AO3 user head icons for the past few months. (I didn't do a support request because gestures wildly) So evidently the new code isn't working in all cases (and DW is a fertile field for many cases).

Three visual samples: https://gofile.io/d/skrnnC

I will now go copy the previous 2 paragraphs to a support request.

Re: Persistent AO3 Userhead Issue

[muccamukk]

Testing muccamukk

Nope. Alas.

GIP Re: Persistent AO3 Userhead Issue

[jesse_the_k]

Thanks for testing

Re: GIP Re: Persistent AO3 Userhead Issue

[muccamukk]

Bummer. That's been irritating me for months, and I was excited to see it on the list.

[satsuma]

I was also concerned about this

Re: Persistent AO3 Userhead Issue

[silveradept]

To help with the support issue, here's an interesting wrinkle - in the e-mail I received testing the AO3 userhead, it rendered properly. So there are some places where this is working correctly, and others where it isn't. I don't know what's different about the e-mail formatter, but it's right where other places are wrong.

[silveradept]

It's nice to see all the things that happen, and how they make the experience better. (Sometimes, eventually.)

[silveradept]

It is. Managing it in smaller chunks would be nice, but that requires spoons that not everyone has at any given time.

[silveradept]

There's always more BML to convert, but there is also progress on the conversion of the BML.

(I suspect we'll be setting off metaphorical fireworks when it's actually done and there is none/the bare minimum of BML left.)

I've fixed the user link for dependably, and hopefully there's a request in soon to change the site footer.

[silveradept]

Oh, no!

The best thing to do in this case is gather as much error information and what you were trying to do and open a support request, so that gets more eyes on the problem to see if there's a fix that can be put in place.

[teres]

At least there no new pages with it coming in, so it should be possible to make it out of the tunnel in the end... (And I'll be cheering for you when it's done, too!)

I've fixed the user link for dependably, and hopefully there's a request in soon to change the site footer.

Thanks for fixing it, and I'll see when that happens!

[evildoer]

I was like "hm I feel like I've seen their username before" - I think we have mutuals in common on the fedi. Small internet! haha

Re: Persistent AO3 Userhead Issue

[kareila]

I think it's because many servers, apparently including the one AO3 uses, have started blocking (or use a third party platform that has started blocking) requests from our servers for insecure (http) links. The code change is to start using https again, but the personal machine you read email on can load the http version just fine.

The reason it's not working for the readers of this post yet is because the change is still waiting to be deployed outside of canary. If you have canary turned on, it works as expected. (And if you turned on canary in the past and it's not working, the relevant cookie expired and you need to turn it off and on again. That's the demographic I found myself in earlier this month.)

[pangolin20]

I can confirm that it fully works on Canary (and the pages newly converted to TT also look quite good!).

Re: Persistent AO3 Userhead Issue

[muccamukk]

Interesting! Do you know when it'll be deployed outside Canary?

[denise]

Mark is posting a top level post that covers our thinking in more detail! Basically: we don't require anyone use it for development and we don't forbid anyone using it for development. We expect that if developers who are not us use it, they use it as an assistive tool at the steps the current tools are good/reliable at doing, to help make their process more efficient, and that the pull requests they submit have been human-reviewed: we would prefer not to get agentic or vibecoded submissions. Any artwork (mood themes, style images, etc) must be the work of a human artist, not generative AI.

Basically: the current tools are good at making it easier to do a lot of the things that are a significant challenge in a codebase of our size, age, and complexity, and the responsible use of tools like Claude and Copilot by an experienced developer, to do things like point you at the likely source of a problem, do first-pass refactoring that can serve as a structure that you start from, etc, is such a significant timesaver that it clears out a ton of roadblocks that historically have been some of the things we struggle most with in terms of development capacity: not using it when it's called for would mean continuing the same slow development process that has frustrated people badly in the past decade or so. (As well as frustrating the developers!) But we aren't letting it roam freely and we aren't letting it write code by itself or make changes without significant human supervision. We expect that if people use it, they use it as one tool of many, as a part of their process, and the final PR or commit is ultimately the product of human work and human judgement, no matter what tools were involved.

[evildoer]

Thank you! This is very helpful. I really appreciate the stance on the art piece as well, that whole image generation ecosystem is another thorn in my side 😩

I definitely understand the usage you've described and I trust y'all will continue to adhere to those guidelines (and fwiw I think this might be the only site where I would be trusting enough of leadership to take something like this at face value, lol).

Re: Persistent AO3 Userhead Issue

[kareila]

I don't know when that will happen, sorry! But I would expect it to be soonish.

Re: Persistent AO3 Userhead Issue

[denise]

We're hoping for a code push in a few weeks but don't have a more exact date yet!

[denise]

More info to save you the troubleshooting time for a support request: we know about the API errors and we're trying to figure out wtf, but it's possibly at the network level and we haven't found a root cause yet.

Re: Persistent AO3 Userhead Issue

[muccamukk]

Thanks! I had my head turned around, and thought this was stuff that had gone out, rather than gone out + pending. Someone has explained it to me in smallish words. 🤦‍♀️

[denise]

I swear to God I actually updated the footer through the on-site copy editing system in early January because I was very proud of remembering it was 2026 and I needed to update it before it was almost 2027, but apparently it didn't stick (it takes 15-30 minutes for a change to be reflected on the live site and I often forget I did it and need to confirm that it worked by the time it would be visible, heh.)

I tried again just now; hopefully it will work this time. That system is the most haunted of all our haunted systems.

[kareila]

It's also possible that you are remembering what you did for 2025 and the passage of linear time is mocking us all.

[denise]

Warning: patented denise tl;dr "it's a lot more complicated than even the complicated version" meandering ahead, heh.

It's the same problem that we're all struggling with in content moderation/Trust and Safety as a profession: starting at levels of "content submitted per hour" that are, like, barely 2x or 3x as much as we get, the process of both detecting and preventing automated abuse such as spam and the process of handling violations of the Terms of Service/getting really bad shit off your site starts to be both a significant undertaking and extremely traumatic to any humans involved. (I've written extensively about the psychological harm that content moderation work has on the people who do it, because I was one of the people doing it in that first wave of user-generated content sites before we had any idea what the psychological consequences of it were, and I have lost so many of my contemporaries and professional acquaintances from the early days to death by suicide or misadventure. And that's not counting how many literally renounced technology and online communications and are living off grid and homesteading or small farming! Which is a very common exit profession for tech.)

So, good automation detection/classification tools, powered by machine learning (and these days, large language model based ML is the most effective form of machine learning for this) not only gets dangerous content taken down faster, becauss you don't have to wait for a human to report it and another human to take action, it also saves a lot of human suffering and trauma. I will refrain from going into a ton of detail except to say that automated image content analysis and detection is probably the single thing that has prevented more moderator trauma than any single other mitigation in the history of Trust and Safety... except. General purpose LLMs are bad at this and you need custom trained models, and a lot of the custom trained models are developed through the outsourcing of labeling/classification labor to the developing world where labor costs are lower (and often to where employee occupational-injury protection laws are weaker or nonexistent), and a shitload of it is subcontracted and abstracted away even further to companies that are highly incentivized to cut their costs and increase their throughput as aggressively as possible and the worker psychological protections we do know work a little cost more than just burning through traumatized people, so the data workers who are classifying the training data don't even have the basic psychological mitigations we know prevent some of the trauma and moral injury from constant immersion in the worst humanity has to offer. And now we're, like, at least four layers of subcontracting away from what "someone who just wants to use automated detection so their moderators don't have to look at child sex abuse and snuff films all day" has the power to influence, control, or mandate better working conditions.

So to some extent it is outsourcing trauma work (and Trust and Safety is inherently trauma work) to people in developing countries! I have a gigantic fucking problem with that! But someone has to do that trauma work, because "don't moderate your website" is not an option, and training a machine learning model to do it will protect more people overall just because of the sheer volume of content posted to the internet every day, and a lot of places are already outsourcing their human moderation trauma work to layers of providers that end up with the trauma work being done by people in developing countries with shit worker protections anyway, so is it better to traumatize people on an ongoing basis instead of use the tools that were developed by traumatizing people? Because we've tried really hard as an industry to come up with a solution that involves no traumatizing people at all, but we haven't found it yet and given human nature we're never gonna! As much as I hate pure utilitarian ethical arguments because they're so easily twisted into justifying atrocities, and prefer my ethical analysis to include a balance of deontological and consequential ethical principles, that one is genuinely difficult to reason through no matter what ethical framework you apply!

And that's just one small element of many. Basically, there's a reason I say my undergraduate degree in philosophy and history of religion is significantly more applicable and valuable to my work in social media product development and Trust and Safety than I ever possibly could have expected, even applying the "the liberal arts are always more applicable than you think", because dear God all of this shit is incredibly complicated and even more nuanced than anyone would think.

But we set out our guiding ethical principles for Dreamwidth when we started and we come back to them constantly to guide our thinking on this, and they haven't changed. Our purpose is to provide our users the tools they need and want to communicate however and whatever they want to without having to sacrifice their privacy and security in giving away their data. We exist to facilitate human conversation, connection, and discussion without the distorting influence of surveillance capitalism (and partially to serve as proof it's possible and inspire more people to try it -- there's a reason I offer free consultation to anyone who's starting or thinking of starting an independent social media site, because I want there to be a million more of them!) Anything we do, any tool we chose, any feature we implement, any process we put in place, is in service to those goals, and we examine everything we do inside that framework.

Sometimes we do use tools and/or third party providers that are less awesome than we would like! Example: we really do need a lot of the "audience device technical capacity" features of Google Analytics in order to determine how to best prioritize development and bug fixing time, and nothing self-hosted has all the functionality we need (and self-hosting a tool increases complexity, in that now you have to keep up that tool's dependencies, watch for security flaws, etc: supply chain attacks where someone compromises a dependency are accelerating.) On the other hand: it's Google. On the other hand, that aggregate information surfaces important things like "what assistive technology people are using to access the site, so we know what to test in". And so on, ad infinitum.

So we do the analysis every time, dig through all the possible risks and threats, figure out whether we can mitigate them or not -- I'm really good at redteaming how something could be exploited by now! For Google Analytics, for instance, we only include it on a representative subset of site pages and never put it in user journal space (unless the user wants to use their GA account because they're comfortable with it). For the implementation of our payment system, which we have to outsource, we structured our implementation and integration so that it would be impossible for a subpoena to our payment processor (who's way less likely to fight a bullshit subpoena than we would be, because we are very fighty) to associate someone's payment with their DW username, and impossible for any theoretical security breach on DW to give an intruder the ability to look at a payment on DW and get someone's government identity from it. (There's a limit to how far that can go with protecting payment identity from being associated with a username from a government subpoena to us, because a court does have the ability to command us to go get the data from the payment processor ourselves and provide it, but see above re: us being fighty about that. It's never happened, to be clear, but we would fight the shit out of any bullshit identity/payment data subpoena we got just like we'd fight the shit out of any other subpoena that we didn't think was necessary, appropriate, proportionate, and addressing an extremely serious crime such as child sexual abuse or genuine human trafficking.)(And just to be absolutely crystal clear: I mean actual coercive violence-backed human labor, sexual, medical, etc trafficking, not "all consensual and uncoerced sex work is actually human trafficking even if that implication means you're the person who's trafficking yourself", because too many people are trying to use the language of human trafficking to make a lot of perfectly fine things sound scary.)

The tl;dr (way, way too late): the usual exhaustive comments explaining a million bits of nuance you're used to seeing from me are the short version of the analysis we do on our decisions! I'm usually skipping over a whole lot of shit! But we always come back to those guiding principles, and we always aim for, does this thing improve our ability to facilitate human communication without affecting user privacy or security, and what guardrails do we need to put on it so that if someone not-us in the chain fucks up, gets compromised, or turns malicious, the exposure to our users will be prevented as much as possible?

[denise]

It's also possible I made the change and then just wandered away/closed the tab without clicking save! Who knows, lol.

[pinterface]

Human communication is fickle, and this is a good example: I actually think this (especially the second paragraph) is a better explanation that what was given in Mark's top-level post.

The top-level post left me thinking "So…what's the difference between code and art? Why is code from the plagiarism machine okay, but art from the plagiarism machine isn't?". This comment connected in a way that didn't leave me asking that. Probably because the phrasing makes the use of AI-for-code sound more like an extra-fancy autocomplete, vs. asking it to do all the work.

(I feel like I'm picking on Mark. I'm not trying to!) Anyway, thanks for the alternate phrasing. It helped!