* origin/ames-set-port:
ames: refactors udp init() and bind()
ames: honor -p for galaxies, with warning
ames: adds port printfs for all ships
ames: honor -p for non-galaxies
Signed-off-by: Jared Tobin <jared@tlon.io>
* origin/link-full:
link-server-hook: disable verb by default
link: make network comms work
link: add minimal link-server-hook and link-webext
server: properly defined request-line type
link: social bookmarking core implementation
group-store: create, add, remove generators
Signed-off-by: Jared Tobin <jared@tlon.io>
This resolves a number of issues that were keeping communications with
foreign ships from working.
- there was no link-update mark
- there was no +on-arvo handling in link-listen-hook
- link-listen-hook was subscribing to the non-existent "link-hook"
- link-proxy-hook permission check was looking at a wrong path
Also makes link-listen-hook aware that subscriptions might get rejected
because of permissions, so that it ignores failed subscriptions instead
of being loud about it.
link-server-hook exposes (parts of) the link-store over eyre, on the
condition that the client is authenticated as the host ship.
link-webext as committed is a very minimal web extension. When its
toolbar button is clicked, it saves the current webpage to /private
in the link-store.
In the future, this should support choosing a target to save to,
highlighting already-saved pages, and many other features.
Stores URLs and their titles for the local ship. Can listen to
"submissions" on foreign ships.
Has a primitive perspective on groups, treating them as
always-interesting. Auto-subscribes to all ships in all groups.
Foreign communications untested.
Largely one-to-one port feature-wise.
Support for document polls was added.
Command preparation and verification got split out into
/ted/claz/prep-command, and got a dedicated +prep-result type to
facilitate future support for more complex preparation steps.
%leave over the network didn't work because we included the message type
in the wire from gall, so the duct for the initial %watch and the %leave
were different. We need to know the message type so we can route the
acknowledgment as %poke-ack, %watch-ack, or no-op.
This moves this piece of information to a piece of state, where we queue
up the message types per [duct wire]. Ames guarantees that
acknowledgments will come in order.
This also includes an easy state adapter. The more interesting part of
the upgrade is that we likely have outstanding subscriptions with the
old wire format. The disadvantage of storing information in wires is
that it can't be upgraded in +load. So, here we listen for updates on
the old wire format, and when we get them we kill the old subscription,
so that it will be recreated with the new wire format.
As an aside, this is a good example of what we mean when we say
subscriptions may be killed at any time, so apps must handle this case.
Finally, this fixes the "attributing" ship to ~zod for agent requests.
This information was ignored for agent requests, but including it causes
spurious duct mismatches.
We've seen issues where the message-num of the head of live.state is
less than current.state. When this happens, we continually try to
resend message n-1, but we throw away any acknowledgment for n-1 because
current.state is already n. This halts progress on that flow.
We don't know what causes us to get in this bad state, so this adds an
assert to the packet pump that we're in a good state, run every time
the packet pump is run. When this crashes, we can turn on |ames-verb
and hopefully identify the cause.
This also adds logic to +on-wake in the packet pump to not try to resend
any messages that have already been acknowledged. This is just to
rescue ships that currently have these stuck flows.
(Incidentally, I'd love to have a rr-style debugger for stuff like this.
Just run a command that says "replay my event log watching for this
specific condition and then stop and let me poke around".)
Turns out this wasn't a regression, it was intended behavior. I
continue to believe it's the wrong behavior, but that will require a
longer discussion.
