Hey guys, just finished updating the RFC. So we decided to make what was listed as the Alternative approach as our main approach as it is more type-safe (instead of dealing with Vec<u8> as previously). There were a few other changes regarding how things should be routed to final destination, hint on what APIs to use and how vaults should sort out partial deletion via POST. It would be nice if anybody has any comments before we finalise the rfc.
11 Likes
Looks good to me, I have no further comments at this moment. Thanks!
1 Like
Owner(s) can set
filterto either blacklist or whitelist. In case it is set toFilterType::BlackList, the vaults shall enforce the rule of allowing everyone but the blacklisted keys to add todataon subsequent updates following the change tofilter, i.e. existing data indatafield will not be dealt by the vaults. Similarly, if set toFilterType::WhiteList, no one but the the whitelisted keys will be allowed to add data.
Is there a limit to the length of these BlackList and Whitelist? And what happens when the maximum is reached? Especially before we have Safecoin implemented we could have a number of spammers filling up quite some Appendable Data space.
Looks like it’s part of the overall 100 KiB restriction.
Spammers won’t fill this, if you have too large a blacklist then it’s best to create a whitelist (you create it though). You should be Ok, if you have thousands of entries then it will get full, but you should be able to link to other SD items as well. Although the size limit is also not 100% agreed yet for all these data types.
2 Likes
Looks good to me! Look forward to using it!
Not sure if this is already here but
4 Likes