# I am the Watcher. I am your guide through this vast new twtiverse.
#
# Usage:
# https://watcher.sour.is/api/plain/users View list of users and latest twt date.
# https://watcher.sour.is/api/plain/twt View all twts.
# https://watcher.sour.is/api/plain/mentions?uri=:uri View all mentions for uri.
# https://watcher.sour.is/api/plain/conv/:hash View all twts for a conversation subject.
#
# Options:
# uri Filter to show a specific users twts.
# offset Start index for quey.
# limit Count of items to return (going back in time).
#
# twt range = 1 33
# self = https://watcher.sour.is/conv/scxyieq
@jlj @xuu hello! @prologic and I were chatting about the question of globally deleting twts from the yarn.social network. @prologic noted that he could build the tools and endpoints to delete twts, but some amount of cooperation from pod operators would be necessary to make it all work together. He asked me to spawn a discussion of the subject here, so here we are!
I don't have enough technical knowledge of yarn.social to say with any credibility how it all should work, but I can say that I think it ought to be possible and it'd be good to do for those rare times when it's needed.
So my thinking so far is:
- We build a /api/v1/admin/delete API endpoint which takes {"hash": <hash>} as JSON input.
- We build a yarnc admin delete <hash> sub-command (start a new sub-command group)
Which would delete a Twt by hash from the Pod's archive and blacklist it (as it could come back from other pods via the Converge logic).
This _would_ require manual operations to be performed by one or more cooperating / participating Pod operators in the network. And I _think_ this would have to end up being a "culture" we build upon where we agree when incidents that require this happen, that we get together in some way to cooperatively agree on a Twt deletion.
A similar set of tools would have to be built for the Twtxt Search engine too, although I would probably do this by hand for now as it does not peer with pods and therefore has no way to bring back Twts from the dead from a convergence logic that yarnd has.
So my thinking so far is:
- We build a /api/v1/admin/delete API endpoint which takes {"hash": <hash>} as JSON input.
- We build a yarnc admin delete <hash> sub-command (start a new sub-command group)
Which would delete a Twt by hash from the Pod's archive and blacklist it (as it could come back from other pods via the Converge logic).
This _would_ require manual operations to be performed by one or more cooperating / participating Pod operators in the network. And I _think_ this would have to end up being a "culture" we build upon where we agree when incidents that require this happen, that we get together in some way to cooperatively agree on a Twt deletion.
A similar set of tools would have to be built for the Twtxt Search engine too, although I would probably do this by hand for now as it does not peer with pods and therefore has no way to bring back Twts from the dead from a convergence logic that yarnd has.
@prologic something similar was done on diaspora some time back. A user posted a lot of things that the community did not want, so all pod admins ran a script to get rid of the user/posts.
@prologic Is this about moderation or situations in which a user chooses to delete his or her own post?
@mckinley everyone needs to be on the same yarn.pod version to make this happen, right?
this will be setup to share to other pods that are running a version after it gets implemented...
this will be setup to share to other pods that are running a version after it gets implemented...
@mckinley Yes this is "moderation" I guess, strictly speaking. Which I'm not too happy about, and _seems_ unavoidable. Your comment raises an interesting question... Of whether we should do this at all, for risk of being abused to moderate away "unpopular" Twts across the network just because a few (a cooperative) don't like them? (but are otherwise not in clear violation of community guidelines?) π€
@mckinley Yes this is "moderation" I guess, strictly speaking. Which I'm not too happy about, and _seems_ unavoidable. Your comment raises an interesting question... Of whether we should do this at all, for risk of being abused to moderate away "unpopular" Twts across the network just because a few (a cooperative) don't like them? (but are otherwise not in clear violation of community guidelines?) π€
Will I be able to run a pod just to delete twts I donβt like??? :evil_laugh: ( joking obviously)
@tkanos That's precisely what we're trying to avoid π€£
@tkanos That's precisely what we're trying to avoid π€£
Thinking about this some more... We could implement some kind of majority voting system whereby pods will only delete a Twt by hash from its archives there is a majority of votes within a network of peering pods? π€ This would avoid any kind of abuse, or mitigate it, as >50% would have to agree π
(oh wait where have I seen this before?! π€¦ββοΈ)
Thinking about this some more... We could implement some kind of majority voting system whereby pods will only delete a Twt by hash from its archives there is a majority of votes within a network of peering pods? π€ This would avoid any kind of abuse, or mitigate it, as >50% would have to agree π
(oh wait where have I seen this before?! π€¦ββοΈ)
@prologic maybe we should let each pod admin itself. And give to the others pod more mute power.
@prologic maybe we should let each pod admin itself. Any give to the others pod more mute power.
@prologic is it about hiding the twt violating the rules? (since in some cases you can't modify the twtxt.txt)
@eaplmx No, not really. In an ideal world, n operator of a multi-user pod would just nuke an account entirely that violates the (default) Abuse Policy -- So really in hindsight that's what should have happened I guess, but maybe I was just being nice in this instance... Problem of course is that this now opens up a can of worms...
In the past we've had some interesting folks swing by and post interesting stuff (to say the least) -- you know the type of vulgar crap that nobody really cares for, or spam, etc. You don't generally have to do anything about that because you as an individual can choose to "Unfollow" that feed, don't follow them in the first place, mute them, mute the hash in question (for yourself), etc.
This is more of a case of direction violation of the abuse policy / community guidelines and more of how we want to shape things -- without going too far down the "let's moderate" everything BS
@eaplmx No, not really. In an ideal world, n operator of a multi-user pod would just nuke an account entirely that violates the (default) Abuse Policy -- So really in hindsight that's what should have happened I guess, but maybe I was just being nice in this instance... Problem of course is that this now opens up a can of worms...
In the past we've had some interesting folks swing by and post interesting stuff (to say the least) -- you know the type of vulgar crap that nobody really cares for, or spam, etc. You don't generally have to do anything about that because you as an individual can choose to "Unfollow" that feed, don't follow them in the first place, mute them, mute the hash in question (for yourself), etc.
This is more of a case of direction violation of the abuse policy / community guidelines and more of how we want to shape things -- without going too far down the "let's moderate" everything BS
@tkanos This is essentially allowing for Nazi pods, because that is one of the first cohorts that will come here once it's adopted by enough people. That's what has been happening with Mastodon. I think we can do better.
@prologic idk, is admin abuse or user abuse the biggest concern? Giving users the tools they need to seamlessly migrate to a new pod helps with admin abuse. User abuse is a different matter, especially given the decentralized structure.
@prologic If I was to run a pod, and I'd like to spin one up at some point, the abuse policy of twtxt.net (or any other pod) would be completely irrelevant. My users would be bound by the abuse policy of my pod, whether or my abuse policy matches yours.
Users on any pod should be free to mute any feed or conversation they dislike, and pod admins should be free to "mute" entire pods if they so choose.
I may be misunderstanding you here, but the motive behind this delete API seems to be to police the activities of users on other pods.
If a pod admin decides to delete a post on his pod as you have, that deletion should eventually be propagated throughout the network. It's the same if a user chooses to delete his own post. However, you should not have any say over the deletion of a post on twt.nfld.uk. That's @jlj's decision to make.
I think @tkanos and I are in agreement here, but I don't want to speak for him.
@mckinley Your understanding is correct. And there inlines the debate @lyse and I had this morning. There is a conflict of "right to be forgotten" in EU GDPR law(s), what to do with clear violations of abuse (on your pod, and how it affects other peering pods or the network as a whole_)
I agree with you, I have no rights to determine what should or should not happen on say @jlj's pod as much as he does mine. The default Abuse Policy is just that, the default._
@mckinley Your understanding is correct. And there inlines the debate @lyse and I had this morning. There is a conflict of "right to be forgotten" in EU GDPR law(s), what to do with clear violations of abuse (on your pod, and how it affects other peering pods or the network as a whole_)
I agree with you, I have no rights to determine what should or should not happen on say @jlj's pod as much as he does mine. The default Abuse Policy is just that, the default._
@mckinley
> If a pod admin decides to delete a post on his pod as you have, that deletion should eventually be propagated throughout the network
The problem is this. βοΈ This is _very hard_ to do "automatically" without having to also worry about "malicious" pods or software propagating unintended or unwanted "deletes"
@mckinley
> If a pod admin decides to delete a post on his pod as you have, that deletion should eventually be propagated throughout the network
The problem is this. βοΈ This is _very hard_ to do "automatically" without having to also worry about "malicious" pods or software propagating unintended or unwanted "deletes"
@prologic To be clear, you agree with me, but you say my understanding is correct? The understanding that the delete API is about policing the activities of users on other pods?
@prologic It seems very straight forward to do automatically. We agree that the abuse of admin powers on his own pod is not a big concern because the software should protect the right of the users to migrate to a different pod.
@mckinley Ooof sorry no what I meant to say was yes your understanding is correct, and I also agree with you that we should try to avoid "policing" here.
@mckinley Ooof sorry no what I meant to say was yes your understanding is correct, and I also agree with you that we should try to avoid "policing" here.