@april Do you actually want messages to be confidential?
-
@april Do you actually want messages to be confidential? Because it seems like we want different things from a federated messaging protocol. So any change I might suggest is likely not aligned with the vision for the project and I should probably just not.
-
Jenniferplusplusreplied to Jenniferplusplus last edited by
@april so that we're on the same page here, the scenario I want to prevent is 3rd parties automatically routing around blocks. Consider a star trek scenario, as an example:
B'ellana Torres follows Worf, and blocks Benjamin Sisko, because Sisko is a cop and she's Maquis.
Sisko also follows Worf.
Worf posts something, Torres responds, and Worf's server automatically forwards the response to Sisko because he follows Worf. Torres blocked Sisko, but he still gets to see her posts. This is bad.
-
April The Pink ⋆☾╶⃝⃤☽⋆replied to Jenniferplusplus last edited by@jenniferplusplus hmm yea, thats not behavior we'd want. but in this specific case wouldnt that be the implementation at fault here? also we have something similar in AP already where implementations can just decide to ignore blocks from other servers and then harass the user even more... had that with some nzs pleroma instances... anyways i might be on and off a bit because we are currently rebuilding our hackspace haha :neocat_sweat: answers might be delayed
-
Jenniferplusplusreplied to April The Pink ⋆☾╶⃝⃤☽⋆ last edited by
@april
Yes, this is behavior that's specified in activitypub. They call it inbox forwarding. It's also the worst thing about AP.But in practice, AP is defined by implementations, and http signatures (by design) breaks inbox forwarding, so it's no longer functionally a default behavior.
It's impossible to have perfect enforcement of blocks across a federated network like this. But, protocols should still do better than to automatically route around them.