4 ms·
> and sequentially query the first party about each of those user IDs Only if the third party is allowed to query whether there's a block between the first par
by phoe-krk 3y ago
> and sequentially query the first party about each of those user IDs
Only if the third party is allowed to query whether there's a block between the first party and the second party. If the block is only visible to the first party, i.e. there's a view filter, then there's no good way of figuring this out.
- preseinger 3y agoif a block should only be readable by the party that created it, then there is no reason for that information to be shared in the first place
- phoe-krk 3y agoWhich sort of is my point. An option to share blocking information with another (trusted?) person should be possible, but as an explicit opt-in from the first party, with the third party not being able to intercept this in any meaningful way.
- preseinger 3y agobut this is useless, isn't it? if blocking information is only available to a given third-party on an opt-on basis from the blocker, then what purpose does this information serve?
- phoe-krk 3y ago"Hey, I know that you have an extensive personal blocklist, can I take a look at it and adapt it to my uses so that I don't start from scratch?" "Hey, I know that your server has an extensive personal blocklist, can I take a look at it and adapt it to my server so that I don't start from scratch?"
- preseinger 3y agoi don't understand your point a "block list" is associated with a user, not a server
- phoe-krk 3y agoNot all are. E.g. Fediverse defederation is a server-wide block, and not all Fediverse instances are making their defederation lists public.