Indexing metadata section in Forc manifest

[deekerno]

As the indexing team works towards a more efficient, user-friendly implementation of the indexer, I'd like to propose allowing for the addition of an optional indexing metadata section to the Forc project manifest.

[Rendered]

[sdankel]

How will we ensure that namespace is unique across projects?

[deekerno]

I thought about this for awhile and I'm still not sure how to address this in the indexing metadata section.

For context, the namespace functionality was actually used as a way to separate indexers that may have the same name. Due to the original indexer's ability to be self-hosted, it was unlikely that namespaces would be collide since teams were generally expected to run their own indexer service deployment. Additionally, the original indexer also contained functionality to use forc wallet to place indexer uploading/stopping/removal behind authenticated routes.

The next iteration of the indexer is intended to be a sort of hosted "public good" service. Thus, the indexer team expects users to deploy their indexers to the service, and in order to ensure that database tables are distinct from one another (as they've generally been named after their GraphQL or Sway types), we need to determine a unique prefix for tables associated with the same contract. The prefix should be user-chosen as the developer experience with using a user-generated identifier is likely to be better than something generated that has no meaning to them. I did think about using a contract ID, but that will change if the content of the contract changes.

[sdankel]

Maybe the indexer website should provide the user with a unique key, which can be used as a prefix?

Are users paying for the indexing service? If so, it should be easy to have a key (or even user-chosen unique namespace) linked to their billing account.

[deekerno]

That's probably a good idea; users could request one using forc wallet and the service could handle generating a unique key in an idempotent manner.

[deekerno]

@sdankel I addressed your feedback through a combination of changes to the document and replies to your comments.

[kayagokalp]

Left 2 nits, my last question before merging this is what is our approach on workspace level metadata? Should that be allowed or left to a future rfc? cc @FuelLabs/tooling

[JoshuaBatty]

Left 2 nits, my last question before merging this is what is our approach on workspace level metadata? Should that be allowed or left to a future rfc? cc @FuelLabs/tooling

I think we should also allow metadata in the top level workspace Forc.toml. I'm looking at a number of large developed workspaces from other teams and think they might feel limited without it.

[kayagokalp]

Left 2 nits, my last question before merging this is what is our approach on workspace level metadata? Should that be allowed or left to a future rfc? cc @FuelLabs/tooling

I think we should also allow metadata in the top level workspace Forc.toml. I'm looking at a number of large developed workspaces from other teams and think they might feel limited without it.

That make sense to me, only thing remaining is that deciding on what should be the policy of conflicting metadata declarations one coming from workspace, and one coming from member package. I think our aim (as forc) should be being totally transparent to this field as this has nothing to do with forc but external tools. So we whould not check any conflicts etc. This is the behaviour of cargo with similar reasonings i believe quoting the linked doc:

There is a similar set of tables at the package level at package.metadata. While cargo does not specify a format for the content of either of these tables, it is suggested that external tools may wish to use them in a consistent fashion, such as referring to the data in workspace.metadata if data is missing from package.metadata, if that makes sense for the tool in question.

Another option would be disallowing package level metadata if there is one in workspace level. But it might hurt the expressivity and also does not really make sense for forc to enforce this as it does not deal with metadata info at all.

After we decide on this, we should the decision in the RFC and then we can merge it maybe?

[kayagokalp]

I guess this should be moved to https://github.com/FuelLabs/sway-rfcs

[zees-dev]

Have added the metadata section in the Forc.toml as part of this PR: FuelLabs/sway#6728
With examples here and here.

metadata is supported at the project level ([project.metadata]) and at the workspace level ([workspace.metadata]).
Funcationality-wise it's very similar to cargo's implementation of the metadata table.
I.e. as long as the section is a valid/parseable toml; any attribute(s) are accepted.
It is upto the 3rd party (external tooling) to make use of this section.

More details can be found here.