Grant Application for Internets

[adotlex]

Project Internets

Internets (previously Interlayer) is a Programmable Message-Passing-Neural-Network layer 1 blockchain. Internets' purpose is to unify web3 fragmentation by utilising graph theory to create a 'network of networks' - an environment of shared blockchain primitives allowing Interchain application development, deployment, and interaction.

Grant level

• Level 1: Up to $10,000, 2 approvals
• Level 2: Up to $30,000, 3 approvals
• Level 3: Unlimited, 5 approvals (for >$100k: Web3 Foundation Council approval)

Application Checklist

• The application template has been copied and aptly renamed (project_name.md).
• I have read the application guidelines.
• Payment details have been provided (Polkadot AssetHub (USDC & DOT) address in the application and bank details via email, if applicable).
• I understand that an agreed upon percentage of each milestone will be paid in vested DOT, to the Polkadot address listed in the application.
• I am aware that, in order to receive a grant, I (and the entity I represent) have to successfully complete a KYC/KYB check.
• The software delivered for this grant will be released under an open-source license specified in the application.
• The initial PR contains only one commit (squash and force-push if needed).
• The grant will only be announced once the first milestone has been accepted (see the announcement guidelines).
• I prefer the discussion of this application to take place in a private Element/Matrix channel. My username is: @_______:matrix.org (change the homeserver if you use a different one)

[github-actions]

CLA Assistant Lite bot All contributors have signed the CLA ✍️ ✅

[adotlex]

I have read and hereby sign the Contributor License Agreement.

[keeganquigley]

Hi @adotlex thanks for the application and sorry for the delay, we were a bit behind due to the holidays but catching up now. Here are a couple of initial questions:

• Could you provide more technical details on how the compose pallet will allow developers to define and modify these primitives? For example, which specific operations will be supported?
• how will you ensure that modifications to Interprmitives don't introduce security vulnerabilities or conflicts?
• what benchmarks are you targeting for key operations like creating, modifying, and querying Interprimitives, as well as for message passing?
• what level of abstraction will the SDKs provide?
• Will you provide integration tests as well, or just unit tests?

[adotlex]

Hey @keeganquigley thanks for the great questions and I apologise for the time taken to answer.

1. Still figuring out how to make this as efficient as possible, but the current model is function that defines a modifier node, and attributes defined by this modifier node. Let’s imagine we want to build the backend for a for a isometric tile based game; we can create a new modifier node with the Compose pallet “modifier; land” and add a couple different attributes, such as “attribute; Ice” and “attribute; Volcanic”. Then, we can use the metagraph pallet to make a new node, using the “modifier; land” (or an ID referring to this modifier), and add the attribute “Ice”. Now we have a game tile, with the “Ice” attribute from the “land” modifier.

2. This is a really great question. Building from the previous answer, it’s important to structure Compose with Modifiers and their Attributes so that you don’t have unexpected attributes. If the only modifier is “land”, and the land modifier only has “Ice” and “Volcanic” attributes listed, we can use it confident that it can only contain these attributes. You could use a combination of modifiers to create the building blocks that you want to use. These attributes / modifiers should be looked at as a means to build backends and will have no ability to interact with the core cryptoeconomic blockchain that is being used to publish them.

3. As the network will provide only essential interactions, and execution can be achieved on an EVM chain, native throughput should be fairly high. I expect the majority of ‘transactions’ will be message passing. If necessary, we can utilise multiple cores to ensure high performance. It’s hard to say specifically what benchmarks to target at this stage. I’d like to see some big data from testnet emerge first.

4. As little as possible. The SDKs are focused on providing a web friendly interface targeting extrinsics in languages that have been widely adopted.

5. Edges will be able to use nodes and compose will be able to modify both edges and nodes; in that sense the unit tests will also act as integration tests. The final chain delivered in milestone 3 will have comprehensive testing of all components in tandem with each other.

Thank you for your great questions and if any more clarification is needed let me know!

[PieWol]

Sorry, for the long delay in reviewing. What is it that I can do with this tech that I can't currently do on Polkadot. What exactly is the difference between what you are calling "Multichain dApp" and "Interchain dApp"? Why and where does the "neural network" aspect play a role. Please explain it to me without using any terms that are not standard tech vocabulary.

Thanks!

[PieWol]

Hey @adotlex ,
Sadly, so far this PR could not gather enough approval from the grants committee. For my part, it's due to the fact that I don't seem to fully understand the benefits of this project, especially the technical details that you are trying to describe. You are highlighting the multichain and message passing aspect of your project, but I don't see where the Polkadot ecosystem is not yet capable of these things. Polkadot is build with a multichain vision and XCMP is in place.

Since you haven't gotten back to me until now and no other approval could be found in the committee, I'm going to close the PR. Feel free to reach out again in case of any questions or a desire to clear up any misunderstandings. All the best for any future projects of yours!