Closed jakmeier closed 1 year ago
Initialization of SocialDB is quite straight forward:
new()
set_status(status = "Live")
Then to register a user, we don't have to do anything. But for every call we do later, we must ensure there is enough storage. To facilitate, user initialization can be as easy as:
storage_deposit(account_id = "user.near")
For actual workload, I am thinking of three different interactions to starts:
All of these interactions are just calls to set
. The only non-trivial part is constructing the argument just right.
This can also be easily extended to all kinds of interactions that change social DB, such as widget updates, profile changes, etc. It's all just set
calls.
The argument construction requires nested JSON serialization as shown below. Luckily, it can be done in just a few lines of Python code.
// Example JSON for "jakmeier.near" following "pugachag.near"
{
"data": {
"jakmeier.near": {
"graph": {
"follow": {
"pugachag.near": ""
}
},
"index": {
"graph": "{\"key\":\"follow\",\"value\":{\"type\":\"follow\",\"accountId\":\"pugachag.near\"}}",
"notify": "{\"key\":\"pugachag.near\",\"value\":{\"type\":\"follow\"}}"
}
}
}
}
See the full call in the explorer: https://explorer.near.org/transactions/J2erddvLFo8L4Qn9Rb4HV8tHA3iJtNcgW6iSDBRwCcBh
So far I code the initialization and the follow transactions. It's available in this commit: https://github.com/near/nearcore/commit/dbef2f07c7843a0bf5cc2e3ed9a960f10e801412
We merged #9133 with initialization, "Follow someone else" and "Post a message".
One inconvenience so far is that the smart contract validation might not be enough for us to be sure that meaningful work is being done. A set
call may be successful without actually having the desired effect.
Ideally we would attach a frontend to benchmarking and look at users and posts from there, even if just to confirm that it does what it should. But I will keep this as a nice-to-have addition for now.
I'm going to close this as there is currently no plan to add likes or a frontend. The current socialDB load is good enough for, as it can be used to test how many users we can support in a given setup.
We are now using locust to create the TPS benchmark described in #8999.
This issue is to track how we integrate SocialDB traffic.