'Hidden' Authenticatd Onion Services

The Problem

Ricochet-Refresh has an issue where anybody who knows a user's onion service id (eg the Ricochet-Refresh user name/handle) then they can cyber-stalk said user by attempting to connect to the onion service (see https://github.com/blueprint-freespeech/ricochet-refresh/issues/73 for a more in-depth description).

Gosling is meant to partially rectify this problem by using multiple onion services (see https://github.com/blueprint-freespeech/gosling/blob/main/docs/protocol.md for architecture info) but still has this issue in the case where a previously allowed contact is blocked and their onion auth key is revoked. The blocked contact can still cyberstalk the user so long as the endpoint server they were given is still in use. This can be mitigated by giving every single contact their own endpoint onion service, but past discussions have indicated this would be bad for the tor relays to maintain so many onion services.

What I'd like

If an onion service is running but requires an auth key to decrypt the service descriptor, the tor daemon helpfully notifies a client that (via a custom SOCKS5 error). This is great UX for connecting to authenticated onion services in Tor Browser (as with OnionShare for example), but less than ideal for the above-described scenario.

It would be nice if it were possible to have a 'hidden' authenticated onion service (lol I know) which a user would only be able to confirm the existence of if they are allowed access via onion auth. So if a user does not have a valid auth key, they should not be able to determine if the service is running.

I have no idea if this is possible given how v3 works, but something to think about for the future maybe?