Hi jens. Welcome
And thanks for your contribution.
I have a long list of thoughts on this. I start with the following quote
I think these two statements go hand in hand: We need a language to describe a Fedi specification that has a few properties. I’m using the vision concept from above.
Vision / Concept: A common and inclusive language to work on
Functional requirements
- Provide reusable templates for tasks
Non-functional requirements
- Be inclusive; avoid terms that people find offensive, e.g. allowlist not whitelist.
- Minimal friction to clarify what something means
- Language does not suggest a solution
Second @jfinkhaeuser Would you be willing to take a look from time to time that we do not preclude the use of non HTTP technologies when not necessary?
Third: I personally think I made the first mistake here by talking about “Vision for a Fedi Specification”. I think the use of “a” implies that the result will be a single document. This is kind of not what I expect. I think that the result of “specifying the Fediverse” would be a sequence of documents, some of them being able to be used by arbitrary network technologies, some requiring HTTP.