Path for supporting presently-third-party apis

[MSevey]

Issue by xloem
Monday Jul 06, 2020 at 13:07 GMT
Originally opened as NebulousLabs/skynet-docs#12

---

As someone who's put work into supporting skynet in another language, I was wondering if there was any available avenue to bring such work into the main supported repository. I could for example work to meet the guidelines of the other apis and look for a co-maintainer, but I'd like to know the avenue is available first.

I started a c++ api at https://github.com/xloem/siaskynetpp but it will need cleanup and redesign to match the interface norms.

[MSevey]

Comment by MSevey
Thursday Jul 09, 2020 at 13:36 GMT

---

Hi @xloem
I saw you commented on the MR for the Ruby SDK but I'll quote David here for others looking at this issue.

Hey, we really appreciate you making a third party SDK supporting Skynet in the form of ruby. Unfortunately, we have a few requirements for SDKs that get listed on the homepage, and so we can't include ruby. Chief reasons:

1. We don't control the repo. If you (or someone else adding their own SDK) were to add malicious code at some point, we would be sending our users to that code from the homepage.

2. We want all of our homepage SDKs to maintain feature parity. As we are adding features to Skynet rapidly, this means that every time we update our SDKs, we need to update all of them. We don't control third party SDKs, which means we can't ensure they support all new features in a timely manner.

We're happy to tell the world about your ruby SDK over our social media channels though - discord, twitter, potentially the mailing list, if you would prefer that?

As for your response/suggestion https://github.com/NebulousLabs/skynet-webportal/pull/120#issuecomment-650109032
The main issue is that we take a strong stance on backwards compatibility with our API and want to offer that for our SDKs as well. So if we start supporting a new SDK we need to continue to support that SDK for the lifetime of the project. I appreciate the idea of having trusted third party maintainers but ultimately the responsibility falls on us and we need to have the internal capacity to maintain the SDK. At this point we need to prioritize getting the current SDKs feature complete with the API before considering additional SDKs.

We do need to define a path/strategy for third party SDKs, we owe that to the community. Our default has always been to support the third party developers and help publish their work to the community but leave the repo in their control.

I will leave this issue open for now and hopefully we can provide some communication to community soon.