extend the current blocking mechanism

[djangobits]

As a first and immediate step, the current blocklist could be separated and extended. Here's a proposal from @vhf

like posted on discord:

Idea for a quick and easy solution to people polluting the feed with stolen things, it's short term but easy: you could put this data: https://github.com/hicetnunc2000/hicetnunc/blob/fb66c0f4529d23bacab304fff81edb634d7a1036/src/pages/feed.js#L45-L53 in a gist: https://gist.github.com/vhf/eb2dc0076cd6bb5ea73fb418d00bd52a , and pull the gist directly as json using axios.get() (the raw latest version of a gist is served as json for json files: https://gist.githubusercontent.com/[gist%20username]/[gist_ID]/raw/[file_name], so something like https://gist.githubusercontent.com/vhf/eb2dc0076cd6bb5ea73fb418d00bd52a/raw/feed.json , just make sure the raw gist url doesn't include the gist commit sha), or put that data in a static hosted file somewhere else obviously this isn't gist or github specific that way people in charge could filter the feed without needing to hardcode the token ids and redeploying.

[andrevenancio]

How many people can add to that gist? only the author right?

[djangobits]

By using pull requests, anybody could add, but the PR must be merged by hicetnunc

[andrevenancio]

I'm happy with a solution like that. But I think the gist should be created by hicetnunc2000 the Organisation, not an individual member. @crzypatchwork more work for you :) Do you mind creating a cop of @vhf gist?

[djangobits]

I agree. I already started to collect a few copyminter acocunts and IDs here, feel free to copy:

Accounts https://gist.github.com/djangobits/2afedabe744b7c9be7ad53a7bb6c8574

IDs (attn, the last ones have an additional info on why they are on the list) https://gist.github.com/djangobits/7ddabfe504113ac61ec09355b7999db5

[djangobits]

btw. I am not saying that is how it must work. I weight openness and decentralization a lot....

[andrevenancio]

It's definitely something that can be implemented. The proposed solution is good in a way that removes the dependency on a re-deploy on both the frontend and the API. But I guess the question is more a moral one. Why should the platform police mint(ed) content. If there is content that is off-limits, like nudity for example, shouldn't that be on the mint page to alert the user what they can/can't do? I quite like the openness of the platform, and some of the flagged objkt are just illustrations.

[djangobits]

I share your opinion and there should also be rules published at some point and in some form, but given the anonymity, people can upload really bad and harmful stuff (I am not talking about simple nudity) and there must be a way to block it. At least means should be in place. Copyright issues could also raise legal issues that could end up being an existential threat for the platform.

[djangobits]

By the way. Using the same mechanism, we could have a list of verified artists based on their Tezos adresses. Just a list of adresses that were verified. Then use that list whenever possible... Verification would be done manually, actively or by request from the artist

[djangobits]

Maybe we should just see the extension of the current blocklist only as a last line of defense and not to moderate or block copyminters. It would only be used if people uploaded extremely graphic or harmful content or if there is a legal request for takedown. Not actively blocking stuff that was copyminted because that would also mean actively policing all uploads. Then work on verification, galleries etc. everything that gives the artist tools to add verifiable information next to his portfolio and to make the feed less central. cc @crzypatchwork

[djangobits]

As we discussed on discord the solution discussed in the initial post, a blocklist based on gist lists should be implemented. Two lists will be created, one with OBJKT IDs one with wallets for later use. Blocked OBJKTS will disappear from the feed. If an OBJKT is blocked, the collect button will be disabled.

This serves as temporary measure until decentrallized verification is in place. Then it will be removed or gists will be emptied and the system will be kept as last line of defense.

@andrevenancio you can start. @crzypatchwork gave his ok to implement this as a temporary solution.

[djangobits]

So @andrevenancio, as we discussed with @crzypatchwork , as a first measure, the feed should hide all OBJKTS from the feed that were minted by the adresses in filters/w.json

[violetforest]

closing due to the issue being addressed with the hDAO / verified profile parameters