I probably cannot adequately express my appreciation for folks undertaking to improve the decentralization of Hive, as you are.
I am not a dev, but have some questions regarding how your build affects censorship and resistance to it on Hive.
"bloom_filter_policy"
Is this a reference to @bloom?
I note you are incorporating @themarkymark's blacklist. Does this include #irredeemables github list? I did not see a specific reference to that list, so inquire. I have strongly advocated for far greater public awareness and involvement in that absolute censorship of affected accounts, and it is my hope that full nodes that do not simply mirror that API censorship mechanism arise.
I would appreciate any comment you might feel appropriate regarding that apparently covertly exercised censorship mechanism, and specifically regarding it's present application to @joe.public, who seems to have been placed on that list and completely censored on all front ends on Hive using extant full nodes, for no other reason than annoying Bernie and Marty.
I do not advocate being a troll. However, I am confident that the definition of a troll is highly subjective, and allowing such total censorship to be applied based on personal opinion is a grave threat to Hive's ability to secure free speech. I would rather deal with trolls and flags than potential censorship because powerful accounts don't like them, or maybe any of us.
Trolls are annoying. Censorship is existential. Steem today reveals what that slippery slope ensures Hive will become if public information and involvement in API mediated censorship is not established presently.
Thanks very much!
Not true. You must be mixing Hive's blacklists and Steemit's censorship.
To see the difference, just compare:
https://hive.blog/@joe.public
https://steemit.com/@gtg
While Stinc under Yuchen seems to have gone after back catalogs, I received a comment from @joe.public today, which is now invisible, and my reply is also invisible. This is censorship at the API level, exactly as it is being undertaken by Stinc and the CCP on Steem, just on Hive it is only applied to active communications, and not catalogs.
The latest update to the #irredeemables list was last month, just before Hive forked off Steem. I have received no indication Hive treated this list any differently than Steem did, and absent intentional changes to how Hive works, this exact list should have the exact same affect on Hive it does on Steem.
here you can see the full list as of that time, administered by @themarkymark and friends, and @joe.public is listed as #622.
No reason given for his being on that list is compelling enough to mandate his total censorship on Hive. He annoyed @themarkymark and Bernie.
That's all it takes to generate a complete censorship of Hive users. That's damn little difference from what Sun Yuchen is doing to Steem.
Hive needs censorship resistance, not a band of merry censors keeping the narrative safe for consensus witnesses and ninjamine whales.
I do appreciate your comment. I am aware of the feathers I have ruffled, and expect your adamance regarding independent thought is particularly revealed by your comment here. I note you're an expert coder, and that nothing I have said in this comment is new information to you.
So, why do you note the minor difference in target of the same exact mechanism that is actively censoring folks on both Steem, wielded by Sun Yuchen today, and @themarkymark and his band of merry silencers of dissent on Hive today? Seems a bit misleading.
Edit: I should say 'the exact same method' rather than 'mechanism, as you are not on the #irredeemables list, which shows that Yuchen is using a different list via the API method to censor folks.
Both method and mechanisms are very different now.
Anti-censorship features of Hive are on the consensus level.
True, that things gets more complicated nowadays when part of API endpoint is a non-consensus front-end oriented social layer such as hivemind.
Node and front-end operators can chose to ignore those features. I'm (same as @pharesim) running on defaults, inherited from Steem (now changed to be independent for obvious reasons)
I see a lot of improvements needed for those mechanisms to improve transparency and decentralization.
In a long term I believe this will be replaced by some sophisticated mechanisms relaying on a web of trust.
yeah man were supposed to have that DIY Decentralzied Voice KYC free p2p ID system that letsyou verify up to 3 otehr people in a web where you submit face selfies every few weeks or days and you have VERIFICATION witnmesses at least thats what I see we could have (The stuff we all BELIEVED @dan was doing at block one as $750 million dollar CTO lol but he ACTUALLy just created an idea and allowed US to create the plan spread across all our brains
just do what dan led us to believe hed do for voice, but on hive, where we need a validator node system where you can tie your owner keys to some system where yoru recovery account can restore your account after 1 year or 2 months or 6 months of inactivity and where you can get people to verify if you still have your account, selfi verification, youd end up with validator node wars , but youd try to create alliances and allow binter blockhain communication, we could allow a Keybase.io system where you verify who you are by having a verification of like 7 different social media accounts . I dunno tehers SO many ways to do this i want to try them all
I just dont think dan will deliver on this, maybe but voice doesnt even let me make posts just comments. and i geta 700 voice daily reward , ghey if that was $700 a day id be happy .
what we need is to finish this silly dream dan has, he is innovating less and less the larger and larger his company gets. But WE can be nimble quick and jump over the candle stick ;)
I am not a coder, and seem to have misunderstood, from your comment, that the API mechanism was being applied on both forks, with the difference that Steem was adding catalogs to what is not passed to front ends.
However, I am learning, and what I am learning today is that folks that are competent to work with APIs have undertaken what I consider to be vast improvements in how censorship is going to be implemented going forward.
I am grateful for your considerations, and for sharing them with me here. I hope trust can be unnecessary, just as I hope spam will stop. I'd much rather users themselves be enabled to choose what is censored from their feeds, as that best enables free speech and dissent in a world that seems hell bent on duplicating the Chinese model of total information control, where any information not mandatory is forbidden.
The centralized platforms are all headed in that direction. Since I, and many I have read say so, are here because of censorship, enabling users to be the only censor of their feeds strikes me as the most potent recruiting campaign possible.
Seems to me it's just the right thing to do, as well.
Thanks!
First off, it's not marky and his friends. It's marky. And it's a difficult, unrewarding job I have the utmost respect for. Nobody else is doing it.
Someone like joe attacking him constantly on a personal level asked for it, and I don't judge. He was removed now though.
As Gandalf said, the process and marky managing it was inherited from steem. Things will be handled differently moving forward, but it takes time.
The new filtering on Steemit works on another level. I don't even call that censorship though, as that describes an action by governments, not private persons. I don't see a duty for anyone to serve anything. It's uncensorable on blockchain level, not more.
During the discussions I have had with @themarkymark I have learned much I did not know, from him and others, such as that there is no lack of spammers that have no personal conflict with Bernie. Indeed, @themarkymark was correct when he indicated I was largely uninformed on the matter.
I will mention my improved understanding to him directly when time allows.
I have not yet read @gtg's comment, but am working through my discussions and expect to, if it's a new comment.
While I note we are not entirely in agreement philosophically, I nonetheless deeply appreciate the action you have taken, and credit you for being the proximate cause of improvements to Hive that have resulted. For that I am deeply grateful, and also because it's almost 2 am here, I will refrain from walls of text that are just me being disagreeable.
Thank you very much.
No
The irredeemables were taken from steemit without changes for now. As it was managed by them (with the help of marky), that wasn't something I could influence so I never really cared.
I do now! This list definitely has to be discussed and a process established to not let a single person just add someone who annoys them. Thanks for pointing it out, I will check more opinions.
Please keep me in the loop as you manage the censorship issue.
I have advocated for requiring a vote on HPS proposals to include an account on #irredeemables, due to it's severe and total censorship of affected accounts. I feel strongly that the same mechanism considered sufficient to elect witnesses should be the mechanism to essentially forever silence people.
Advocates of censoring the account can present evidence in support of the inclusion, the accused can present their own, and voters decide. I also recommend periodic appeals be allowed of the censored account via the same HPS method. If they receive enough votes, they should be allowed to get off the list.
We need a robust mechanism to undertake such a terminal threat to users of Hive as API total and complete censorship of all ability to communicate with other folks here, and I can't think of one better atm.
Thanks!
In my view, blocking content from the interfaces should happen there. If an interface operator runs their own API node it makes sense for them to block it there directly. I do not operate an interface though, so I will probably set my node up with no or just a minimal irredeemables list. My hivemind is not fully synced yet and routed to anyx, so I have a few days to hear other opinions and make a decision then.