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'
@nire [citation needed], string comparisons are really cheap.
@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 this is similar to my understanding of the current model, I feel like I've missed something
@aeonofdiscord fundamentally so, unless you're assuming my addressing here means people you @ and then thats true... for unlisted posts
@nire okay, I think I understand
@aeonofdiscord like the problem right now is that federated posts go... everywhere but blocked/silenced servers, and unlisted posts are basically that except they dont federate (nominally...) and are shared mostly via boosts
@aeonofdiscord so it goes to followers, boosts of those people, and then, if the visibility is federated, to the servers federated with you
@nire okay, I'm confused again. I thought unlisted posts did federate (to followers) but had a do-not-display-in-public-timelines flag
@aeonofdiscord yes but who knows which not-mastodon instances support that
@aeonofdiscord which is why im using weird wording here
@nire yeah it's very hard to describe this stuff accurately
@aeonofdiscord almost like the terms chosen for it were chosen in true open source manner
@nire so the problem you're trying to solve is like
I send a toot from chillparty.social, and mark it unlisted
one of my followers on greyarea.xyz boosts it
one of their followers on badguy.zone (which is a GNU Social instance) boosts it again
and now it starts appearing in public timelines despite the flag
@aeonofdiscord worse -- you dont know its in the public TL, but it is in the ones most likely to cause harm
@aeonofdiscord fail-deadly is overkill of a term for this but its a milder form of that, instead of fail-safe where it could just... only go to followers
@aeonofdiscord if they dont support it
@nire so are you thinking in terms of metadata on the toot ("please don't send this to badguy.zone") or on the instance ("this instance supports X, Y and Z toot-privacy features")?
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