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.
Better subscription path API support. Should support us better moving
forward.
Note that this kills the server-hook. It will be replaced with a
link-view shortly.
Also re-orders the comment paths to have URL first, which is easier to
handle and also seems more correct wrt the behavior you might want in
the web extension and similar use cases.
Don't include pkg/arvo/tests and pkg/urbit/tests when running
git-archive(1).
Additionally, move the export-ignore declaration for
pkg/urbit/hashtable_tests into the pkg/urbit/.gitattributes files. For
default operation, git-archive(1) requires that these declarations be
located on the tree being archived.
Removes miscellaneous files that had lingered from pre-monorepoisation:
* pkg/arvo Travis and .gitignore, .gitattributes files
* pkg/urbit CONTRIBUTING.md (subsumed by file in repository root)
Group definitions are not guaranteed to be instantly in sync between
ships, so our subscription may get rejected if we open it "prematurely".
This adds retry logic with exponential backoff to account for that case.
Due to asynchronicity, Ford can receive responses from Clay to requests
that it has already attempted to cancel. This removes some overzealous
assertions that this wouldn't happen.
Dynamically compute subject so that language server can see arms
from imports. Fall back to -:!>(..zuse) if the build is an app,
because of opaque payloads.
@ixv recently uncovered a bug (#2180) in Ford that caused certain
rebuilds to crash. @Fang- and I believe this change should fix the bug,
and we have confirmed that the reproduction that used to fail about two
thirds of the time now has not failed at all in the ten or so times
we've run it since then. @Fang- is still running more tests to confirm
the fix with more certainty.
It turned out the cause was that (depending on the rebuild order, which
is unspecified and should not need to be specified), Ford could enqueue
a provisional sub-build to be run but then, later in the same +gather
call, discover that the sub-build was in fact an orphan and delete it
from builds.state accordingly. Then when Ford tried to run the
sub-build, it would have already been deleted from the state, so Ford
would crash when trying to process its result in +reduce.
The fix was to make sure that when we discover a provisional sub-build
is orphaned, dequeue it from candidate-builds and next-builds to make
sure we don't try to run it. I'm about 95% sure this fix completely
solves the bug.
