⧓ About Apillon
Apillon is a Web3 development platform empowering developers to build in the Polkadot ecosystem.
The Apillon platform serves as a unified gateway to the Web3 services provided by linked Polkadot parachains. Following the multi-chain vision, Apillon powers the transition of developers to Web3, simplifying its adoption in the real economy, and expanding its versatility as the ecosystem grows. With Apillon, Web3 services are within reach for every developer, regardless of their background and experience with blockchain technology.
Connecting the DOTs
Beyond our technical delivery and different product integrations, we believe it’s important to point out what the current version of Apillon demonstrates on a higher level, its unique value proposition, and what differentiates Apillon from competitors.
At the point of writing, Apillon has fully integrated the following parachains:
- Crust Network
- Moonbeam Network
- Subsquid
Following the technical integration of these parachains, we have abstracted five Web3 infrastructure services:
- Web3 Storage (via storage buckets)
- Web3 Website Hosting
- Dapp deployment
- NFT collection deployment
- Web3 Computing
We see a huge difference between the parachain integration and the services we provide on top of those integrations. Here’s how.
Decentralized storage and hosting & Crust Network
Crust Network integration helps us ensure files are distributed (pinned on multiple locations) on the IPFS network. From here, we have developed a Web3 Storage service that delivers a user experience mimicking typical AWS S3 storage buckets.
We understand that if we are to boost the adoption of Web3, we need to cater to a wider audience of developers by relying on and mimicking the services they are already using. Not only because it saves time, but because a certain level of UX consensus was already reached by the Web2 cloud providers in the past 15 years or so on how to represent storage abstractions in a way that aligns with typical development workflow, planning, architecture and finally, execution.
Looking closely at the IPFS storage as envisioned by Crust, it quickly became obvious that a website hosting should be sourced from this parachain, as well. So we have built a typical Web3 Hosting service where users can rely on a 2-staged approach for deployment — staging and production — allowing them to preview their website deployment before committing to blockchain interaction.
Again, here we are relying on years of UX rules set by thousands of hosting providers over the past 30 years or so. Certain flows and UIs simply became standardized and we have a great opportunity to utilize that and speed up the development process also in the Web3 arena.
Web3 development UX
It is important to note that in the developer’s context, we interpret UX much broader than just the platform’s UI, where users can create storage buckets, as we are not a “no code” solution.
We expand our UX horizons to the APIs, Documentation, CLI and Apillon’s own SDK, where we follow the same mentality. Want to store a file in a decentralized storage? Create a bucket on Apillon, scaffold the project in your favorite language, integrate the Apillon API and start pushing the files like there’s no tomorrow.
We are not in the business of simply translating one SDK to another, but instead, we go deeply into a single service, review its functionality and limitations, find the parallels to the existing Web2 services, and ask ourselves how can we bring that UX on top of modern Web3 tech. Keep in mind that Apillon’s mission and vision are both driven toward speeding up Web3 adoption.
The mission of Apillon is to accelerate Web3 adoption by continuously empowering its builders as it pursues the vision of accelerating the world’s transition to a completely decentralized Web3 future.
The mission and vision of Apillon are ultra-important pieces of information because they force us to filter every new idea for product development through these statements and determine whether it would be beneficial for Web3 adoption or not.
As I will expand on in continuation, almost everything we do is submitted to end users’ experience and mainstream Web3 adoption.
Thinking in Apillon — Synergies
Now that it is clear how we approach individual parachains, it is also important to mention how we think about synergies. To explain synergies better, we are now adding the Moonbeam parachain to the story.
Moonbeam Network
The decision to integrate Moonbeam Network brought Apillon an opportunity to expand further in its capabilities and empower developers to create and deploy fully functional dapps.
The first smart contract we have supported from Moonbeam is a customized ERC-721 — an NFT minting smart contract. We chose to go with this standard not only because NFTs are an important part of the blockchain future, but also because Apillon can solve a typical issue most NFT projects have right now, namely metadata and NFT media storage, completely free of charge.
Remember FTX? FTX sold thousands of NFTs with their media files stored on centralized FTX servers. Once the ship sank, those servers were shut down, and all NFT owners got stuck with NFTs linking to a 404 site. Neat, isn’t it?
So, it is very obvious that the first step before proceeding to deploy an ERC-721 contract and start minting an NFT, is to address the question of [NFT metadata and its media files storage]. Luckily, Apillon has this already integrated, with a polished UI, allowing us to start playing with the first synergies.
When an Apillon user decides to create an NFT collection, they are guided by a wizard offering two options. They can either provide their own metadata URI or store the metadata and NFT media files using Apillon storage buckets, consequently storing those files on IPFS via Crust, making them decentralized, unstoppable, and permanently available. Point being, we can rely on Apillon’s own services synergy in building improved workflows for developers.
This synergy approach allows us to consider all existing parachains or Polkadot solutions and ask ourselves, “How would the integration of this specific service benefit the end user — the developer, and how many synergies can we create with existing integrations?” This is Apillon’s approach to Polkadot interoperability without relying on protocol-level XCM standard or other “complicated stuff”.
Apillon lives on a building layer (or Layer 3), right under the application layer, where ordinary users enter Web3. So we have a unique position to think from the perspective of a developer, as well as from the perspective of Web3 adoption and end users who will end up using Web3 solutions.
KILT Protocol
So now, the story slowly takes us to another parachain, KILT. At the time of writing, Apillon has developed an internally fully functioning KILT integration prototype. However, the KILT-based Web3 Authentication service is yet to become available to the general public. We will go into reasons for it a bit later, but for now, let’s review what KILT brings to the table.
Decentralized Identifiers is a W3C standard that was released as version 1.0 in the July of 2022. W3C is the most important standardization body in the evolution of the Web, including Web1, Web2 and most likely Web3. The DID standard shows that W3C is heavily aligned with the general Web3 goals, like user privacy and ownership, and KILT is one of the first on-chain implementations of this standard. From Apillon’s perspective, having a partner that relies on a W3C standard gives us the unique advantage of architecting our services “the right way”.
To keep the Layer 3 synergy thinking in Apillon and empower all Apillon users to reach all Web3 targets (ownership, privacy), we need to think about how to position our Web3 Authentication service, currently built on KILT. If we put ourselves in the shoes of a new Web3 developer, she or he will have to ensure privacy and ownership as features of the Web3 apps they build on Apillon.
We believe that everything in Web3 starts with user identity. Currently in Web3, privacy and ownership are mostly achieved by using wallet extensions, but this has proven to be a huge hinderer of user adoption because it includes mnemonic phrases, transaction or action irreversibility due to blockchain immutability, and massive friction in the mobile app development. Besides, users are nowadays also prompted to add the X wallet to their collection of wallets to use the Y service. With all this in mind, is it a valid experiment to test whether Decentralized Identities, or DIDs as envisioned by the W3C, are a better way of tackling user friction in Web3 adoption?
At Apillon, user privacy, sovereignty, and asset ownership are seen as an identity-first solution, where all other parachain services are hierarchically layered under the Web3 Authentication service. This means that when a developer builds a Web3 application on Apillon, the identity-first design is opinionated and enforced. All users that onboard Web3 using dapps built on Apillon will therefore enjoy the following trustless guarantees:
- Self-sovereign identity as provided by W3C implementation via KILT Protocol
- Decentralized file storage via Crust, where file ownership is linked to user identity
- Moonbeam and Astar-powered smart contract deployment, where smart contract ownership is linked to user identity
- Integration of parachain N, where the ownership of the outcome of interaction with parachain N is linked to user identity
This kind of approach ensures that all users can control the complete scope of their privacy via DIDs, and all actions they do on Polkadot parachains are accounted for and owned by their accounts linked to DIDs. In theory, all users can then detach themselves from any undesired services, move their files or do any action on chain, bypassing Apillon, giving them full control over their online identity and digital assets, as promised by the Web3 manifesto.
We are still far from this solution, so the purpose of the above at this point is simply to demonstrate our project design thought process, long-term thinking, and ideal-case outcome in Apillon’s future.
When thinking of DIDs within our vision of delivering superior Web3 UX, we acknowledge the fact that once the DID credentials are attested and generated, the user is faced with two options:
- Storing their .json credentials locally
- Storing their credentials in a wallet extension
Neither option removes the friction between the user and any Web3 application. This is why we came up with an innovative solution internally called DID Vault. We wrote a W3F grant application to support it, and if you are interested in how the DID Vault works, you can read more about it here: Apillon Grant Request by ninoCookies · Pull Request #1319 · w3f/Grants-Program · GitHub.
To summarize the DID functionality, it is essentially a decentralized, end-to-end encrypted DID storage, allowing users to either store DID on their computer, in the wallet extension, or simply encrypt the newly generated credentials within the browser and send it to the decentralized storage. Each time they log in using these credentials, a user goes through the Oauth-like experience:
- Log in to Apillon
- Enter their email address
- Encrypted DID is pulled from the decentralized server to the user’s browser
- User enters the password to decrypt the DID and uses it to log in to the Web3 service
It’s a brief example but takes extensive work. We’re ready to bring Web3 building UX to the next level, and we will continue to do so whenever a clear opportunity arises.
Phala Network
One of our amazing developers is currently working on the first Phala — Apillon use case. We are writing a custom Phat Contract in Ink, which will soon get deployed to Phala. Soon after, the first use cases will be enabled.
Subsquid integration
Since we are abstracting a lot of problematic things for our developers, we are the ones that need to handle creating, batching, monitoring transactions on multiple parachains, etc.
To handle our internal blockchain monitoring, we integrated Subsquid. This parachain indexer is fast, reliable, and able to support our complex use cases.
But this is just the first step of our Subsquid integration. So stay tuned for more updates.
What can we expect in the next quarter?
In the next quarter, Apillon will continue expanding horizontally. This means integrating new parachains and building new Web3 services from them while maintaining the existing integrations with polished and sleeker UI.
We are constantly monitoring the usage of our platform, so we will soon be able to say which of the already integrated services will get their own vertical updates. We could either expand the offering with the smart contract templates or Phat contract solutions or even expand the Web3 Authentication vertical. Either way, it is going to be an ultra-interesting quarter for Apillon and Web3 development.
Parachain integrations confirmed for Q2
- KILT Protocol
- Phala Network
- Astar added to dapp protocols
- Subsquid service
Besides, we are soon releasing a public website where anyone will be able to access the Apillon changelog and versioning, as well as the public Roadmap.
Exciting times ahead!