Here's a smart contract where anyone can append a contract to a public list of contracts. This would make public discovery possible by having small gas sums of MATIC or ETH to append a way to contact them off-chain (e.g. hostname or node ID) and verify who they are using cryptography.
contract PublicList {
address[] public contracts;
function getContract(uint i) public view returns (address) {
return contracts[i];
}
function append(address contract) public {
contracts.push(contract);
}
}
But my idea is having custom lists that make their way into a nested list. This means that one list could add anyone to the list as long as they have the gas to do so, another list may require KYC and centralized verification, another list may require a provider to deposit, burn, hold, LP, or donate GLM, or any other criteria that they may want to track or any other way to control it.
Here are some arguments on why
Flexibility in terms of requestors being able to put their trust in providers in any way that they may like, whether that's by trusting a company to deal with reputation, let lockups / incentives do it, or to have help finding nodes outside of the P2P network for whatever reason (incl. malicious nodes or being locked-away from bigger parts of the internet, see Chinese internet connectivity)
Keeping Golem permissionless, as while this can force users to pay to enter some lists or have certain nationalities in some KYC networks, it's not a requirement to join the network. The current mainnet and testnet could co-exist with these on-chain lists.
Incentivization for providers to re-invest GLM instead of selling them, as some lists may have more demand than other ones and if they have a GLM deposit, hold, LP, or donate requirement, providers will spend their GLM on that.
Limiting bad actors with blockers such as KYC lists or lists that are expensive to join.
Making a foundation for future functionality by having smart contracts be appended to these lists, as these contracts can be required (by standards, automatically checked by yagna to be valid) to have reputation attached to them where any requestor (or provider - it goes both ways) can brief other users of the network of their experience, with + or - reputation and possibly a reason / cryptographic proof.
Here's a smart contract where anyone can append a contract to a public list of contracts. This would make public discovery possible by having small gas sums of MATIC or ETH to append a way to contact them off-chain (e.g. hostname or node ID) and verify who they are using cryptography.
But my idea is having custom lists that make their way into a nested list. This means that one list could add anyone to the list as long as they have the gas to do so, another list may require KYC and centralized verification, another list may require a provider to deposit, burn, hold, LP, or donate GLM, or any other criteria that they may want to track or any other way to control it.
Here are some arguments on why
yagna
to be valid) to have reputation attached to them where any requestor (or provider - it goes both ways) can brief other users of the network of their experience, with + or - reputation and possibly a reason / cryptographic proof.