Okay, I need a reality check about how defederation works:
Say, Instance A defederates from Instance C, but there is an Instance B that federates with both.
Can people with accounts on B boost toots from people on A into timelines of people on C?
Can this happen the other way: toots from C boosted by B into A's timelines?
@rysiek Assuming signed fetch is enabled, here's what I understand should generally happen:
A makes a post, may send it to B, does not send it to C
B boosts the post from A, it may send the Announce activity to C. The activity can contain the actual object (idk if any software does it like this), but can also just be a reference.
C will see the Announce activity. It does not yet have the object itself, so it needs to get it somehow. If the object is embedded in the activity, it can't be sure that the object (who belongs to A) is not tampered with, so it will try to fetch it from A. If the activity only contains a reference, it will also try to fetch it from A. So in any case, C should try to fetch it from A.
If A has signed fetch enabled, then C needs to authorise itself, meaning that A knows it's C who fetches, and thus A can decide to not send the object. So no, in this case it's not generally possible for B to boost it into C's TL's.
For the other way around, no. When an object comes in from C, A will simply ignore/drop it.
Some things to note:
Without signed fetch, A won't know who tries to fetch the object, so C will just get it and thus it will show in the TL's (and thus, yes, in this case it's possible for B to boost it into C's TL's).
Signed fetch can be worked-around easily with accept-by-default federation (what basically all server do). E.g. If the admin of C really wants, they can get another domain that isn't blocked, and change their instance code so it pretends to be an instance on this non-blocked domain.
While the post wont show on C, there's still a meta data leak. In this example the Announce activity (which, without the object, won't normally be shown on TL's), but it can also be a reply. In that case the post itself wont show, but the reply may provide info about the content of the post.
I'm speaking generically, not for one specific implementation.
I thought that you could pass around activities signed by their actors (I recall a mechanism called Linked Data Signatures, but now when trying to look it up ended up in a maze of specs, all different: its spec was apparently subsumed by https://w3c.github.io/vc-data-integrity/, which uses some terminology that's confusing for me at first glance). Do I recall correctly that one could do that in principle in APub? Do you know if anyserver does that?
@robryk @ilja @rysiek By the knowledge of year 2019, Mastodon has implemented support for LDsigs as well as HTTPsigs (ephemeral signatures, fetching from origin required), while Pleroma (and thus probably Akkoma) only implement HTTPsigs.
One way for preventing post verification for blocked instances despite signed object announces would be preventing the blocked instance from retrieving the user key. But keys are public properties of a user profile right now.
->
@robryk @ilja @rysiek
We probably need to face that there's no such thing like "almost-public posts".
The only thing we can achieve is preventing interaction below our post – at least on our own instance and on the ones of our followers, as we won't relay these replies to all our followers like done otherwise.
I would dearly like to see more ActivityPub clients as opposed to Mastodon clients, and with the current sad state of proxy fetching anything not publicly fetchable is hard to observe for such clients. (Sure, they'd need the rest of c2s implemented to actually write something, but readonly ones are already pretty useful.) Thus I'd really like us not to do mostly-ineffective public-except-for-blocks posts, because they're not public enough for such clients to see them but also don't help that much against the original problem.
