ok so, i think my ideal implimentation would be this: your instance acts as a post office.
your client addresses things, under the hood, to 'everywhere you havent blacklisted, and also where the instance has blacklisted' unless you specify it only to go to specific addressees (followers, mutuals, @)
this also would make it easyish to impliment local-timeline-only posts, or cluster similar-minded instances into 'herds'
blacklisting is ideal here because, if nothing else, the sheer ammount of CPU load whitelisting would cause if you wanted to federate to all of mastodon but nowhere else
@cadey its not string comparisons as much as if everyone is doing this -- current stuff is already hard on things
@cadey which is to say, its more requests than it already is, so the less the better
@geekylou yeah but in my example here its allowing finer grained control for the user than just all of mastodon
@LogicalDash i made like nine statements can you be more specific?
@nire why would a whitelist be more cpu load?
@LogicalDash I mean i guess it could be a bit you could flip, its just that in most people's usecases the whitelist would be more populated than the blacklist
@LogicalDash but im already assuming at volume its going to be an issue if running instances already have problems with that, though maybe most of the CPU load deals with the federated timeline. I havent checked in a few months, as I no longer can run my own instance for testing
@LogicalDash but its not just string compare, its string compare and, "I am flinging this there", instead of just flinging it to @-s and the entire universe sans silenced places
@LogicalDash which has to be on a per-post basis now, instead of just, dont fling at all to those places
@nire [citation needed], string comparisons are really cheap.