Follow Friday 3-6-26
2026-03-06 01:05 amHere's the plan: every Friday, let's recommend some people and/or communities to follow on Dreamwidth. That's it. No complicated rules, no "pass this on to 7.328 friends or your cat will die".
Here's the plan: every Friday, let's recommend some people and/or communities to follow on Dreamwidth. That's it. No complicated rules, no "pass this on to 7.328 friends or your cat will die".
Dealbreakers: Racism, ableism, transphobia, homophobia, antisemitism, being a dick, Scientology apologists, anyone who thinks Mike Shinoda is evil because of an Instagram reel, "isn't wrestling fake?", "you still like Linkin Park?"
Here's the plan: every Friday, let's recommend some people and/or communities to follow on Dreamwidth. That's it. No complicated rules, no "pass this on to 7.328 friends or your cat will die".

We've seen some questions lately about AI and how it relates to Dreamwidth, especially around scraping and training. Rather than answer piecemeal, I wanted to talk through how
denise and I are thinking about this and try to be explicit about some things.
Dreamwidth is a user-supported service. We don't build the service around monetizing user data, and that informs how we approach AI just like it informs everything else we do.
Dreamwidth does not and will not sell, license, or otherwise provide user content for AI training. We have not and will not enter into data-access agreements for AI training purposes.
We will continue taking reasonable technical steps to discourage large-scale automated scraping, including known AI crawlers, where it is practical to do so. No public website can prevent scraping with absolute certainty, but we will keep doing what we reasonably can on our side.
Dreamwidth will not introduce AI features (and we have no current intention of doing so) that use or process user content without a public discussion with the community first.
We're only phrasing it like this because we can't predict the future and who knows what will be possible and available in five or ten years, but right now there's nothing we can see wanting to add.
If that ever changed, the conversation would happen openly before any decisions were made.
Keeping Dreamwidth usable means dealing with things like spam and abuse, and that sometimes requires automated admin tools to be more efficient or effective.
We are not currently using AI-driven systems for moderation or similar decisions.
If we ever decide that an AI-based tool would help address a site admin problem like spam, we will explain what we are doing and how it works (and ask for feedback!) before putting it into use. Any such tools would exist only to make it easier and more efficient for us to do the work of running the site.
Dreamwidth is an open-source project, and contributors use a variety of tools and workflows.
Contributors may choose whether or not to use AI-assisted tools when writing or reviewing code. Dreamwidth will not require contributors to use AI tools, and we will not reject contributions solely because AI-assisted tools were used.
For developers: if you use any AI-assisted development tools for generating a pull request or code contribution, we expect you to thoroughly and carefully review the output of those tools before including them in a pull request. We would ask the community not to submit pull requests from automated agents with no human intervention in the submission process.
I think it's important and I want to be able to review, understand, and maintain any contributions effectively, and that means humans are involved and making sure we're writing code for humans to work with, even if AI was involved.
Important note: this applies to code only. We expect any submitted images or artwork (such as for styles, mood themes, or anything else) to be the work of a human artist.
And to be very explicit, any AI-assisted development does not involve access to Dreamwidth posts or personal content.
Oh, and we'll probably mention this (or a subset of this that isn't code related) in an upcoming
dw_news post, but will defer to
denise on that!
https://dotat.at/@/2026-02-24-nsnotifyd-2-4-released.html
The nsnotifyd daemon monitors a set of DNS zones and
runs a command when any of them change. It listens for DNS NOTIFY
messages so it can respond to changes promptly. It also uses each
zone's SOA refresh and retry parameters to poll for updates if
nsnotifyd does not receive NOTIFY messages more frequently. It comes
with a client program nsnotify for sending notify messages.
This nsnotifyd-2.4 release includes a new feature and
some bug fixes:
The new -S option tells nsnotifyd to send all SOA queries to
a specific server.
Previously, in response to a NOTIFY message, it would send a SOA query back to the source of the NOTIFY, as specified by RFC 1996.
(Typically, a NOTIFY will only be accepted from a known authoritative server for the zone. The target of the NOTIFY responds with a SOA refresh query and zone transfer. But it should avoid trying to refresh from one of the other authoritative servers which might not have received the latest version of the zone.)
Mark Felder encountered a situation where it would have
been more convenient to fix the address that nsnotifyd sends SOA
queries to, because the source of the NOTIFY messages wasn't
responding on that address.
Since nsnotifyd is intended to work as glue between disparate
parts of a system, it makes sense for it to work around awkward
interoperability problems.
The nsnotify client program was broken and unable to create
NOTIFY messages. D'oh!
I have adjusted the release process so that it works better with
git archive and web front-ends that offer tarball downloads.