Some people seem blissfully unaware that the 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
mastodon.starrevolution.org/@L
(1/2)

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 , or rooms, or group chats, or 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.

Show thread

@strypey ActivityPub offers the possibility of private interactions. Check my last posts under the activitypub tag.

In a nut shell, if your recipients don't include the public namespace, the interaction should be private - at least according to the spec. I don't know how existing implementations do it though.

The service I work on supports creating private user accounts if the Create activity for the account doesn't have the public namespace in the recipients list. It's as simple as that.

@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.

@mariusor
> where activitypub stops being useful is when servers don't propagate properly the Moderation/Deletion activities of users

AFAIK 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.

@strypey

> 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.

@mariusor
> 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. :)

Follow

@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.

@strypey

> 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.

Sign in to participate in the conversation
Mastodon - NZOSS

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!