Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
So far it was not possible to reasonably render a server's rules in client apps due to the unregulated nature of the "custom extended information" field, with no guarantee that it contains any rules, or where they are, or how they are formatted, not to mention all of the extra HTML that it is possible to have there (YouTube embeds, donation banners, and so on).
It is also my belief that the long and detailed codes of conduct that are common on the fediverse are often not read during sign-up or any other time (until some dispute appears).
With a specialized server rules system that essentially amounts to a flat bullet point list (where each item is limited to plain text and 300 characters), it is much easier for new users to read and understand and for client apps to display.
REST API changes
GET /api/v1/instance/rules
to REST APIid
andtext
id
is currently not useful for anything but might become useful later if the rules need to be referencedrules
attribute toGET /api/v1/instance
in REST API