mod_vcard_muc: Add an alternative method of signaling avatar change When the avatar has been changed, a signal is sent that the room configuration has changed. Clients then do a disco#info query to find the SHA-1 of the new avatar. They can then fetch it as before, or not if they have it cached already. This is meant to be less disruptive than signaling via presence, which caused problems for some clients. If clients transition to the new method, the old one can eventually be removed. The namespace is made up while waiting for standardization. Otherwise it is very close to what's described in https://xmpp.org/extensions/inbox/muc-avatars.html

---
labels:
- 'Stage-Alpha'
- 'Type-Storage'
summary: Experimental map store optimized for small incremental changes
...

This is an experimental storage driver where changed data is appended.
Data is simply written as `key = value` pairs to the end of the file.
This allows changes to individual keys to be written without needing to
write out the entire object again, but reads would grow gradually larger
as it still needs to read old overwritten keys. This may be suitable for
e.g. rosters where individual contacts are changed at a time. In theory,
this could also allow rolling back changes.

Requires 0.10