The Future of siad

Foundation
#1

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):

  1. 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 siad or build custom solutions using the Foundation node and libraries.
  2. Transfer siad entirely 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 siad.

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?

#2

I like option 1 for the following reasons (in no particular order):

  1. I think it is a cleaner split to start and sets a better precedence for splitting code in the future. That precedence being that anything common to all sia nodes is handled by the foundation and any specific modules are handled by the respective organization. I would include the explorer and wallet modules in the initial split as well. Since there is still a lot of code in the renter and host modules that is common to all sia nodes, the Foundation can contract with Skynet Labs to work on splitting out the code appropriately. This would additionally set a precedence of handling pulling common code back into the Foundation’s ownership.

  2. Having the foundation managing merge request related to Skynet will be a distraction to the Foundation, a road block to Skynet Labs, and overall a further blurring of the lines between the two organizations in terms of code ownership.

  3. Taking ownership of the code that makes a minimum siad also forces the conversation of what that is which I think will be beneficial in other conversation. If the Foundation just takes over all of the siad code base we are just postponing that conversation.

  4. Having Skynet Labs retain ownership of the modules that we believe are necessary for Skynet also forces us to honor that and defend prioritization of development on those modules. If we find ourselves not prioritizing feature requests or bug fixes from the community because we don’t believe they are a priority for Skynet, then we should be able to either articulate where in the priority list it falls or work on moving that code under the foundation.

2 Likes
#3

I also agree with Option 1. I’ve always been a fan of a more minimal/modular approach to siad and i think the us is a great start to that. Also I love the idea of a fresh start. There are some tricky things siad has had to do to maintain API-compatibility, and think its due time we can start fresh :slight_smile:

However, I do think that siad should be eventually interfacing with the lower-level libraries that Foundation provides when they are ready. A layered-onion approach will ensure the foundation modules get sufficient real life usage, and is more resilient to accidental hardforks due to the shared-logic.

#4

If you start fresh, what happens to companies and apps building on the legacy code?

#5

I guess if worst comes to worst, Skynet Labs can probably maintain the legacy API under skyd and ensure old apps still work if they upgrade.