Otherwise every UI refresh of any kind causes text boxes to lose focus.

Do not show "none" affiliation since it doesn't really mean much and is
the default, same for "participant".  Show "visitor" role as "muted".

Hats are coloured by the URI not their name.

Some servers ignore extra payloads on the change presence itself, so once that's
done then send the extra payloads in a new presence.

Which was causing a crash here.

This requires not compressing it or cropping it unless we want to do *a lot*
more code, so file must be under 100k or we freeze it and no promises what your
non-square avatars will look like generally.

All drawables forever

Serious UI lag and bugs when it gets too big

See https://soprani.ca/todo/302

Some things are banned by resourceprep that a user might wish to use.

If this happens, then punycode the resource so they can at least join the room.
Always send their chosen nick (not a mangled version) as <nick> in presence.
Always save their chosen nick (not a mangled version) in bookmarks (risky, since
if they try to use this bookmark from a client not supporting this it may not
let them join without changing nick).
If we get a <nick> in presence, then we respect it if it matches the punycode
decode of the resource (this is to prevent spoofing or double-naming since MUC
services won't be validating the <nick> at all right now. May relax this in the
future).
Save their actual nick (whatever we're actually showing, so <nick> if we used
that) into conversation attributes instead of assuming it will match the
resource.
Use resource for technical stuff (like PM addressing) and nick for display.

Hilight on both nick and resource so that mentions from legacy clients work.

Which actually validates according to spec instead of just being lazy.

Anything you have open is essential to the process.

So that one account doesn't override another's attempt to sync

For easier debugging