Some people seem blissfully unaware that the #fediverse is a federated social *web*, the whole purpose of the tools is to publish stuff for any web user to see. Instead of choosing the right tool for their needs, these folks want us to ...
> burn activitypub to the ground and start over
Whatever AP devs do, determined BadActors can easily circumvent blocks by going to the web page of your feed. What people looking for private discussion spaces need is something like #jabber #MUCs, or #Matrix rooms, or #Wire group chats, or #Crabgrass groups, or private Discourse instances, or any one of dozens of other free code tools that exist for private group discussions. But no, they demand we turn the fediverse into those to suit their use case.
@strypey where activitypub stops being useful is when servers don't propagate properly the Moderation/Deletion activities of users. Say I Create an Object that is privately sent to 2 people on 2 instances. If I then Delete that Object but one of the instances doesn't accept the Delete activity, it means that the Object (in its original form) will still be accessible to the person on that instance.
I think this is what kanini and cwebber are trying to find solutions for.
@strypey my personal opinion is that any solution that they would find (be it OCAP) or something else, it would introduce _a lot_ of extra complexity to an already complex specification. And I don't think it's worth it.
Yes people (malicious or not) will have access to older versions of your content... but hell, that's how the "web" works as you put it, and it should be expected, even if it's not the best outcome.
@arjen right, which is why Zot doesn't send the private content to the receiver's server, it sends an address to the receivers server, which allows the receivers client to view the content on the sender's server. It's not a perfect solution but better, for reasons discussed here:
@arjen but is there a distinction between "server" and "client" in this context?
> where activitypub stops being useful is when servers don't propagate properly the Moderation/Deletion activities of users
AFAIK #Zot solves this by keeping private content on the sending user's server, and giving receiving users a recallable permission to view it there. If the sending user deletes it, it's gone. Once you send a copy of content to another server, however you might tag it and ask receiving servers to handle it, you've lost any guarantee of it remaining private.
> AFAIK #Zot solves this by keeping private content on the sending user's server, and giving receiving users a recallable permission to view it there
I am not sure of the exact mechanism, but it doesn't sound like a good option to me. Once someone can _view_ it, that means they now have a copy that needs not conform to the ulterior actions of the owner: delete, hide, etc
I don't think there's any mechanism (outside of DRMed hardware maybe) that can circumvent this issue.
> Once someone can _view_ it, that means they now have a copy that needs not conform to the ulterior actions of the owner: delete, hide, etc
In theory, sure. Ideally, if they implement the protocol, that copy is perishable by nature. If they don't implement the protocol, they don't get access to the private data. Either way, it's still an improvement on sending out N copies of private data for permanent storage on other servers, and then hoping they honour requests to delete etc.
@strypey what I'm saying is that to my knowledge there is no way to enforce "persihable by nature" copies.
All of this relies on the services and clients honoring the contracts of not storing local copies outside the context of "perishableness". Which is also the current state of activitypub.
It's a sad situation, but I don't think there's any (current) way around it. I would be glad to be proven wrong.
@mariusor I think the difference you're glossing over here is important. In AP, by default, any post is sent to the server of the remote users who are following and/or addressed, for permanent storage on that server. In Zot, private posts are only sent to the browser of the user who has received permission to view them. Now, I grant you this doesn't stop the user's browser taking a copy (screenshot if all else fails). But it means delete operations don't have to propagated to multiple servers.
@strypey I'm not "glossing" over it, I find it irrelevant. Not all clients are browsers in this day and age, and any protocol that relies on that assumption is something I won't be interested in.
But if this distinction is enough for you to feel better about the security of the protocol, that's fine by me.
Also, sending just the reference of the object is something AP can do too. And if said object is properly scoped, it can only be read by clients on behalf of a valid recipient. :)
@mariusor *sigh* I'm probably explaining this about as well as a monkey explaining a pair of scissors, but ...
> Not all clients are browsers
Splitting hairs much? ;) Swap in "client" instead of "browser" in my statement. The important thing is the receiving server's only role is to hand the client an address, not the content itself.
> sending just the reference of the object is something AP can do too
AP apps *could* do that way, but it's not part of the spec (yet). It's baked into Zot.
> Splitting hairs much
Not really, I thought you mentioned browsers as clients in the idea that a user can trust their browser to respect the intent of the API concerning the access scheme of a resource.
I was trying to clarify that a user can never be sure a client will do the right thing in this respect, and with untrusted clients comes the imposibillity to guarantee privacy.
I'm going to stop here, I feel like neither of us is bringing enough supporting evidence for this. :)
@mariusor did you see my practical example? It seems like you're interpreting me as saying the Zot approach guarantees perfect secrecy. Of course it doesn't. Nothing transferred over a digital network can. I'm just saying the Zot approach has less room for both incompetence and Bad Actors to reveal content intended to be private, as demonstrated in the DM example.
@mariusor Let's look at a practical example. When Mastodon firsted rolled out DMs, they were send out to the receiving user's server the same as any other post. If the receiving server wasn't Mastodon and didn't recognize the flags that distinguished a post as a DM, it just published it to the web as a normal post. If the DM was stored only on the originating server, a receiving server that wasn't Mastodon wouldn't have understood what to do with the DM address it received, and ignored it.
Metalhead.club is a Mastodon instance hosted in Germany and powered by 100% green energy.