If chats with identical resource paths were created, that would result
in chat-hook seeing updates twice.
These "/mailbox wire sub to local chat-store" subscriptions aren't
created by the current logic anymore, and as such any existing ones
should be eradicated.
chat: ota attempt
chat: ota triggers chat-store to tell chat-hook to send cards to update chat-store's state
contact-view: commented out avatars and base64
chat: cleaned up commits
If we don't host a group, we can't (locally) delete it, but we do still
have a permission-hook entry we want to clean up. This does that
deletion, but still relies on the permission-hook logic to clean it up
in the local group case.
Permissions for the new group need to be exposed to the members of those
new groups. This makes the on-migrate logic poke the permission-hook for
that.
This temporary, upgrade-oriented logic depends on two assumptions:
- If the metadata-store is not running, we are still in the process of
applying the upgrade.
- If the above is true, all chats are /~host/name, all groups are
/~/~host/name, and they have a strict one-to-one relation.
Armed with those assumptions, we can deduce groups from chats and vice
versa without depending on the metadata-store, allowing us to carry on
as if it were already running.
We want to move from group/permission paths of the form /chat/~host/name
to /~/~host/name, merging the ./read and ./write permission paths into a
single permission matching the group path.
(The leading /~ signifies an "unmanaged" group, one used by apps
internally, and not explicitly exposed to the user as a contacts group.)
This upgrade logic does roughly the following, for every chat path, to
accomplish the migration:
1. delete ./read and ./write groups associated with the chat
2. create a new group containing an approximate "uni" of the old groups
3. register the chat + new group with the metadata-store
4. hook the group up to its matching permission set
Note that because existing groups are hooked up through the
permission-group-hook, doing step 1 deletes the associated permissions.
Step 4 then re-establishes that relation for the newly created group.
The logic here scries into the metadata-store, and as such depends on
that having been started prior to this upgrade process.
When permissions change, find out which chats are impacted (on the
assumption that permission paths are group paths), then perform actions
wrt that chat accordingly.
When a chat is interacted with, find out which groups the chat is
associated with, then use those to perform permission checks. If the
check passes for any group, permission is granted.
Instead of providing a (unit path), allows for (list path), which better
supports the "update to path and subpath cases".
For example, if /things wants updates about everything, and
/things/specific wants updates about the specific thing, they'll both
need to receive a %fact when the specific thing changes.
Previously, these would have been two separate moves. Now, gall handles
the multi-targeting for you.
