> relay policy is hard to infer via nip 11

Yes, absolutely.

I was just working on this. Look, I updated my policies to expose a NIP-11 type thing, so each policy plugin can expose to other parts of the code what NIP-11 things they affect: https://gitlab.com/soapbox-pub/nostrify/-/blob/main/packages/policies/PowPolicy.ts?ref_type=heads#L37

So in theory I could call `policy.info` of each of my policies and combine them together to display the NIP-11 info on my relay.

But in practice the combined policy has a bunch of conditions that apply under different circumstances: https://gitlab.com/soapbox-pub/gleasonator-policy/-/blob/main/mod.ts?ref_type=heads

A NIP-05 is required, but only for kind 1, 3, 4 6, and 7, and only for users who aren't in jack's follows of follows. (I ended up removing POW - there isn't even a "nip05 limitation" field yet).

What we actually need is an array of structured "rules" syntax. Deprecate "limitation" and add "rules" to NIP-11. But I don't know that a declarative syntax will ever be able to fully capture it. It would need "if" and "else" parameters, and a list of named functions that clients would need to implement. Eg:

{ if: ["match_filter", filter], then: { if: ["nip05", ...opts], then: ["ok", true] }, else: ["ok", false] }

I don't know... 

 Yeah, and compiling all this to a human-readable summary will definitely be impossible in all circumstances. I think policy might be best indicated by a combination of common, standard limitations (or rules, sure), and a human-readable description. Eventually, common configurations might be compiled into simple tags, like "paid inbox" or "fresh pubkeys". If a relay advertises that it's good for a given use case, they don't have to prove it and might not work well, but users and clients could at least make more intellligent guesses. 

 Human readable description makes sense.