I feel that the max settings imposed by the 50k max size limit, will satisfy most crazy hidden service use cases that someone might have wrt scalability or number of authed clients. It can support up to 350 authed clients, and 20 intro points. We should increase the max size limit, if we want to support more advanced use cases.
I also feel the configurations that fit in the default descriptor (of 10k bytes blob) will probably satisfy most hidden service use cases out there as it can support up to 80 authed clients, and up to 11 intro points. The anonymity set of those hidden services descriptors will be good wrt snooping HSDirs
Giant hidden service descriptors will stand out and their anonymity set will likely be small. I think such giant hidden services should perhaps split their info to multiple descriptors using some sort of stealth-auth mechanism (where they give different onion address to different clients). Alternatively, we should change our padding rules, or always pad to max descriptor size.
I understand what I'm saying below might be a bit far fetched but while we're brainstorming on things, I thought I'd just throw this out...
I think it would be interesting to see things like onion-balance get integrated into this setup at some point in the long run, so if there's a giant onion service, it would automatically scale after a certain amount of clients or requests. I haven't thought much about how it can work in auth mechanism but I find it an interesting subject to think about. Specially if we want to mainstream the heavy use of onion services.
Kudos for working on such important properties of Tor.
Cheers,