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.
@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.
@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.
> ActivityPub offers the possibility of private interactions
The keyword there being "possibility". The fediverse, as currently implemented, is primarily a public-facing microblogging network, with a few multimedia add-ons like #PeerTube and #Pixelfed (and very soon #FunkWhale). If there's anything to be learned from the history of social media, and the rollout of Mastodon's DMs, we need to be very careful about adding "private" functionality, and make sure UI promises are kept.
@strypey and this is why people need to stop looking at Mastodon as being the all encompasing solution for the fediverse's future and start doing their own things, or support those who do. :)
@strypey they're not allowed to have opinions on how the fediverse works and should work if they can't program it themselves?
Contrary to your belief, AP devs CAN do something to prevent block circumvention. And today it is way easier to circumvent blocks than going to the web pages of everyone you want to stalk, and that can definitely be fixed.
Plus, making it harder to circumvent is still valuable for people being harassed even if it's not perfect.
> they're not allowed to have opinions on how the fediverse works and should work if they can't program it themselves?
If you say so, but this has nothing to do with what I'm saying. Which is that users can help themselves more by selecting the right tool for the job, than by complaining that the screwdriver devs have made isn't very good of hammering in nails. The rest of your comment pointedly ignores that people have the options mentioned in the follow-on post, so we're done here.
@strypey group chats is in no way a replacement for actual privacy in microblogging.
The problem as I see it is that there ISN'T a right tool for the job right now, and mastodon is the bedt approximation right now, so of course, that's what people want to improve on.
> group chats is in no way a replacement for actual privacy in microblogging.
I don't understand what you're arguing here. Can you clarify?
Here's the situation. The fediverse - at it's current stage of development - does not do private content (even Mastodon DMs are not reliably private). At some future time, hopefully it will, but for now, it doesn't. Anyone who wants private discussion needs to choose a different tool or be disappointed. That's just the technical reality.
@zatnosk as such, inflammatory demands that we burn down the fediverse because it doesn't offer the privacy tools people want *right now* is ... well ... a bit like buying a second hand analog TV and throwing a tantrum because it's not digital.
@strypey they only said to burn down the protocol if the issues can't be fixed. So we fix the privacy issues, and noone wants to burn anything
> we fix the privacy issues
That's not an accurate description of the situation. Privacy features can't be "fixed", because they are not present in any existing AP apps, and have not even been promised, except as a potential future evolution. So like I said, anyone expecting privacy features from AP apps has chosen the wrong tool. Don't get me wrong, I'm all for adding carefully designed privacy features to the AP fediverse. But this can't be done quickly *and* effectively. Pick one.
@strypey I said "fix privacy issues" not "features". As in, we need to fix the privacy issues that exist from how we currently use AP. Noone said it would be easy or quick, but it still needs to be fixed, and it needs to have as much support as we can gather, since that makes making huge changes like this less painful.
Choosing AP and expecting privacy is not a wrong choice - it's a work in progress, and we can't wait for a perfect tool before we start using what we have.
> I said "fix privacy issues" not "features"
I can't understand how there can be privacy issues if there are no privacy features to have privacy issues with. The issue is that people are expecting privacy from a publishing tool.
> Choosing AP and expecting privacy
... is like broadcasting a TV channel and expecting total control over who can see it.
We seem to be going in circles. I guess we'll have to agree to disagree on this :)
@strypey AP is so much more than a publishing tool. Just the fact that you can choose not to address the public, means that there is intended to be some sort of privacy.
But if you insist on reducing AP and everything the fediverse can do to "publishing stuff to be read in browsers", then sure, we have nothing to discuss.
Your TV metaphor is lacking:
AP is both many-to-many and two-way communication.
TV is one-to-many and one-way, so "publishing" is all it can do.
Perhaps this is the source of our misunderstanding. This:
> you can choose not to address the public
... is a feature of Mastodon that's not yet available in most other fediverse apps. Like a lot of Mastodon's feature, it's been rushed out without proper testing, and with very little consideration for how it might be handled (or not) by instances of other apps. This is not an AP or fediverse problem, it's a Mastodon workflow problem, which "burning down" AP cannot and will not fix.
@strypey the To and Cc fields are a core part of the activitypub protocol. Addressing specific actors without addressing the public is not a mastodon invention.
It might have been a mastodon hack in OStatus, but that is not the case in AP.
I'm pretty sure Nextclouds filesharing make good use of To and Cc fields as well, without making everything public.
@zatnosk right, this was my original point. The problem is not AP or what it allows *in theory*. The problem is the limitations of the current implementations of AP - a 1 year old spec - in existing fediverse software. Recognizing these limitations, a sensible user will have their sensitive community discussions on a platform that has reliably functional privacy features, like the ones I listed. Or they could throw a tantrum *shrug*, whatever floats their boat. Good chat :)
@strypey the "sensible community discussion" you talk about is closer to "trying to exist in a public space while being part of an oppressed minority". We're talking of preventing block circumvention, which is primarily a tool of harassers.
And again, there is no perfect alternative, so people use the best approximation. Private group chat can't replace safe microblogging. AP based microblogging need to improve, because it is lacking, and there is nothing better available.
> Private group chat can't replace safe microblogging
I don't understand why. Can you expand on this? What does group chat lack that microblogging provides?
@zatnosk but again, I think we're talking past each other. I'm talking about selecting from the existing software choices, based on the your needs. You're talking about future development and how it could (and hopefully will) fulfill needs it currently doesn't, and can't without some major infrastructure upgrades, on multiple volunteer-run software projects, requiring coodinated rollouts so it all works as desired. Which takes time, not flame.
@strypey you're probably right in us talking past each other. Let's just stop here then. I hope you have a good day :)
@zatnosk you too. Thanks for the respectful discussion :)
@zatnosk BTW ...
> the "sensible community discussion" you talk about
If you check the thread you'll find I I never said the words you're quoting. Putting words in people's mouths doesn't help facilitate friendly communication :/
@strypey sorry, I mistyped, I meant to quote you for "sensible community discussion". I'm not trying to put words in your mouth :)
@strypey I agree that the #Fediverse should be for public content. For publishing snippets for the world to see or perhaps a limited audience but never snippets that contain any sensitive information.
#XMPP and social networks built on it, like #Movim of #SalutAToi, are better for private social networking. Even though I recently discovered #ScuttleButt, which seems even better for private socialing!
@stevenroose You didn't mention #Zot, which has already demonstrated some solutions for federated privacy that AP devs can learn from. See the ensuring thread(s). I think the fediverse can become a full FB replacement, and that means being able to reliably convey private data privately (ideally with #E2EE). I just think it's disingenuous to pretend that we're already there. We're not even close yet.
@strypey It would be cool to see a more Facebook-like social network built on AP. Diaspora has a more Facebok like UX.
@stevenroose I want to say "have you actually used #Diaspora?" then caught myself and realized that could sound more aggressive than intended ;) But that's something people are always saying, and it really isn't true. Diaspora is pretty similar to Friendica, a federated blogging platform with a few options for posting to public/ private/ select subset of friends. It doesn't have any of the feature that make FB distinct; live chat, events invites/ RSVPs, etc.
@strypey I used Diaspora for a few months several years ago. The interface felt a lot more like Facebook. Timelines, one single feed with posts and comments on them.
Now just as then, the discussion fails to address the root causes.
As those in the spying, subversion or terrorism businesses might know, private & confidential communication is extremely hard and inconvenient. By its very nature as a social act, a pure technological solution does not exist.
The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!