Scrubbing an ASCII-8BIT string isn't ever going to remove anything, because
there's no code point that isn't valid 8-bit ASCII. Since we'd really
prefer it if everything were UTF-8 anyway, we'll just assume, for now, that
whatever comes out of SimpleRSS is probably UTF-8, and just nuke anything
that isn't a valid UTF-8 codepoint.
Of course, the *real* bug here is that SimpleRSS [unilaterally converts
everything to
ASCII-8BIT](https://github.com/cardmagic/simple-rss/issues/15). It's
presumably *far* too much to ask that it detects the encoding of the source
RSS feed and marks the parsed strings with the correct encoding...
"I'm going to do something entirely sane and reasonable" doesn't warrant a
warning-level log message. It's perfectly fine and reasonable to just log
that sort of thing at info level.
Strangers get to create new topics (if the appropriate tickbox is ticked)
but low-TL existing users don't. That might seem a bit backwards, but
the tickbox says 'strangers', not 'everyone'.
On sites that don't otherwise configure an avatar fallback, Discourse will
now tell the client to get its letter avatars from a location which nginx
proxies to the centralised `avatars.discourse.org` service. This alleviates
privacy concerns, whilst still providing some degree of performance benefit
(no need for every site to delay avatar response by 300ms for image
rendering).
It is still possible to gain the benefits of global image caching and the
lower latency of requesting directly from a CDN, by explicitly changing the
`external_system_avatars_url` site setting to
`https://avatars.discourse.org/letter/{first_letter}/{color}/{size}.png`.