If we are to do a greylist... Greylist questions, concerns, suggestions, and dreams. Brainstorming thread.
Brainstorming! No wrong ideas. Try to give a reasoning to your thinking.
It is likely that most greylisted projects will be greylisted only for short periods of time due to temporary lack of WUs. If we implement Total Credit Delta (described in the 4.0-2018 Roadmap Proposals) this will have a noticeable effect on earned MAG, and, of course, science and data analysis completed.
So.
If we are to do a greylist...
what if we somehow implement a secondary project mechanism? This mechanism would automatically redirect your cycles to your chosen backup, or secondary, project choice should your first project choice be greylisted for one reason or another. As soon as your primary project is degreylisted/rewhitelisted, your cycles are automatically redirected to its WU.
I'm thinking about people who don't want to keep track of everything every day.
Let's see what ideas we can come up with!
Not a gridcoin network thing, but Good idea anyway.
if we end up building a GUI that manages BOINC projects, it could be a Gridcoin thing, yes?
and if it must be built into the BOINC client, we may need to support its development on their end. it might be a good first step in co-development.
I'm not 100% clear as to what the "greylist" entails exactly. What I do know is that I am strongly in favor of moving to some sort of fully automated system for including projects which removes the voting / human element as thoroughly as possible. In practice, we will probably always need blacklisting capability to remove abusive / illegal projects, but we should at least be thinking ahead to when the first commercial projects want to get on board and how painful it's going to be when a bunch of "Gridcoin is only for science" purists try to block their inclusion for no reason other than that they aren't academic.
So I'm not sure if that's relevant feedback, but it is what it is.:)
some of the conversations on the greyist were recently compiled into an idea by @guk. the idea can be found here.
based on these conversations, i see the greylist as follows:
the greylist is a way to automatically and temporarily remove a BOINC project from the whitelist if a given set of parameters are met. it could also operate as a stepping stone after a project is voted into the whitelist but before it is actually whitelisted -- so we do not have the problems presented by adding Source Finder.
the UX of a BOINC project would then be:
this is a very brief summary of the greylist -- it has been a conversation for months. i'm sure something more solid will be popping up in the coming weeks.
Yeah, I think 3 and 4 are good ideas, but 1, 2 and half of 5 need to go away long-term.:) Otherwise politics get in the way where they don't need to. Basically I think any new project should be able to self-add to a "whitelist" (#3) provided it doesn't instantly fail the checks in step 4, and the last part of step 5 is the same ridiculous feeling-laden sluggish nonsense that we currently have.:) "Not messing with the superblock process" in step 2 is okay, but it should be something that can be quantified and bundled into step 4.
Perhaps we could make a greylist via the python rain tool described by scalextrix described in his post. If we had webportal that would enable someone to easily convert btc/eth into GRC to rain on any boinc project (since the tool works with non-whitelisted projects as well) then this would effectively function as a greylist. Another option would be to potentially put something like this in the client?