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

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.

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

@mariusor @strypey once a server receives a message, from then it is out of your hands. Anyone telling you otherwise forgets that the byte sequence is then that server's to do with what they like.


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

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!