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 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.
> 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.
@strypey @mariusor I've considered the problem of fediverse private messages for Epicyon, but havn't been able to think of a solution which would be more secure than the current DM implementaton. Things I thought of were:
Client side encryption
Encrypt the message using the signing keys
This seems like an obvious solution until you consider that the thread model is a rogue instance on the receiving side. Once the DM is decrypted by the receiving server the rogue instance can still do whatever it wants with the message (send it to unintended recipients, etc). So this wouldn't provide much more security than TLS.
Message is a link to the sending server, using the OCAP principle
This doesn't work either. The rogue instance can just wget whatever it wants.
Whenever you send a DM it just bridges to XMPP using a lookup table. Unfortunately this still involves private keys being on the server. the XMPP message could be sent unencrypted using TLS only, but that's no better than how DMs work at present.
The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!