Implementing a blocking feature wouldn't hurt Keybase in the slightest. Are you imagining that everyone would block everyone else? I just don't see that happening.Ī blocking function is of high value to users and very low impact to the functionality of the site.
So far the arguments against having the ability to block seem to boil down to "why would you want that?" and a vague "it may hurt the site". Thanks, everyone, for opinions on - your points on blocking are certainly valid.Īs an aside, we ran a dating site for 10 years. I know that when you don't want to see someone, you really don't want them appearing in your suggestions, in the form of notifications, or in any other way.
FLAWS IN DELETED KEYBASE APP IMAGES VERIFICATION
You also might not want other people making connections between the 2 of you, and that's more subtle.I'll get to that in a & - your points are valid when looking at tracker statements as a distributed proof verification service. #Flaws in deleted keybase app chat verification# It's definitely one of the roles of tracking. However, it's hyperbole that we're shooting ourselves in the foot to block tracking! The service would not be weakened if someone could magically remove some of the strength of their own proofs by preventing others from tracking them. They'd still have all the power of their own proofs, timestamped, in Keybase's merkle tree, even hashed into the bitcoin blockchain. The big problem here is that you never want a person to know you block them. It can incite people further, offend them, or make them think they're successful at getting to you. This adds fuel to the fire, which will make them attack in other ways, outside the controls of the blocking system: on other services, via other accounts, whatever.
Or it might just hurt their feelings.Īaand.blocking a tracker statement would be discoverable by the person being blocked. They are signed statements put into a public place, which, by design, is consistent for all users. To be clear: to block someone from tracking would require that either (a) they can't write this entry in the merkle tree, or (b) clients all see the entry in the merkle tree, but they've been notified in some way to ignore that one blocked entry. Both expose this info pretty clearly to the person being blocked - far more easily than on services that keep and control their own "follow" graphs and expose them selectively to everyone differently. I think the most logical answer is probably that blocking should happen privately, just from the perspective of the person doing the blocking. #Flaws in deleted keybase app chat verification#.
0 kommentar(er)
