There was some productive discussion this week about the remote scry protocol. Ideally, we wouldn't need any session-based protocol to ensure low latency on responses to scry requests whose paths haven't been bound yet when the publisher receives the request, and the basic protocol would handle this. The following is a sketch of a way to do this, by making scry requests for paths that are known to be part of publications "sticky" on the publisher, so they persist long enough that when the path does get grown, the response can be sent down to requesters immediately.
Subscriber sends scry request to publisher ship asking for wave n+1 of some subscription. Only waves up through n have been published, and n+1 doesn't exist yet. The publisher's Arvo had told its Vere that it will notify Vere whenever new paths are grown under a certain set of path prefixes. Since the publisher Gall is managing the publication in question (along with all other publications), it included the publication path in this list of prefixes. Vere is storing this list of prefixes in memory.
The scry request for wave n+1 matches the prefix for this publication, so Vere knows that Arvo will tell it when it exists. If this is the first request the publisher has received for this scry path, then it scrys into Arvo. If it's not the first request, or if the scry into Arvo returns a block (~ -- no answer for now), Vere stores the request in its pending interest table for some amount of time -- maybe a minute -- secure in the knowledge that Arvo will notify it if the path gets grown during that interval.
Arvo would tell Vere which path prefixes are part of publications on
%born(process restart), and whenever a solid-state publication begins or ends.