Apillon Web3 development platform as a common good infrastructure - Polkadot Treasury Proposal

This post is an informal notice as we want the Proposal to reach the complete volume of the Polkadot and Web3 communities. The official discussion is taking place on Polkassembly - feel free to join us there as well. Apillon Web3 development platform as a common good infrastructure - Polkadot Treasury Proposal | Polkassembly

With this Proposal, the Apillon platform would transition to an open-source infrastructure solution with permanent freemium access, governed by the community, and thus become a common good project, further spurring Web3 adoption, Polkadot ecosystem growth, and DOT utility.

Apillon (apillon.io) is a Web3 development platform (app.apillon.io) empowering developers to easily build dapps and other Web3 products in the Polkadot ecosystem.

Currently, the platform provides the functionality of dashboard-based deployment of Web3 services and API connectivity - the parachains’ functionalities are abstracted and translated into ready-to-use, few-click Web3 services that can be combined to power multi-chain Web3 projects.

Through DOT-based open governance by the Apillon community, the platform would undergo future upgrades, including integrations of voted parachain and other services, to best respond to users’ needs and deliver user-oriented opportunities for Web3 adoption.

We want to make the concept of Apillon’s Treasury Proposal as comprehensive and transparent as possible. We will do our best to provide additional explanation and information you might request.

Additional links:

Please post any questions, concerns, or feedback in one of the following ways:

  • In the comments section below
  • In the Polkadot Forum comment section (informal)
  • In the Polkadot Direction Element channel comments section (informal)
8 Likes

This sounds exciting, I would love to use a Polkadot powered solution. I recently learned about IPFS, IPNS, and pinning. After following the tutorials on ipfs.tech I setup a local node and hosted a static single web page site. After that I chose to use a centralized hosted pinning service to ensure availability. I pay a monthly fee for this service. Apillon+Crust sounds similar to the Fleek value-add service on top of the free IPFS. Is this a fair comparison?

Can you provide an ELI5 of how the different parts of this offering are decentralized?

On the IPFS website they talk about Avoiding centralization

When I watched this Crust Tutorial 4:00 I noticed the selection dropdowns for an IPFS Gateway and Pinner…

So I am trying to understand how your offering differs from that of other centralized value-add hosting services.

4 Likes

I read your proposal and wiki yesterday - it is incredibly thorough, well written and considered.

You are definitely focusing on a clear pain point - essentially you are aiming to create an ‚Äėoperating system‚Äô framework for the Substrate ecosystem.

High level

Apillon pursues Polkadot’s multi-chain vision by seamlessly linking supported parachains in
an opinionated manner and translating them into decentralized microservices called Web3
Services.

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?

Integrations / ecosystem positioning

  • Is this project expressly focused on abstracting the specific logic of current parachains to Polkadot?

  • Will you be doing the same for Kusama?

  • Will you be doing the same for solo-chains that are not part of either relay?

Parachain Dependability section

Polkadot’s approach to creating a competitive market is leasing parachain slots to niche
parachains. But it could also lead to certain services not having a redundancy offering,
making them risky to governance pivot in the long run. In case of a service failure, Apillon is
thus currently unable to provide service alternatives or redundancy

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.

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?

Governance / Token / Funding sections

As a common good project, Apillon should be funded by the ecosystem and, in exchange,
governed by the Polkadot community. This would ensure that the path of project evolution
remains transparent, open-source, and within community needs.

Post-funding changes to Apillon:
‚ßď The Apillon platform becomes open-source.
‚ßď Apillon‚Äôs product offering is governed via Polkadot governance.
‚ßď Apillon‚Äôs NCTR token is removed from the open-source project; the main token used
is DOT.
‚ßď Apillon becomes the first Common Good Infrastructure project on Polkadot. It does
not pursue a parachain slot in the first year of operation.
‚ßď Apillon continues large-scale marketing activities and establishes clear adoption
KPIs.

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.

Final question

Why do you think Polkassembly’s off-chain interface is more official that say here?

3 Likes

It is a fair comparison. We use IPFS and instead of a central pinning service, we utilize Crust parachain for decentralised pinning. As for hosting service we are running our own IPFS gateway with a reverse proxy capable of generating an SSL certificate for your domain, powered with IPNS and deploy procedure mimicking Web2 deploy pipelines (simple to setup with Github actions or any other automatization tool).

This is all already live and running and you can check it out: https://app.apillon.io/ So as for centralized / decentralised. The underlying service of what is on IPFS and how it’s pinned is fully decentralized while our ipfs gateway works the same way as others, meaning if it goes down your domain will be pointing to an empty service. The website is still available directly through iIPFS but not through a domain. Since domain resolving works though existing Web2 solution and IPFS gateway is exactly as its name suggests a gateway to Web2. Now how we will try to address this in the future is:

  • IPFS cluster of multiple gateways to ensure availability
  • option of dedicated ipfs gateway specifically for a project
  • open sourcing our code, reverse proxy, etc. So anyone can set up their node and sync with us supporting blockchain domains.

But in the end, the only real solution would be using IPFS directly through a browser that supports that (like Brave browser and Opera).
With any integration we do we always make sure that the underlying service is fully decentralised, but the service around it can have some centralised parts and we believe there is nothing wrong with that as long as the result is decentralised.

Keep in mind though, Apillon covers way more services than just storage and hosting. We already have NFT Smart Contract deployments for Moonbeam and Astar, with Authentication and Compute services coming in the following weeks.

Tadej Vengust | Apillon CTO

3 Likes

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.

1 Like

Thanks for your replies - makes sense.

The other point I forgot to reference which is more of a general remark for the ecosystem is that you are requesting funds solely from DOT, and also promising to make DOT the fee token after the 2 years.

This makes a lot of sense, but also illustrates the independent nature of the KSM relay economy - there need to be apps that are solely focused on ensuring fees are paid in KSM to ensure it survives.

2 Likes

We have now updated the Polkassembly post with the date of the proposal going live on-chain as well as the link to our discussion on AAG.

For a better visual positioninig of Apillon:

Would love to keep this conversation going and get more feedback from the community.

3 Likes