4 ms·

So, about that federated DELETE operation. In a decentralized network, we can't unilaterally delete a shared piece of content; that is one of the main features

So, about that federated DELETE operation. In a decentralized network, we can't unilaterally delete a shared piece of content; that is one of the main features of decentralization. Even providing that verb seems kind of deceptive to me; it implies that content that enters the network, could conceivably be purged, which will affect how people use the network. Perhaps DISOWN would be a more accurate verb, especially if it would only be accepted from the original owner.

HerraBRE 9y ago
If the social contract says "delete things when you see a delete message", then that's useful in a federated environment. Only bad actors will disobey and they will have to modify their software in order to do so. This doesn't provide absolute protection against bad actors, but since most bad actors don't own a time machine, it reduces the scope of the harm they can enact. Consider the adversary "angry ex-boyfriend." Let's assume he wasn't always angry and isn't a sociopath. By the time he has become angry, the sensitive posts have already been deleted. This makes a difference in real life to real people. There is indeed a user-interface concern, to not over-promise to the end-user. But that doesn't justify leaving such a useful thing out at the protocol level.
- nercht12 9y ago
  >> most bad actors don't own a time machine You mean besides me, of course. XD EDIT: It's a joke people, for Pete's sake.
  - devrandomguy 9y ago
    Actually, this is a real issue. For one, there is the Wayback Machine, which could very well see increased usage and mindshare as legally mandated content takedowns increase. For another, if, say, Facebook wanted to harvest data from this network to create shadow profiles and flesh out missing patterns in their analytics, then they could easily follow everything, keep the raw data/content internal, and never develop the ability to retroactively un-analyze that data when a delete request comes in.
    - HerraBRE 9y ago
      This is a legitimate concern. I would not put it past Facebook (or other businesses which are addicted to harvesting user data) to behave badly against networks like this. However, for the sake of their reputations they'd still probably do it quietly, which means many of the person-to-person attacks that deletion protects against would still be thwarted. This is a problem the same way Facebook's privacy controls are a problem. Facebook themselves are not bound by them, but they're still useful if you want to protect your data from other users of the platform. And FWIW, I think most of the big crawlers respect robots.txt - this is the same sort of thing.
- beagle3 9y ago
  > Only bad actors will disobey and they will have to modify their software in order to do so. I have an hourly bup backup for each of my servers, that goes to a backup host. I am not a bad actor, have not modified any software, and yet if I run an activityhub server I will have a complete timeline at 1hr granularity, so basically anything not deleted within minutes of posting. (Considering a switch to borg backup when I have the time to really evaluate it)
cookiecaper 9y ago
No, I think it's important to retain mutability. Anything you post on the internet now functions the same way; everyone who has viewed it received a copy, and there's no way to ensure that the content is actually gone from everyone's machine; it probably exists in the browser cache of most recipients, etc. However, I think one of the big things that cryptonerds and other people deeply involved in developing this type of technology overlook is that most people don't want a system that tells them "good luck retracting anything you ever publish". Integrating this as a "feature" is actually an active barrier to adoption. Yes, it's true that you can't ever guarantee all copies of something have been destroyed after they've disseminated, but you can still provide the facilities necessary to signal that the content owner wants that to happen, and create an expectation that blessed clients will observe that signal internally. We need to provide mutability at least on par with the current experience if we expect one of these alternate social protocols to pick up steam. These are popping up like flies recently, and most overlook this.
paroneayea 9y ago
So, I'm co-editor of the ActivityPub spec, hi! And yes, there's both reasons to want a Delete operation and to be skeptical of it! Reasons to be skeptical of it: well there's the obvious ones, you might want to hold on to some content coming your way and lots of people are disappointed to see things disappear. Mutating networks have some dangers for sure. Reasons it to want it, or that it's there: well, this is how all the existing federated social networks work. ActivityPub was designed in the context of standardizing basically something that projects like Mastodon, Diaspora, MediaGoblin, GNU Social, etc can use. And that is how things work now... mutation and federated deletion has been part of the existing federated social web for a decade. And we're trying to build something people can hook into their existing systems. People may also change their minds about things. Should they have the authority to remove their own posts? An open question, but at the very least, whether a server removes the content or not, a Delete is a request to do so across the network. However, yes, there is an alternative structure one can imagine for these things, and that's something a bit closer to something git-like in the way that branches point at commits, but may change at which commit they point to over time, but the commits themselves never change. That's a desirable thing to explore, and I've blogged about it: http://dustycloud.org/blog/an-even-more-distributed-activitypub/ http://dustycloud.org/blog/an-even-more-distributed-activity... And we're even looking at exploring it, possibly, in the Social Web Incubator Community Group: https://www.w3.org/wiki/ActivityPub_extensions#Possible_future_extensions https://www.w3.org/wiki/ActivityPub_extensions#Possible_futu... BTW, if you're interested in such things, the community group is open to everyone and is hosting weekly meetings https://www.w3.org/community/swicg/ https://www.w3.org/community/swicg/ and we'll be hosting a meeting next week https://www.w3.org/wiki/SocialCG/2017-05-31 https://www.w3.org/wiki/SocialCG/2017-05-31
TazeTSchnitzel 9y ago
Practical and legal concerns make such an operation a necessity. Of course it's not guaranteed to work, it relies on trust, but you can't make a system intended for real-world use where you can't at least attempt to delete things. Additionally, though the technology can't force other instances to delete things, other concerns perhaps can. Consider the potential legal implications of deliberately ignoring delete requests.

HerraBRE 9y ago

If the social contract says "delete things when you see a delete message", then that's useful in a federated environment. Only bad actors will disobey and they will have to modify their software in order to do so. This doesn't provide absolute protection against bad actors, but since most bad actors don't own a time machine, it reduces the scope of the harm they can enact. Consider the adversary "angry ex-boyfriend." Let's assume he wasn't always angry and isn't a sociopath. By the time he has become angry, the sensitive posts have already been deleted. This makes a difference in real life to real people. There is indeed a user-interface concern, to not over-promise to the end-user. But that doesn't justify leaving such a useful thing out at the protocol level.

nercht12 9y ago
>> most bad actors don't own a time machine You mean besides me, of course. XD EDIT: It's a joke people, for Pete's sake.
- devrandomguy 9y ago
  Actually, this is a real issue. For one, there is the Wayback Machine, which could very well see increased usage and mindshare as legally mandated content takedowns increase. For another, if, say, Facebook wanted to harvest data from this network to create shadow profiles and flesh out missing patterns in their analytics, then they could easily follow everything, keep the raw data/content internal, and never develop the ability to retroactively un-analyze that data when a delete request comes in.
  - HerraBRE 9y ago
    This is a legitimate concern. I would not put it past Facebook (or other businesses which are addicted to harvesting user data) to behave badly against networks like this. However, for the sake of their reputations they'd still probably do it quietly, which means many of the person-to-person attacks that deletion protects against would still be thwarted. This is a problem the same way Facebook's privacy controls are a problem. Facebook themselves are not bound by them, but they're still useful if you want to protect your data from other users of the platform. And FWIW, I think most of the big crawlers respect robots.txt - this is the same sort of thing.
beagle3 9y ago
> Only bad actors will disobey and they will have to modify their software in order to do so. I have an hourly bup backup for each of my servers, that goes to a backup host. I am not a bad actor, have not modified any software, and yet if I run an activityhub server I will have a complete timeline at 1hr granularity, so basically anything not deleted within minutes of posting. (Considering a switch to borg backup when I have the time to really evaluate it)

cookiecaper 9y ago

No, I think it's important to retain mutability. Anything you post on the internet now functions the same way; everyone who has viewed it received a copy, and there's no way to ensure that the content is actually gone from everyone's machine; it probably exists in the browser cache of most recipients, etc. However, I think one of the big things that cryptonerds and other people deeply involved in developing this type of technology overlook is that most people don't want a system that tells them "good luck retracting anything you ever publish". Integrating this as a "feature" is actually an active barrier to adoption. Yes, it's true that you can't ever guarantee all copies of something have been destroyed after they've disseminated, but you can still provide the facilities necessary to signal that the content owner wants that to happen, and create an expectation that blessed clients will observe that signal internally. We need to provide mutability at least on par with the current experience if we expect one of these alternate social protocols to pick up steam. These are popping up like flies recently, and most overlook this.

paroneayea 9y ago

So, I'm co-editor of the ActivityPub spec, hi! And yes, there's both reasons to want a Delete operation and to be skeptical of it! Reasons to be skeptical of it: well there's the obvious ones, you might want to hold on to some content coming your way and lots of people are disappointed to see things disappear. Mutating networks have some dangers for sure. Reasons it to want it, or that it's there: well, this is how all the existing federated social networks work. ActivityPub was designed in the context of standardizing basically something that projects like Mastodon, Diaspora, MediaGoblin, GNU Social, etc can use. And that is how things work now... mutation and federated deletion has been part of the existing federated social web for a decade. And we're trying to build something people can hook into their existing systems. People may also change their minds about things. Should they have the authority to remove their own posts? An open question, but at the very least, whether a server removes the content or not, a Delete is a request to do so across the network. However, yes, there is an alternative structure one can imagine for these things, and that's something a bit closer to something git-like in the way that branches point at commits, but may change at which commit they point to over time, but the commits themselves never change. That's a desirable thing to explore, and I've blogged about it: http://dustycloud.org/blog/an-even-more-distributed-activitypub/ http://dustycloud.org/blog/an-even-more-distributed-activity... And we're even looking at exploring it, possibly, in the Social Web Incubator Community Group: https://www.w3.org/wiki/ActivityPub_extensions#Possible_future_extensions https://www.w3.org/wiki/ActivityPub_extensions#Possible_futu... BTW, if you're interested in such things, the community group is open to everyone and is hosting weekly meetings https://www.w3.org/community/swicg/ https://www.w3.org/community/swicg/ and we'll be hosting a meeting next week https://www.w3.org/wiki/SocialCG/2017-05-31 https://www.w3.org/wiki/SocialCG/2017-05-31

TazeTSchnitzel 9y ago

Practical and legal concerns make such an operation a necessity. Of course it's not guaranteed to work, it relies on trust, but you can't make a system intended for real-world use where you can't at least attempt to delete things. Additionally, though the technology can't force other instances to delete things, other concerns perhaps can. Consider the potential legal implications of deliberately ignoring delete requests.