Claire

> @ClearlyClaire to be clear, we're saying revert most of the Tag#formatted_name changes? Yes. I'm fine with the refactor when there is no `name`/`display_name` change, what I want to avoid...

> If we're changing the PR links to their individual documentation page/section, I'm thinking maybe it's a good idea to cross-link them back? Yes, that sounds reasonable

Notifications from limited accounts are created as filtered according to the user's notifications policy, which by default puts those in filtered notifications, and do not drop them (contrary to pre-4.3.0).

The defaults are the following: everything is ACCEPTed except for unsolicited DMs and limited accounts which get FILTERed, so I'm afraid there is no way to recover exactly the same...

This looks ok but I'd like someone else to have a look. My concern is that an incorrect call, an abruptly aborted process, or some edge case we are not...

This comes at a cost, because `Parslet` does not do any kind of optimization, and the disjunction in `prefix_operator` significantly increases the work Parslet will do. I can manually write...

(Pushed an optimized form that takes care of the cost)

I can confirm this changes the behavior of default values. Indeed, taking the example of `OIDC_UID_FIELD`, the behavior stays the same when the environment variable is defined, but when omitted,...

> do we like this general approach of wrapping these with config_for to move env loading earlier? At least for this part, yes, if the defaults issue can be handled...

> this might be niche but i would like to see _ungrouped_ follow notifications, while leaving my account auto-accepting follow requests, but only from people i already follow. Sorry, I'm...