The card type has changed, so we need a state upgrade. As I understand
it, these existed for a particular upgrade to get around the fact that
Ford Turbo updates apps in random order. In Ford Fusion, all apps are
started in parallel before any of their moves are emitted, so this is
no longer a problem.
Since these will no longer be needed and they don't load properly when
+card changes, we deleted them. While trying to find a bug that I
introduced, I refactored +on-load a little bit -- I can revert this if
it's confusing.
Improved the namespacing by dropping the app prefix on types, e.g.
chat-hook-action -> action. Compensated for shadowing by importing the
/sur files behind a face. End result is that a chat-hook-action becomes
an action:hook. Splits chat-json into lib/chat-{hook,store,view}. Uses
^? on changes files in /lib and /sur to discourage deeply nested
importing.
When a group is left, the permissions no longer exist and the mailbox
subscription is kicked. Before attempting to resubscribe, we simply
check if we still have permissions and if not, leave the chat.
We weren't accounting for backlog subscriptions with non-zero message
indexes in their wires. Now, we look through all of our outgoing
subscriptions to identify relevant backlog subscriptions, and leave all
of those.
The more proper fix here is to not include message indexes in the wire
in the first place, since we don't ever reuse that anywhere. But that's
a more invasive change, so we just leave a TODO for it instead.
Previously, we were removing the relevant entry from the `synced` map
before calling `+pull-wire`, which requires an entry to still be there.
This lead to subscriptions not actually being pulled, commonly leading
to "subscribe wire not unique" errors on re-join.
In addition to fixing that, `%remove` actions now try to pull the
subscription regardless of whether they have an entry in the `synced`
map or not. `%leave` is always safe, and we might want to clean up
subscriptions that shouldn't be there anymore in the first place.
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.
