This looks like a misunderstanding. It is not an admin SIP. Your team and you, @Gonzacolo, or anybody involved, can author and take credit.
When I said “we have the CTO attention” I meant he is ready to listen to the ask and include into his backlog. it is a similar approach to the one we had with 3 of your previous SIPs:
Meaning a SIP documented by the community and executed by the Sandbox (which is still a SIP). I just assumed that you have understood it the same way I expressed it, especially because you had 3 previous SIPs following the same principles. Perhaps, I should have been more clear, sorry about that.
Yes, I misunderstood @cyril , sorry about that, I edited my response to declutter the conversation
When you said TSB will “build it out” … you meant that TSB will add it as a feature request, so it’s a $0 SIP.
Well that’s embarrassing of me. My fault completely
Moving on!
Okay, so all we need to do then is make sure the contents are really refined of what the API should be.
@WakeUpLabs and others. I’m thinking we can make this a big community SIP with many coauthors. With this being a $0 SIP, do you still feel comfortable keeping lead engineer of the final list of API ? It’s okay if you prefer not to, I misunderstood part of it too.
If you are comfortable staying on, then your shared link will do nicely in cementing our thoughts. All we need to do now is make sure it’s taking everything into account and I’ll transfer it to my final version.
It’s all good @Lanzer ! I’ll standby when you feel it’s time to share the request to TSB. Anything you can give me in the meantime, so we can stay “fresh” in the product team’s mind is welcome.
All I need is a final check from the community here. If @WakeUpLabs or @Gonzacolo still wants to take on responsibility as engineering lead for the SIP, all I need is them to do one final push with me to finalize the API request list
I can certainly share the SIP that we have so far. It basically is the same as what I posted above but I also completed the milestones and other fields.
We apologize for the delay and for not recognizing the SIP’s current state. We got excited and proposed development-focused ideas instead of what you needed right now.
We fully agree with @shont that this could bring additional income and adoption to the Sandbox ecosystem in the long run.
Having said that, let’s focus on finalizing the SIP first.
@Lanzer, please share the formal draft with us. We’ll provide feedback, and if you tag us, we’ll be available to clarify any technical points.
@Gonzacolo@WakeUpLabs has access to edit freely, I opened it to everyone else to insert comments.
Please take it easy when you read it. I’m not a programmer or API dev, so my language or technical solution might not be entirely accurate. Please feel free to correct!
This is fine Lanzer, no need to go into detail on the engineering technicals, the gist of it is just what data we need to be able to access. This could open up so many possibilities, fingers crossed they run with it.
The SIP is ready to go. Here is the open form. Shall I input it into the typeform or would you prefer I just link it here and your team takes it from there?
A very important addition that I made that we haven’t talked about right now. For the budget, I set it to 1000 500 USDC (4200 2200 SAND). 500 USDC to my team and 500 USDC to Wakeup Labs team for expenses preparing and coordinating the SIP. Please let me know if this is an issue.
edit: I included 500 for Wakeup Labs without asking them and they made the generous choice of choosing not to accept a preparation reimbusement. So I’ll just make it 500 USDC (2100 SAND) total.
Thank you all for the good work so far! Here is the feedback from TSB:
I quote:
Thanks for compiling the list of requested data fields from the community. We appreciate Sandbox DAO’s active engagement.
Regarding the feasibility of implementing the requested data fields, initially, here is our answer:
Wallet addresses: We will need to check with legal if it’s possible, as it could be sensitive data that could be exploited by malicious actors.
KYC status: only the status should be ok, but will check with legal anyway.
Ongoing and persistent saved variables for each user:We will need more details on the possible use-cases in order to understand how could be the best way of providing this data points.
Quest completion: Same as above
Total playtime: Same as above
high scores: Same as above
As I already anticipated, we are already advanced on the first iteration of the API (you could check our Developers Hub site here), and initially it is aimed to giving third-party developers access to our content (Assets, Avatars) and to allow “Login with Sandbox Account” functionally (for the logged-in user you could indeed request user profile data, but not for other users yet).
It looks like more detail are required re the persistant variables, quest completion, playtime and high score. @WakeUpLabs@Lanzer
@Lanzer re your payment: I’ll send you a note in your DM
All in all, that seems like a great response from TSB!
We only gave them a short list to keep it simple. They seem very receptive to ongoing discussion and have requested more info (specifically in regards to use cases to justify the API development and ensure compliance with legal).
This is fantastic and we love seeing more transparency on what TSB is working on towards APIs. Thanks for sharing the TSB feedback, and the Developers Hub & Documentation @Cyril!
While it all seems under construction and most documentation is yet missing, we feel this is a great step towards a more 3rd party developer friendly environment.
Regarding the feasibility of implementing the requested data fields, initially, here is our answer:
Wallet addresses: We will need to check with legal if it’s possible, as it could be sensitive data that could be exploited by malicious actors.
KYC status: only the status should be ok, but will check with legal anyway.
Ongoing and persistent saved variables for each user: We will need more details on the possible use-cases in order to understand how could be the best way of providing this data points.
Quest completion: Same as above
Total playtime: Same as above
high scores: Same as above
As I already anticipated, we are already advanced on the first iteration of the API (you could check our Developers Hub site here), and initially it is aimed to giving third-party developers access to our content (Assets, Avatars) and to allow “Login with Sandbox Account” functionally (for the logged-in user you could indeed request user profile data, but not for other users yet).
Sharing wallet address details is probably not a legal problem. But even if it poses a problem in accordance with the laws that TSB is bound to, if the user introduces his wallet to the 3rd party site with his own consent, the wallet can be checked by TSB and get the information.
KYC information sharing or status sharing is prohibited everywhere as far as I know. Today, even the global systems and local systems of the stock exchanges demand separate KYC. they do not accept KYC status even within themselves. Maybe it may be different for TSB.
It’s not illegal to share whether an account is KYC or not, I think Biversen is saying that if an API user were required to do KYC it would be illegal to use Sandbox’s to check the box.
Anyway, I assume @theKuntaMC you are talking about the use cases? Or what do we need to continue here.
