I would not consider that shadow banning or even banning. The user had their notes accepted by some relays. I think the lesson here is that relay management needs to improve. The UX is lacking as evident by his experience. 

 Since amethyst has the inbox model I often see my posts getting delete. I don't understand it at all.

It's like witchcraft for me at this point  

 At the end of the day relays are really just redundancy servers but with lealy abstraction in the nostr eco system. Unless some clients come up with a brilliant GUI for it, then most user's won't understand it.

The client question is how much hand holding should be done or not.

I agree more could be done in the relay info department, for users. In most cases they are quite tricky to know anything about on the client side. 

 i think relay management, gossip model, finding relays with less spam, dm relays, .... all these are pretty overwhelming for users. things should be much more easier. relay management should be automatic... nostr heads should really think seriously about user experience and making things a lot easier. i don't know how many people will find nostr quite complicated and leave.. 

here is an automatic relay algo: 
1. post to as many relays as possible. 
2. read from some relays. if a user marks a note spam, remove that relay that carried the spam or reduce the score of that relay. when score is 0 remove the relay.
 

 > 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. 

 It was me.