Mr. DrogDrog

This is not what we want. We want to validate that the response matches the typescript types that are defined in the frontend. Because then we can make sure that...

E.g. you change a key in the frontend config response in the backend (like changing specialUrls to awesomeUrls). Then the frontend CI would fail because we expect "specialUrls" but it's...

But because frontend and backend are built and developed separately this wouldn't change anything. There is still the manual interaction "generate new validators/types from the API spec". This means that...

> The frontend could also just use the `.dto.ts` files from the backend and use them to validate JSON with [class-validator](https://github.com/typestack/class-validator). That would skip the OpenAPI step and allow code-reuse...

Okay for clarification: We're both talking about runtime validation, but David proposed to copy the types from the backend so we don't have to create them again. Well. That's also...

Your proposed alternative with the grid is already included in HedgeDoc 2. The buttons for adding/removing could also be added.

These names are examples. We had enough discussion where someone was confused because the names weren't unique. That's why I want to define clear names, that everybody understands and document...

I don't think that a dedicated page would be useful. That are unnecessary page reloads for UI settings.

Hi Mark, Short Answer: No Long Answer: Interesting idea, but saving files is not everything. For a full hedgedoc experience we need the realtime component and permission management. Also synchronising...

> Is the current codebase flexible enough to even allow a distributed version to exist? Most likely it isn't. Our primary goal right now is to make the frontend work...