Downgrades unmanaged chat paths to their uglified versions, as used by
web chat. Removes "group-based" indicators and makes them implicit in
shorter paths instead.
Under mysterious conditions, chat-cli might get into a state where its
rendering width is set to zero. This makes sure we set it back to 80
if that's the case.
This commit is mostly just precaution.
This reverts commit 046506f9d4, reversing
changes made to 6ef08962ef.
I'm reverting this as we're moving to a new branch/release model in
which breaching changes (as this one is) will live on a long-running
'next' branch, rather than alongside non-breaching changes in master.
This revert should itself be reverted on the 'next' branch.
It was filling the number.envelope prior to adding the envelope to the
mailbox, but wasn't actually including that change in the %message(s)
update that was getting sent out.
This makes +append-envelope return both the updated mailbox _and_ the
modified envelope, which we then use in our outgoing update.
During upgrade, we gassed _in_ a map, instead of _by_, causing it to use
set-style sorting, leading to incorrect lookups.
This fixes that upgrade logic, and re-builds the map for existing instances.
+dbug [%state 'some-hoon'] now allows you to run some-hoon against the
application's state. That hoon has access to the bowl and stdlib for
more dbugging convenience.
Was using "manual" scries, and incorrect ones at that. Would crash, causing
subscriptions to not go through. Now uses the helper function and correct paths.
Re-enables chat creation, touches up invite logic, and makes everything
work with the new "un/managed" attribute of chats.
Changes the +target type, so requires state transition. We use that
opportunity to clean up our messages mirror (memory reclamation).
"Unmanaged" chats should work the same as they did before.
Group-based chats are secondary citizens, but supported by prepending
"group " to whatever target you want to use. ie:
;join group ~marzod/secret-club :: join a group-based chat
;group ~marzod/secret-club :: target a group-based chat
The latter case should be rarely needed, as glyphs remember this
attribute of their bound target.
Creating a group alongside a chat is supported through:
;create village-with-group /cool-kids
You can then invite to that group (and by extension the associated chat)
by doing:
;invite group /cool-kids ~rinsed-walrus
To 30 blocks + 30 blocks + 0-5 minutes == about 15 minutes total.
Further reduction should be possible, but requires changing the
algorithm a bit. We don't want to reduce the number of confirmations
below about 30, though, since we don't handle reorganizations well.
See #2414.
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
* master: (484 commits)
king: Slight CLI cleanup and fix test build.
king: Add command-line flags to configure HTTP and HTTPS ports.
groups: reduce metadata updates, removal
chat: reducer handles metadata removal
groups: exclude group metadata from channels list
groups: set and surface group name metadata
groups: remove dummy 'share' flow, 'default' group
contacts: rename, migrate '~contacts' to '~groups'
sh/release: rename vere release tarballs
vere: patch version bump (v0.10.3 -> v0.10.4.rc1) [ci skip]
pills: updated brass and solid
chat: pull room contacts from associated group
chat: spell 'permanent' correctly
eyre: remove padding from 'access' input
chat: only delete metadata for a chat if you created it
chat: settings inputs add borders on focus
vere: disables gc on |mass in the daemon process
chat: remove console.log from metadataAction
chat: style fixes during review, use metadata-hook
chat: edit description, color settings
...
* origin/os1-rc: (439 commits)
pills: updated brass and solid
chat: pull room contacts from associated group
chat: spell 'permanent' correctly
eyre: remove padding from 'access' input
chat: only delete metadata for a chat if you created it
chat: settings inputs add borders on focus
chat: remove console.log from metadataAction
chat: style fixes during review, use metadata-hook
chat: edit description, color settings
chat: add update-metadata to metadata reducer
chat: revise api.js to match data structures
metadata-json: add json to action parsers
chat: construct settings page for metadata
chat: correct bottom border on join links
chat: copy shortcodes
chat: linkify unmanaged chats
metadata-hook: support group members other than host creating shared resources
contacts: add bg-gray0 to root page
chat + contact views: updated for style and to assert that group-path must be equal to app-path if there are ships in the members set
contacts: changed color + copy of "add to group" button
...
- finds resources & displays details using metadata-store
- supports creating new collections for groups
- supports creating new collections with new unmanaged group
- supports receiving invites for new (unmanaged) collections
In order to track & respond to all group-related metadata, hooks may
want to subscribe to the metadata-store in response to group creation.
In that case it is possible that there are no entries for the group-path
in group-indices yet.
This makes us fall back to the empty set in case group-indices has no
entry for the group-path yet.
The previous Tile.png for the Dojo module (Soto) was a stylized rendering of "barcen" and could be seen as confusing. Fixing up the image to appear more *actually* glyph-like.
* origin/ted/ford-no-pit:
pills: update solid
http.c: revert timeout to original ~m10
tests: prime ford %reef cache
http.c: bump timeout from ~m20 to ~m30
http.c: bump timeout from ~m10 to ~m20
tests: fix ford tests for no %reef short-circuit
ford: remove pit short-circuit
* liam-fitzgerald/hoon-spot:
hoon: toggle spot typehints on flag
hoon: support %spot hint in xray
hoon: add %spot typehint
Signed-off-by: Jared Tobin <jared@tlon.io>
In order to track & respond to all app-related metadata, hooks may want to
subscribe to the metadata-store as the first thing they do on-init. In that case
it is exceedingly likely that there are no entries for the app-name in
app-indices yet.
This makes us fall back to the empty set in case app-indices has no entry for
the app-name yet.
Basically, this PR includes a collection of edits made to the headers across each of our OS1 modules.
I flattened the font sizing, fixed edge margins/padding, and fixed some button copy in the case of the Contacts app.
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.
If we %add-owned, then we add an entry to the access-control jug matching the
data we put into the synced map. When a permission gets deleted, we remove it
from synced, but previously neglected to clean up the matching access-control
entry.
This ensures that if a permission was deleted, and we had it registered as
owned, that the relevant access-control entry is removed from state.
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.
We may %hear or %read content that was posted some time ago, so we need
to make sure we add it at the appropriate position (wrt timestamp)
rather than just sticking it at the head of the list.
Shortcuts the existing retry timer by having new members send out a poke
when they acknowledge joining the group.
The existing retry logic is left in place to deal with other cases of
subscription failure.
Also fixes an incorrect relevancy check during subscription retries, now
properly preventing duplicate subscriptions.
We were scrying for /gx/path instead of /gx/=link-store=/path.
In the %annotations case, that path wasn't even correct.
Also refactors scries out into a +scry-for helper.
* origin/philip/gall-ack-fix:
gall: give both acks in case of unexpected ack
gall: make 2140e07 ota-able
gall: properly track remote acknowledgments
Signed-off-by: Jared Tobin <jared@tlon.io>
It's hard to say what's the safest thing to do when we get an ack we
weren't expecting due to losing outstanding.agents.state in +load
3-to-4, so this gives both a watch-ack and a poke-ack. This seems most
likely to succeed.
Does not change state type, but clears outstanding.agents.state since
it's full of garbage values. This introduces a possibility that we may
have been in the middle of something, so we handle that in a reasonably
sane way.
outstanding.agents.state is a queue of what sort of message we sent to a
foreign app. We use it so that when the acknowledgment comes back we
know whether to treat it as a watch-ack, poke-ack, or neither. We used
to put this info in the wire, but this gave us a different ames flow,
which meant %leave and %watch didn't get associated (causing #2079).
The error was that when when retrieving the item from the queue, we put
the new 1-item-shorter queue back in outstanding.agents.state at a
different wire than it came from, so the queues never actually got
shorter, and acknowledgments of the wrong sort were commonly produced.
This caused problems mainly in situations where we poke and peer on the
same wire, and possibly when a subscription was cancelled.
Possibly related to #2206 and #2176. I would expect this bug to cause
those issues, but I haven't verified the converse. Also possibly
related to #2153 and #2079.
"Replace" suggests this function either produces an updated set/map when done,
like +snap, or changes all values in-place, like +turn. In truth, it's more
similar to +roll, which does reduction/accumulation.
("Reduce" specifically was chosen because it maintains the mnemonic relation to
the arm name.)
