Hello!
This is a discussion thread for the proposed FEP-67ff: FEDERATION.md.
Please use this thread to discuss the proposed FEP and any potential problems
or improvements that can be addressed.
Summary
FEDERATION.md is a file containing information necessary for achieving interoperability with a federated service. It was originally proposed by Darius Kazemi on SocialHub forum in Documenting federation behavior in a semi-standard way? topic.
Markdown front matter can be used to present data like supported FEPs in a machine-readable format.
Automatic discovery is also possible. NodeInfo 2.1 defines software.repository field. From there, a crawler can discover FEDERATION.md file in a project root.
I think that these suggestions, especially the software.repository usage, would be good to add to the FEP. The machine-readable front matter is nice, but without some standardization of the fields, I don’t know how useful it will be.
I’m also hesitant to recommend frontmatter. NodeInfo’s metadata field is probably a better way to provide machine-readable list of software capabilities. I expect that standardization will be driven by multi-app clients such as Fedilab: Fedilab Apps: "Extra-features (disabled by default) is somewhat …" - Fedilab
Here’s a pre-DRAFT of a FEP describing the machine-readable implementation report (by @helge): fep/fep/aaa3/fep-aaa3.md at e1b2a16707b542ea5ea0cfb390ac1abce89f05bb - helge/fep - Codeberg.org. I think this is a good idea, though I’m not sure about the best place for such report: instance actor or NodeInfo metadata.
Anyway, it would be better to focus on human-readable documentation in FEP-67ff. We have 12 implementations already, so I’m inclined to finalize proposal in its current form.
What I mean to say is that I’m in agreement, but Discourse doesn’t let me post just .
14 implementations.
A standard for machine-readable implementation reports was proposed in FEP-6481, so I think FEP-67ff is now complete.
Requesting final comments on the proposal.