Feature request: views are the only content entity without write endpoints — add create / update / delete for list & set views

Have you read a contributing guide?

• I have read CONTRIBUTING.md
• I have searched the existing requests and didn't find any that were similar
• I have considered creating a pull request instead and want to proceed

Clear and concise description of the problem

Every user-content entity in the API supports full CRUD except views:

A view is the object that actually carries the query — its layout, filters and sorts. GET /lists/{list_id}/views returns all of that faithfully, but there is no way to create a view, or to change its filters / sorts / layout afterwards.

Checking the 2025-11-08 spec, neither path exists, and both calls return 404 against a live local instance:

POST   /v1/spaces/{space_id}/lists/{list_id}/views           -> 404
PATCH  /v1/spaces/{space_id}/lists/{list_id}/views/{view_id} -> 404

Why this matters

Views are the only way to persist a query in Anytype. Without write access:

• A view's filters, sorts and grouping can only be configured by hand in the desktop UI.
• Integrations, scripts and agents can read a view definition but never produce one. So "a Kanban grouped by status, filtered to unfinished tasks" is not expressible through the API — even though the API can create every object, property and tag that the view would display.
• The API ends up asymmetric in a way that is hard to work around: you can create the data, but not the presentation of it.

How could it be done

Expose the same shape that GET .../views already returns:

• POST /v1/spaces/{space_id}/lists/{list_id}/views — body {name, layout, filters[], sorts[]}
• PATCH /v1/spaces/{space_id}/lists/{list_id}/views/{view_id} — partial update of those fields
• DELETE /v1/spaces/{space_id}/lists/{list_id}/views/{view_id}

The existing Filter and Sort schemas already describe the payload precisely (property_key, format, condition, value, sort_type), so this does not need a new model.

Small thing while you are in there: the View schema in the spec declares layout as enum: [grid, table], but the live API also returns kanban, gallery, calendar and list.

Real life use case

Agent-driven workflows where the agent maintains the data and a human opens the result in the app. A daily status dashboard built from task objects: the agent can already create the tasks and filter them correctly, but it cannot materialise the view — so the dashboard has to live outside Anytype, next to none of the data. Closing this would let the query be built once and then read natively in the clients.

Start with the 2025-11-08 API spec and the existing GET /v1/spaces/{space_id}/lists/{list_id}/views response, then inspect the Filter, Sort, and View schemas. Add create, partial update, and delete operations for list and set views, including the documented layout values, and verify that the generated API description exposes the requested paths and payloads.