FEP-67ff: FEDERATION.md

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.

3 Likes

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.

2 Likes

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.

1 Like

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.

:+1:

What I mean to say is that I’m in agreement, but Discourse doesn’t let me post just :+1:.

1 Like

@arcanicanis started a new topic to discuss machine-readable implementation reports