Am I correct in thinking you want to create a framework for something akin to ‘iOS’ on polkadot’s decentralised settlement and business logic (firmware) core?
We look at our platform from the eyes of the developer. Which tools might the developer need in the future and which Parachains, solutions, protocols or just parts of Parachains in Polkadot can enable that specific functionality. A nice and similar case from Web2 would be Firebase.
On the second step, we review how this specific integration plays with other integrations, providing “infrastructure interoperability”. e.g. our NFT deployment flow provides you with metadata decentralized storage on one Parachain and then deploys the smart contract to another from the same flow. This is our primary goal.
Because of the nature of the product: open-source, governance based, we don’t feel this is directly comparable to iOS, which is a closed, centralized system, while Apillon has the Web3 foundations that allows community driven change over time, thus relieving “vendor lock in” conflicts.
Is this project expressly focused on abstracting the specific logic of current parachains to Polkadot?
Right now, we are heavily focused on the horizontal scope of the Polkadot offering, primarily Parachains. With that, we specifically mean we are trying to quickly derive most needed functionalities from a wide range of Parachains. With time, we are planning to go vertically into specific Parachains (those that get used the most on Apillon) and derive more value from them. That said, Polkadot Parachains are our main focus, since we believe those are more stable.
Will you be doing the same for Kusama?
We have not included Kusama solutions into our first milestone, but we are constantly monitoring the maturity and match of projects on Kusama. We are implemeting Polkadot parachain primarily since we believe those are more stable and Kusama is in its context a testing/canary network with lower monetary value. That said if there is a Kusama parachain that will not be on Polkadot and it would address a need for our developers we will integrate it.
Will you be doing the same for solo-chains that are not part of either relay?
We have integrated Crust as a solo-chain before they reserved their slot, to promote Web3 decentralised storage (one of the main services Web3 developers need). That said, once the project passes our internal checklist and we establish a healthy personal relationship with the team behind the solution, we are looking to integrate solutions that are not necessarily Parachains, but function within the Polkadot ecosystem.
Apillon’s ‘opinionated service’ is as you correctly state entirely dependent on lower level dependancies that may well not have continuous uptime, long term resilience or predictable governance.
Yes it is true. Apillon utilises Parachains and derives value from them. If a parachain would stop functioning for some reason, or the governance would change the direction of that specific parachain, that underlying service would cease to function as expected. This is therefore the question for whole Polkadot ecosystem and its underlying community. For now, we believe Polkadots governance and the people behind it, pursue the same exact values as Apillon - Web3 adoption. As long as we are aligned on the core values, the risk is minimal.
Without some guaranteed consistency here, why would developers want to risk building on Apillon if the sands shift under their feet in a manner entirely consistent with the issues of ‘platform risk’ that pervade ‘Web2’?
This is effectively the primary case against Apillon’s ability to deliver on its vision.
Do you have any views on this? For example, you could just include system chains?
We have touched base of Apillon risks in the proposal, directly tackling the question of redundancy. Now, even though edge scenarios are possible and it is good to point them out, so far our experience in working with parachains has been stellar, so we have high confidence in Polkadot ecosystem and solutions involved in it (as already mentioned)
By going open source, common good with community based governance, we are directly giving longevity to the product as well as vendor lock in mitigation. Developers will therefore not only use the product, but help shape it, via governance, allowing them to make the right choices on the long run.
On the question of system chains, yes, definitely something we are going to integrate in further milestones. We have mentioned Statemint as a possible core solution for our Price stability module.
This seems well thought through and could become a model for other common good / system chains that do not fit easily into current 'parachain / L1/L2 frameworks.
I guess in answer to my above questions, since value accrues directly to DOT and not KSM, it makes most sense to only include parachains bonded and incentivised via the DOT token.
Fee structures also seem smart.
Thank you for the kind compliment. We have put a lot of thought into positioning of our product technically and we see these parameters as a forward thinking trend that gives transparency and further boosts trust into Web3 products.
Why do you think Polkassembly’s off-chain interface is more official that say here?
We wanted to invite as many people to the public discussion as possible so we are targeting all relevant channels. Fact is, voting still happens on Polkassembly.
