While #Fedify's #Vocabulary API provides comprehensive support for #ActivityPub and major vendor extensions, its code-generation approach makes runtime extensions challenging. However, the project welcomes contributions to expand the supported types and properties.

Fedify accepts vocabulary contributions when they meet any of these criteria:

• Documented in FEP (Fediverse Enhancement Proposals) or equivalent specification
• Already adopted by widely-used #fediverse implementations like Mastodon or Pleroma
• Thoroughly discussed within the Fedify community (Discord, Matrix, GitHub Discussions)

Contributing new vocabulary is straightforward. The vocabulary definitions live in YAML files within the fedify/vocab/ directory. To add a new type, create a new .yaml file. To add properties to existing types, extend the properties section in the relevant .yaml file.

This approach ensures Fedify's vocabulary coverage grows with the fediverse ecosystem while maintaining type safety and comprehensive documentation. If you're working with custom ActivityPub extensions, consider contributing them upstream to benefit the entire community.

For detailed guidance on the contribution process, see the Extending the vocabulary section in Fedify's docs.

#fedidev

@fedify this sounds reasonable for extending support for 3rd party vocabulary. How do you envision developing 1st party vocab for servers implemented using fedify?

For example, I'm developing a service that needs to introduce some new object types. But I'm nowhere near ready to codify them in a FEP or share them with broader fedify userbase. What would be the best way to continue using fedify in this prototyping phase? (Perhaps building with a fedify fork and merge uspream once server is done?)