Mastodon at the very least seems to prevent the creation of emoji with
dots in their name (and refuses to accept them in federation). It feels
like being cautious in what we accept is reasonable here.
Colons are the emoji separator and so obviously should be blocked.
Perhaps instead of filtering out things like this we should just
do a regex match on `[a-zA-Z0-9_-]`? But that's plausibly a decision
for another day
Perhaps we should also have a centralised "is this a valid emoji shortcode?"
function
OTP builds to 1.15
Changelog entry
Ensure policies are fully loaded
Fix :warn
use main branch for linkify
Fix warn in tests
Migrations for phoenix 1.17
Revert "Migrations for phoenix 1.17"
This reverts commit 6a3b2f15b74ea5e33150529385215b7a531f3999.
Oban upgrade
Add default empty whitelist
mix format
limit test to amd64
OTP 26 tests for 1.15
use OTP_VERSION tag
baka
just 1.15
Massive deps update
Update locale, deps
Mix format
shell????
multiline???
?
max cases 1
use assert_recieve
don't put_env in async tests
don't async conn/fs tests
mix format
FIx some uploader issues
Fix tests
* rejected_shortcodes is defined as a list of strings in the
configuration description. As such, database-based configuration was
led to handle those settings as strings, and not as the actually
expected type, Regex.
* This caused each message passing through this MRF, if a rejected
shortcode was set and the emoji did not exist already on the instance,
to fail federating, as an exception was raised, swiftly caught and
mostly silenced.
* This commit fixes the issue by introducing new behavior: strings are
now handled as perfect matches for an emoji shortcode (meaning that if
the emoji-to-be-pulled's shortcode is in the blacklist, it will be
rejected), while still supporting Regex types as before.
FloatingGhost