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.
Introduced in #2546, the new functionality seems able to induce weird
behavior causing messages to be processed twice. Disabling this
functionality on the frontend until that has been fixed.
When you were looking at your own card in another group,
it would say "Remove from" group. This is from an arbitrarily strict
ternary check that adminOpt catches
for us, so we just check if the ship is us.
Before we saw if window.ship was in the path of the group.
If you're a star or higher, you'll match many group paths that you don't
own. This strengthens the check.
We were looking for the box in our contacts object, not the associated
group, so if you had a group and chat with the same name,
you'd see nicknames, but in no other situations. This commit rectifies
that by safely polling for the associated group of the chat.
* origin/mp/publish/new-button:
publish: prevent submission of empty notes
publish: add responsive width for new post button
Signed-off-by: Jared Tobin <jared@tlon.io>
* origin/m/chat-groupify-extra:
chat-view: %delete even without association
frontend: apply ec6c2ed69 to link, publish, groups
chat fe: clarify copy
chat fe: support adding chat to existing group
chat fe: invite search with/out ships
chat-view: allow %groupify into existing group
chat-view: add docs for %create action
Signed-off-by: Jared Tobin <jared@tlon.io>
When a ship breaches, we remove all messages that have yet to be
delivered to an app (eg if it's not yet started). We also add
|gall-sear to do this manually, but this shouldn't be needed in normal
operation.
Finally, to unblock ~zod and ~bus on mainnet, we sear one particular
ship automatically on loading hood. It cannot be done manually because
no userpace changes can be made until it's unblocked.
Previously, running %delete had a hard dependency on a (metadata-store)
association being present for the chat. If a remotely-hosted chat got
deleted, that would delete the association, preventing us from deleting
the chat for ourselves.
Now, we simply neglect to do related metadata deletions if no
association was present in the first place.
Using the updated chat-view %groupify action. Groupifying without
selecting a group creates a new group based off the chat. Selecting a
group first makes that the target of the group, and allows you to
specify whether to merge ships from the chat into the group.
