With the Foundation assuming responsibility for core Sia software such as consensus, p2p, etc., the future of
siad is unclear. In the original proposal, I stated that the Foundation would pursue a “minimal full node.” To me, that meant a node providing only the gateway, consensus, and transaction pool modules. The Foundation would also develop host, renter, and wallet libraries. (In practice, this would probably just mean adopting the
us project.) Skynet Labs would then build on the Foundation’s node and libraries, adding their hostdb, renter, Skyfile support, etc., and then wrap the resulting daemon in an HTTP API to form
siad as we know it today.
However, some objections have been raised to this plan. In particular, this arrangement would mean that anyone wanting to build on the current
siad API would need to get their software from Skynet Labs, rather than the Foundation. Furthermore, this arrangement would require Skynet Labs to continue maintaining code that is not relevant to Skynet itself, such as the wallet and explorer modules. As an alternative, it has been suggested that the Foundation inherit
siad in its entirety. Skynet Labs would then continue to develop
siad by submitting merge requests, which would need to be reviewed by the Foundation.
The fundamental question here is: which parts of
siad, as it exists today, should the Foundation be responsible for? In other words, there are basically two options (glossing over many minor details):
- Proceed as stated in the proposal. The Foundation maintains a minimal full node, along with host and renter libraries. Skynet Labs builds on these and to form
siad. Hosts, renters, and developers either use
siador build custom solutions using the Foundation node and libraries.
siadentirely to the Foundation. Skynet Labs continues to heavily develop
siad, but their merge requests must be approved by the Foundation. Hosts, renters, and developers use
Personally, my preference is option 1. I like that it allows the organizations to ship code independently, and that it encourages the development of custom solutions. I’m also not keen on the Foundation inheriting the existing
siad codebase and committing to supporting its API; in particular, it’s not clear to me how the Skynet-specific endpoints would be handled. I’m much more motivated by the prospect of starting fresh. (Yes, the Foundation will be inheriting the gateway/consensus/tpool code regardless; however, this does not necessarily mean supporting their existing APIs, and the Utreexo effort will entail major refactors of these modules anyway.)
On the other hand, option 2 is probably more desirable for Skynet Labs (aside from the added friction around merge requests and the loss of control over release timing). It may also be preferable to those who want Skynet Labs to have the same position in the community as other third-party developers. Another advantage is that end users don’t have to make a choice between two different daemon binaries.
I’m very interested to hear community opinions on this, so please weigh in with your thoughts. Which parts of
siad, as it exists today, should the Foundation be responsible for? Which organization should be responsible for supporting the
siad API? And what do you think the situation should look like 5 years from now?