6 ms·

I'm only minimally familiar with BlueSky. Is it a fair analogy, for understanding what this is, to say it's like: - If someone replies to this HN comment I jus

I'm only minimally familiar with BlueSky. Is it a fair analogy, for understanding what this is, to say it's like: - If someone replies to this HN comment I just wrote, and I don't like it, I can delete their comment (because there is an thread ownership concept on BlueSky, and the earliest comment is the owner); - If someone links to this HN comment I just wrote, and I don't like it, I can make that hyperlink disappear, or invalidate in some way (because BlueSky is a locked API garden and hyperlinks are not plain text, but magic cloud API tokens) Is this much correct?

skrbjc 2y ago
Pretty much, the first one being more like you can hide a comment that you don't like and if someone wants to see it they can click "see hidden replies"
- Jare 2y ago
  My reading of "hiding replies" was that people who follow the replier would still see the reply as part of their normal feed. So you are not silencing them for their audience. Which is fair. The removal of links to yourself is also very welcome. Both tools have cons, and there's methods to work around them / prevent them from taking effect. But they address the default easy/trivial ways in which people can pollute other users, so in practice the value for users should prove high.
roblabla 2y ago
> - If someone replies to this HN comment I just wrote, and I don't like it, and I can delete their comment (because there is an thread ownership concept on BlueSky, and the earliest comment is the owner); You can hide it - which I agree is functionally equivalent to deleting it as people are very unlikely to go dig for hidden comments. FWIW this is kinda similar to "flagging" a comment on HN, which (as far as I understand) will cause it to be hidden for everyone - at least until someone vouches it back. > - If someone links to this HN comment I just wrote, and I don't like it, I can make that hyperlink disappear, or invalidate in some way (because BlueSky is a locked API garden and hyperlinks are not plain text, but magic cloud API tokens) You can just make the hyperlink disappear to anyone using the default BlueSky frontend. But from my understanding, the hyperlink will still be accessible through the API.
- AnimalMuppet 2y ago
  The difference is that on actual HN, it takes more than one flag vote to hide a comment. (I suspect it's in the range 2-5, but I don't actually know.) So one person can't make a post they don't like disappear.
  - thenewnewguy 2y ago
    Also, anyone can flag a comment, not just the thread starter (I personally suspect flags from the thread starter are actually down-weighted). HN flagging is not meant to hide people you don't want to see reply to your comments, it is meant to identify rule-breaking comments.
  - teruakohatu 2y ago
    > The difference is that on actual HN, it takes more than one flag vote to hide a comment. (I suspect it's in the range 2-5, but I don't actually know.) So one person can't make a post they don't like disappear. I don't know, but I would suspect if the user who wrote the parent comment flags a reply, it would be less weight than if another random user flagged it.
- an_ko 2y ago
  To clarify how flagging works on HN: Flagging only hides a comment once "enough" users flag it, and even then remains visible to users with the showdead option set in their profile. Source: https://news.ycombinator.com/item?id=12173809 https://news.ycombinator.com/item?id=12173809
  - throwup238 2y ago
    Where "enough" = two accounts.
    - PaulHoule 2y ago
      I think. I know N>1 because I sometimes flag something and it is not suppressed right away. Often though I flag something and then it is suppressed a few minutes later so I believe N=2 or N=3 or something small like that. For that matter a lot of posts get suppressed right away, particularly from people who visit HN and immediately start posting stories from the same blog over and over again.
skybrian 2y ago
Only at the app level. At the protocol level, each user has a repo with their own posts and you can't delete other people's posts.
advisedwang 2y ago
Not really correct. You can A) Make it so YOUR NAME and YOUR POST doesn't appear attached to a post that somebody else makes. Their post will still be visible to their followers. B) Make it so that YOUR FOLLOWERS don't see somebody else's reply unless they click a "hidden replies" button. Their post will still be visible to their followers or someone looking at their timeline. In no case can you prevent somebody's posts being visible to their followers.
- saurik 2y ago
  The former doesn't make much sense in a distributed system where we expect to have multiple clients--and, preferably, no dominant one!--as there is no reason for the people you are restricting to opt in to that restriction. > B) Make it so that YOUR FOLLOWERS don't see somebody else's reply unless they click a "hidden replies" button. Their post will still be visible to their followers or someone looking at their timeline. Like, for this latter use case, if I am following you, I am buying into your frame and am often am going to agree with your moderation choices on the people who reply to you, so it actually makes a lot of sense to me that I would accept your ability to hide replies I "shouldn't" / "wouldn't want to" see. Meanwhile, the only recourse to be heard for the person whose reply was hidden is to do so to their own audience; this not only seems fair, but strips them of the power they were trying to "steal" from you when they replied to your post in the hope of gaining access to your audience. > A) Make it so YOUR NAME and YOUR POST doesn't appear attached to a post that somebody else makes. Their post will still be visible to their followers. However, this former use case does not have the same structure: if I am following someone else and they talk about something you said, but now I can't see what/who they are talking about, I'm just going to get annoyed, as the goals of this feature don't align with the direct user of the client anymore. At best, this just leads to people using workarounds, as the recourse is too powerful: anyone--not even merely the quoter--can add a reply with a screenshot of the post and a permalink through an external link shortener. At worst, it leads us down the dishonorable path of people demanding client DRM :/. It sucks, because I was kind of excited about BlueSky actually caring about distributed incentive issues in a world where they were not the only client; but, this is the kind of mistake that people get goaded into making when they build a distributed system and start to assume centralization. ...and like, by the way: this feature is also inherently dishonest, as, even if it is documented how it works, a lot of users aren't going to understand it, and so they are going to assume they have a safety net in place that doesn't really exist in the protocol. This honesty issue is similar to the way Snapchat claims people won't be able to (at least secretly, though I remember the original claim to be stronger) save the photos they send. Of course, people often can secretly screenshot your photos--such as using jailbroken devices or even merely a second camera via the good ol' analog loophole--but people send riskier photos because they trust the feature to protect them. And yes, I totally understand that Snapchat's feature sort of works and maybe is better than nothing?... but, it only works due to continual effort Snapchat invests--from both their engineers and lawyers--to enforce the feature by embracing DRM, implementing user behavior profiling / banning, and sending legal cease and desist notices to alternative clients. I hope (but no longer can assume) that BlueSky won't (or can't) ever go to such lengths; and so, in some sense, the feature is even less honest, right? :/ Even if the feature "sort of works", the power only comes from "pretty much there is only one client everyone has", and so the incentives are broken. If I were building this, I would have done the exact opposite: if someone "quotes" you, there should be a copy of that content stored on the quoter's end, so that it is still visible even if the original is deleted... but like, that copy would be trivially editable, so no one ever treats previews as truth. You have to implement it like that, as it has to be functionally equivalent to the analog loophole version of the feature -- the one where the quoter just attaches a potentially-forged screenshot of the post along with a link through an external shortener -- in order to align everyone's incentives.

skrbjc 2y ago

Pretty much, the first one being more like you can hide a comment that you don't like and if someone wants to see it they can click "see hidden replies"

Jare 2y ago
My reading of "hiding replies" was that people who follow the replier would still see the reply as part of their normal feed. So you are not silencing them for their audience. Which is fair. The removal of links to yourself is also very welcome. Both tools have cons, and there's methods to work around them / prevent them from taking effect. But they address the default easy/trivial ways in which people can pollute other users, so in practice the value for users should prove high.

roblabla 2y ago

> - If someone replies to this HN comment I just wrote, and I don't like it, and I can delete their comment (because there is an thread ownership concept on BlueSky, and the earliest comment is the owner); You can hide it - which I agree is functionally equivalent to deleting it as people are very unlikely to go dig for hidden comments. FWIW this is kinda similar to "flagging" a comment on HN, which (as far as I understand) will cause it to be hidden for everyone - at least until someone vouches it back. > - If someone links to this HN comment I just wrote, and I don't like it, I can make that hyperlink disappear, or invalidate in some way (because BlueSky is a locked API garden and hyperlinks are not plain text, but magic cloud API tokens) You can just make the hyperlink disappear to anyone using the default BlueSky frontend. But from my understanding, the hyperlink will still be accessible through the API.

AnimalMuppet 2y ago
The difference is that on actual HN, it takes more than one flag vote to hide a comment. (I suspect it's in the range 2-5, but I don't actually know.) So one person can't make a post they don't like disappear.
- thenewnewguy 2y ago
  Also, anyone can flag a comment, not just the thread starter (I personally suspect flags from the thread starter are actually down-weighted). HN flagging is not meant to hide people you don't want to see reply to your comments, it is meant to identify rule-breaking comments.
- teruakohatu 2y ago
  > The difference is that on actual HN, it takes more than one flag vote to hide a comment. (I suspect it's in the range 2-5, but I don't actually know.) So one person can't make a post they don't like disappear. I don't know, but I would suspect if the user who wrote the parent comment flags a reply, it would be less weight than if another random user flagged it.
an_ko 2y ago
To clarify how flagging works on HN: Flagging only hides a comment once "enough" users flag it, and even then remains visible to users with the showdead option set in their profile. Source: https://news.ycombinator.com/item?id=12173809 https://news.ycombinator.com/item?id=12173809
- throwup238 2y ago
  Where "enough" = two accounts.
  - PaulHoule 2y ago
    I think. I know N>1 because I sometimes flag something and it is not suppressed right away. Often though I flag something and then it is suppressed a few minutes later so I believe N=2 or N=3 or something small like that. For that matter a lot of posts get suppressed right away, particularly from people who visit HN and immediately start posting stories from the same blog over and over again.

skybrian 2y ago

Only at the app level. At the protocol level, each user has a repo with their own posts and you can't delete other people's posts.

advisedwang 2y ago

Not really correct. You can A) Make it so YOUR NAME and YOUR POST doesn't appear attached to a post that somebody else makes. Their post will still be visible to their followers. B) Make it so that YOUR FOLLOWERS don't see somebody else's reply unless they click a "hidden replies" button. Their post will still be visible to their followers or someone looking at their timeline. In no case can you prevent somebody's posts being visible to their followers.

saurik 2y ago
The former doesn't make much sense in a distributed system where we expect to have multiple clients--and, preferably, no dominant one!--as there is no reason for the people you are restricting to opt in to that restriction. > B) Make it so that YOUR FOLLOWERS don't see somebody else's reply unless they click a "hidden replies" button. Their post will still be visible to their followers or someone looking at their timeline. Like, for this latter use case, if I am following you, I am buying into your frame and am often am going to agree with your moderation choices on the people who reply to you, so it actually makes a lot of sense to me that I would accept your ability to hide replies I "shouldn't" / "wouldn't want to" see. Meanwhile, the only recourse to be heard for the person whose reply was hidden is to do so to their own audience; this not only seems fair, but strips them of the power they were trying to "steal" from you when they replied to your post in the hope of gaining access to your audience. > A) Make it so YOUR NAME and YOUR POST doesn't appear attached to a post that somebody else makes. Their post will still be visible to their followers. However, this former use case does not have the same structure: if I am following someone else and they talk about something you said, but now I can't see what/who they are talking about, I'm just going to get annoyed, as the goals of this feature don't align with the direct user of the client anymore. At best, this just leads to people using workarounds, as the recourse is too powerful: anyone--not even merely the quoter--can add a reply with a screenshot of the post and a permalink through an external link shortener. At worst, it leads us down the dishonorable path of people demanding client DRM :/. It sucks, because I was kind of excited about BlueSky actually caring about distributed incentive issues in a world where they were not the only client; but, this is the kind of mistake that people get goaded into making when they build a distributed system and start to assume centralization. ...and like, by the way: this feature is also inherently dishonest, as, even if it is documented how it works, a lot of users aren't going to understand it, and so they are going to assume they have a safety net in place that doesn't really exist in the protocol. This honesty issue is similar to the way Snapchat claims people won't be able to (at least secretly, though I remember the original claim to be stronger) save the photos they send. Of course, people often can secretly screenshot your photos--such as using jailbroken devices or even merely a second camera via the good ol' analog loophole--but people send riskier photos because they trust the feature to protect them. And yes, I totally understand that Snapchat's feature sort of works and maybe is better than nothing?... but, it only works due to continual effort Snapchat invests--from both their engineers and lawyers--to enforce the feature by embracing DRM, implementing user behavior profiling / banning, and sending legal cease and desist notices to alternative clients. I hope (but no longer can assume) that BlueSky won't (or can't) ever go to such lengths; and so, in some sense, the feature is even less honest, right? :/ Even if the feature "sort of works", the power only comes from "pretty much there is only one client everyone has", and so the incentives are broken. If I were building this, I would have done the exact opposite: if someone "quotes" you, there should be a copy of that content stored on the quoter's end, so that it is still visible even if the original is deleted... but like, that copy would be trivially editable, so no one ever treats previews as truth. You have to implement it like that, as it has to be functionally equivalent to the analog loophole version of the feature -- the one where the quoter just attaches a potentially-forged screenshot of the post along with a link through an external shortener -- in order to align everyone's incentives.