mod_report_affiliations: Fix traceback a non-user is sending a presence For now we won’t touch their presence instead of emiting this traceback: error Traceback[s2s]: /usr/lib/prosody/core/rostermanager.lua:275: attempt to concatenate a nil value (local 'username') stack traceback: /usr/lib/prosody/core/rostermanager.lua:275: in function 'prosody.core.rostermanager.is_user_subscribed' ...ules/mod_report_affiliations/mod_report_affiliations.lua:116: in field '?' /usr/lib/prosody/util/events.lua:81: in function </usr/lib/prosody/util/events.lua:77> (...tail calls...) /usr/lib/prosody/core/stanza_router.lua:184: in upvalue 'core_post_stanza' /usr/lib/prosody/modules/mod_presence.lua:244: in function </usr/lib/prosody/modules/mod_presence.lua:231> (...tail calls...) /usr/lib/prosody/util/events.lua:81: in function </usr/lib/prosody/util/events.lua:77> (...tail calls...) /usr/lib/prosody/core/stanza_router.lua:188: in upvalue 'core_post_stanza' /usr/lib/prosody/core/stanza_router.lua:128: in upvalue 'core_process_stanza' /usr/lib/prosody/modules/mod_s2s.lua:818: in upvalue 'func' /usr/lib/prosody/util/async.lua:149: in function </usr/lib/prosody/util/async.lua:147>

---
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