Thanks!
- automating badge rejection at the relay level
- apps verifying the tree up to 2-3 levels
I'm wondering if "just" a combo in that vain could be enough and avoid cryptography schemes.
Thanks!
- automating badge rejection at the relay level
- apps verifying the tree up to 2-3 levels
I'm wondering if "just" a combo in that vain could be enough and avoid cryptography schemes.
someone has raised an issue about mute lists and it occurs to me that bloom filters could replace explicit lists. more compact data-wise and more obscure in that you can't know if you are on it without testing the filter on your key.
a replaceable event containing a bloom filter could be used for the case you describe.
i'm also going to ponder this idea for a secondary mechanism for defining mute lists on #orly because it is possible to define this event kind as privileged so only the relay can read it as well as the author
Yeah, I am across bloom-filters several times the last week's too.
Still need to grasp its application more to cases like this.
well, i think that it's not really useful for one-off stuff like relay configurations but for distributing them it might make sense, as it saves some on bandwidth. but i'm not seeing a strong case for this. events are not that big in data size, especially not when encoded as raw binary. typically follow lists are like 1/4 or less the size of the json