(Re)subscribing gets us a %contacts update, containing the full set of
contacts as it currently exists.
Previously, we would fully delete our local state, only to recreate it
using the data from the update.
Now, we never delete existing data, instead only creating if we don't
have it yet, and adding, removing or recreating contacts if they
changed.
In the future, we'll want an easy way to turn two contacts into an %edit
diff, to let us apply correct semantics to individual contacts, too.
Instead, %bundle and %add if we don't have the group locally yet,
or %add and %remove whatever the difference is between the local group
and the group as specified in the %path update.
In both, we make clear that the wire is always of the /@/group/^ form,
and alias the "group path" portion of the wire for clarity.
For kick, more obviously reuse the same wire, don't reconstruct it.
For watch-nack, only delete from the synced map if the source of the
watch-nack is still relevant. While we don't expect this to be relevant
considering current mode of operation, this does protect us against
strange cases.
Instead of going purely off metadata, we now track the collections we're
listening to, and allow the user to remove collections from that list.
This allows us to remove/ignore collections, without mutilating group
assocations locally.
We were taking care not to re-add something to our data store if we
already had it in there, but were still sending out an update
regardless.
With this, we only send out an update if we weren't previously aware
of the content.
Makes it so that |cancel %force skips the next thing in the queue if
you're not in the middle of something. If you are in the middle of
something, it skips the thing you're in the middle of (just like naked
|cancel).
This should resolve issues where |cancel doesn't drain the queue.
Considering some of the options here were atoms, not cells, $% wasn't
appropriate, and led to *etyp:abi:ethereum resulting in ford %ride execution
failure. Simply using $? instead would result in a fish-loop, so here we split
the atom cases from the tagged union ones with a $@.
Previously, the pretty-printing for %incoming and %outgoing results was hanging
on to and displaying irrelevant type information: "_list_ of subscriptions",
"wire with _head and tail_", and so on.
Here, we move to producing tangs, instead of vases, and print those. For the
%incoming and %outgoing cases, we print a line for every subscription, sorting
them by path and wire respectively, and giving clean, easily readable output.
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.
* 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.
In many cases running without %force is insufficient because ford
crashes while unsubscribing. This should fix some cases of OTAs being
received but not processed.
We have three stacks: the hoon stack, bar stack, and duct stack. This
turns the bar stack to a list of ducts and adds it to the hoon stack.
This tells you the ducts of the moves that caused the move where you
crashed.
See:
recover: dig: intr
crud: %belt event failed
bail: intr
bar-stack
~[
~[/g/use/spider/~zod/build/~.dojo_0v5ogno.5anji.vn3f6.4gs7t.6r2ft /d //term/1]
~[/d //term/1]
~[/g/use/spider/~zod/find/~.dojo_0v5ogno.5anji.vn3f6.4gs7t.6r2ft /d //term/1]
~[/g/use/dojo/~zod/out/~zod/spider/drum/wool /d //term/1]
~[/d //term/1]
~[/g/use/dojo/~zod/drum/hand /d //term/1]
~[/g/use/hood/~zod/out/~zod/dojo/drum/phat/~zod/dojo /d //term/1]
~[/d //term/1]
~[//term/1]
]
call: failed
/~zod/home/~2020.3.17..23.14.11..50e0/sys/vane/ford:<[6.128 3].[6.220 5]>
/~zod/home/~2020.3.17..23.14.11..50e0/sys/vane/ford:<[6.129 3].[6.220 5]>
/~zod/home/~2020.3.17..23.14.11..50e0/sys/vane/ford:<[6.132 3].[6.220 5]>
...
Gives you a poor man's progress bar. For example, to determine how much
of an OTA you've downloaded from your sponsor, run:
|ames-sift (sein:title our now our)
|ames-verb %rcv
and then to turn it off:
|ames-verb
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.)
This lines up the input with the "Set location" button,
and makes the latitude/longitude setting error
more concise, in order to fit within the tile without overflow.
This commit also removes some Tachyons-specific CSS classes.
Adds a `[%spot *]` type to the `note` type annotation definition.
These are added when the %dbug hoon is encountered. Done to enable
jump to defintion in the language-server.
Specifically, this commit removes the add action from the contact-view
and replaces it with a listener within contact-hook for additions
to groups. This means that when a ship is added to a group that the
contact-hook is watching, the ship is automatically sent an invite to
join that "managed group" from the contacts application. This also
includes the UI integration work on the management screen and settings
screen for working with the new group / permission structure.
On the frontend, updates the route path to include the (base64-encoded)
url. Uses that and the load-single functionality to support loading
directly into a submission page, which fetches just the requested
submission.
Also ensures we don't open duplicate comment subscriptions.
Base64 encoding isn't actually @ta-safe, since it contains capitals and
=. +wood escapes all such characters explicitly. The result is more
readable and more hoon-native paths, but does mean clients will have to
re-implement +wood locally.
