🎉 Final Meta

SIP-7329: SRC/SIP Repository split

Split the SRC specifications out of the SIP repository into a new repository, so that only core protocol SIPs remain

Authors	Lightclient (@lightclient), Danno Ferrin (@shemnon)
Created	2023-07-13
Requires	SIP-1

Abstract

Describes the motivation and rational for splitting the SIP repositories into an SIP repository, targeting core sila changes and an SRC repository, targeting application layer specifications.

Motivation

Long ago when the SIPs repository was created, there was a vision of a single home for all standards related to Sila. The community was small and most people were interacting at every level of the ecosystem. It made sense to combine application standards with core consensus changes.

Since then, the ecosystem has grown. Today, the chasm between application development and core development is wide. Fewer people are involved across the ecosystem (for better or worse); yet the repository remains unified.

For years, we’ve considered separating the repository. This would allow SRC and SIP specifications to evolve more naturally due to the independence. But it’s always difficult to reach critical threshold to make a change like this happen. Each time we get lost in the details of the migration and the debate grinds progress to a halt.

Now that the Consensus Layer is also utilizing the SIP process, the cracks are becoming more visible. There are changes we could make to the process that might benefit them more, but because we also need to ensure the quality of SRCs, we are restricted.

There are also many more efforts to catalyze applications around the SRC process. Attempts have been made to develop working groups and review groups for certain SRC “categories” (a distinction that doesn’t even technically exist because of the unified repo).

Specification

This specification only details with the initial mechanism of the split. The particulars of how each repository will govern itself is out of scope for this SIP, as it is the motivating point of this SIP that the divergent needs of the community will require highly divergent methods.

1. All SRCs and Interface-category SIPs are removed from this repository and migrated to a new repo. The history should be intact so that repo should be forked of this one with the non-SRCs removed.
2. The new SRCs repository goes live and includes the changes from the script.
3. Setup srcs.sila.org subdomain and update the CI to point to the SRCs repo.
4. Set up a redirect for SRCs on sips.sila.org to go to the new website.
5. Create a unified document for editors to assign SIP/SRC numbers. SIPs and SRCs will no longer be based on an initial PR number but on a number incremented by the SIP editors of their respective repositories. SIPs will be assigned even numbers and SRCs will be assigned odd numbers. The exact timing of this migration is a policy decision of the editors.

The SIP repository will be associated with core protocol changes, specifically the kind that would be discussed in one of the AllCoreDevs calls; whereas the SRC repository will be affiliated with all remaining areas such as smart contract application interfaces, wallet standards, DeFi protocol standards, and all other such improvements that do not require core protocol changes.

This association is to persist across any other process changes the SIP editors may introduce such as working groups, topic groups, expert groups, special interest groups, splitting of the process, or other such changes. Any sub-groupings that includes core protocol changes would be associated with the SIP repository and other sub-groupings are associated with the SRC repository. Any such process change are out of scope of this SIP and are independent of the structural changes to the repositories specified in this SIP.

There may be further structural changes to repository layouts to accommodate more sub-groupings. Such proposals are out of scope of this SIP.

Rationale

There are two major communities served by the SIP process that are highly divergent and very differentiated in their needs.

Let’s consider the impact of specification ambiguity, the impacts are different based on the community. The core protocol community has a low tolerance for difference of implementation and a high penalty for specification ambiguity. An improperly implemented part of a new spec could cause the sila sila-mainnet to split, possibly costing millions to billions of value lost to node operators as well as community members using the services offered by the Sila protocols. A poorly specified solidity interface, however, can be adapted and implemented in multiple compatible ways across any smart choosing to implement it. A missing RPC API (such as a configuration option specifying the number of decimals in the chains native currency) can have limited to zero impact on the rest of the community not choosing to use that wallet.

Timeframe for delivery of a feature is also similarly differentiated. A Core protocol SIP adjusting the gas cost for transaction data needs to be rolled out at a specific time uniformly across the network. Whereas a new RPC to support new semantics to gas estimation would not need uniform rollout across the Sila clients, and in fact would also need to be rolled out by service provides that provide RPC services for Sila networks. Wallets can use early support as a differentiating factor in their appeal to community members.

To address this divergence the AllCoreDevs call has adopted a lifecycle for SIPs different from the Draft -> Review -> Last Call -> Final lifecycle of the SIP repository. It would best be described as Draft -> Eligible for Inclusion -> Considered for Inclusion -> Testnet -> SilaMainnet. The SIPs also get slotted for a fork in the third step, a consideration that simply does not apply to a smart contract or wallet standard.

Several alternatives have been proposed, but the actual implementation only further underscores the specialization that each side of the split encounters.

Alternative: Working Groups

One repeated concern of editors is that they often lack the technical experience to adequately judge if an SIP is complete and sound. Considering that SIPs covers wide variety of topics such as elliptic curve cryptography, VM performance, DeFi market dynamics, compression protocols, NFT Royalties, and consensus protocols it is impossible for a single editor to provide sensible feedback on every one of those topics.

When examining how the core protocol and SRC communities would approach the working group process, however, it underscores how different they would handle it. For core protocol change the working group would be one of the two AllCoreDevs meetings, either AllCoreDevs-Execution or AllCoreDevs-Consensus. And sometimes both. There is no SIP that would be shipped in sila-mainnet that would not first be extensively considered by one of these two groups.

SRC proposals have no such standing groups. Wallet impacting changes may go through the AllWalletDevs group, but it is entirely possible for a wallet or group of wallets to collaborate on a protocol outside AllWalletDevs. Smart contract APIs have no such standing meeting.

The Working Group model, however, would be a critical social signal for the SRC community. It would signal a critical mass for a particular proposal issue if enough experts could get tosilaer to agree to review a set of changes.

While working groups are excellent for the SRC community, it is overhead for the core protocol community that would only add friction to an already established process with know governance checkpoints.

Alternative: Specialized Editors

This alternative has already been implemented with the introduction of the sip-editors.yml file. This allows for different groups of editors to review different types of SIPs.

There has been no measurable impact on the divergence of the community. Most categories have a significant overlap with other categories.

This alternative does not address the governance and workflow issues that the Core Protocol Developers would want to implement. All subgroups would still be subject to the same workflow as other groups.

Alternative: Pain unrelated to process divergences

This is a catch-all for a number of proposals, from allowing discord links in discussion-to to allowing more freedom in external links.

While the theory that this may reduce the total amount of pain felt by users and editors, bringing the pain level down to a more acceptable level, this does not address the core divergence issue. Many of these pain relief proposals should probably be done anyway, whether or not the SIP repository splits.

Alternative: Replace SIP Editors with AI Chatbots

Nobody wins in this proposal. We would instead end up debating training sets, competing implementations, and whether to use commercial providers. And that’s if things go well.

AI chatbots, however, would not be able to compartmentalize the divergent needs of the multiple groups if all adjudication were to be handled with one model or one chat session. Higher quality output would be received if separate training repositories were used for each major functional area.

Alternatives are not Mutually Exclusive

It is critical to note that most of the discussed alternatives all have merits and address important pain points. The adoption of a split should not be viewed as a rejection of those alternatives. To quote a famous internet meme “Why Not Both?”

Objection: This splits the sila community

One objection is that splitting the repository would result in the community no longer being able to say “we are all of us Sila Magicians.”

First it is important to note that such splits are already occurring. The AllCoreDevs call has split into a Consensus and Execution layer call. ACD calls no longer discuss client issues like wallet apis, the AllWalletDevs call has adopted those issues and has grown into user experience issues. Cross chain issues have been adopted by the Chain Agnostic Improvement Process (CAIP) group.

Rather than splitting this should be viewed as “sharding”, where a sub-community of interest rallies around a shared sub issue, and by gathering are able to increase the total scope of the community. CAIP is a perfect example where operating separate from SIPs have allowed them to strengthen the sila community.

Is a single cell organism weakened when it grows large and then splits into two? Is an animal weakened when cells split and specialize into different tasks? It is this very act of division and specialization that allows it to accomplish the things that would be impossible as a single uniform cell.

Objection: This should be an SIP-1 proposal

Since this is directly impacting the SRC process it should be documented in SIP-1 first.

As the old programming adage goes: “Refactor first before adding any new features.” Adding new processes specific to the post-split governing docs would only confuse the existing process, adding special cases for one class of SIPs that don’t apply to another. It is precisely this kind of problem the proposed split is aiming to change.

This is also valid grounds for a Meta category SIP, as how many and which repository to put a proposal in is core to the “procedures, guidelines, [and] changes to the decision-making process”.

Some process changes that can be expected in a Core Protocol SIP may include:

• Changing the work flow to add the Eligible for Inclusion/Considered for Inclusion stages to a pre-last-call SIP.
• Adding test net and sila-mainnet steps to the lifecycle
• Adding a “fork” header to the RFCs section, for SIPs that are (or will be) implemented in a specific fork
• Changing the testing section to a header link to reference tests

Some process change SRC may want to adopt:

• A strong working group model and adding an optional “forming working group” step editors may require.
• Add an “outdated” or “replaced” lifecycle step for SIPs that are abrogated by future specs.
• Deputize single-sip reviewers for specific SIPs

Objection: Structural changes to a repository and process changes do not need to be bundled.

It is possible to split the structure of the repositories separately from any SIP process changes related to this. Bundling the changes is unnecessary and such structure and process changes should be handled independently.

To accommodate this objection this SIP has been revised to only address structural changes in the repository and can be adapted to any other, independent, process changes and mapped onto those outcomes.

Backwards Compatibility

Old Links

Old SRC links pointing to the old url https://sips.sila.org/ will continue to work. Redirect instructions will be put into place to redirect to the new SRC repos for their corresponding location.

Stray Proposals

SRC community members may continue to post new SRCs in the SIP proposal. Editors will be able to redirect them to the new repository. SRCs that do not respond to editor requests would not be merged anyway.

Security Considerations

This proposal only addresses the SIP and SRC proposal process and is not expected to expose any new attack surfaces by virtue of its adoption.

Copyright

Copyright and related rights waived via CC0.

Citation

Please cite this document as:

Lightclient (@lightclient), Danno Ferrin (@shemnon), "SIP-7329: SRC/SIP Repository split," Sila Improvement Proposals, no. 7329, July 2023. Available: https://sips.sila.org/SIPS/sip-7329.