Add spec for filename

[afragen]

Adds a spec for the addition of file to the list of downloadable data. file is used as an associative array key in the update transients.

There is no other way to easily obtain the main plugin file in a plugin.

[rmccue]

This is WordPress-specific so should be in the WP extension. That said, I'm not sure this makes sense for the protocol; if we only need this for updating, why can't we scan the directory for the plugin header?

[afragen]

I'll see what I can do, but isn't updating important? It is an optional piece of data.

[afragen]

Aren't keywords, sections, etc all WP specific data?

[afragen]

I'm looking but I do not see an easy way to get this data consistently.

[afragen]

The issue is there may be installed plugins that might also match a plain slug to another plugin, eg git-updater and git-updater-bitbucket. The safest way to obtain this data is to return it from the MetadataDocument.

[rmccue]

They shouldn't match the DID though, which is what we should be using as the canonical ID. In any case, let's move that conversation to the fair-plugin repo rather than here.

Aren't keywords, sections, etc all WP specific data?

No, they're generic for any type of package in that they're listing data. sections is more WP-specific with the types of sections that are available, which is why those are specced in the WP extension.

[afragen]

I re-wrote the spec to be more generic.

[rmccue]

I'm still not seeing the need for this, either generically or in the WP world.

In WP, including the directory name would have potential conflicting issues, given that the client is responsible for picking the directory's name (per fairpm/fair-plugin#124). This means at best we could include the filename but not directory here, but I'm still not really seeing where that's actually required; why can't the client determine this for whatever it's needed for?

In the generic protocol, I can see that there could be concept of either a "entry file" or a "manifest file", but those seem like an implementation-specific thing really.

For example, let's say that FAIR is used to distribute npm packages. There's no need there for this parameter, as package.json is a fixed filename for the manifest file, and that has its own way of specifying entrypoint files (main). Or, Rust crates which have Cargo.toml for the manifest, and src/main.rs for the entrypoint file. Same in Composer as well: composer.json which has the autoload files.

The closest might be Windows executable packages? It looks like the only real package manager for those (Chocolatey) has a similar fixed manifest file (.nuspec).

Overall though, I'm not seeing why the FAIR protocol needs to know/publish this information, as it seems a client-specific thing.

[toderash]

Overall though, I'm not seeing why the FAIR protocol needs to know/publish this information, as it seems a client-specific thing.

You're right, it doesn't. In the tech call on 2025-07-07 (last week) we identified that there were some requirements that were WordPress-specific that should not be part of the FAIR Protocol, but that since we were implementing with WP, there are some WP-specific requirements wrt how the protocol is implemented. Down the road should other projects adopt it, they may have similar implementation requirements that aren't part of the spec either, but are necessary for a particular ecosystem.

This is that. In order to implement FAIR for the WP ecosystem, we need to make a determination for how to handle something that WordPress needs but that is intentionally not addressed in the protocol. It may be helpful to identify these explicitly as we go, so the spec remains generic while we work out how to apply it to WordPress. This should perhaps become part of a separate implementation doc that is WP-specific.

[afragen]

Doesn't really need to be WP specific but I think we don't need this anymore unless our current solution fails somehow.

[afragen]

This was needed and is currently used in the FAIR plugin.

[afragen]

Implemented in code here, fairpm/fair-beacon#22