Alex on Nostr: > relay policy is hard to infer via nip 11 Yes, absolutely. I was just working on ...
> 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...
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...