"
+----
diff --git a/modules/developer/pages/ocis/identity-provider/oidc.adoc b/modules/developer/pages/ocis/identity-provider/oidc.adoc
new file mode 100644
index 00000000..44782dc4
--- /dev/null
+++ b/modules/developer/pages/ocis/identity-provider/oidc.adoc
@@ -0,0 +1,101 @@
+= OIDC
+:toc: right
+:toclevels: 3
+
+Infinite Scale has implemented OpenID Connect (OIDC) for authentication.
+OIDC defines a discovery mechanism, called OpenID Connect Discovery,
+where an OpenID server publishes its metadata at a well-known URL, typically:
+
+`https://ocis.test/.well-known/openid-configuration`
+
+This URL returns a JSON listing of the OpenID/OAuth endpoints, supported scopes and claims, public keys used to sign the tokens, and other details.
+The clients can use this information to construct a request to the OpenID server.
+The field names and values are defined in the link:https://openid.net/specs/openid-connect-discovery-1_0.html[OpenID Connect Discovery Specification].
+Here is an example of data returned:
+[source,json]
+----
+{
+ "issuer": "https://ocis.test",
+ "authorization_endpoint": "https://ocis.test/signin/v1/identifier/_/authorize",
+ "token_endpoint": "https://ocis.test/konnect/v1/token",
+ "userinfo_endpoint": "https://ocis.test/konnect/v1/userinfo",
+ "end_session_endpoint": "https://ocis.test/signin/v1/identifier/_/endsession",
+ "check_session_iframe": "https://ocis.test/konnect/v1/session/check-session.html",
+ "jwks_uri": "https://ocis.test/konnect/v1/jwks.json",
+ "scopes_supported": [
+ "openid",
+ "offline_access",
+ "profile",
+ "email",
+ "LibgreGraph.UUID",
+ "LibreGraph.RawSub"
+ ],
+ "response_types_supported": [
+ "id_token token",
+ "id_token",
+ "code id_token",
+ "code id_token token"
+ ],
+ "subject_types_supported": [
+ "public"
+ ],
+ "id_token_signing_alg_values_supported": [
+ "RS256",
+ "RS384",
+ "RS512",
+ "PS256",
+ "PS384",
+ "PS512"
+ ],
+ "userinfo_signing_alg_values_supported": [
+ "RS256",
+ "RS384",
+ "RS512",
+ "PS256",
+ "PS384",
+ "PS512"
+ ],
+ "request_object_signing_alg_values_supported": [
+ "ES256",
+ "ES384",
+ "ES512",
+ "RS256",
+ "RS384",
+ "RS512",
+ "PS256",
+ "PS384",
+ "PS512",
+ "none",
+ "EdDSA"
+ ],
+ "token_endpoint_auth_methods_supported": [
+ "client_secret_basic",
+ "none"
+ ],
+ "token_endpoint_auth_signing_alg_values_supported": [
+ "RS256",
+ "RS384",
+ "RS512",
+ "PS256",
+ "PS384",
+ "PS512"
+ ],
+ "claims_parameter_supported": true,
+ "claims_supported": [
+ "iss",
+ "sub",
+ "aud",
+ "exp",
+ "iat",
+ "name",
+ "family_name",
+ "given_name",
+ "email",
+ "email_verified"
+ ],
+ "request_parameter_supported": true,
+ "request_uri_parameter_supported": false
+}
+----
+
+Refer to the link:https://owncloud.dev/apis/http/authorization[Authorization] section for example usages and details.
diff --git a/modules/developer/pages/ocis/index.adoc b/modules/developer/pages/ocis/index.adoc
new file mode 100644
index 00000000..5b5c7a95
--- /dev/null
+++ b/modules/developer/pages/ocis/index.adoc
@@ -0,0 +1,61 @@
+= oCIS - ownCloud Infinite Scale
+:toc: right
+:toclevels: 3
+
+image::media/is.png[,width=70%]
+
+== ownCloud Infinite Scale
+Welcome to oCIS, the modern file-sync and share platform, which is based on our knowledge and experience with the PHP based link:https://owncloud.com/#server[ownCloud server].
+
+=== The idea of federated storage
+To create a truly federated storage architecture oCIS breaks down the old ownCloud 10 user specific namespace, which is assembled on the server side, and makes the individual parts accessible to clients as storage spaces and storage space registries.
+
+The diagram below shows the core concepts that are the foundation for the new architecture:
+- End user devices can fetch the list of _storage spaces_ a user has access to, by querying one or multiple _storage space registries_. The list contains a unique endpoint for every _storage space_.
+- xref:./storage/terminology#storage-space-registries.adoc[_Storage space registries_] manage the list of storage spaces a user has access to. They may subscribe to _storage spaces_ in order to receive notifications about changes on behalf of an end users mobile or desktop client.
+- xref:./storage/terminology#storage-spaces.adoc[_Storage spaces_] represent a collection of files and folders. A users personal files are contained in a _storage space_, a group or project drive is a _storage space_, and even incoming shares are treated and implemented as _storage spaces_. Each with properties like owners, permissions, quota and type.
+- xref:./storage/terminology#storage-providers.adoc[_Storage providers_] can hold multiple _storage spaces_. At an oCIS instance, there might be a dedicated _storage provider_ responsible for users personal storage spaces. There might be multiple, either to shard the load, provide different levels of redundancy or support custom workflows. Or there might be just one, hosting all types of _storage spaces_.
+
+image::ocis/idea.drawio.svg[]
+
+As an example, Einstein might want to share something with Marie, who has an account at a different identity provider and uses a different storage space registry. The process makes use of link:https://openid.net/specs/openid-connect-core-1_0.html[OpenID Connect (OIDC)] for authentication and would look something like this:
+
+To share something with Marie, Einstein would open `https://cloud.zurich.test`. His browser loads oCIS web and presents a login form that uses the link:https://openid.net/specs/openid-connect-discovery-1_0.html#EmailSyntax[OpenID Connect Discovery] to look up the OIDC issuer. For `einstein@zurich.test` he will end up at `https://idp.zurich.test`, authenticate and get redirected back to `https://cloud.zurich.test`. Now, oCIS web will use a similar discovery to look up the _storage space registry_ for the account, based on the email (or username). He will discover that `https://cloud.zurich.test` is also his _storage registry_ that the web UI will use to load the list of _storage spaces_ that are available to him.
+
+After locating a folder that he wants to share with Marie he enters her email `marie@paris.test` in the sharing dialog to grant her the editor role. This, in effect, creates a new _storage space_ that is registered with the _storage space registry_ at `https://cloud.zurich.test`.
+
+Einstein copies the URL in the browser (or an email with the same URL is sent automatically, or the storage registries use a back-channel mechanism). It contains the most specific `storage space id` and a path relative to it: `https://cloud.zurich.test/#/spaces/716199a6-00c0-4fec-93d2-7e00150b1c84/a/rel/path`.
+
+When Marie enters that URL she will be presented with a login form on the `https://cloud.zurich.test` instance, because the share was created on that domain. If `https://cloud.zurich.test` trusts her OpenID Connect identity provider `https://idp.paris.test` she can log in. This time, the _storage space registry_ discovery will come up with `https://cloud.paris.test` though. Since that registry is different than the registry tied to `https://cloud.zurich.test` oCIS web can look up the _storage space_ `716199a6-00c0-4fec-93d2-7e00150b1c84` and register the WebDAV URL `https://cloud.zurich.test/dav/spaces/716199a6-00c0-4fec-93d2-7e00150b1c84/a/rel/path` in Marie's _storage space registry_ at `https://cloud.paris.test`. When she accepts that share her clients will be able to sync the new _storage space_ at `https://cloud.zurich.test`.
+
+=== oCIS microservice runtime
+
+The oCIS runtime allows us to dynamically manage services running in a single process. We use link:https://github.com/thejerf/suture[suture] to create a supervisor tree that starts each service in a dedicated goroutine. By default oCIS will start all built-in oCIS services in a single process. Individual services can be moved to other nodes to scale-out and meet specific performance requirements. A link:https://github.com/asim/go-micro/blob/master/registry/registry.go[go-micro] based registry allows services in multiple nodes to form a distributed microservice architecture.
+
+=== oCIS Services
+
+Every oCIS service uses link:https://github.com/owncloud/ocis/tree/master/ocis-pkg[ocis-pkg], which implements the link:https://go-micro.dev/[go-micro] interfaces for link:https://github.com/asim/go-micro/blob/v3.5.0/server/server.go#L17-L37[servers] to register and link:https://github.com/asim/go-micro/blob/v3.5.0/client/client.go#L11-L23[clients] to lookup nodes with a service link:https://github.com/asim/go-micro/blob/v3.5.0/registry/registry.go[registry].
+We are following the link:https://12factor.net/[12 Factor] methodology with oCIS. The uniformity of services also allows us to use the same command, logging and configuration mechanism. Configurations are forwarded from the
+oCIS runtime to the individual extensions.
+
+
+=== go-micro
+
+While the link:https://go-micro.dev/[go-micro] framework provides abstractions as well as implementations for the different components in a microservice architecture, it uses a more developer focused runtime philosophy: It is used to download services from a repo, compile them on the fly and start them as individual processes. For oCIS we decided to use a more admin friendly runtime: You can download a single binary and start the contained oCIS services with a single `bin/ocis server`. This also makes packaging easier.
+
+We use link:https://github.com/owncloud/ocis/tree/master/ocis-pkg[ocis-pkg] to configure the default implementations for the go-micro link:https://github.com/asim/go-micro/tree/v3.5.0/plugins/server/grpc[grpc server], link:https://github.com/asim/go-micro/tree/v3.5.0/plugins/client/grpc[client] and link:https://github.com/asim/go-micro/blob/v3.5.0/registry/mdns_registry.go[mdns registry], swapping them out as needed, e.g. to use the link:https://github.com/asim/go-micro/tree/v3.5.0/plugins/registry/kubernetes[kubernetes registry plugin].
+
+=== REVA
+A lot of embedded services in oCIS are built upon the link:https://reva.link/[REVA] runtime. We decided to bundle some of the link:https://github.com/cs3org/cs3apis[CS3 services] to logically group them. A link:https://github.com/owncloud/ocis/blob/v1.2.0/storage/pkg/command/storagehome.go#L93-L108[home storage provider], which is dealing with link:https://cs3org.github.io/cs3apis/#cs3.storage.provider.v1beta1.ProviderAPI[metadata], and the corresponding link:https://github.com/owncloud/ocis/blob/v1.2.0/storage/pkg/command/storagehome.go#L109-L123[data provider], which is dealing with link:https://cs3org.github.io/cs3apis/#cs3.gateway.v1beta1.FileUploadProtocol[up and download], are one example. The link:https://github.com/owncloud/ocis/blob/v1.2.0/storage/pkg/command/frontend.go[frontend] with the link:https://github.com/owncloud/ocis/blob/v1.2.0/storage/pkg/command/frontend.go#L132-L138[oc flavoured webdav], link:https://github.com/owncloud/ocis/blob/v1.2.0/storage/pkg/command/frontend.go#L139-L148[ocs handlers] and a link:https://github.com/owncloud/ocis/blob/v1.2.0/storage/pkg/command/frontend.go#L126-L131[data-gateway] are another.
+
+=== Protocol driven development
+Interacting with oCIS involves a multitude af APIs. The server and all clients rely on link:https://openid.net/connect/[OpenID Connect] for authentication. The link:https://owncloud.dev/services/idp/[embedded LibreGraph Connect] can be replaced with any other OpenID Connect Identity Provider. Clients use the link:http://webdav.org/[WebDAV] based link:https://github.com/cernbox/smashbox/blob/master/protocol/protocol.md[oc sync protocol] to manage files and folders, link:https://doc.owncloud.com/server/developer_manual/core/apis/ocs-share-api.html[ocs to manage shares] and link:https://tus.io/protocols/resumable-upload.html[TUS] to upload files in a resumable way. On the server side link:https://reva.link/[REVA] is the reference implementation of the link:https://github.com/cs3org/cs3apis[CS3 apis] which is defined using link:https://developers.google.com/protocol-buffers/[protobuf]. By embedding link:https://github.com/libregraph/idm[libregraph/idm], oCIS provides a link:https://tools.ietf.org/html/rfc2849[LDAP] interface to make accounts, including guests available to firewalls and other systems. In the future, we are looking into link:https://docs.microsoft.com/en-us/graph/api/overview?view=graph-rest-1.0[the Microsoft Graph API], which is based on link:http://docs.oasis-open.org/odata/odata/v4.0/odata-v4.0-part1-protocol.html[odata], as a well-defined REST/JSON dialect for the existing endpoints.
+
+=== Acceptance test suite
+We run a huge link:https://github.com/owncloud/core/tree/master/tests[test suite], which originated in ownCloud 10 and continues to grow. A detailed description can be found in the developer docs for xref:development/testing.adoc[testing].
+
+=== Architecture Overview
+
+Running `bin/ocis server` will start the following services, all of which can be scaled and deployed on a single node or in a cloud native environment, as needed.
+
+image::ocis/architecture-overview.drawio.svg[]
diff --git a/modules/developer/pages/ocis/license.adoc b/modules/developer/pages/ocis/license.adoc
new file mode 100644
index 00000000..e7057062
--- /dev/null
+++ b/modules/developer/pages/ocis/license.adoc
@@ -0,0 +1,9 @@
+= License
+:toc: right
+:toclevels: 3
+
+The source code of the project is licensed under the link:https://github.com/owncloud/ocis/blob/master/LICENSE[Apache 2.0] license. For the license of the used libraries you have to check the respective sources.
+
+Stable, supported binary builds of ownCloud Infinite Scale that will be distributed by ownCloud GmbH are covered by a non OSS Freemium License link:https://owncloud.com/license-owncloud-infinite-scale/[EULA]. This protects additional efforts that ownCloud GmbH is putting into these builds.
+
+Since the source code of Infinite Scale is available under free licenses, the free usage can, should and will not be limited in general.
diff --git a/modules/developer/pages/ocis/metrics.adoc b/modules/developer/pages/ocis/metrics.adoc
new file mode 100644
index 00000000..7caef118
--- /dev/null
+++ b/modules/developer/pages/ocis/metrics.adoc
@@ -0,0 +1,103 @@
+= Metrics
+:toc: right
+:toclevels: 3
+
+== Metrics
+
+This service provides some link:https://prometheus.io/[Prometheus] metrics through the debug endpoint, you can optionally secure the metrics endpoint by some random token, which has to be configured either through the flag `--debug-token` or the environment variable `OCIS_DEBUG_TOKEN` mentioned above. By default, the metrics endpoint is bound to `http://0.0.0.0:8001/metrics`.
+
+go_gc_duration_seconds
+: A summary of the GC invocation durations
+
+go_gc_duration_seconds_sum
+: A summary of the GC invocation durations
+
+go_gc_duration_seconds_count
+: A summary of the GC invocation durations
+
+go_goroutines
+: Number of goroutines that currently exist
+
+go_info
+: Information about the Go environment
+
+go_memstats_alloc_bytes
+: Number of bytes allocated and still in use
+
+go_memstats_alloc_bytes_total
+: Total number of bytes allocated, even if freed
+
+go_memstats_buck_hash_sys_bytes
+: Number of bytes used by the profiling bucket hash table
+
+go_memstats_frees_total
+: Total number of frees
+
+go_memstats_gc_cpu_fraction
+: The fraction of this program's available CPU time used by the GC since the program started
+
+go_memstats_gc_sys_bytes
+: Number of bytes used for garbage collection system metadata
+
+go_memstats_heap_alloc_bytes
+: Number of heap bytes allocated and still in use
+
+go_memstats_heap_idle_bytes
+: Number of heap bytes waiting to be used
+
+go_memstats_heap_inuse_bytes
+: Number of heap bytes that are in use
+
+go_memstats_heap_objects
+: Number of allocated objects
+
+go_memstats_heap_released_bytes
+: Number of heap bytes released to OS
+
+go_memstats_heap_sys_bytes
+: Number of heap bytes obtained from system
+
+go_memstats_last_gc_time_seconds
+: Number of seconds since 1970 of last garbage collection
+
+go_memstats_lookups_total
+: Total number of pointer lookups
+
+go_memstats_mallocs_total
+: Total number of mallocs
+
+go_memstats_mcache_inuse_bytes
+: Number of bytes in use by mcache structures
+
+go_memstats_mcache_sys_bytes
+: Number of bytes used for mcache structures obtained from system
+
+go_memstats_mspan_inuse_bytes
+: Number of bytes in use by mspan structures
+
+go_memstats_mspan_sys_bytes
+: Number of bytes used for mspan structures obtained from system
+
+go_memstats_next_gc_bytes
+: Number of heap bytes when next garbage collection will take place
+
+go_memstats_other_sys_bytes
+: Number of bytes used for other system allocations
+
+go_memstats_stack_inuse_bytes
+: Number of bytes in use by the stack allocator
+
+go_memstats_stack_sys_bytes
+: Number of bytes obtained from system for stack allocator
+
+go_memstats_sys_bytes
+: Number of bytes obtained from system
+
+go_threads
+: Number of OS threads created
+
+promhttp_metric_handler_requests_in_flight
+: Current number of scrapes being served
+
+promhttp_metric_handler_requests_total
+: Total number of scrapes by HTTP status code
diff --git a/modules/developer/pages/ocis/migration.adoc b/modules/developer/pages/ocis/migration.adoc
new file mode 100644
index 00000000..d6e36d14
--- /dev/null
+++ b/modules/developer/pages/ocis/migration.adoc
@@ -0,0 +1,773 @@
+= Migration
+:toc: right
+:toclevels: 3
+
+The migration happens in subsequent stages while the service is online. First all users need to migrate to the new architecture, then the global namespace needs to be introduced. Finally, the data on disk can be migrated user by user by switching the storage driver.
+
+
+
+[WARNING]
+====
+@jfd: It might be easier to introduce the spaces api in oc10 and then migrate to oCIS. We cannot migrate both at the same time, the architecture to oCIS (which will change fileids) and introduce a global namespace (which requires stable fileids to let clients handle moves without redownloading). Either we implement arbitrary mounting of shares in oCIS / reva or we make clients and oc10 spaces aware.
+====
+
+
+
+
+== Migration Stages
+
+=== Stage 0: pre migration
+Is the pre-migration stage when having a functional ownCloud 10 instance.
+
+
+
+==== FAQ
+_Feel free to add your question as a PR to this document using the link at the top of this page!_
+
+
+
+
+
+=== Stage 1: introduce ownCloud Web
+Install and introduce link:https://github.com/owncloud/web/[ownCloud Web] and let users test it voluntarily to gain early feedback on the new UI.
+
+==== Steps
+Deploy web and enable switching to and from it.
+For more details see: link:https://owncloud.dev/clients/web/deployments/oc10-app/[ownCloud 10 with ownCloud Web]
+
+
+
+_TODO allow limiting the web ui switch to an 'early adopters' group_
+
+
+
+==== Validation
+Ensure switching back and forth between the classic ownCloud 10 web UI and ownCloud web works as at our https://demo.owncloud.com.
+
+==== Rollback
+Should there be problems with ownCloud web at this point it can simply be removed from the menu and be undeployed.
+
+==== Notes
+
+The ownCloud 10 demo instance uses OAuth to obtain a token for ownCloud web and currently always requires explicit consent. In oCIS the token is provided by the OpenID Connect Identity Provider, which may skip the consent step for trusted clients for a more seamless login experience. You may want to introduce OpenID Connect before enabling the new web UI.
+
+
+
+_TODO make oauth2 in oc10 trust the new web ui, based on `redirect_uri` and CSRF so no explicit consent is needed?_
+
+==== FAQ
+_Feel free to add your question as a PR to this document using the link at the top of this page!_
+
+
+
+
+
+=== Stage 2: introduce OpenID Connect
+
+Basic auth requires us to properly store and manage user credentials. Something we would rather like to delegate to a tool specifically built for that task.
+While SAML and Shibboleth are protocols that solve that problem, they are limited to web clients. Desktop and mobile clients were an afterthought and keep running into timeouts. For these reasons, we decided to move to link:https://owncloud.com/news/openid-connect-oidc-app/[OpenID Connect as our primary authentication protocol].
+
+
+
+_TODO @butonic add ADR for OpenID Connect and flesh out pros and cons of the above_
+
+
+
+==== User impact
+
+When introducing OpenID Connect, the clients will detect the new authentication scheme when their current way of authenticating returns an error. Users will then have to
+reauthorize at the OpenID Connect IdP, which again, may be configured to skip the consent step for trusted clients.
+
+==== Steps
+1. There are multiple products that can be used as an OpenID Connect IdP. We test with link:https://github.com/libregraph/lico[LibreGraph Connect], which is also link:https://github.com/owncloud/web/[embedded in oCIS]. Other alternatives include link:https://www.keycloak.org/[Keycloak] or link:https://www.pingidentity.com/[Ping]. Please refer to the corresponding setup instructions for the product you intend to use.
+
+
+
+_TODO @butonic flesh out oCIS IDP documentation_
+
+
+
+2. Add link:https://doc.owncloud.com/server/admin_manual/configuration/user/oidc/[Openid Connect (OIDC)] support to ownCloud 10.
+
+==== Validation
+When OpenID Connect support is enabled verify that all clients can login:
+- web classic
+- ownCloud web
+- desktop
+- android
+- iOS
+
+==== Rollback
+Should there be problems with OpenID Connect at this point you can disable the app. Users will have to reauthenticate in this case.
+
+==== Notes
+
+Legacy clients relying on Basic auth or app passwords need to be migrated to OpenId Connect to work with oCIS. For a transition period Basic auth in oCIS can be enabled with `PROXY_ENABLE_BASIC_AUTH=true`, but we strongly recommend adopting OpenID Connect for other tools as well.
+
+While OpenID Connect providers will send an `iss` and `sub` claim that relying parties (services like oCIS or ownCloud 10) can use to identify users we recommend introducing a dedicated, globally unique, persistent, non-reassignable user identifier like a UUID for every user. This `ownclouduuid` should be sent as an additional claim to save additional lookups on the server side. It will become the user id in oCIS, e.g. when searching for recipients the `ownclouduuid` will be used to persist permissions with the share manager. It has a different purpose than the ownCloud 10 username, which is used to login. Using UUIDs we can not only mitigate username collisions when merging multiple instances but also allow renaming usernames after the migration to oCIS has been completed.
+
+
+
+==== FAQ
+_Feel free to add your question as a PR to this document using the link at the top of this page!_
+
+
+
+
+
+=== Stage 3: introduce oCIS internally
+
+Before letting oCIS handle end user requests we will first make it available in the internal network. By subsequently adding services we can add functionality and verify the services work as intended.
+
+Start oCIS backend and make read only tests on existing data using the `owncloudsql` storage driver which will read (and write)
+- blobs from the same datadirectory layout as in ownCloud 10
+- metadata from the ownCloud 10 database:
+The oCIS share manager will read share information from the ownCloud database using an `owncloud` driver as well.
+
+
+
+_TODO @butonic add guide on how to configure `owncloudsql`_
+
+_TODO we need a share manager that can read from the ownCloud 10 database as well as from whatever new backend will be used for a pure oCIS setup. Currently, that would be the json file. Or that is migrated after all users have switched to oCIS. -- jfd_
+
+
+
+==== User impact
+None, only administrators will be able to explore oCIS during this stage.
+
+==== Steps and verifications
+
+We are going to run and explore a series of services that will together handle the same requests as ownCloud 10. For initial exploration the oCIS binary is recommended. The services can later be deployed using a single oCIS runtime or in multiple containers.
+
+
+===== Storage provider for file metadata
+1. Deploy OCIS storage provider with owncloudsql driver.
+2. Set `read_only: true` in the storage provider config. _TODO @butonic add read only flag to storage drivers_
+3. Use cli tool to list files using the CS3 api
+
+===== File ID alternatives
+Multiple ownCloud instances can be merged into one oCIS instance. To prevent the numeric ids from colliding, the file ids will be prefixed with a new storage space id which is used by oCIS to route requests to the correct storage provider. See Stage 8 below.
+
+
+
+[WARNING]
+====
+_Alternative 1_
+Add a routable prefix to fileids in oc10, and replicate the prefix in oCIS.
+=== Stage-3.1
+Let oc10 render file ids with prefixes: `$!`. This will allow clients to handle moved files.
+
+=== Stage-3.2
+Roll out new clients that understand the spaces API and know how to convert local sync pairs for legacy oc10 `/webdav` or `/dav/files/` home folders into multiple sync pairs.
+One pair for `/webdav/home` or `/dav/files//home` and another pair for every accepted share. The shares will be accessible at `/webdav/shares/` when the server side enables the spaces API.
+Files can be identified using `$!` and moved to the correct sync pair.
+
+=== Stage-3.3
+Enable spaces API in oc10:
+- New clients will get a response from the spaces API and can set up new sync pairs.
+- Legacy clients will still poll `/webdav` or `/dav/files/` where they will see new subfolders instead of the users home. They will move down the users files into `/home` and shares into `/shares`. Custom sync pairs will no longer be available, causing the legacy client to leave local files in place. They can be picked up manually when installing a new client.
+
+====
+
+
+[WARNING]
+====
+_Alternative 2_
+An additional `uuid` property used only to detect moves. A lookup by uuid is not necessary for this. The `/dav/meta` endpoint would still take the fileid. Clients would use the `uuid` to detect moves and set up new sync pairs when migrating to a global namespace.
+=== Stage-3.1
+Generate a `uuid` for every file as a file property. Clients can submit a `uuid` when creating files. The server will create a `uuid` if the client did not provide one.
+
+=== Stage-3.2
+Roll out new clients that understand the spaces API and know how to convert local sync pairs for legacy oc10 `/webdav` or `/dav/files/` home folders into multiple sync pairs.
+One pair for `/webdav/home` or `/dav/files//home` and another pair for every accepted share. The shares will be accessible at `/webdav/shares/` when the server side enables the spaces API. Files can be identified using the `uuid` and moved to the correct sync pair.
+
+=== Stage-4.1
+When reading the files from oCIS return the same `uuid`. It can be migrated to an extended attribute or it can be read from oc10. If users change it the client will not be able to detect a move and maybe other weird stuff happens. _What if the uuid gets lost on the server side due to a partial restore?_
+
+====
+
+
+
+
+
+
+===== graph API endpoint
+1. Deploy graph api to list spaces
+2. Use curl to list spaces using graph drives endpoint
+
+===== owncloud flavoured WebDAV endpoint
+1. Deploy ocdav
+2. Use curl to send PROPFIND
+
+===== data provider for up and download
+1. Deploy dataprovider
+2. Use curl to up and download files
+3. Use tus to upload files
+
+Deploy ...
+
+===== share manager
+Deploy share manager with ownCloud driver
+
+===== reva gateway
+1. Deploy gateway to authenticate requests? I guess we need that first... Or we need the to mint a token. Might be a good exercise.
+
+===== automated deployment
+Finally, deploy oCIS with a config to set up everything running in a single oCIS runtime or in multiple containers.
+
+==== Rollback
+You can stop the oCIS process at any time.
+
+==== Notes
+
+Multiple ownCloud instances can be merged into one oCIS instance. The file ids will be prefixed with a new storage space id which is used to route requests to the correct storage provider.
+
+
+
+==== FAQ
+_Feel free to add your question as a PR to this document using the link at the top of this page!_
+
+
+
+
+
+=== Stage 4: internal write access with oCIS
+Test writing data with oCIS into the existing ownCloud 10 data directory using the `owncloudsql` storage driver.
+
+==== User impact
+Only administrators will be able to explore oCIS during this stage. End users should not be affected if the testing is limited to test users.
+
+==== Steps
+Set `read_only: false` in the storage provider config.
+
+
+
+_TODO @butonic add read only flag to storage drivers_
+
+
+
+==== Verification
+==== Rollback
+Set `read_only: true` in the storage provider config.
+
+
+
+_TODO @butonic add read only flag to storage drivers_
+
+
+
+==== Notes
+
+With write access it becomes possible to manipulate existing files and shares.
+
+
+
+==== FAQ
+_Feel free to add your question as a PR to this document using the link at the top of this page!_
+
+
+
+
+
+=== Stage-5: introduce user aware proxy
+In the previous stages oCIS was only accessible for administrators with access to the network. To expose only a single service to the internet, oCIS comes with a user aware proxy that can be used to route requests to the existing ownCloud 10 installation or oCIS, based on the authenticated user. The proxy uses OIDC to identify the logged-in user and route them to the configured backend.
+
+==== User impact
+The IP address of the ownCloud host changes. There is no change for the file sync and share functionality when requests are handled by the oCIS codebase as it uses the same database and storage system as owncloud 10.
+
+==== Steps and verifications
+
+===== Deploy oCIS proxy
+1. Deploy the `ocis proxy`
+2. Verify the requests are routed based on the ownCloud 10 routing policy `oc10` by default
+
+===== Test user based routing
+1. Change the routing policy for a user or an early adopters group to `ocis` _TODO @butonic currently, the migration selector will use the `ocis` policy for users that have been added to the accounts service. IMO we need to evaluate a claim from the IdP._
+2. Verify the requests are routed based on the oCIS routing policy `oc10` for 'migrated' users.
+
+At this point you are ready to rock & roll!
+
+===== Let ownCloud domain point to proxy
+1. Update the dns to use the oCIS proxy instead of the ownCloud application servers directly.
+2. Let DNS propagate the change and monitor requests moving from the ownCloud application servers to the oCIS proxy.
+3. Verify the DNS change has propagated sufficiently. All requests should now use the oCIS Proxy.
+
+==== Rollback
+Should there be a problem with the oCIS routes the user can be routed to ownCloud by changing his routing policy. In case of unfixable problems with the proxy the DNS needs to be updated to use the ownCloud 10 application servers directly. This could also be done in a load balancer.
+
+==== Notes
+
+The proxy is stateless, multiple instances can be deployed as needed.
+
+
+
+==== FAQ
+_Feel free to add your question as a PR to this document using the link at the top of this page!_
+
+
+
+
+
+=== Stage-6: parallel deployment
+Running ownCloud 10 and oCIS in parallel is a crucial stage for the migration: it allows users access to group shares regardless of the system that is being used to access the data. A user by user migration with multiple domains would technically break group shares when users vanish because they (and their data) are no longer available in the old system.
+
+Depending on the amount of power users on an instance, the admin may want to allow users to voluntarily migrate to the oCIS backend. A monitoring system can be used to visualize the behavior for the two systems and gain trust in the overall stability and performance.
+
+==== User impact
+Since the underling data is still stored in the same systems, a similar or performance can be expected.
+
+
+See _TODO hmpf outdated didn't we want to run them nightly? ..._
+_TODO @butonic update performance comparisons nightly_
+
+
+
+==== Steps
+There are several options to move users to the oCIS backend:
+- Use a canary app to let users decide themselves
+- Use an early adopters group with an opt-in
+- Force migrate users in batch or one by one at the administrators will
+
+==== Verification
+The same verification steps as for the internal testing stage apply. Just from the outside.
+
+==== Rollback
+Until now, the oCIS configuration mimics ownCloud 10 and uses the old data directory layout and the ownCloud 10 database. Users can seamlessly be switched from ownCloud 10 to oCIS and back again.
+
+
+_TODO @butonic we need a canary app that allows users to decide for themselves which backend to use_
+
+
+
+
+
+==== Notes
+Running the two systems in parallel stage
+Try to keep the duration of this stage short. Until now we only added services and made the system more complex. oCIS aims to reduce the maintenance cost of an ownCloud instance. You will not get there if you keep both systems alive.
+
+
+
+==== FAQ
+_Feel free to add your question as a PR to this document using the link at the top of this page!_
+
+
+
+
+
+=== Stage-7: introduce spaces using ocis
+To encourage users to switch you can promote the workspaces feature that is built into oCIS. The ownCloud 10 storage backend can be used for existing users. New users and group or project spaces can be provided by storage providers that better suit the underlying storage system.
+
+==== Steps
+First, the admin needs to
+- deploy a storage provider with the storage driver that best fits the underlying storage system and requirements.
+- register the storage in the storage registry with a new storage id (we recommend a uuid).
+
+Then a user with the necessary create storage space role can create a storage space and assign Managers.
+
+
+
+_TODO @butonic a user with management permission needs to be presented with a list of storage spaces where he can see the amount of free space and decide on which storage provider the storage space should be created. For now a config option for the default storage provider for a specific type might be good enough._
+
+
+
+==== Verification
+The new storage space should show up in the `/graph/drives` endpoint for the managers and the creator of the space.
+
+==== Notes
+Depending on the requirements and acceptable tradeoffs, a database less deployment using the ocis or s3ng storage driver is possible. There is also a link:https://github.com/cs3org/reva/pull/1209[cephfs driver] on the way, that directly works on the API level instead of POSIX.
+
+=== Stage-8: shut down ownCloud 10
+Disable ownCloud 10 in the proxy, all requests are now handled by oCIS, shut down oc10 web servers and redis (or keep for calendar & contacts only? rip out files from oCIS?)
+
+==== User impact
+All users are already sent to the oCIS backend. Shutting down ownCloud 10 will remove the old web UI, apps and functionality that is not yet present in ownCloud web. For example contacts and calendar.
+
+
+
+_TODO @butonic recommend alternatives_
+
+
+
+==== Steps
+1. Shut down the apache servers that are running the ownCloud 10 PHP code.
+2. DO NOT SHUT DOWN THE DATABASE, YET!
+
+==== Verification
+The ownCloud 10 classic web UI should no longer be reachable.
+
+==== Rollback
+Redeploy ownCloud 10.
+
+==== Notes
+
+The database needs to remain online until the storage layer and share metadata have been migrated as well. One thing at a time.
+
+
+
+==== FAQ
+_Feel free to add your question as a PR to this document using the link at the top of this page!_
+
+
+
+
+
+=== Stage 9: storage migration
+To get rid of the database we will move the metadata from the old ownCloud 10 database into dedicated storage providers. This can happen in a user by user fashion. group drives can properly be migrated to group, project or workspaces in this stage.
+
+==== User impact
+Noticeable performance improvements because we effectively shard the storage logic and persistence layer.
+
+==== Steps
+1. User by user storage migration from `owncloud` or `ownclouds3` driver to `ocis`/`s3ng`/`cephfs`... currently this means copying the metadata from one storage provider to another using the cs3 api.
+2. Change the responsible storage provider for a storage space (e.g. a user home, a group or project space are a workspace) in the storage registry.
+
+
+
+_TODO @butonic implement `ownclouds3` based on `s3ng`_
+_TODO @butonic implement tiered storage provider for seamless migration_
+_TODO @butonic document how to manually do that until the storage registry can discover that on its own._
+
+
+
+==== Verification
+Start with a test user, then move to early adopters and finally migrate all users.
+
+==== Rollback
+To switch the storage provider again the same storage space migration can be performed again: copy metadata and blob data using the CS3 api, then change the responsible storage provider in the storage registry.
+
+==== Notes
+
+Multiple ownCloud instances can be merged into one oCIS instance. The file ids will be prefixed with a new storage space id which is used to route requests to the correct storage provider.
+
+The storage space migration will become a seamless feature in the future that allows administrators to move users to storage systems with different capabilities, to implement premium features, deprovisioning strategies or archiving.
+
+
+
+==== FAQ
+_Feel free to add your question as a PR to this document using the link at the top of this page!_
+
+
+
+
+
+=== Stage-10: share metadata migration
+Migrate share data to _yet to determine_ share manager backend and shut down ownCloud database.
+
+The ownCloud 10 database still holds share information in the `oc_share` and `oc_share_external` tables. They are used to efficiently answer queries about who shared what with whom. In oCIS shares are persisted using a share manager and if desired these grants are also sent to the storage provider so it can set ACLs if possible. Only one system should be responsible for the shares, which in case of treating the storage as the primary source effectively turns the share manager into a cache.
+
+==== User impact
+Depending on chosen the share manager provider some sharing requests should be faster: listing incoming and outgoing shares is no longer bound to the ownCloud 10 database but to whatever technology is used by the share provider:
+ - For non HA scenarios they can be served from memory, backed by a simple json file.
+ - TODO: implement share manager with redis / nats / ... key value store backend: use the micro store interface please ...
+
+==== Steps
+1. Start new share manager
+2. Migrate metadata using the CS3 API (copy from old to new)
+3. Shut down old share manager
+4. Shut down ownCloud 10 database
+
+
+
+_TODO for HA implement share manager with redis / nats / ... key value store backend: use the micro store interface please ..._
+_TODO for batch migration implement share data migration cli with progress that reads all shares via the cs3 api from one provider and writes them into another provider_
+_TODO for seamless migration implement tiered/chained share provider that reads share data from the old provider and writes new shares to the new one_
+_TODO for storage provider as source of truth persist ALL share data in the storage provider. Currently, part is stored in the share manager, part is in the storage provider. We can keep both, but the share manager should directly persist its metadata to the storage system used by the storage provider so metadata is kept in sync_
+
+
+
+==== Verification
+After copying all metadata start a dedicated gateway and change the configuration to use the new share manager. Route a test user, a test group and early adopters to the new gateway. When no problems occur you can start the desired number of share managers and roll out the change to all gateways.
+
+
+
+_TODO let the gateway write updates to multiple share managers ... or rely on the tiered/chained share manager provider to persist to both providers_
+
+
+
+==== Rollback
+To switch the share manager to the database one revert routing users to the new share manager. If you already shut down the old share manager start it again. Use the tiered/chained share manager provider in reverse configuration (new share provider as read only, old as write) and migrate the shares again. You can also restore a database backup if needed.
+
+
+
+=== Stage-11
+Profit! Well, on the one hand you do not need to maintain a clustered database setup and can rely on the storage system. On the other hand you are now in microservice wonderland and will have to relearn how to identify bottlenecks and scale oCIS accordingly. The good thing is that tools like jaeger and prometheus have evolved and will help you understand what is going on. But this is a different topic. See you on the other side!
+
+==== FAQ
+_Feel free to add your question as a PR to this document using the link at the top of this page!_
+
+
+
+
+
+== Architectural differences
+
+The fundamental difference between ownCloud 10 and oCIS is that the file metadata is moved from the database in the `oc_filecache` table (which is misnamed, as it actually is an index) to the storage provider who can place metadata as close to the underlying storage system as possible. In effect, the file metadata is sharded over multiple specialized services.
+
+
+== Data that will be migrated
+
+Currently, oCIS focuses on file sync and share use cases.
+
+=== Blob data
+
+In ownCloud 10 the files are laid out on disk in the _data directory_ using the following layout:
+----
+data
+├── einstein
+│ ├── cache
+│ ├── files
+│ │ ├── Photos
+│ │ │ └── Portugal.jpg
+│ │ ├── Projects
+│ │ │ └── Notes.md
+│ │ └── ownCloud Manual.pdf
+│ ├── files_external
+│ ├── files_trashbin
+│ │ ├── files
+│ │ │ ├── Documents.d1564687985
+│ │ │ ├── TODO.txt.d1565721976
+│ │ │ └── welcome.txt.d1564775872
+│ │ └── versions
+│ │ │ ├── TODO.txt.v1564605543.d1565721976
+│ │ │ └── TODO.txt.v1564775936.d1565721976
+│ ├── files_versions
+│ │ ├── Projects
+│ │ │ ├── Notes.md.v1496912691
+│ │ │ └── Notes.md.v1540305560
+│ │ └── ownCloud Manual.pdf.v1396628249
+│ ├── thumbnails
+│ │ └── 123
+│ │ │ ├── 2048-1536-max.png
+│ │ │ └── 32-32.png // the file id, e.g. of /Photos/Portugal.jpg
+│ └── uploads
+├── marie
+│ ├── cache
+│ ├── files
+│ ├── files_external
+│ ├── files_trashbin
+│ ├── files_versions
+│ └── thumbnails
+│ …
+├── moss
+…
+----
+
+The _data directory_ may also contain subfolders for ownCloud 10 applications like `avatars`, `gallery`, `files_external` and `cache`.
+
+When an object storage is used as the primary storage all file blobs are stored by their file id and a prefix, e.g.: `urn:oid:`.
+
+The three types of blobs we need to migrate are stored in
+- `files` for file blobs, the current file content,
+- `files_trashbin` for trashed files (and their versions) and
+- `files_versions` for file blobs of older versions.
+
+
+
+=== Filecache table
+
+In both cases the file metadata, including a full replication of the file tree, is stored in the `oc_filecache` table of an ownCloud 10 database. The primary key of a row is the file id. It is used to attach additional metadata like shares, tags, favorites or arbitrary file properties.
+
+The `filecache` table itself has more metadata:
+
+| Field | Type | Null | Key | Default | Extra | Comment | Migration |
+|--------------------|---------------|------|-----|---------|----------------|----------------|----------------|
+| `fileid` | bigint(20) | NO | PRI | NULL | auto_increment | | MUST become the oCIS `opaqueid` of a file reference. `ocis` driver stores it in extended attributes and can use numbers as node ids on disk. for eos see note below table |
+| `storage` | int(11) | NO | MUL | 0 | | _the filecache holds metadata for multiple storages_ | corresponds to an oCIS _storage space_ |
+| `path` | varchar(4000) | YES | | NULL | | _the path relative to the storages root_ | MUST become the `path` relative to the storage root. `files` prefix needs to be trimmed. |
+| `path_hash` | varchar(32) | NO | | | | *mysql once had problems indexing long paths, so we stored a hash for lookup by path. | - |
+| `parent` | bigint(20) | NO | MUL | 0 | | _used to implement the hierarchy and listing children of a folder by id. redundant with `path`_ | - |
+| `name` | varchar(250) | YES | | NULL | | _basename of `path`_ | - |
+| `mimetype` | int(11) | NO | | 0 | | _joined with the `oc_mimetypes` table. only relevant for object storage deployments_ | can be determined from blob / file extension |
+| `mimepart` | int(11) | NO | | 0 | | _"_ | can be determined from blob / file extension |
+| `size` | bigint(20) | NO | | 0 | | _same as blob size unless encryption is used_ | MAY become size, can be determined from blob |
+| `mtime` | bigint(20) | NO | | 0 | | _same as blob mtime_ | for files MAY become mtime (can be determined from blob as well), for directories MUST become tmtime |
+| `encrypted` | int(11) | NO | | 0 | | _encrypted flag_ | oCIS currently does not support encryption |
+| `etag` | varchar(40) | YES | | NULL | | _used to propagate changes in a tree_ | MUST be migrated (or calculated in the same way) to prevent clients from syncing unnecessarily |
+| `unencrypted_size` | bigint(20) | NO | | 0 | | _same as blob size_ | oCIS currently does not support encryption |
+| `storage_mtime` | bigint(20) | NO | | 0 | | _used to detect external storage changes_ | oCIS delegates that to the storage providers and drivers |
+| `permissions` | int(11) | YES | | 0 | | *used as the basis for permissions. synced from disk when running a file scan. * | oCIS delegates that to the storage providers and drivers |
+| `checksum` | varchar(255) | YES | | NULL | | _same as blob checksum_ | SHOULD become the checksum in the storage provider. eos calculates it itself, `ocis` driver stores it in extended attributes |
+
+
+[quote]
+____
+Note: for EOS a hot migration only works seamlessly if file ids in oc10 are already read from eos. Otherwise, either a mapping from the oc10 filecache file id to the new eos file id has to be created under the assumption that these id sets do not intersect or files and corresponding shares need to be exported and imported offline to generate a new set of ids. While this will preserve public links, user, group and even federated shares, old internal links may still point to different files because they contain the oc10 fileid
+____
+
+
+
+
+=== share table
+
+used to store
+- Public links
+- Private shares with users and groups
+- Federated shares _partly_
+- Guest shares
+
+| Field | Type | Null | Key | Default | Extra | Comment | link:https://cs3org.github.io/cs3apis/[CS3 API] |
+|---------------|--------------|------|-----|---------|----------------|---------|-|
+| `id` | int(11) | NO | PRI | NULL | auto_increment | | `ShareId.opaqueid` string |
+| `share_type` | smallint(6) | NO | | 0 | | _in CS3 every type is handled by a dedicated API. See below the table_ | does NOT map to link:https://cs3org.github.io/cs3apis/#cs3.sharing.ocm.v1beta1.Share.ShareType[`Share.ShareType`] _TODO clarify_ |
+| `share_with` | varchar(255) | YES | MUL | NULL | | | `Share.grantee` link:https://cs3org.github.io/cs3apis/#cs3.storage.provider.v1beta1.Grantee[`Grantee`] |
+| `uid_owner` | varchar(64) | NO | | | | | `ShareId.owner` link:https://cs3org.github.io/cs3apis/#cs3.identity.user.v1beta1.UserId[`UserID`] |
+| `parent` | int(11) | YES | | NULL | | | - |
+| `item_type` | varchar(64) | NO | MUL | | | | `Share.resource_id` link:https://cs3org.github.io/cs3apis/#cs3.storage.provider.v1beta1.ResourceId[`ResourceId`] |
+| `item_source` | varchar(255) | YES | MUL | NULL | | | `Share.resource_id` link:https://cs3org.github.io/cs3apis/#cs3.storage.provider.v1beta1.ResourceId[`ResourceId`] |
+| `item_target` | varchar(255) | YES | | NULL | | | `Share.resource_id` link:https://cs3org.github.io/cs3apis/#cs3.storage.provider.v1beta1.ResourceId[`ResourceId`] |
+| `file_source` | bigint(20) | YES | MUL | NULL | | _cannot store uuid style file ids from oCIS. when all users have migrated to oCIS the share manager needs to be updated / migrated to a version that does._ | `Share.resource_id` link:https://cs3org.github.io/cs3apis/#cs3.storage.provider.v1beta1.ResourceId[`ResourceId`] |
+| `file_target` | varchar(512) | YES | | NULL | | | `Share.resource_id` link:https://cs3org.github.io/cs3apis/#cs3.storage.provider.v1beta1.ResourceId[`ResourceId`] |
+| `permissions` | smallint(6) | NO | | 0 | | | `Share.Permissions` link:https://cs3org.github.io/cs3apis/#cs3.sharing.ocm.v1beta1.SharePermissions[`SharePermissions`] |
+| `stime` | bigint(20) | NO | | 0 | | | `Share.ctime`, `Share.mtime` |
+| `accepted` | smallint(6) | NO | | 0 | | | `ReceivedShare.ShareState` link:https://cs3org.github.io/cs3apis/#cs3.sharing.collaboration.v1beta1.ShareState[`ShareState`] |
+| `expiration` | datetime | YES | | NULL | | _only used for the Link API and storage provider api, currently cannot be added using the Collaboration or OCM API_ | link:https://cs3org.github.io/cs3apis/#cs3.storage.provider.v1beta1.Grant[`Grant`] |
+| `token` | varchar(32) | YES | MUL | NULL | | | link:https://cs3org.github.io/cs3apis/#cs3.sharing.link.v1beta1.PublicShare[`PublicShare.token`] |
+| `mail_send` | smallint(6) | NO | | 0 | | | - |
+| `uid_initiator` | varchar(64) | YES | | NULL | | | `ShareId.creator` link:https://cs3org.github.io/cs3apis/#cs3.identity.user.v1beta1.UserId[`UserID`] |
+| `share_name` | varchar(64) | YES | | NULL | | _only exists for public shares_ | link:https://cs3org.github.io/cs3apis/#cs3.sharing.link.v1beta1.PublicShare[`PublicShare.display_name`] |
+| `attributes` | longtext | YES | | NULL | | _additional share attributes_ | _could be implemented using opaque data, but should be added to the CS3 api_ |
+
+In the CS3 API
+1. public links are handled by the PublicShareProvider using the link:https://cs3org.github.io/cs3apis/#cs3.sharing.link.v1beta1.LinkAPI[Link API]
+2. internal shares are handled by the UserShareProvider using the link:https://cs3org.github.io/cs3apis/#cs3.sharing.collaboration.v1beta1.CollaborationAPI[Collaboration API]. This covers user and group shares.
+3. federated shares are handled by the OcmShareProvider using the link:https://cs3org.github.io/cs3apis/#cs3.sharing.ocm.v1beta1.OcmAPI[OCM Share Provider AP] aka. Open Cloud Mesh.
+
+
+
+
+=== share_external
+
+Used to store additional metadata for federated shares.
+
+| Field | Type | Null | Key | Default | Extra | Comment |
+|-----------------|---------------|------|-----|---------|----------------|---------|
+| `id` | bigint(20) | NO | PRI | NULL | auto_increment | |
+| `remote` | varchar(512) | NO | | NULL | | Url of the remote owncloud instance |
+| `share_token` | varchar(64) | NO | | NULL | | Public share token |
+| `password` | varchar(64) | YES | | NULL | | Optional password for the public share |
+| `name` | varchar(64) | NO | | NULL | | Original name on the remote server |
+| `owner` | varchar(64) | NO | | NULL | | User that owns the public share on the remote server |
+| `user` | varchar(64) | NO | MUL | NULL | | Local user which added the external share |
+| `mountpoint` | varchar(4000) | NO | | NULL | | Full path where the share is mounted |
+| `mountpoint_hash` | varchar(32) | NO | | NULL | | md5 hash of the mountpoint |
+| `remote_id` | varchar(255) | NO | | -1 | | |
+| `accepted` | int(11) | NO | | 0 | | |
+
+
+
+_TODO document how the reva OCM service currently persists the data_
+
+
+
+
+
+=== trusted_servers
+
+used to determine if federated shares can automatically be accepted
+
+| Field | Type | Null | Key | Default | Extra | Comment |
+|---------------|--------------|------|-----|---------|----------------|---------|
+| `id` | int(11) | NO | PRI | NULL | auto_increment | |
+| `url` | varchar(512) | NO | | NULL | | Url of trusted server |
+| `url_hash` | varchar(255) | NO | UNI | | | sha1 hash of the url without the protocol |
+| `token` | varchar(128) | YES | | NULL | | token used to exchange the shared secret |
+| `shared_secret` | varchar(256) | YES | | NULL | | shared secret used to authenticate |
+| `status` | int(11) | NO | | 2 | | current status of the connection |
+| `sync_token` | varchar(512) | YES | | NULL | | cardDav sync token |
+
+
+
+_TODO clarify how OCM handles this and where we store / configure this. It seems related to trusted IdPs_
+
+
+
+
+
+=== user data
+
+Users are migrated in two steps:
+1. They should all be authenticated using OpenID Connect, which already moves them to a common identity management system.
+2. To search share recipients, both, ownCloud 10 and oCIS need access to the same user directory using e.g. LDAP.
+
+
+
+_TODO add state to CS3 API, so we can 'disable' users_
+_TODO how do we map (sub) admins? -> map to roles & permissions_
+
+
+
+accounts:
+
+| Field | Type | Null | Key | Default | Extra | Comment |
+|---------------|---------------------|------|-----|---------|----------------|---------|
+| `id` | bigint(20) unsigned | NO | PRI | NULL | auto_increment | |
+| `email` | varchar(255) | YES | MUL | NULL | | |
+| `user_id` | varchar(255) | NO | UNI | NULL | | |
+| `lower_user_id` | varchar(255) | NO | UNI | NULL | | |
+| `display_name` | varchar(255) | YES | MUL | NULL | | |
+| `quota` | varchar(32) | YES | | NULL | | |
+| `last_login` | int(11) | NO | | 0 | | |
+| `backend` | varchar(64) | NO | | NULL | | |
+| `home` | varchar(1024) | NO | | NULL | | |
+| `state` | smallint(6) | NO | | 0 | | |
+
+users:
+
+| Field | Type | Null | Key | Default | Extra | Comment |
+|-------------|--------------|------|-----|---------|-------|---------|
+| `uid` | varchar(64) | NO | PRI | | |
+| `password` | varchar(255) | NO | | | |
+| `displayname` | varchar(64) | YES | | NULL | |
+
+groups:
+
+The groups table really only contains the group name.
+
+| Field | Type | Null | Key | Default | Extra |
+|-------|-------------|------|-----|---------|-------|
+| `gid` | varchar(64) | NO | PRI | | |
+
+
+
+=== LDAP
+
+
+
+_TODO clarify if metadata from ldap & user_shibboleth needs to be migrated_
+
+
+
+The `dn` -> _owncloud internal username_ mapping that currently lives in the `oc_ldap_user_mapping` table needs to move into a dedicated `ownclouduuid` attribute in the LDAP server. The idp should send it as a claim so the proxy does not have to look up the user using LDAP again. The username cannot be changed in ownCloud 10 and the oCIS provisioning API will not allow changing it as well. When we introduce the graph api we may allow changing usernames when all clients have moved to that api.
+
+The problem is that the username in owncloud 10 and in oCIS also need to be the same, which might not be the case when the ldap mapping used a different column. In that case we should add another owncloudusername attribute to the ldap server.
+
+
+
+
+=== activities
+
+_dedicated service, not yet implemented, requires decisions about an event system -- jfd_
+
+| Field | Type | Null | Key | Default | Extra | Comment |
+|---------------|---------------|------|-----|---------|----------------|---------|
+| `activity_id` | bigint(20) | NO | PRI | NULL | auto_increment |
+| `timestamp` | int(11) | NO | MUL | 0 | |
+| `priority` | int(11) | NO | | 0 | |
+| `type` | varchar(255) | YES | | NULL | |
+| `user` | varchar(64) | YES | | NULL | |
+| `affecteduser` | varchar(64) | NO | MUL | NULL | |
+| `app` | varchar(255) | NO | | NULL | |
+| `subject` | varchar(255) | NO | | NULL | |
+| `subjectparams` | longtext | NO | | NULL | |
+| `message` | varchar(255) | YES | | NULL | |
+| `messageparams` | longtext | YES | | NULL | |
+| `file` | varchar(4000) | YES | | NULL | |
+| `link` | varchar(4000) | YES | | NULL | |
+| `object_type` | varchar(255) | YES | MUL | NULL | |
+| `object_id` | bigint(20) | NO | | 0 | |
+
+== Links
+
+The link:https://github.com/owncloud/data_exporter[data_exporter] has logic that allows exporting and importing users, including shares. The link:https://github.com/owncloud/data_exporter/tree/master/lib/Model[model classes] contain the exact mapping.
+
+
diff --git a/modules/developer/pages/ocis/release_notes.adoc b/modules/developer/pages/ocis/release_notes.adoc
new file mode 100644
index 00000000..d7eb514a
--- /dev/null
+++ b/modules/developer/pages/ocis/release_notes.adoc
@@ -0,0 +1,5 @@
+= Release Notes
+:toc: right
+:toclevels: 3
+
+The Infinite Scale Release Notes have been moved and are published with the link:https://doc.owncloud.com/docs/next/ocis_release_notes.html[ownCloud Documentation].
diff --git a/modules/developer/pages/ocis/release_roadmap.adoc b/modules/developer/pages/ocis/release_roadmap.adoc
new file mode 100644
index 00000000..be5a6499
--- /dev/null
+++ b/modules/developer/pages/ocis/release_roadmap.adoc
@@ -0,0 +1,136 @@
+= Release Life Cycle
+:toc: right
+:toclevels: 3
+
+
+This page is designed to provide clarity and transparency regarding the scheduling, nature, and support of our releases, ensuring you have all the information you need to stay updated and manage your deployments effectively. Find here an overview of our plans for future enhancements and features: link:https://owncloud.com/roadmap[owncloud.com/roadmap]
+
+== Dates
+
+Note that Version and Notes tagged with UNRELEASED are only prepared and cannot be resolved by design.
+
+
+| Release Date | Type | Version | Notes |
+|----------------|----------------|---------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------------------|
+| UNRELEASED | _Production_ | _link:https://download.owncloud.com/ocis/ocis/stable/7.1.0/[Infinite Scale 7 (7.1.0)]_ | _link:https://doc.owncloud.com/ocis_release_notes.html#infinite-scale-7-1-0-production[Release Notes]_ |
+| 07.02.2025 | _Production_ | _link:https://download.owncloud.com/ocis/ocis/stable/7.0.1/[Infinite Scale 7 (7.0.1)]_ | _link:https://doc.owncloud.com/ocis_release_notes.html#infinite-scale-7-0-1-production[Release Notes]_ |
+| 07.02.2025 | Rolling | link:https://download.owncloud.com/ocis/ocis/rolling/6.5.1/[Infinite Scale 6 (6.5.1)] | link:https://doc.owncloud.com/ocis_release_notes.html#infinite-scale-6-5-1-rolling[Release Notes] |
+| _17.12.2024_ | _Production_ | _link:https://download.owncloud.com/ocis/ocis/stable/7.0.0/[Infinite Scale 7 (7.0.0)]_ | _link:https://doc.owncloud.com/ocis_release_notes.html#infinite-scale-7-0-0-production[Release Notes]_ |
+| _14.11.2024_ | _Production_ | _link:https://download.owncloud.com/ocis/ocis/stable/5.0.9/[Infinite Scale 5 (5.0.9)]_ | _link:https://doc.owncloud.com/ocis_release_notes.html#infinite-scale-5-0-9-production[Release Notes]_ |
+| 24.10.2024 | Rolling | link:https://download.owncloud.com/ocis/ocis/rolling/6.6.1/[Infinite Scale 6 (6.6.1)] | link:https://doc.owncloud.com/ocis_release_notes.html#infinite-scale-6-6-1-rolling[Release Notes] |
+| 22.10.2024 | Rolling | link:https://download.owncloud.com/ocis/ocis/rolling/6.6.0/[Infinite Scale 6 (6.6.0)] | link:https://doc.owncloud.com/ocis_release_notes.html#infinite-scale-6-6-0-rolling[Release Notes] |
+| 01.10.2024 | Rolling | link:https://download.owncloud.com/ocis/ocis/rolling/6.5.0/[Infinite Scale 6 (6.5.0)] | link:https://doc.owncloud.com/ocis_release_notes.html#infinite-scale-6-5-0-rolling[Release Notes] |
+| 30.09.2024 | Production | link:https://download.owncloud.com/ocis/ocis/stable/5.0.8/[Infinite Scale 5 (5.0.8)] | link:https://doc.owncloud.com/ocis_release_notes.html#infinite-scale-5-0-8-production[Release Notes] |
+| 12.09.2024 | Rolling | link:https://download.owncloud.com/ocis/ocis/rolling/6.4.0/[Infinite Scale 6 (6.4.0)] | link:https://doc.owncloud.com/ocis_release_notes.html#infinite-scale-6-4-0-rolling[Release Notes] |
+| 04.09.2024 | Production | link:https://download.owncloud.com/ocis/ocis/stable/5.0.7/[Infinite Scale 5 (5.0.7)] | link:https://doc.owncloud.com/ocis_release_notes.html#infinite-scale-5-0-7-production[Release Notes] |
+| 19.08.2024 | Rolling | link:https://download.owncloud.com/ocis/ocis/rolling/6.3.0/[Infinite Scale 6 (6.3.0)] | link:https://doc.owncloud.com/ocis_release_notes.html#infinite-scale-6-3-0-rolling[Release Notes] |
+| 30.07.2024 | Rolling | link:https://download.owncloud.com/ocis/ocis/rolling/6.2.0/[Infinite Scale 6 (6.2.0)] | link:https://doc.owncloud.com/ocis_release_notes.html#infinite-scale-6-2-0-rolling[Release Notes] |
+| 08.07.2024 | Rolling | link:https://download.owncloud.com/ocis/ocis/rolling/6.1.0/[Infinite Scale 6 (6.1.0)] | link:https://doc.owncloud.com/ocis_release_notes.html#infinite-scale-6-1-0-rolling[Release Notes] |
+| 19.06.2024 | Rolling | link:https://download.owncloud.com/ocis/ocis/rolling/6.0.0/[Infinite Scale 6 (6.0.0)] | link:https://doc.owncloud.com/ocis_release_notes.html#infinite-scale-6-0-0-rolling[Release Notes] |
+| 17.07.2024 | Production | link:https://download.owncloud.com/ocis/ocis/stable/5.0.6/[Infinite Scale 5 (5.0.6)] | link:https://doc.owncloud.com/ocis_release_notes.html#infinite-scale-5-0-6[Release Notes] |
+| 22.05.2024 | Production | link:https://download.owncloud.com/ocis/ocis/stable/5.0.5/[Infinite Scale 5 (5.0.5)] | link:https://doc.owncloud.com/ocis_release_notes.html#infinite-scale-5-0-5[Release Notes] |
+| 14.05.2024 | Production | link:https://download.owncloud.com/ocis/ocis/stable/5.0.4/[Infinite Scale 5 (5.0.4)] | link:https://doc.owncloud.com/ocis_release_notes.html#infinite-scale-5-0-4[Release Notes] |
+| 02.05.2024 | Production | link:https://download.owncloud.com/ocis/ocis/stable/5.0.3/[Infinite Scale 5 (5.0.3)] | link:https://doc.owncloud.com/ocis_release_notes.html#infinite-scale-5-0-3[Release Notes] |
+| 17.04.2024 | Production | link:https://download.owncloud.com/ocis/ocis/stable/5.0.2/[Infinite Scale 5 (5.0.2)] | link:https://doc.owncloud.com/ocis_release_notes.html#infinite-scale-5-0-2[Release Notes] |
+| 11.04.2024 | Production | link:https://download.owncloud.com/ocis/ocis/stable/5.0.1/[Infinite Scale 5 (5.0.1)] | link:https://doc.owncloud.com/ocis_release_notes.html#infinite-scale-5-0-1[Release Notes] |
+| 18.03.2024 | Production | link:https://download.owncloud.com/ocis/ocis/stable/5.0.0/[Infinite Scale 5 (5.0.0)] | link:https://doc.owncloud.com/ocis_release_notes.html#infinite-scale-5-0-0[Release Notes] |
+| 27.03.2024 | Production | link:https://download.owncloud.com/ocis/ocis/stable/4.0.7/[Infinite Scale 4 (4.0.7)] | link:https://doc.owncloud.com/ocis_release_notes.html#infinite-scale-4-0-7[Release Notes] |
+| 07.02.2024 | Production | link:https://download.owncloud.com/ocis/ocis/stable/4.0.6/[Infinite Scale 4 (4.0.6)] | link:https://doc.owncloud.com/ocis_release_notes.html#infinite-scale-4-0-6[Release Notes] |
+| 21.12.2023 | Production | link:https://download.owncloud.com/ocis/ocis/stable/4.0.5/[Infinite Scale 4 (4.0.5)] | link:https://doc.owncloud.com/ocis_release_notes.html#infinite-scale-4-0-5[Release Notes] |
+| 07.12.2023 | Production | link:https://download.owncloud.com/ocis/ocis/stable/4.0.4/[Infinite Scale 4 (4.0.4)] | link:https://doc.owncloud.com/ocis_release_notes.html#infinite-scale-4-0-4[Release Notes] |
+| 24.11.2023 | Production | link:https://download.owncloud.com/ocis/ocis/stable/4.0.3/[Infinite Scale 4 (4.0.3)] | link:https://doc.owncloud.com/ocis_release_notes.html#infinite-scale-4-0-3[Release Notes] |
+| 06.10.2023 | Production | link:https://download.owncloud.com/ocis/ocis/stable/4.0.2/[Infinite Scale 4 (4.0.2)] | link:https://doc.owncloud.com/ocis_release_notes.html#infinite-scale-4-0-2[Release Notes] |
+| 01.09.2023 | Production | link:https://download.owncloud.com/ocis/ocis/stable/4.0.1/[Infinite Scale 4 (4.0.1)] | link:https://doc.owncloud.com/ocis_release_notes.html#infinite-scale-4-0-1[Release Notes] |
+| 25.08.2023 | Production | link:https://download.owncloud.com/ocis/ocis/stable/4.0.0/[Infinite Scale 4 (4.0.0)] | link:https://doc.owncloud.com/ocis_release_notes.html#infinite-scale-4-0-0[Release Notes] |
+| 07.06.2023 | Production | link:https://download.owncloud.com/ocis/ocis/stable/3.0.0/[Infinite Scale 3 (3.0.0)] | link:https://doc.owncloud.com/ocis_release_notes.html#infinite-scale-3-0-0[Release Notes] |
+| 30.11.2022 | Production | link:https://download.owncloud.com/ocis/ocis/stable/2.0.0/[Infinite Scale 2 (2.0.0)] | link:https://doc.owncloud.com/ocis_release_notes.html#infinite-scale-2-0-0[Release Notes] |
+| 04.04.2022 | Beta | link:https://download.owncloud.com/ocis/ocis/stable/1.9.0/[Infinite Scale 1 (1.9.0)] | link:https://doc.owncloud.com/ocis_release_notes.html#beta-releases[Release Notes] |
+| 04.04.2022 | Beta | link:https://download.owncloud.com/ocis/ocis/stable/1.8.0/[Infinite Scale 1 (1.8.0)] | link:https://doc.owncloud.com/ocis_release_notes.html#beta-releases[Release Notes] |
+| 04.04.2022 | Beta | link:https://download.owncloud.com/ocis/ocis/stable/1.7.0/[Infinite Scale 1 (1.7.0)] | link:https://doc.owncloud.com/ocis_release_notes.html#beta-releases[Release Notes] |
+| 04.04.2022 | Beta | link:https://download.owncloud.com/ocis/ocis/stable/1.6.0/[Infinite Scale 1 (1.6.0)] | link:https://doc.owncloud.com/ocis_release_notes.html#beta-releases[Release Notes] |
+| 04.04.2022 | Beta | link:https://download.owncloud.com/ocis/ocis/stable/1.5.0/[Infinite Scale 1 (1.5.0)] | link:https://doc.owncloud.com/ocis_release_notes.html#beta-releases[Release Notes] |
+| 04.04.2022 | Beta | link:https://download.owncloud.com/ocis/ocis/stable/1.4.0/[Infinite Scale 1 (1.4.0)] | link:https://doc.owncloud.com/ocis_release_notes.html#beta-releases[Release Notes] |
+| 04.04.2022 | Beta | link:https://download.owncloud.com/ocis/ocis/stable/1.3.0/[Infinite Scale 1 (1.3.0)] | link:https://doc.owncloud.com/ocis_release_notes.html#beta-releases[Release Notes] |
+| 13.04.2022 | Beta | link:https://download.owncloud.com/ocis/ocis/stable/1.20.0/[Infinite Scale 1 (1.20.0)] | link:https://doc.owncloud.com/ocis_release_notes.html#beta-releases[Release Notes] |
+| 04.04.2022 | Tech Preview | link:https://download.owncloud.com/ocis/ocis/stable/1.2.0/[Infinite Scale 1 (1.2.0)] | link:https://doc.owncloud.com/ocis_release_notes.html#technology-preview-releases[Release Notes] |
+| 05.04.2022 | Tech Preview | link:https://download.owncloud.com/ocis/ocis/stable/1.19.1/[Infinite Scale 1 (1.19.1)] | link:https://doc.owncloud.com/ocis_release_notes.html#technology-preview-releases[Release Notes] |
+| 05.04.2022 | Tech Preview | link:https://download.owncloud.com/ocis/ocis/stable/1.19.0/[Infinite Scale 1 (1.19.0)] | link:https://doc.owncloud.com/ocis_release_notes.html#technology-preview-releases[Release Notes] |
+| 04.04.2022 | Tech Preview | link:https://download.owncloud.com/ocis/ocis/stable/1.18.0/[Infinite Scale 1 (1.18.0)] | link:https://doc.owncloud.com/ocis_release_notes.html#technology-preview-releases[Release Notes] |
+| 04.04.2022 | Tech Preview | link:https://download.owncloud.com/ocis/ocis/stable/1.17.0/[Infinite Scale 1 (1.17.0)] | link:https://doc.owncloud.com/ocis_release_notes.html#technology-preview-releases[Release Notes] |
+| 04.04.2022 | Tech Preview | link:https://download.owncloud.com/ocis/ocis/stable/1.16.0/[Infinite Scale 1 (1.16.0)] | link:https://doc.owncloud.com/ocis_release_notes.html#technology-preview-releases[Release Notes] |
+| 04.04.2022 | Tech Preview | link:https://download.owncloud.com/ocis/ocis/stable/1.15.0/[Infinite Scale 1 (1.15.0)] | link:https://doc.owncloud.com/ocis_release_notes.html#technology-preview-releases[Release Notes] |
+| 04.04.2022 | Tech Preview | link:https://download.owncloud.com/ocis/ocis/stable/1.14.0/[Infinite Scale 1 (1.14.0)] | link:https://doc.owncloud.com/ocis_release_notes.html#technology-preview-releases[Release Notes] |
+| 04.04.2022 | Tech Preview | link:https://download.owncloud.com/ocis/ocis/stable/1.13.0/[Infinite Scale 1 (1.13.0)] | link:https://doc.owncloud.com/ocis_release_notes.html#technology-preview-releases[Release Notes] |
+| 04.04.2022 | Tech Preview | link:https://download.owncloud.com/ocis/ocis/stable/1.12.0/[Infinite Scale 1 (1.12.0)] | link:https://doc.owncloud.com/ocis_release_notes.html#technology-preview-releases[Release Notes] |
+| 04.04.2022 | Tech Preview | link:https://download.owncloud.com/ocis/ocis/stable/1.11.0/[Infinite Scale 1 (1.11.0)] | link:https://doc.owncloud.com/ocis_release_notes.html#technology-preview-releases[Release Notes] |
+| 04.04.2022 | Tech Preview | link:https://download.owncloud.com/ocis/ocis/stable/1.10.0/[Infinite Scale 1 (1.10.0)] | link:https://doc.owncloud.com/ocis_release_notes.html#technology-preview-releases[Release Notes] |
+| 04.04.2022 | Tech Preview | link:https://download.owncloud.com/ocis/ocis/stable/1.1.0/[Infinite Scale 1 (1.1.0)] | link:https://doc.owncloud.com/ocis_release_notes.html#technology-preview-releases[Release Notes] |
+| 04.04.2022 | Tech Preview | link:https://download.owncloud.com/ocis/ocis/stable/1.0.0/[Infinite Scale 1 (1.0.06)] | link:https://doc.owncloud.com/ocis_release_notes.html#technology-preview-releases[Release Notes] |
+Please find the daily release here: link:https://download.owncloud.com/ocis/ocis/daily/[https://download.owncloud.com/ocis/ocis/daily/].
+
+
+== Release Types
+
+ownCloud Infinite Scale is released in three different release types: _Production_, _Rolling_ and _Daily_. Each of them is targeted to a specific use case and audience group:
+
+// SHORTCODE: {{< hint type=tip title=Production >}}
+- Stable and tested release, suitable for critical data.
+- Slow cycle, but most stable with slow feature additions.
+- Patch releases are provided for critical- and security-bugs as defined by ownCloud support regulations.
+// SHORTCODE: {{< /hint >}}
+<--->
+// SHORTCODE: {{< hint title=Rolling icon=gdoc_check >}}
+- Chances are high that some manual testing has happened, yet not structured.
+- Features are mostly completed. An upgrade path from the previous rolling release is provided and tested. Great release to use with non critical data.
+- Critical bugs are guaranteed to be fixed with the next rolling release.
+// SHORTCODE: {{< /hint >}}
+##
+<--->
+// SHORTCODE: {{< hint type=important title=Daily >}}
+- Mainly for test use cases. As the releases are done completely unattended, only the automatic test suite has tested the release. Manual testing was only applied by chance.
+- Based on ownClouds strong test suite the daily releases are pretty stable, but the risk of unfinished changes is high.
+- For example, if a feature requires three commits, and only one was committed, the daily is cut anyway.{{< /columns >}}
+// SHORTCODE: {{< /hint >}}
+
+| Type | Production | Rolling | Daily |
+| ----------------------------- | ------------------------------------------------------------------------------------------------------ | -------------------------------------------------- | ---------------------------------------- |
+| Frequency | About every 6 month | Every 3 weeks | Daily |
+| Audience | Everyone | Early adopters | Developers |
+| Risk | Low (known) risk | Low-medium risk | High (unknown) risk |
+| Support | Commercially supported | Company support on special agreement with ownCloud | Community support |
+| Documentation | Official | Moving documentation | Moving documentation, engineering output |
+| Updates | Patch releases based on last stable | Rolling every three weeks | None |
+| Update path | Incremental: from previous production to new production, from last rolling before a production release | from previous rolling to new rolling | Clean slate |
+| Downgrade | No | No | No |
+| Service-level agreement (SLA) | Yes | No | No |
+| Overlapping support | Yes | No | No |
+
+
+
+
+== Documentation
+- _Production_ will come with released documentation that is specific for the release. It will remain valid throughout the whole livetime of the release. If patches require documentation changes, addendums will be delivered.
+
+- _Daily_ and _Rolling_ have access to the documentation as it moves forward in the development process along with the product which will be available on ownClouds web site. There wont be specific releases. Changelog entries, PR comments and similar engineering output can complement the information.
+
+== Updating and Overlap
+
+- _Production_ provides a guaranteed upgrade path from the last Production release, as well as from the previous Rolling release before the new Production. For that, support from ownCloud is required. Upgrades between two Production releases are only supported to tested patch releases provided by ownCloud. In an upgrade process, all released patch releases have to be installed in the correct sequence.
+
+- _Rolling_ is guaranteed to upgrade from the last rolling release or from the previous daily before the new Rolling release. If a critical bug is found in a rolling release, it is guaranteed to be fixed in the next Rolling. There are no backports to the Rolling. In critical cases, an upgrade to a daily release in between has to be done at own risk.
+
+- _Daily_ does not come with any guaranteed update path. Chances are good that updates will go smooth, but that might have hickups in cases where the upgrade code is not finalized in time.
+
+Only production gives a reasonable overlap time between releases, for example if version 9 was released, version 8 will still receive a patch release for critical bugs for a reasonable time frame. That time frame will be announced separately and will be aligned with customer needs.
+== Support
+ownCloud only offers commercial support for _Production_. Rolling might be considered for customer installations in the sales process but always requires an individual agreement between all parties.
+
+_Daily_ and _Rolling_ are supported on best effort provided by community and ownCloud staff. There is _no SLA_ and no guarantee for attention.
+
+As ownCloud understands that the effort taken to report a problem is significant and results benefit all users in the community and ownCloud customers, there are resources available to respectfully work on community issues.
+
+Please consider the link:https://github.com/owncloud/ocis/blob/master/CONTRIBUTING.md[Contribution guidelines] for this.
+
+== Versioning Scheme
+image::../storage/semver-schema.png[Schema of Semantic Versioning,width=70%]
+We adhere to _Semantic Versioning_ (SemVer) to ensure clarity and predictability in each of our releases. Learn how Semantic Versioning works on link:https://semver.org/ [https://semver.org/].
diff --git a/modules/developer/pages/ocis/releasing_guide/index.adoc b/modules/developer/pages/ocis/releasing_guide/index.adoc
new file mode 100644
index 00000000..58e348db
--- /dev/null
+++ b/modules/developer/pages/ocis/releasing_guide/index.adoc
@@ -0,0 +1,7 @@
+= Releasing Processes
+:toc: right
+:toclevels: 3
+
+== General Information
+
+This section provides information how to prepare a new Infinite Scale release.
diff --git a/modules/developer/pages/ocis/releasing_guide/releasing_guide.adoc b/modules/developer/pages/ocis/releasing_guide/releasing_guide.adoc
new file mode 100644
index 00000000..fbd06dcf
--- /dev/null
+++ b/modules/developer/pages/ocis/releasing_guide/releasing_guide.adoc
@@ -0,0 +1,200 @@
+= Releasing Guide
+:toc: right
+:toclevels: 3
+
+
+To prepare an oCIS production release, you must follow a specific sequence of steps in the correct order.
+
+== New ocis Version
+
+Use this detailed copy/paste checklists for Jira when starting a new release.
+
+[WARNING]
+====
+* The _examples_ use the following versions which will need to be _adapted_ for the planned release:
+ * For Major and Minor versions: `7.2.0`
+ * For Patch releases: `7.2.1`
+* The process differs slighly when creating a patch release only.
+* Changes applied to a `stable-7.2` branch valid for documentation will be processed to the `docs-stable-x.y` branch automatically after merging.
+====
+
+
+=== Steps for Major or Minor Releases
+
+[WARNING]
+====
+* A new production release is being prepared and the implementation of new features has finished in master.
+* `web`, `reva` and `dependencies` have already been bumped.
+* Translations
+ * For oCIS, all required translations changes are included.
+ * For Web, all translation changes have been applied and are part of the web version provided.
+* _Only_ bug fixes to release candidates are allowed.
+====
+
+
+==== Overview
+
+1. Start the Releasing Process
+1. Start the Release Candidates Phase
+1. Prepare Release\
+Integrate all RC changes and set the final version
+1. Sign-off the Releasing Process
+1. Release the new Version
+1. Postprocessing and Finalization\
+Backport changes to `master` and create other required stable branches, update cronjobs and clean up
+
+==== Details
+
+----
+https://owncloud.dev/ocis/releasing_guide/
+
+* [ ] Start the Releasing Process
+ * [ ] Create a `stable-7.2` branch based on current `master`
+ * [ ] Inform documentation that the releasing process has started
+
+* [ ] Start the Release Candidates Phase
+ * [ ] Create a new feature branch based on `stable-7.2`
+ * [ ] Move all changelog items from `unreleased` to `7.2.0-rc.1_2025-06-12`
+ * [ ] Bump oCIS version in `ocis-pkg/version/version.go`
+ * [ ] Bump oCIS version in `sonar-project.properties`
+ * [ ] Create PR with `[full-ci][k6-test]` against `stable-7.2`
+ * [ ] Get PR approved. **DO NOT MERGE YET**
+ * [ ] Wait for pipeline to be green
+ * [ ] Create tag: `git tag -s v7.2.0-rc.1 -m "Release 7.2.0-rc.1"`
+ * [ ] Push tag: `git push origin v7.2.0-rc.1`
+ * [ ] Watch the PR to see pipeline succeed (can be restarted)
+ * [ ] Merge PR
+ * [ ] Sync with DevOps and Product\
+ Repeat process with `rc.2`,`rc.3`, ...
+ * [ ] All required translations from oCIS are included
+ * [ ] All issues are fixed, RC phase has finished
+
+* [ ] Prepare Release
+ * [ ] Create a new feature branch based on `stable-7.2`
+ * [ ] Move all changelog items from `7.2.0-rc.*` to `7.2.0_2025-04-01`
+ * [ ] Bump oCIS version in `ocis-pkg/version/version.go`
+ * [ ] Bump oCIS version in `sonar-project.properties`
+ * [ ] Create PR with `[full-ci][k6-test]` against `stable-7.2`
+ * [ ] Mark PR as **Draft** to avoid accidentially merging
+ * [ ] Get PR approved. **DO NOT MERGE YET**\
+ Info: merging will be done in step *Release the new Version*
+ * [ ] Wait for pipeline to be green
+
+* [ ] Get new Release Sign-off (jira)
+ * [ ] **EITHER (preferred):** Find someone who wants the release more than you do, and have them sign-off
+ * [ ] **OR (not recommended):** Have the appropriate people sign the *release sign-off* document
+
+* [ ] Release the new Version
+ * [ ] Create tag: `git tag -s v7.2.0 -m "Release 7.2.0"`\
+ Note the tag name scheme is important
+ * [ ] Push tag: `git push origin v7.2.0`
+ * [ ] Watch the PR to see pipeline succeed (can be restarted)
+ * [ ] Smoke test docker image `owncloud/ocis@v7.2.0`
+ * [ ] Choose any docker-compose example from oCIS repository
+ * [ ] Export `OCIS_DOCKER_IMAGE=owncloud/ocis`
+ * [ ] Export `OCIS_DOCKER_TAG=7.2.0`
+ * [ ] `docker compose up -d`
+ * [ ] Confirm oCIS version in browser and start the `upload-download-awesome` test
+ * [ ] Remove the **Draft** state and Merge PR\
+ This is the PR from step *Prepare Release*
+ * [ ] Delete the feature branch
+ * [ ] Announce release in *Teams channel: oCIS*
+
+* [ ] Postprocessing and Finalization
+ * [ ] Backport `stable-7.2` to the master branch
+ * [ ] Create a `docs-stable-7.2` branch
+ * [ ] Create orphan branch: `git checkout --orphan docs-stable-7.2`
+ * [ ] Initial commit: `git commit --allow-empty -m "initial commit"`
+ * [ ] Push it: `git push`
+ * [ ] Adjust the `.drone.star` file to write to `docs-stable-7.2`
+ * [ ] Find target_branch value in the docs section and change it to `docs-stable-7.2`
+ * [ ] Example: https://github.com/owncloud/ocis/blame/56f7645f0b11c9112e15ce46f6effd2fea01d6be/.drone.star#L2249
+ * [ ] Add `stable-7.2` to the nightly cron jobs in drone (`Settings` -> `Cron Jobs`)
+----
+
+=== Steps for Patch Releases Only
+
+[WARNING]
+====
+* A patch branch is prepared, based off the appropriate stable branch, and contains all the changes including `web`, `reva` and `dependencies` bumps. The patch branch is merged into the corresponding stable branch. No release candidates are used because the changes are known.
+* Translations
+ * For oCIS, all required translations changes are included.
+ * For Web, all translation changes have been applied and are part of the web version provided.
+* _Only_ bug fixes to the patch branch are allowed.
+====
+
+
+==== Overview
+
+1. Prepare Release\
+Integrate all patches and set the final version
+1. Sign-off the Releasing Process
+1. Release the new Version
+1. Check Forward Porting to Master
+
+==== Details
+
+----
+https://owncloud.dev/ocis/releasing_guide/
+
+* [ ] Prepare Release
+ * [ ] Create a new feature branch based on `stable-7.2`
+ * [ ] Move all changelog items from `unreleased` to `7.2.1_2025-04-01`
+ * [ ] Bump oCIS version in `ocis-pkg/version/version.go`
+ * [ ] Bump oCIS version in `sonar-project.properties`
+ * [ ] Create PR with `[full-ci][k6-test]` against `stable-7.2`
+ * [ ] Mark PR as **Draft** to avoid accidentially merging
+ * [ ] Get PR approved **requires 2 approvals**, **DO NOT MERGE YET**\
+ Info: merging will be done in step *Release the new Version*
+ * [ ] Wait for pipeline to be green
+
+* [ ] Get new Release Sign-off (confluence)
+ * [ ] **EITHER (preferred):** Find someone who wants the release more than you do, and have them sign-off
+ * [ ] **OR (not recommended):** Have the appropriate people sign the *release sign-off* document
+
+* [ ] Release the new Version
+ * [ ] Create tag: `git tag -s v7.2.1 -m "Release 7.2.1"`\
+ Note the tag name scheme is important
+ * [ ] Push tag: `git push origin v7.2.1`
+ * [ ] Watch the PR to see pipeline succeed (can be restarted)
+ * [ ] Smoke test docker image `owncloud/ocis@v7.2.1`
+ * [ ] Choose any docker-compose example from ocis repository
+ * [ ] Export `OCIS_DOCKER_IMAGE=owncloud/ocis`
+ * [ ] Export `OCIS_DOCKER_TAG=7.2.1`
+ * [ ] `docker compose up -d`
+ * [ ] Confirm oCIS version in browser and start the `upload-download-awesome` test
+ * [ ] Remove the **Draft** state and Merge PR\
+ This is the PR from step *Prepare Release*
+ * [ ] Delete the feature branch
+ * [ ] Announce release in *Teams channel: oCIS*
+
+* [ ] Check if Forward Porting to Master is Required
+----
+
+== Update Documentation Related Data
+
+=== Envvar Changes
+
+Follow the link:https://owncloud.dev/services/general-info/envvars/new-release-process/[Release Process for Envvars] documentation to update the required environment variable data. These changes _must_ be present in the appropriate `stable-7.2` branch and should be applied to the respective feature branch during the development cycle. This _avoids manually backporting_ to `stable-7.2` but may be required if changes go to master instead. Changes to envvars are typically found in the `docs` folder.
+
+[WARNING]
+====
+The admin docs processes access the data via the branch name, not the tag set. Therefore, any changes applied to the stable branch are accessible to the documentation process without the need of a new version.
+====
+
+
+=== Prepare Admin Docs
+
+The admin documentation must be prepared for the new release.
+
+Note that this section is only _informational_ for oCIS developers and is done by the documentation team. This is why they need to be informed in a timely manner.
+
+* [ ] Create _overview release notes_ in the `docs-main` repo based on the changelog\
+The source is most likely the unreleased folder during the development cycle
+* [ ] For Major and Minor versions:
+ * [ ] Add all _documentation changes_ including the upgrade guide in the `docs-ocis` repo in master
+ * [ ] Create a new release branch in the `docs-ocis` repo based off master
+ * [ ] _Update oCIS branches and versions_ in the `docs` repo
+* [ ] For Patch releases:
+ * [ ] _Update oCIS versions_ in the `docs` repo
+
diff --git a/modules/developer/pages/ocis/releasing_guide/troubleshooting.adoc b/modules/developer/pages/ocis/releasing_guide/troubleshooting.adoc
new file mode 100644
index 00000000..95a607a0
--- /dev/null
+++ b/modules/developer/pages/ocis/releasing_guide/troubleshooting.adoc
@@ -0,0 +1,70 @@
+= Troubleshooting
+:toc: right
+:toclevels: 3
+
+
+This document covers some of the issues that can happen during the release process.
+
+Use this detailed copy/paste checklists for the PR when starting a backport.
+
+== Backport Missing Commits
+
+Once the `stable-x.y` branch has been created but work has been merged into master, these changes will not appear in the stable branch unless backporting is used.
+
+[WARNING]
+====
+* Any change applied to `stable-7.2` must be made _before_ the tag for this release is created to be part of which is mandatory for any code change.
+* There is one exception. Changes applied for documentation purposes are accessed via the branch name by the doc process and not via the tag and therefore accessible to the documentation processes.
+====
+
+
+Though any changes should ideally be targeted to the correct branch from the beginning, this may sometimes be impossible, especially for the following folder locations:
+
+- `docs` and
+- `deployments/examples/ocis_full`
+
+=== Documentation
+
+Changes to documentation must be present in the respective stable branch because the documentation process accesses the data for further processing. Follow these steps to apply all doc related changes from master to the stable branch _after_ the tag has been created:
+
+----
+https://owncloud.dev/ocis/releasing_guide/
+
+* [ ] Check all relevant commits made to the master branch that are not in stable\
+`git log stable-7.2..master -- docs/`
+* [ ] Double check all changes if they apply to stable\
+`git diff stable-7.2..master -- docs/`
+* [ ] Create a new feature branch based on `stable-7.2`
+* [ ] Cherry pick missing commits
+* [ ] Create PR with leading `[docs-only]` against `stable-7.2`
+* [ ] Get PR approved **requires 2 approvals** and merge it
+* [ ] Delete feature branch
+----
+
+=== Deployment Example
+
+Changes to the `ocis_full` deployment example are less critical. But as this is referenced by the documentation, changes must be present in the respective stable branch. Follow these steps to apply all deployment example related changes from master to the stable branch _after_ the tag has been created:
+
+==== Web Extensions
+
+Update all dependencies and extension related data in the `web-extensions` repo and create for each extension a new release if applicapable.
+
+==== ocis_full
+
+Update the `ocis_full` deployment example as required in master which includes to update the versions of the web extensions used. Test the functionality if the example works.
+
+Follow these steps to apply all `ocis_full` deployment example related changes from master to the stable branch:
+
+----
+https://owncloud.dev/ocis/releasing_guide/
+
+* [ ] Check all relevant commits made to the master branch that are not in stable\
+`git log stable-7.2..master -- deployments/examples/ocis_full/`
+* [ ] Double check all changes if they apply to stable\
+`git diff stable-7.2..master -- deployments/examples/ocis_full/`
+* [ ] Create a new feature branch based on `stable-7.2`
+* [ ] Cherry pick missing commits
+* [ ] Create PR with leading `[docs-only]` against `stable-7.2`
+* [ ] Get PR approved **requires 2 approvals** and merge it
+* [ ] Delete feature branch
+----
diff --git a/modules/developer/pages/ocis/storage-backends/cephfs.adoc b/modules/developer/pages/ocis/storage-backends/cephfs.adoc
new file mode 100644
index 00000000..cb8d450a
--- /dev/null
+++ b/modules/developer/pages/ocis/storage-backends/cephfs.adoc
@@ -0,0 +1,71 @@
+= cephfs
+:toc: right
+:toclevels: 3
+
+
+oCIS intends to make the aspects of existing storage systems available as transparently as possible, but the static sync algorithm of the desktop client relies on some form of recursive change time propagation on the server side to detect changes. While this can be bolted on top of existing file systems with inotify, the kernel audit or a fuse based overlay filesystem, a storage system that already implements this aspect is preferable. Aside from EOS, cephfs supports a recursive change time that oCIS can use to calculate an etag for the webdav API.
+
+== Development
+
+The cephfs development happens in a link:https://github.com/cs3org/reva/pull/1209[Reva branch] and is currently driven by CERN.
+
+== Architecture
+
+In the original approach the driver was based on the link:https://github.com/cs3org/reva/blob/a8c61401b662d8e09175416c0556da8ef3ba8ed6/pkg/storage/utils/localfs/localfs.go[localfs] driver, relying on a locally mounted cephfs. It would interface with it using the POSIX apis. This has been changed to directly call the Ceph API using https://github.com/ceph/go-ceph. It allows using the ceph admin APIs to create sub-volumes for user homes and maintain a file id to path mapping using symlinks.
+
+== Implemented Aspects
+The recursive change time built ino cephfs is used to implement the etag propagation expected by the ownCloud clients. This allows oCIS to pick up changes that have been made by external tools, bypassing any oCIS APIs.
+
+Like other filesystems cephfs uses inodes and like most other filesystems inodes are reused. To get stable file identifiers the current cephfs driver assigns every node a file id and maintains a custom fileid to path mapping in a system directory:
+----
+/tmp/cephfs $ tree -a
+.
+├── reva
+│ └── einstein
+│ ├── Pictures
+│ └── welcome.txt
+└── .reva_hidden
+ ├── .fileids
+ │ ├── 50BC39D364A4703A20C58ED50E4EADC3_570078 -> /tmp/cephfs/reva/einstein
+ │ ├── 571EFB3F0ACAE6762716889478E40156_570081 -> /tmp/cephfs/reva/einstein/Pictures
+ │ └── C7A1397524D0419B38D04D539EA531F8_588108 -> /tmp/cephfs/reva/einstein/welcome.txt
+ └── .uploads
+----
+
+Versions are not file but snapshot based, a link:https://docs.ceph.com/en/latest/dev/cephfs-snapshots/[native feature of cephfs]. The driver maps entries in the native cephfs `.snap` folder to the CS3 api recycle bin concept and makes them available in the web UI using the versions sidebar. Snapshots can be triggered by users themselves or on a schedule.
+
+Trash is not implemented, as cephfs has no native recycle bin and instead relies on the snapshot functionality that can be triggered by end users. It should be possible to automatically create a snapshot before deleting a file. This needs to be explored.
+
+Shares link:https://github.com/cs3org/reva/pull/1209/files#diff-5e532e61f99bffb5754263bc6ce75f84a30c6f507a58ba506b0b487a50eda1d9R168-R224[are mapped to ACLs] supported by cephfs. The share manager is used to persist the intent of a share and can be used to periodically verify or reset the ACLs on cephfs.
+
+== Future work
+- The spaces concept matches cephfs sub-volumes. We can implement the CreateStorageSpace call with that, keep track of the list of storage spaces using symlinks, like for the id based lookup.
+- The share manager needs a persistence layer.
+- Currently we persist using a single json file.
+- As it basically provides two lists, _shared with me_ and _shared with others_, we could persist them directly on cephfs!
+ - If needed for redundancy, the share manager can be run multiple times, backed by the same cephfs
+ - To save disk io the data can be cached in memory, and invalidated using stat requests.
+- A good tradeoff would be a folder for each user with a json file for each list. That way, we only have to open and read a single file when the user want's to list the shares.
+- To allow deprovisioning a user the data should be sharded by userid. That way all share information belonging to a user can easily be removed from the system. If necessary it can also be restored easily by copying the user specific folder back in place.
+- For consistency over metadata any file blob data, backups can be done using snapshots.
+- An example where einstein has shared a file with marie would look like this on disk:
+----
+/tmp/cephfs $ tree -a
+.
+├── reva
+│ └── einstein
+│ ├── Pictures
+│ └── welcome.txt
+├── .reva_hidden
+│ ├── .fileids
+│ │ ├── 50BC39D364A4703A20C58ED50E4EADC3_570078 -> /tmp/cephfs/reva/einstein
+│ │ ├── 571EFB3F0ACAE6762716889478E40156_570081 -> /tmp/cephfs/reva/einstein/Pictures
+│ │ └── C7A1397524D0419B38D04D539EA531F8_588108 -> /tmp/cephfs/reva/einstein/welcome.txt
+│ └── .uploads
+└── .reva_share_manager
+ ├── einstein
+ │ └── sharedWithOthers.json
+ └── marie
+ └── sharedWithMe.json
+----
+- The fileids should link:https://github.com/cs3org/reva/pull/1209/files#diff-eba5c8b77ccdd1ac570c54ed86dfa7643b6b30e5625af191f789727874850172R125-R127[not be based on the path] and instead use a uuid that is also persisted in the extended attributes to allow rebuilding the index from scratch if necessary.
diff --git a/modules/developer/pages/ocis/storage-backends/dcfsnfs.adoc b/modules/developer/pages/ocis/storage-backends/dcfsnfs.adoc
new file mode 100644
index 00000000..6f37d7a9
--- /dev/null
+++ b/modules/developer/pages/ocis/storage-backends/dcfsnfs.adoc
@@ -0,0 +1,60 @@
+= Decomposed FS on NFS
+:toc: right
+:toclevels: 3
+
+
+oCIS' default storage backend is the Decomposed FS. The Decomposed FS can be set up to run on a NFS share. That way the same storage can be provided over the network to other nodes running oCIS.
+
+This document summarizes a few important considerations of the NFS setup and describes a tested setup. The test has not covered concurrent access of data from different nodes yet.
+
+== NFS Server Setup
+
+This document covers the linux kernel NFS server on a standard Linux running on x86_64.
+
+The NFS server needs to be set up in a way that it supports link:https://en.wikipedia.org/wiki/Extended_file_attributes[extended file attributes].
+
+Extended attributes are supported by NFS starting with Kernel version 5.9, which means that the server with the NFS server has to run a kernel with that or a higher version number. To check that, run the command `uname -a` on the NFS server and compare the displayed version number.
+
+The NFS server in the test setup was configured with the following line in the config file `/etc/exports`:
+
+`/space/nfstest 192.168.178.0/24(rw,root_squash,async,subtree_check,anonuid=0,anongid=100,all_squash)`
+
+This exports the directory `/space/nfstest` to the internal network with certain options.
+
+Important:
+
+- The share needs to be exported with the `async` option for proper NFS performance.
+
+== NFS Client Mount
+
+The nodes that run oCIS need to mount the NFS storage to a local mount point.
+
+The test setup uses the client mount command: `mount -t nfs -o nfsvers=4 192.168.178.28:/space/nfstest /mnt/ocisdata/`
+
+It sets the NFS version to 4, which is important to support extended attributes.
+
+After successfully mounting the storage on the client, it can be checked if the NFS setup really supports extended attributes properly using the following commands.
+
+`setfattr -n user.test -v "xattr test string" ocisdata/foo` to write an extended attribute to a file, and `getfattr -d ocisdata/foo` to list all the attributes a file has set.
+
+[NOTE]
+====
+The NFS server setup can be optimized considering system administrative-, performance- and security options. This is not (yet) covered in this documentation.
+====
+
+
+== oCIS Start using the NFS Share
+
+The oCIS server can be instructed to set up the decomposed FS at a certain path by setting the environment variable `OCIS_BASE_DATA_PATH`.
+
+The test setup started an oCIS tech preview single binary release using this start command:
+
+[source,bash]
+----
+./ocis init
+OCIS_BASE_DATA_PATH=/mnt/ocisdata/ OCIS_LOG_LEVEL=debug OCIS_INSECURE=true PROXY_HTTP_ADDR=0.0.0.0:9200 OCIS_URL=https://hostname:9200 ./ocis server
+----
+
+This starts oCIS and a decomposed FS skeleton file system structure is set up on the NFS share.
+
+The oCIS instance is passing a smoke test.
diff --git a/modules/developer/pages/ocis/storage-backends/eos.adoc b/modules/developer/pages/ocis/storage-backends/eos.adoc
new file mode 100644
index 00000000..b8758e66
--- /dev/null
+++ b/modules/developer/pages/ocis/storage-backends/eos.adoc
@@ -0,0 +1,245 @@
+= EOS
+:toc: right
+:toclevels: 3
+
+
+oCIS can be configured to run on top of link:https://eos.web.cern.ch/[eos]. While the link:http://eos-docs.web.cern.ch/[eos documentation] does cover a lot of topics, it leaves out some details that you may have to either pull from various link:https://gitlab.cern.ch/eos/eos-docker[docker containers], the link:https://eos-community.web.cern.ch/[forums] or even the link:https://github.com/cern-eos/eos[source] itself.
+
+This document is a work in progress of the current setup.
+
+== Docker dev environment for eos storage
+
+We begin with the docker-compose.yml found in https://github.com/owncloud/ocis/tree/master/ocis/ and
+switch it to eos-storage.
+
+=== 1. Start eos & ocis containers
+
+Start the eos cluster and ocis via the compose stack.
+----
+docker-compose up -d
+----
+
+[NOTE]
+====
+The first time the _ocis_ container starts up, it will compile ocis from scratch which can take a while.
+To follow progress, run `docker-compose logs -f --tail=10 ocis`
+====
+
+
+=== 2. LDAP support
+
+Configure the OS to resolve users and groups using ldap
+
+----
+docker-compose exec -d ocis /start-ldap
+----
+
+Check that the OS in the ocis container can now resolve einstein or the other demo users
+
+----
+$ docker-compose exec ocis id einstein
+uid=20000(einstein) gid=30000(users) groups=30000(users),30001(sailing-lovers),30002(violin-haters),30007(physics-lovers)
+----
+
+[NOTE]
+====
+If the user is not found at first you might need to wait a few more minutes in case the ocis container is still compiling.
+====
+
+
+We also need to restart the storage-userprovider service, so it picks up the changed environment. Without a restart it is not able to resolve users from LDAP.
+----
+docker-compose exec ocis ./bin/ocis kill storage-userprovider
+docker-compose exec ocis ./bin/ocis run storage-userprovider
+----
+
+=== 3. Home storage
+
+Kill the home storage. By default it uses the `ocis` storage driver. We need to switch it to the `eoshome` driver:
+
+----
+docker-compose exec ocis ./bin/ocis kill storage-home
+docker-compose exec -e STORAGE_HOME_DRIVER=eoshome ocis ./bin/ocis run storage-home
+----
+
+=== 4. Users storage
+
+Kill the users storage. By default it uses the `ocis` storage driver. We need to switch it to the `eos` driver:
+
+----
+docker-compose exec ocis ./bin/ocis kill storage-users
+docker-compose exec -e STORAGE_USERS_DRIVER=eos ocis ./bin/ocis run storage-users
+----
+
+=== 5. Metadata storage
+
+First we need to create the metadata root in eos and set an owner:
+----
+docker-compose exec ocis eos mkdir -p /eos/dockertest/ocis/metadata
+docker-compose exec ocis eos chown 2:2 /eos/dockertest/ocis/metadata
+----
+
+[NOTE]
+====
+The uid and gid `2` are referencing the user `daemon` inside the ocis container. That user is also configured when restarting the accounts service later. For production systems you should create a dedicated user for the metadata storage.
+====
+
+
+Kill the metadata storage. By default it uses the `ocis` storage driver. We need to switch it to the `eos` driver:
+
+----
+docker-compose exec ocis ./bin/ocis kill storage-system
+docker-compose exec -e STORAGE_SYSTEM_DRIVER=eos -e STORAGE_SYSTEM_ROOT=/eos/dockertest/ocis/metadata ocis ./bin/ocis run storage-system
+----
+
+
+=== 6. Accounts service
+
+Kill the accounts service. By default it uses the `ocis` storage driver. We need to switch it to the `eos` driver:
+
+----
+docker-compose exec ocis ./bin/ocis kill accounts
+docker-compose exec -e ACCOUNTS_SERVICE_USER_USERNAME=daemon -e ACCOUNTS_SERVICE_USER_UID=2 -e ACCOUNTS_SERVICE_USER_GID=2 ocis ./bin/ocis run accounts
+----
+
+== Verification
+
+Login with `einstein / relativity`, upload a file to einsteins home and verify the file is there using
+
+----
+docker-compose exec ocis eos ls -l /eos/dockertest/reva/users/4/4c510ada-c86b-4815-8820-42cdf82c3d51/
+-rw-r--r-- 1 einstein users 10 Jul 1 15:24 newfile.txt
+----
+
+If the problem persists, please check the <>.
+
+== Further exploration
+
+EOS has a built-in shell that you can enter using
+----
+$ docker-compose exec mgm-master eos
+# ---------------------------------------------------------------------------
+# EOS Copyright (C) 2011-2019 CERN/Switzerland
+# This program comes with ABSOLUTELY NO WARRANTY; for details type `license'.
+# This is free software, and you are welcome to redistribute it
+# under certain conditions; type `license' for details.
+# ---------------------------------------------------------------------------
+EOS_INSTANCE=eostest
+EOS_SERVER_VERSION=4.6.5 EOS_SERVER_RELEASE=1
+EOS_CLIENT_VERSION=4.6.5 EOS_CLIENT_RELEASE=1
+EOS Console [root://localhost] |/> help
+access Access Interface
+accounting Accounting Interface
+acl Acl Interface
+archive Archive Interface
+attr Attribute Interface
+backup Backup Interface
+clear Clear the terminal
+cd Change directory
+chmod Mode Interface
+chown Chown Interface
+config Configuration System
+console Run Error Console
+cp Cp command
+debug Set debug level
+exit Exit from EOS console
+file File Handling
+fileinfo File Information
+find Find files/directories
+newfind Find files/directories (new implementation)
+fs File System configuration
+fsck File System Consistency Checking
+fuse Fuse Mounting
+fusex Fuse(x) Administration
+geosched Geoscheduler Interface
+group Group configuration
+health Health information about system
+help Display this text
+info Retrieve file or directory information
+inspector Interact with File Inspector
+io IO Interface
+json Toggle JSON output flag for stdout
+license Display Software License
+ls List a directory
+ln Create a symbolic link
+map Path mapping interface
+member Check Egroup membership
+mkdir Create a directory
+motd Message of the day
+mv Rename file or directory
+node Node configuration
+ns Namespace Interface
+pwd Print working directory
+quit Exit from EOS console
+quota Quota System configuration
+reconnect Forces a re-authentication of the shell
+recycle Recycle Bin Functionality
+rmdir Remove a directory
+rm Remove a file
+role Set the client role
+route Routing interface
+rtlog Get realtime log output from mgm & fst servers
+silent Toggle silent flag for stdout
+space Space configuration
+stagerrm Remove disk replicas of a file if it has tape replicas
+stat Run 'stat' on a file or directory
+squash Run 'squashfs' utility function
+test Run performance test
+timing Toggle timing flag for execution time measurement
+touch Touch a file
+token Token interface
+tracker Interact with File Tracker
+transfer Transfer Interface
+version Verbose client/server version
+vid Virtual ID System Configuration
+whoami Determine how we are mapped on server side
+who Statistics about connected users
+? Synonym for 'help'
+.q Exit from EOS console
+EOS Console [root://localhost] |/>
+----
+
+But this is a different adventure. See the links at the top of this page for other sources of information on eos.
+
+== Cleaning up
+
+To clean up and start completely from scratch, run `docker-compose down -v`.
+Then delete the local "bin" folder as root which contains the ocis binaries compiled by the "ocis" docker.
+
+== Troubleshooting
+
+=== Docker-compose exits right away
+
+When running `docker-compose up -d` ocis exits right away.
+
+You can check the error code using `docker-compose ps` and investigate further by running only ocis again using `docker-compose up ocis` (without `-d` so you can see what is going on in the foreground).
+One reason might be that the binary was already built but does not match the container env. Try running `make clean` before running `docker-compose up ocis` so it gets built inside the container.
+
+=== Where are the logs ?
+
+The ocis logs can be accessed using `docker-compose logs ocis`. Add `-f` for following.
+
+=== How do I update a service in the ocis container?
+
+1. `docker-compose exec ocis make clean build` to update the binary
+2. `docker-compose exec ocis ./bin/ocis kill ` to kill the service
+3. `docker-compose exec ocis ./bin/ocis run ` to start the service. Do not forget to set any env vars, e.g.
+ `docker-compose exec -e STORAGE_HOME_DRIVER=eoshome -e STORAGE_DRIVER_EOS_LAYOUT="{{substr 0 1 .Id.OpaqueId}}/{{.Id.OpaqueId}}" ocis ./bin/ocis run storage-home`
+
+=== Creation and upload of files does not work
+
+If the upload did not work, please check the status of the eos space using the command `docker-compose exec mgm-master eos fs ls`.
+In case the default space appears as offline, run `docker-compose exec mgm-master eos space set default on`.
+
+=== Uploading big files appears to hang
+
+Please note that the uploads first go into the "ocis" docker and land in its "/tmp" folder, then gets copied over to the EOS docker using `xrdcopy`.
+This is why uploading first transfers all bytes and then seem to hang for a while during the final copy.
+
+=== Running out of space quickly
+
+The EOS dockers are configured with replication, so every file uploaded there will be replicated 4 times,
+so make sure there is enough physical space on disk when testing.
+
+Also please note that older failed uploads might still be present in the "/tmp" directory of the "ocis" container.
+
diff --git a/modules/developer/pages/ocis/storage-backends/index.adoc b/modules/developer/pages/ocis/storage-backends/index.adoc
new file mode 100644
index 00000000..95a08843
--- /dev/null
+++ b/modules/developer/pages/ocis/storage-backends/index.adoc
@@ -0,0 +1,4 @@
+= Storage backends
+:toc: right
+:toclevels: 3
+
diff --git a/modules/developer/pages/ocis/storage/index.adoc b/modules/developer/pages/ocis/storage/index.adoc
new file mode 100644
index 00000000..824d7eca
--- /dev/null
+++ b/modules/developer/pages/ocis/storage/index.adoc
@@ -0,0 +1,30 @@
+= Storage
+:toc: right
+:toclevels: 3
+
+== Overview
+
+OCIS wraps link:https://github.com/cs3org/reva/[reva] and adds an opinionated configuration to provide two core services for the oCIS platform:
+1. A xref:./spacesregistry.adoc[_Spaces Registry_] that acts as a dictionary for storage _Spaces_ and their metadata
+2. A xref:./spacesprovider.adoc[_Spaces Provider_] that organizes _Resources_ in storage _Spaces_ and persists them in an underlying _Storage System_
+
+_Clients_ will use the _Spaces Registry_ to poll or get notified about changes in all _Spaces_ a user has access to. Every _Space_ has a dedicated `/dav/spaces/` WebDAV endpoint that is served by a _Spaces Provider_ which uses a specific reva storage driver to wrap an underlying _Storage System_.
+
+image::ocis/storage/overview.drawio.svg[]
+
+The dashed lines in the diagram indicate requests that are made to authenticate requests or lookup the storage provider:
+1. After authenticating a request, the proxy may either use the CS3 `userprovider` or the accounts service to fetch the user information that will be minted into the `x-access-token`.
+2. The gateway will verify the JWT signature of the `x-access-token` or try to authenticate the request itself, e.g. using a public link token.
+
+[WARNING]
+====
+The bottom part is lighter because we will deprecate it in favor of using only the CS3 user and group providers after moving some account functionality into reva and glauth. The metadata storage is not registered in the reva gateway to separate metadata necessary for running the service from data that is being served directly.
+====
+
+
+== Endpoints and references
+
+In order to reason about the request flow, two aspects in the architecture need to be understood well:
+1. What kind of xref:./namespaces.adoc[_namespaces_] are presented at the different WebDAV and CS3 endpoints?
+2. What kind of xref:./terminology.md#resources.adoc[_resource_] xref:./terminology.md#references.adoc[_references_] are exposed or required: path or id based?
+image::ocis/storage/storage.drawio.svg[]
diff --git a/modules/developer/pages/ocis/storage/namespaces.adoc b/modules/developer/pages/ocis/storage/namespaces.adoc
new file mode 100644
index 00000000..39687710
--- /dev/null
+++ b/modules/developer/pages/ocis/storage/namespaces.adoc
@@ -0,0 +1,100 @@
+= Namespaces
+:toc: right
+:toclevels: 3
+
+A _namespace_ is a set of paths with a common prefix. Depending on the endpoint you are talking to you will encounter a different kind of namespace:
+In ownCloud 10 all paths are considered relative to the users home. The CS3 API uses a global namespace and the _storage providers_ use a local namespace with paths relative to the storage providers root.
+
+image::ocis/storage/namespaces.drawio.svg[]
+
+The different paths in the namespaces need to be translated while passing xref:./terminology.md#references.adoc[_references_] from service to service. While the oc10 endpoints all work on paths we internally reference shared resources by id, so the shares don't break when a file is renamed or moved inside a storage xref:./spaces.adoc[_space_]. The following table lists the various namespaces, paths and id based references:
+
+| oc10 namespace | CS3 global namespace | storage provider | reference | content |
+|--------------------------------------------------|----------------------------------------|------------------|-----------|---------|
+| `/webdav/path/to/file.ext` `/dav/files//path/to/file.ext` | `/home/path/to/file.ext` | home | `//path/to/file.ext` | currently logged in users home |
+| `/webdav/Shares/foo` `/dav/files//Shares/foo` | `/home/Shares/foo` | users | id based access | all users, used to access collaborative shares |
+| `/dav/public-files//rel/path/to/file.ext` | `/public//rel/path/to/file.ext` | public | id based access | publicly shared files, used to access public links |
+
+
+[CAUTION]
+====
+oCIS currently is configured to jail users into the CS3 `/home` namespace in the oc10 endpoints to mimic ownCloud 10. CernBox has been exposing a global namespace on `/webdav` for years already. The ocs service returns urls that are relative to the CS3 global namespace which makes both scenarios work, but only one of them at a time. Which is why the testsuite hiccups when trying to link:https://github.com/cs3org/reva/pull/1605[Allow full paths targets in reva#1605].
+====
+
+
+
+[WARNING]
+====
+In the global CS3 namespaces we plan to move `/home/Shares`, which currently lists all mounted shares of the currently logged-in user to a dedicated `/shares` namespace. See xref:#cs3-namespaces.adoc[below] and link:https://github.com/cs3org/reva/pull/1584[Move shares folder out from home directory to a separate mount reva#1584].
+====
+
+
+== ownCloud namespaces
+
+In contrast to the global namespace of CS3, ownCloud always presented a user specific namespace on all endpoints. It will always list the users private files under `/`. Shares can be mounted at an arbitrary location in the users private spaces. See the xref:./spacesprovider#webdav.adoc[webdav] and xref:./spacesprovider#sharing.adoc[ocs] sections for more details end examples.
+
+With the spaces concept we are planning to introduce a global namespace to the ownCloud webdav endpoints. This will push the users private space down in the hierarchy: it will move from `/webdav` to `/webdav/home` or `/webdav/users/`. The related xref:../../ocis/migration.adoc[migration stages] are subject to change.
+
+== CS3 global namespaces
+
+The _CS3 global namespace_ in oCIS is configured in the storage xref:./spacesregistry.adoc[_spaces registry_]. oCIS uses these defaults:
+
+| global namespace | description |
+|-|-|
+| `/home` | an alias for the currently logged in uses private space |
+| `/users/` | user private spaces |
+| `/shares` | a virtual listing of share spaces a user has access to |
+| `/public/` | a virtual folder listing public shares |
+| `/spaces/` | _TODO: project or group spaces_ |
+
+Technically, the `/home` namespace is not necessary: the storage xref:./spacesregistry.adoc[_spaces registry_] knows the path to a users private space in the `/users` namespace and the gateway can forward the requests to the responsible storage provider.
+
+[WARNING]
+====
+*@jfd: Why don't we use `/home/` instead of `/users/`. Then the paths would be consistent with most unix systems.
+====
+
+
+The `/shares` namespace is used to solve two problems:
+- To query all shares the current user has access to the _share manager_ can be used to list the resource ids. While the shares can then be navigated by resource id, they will return the relative path in the actual xref:./terminology.md#storage-providers.adoc[_storage provider_], leaking parent folders of the shared resource.
+- When accepting a remote share e.g., for OCM the resource does not exist on the local instance. They are made accessible in the global namespace under the `/shares` namespace.
+
+[WARNING]
+====
+_@jfd: Should we split `/shares` into `/collaborations`, `/ocm` and `/links`? We also have `/public` which uses token based authentication. They may have different latencies or polling strategies? Well, I guess we can cache them differently regardless of the mount point._
+====
+
+
+== Browser URLs vs API URLs
+In ownCloud 10 you can not only create _public links_ but also _private links_. Both can be copy pasted into an email or chat to grant others access to a file. Most often though, end users will copy and paste the URL from their browsers location bar.
+
+| URL | description |
+|-|-|
+| https://demo.owncloud.com/apps/files/?dir=/Photos/Vacation&fileid=24 | The normal browser URL |
+| https://demo.owncloud.com/apps/files/?fileid=24 | the `dir` is actually not used to find the directory and will be filled when pasting this URL |
+| https://demo.owncloud.com/f/24 | _private links_ are the shortened version of this and work in the same way |
+| https://demo.owncloud.com/s/piLdAAt1m3Bg0Fk | public link |
+
+// SHORTCODE: {{< hint >}}
+The `dir` parameter alone cannot be used to look up the directory, because the path for a file may be different depending on the currently logged-in user:
+- User A shares his `/path/to/Photos` with User X.
+- User B shares his `/other/path/to/Photos` with User X and Y.
+- User A shares his `/path/to/Photos` with User Y.
+
+(Depending on the order in which they accept the shares) X and Y now have two folders `/shares/Photos` and `/shares/Photos (1)`. But if they were to copy paste a link with that path in the URL and if the directory were only looked up by path X and Y would end up in different folders.
+
+You could argue that the path should always use a global path in the CS3 namespace:
+- User A shares his `/users/a/path/to/Photos` with User X.
+- User B shares his `/users/b/other/path/to/Photos` with User X and Y.
+- User A shares his `/users/a/path/to/Photos` with User Y.
+
+By using a global path like this X and Y would always end up in the correct folder. However, there are two caveats:
+- This only works for resources that reside on the instance (because only they have unique and global path). Shares from other instances need to be identified by id, or they cannot be uniquely addressed
+- User A may not want to leak path `path/to` segments leading to `Photos`. They might contain things like `low-priority` or personal data.
+
+That is the reason why URLs always have to contain some kind of stable identifier. By introducing the concept of _storage spaces_ and treating user homes, project drives and shares we can create a URL that contains an identifier for the _storage space_ and a path relative to the root of it.
+// SHORTCODE: {{< /hint >}}
+
+In ocis we will unify the way links sharing works, however there will always be at least two types of URLs:
+1. the URL you see in the browsers location bar, and
+2. the URL that a client uses to actually access a file.
diff --git a/modules/developer/pages/ocis/storage/proposedchanges.adoc b/modules/developer/pages/ocis/storage/proposedchanges.adoc
new file mode 100644
index 00000000..46f3902e
--- /dev/null
+++ b/modules/developer/pages/ocis/storage/proposedchanges.adoc
@@ -0,0 +1,174 @@
+= Proposed Changes
+:toc: right
+:toclevels: 3
+
+Some architectural changes still need to be clarified or changed. Maybe an ADR is in order for all of the below.
+
+== Reva Gateway changes
+
+== A dedicated shares storage provider
+
+Currently, when a user accepts a share, a cs3 reference is created in the users `/home/shares` folder. This reference represents the mount point of a share and can be renamed, similar to the share jail in ownCloud 10. This spreads the metadata of a share in two places:
+- the share is persisted in the _share manager_
+- the mount point of a share is persisted in the home _storage provider_
+
+Furthermore, the _gateway_ treats `/home/shares` different than any other path: it will stat all children and calculate an etag to allow clients to discover changes in accepted shares. This requires the storage provider to cooperate and provide this special `/shares` folder in the root of a users home when it is accessed as a home storage. That is the origin of the `enable_home` config flag that needs to be implemented for every storage driver.
+
+In order to have a single source of truth we need to make the _share manager_ aware of the mount point. We can then move all the logic that aggregates the etag in the share folder to a dedicated _shares storage provider_ that is using the _share manager_ for persistence. The _shares storage provider_ would provide a `/shares` namespace outside of `/home` that lists all accepted shares for the current user. As a result the storage drivers no longer need to have a `enable_home` flag that jails users into their home. The `/home/shares` folder would move outside of the `/home`. In fact `/home` will no longer be needed, because the home folder concept can be implemented as a space: `CreateHome` would create a `personal` space on the.
+
+Work on this is done in https://github.com/cs3org/reva/pull/2023
+
+[WARNING]
+====
+What about copy pasting links from the browser? Well this storage is only really needed to have a path to ocm shares that actually reside on other instances. In the UI the shares would be listed by querying a _share manager_. It returns ResourceIds, which can be stated to fetch a path that is then accessible in the CS3 global namespace. Two caveats:
+- This only works for resources that are actually hosted by the current instance. For those it would leak the parent path segments to a shared resource.
+- For accepted OCM shares there must be a path in the xref:./namespaces.md#cs3-global-namespaces.adoc[_CS3 global namespace_] that has to be the same for all users, otherwise they cannot copy and share those URLs.
+====
+
+
+=== The gateway should be responsible for path transformations
+
+Currently, storage providers are aware af their mount point, coupling them tightly with the gateway.
+
+Tracked in https://github.com/cs3org/reva/issues/578
+
+Work is done in https://github.com/cs3org/reva/pull/1866
+
+== URL escaped string representation of a CS3 reference
+
+For the spaces concept we introduced the `/dav/spaces/` endpoint. It encodes a cs3 _reference_ in a URL compatible way.
+1. We can separate the path using a `/`: `/dav/spaces//`
+2. The `spaceid` currently is a cs3 resourceid, consisting of `` and ``. Since the opaqueid might contain `/` e.g. for the local driver we have to urlencode the spaceid.
+
+To access resources by id we need to make the `/dav/meta/` able to list directories... Otherwise id based navigation first has to look up the path. Or we use the libregraph api for id based navigation.
+
+A _reference_ is a logical concept. It identifies a xref:#resources.adoc[_resource_] and consists of a `` and a ``. A `` consists of a `` and a ``. They can be concatenated using the separators `!` and `:`:
+----
+!:
+----
+While all components are optional, only three cases are used:
+| format | example | description |
+|-|-|-|
+| `!:` | `!:/absolute/path/to/file.ext` | absolute path |
+| `!:` | `ee1687e5-ac7f-426d-a6c0-03fed91d5f62!:path/to/file.ext` | path relative to the root of the storage space |
+| `!:` | `ee1687e5-ac7f-426d-a6c0-03fed91d5f62!c3cf23bb-8f47-4719-a150-1d25a1f6fb56:to/file.ext` | path relative to the specified node in the storage space, used to reference resources without disclosing parent paths |
+
+`` should be a UUID to prevent references from breaking when a _user_ or xref:#storage-spaces.adoc[_storage space_] gets renamed. But it can also be derived from a migration of an oc10 instance by concatenating an instance identifier and the numeric storage id from oc10, e.g. `oc10-instance-a$1234`.
+
+A reference will often start as an absolute/global path, e.g. `!:/home/Projects/Foo`. The gateway will look up the storage provider that is responsible for the path
+
+| Name | Description | Who resolves it? |
+|------|-------------|-|
+| `!:/home/Projects/Foo` | the absolute path a client like davfs will use. | The gateway uses the storage registry to look up the responsible storage provider |
+| `ee1687e5-ac7f-426d-a6c0-03fed91d5f62!:/Projects/Foo` | the `storage_space` is the same as the `root`, the path becomes relative to the root | the storage provider can use this reference to identify this resource |
+
+Now, the same file is accessed as a share
+| Name | Description |
+|------|-------------|
+| `!:/users/Einstein/Projects/Foo` | `Foo` is the shared folder |
+| `ee1687e5-ac7f-426d-a6c0-03fed91d5f62!56f7ceca-e7f8-4530-9a7a-fe4b7ec8089a:` | `56f7ceca-e7f8-4530-9a7a-fe4b7ec8089a` is the id of `Foo`, the path is empty |
+
+
+The `:`, `!` and `$` are chosen from the set of link:https://tools.ietf.org/html/rfc3986#section-2.2[RFC3986 sub delimiters] on purpose. They can be used in URLs without having to be encoded. In some cases, a delimiter can be left out if a component is not set:
+| reference | interpretation |
+|-|-|
+| `/absolute/path/to/file.ext` | absolute path, all delimiters omitted |
+| `ee1687e5-ac7f-426d-a6c0-03fed91d5f62!path/to/file.ext` | relative path in the given storage space, root delimiter `:` omitted |
+| `56f7ceca-e7f8-4530-9a7a-fe4b7ec8089a:to/file.ext` | relative path in the given root node, storage space delimiter `!` omitted |
+| `ee1687e5-ac7f-426d-a6c0-03fed91d5f62!56f7ceca-e7f8-4530-9a7a-fe4b7ec8089a:` | node id in the given storage space, `:` must be present |
+| `ee1687e5-ac7f-426d-a6c0-03fed91d5f62` | root of the storage space, all delimiters omitted, can be distinguished by the `/` |
+
+== space providers
+When looking up an id based resource the reference must use a logical space id, not a CS3 resource id. Otherwise id based requests, which only have a resourceid consisting of a storage id and a node id cannot be routed to the correct storage provider if the storage has moved from one storage provider to another.
+
+if the registry routes based on the storageid AND the nodeid it has to keep a cache of all nodeids in order to route all requests for a storage space (which consists of storage it + nodeid) to the correct storage provider. the correct resourceid for a node in a storage space would be `$!`. The `$` part allow the storage registry to route all id based requests to the correct storage provider. This becomes relevant when the storage space was moved from one storage provider to another. The storage space id remains the same, but the internal address and port change.
+
+TODO discuss to clarify further
+
+== Storage drivers
+
+=== allow clients to send a uuid on upload
+iOS clients can only queue single requests to be executed in the background. They queue an upload and need to be able to identify the uploaded file after it has been uploaded to the server. The disconnected nature of the connection might cause workflows or manual user interaction with the file on the server to move the file to a different place or changing the content while the device is offline. However, on the device users might have marked the file as favorite or added it to other iOS specific collections. To be able to reliably identify the file the client can generate a `uuid` and attach it to the file metadata during the upload. While it is not necessary to look up files by this `uuid` having a second file id that serves exactly the same purpose as the `file id` is redundant.
+
+Another aspect for the `file id` / `uuid` is that it must be a logical identifier that can be set, at least by internal systems. Without a writeable fileid we cannot restore backups or migrate storage spaces from one storage provider to another storage provider.
+
+Technically, this means that every storage driver needs to have a map of a `uuid` to an internal resource identifier. This internal resource identifier can be
+- an eos fileid, because eos can look up files by id
+- an inode if the filesystem and the storage driver support looking up by inode
+- a path if the storage driver has no way of looking up files by id.
+ - In this case other mechanisms like inotify, kernel audit or a fuse overlay might be used to keep the paths up to date.
+ - to prevent excessive writes when deep folders are renamed a reverse map might be used: it will map the `uuid` to `:`, in order to trade writes for reads
+ - as a fallback a sync job can read the file id from the metadata of the resources and populate the uuid to internal id map.
+
+The TUS upload can take metadata, for PUT we might need a header.
+
+=== Space id vs resource id vs storage id
+
+We have `/dav/meta/` where the `fileid` is a string that was returned by a PROPFIND or by the `/graph/v1.0/me/drives/` endpoint? That returns a space id and the root drive item which has an `id`
+
+Does that `id` have a specific format? We currently concatenate as `!`.
+
+A request against `/dav/meta/fileid` will use the reva storage registry to look up a path.
+
+What if the storage space is moved to another storage provider. This happens during a migration:
+
+1. the current oc10 fileids need to be prefixed with at least the numeric storage id to shard them.
+
+`123` becomes `instanceprefix$345!123` if we use a custom prefix that identifies an instance (so we can merge multiple instances into one ocis instance) and append the numeric storageid `345`. The pattern is `$!`.
+
+Every `$` identifies a space.
+
+- [ ] the owncloudsql driver can return these spaceids when listing spaces.
+
+Why does it not work if we just use the fileid of the root node in the db?
+
+Say we have a space with three resources:
+`$!`
+`instanceprefix$345!1`
+`instanceprefix$345!2`
+`instanceprefix$345!3`
+
+All users have moved to ocis and the registry contains a regex to route all `instanceprefix.*` references to the storageprovider with the owncloudsql driver. It is up to the driver to locate the correct resource by using the filecache table. In this case the numeric storage id is unnecessary.
+
+Now we migrate the space `345` to another storage driver:
+- the storage registry contains a new entry for `instanceprefix$345` to send all resource ids for that space to the new storage provider
+- the new storage driver has to take into account the full storageid because the nodeid may only be unique per storage space.
+
+If we now have to fetch the path on the `/dav/meta/` endpoint:
+`/dav/meta/instanceprefix$345!1`
+`/dav/meta/instanceprefix$345!2`
+`/dav/meta/instanceprefix$345!3`
+
+This would work because the registry always sees `instanceprefix$345` as the storageid.
+
+Now if we use the fileids directly and leave out the numeric storageid:
+`!`
+`instanceprefix!1`
+`instanceprefix!2`
+`instanceprefix!3`
+
+This is the current `!` format.
+
+The reva storage registry contains a `instanceid` entry pointing to the storage provider with the owncloudsql driver.
+
+Resources can be looked up because the oc_filecache has a unique fileid over all storages.
+
+Now we again migrate the space `345` to another storage driver:
+- the storage registry contains a new entry for `instanceprefix!1` so the storage space root now points to the new storage provider
+- The registry needs to be aware of node ids to route properly. This is a no-go. We don't want to keep a cache of _all_ nodeids in the registry. Only the root nodes of spaces.
+- The new storage driver only has a nodeid which might collide with other nodeids from other storage spaces, e.g. when two instances are imported into one ocis instance. Although it would be possible to just set up two storage providers extra care would have to be taken to prevent nodeid collisions when importing a space.
+
+If we now have to fetch the path on the `/dav/meta/` endpoint:
+`/dav/meta/instanceprefix!1` would work because it is the root of a space
+`/dav/meta/instanceprefix!2` would cause the gateway to poll all storage providers because the registry has no way to determine the responsible storage provider
+`/dav/meta/instanceprefix!3` same
+
+The problem is that without a part in the storageid that allows differentiating storage spaces we cannot route them individually.
+
+Now, we could use the nodeid of the root of a storage space as the spaceid ... if it is a uuid. If it is numeric it needs a prefix to distinguish it from other spaces.
+`!` would be easy for the decomposedfs.
+eos might use numeric ids: `$!`, but it needs a custom prefix to distinguish multiple eos instances.
+
+Furthermore, when migrating spaces between storage providers we want to stay collision free, which is why we should recommend uuids.
+
+All this has implications for the decomposedfs, because it needs to split the nodes per space to prevent them from colliding.
diff --git a/modules/developer/pages/ocis/storage/spaces.adoc b/modules/developer/pages/ocis/storage/spaces.adoc
new file mode 100644
index 00000000..fe2755a0
--- /dev/null
+++ b/modules/developer/pages/ocis/storage/spaces.adoc
@@ -0,0 +1,212 @@
+= Spaces
+:toc: right
+:toclevels: 3
+
+
+== Editing a Storage Space
+
+The OData specification allows for a mirage of ways of addressing an entity. We will support addressing a Drive entity by its unique identifier, which is the one the graph-api returns when listing spaces, and its format is:
+
+[source,json]
+----
+{
+ "id": "1284d238-aa92-42ce-bdc4-0b0000009157!b6e2c9cc-9dbe-42f0-b522-4f2d3e175e9c"
+}
+----
+
+This is an extract of an element of the list spaces response. An entire object has the following shape:
+
+[source,json]
+----
+{
+ "driveType": "project",
+ "id": "1284d238-aa92-42ce-bdc4-0b0000009157!b6e2c9cc-9dbe-42f0-b522-4f2d3e175e9c",
+ "lastModifiedDateTime": "2021-10-07T11:06:43.245418+02:00",
+ "name": "marketing",
+ "owner": {
+ "user": {
+ "id": "ddc2004c-0977-11eb-9d3f-a793888cd0f8"
+ }
+ },
+ "quota": {
+ "total": 65536
+ },
+ "root": {
+ "id": "1284d238-aa92-42ce-bdc4-0b0000009157!b6e2c9cc-9dbe-42f0-b522-4f2d3e175e9c",
+ "webDavUrl": "https://localhost:9200/dav/spaces/1284d238-aa92-42ce-bdc4-0b0000009157!b6e2c9cc-9dbe-42f0-b522-4f2d3e175e9c"
+ }
+}
+----
+
+=== Updating a space property
+
+Having introduced the above, one can refer to a Drive with the following URL format:
+
+[source,console]
+----
+'https://localhost:9200/graph/v1.0/drives/1284d238-aa92-42ce-bdc4-0b0000009157!07c26b3a-9944-4f2b-ab33-b0b326fc7570
+----
+
+Updating an entity attribute:
+
+[source,console]
+----
+curl -X PATCH 'https://localhost:9200/graph/v1.0/drives/1284d238-aa92-42ce-bdc4-0b0000009157!07c26b3a-9944-4f2b-ab33-b0b326fc7570' -d '{"name":"42"}' -v
+----
+
+The previous URL resource path segment (`1284d238-aa92-42ce-bdc4-0b0000009157!07c26b3a-9944-4f2b-ab33-b0b326fc7570`) is parsed and handed over to the storage registry in order to apply the patch changes in the body, in this case update the space name attribute to `42`. Since space names are not unique we only support addressing them by their unique identifiers, any other query would render too ambiguous and explode in complexity.
+
+
+=== Updating a space description
+
+Since every space is the root of a webdav directory, following some conventions we can make use of this to set a default storage description and image. In order to do so, every space is created with a hidden `.space` folder at its root, which can be used to store such data.
+
+[source,curl]
+----
+curl -k -X PUT https://localhost:9200/dav/spaces/1284d238-aa92-42ce-bdc4-0b0000009157\!07c26b3a-9944-4f2b-ab33-b0b326fc7570/.space/description.md -d "Add a description to your spaces" -u admin:admin
+----
+
+Verify the description was updated:
+
+[source,curl]
+----
+❯ curl -k https://localhost:9200/dav/spaces/1284d238-aa92-42ce-bdc4-0b0000009157\!07c26b3a-9944-4f2b-ab33-b0b326fc7570/.space/description.md -u admin:admin
+Add a description to your spaces
+----
+
+This feature makes use of the internal storage layout and is completely abstracted from the end user.
+
+=== Quotas
+
+Spaces capacity (quota) is independent of the Storage quota. As a Space admin you can set the quota for all users of a space, and as such, there are no limitations and is up to the admin to make a correct use of this.
+
+It is possible to have a space quota greater than the storage quota. A Space may also have "infinite" quota, meaning a single space without quota can occupy the entirety of a disk.
+
+==== Quota Enforcement
+
+Creating a Space with a quota of 10 bytes:
+
+`curl -k -X POST 'https://localhost:9200/graph/v1.0/drives' -u admin:admin -d '{"name":"marketing", "quota": {"total": 10}}' -v`
+
+[source,console]
+----
+/var/tmp/ocis/storage/users
+├── blobs
+├── nodes
+│ ├── 627981c2-2a71-4adf-b680-177e245afdda
+│ ├── 9541e7c3-8fda-4b49-b697-e7e51457cf5a
+│ ├── b5692345-108d-4b80-9747-3a7e9739ad57
+│ └── root
+│ ├── 118351d7-67a4-4cdf-b495-6093d1e572ed -> ../627981c2-2a71-4adf-b680-177e245afdda
+│ └── ddc2004c-0977-11eb-9d3f-a793888cd0f8 -> ../b5692345-108d-4b80-9747-3a7e9739ad57
+├── spaces
+│ ├── personal
+│ │ └── b5692345-108d-4b80-9747-3a7e9739ad57 -> ../../nodes/b5692345-108d-4b80-9747-3a7e9739ad57
+│ ├── project
+│ │ └── 627981c2-2a71-4adf-b680-177e245afdda -> ../../nodes/627981c2-2a71-4adf-b680-177e245afdda
+│ └── share
+├── trash
+└── uploads
+----
+
+Verify the new space has 10 bytes, and none of it is used:
+
+[source,json]
+----
+{
+ "driveType": "project",
+ "id": "1284d238-aa92-42ce-bdc4-0b0000009157!627981c2-2a71-4adf-b680-177e245afdda",
+ "lastModifiedDateTime": "2021-10-15T11:16:26.029188+02:00",
+ "name": "marketing",
+ "owner": {
+ "user": {
+ "id": "ddc2004c-0977-11eb-9d3f-a793888cd0f8"
+ }
+ },
+ "quota": {
+ "remaining": 10,
+ "total": 10,
+ "used": 0
+ },
+ "root": {
+ "id": "1284d238-aa92-42ce-bdc4-0b0000009157!627981c2-2a71-4adf-b680-177e245afdda",
+ "webDavUrl": "https://localhost:9200/dav/spaces/1284d238-aa92-42ce-bdc4-0b0000009157!627981c2-2a71-4adf-b680-177e245afdda"
+ }
+}
+----
+
+Upload a 6 bytes file:
+
+`curl -k -X PUT https://localhost:9200/dav/spaces/1284d238-aa92-42ce-bdc4-0b0000009157\!627981c2-2a71-4adf-b680-177e245afdda/6bytes.txt -d "012345" -u admin:admin -v`
+
+Query the quota again:
+
+[source,json]
+----
+{
+ "quota": {
+ "remaining": 4,
+ "total": 10,
+ "used": 6
+ }
+}
+----
+
+Now attempt to upload 5 bytes to the space:
+
+`curl -k -X PUT https://localhost:9200/dav/spaces/1284d238-aa92-42ce-bdc4-0b0000009157\!627981c2-2a71-4adf-b680-177e245afdda/5bytes.txt -d "01234" -u admin:admin -v`
+
+The request will fail with `507 Insufficient Storage`:
+
+----
+ HTTP/1.1 507 Insufficient Storage
+< Access-Control-Allow-Origin: *
+< Content-Length: 0
+< Content-Security-Policy: default-src 'none';
+< Date: Fri, 15 Oct 2021 09:24:46 GMT
+< Vary: Origin
+< X-Content-Type-Options: nosniff
+< X-Download-Options: noopen
+< X-Frame-Options: SAMEORIGIN
+< X-Permitted-Cross-Domain-Policies: none
+< X-Robots-Tag: none
+<
+* Connection #0 to host localhost left intact
+* Closing connection 0
+----
+
+===== Considerations
+
+- If a Space quota is updated to unlimited, the upper limit is the entire available space on disk
+[WARNING]
+====
+
+The current implementation in oCIS might not yet fully reflect this concept. Feel free to add links to ADRs, PRs and Issues in short warning boxes like this.
+
+====
+
+
+== Storage Spaces
+A storage _space_ is a logical concept. It organizes a set of xref:#resources.adoc[_resources_] in a hierarchical tree. It has a single _owner_ (_user_ or _group_),
+a _quota_, _permissions_ and is identified by a `storage space id`.
+
+image::ocis/storage/storagespace.drawio.svg[]
+
+Examples would be every user's personal storage _space_, project storage _spaces_ or group storage _spaces_. While they all serve different purposes and may or may not have workflows like antivirus scanning enabled, we need a way to identify and manage these subtrees in a generic way. By creating a dedicated concept for them this becomes easier and literally makes the codebase cleaner. A storage xref:./spacesregistry.adoc[_Spaces Registry_] then allows listing the capabilities of storage _spaces_, e.g. free space, quota, owner, syncable, root etag, upload workflow steps, ...
+
+Finally, a logical `storage space id` is not tied to a specific xref:./spacesprovider.adoc[_spaces provider_]. If the xref:./storagedrivers.adoc[_storage driver_] supports it, we can import existing files including their `file id`, which makes it possible to move storage _spaces_ between xref:./spacesprovider.adoc[_spaces providers_] to implement storage classes, e.g. with or without archival, workflows, on SSDs or HDDs.
+
+== Shares
+_To be clarified: we are aware that xref:#storage-spaces.adoc[_storage spaces_] may be too 'heavyweight' for ad hoc sharing with groups. That being said, there is no technical reason why group shares should not be treated like storage xref:#storage-spaces.adoc[_spaces_] that users can provision themselves. They would share the quota with the users home or personal storage xref:#storage-spaces.adoc[_space_] and the share initiator would be the sole owner. Technically, the mechanism of treating a share like a new storage xref:#storage-spaces.adoc[_space_] would be the same. This obviously also extends to user shares and even file individual shares that would be wrapped in a virtual collection. It would also become possible to share collections of arbitrary files in a single storage space, e.g. the ten best pictures from a large album._
+
+== Notes
+
+We can implement link:https://cs3org.github.io/cs3apis/#cs3.storage.provider.v1beta1.ListStorageSpacesRequest[ListStorageSpaces] by either
+- iterating over the root of the storage and treating every folder following the `` as a `home` _storage space_,
+- iterating over the root of the storage and treating every folder following a new `` as a `project` _storage space_, or
+- iterating over the root of the storage and treating every folder following a generic `` as a _storage space_ for a configurable space type, or
+- we allow configuring a map of `space type` to `layout` (based on the link:https://cs3org.github.io/cs3apis/#cs3.storage.provider.v1beta1.CreateStorageSpaceRequest[CreateStorageSpaceRequest]) which would allow things like
+----
+home=/var/lib/ocis/storage/home/{{substr 0 1 .Owner.Username}}/{{.Owner.Username}}
+spaces=/spaces/var/lib/ocis/storage/projects/{{.Name}}
+----
diff --git a/modules/developer/pages/ocis/storage/spacesprovider.adoc b/modules/developer/pages/ocis/storage/spacesprovider.adoc
new file mode 100644
index 00000000..e40eea2d
--- /dev/null
+++ b/modules/developer/pages/ocis/storage/spacesprovider.adoc
@@ -0,0 +1,111 @@
+= Spaces Provider
+:toc: right
+:toclevels: 3
+
+[WARNING]
+====
+
+The current implementation in oCIS might not yet fully reflect this concept. Feel free to add links to ADRs, PRs and Issues in short warning boxes like this.
+
+====
+
+
+== Spaces Provider
+A _storage provider_ manages xref:#resources.adoc[_resources_] identified by a xref:#references.adoc[_reference_]
+by accessing a xref:#storage-systems.adoc[_storage system_] with a xref:./storagedrivers.adoc[_storage driver_].
+
+image::ocis/storage/spacesprovider.drawio.svg[]
+
+
+== Frontend
+
+The oCIS frontend service starts all services that handle incoming HTTP requests:
+- _ocdav_ for ownCloud flavoured WebDAV
+- _ocs_ for sharing, user provisioning, capabilities and other OCS API endpoints
+- _datagateway_ for up and downloads
+- TODO: _ocm_
+
+image::ocis/storage/frontend.drawio.svg[]
+
+=== WebDAV
+
+The ocdav service not only handles all WebDAV requests under `(remote.php/)(web)dav` but also some other legacy endpoints like `status.php`:
+
+| endpoint | service | CS3 api | CS3 namespace | description | TODO |
+|----------|---------|-------------|------|------|------|
+| _ownCloud 10 / current ocis setup:_ |||||
+| `status.php` | ocdav | - | - | currently static | should return compiled version and dynamic values |
+| `(remote.php/)webdav` | ocdav | storageprovider | `/home` | the old webdav endpoint | |
+| `(remote.php/)dav/files/` | ocdav | storageprovider | `/home` | the new webdav endpoint | |
+| `(remote.php/)dav/meta//v` | ocdav | storageprovider | id based | versions | |
+| `(remote.php/)dav/trash-bin/` | ocdav | recycle | - | trash | should aggregate the trash of xref:./terminology.md#storage-spaces.adoc[_storage spaces_] the user has access to |
+| `(remote.php/)dav/public-files/` | ocdav | storageprovider | `/public/` | public links | |
+| `(remote.php/)dav/avatars/` | ocdav | - | - | avatars, hardcoded | look up from user provider and cache |
+| _CernBox setup:_ |||||
+| `(remote.php/)webdav` | ocdav | storageprovider | `/` | | |
+| _Note: existing folder sync pairs in legacy clients will break when moving the user home down in the path hierarchy_ |||||
+| `(remote.php/)webdav/home` | ocdav | storageprovider | `/home` | | |
+| `(remote.php/)webdav/users` | ocdav | storageprovider | `/users` | | |
+| `(remote.php/)dav/files/` | ocdav | storageprovider | `/users/` | | |
+| _Spaces concept also needs a new endpoint:_ |||||
+| `(remote.php/)dav/spaces//` | ocdav | storageregistry & storageprovider | bypass path based namespace and directly talk to the responsible storage provider using a relative path | link:https://github.com/owncloud/ocis/pull/1827[spaces concept] needs to point to storage xref:./spaces.adoc[_spaces_] | allow accessing spaces, listing is done by the graph api |
+
+
+The correct endpoint for a users home storage xref:./spaces.adoc[_space_] in oc10 is `remote.php/dav/files/`. In oc10 all requests at this endpoint use a path based reference that is relative to the users home. In oCIS this can be configured and defaults to `/home` as well. Other API endpoints like ocs and the web UI still expect this to be the users home.
+
+In oc10 we originally had `remote.php/webdav` which would render the current users home xref:./terminology.md#storage-spaces.adoc[_storage space_]. The early versions (pre OC7) would jail all received shares into a `remote.php/webdav/shares` subfolder. The semantics for syncing such a folder are link:https://github.com/owncloud/core/issues/5349[not trivially predictable], which is why we made shares link:https://github.com/owncloud/core/pull/8026[freely mountable] anywhere in the users home.
+
+The current reva implementation jails shares into a `remote.php/webdav/Shares` folder for performance reasons. Obviously, this brings back the link:https://github.com/owncloud/product/issues/7[special semantics for syncing]. In the future we will follow link:https://github.com/owncloud/product/issues/302[a different solution] and jail the received shares into a dedicated `/shares` space, on the same level as `/home` and `/spaces`. We will add a dedicated link:https://github.com/owncloud/ocis/pull/1827[API to list all _storage spaces_] a user has access to and where they are mounted in the users _namespace_.
+
+[WARNING]
+====
+TODO rewrite this hint with `/dav/spaces`
+Existing folder sync pairs in legacy clients will break when moving the user home down in the path hierarchy like CernBox did.
+For legacy clients the `remote.php/webdav` endpoint will no longer list the users home directly, but instead present the different types of storage spaces:
+- `remote.php/webdav/home`: the users home is pushed down into a new `home` xref:./terminology.md#storage-spaces.adoc[_storage space_]
+- `remote.php/webdav/shares`: all mounted shares will be moved to a new `shares` xref:./terminology.md#storage-spaces.adoc[_storage space_]
+- `remote.php/webdav/spaces`: other xref:./terminology.md#storage-spaces.adoc[_storage spaces_] the user has access to, e.g. group or project drives
+====
+
+
+
+=== Sharing
+
+The link:https://doc.owncloud.com/server/developer_manual/core/apis/ocs-share-api.html[OCS Share API] endpoint `/ocs/v1.php/apps/files_sharing/api/v1/shares` returns shares, which have their own share id and reference files using a path relative to the users home. They API also lists the numeric storage id as well as the string type `storage_id` (which is confusing ... but yeah) which would allow constructing combined references with a `storage space id` and a `path` relative to the root of that xref:./terminology.md#storage-spaces.adoc[_storage space_]. The web UI however assumes that it can take the path from the `file_target` and append it to the users home to access it.
+
+// SHORTCODE: {{< hint >}}
+The API link:https://doc.owncloud.com/server/developer_manual/core/apis/ocs-share-api.html#example-request-response-payloads-4[already returns the storage id] (and numeric id) in addition to the file id:
+----
+ home::auser
+ 993
+ 3994486
+ 3994486
+ 3994485
+ /Shared/Paris.jpg
+----
+link:https://doc.owncloud.com/server/developer_manual/core/apis/ocs-share-api.html#function-arguments[Creating shares only takes the _path_ as the argument] so creating and navigating shares only needs the path. When you update or delete a share it takes the `share id` not the `file id`.
+// SHORTCODE: {{< /hint >}}
+
+The OCS service makes a stat request to the storage provider to get a link:https://cs3org.github.io/cs3apis/#cs3.storage.provider.v1beta1.ResourceInfo[ResourceInfo] object. It contains both, a link:https://cs3org.github.io/cs3apis/#cs3.storage.provider.v1beta1.ResourceId[`ResourceId`] _and_ an absolute path. If the _resource_ exists a request is sent to the gateway. Depending on the type of share the link:https://cs3org.github.io/cs3apis/#cs3.sharing.collaboration.v1beta1.CollaborationAPI[Collaboration API], the link:https://cs3org.github.io/cs3apis/#cs3.sharing.link.v1beta1.LinkAPI[Link API] or the link:https://cs3org.github.io/cs3apis/#cs3.sharing.ocm.v1beta1.OcmAPI[Open Cloud Mesh API] endpoints are used.
+
+| API | Request | Resource identified by | Grant type | Further arguments |
+|-----|---------|------------------------|------------|-------------------|
+| Collaboration | link:https://cs3org.github.io/cs3apis/#cs3.sharing.collaboration.v1beta1.CreateShareRequest[CreateShareRequest] | link:https://cs3org.github.io/cs3apis/#cs3.storage.provider.v1beta1.ResourceInfo[ResourceInfo] | link:https://cs3org.github.io/cs3apis/#cs3.sharing.collaboration.v1beta1.ShareGrant[ShareGrant] | - |
+| Link | link:https://cs3org.github.io/cs3apis/#cs3.sharing.link.v1beta1.CreatePublicShareRequest[CreatePublicShareRequest] | link:https://cs3org.github.io/cs3apis/#cs3.storage.provider.v1beta1.ResourceInfo[ResourceInfo] | Link link:https://cs3org.github.io/cs3apis/#cs3.sharing.link.v1beta1.Grant[Grant] | We send the public link `name` in the `ArbitraryMetadata` of the `ResourceInfo` |
+| Open Cloud Mesh | link:https://cs3org.github.io/cs3apis/#cs3.sharing.ocm.v1beta1.CreateOCMShareRequest[CreateOCMShareRequest] | link:https://cs3org.github.io/cs3apis/#cs3.storage.provider.v1beta1.ResourceId[ResourceId] | OCM link:https://cs3org.github.io/cs3apis/#cs3.sharing.ocm.v1beta1.ShareGrant[ShareGrant] | OCM link:https://cs3org.github.io/cs3apis/#cs3.ocm.provider.v1beta1.ProviderInfo[ProviderInfo] |
+
+
+// SHORTCODE: {{< hint >}}
+The user and public share provider implementations identify the file using the link:https://cs3org.github.io/cs3apis/#cs3.storage.provider.v1beta1.ResourceId[`ResourceId`]. The link:https://cs3org.github.io/cs3apis/#cs3.storage.provider.v1beta1.ResourceInfo[`ResourceInfo`] is passed so the share provider can also store who the owner of the resource is. The _path_ is not part of the other API calls, e.g. when listing shares.
+The OCM API takes an id based reference on the CS3 api, even if the OCM HTTP endpoint takes a path argument. _@jfd: Why? Does it not need the owner? It only stores the owner of the share, which is always the currently logged-in user, when creating a share. Afterwards only the owner can update a share ... so collaborative management of shares is not possible. At least for OCM shares._
+// SHORTCODE: {{< /hint >}}
+
+
+== REVA Storage Registry
+
+The reva _storage registry_ manages the xref:./namespaces.md#cs3-global-namespaces.adoc[_CS3 global namespace_]:
+It is used by the reva _gateway_
+to look up `address` and `port` of the xref:#storage-providers.adoc[_storage provider_]
+that should handle a xref:#references.adoc[_reference_].
+
+image::ocis/storage/storageregistry.drawio.svg[]
diff --git a/modules/developer/pages/ocis/storage/spacesregistry.adoc b/modules/developer/pages/ocis/storage/spacesregistry.adoc
new file mode 100644
index 00000000..abdc962c
--- /dev/null
+++ b/modules/developer/pages/ocis/storage/spacesregistry.adoc
@@ -0,0 +1,17 @@
+= Spaces Registry
+:toc: right
+:toclevels: 3
+
+[WARNING]
+====
+
+The current implementation in oCIS might not yet fully reflect this concept. Feel free to add links to ADRs, PRs and Issues in short warning boxes like this.
+
+====
+
+
+== Storage Space Registries
+
+A storage _spaces registry_ manages the xref:./namespaces.adoc[_namespace_] for a _user_: it is used by _clients_ to look up storage spaces a user has access to, the `/dav/spaces` endpoint to access it via WabDAV, and where the client should mount it in the users personal namespace.
+
+image::ocis/storage/spacesregistry.drawio.svg[]
diff --git a/modules/developer/pages/ocis/storage/storagedrivers.adoc b/modules/developer/pages/ocis/storage/storagedrivers.adoc
new file mode 100644
index 00000000..b70f9ea5
--- /dev/null
+++ b/modules/developer/pages/ocis/storage/storagedrivers.adoc
@@ -0,0 +1,203 @@
+= Storage drivers
+:toc: right
+:toclevels: 3
+
+A _storage driver_ implements access to a xref:#storage-systems.adoc[_storage system_]:
+
+It maps the _path_ and _id_ based CS3 _references_ to an appropriate xref:#storage-systems.adoc[_storage system_] specific reference, e.g.:
+- eos file ids
+- posix inodes or paths
+- deconstructed filesystem nodes
+
+== Storage providers
+
+To manage the file tree oCIS uses _storage providers_ that are accessing the underlying storage using a _storage driver_. The driver can be used to change the implementation of a storage aspect to better reflect the actual underlying storage capabilities. As an example a move operation on a POSIX filesystem (link:https://danluu.com/deconstruct-files/[theoretically]) is an atomic operation. When trying to implement a file tree on top of S3 there is no native move operation that can be used. A naive implementation might fall back on a COPY and DELETE. Some S3 implementations provide a COPY operation that uses an existing key as the source, so the file at least does not need to be reuploaded. In the worst case scenario, which is renaming a folder with hundreds of thousands of objects, a reupload for every file has to be made. Instead of hiding this complexity a better choice might be to disable renaming of files or at least folders on S3. There are however implementations of filesystems on top of S3 that store the tree metadata in dedicated objects or use a completely different persistence mechanism like a distributed key value store to implement the file tree aspect of a storage.
+
+
+[NOTE]
+====
+While the _storage provider_ is responsible for managing the tree, file up- and downloads are delegated to a dedicated _data provider_. See below.
+====
+
+
+== Storage aspects
+A lot of different storage technologies exist, ranging from general purpose file systems with POSIX semantics to software defined storage with multiple APIs. Choosing any of them is making a tradeoff decision. Or, if a storage technology is already in place it automatically predetermines the capabilities that can be made available. _Not all storage systems are created equal._
+
+Unfortunately, no POSIX filesystem natively supports all storage aspects that ownCloud 10 requires:
+
+=== A hierarchical file tree
+An important aspect of a filesystem is organizing files and directories in a file hierarchy, or tree. It allows you to create, move and delete nodes. Beside the name a node also has well known metadata like size and mtime that are persisted in the tree as well.
+
+[NOTE]
+====
+_Folders are not directories_
+There is a difference between _folder_ and _directory_: a _directory_ is a file system concept. A _folder_ is a metaphor for the concept of a physical file folder. There are also _virtual folders_ or _smart folders_ like the recent files folder which are no file system _directories_. So, every _directory_ and every _virtual folder_ is a _folder_, but not every _folder_ is a _directory_. See link:https://en.wikipedia.org/wiki/Directory_(computing[the folder metaphor in wikipedia]#Folder_metaphor). Also see the activity history below.
+====
+
+
+==== Id based lookup
+While traditionally nodes in the tree are reached by traversing the path the tree persistence should be prepared to look up a node by an id. Think of an inode in a POSIX filesystem. If this operation needs to be cached for performance reasons keep in mind that cache invalidation is hard and crawling all files to update the inode to path mapping takes O(n), not O(1).
+
+==== ETag propagation
+For the state based sync a client can discover changes by recursively descending the tree and comparing the ETag for every node. If the storage technology supports propagating ETag changes up the tree, only the root node of a tree needs to be checked to determine if a discovery needs to be started and which nodes need to be traversed. This allows using the storage technology itself to persist all metadata that is necessary for sync, without additional services or caches.
+
+==== Subtree size accounting
+The tree can keep track of how many bytes are stored in a folder. Similar to ETag propagation a change in file size is propagated up the hierarchy.
+
+[NOTE]
+====
+_ETag and Size propagation_
+When propagating the ETag (mtime) and size changes up the tree the question is where to stop. If all changes need to be propagated to the root of a storage then the root or busy folders will become a hotspot. There are two things to keep in mind: 1. propagation only happens up to the root of a single space (a user private drive or a single group drive), 2. no cross storage propagation. The latter was used in oc10 to let clients detect when a file in a received shared folder changed. This functionality is moving to the storage registry which caches the ETag for every root so clients can discover if and which storage changed.
+====
+
+
+==== Rename
+Depending on the underlying storage technology some operations may either be slow, up to a point where it makes more sense to disable them entirely. One example is a folder rename: on S3 a _simple_ folder rename translates to a copy and delete operation for every child of the renamed folder. There is an exception though: this restriction only applies if the S3 storage is treated like a filesystem, where the keys are the path and the value is the file content. There are smarter ways to implement file systems on top of S3, but again: there is always a tradeoff.
+
+[NOTE]
+====
+_S3 has no rename_
+Technically, link:https://docs.aws.amazon.com/sdk-for-java/v1/developer-guide/examples-s3-objects.html#copy-object[S3 has no rename operation at all]. By design, the location of the value is determined by the key, so it always has to do a copy and delete. Another example is the link:https://redis.io/commands/rename[redis RENAME operation]: while being specified as O(1) it _executes an implicit DEL operation, so if the deleted key contains a very big value it may cause high latency..._
+====
+
+
+==== Arbitrary metadata persistence
+In addition to well known metadata like name size and mtime, users might be able to add arbitrary metadata like tags, comments or link:https://en.wikipedia.org/wiki/Dublin_Core[dublin core]. In POSIX filesystems this maps to extended attributes.
+
+=== Grant persistence
+The CS3 API uses grants to describe access permissions. Storage systems have a wide range of permissions granularity and not all grants may be supported by every storage driver. POSIX ACLs for example have no expiry. If the storage system does not support certain grant properties, e.g. expiry, then the storage driver may choose to implement them in a different way. Expiries could be persisted in a different way and checked periodically to remove the grants. Again: every decision is a tradeoff.
+
+=== Trash persistence
+After deleting a node the storage allows listing the deleted nodes and has an undo mechanism for them.
+
+=== Versions persistence
+A user can restore a previous version of a file.
+
+[NOTE]
+====
+_Snapshots are not versions_
+Modern POSIX filesystems support snapshotting of volumes. This is different from keeping track of versions to a file or folder, but might be another implementation strategy for a storage driver to allow users to restore content.
+====
+
+
+=== Activity History
+The storage keeps an activity history, tracking the different actions that have been performed. This does not only include file changes but also metadata changes like renames and permission changes.
+
+== Storage drivers
+
+Reva currently has several storage driver implementations that can be used for _storage providers_ as well as _data providers_.
+
+=== OCIS and S3NG Storage Driver
+
+The oCIS storage driver is the default storage driver. It decomposes the metadata and persists it in a POSIX filesystem. Blobs are stored on the filesystem as well. The layout makes extensive use of symlinks and extended attributes. A filesystem like xfs or zfs without practical inode size limitations is recommended. We will evolve this to further integrate with file systems like cephfs or gpfs.
+
+[WARNING]
+====
+Ext4 limits the number of bytes that can be used for extended attribute names and their values to the size of a single block (by default 4k). This reduces the number of shares for a single file or folder to roughly 20-30, as grants have to share the available space with other metadata.
+====
+
+
+The S3NG storage driver uses the same metadata layout on a POSIX storage as the oCIS driver, but it uses S3 as the blob storage.
+
+==== Tradeoffs
+➕ Efficient ID based lookup
+
+➕ Leverages Kernel VFS cache
+
+➕ No database needed
+
+➖ Not intended to be accessed by end users on the server side as it does not reflect a normal filesystem on disk
+
+➖ Metadata limited by Kernel VFS limits (see below)
+
+==== Related Kernel limits
+The Decomposed FS currently stores CS3 grants in extended attributes. When listing extended attributes the result is currently limited to 64kB. Assuming a 20 byte uuid a grant has ~40 bytes. Which would limit the number of extended attributes to ~1630 entries or ~1600 shares. This can be extended by moving the grants from extended attributes into a dedicated file and is tracked in link:https://github.com/owncloud/ocis/issues/4638[ocis/issues/4638].
+
+From link:https://en.wikipedia.org/wiki/Extended_file_attributes#Linux[Wikipedia on Extended file attributes]:
+[quote]
+____
+The Linux kernel allows extended attribute to have names of up to 255 bytes and values of up to 64 KiB,[14] as do XFS and ReiserFS, but ext2/3/4 and btrfs impose much smaller limits, requiring all the attributes (names and values) of one file to fit in one "filesystem block" (usually 4 KiB). Per POSIX.1e,[citation needed] the names are required to start with one of security, system, trusted, and user plus a period. This defines the four namespaces of extended attributes.[15]
+____
+
+
+And from the link:https://www.man7.org/linux/man-pages/man2/listxattr.2.html[man page on listxattr]:
+[quote]
+____
+As noted in xattr(7), the VFS imposes a limit of 64 kB on the size of the extended attribute name list returned by listxattr(7). If the total size of attribute names attached to a file exceeds this limit, it is no longer possible to retrieve the list of attribute names.
+____
+
+
+=== Local Storage Driver
+
+The _minimal_ storage driver for a POSIX based filesystem. It literally supports none of the storage aspect other than basic file tree management. Sharing can - to a degree - be implemented using POSIX ACLs.
+
+- tree provided by a POSIX filesystem
+ - inefficient path by id lookup, currently uses the file path as id, so ids are not stable
+ - can store a uuid in extended attributes and use a cache to look them up, similar to the ownCloud driver
+ - no native ETag propagation, five options are available:
+ - built in propagation (changes bypassing ocis are not picked up until a rescan)
+ - built in inotify (requires 48 bytes of RAM per file, needs to keep track of every file and folder)
+ - external inotify (same RAM requirement, but could be triggered by external tools, e.g. a workflow engine)
+ - kernel audit log (use the linux kernel audit to capture file events on the storage and offload them to a queue)
+ - fuse filesystem overlay
+ - no subtree accounting, same options as for ETag propagation
+ - efficient rename
+ - arbitrary metadata using extended attributes
+- grant persistence
+ - using POSIX ACLs
+ - requires an LDAP server to make guest accounts available in the OS
+ - an existing LDAP could be used if guests ar provisioned in another way
+ - using extended attributes to implement expiry or sharing that does not require OS level integration
+ - fuse filesystem overlay
+- no native trash
+ - could use link:https://specifications.freedesktop.org/trash-spec/trashspec-latest.html[The FreeDesktop.org Trash specification]
+ - fuse filesystem overlay
+- no native versions, multiple options possible
+ - git for folders
+ - rcs for single files
+ - rsnapshot for hourly / daily / weekly / monthly backups ... but this is not versioning as known from oc10
+ - design new freedesktop spec, basically what is done in oc10 without the limitations or borrow ideas from the freedesktop trash spec
+ - fuse filesystem overlay
+
+To provide the other storage aspects we plan to implement a FUSE overlay filesystem which will add the different aspects on top of local filesystems like ext4, btrfs or xfs. It should work on NFSv4 as well, although NFSv4 supports RichACLs and we will explore how to leverage them to implement sharing at a future date. The idea is to use the storages native capabilities to deliver the best user experience. But again: that means making the right tradeoffs.
+
+=== EOS Storage Driver
+
+The CERN eos storage has evolved with ownCloud and natively supports id based lookup, ETag propagation, subtree size accounting, sharing, trash and versions. To use it you need to change the default configuration of the `storage storage-home` command (or have a look at the Makefile ̀ eos-start` target):
+
+----
+export STORAGE_DRIVER_EOS_NAMESPACE=/eos
+export STORAGE_DRIVER_EOS_MASTER_URL="root://eos-mgm1.eoscluster.cern.ch:1094"
+export STORAGE_DRIVER_EOS_ENABLE_HOME=true
+export STORAGE_DRIVER_EOS_LAYOUT="dockertest/{{.Username}}"
+----
+
+Running it locally also requires the `eos` and `xrootd` binaries. Running it using `make eos-start` will use CentOS based containers that already have the necessary packages installed.
+
+[NOTE]
+====
+Pull requests to add explicit `storage storage-(s3|custom|...)` commands with working defaults are welcome.
+====
+
+
+=== S3 Storage Driver
+
+A naive driver that treats the keys in an S3 capable storage as `/` delimited path names. While it does not support MOVE or ETag propagation it can be used to read and write files. Better integration with native capabilities like versioning is possible but depends on the Use Case. Several storage solutions that provide an S3 interface also support some form of notifications that can be used to implement ETag propagation.
+
+== Data Providers
+
+Clients using the CS3 API use an link:https://cs3org.github.io/cs3apis/#cs3.storage.provider.v1beta1.InitiateFileDownloadRequest[InitiateFileDownload] and link:https://cs3org.github.io/cs3apis/#cs3.storage.provider.v1beta1.InitiateFileUploadRequest[InitiateUpload] request at the link:https://cs3org.github.io/cs3apis/#cs3.gateway.v1beta1.GatewayAPI[storage gateway] to obtain a URL endpoint that can be used to either GET the file content or upload content using the resumable link:https://tus.io[tus.io] protocol.
+
+The _data provider_ uses the same _storage driver_ as the _storage provider_ but can be scaled independently.
+
+The dataprovider allows uploading the file to a quarantine area where further data analysis may happen before making the file accessible again. One use case for this is antivirus scanning for files coming from untrusted sources.
+
+== Future work
+
+=== FUSE overlay filesystem
+We are planning to further separate the concerns and use a local storage provider with a FUSE filesystem overlaying the actual POSIX storage that can be used to capture deletes and writes that might happen outside of ocis/reva.
+
+It would allow us to extend the local storage driver with missing storage aspects while keeping a tree like filesystem that end users are used to see when sshing into the machine.
+
+=== Upload to Quarantine area
+Antivirus scanning of random files uploaded from untrusted sources and executing metadata extraction or thumbnail generation should happen in a sandboxed system to prevent malicious users from gaining any information about the system. By spawning a new container with access to only the uploaded data we can further limit the attack surface.
diff --git a/modules/developer/pages/ocis/storage/terminology.adoc b/modules/developer/pages/ocis/storage/terminology.adoc
new file mode 100644
index 00000000..13f04869
--- /dev/null
+++ b/modules/developer/pages/ocis/storage/terminology.adoc
@@ -0,0 +1,99 @@
+= Terminology
+:toc: right
+:toclevels: 3
+
+Communication is hard. And clear communication is even harder. You may encounter the following terms throughout the documentation, in the code or when talking to other developers. Just keep in mind that whenever you hear or read _storage_, that term needs to be clarified, because on its own it is too vague. PR welcome.
+
+== Logical concepts
+
+=== Resources
+A _resource_ is the basic building block that oCIS manages. It can be of link:https://cs3org.github.io/cs3apis/#cs3.storage.provider.v1beta1.ResourceType[different types]:
+- an actual _file_
+- a _container_, e.g. a folder or bucket
+- a _symlink_, or
+- a xref:#references.adoc[_reference_] which can point to a resource in another xref:#storage-providers.adoc[_storage provider_]
+
+=== References
+A _reference_ identifies a xref:#resources.adoc[_resource_]. A link:https://cs3org.github.io/cs3apis/#cs3.storage.provider.v1beta1.Reference[_CS3 reference_] can carry a _path_ and a link:https://cs3org.github.io/cs3apis/#cs3.storage.provider.v1beta1.ResourceId[CS3 _resource id_]. The references come in two flavors: absolute and combined.
+Absolute references have either the _path_ or the _resource id_ set:
+- An absolute _path_ MUST start with a `/`. The _resource id_ MUST be empty.
+- An absolute _resource id_ uniquely identifies a xref:#resources.adoc[_resource_] and is used as a stable identifier for sharing. The _path_ MUST be empty.
+Combined references have both, _path_ and _resource id_ set:
+- the _resource id_ identifies the root xref:#resources.adoc[_resource_]
+- the _path_ is relative to that root. It MUST start with `.`
+== References
+
+A _reference_ is a logical concept that identifies a xref:#resources.adoc[_resource_]. A link:https://cs3org.github.io/cs3apis/#cs3.storage.provider.v1beta1.Reference[_CS3 reference_] consists of either
+- a _path_ based reference, used to identify a xref:#resources.adoc[_resource_] in the xref:./namespaces.adoc[_namespace_] of a xref:#storage-providers.adoc[_storage provider_]. It must start with a `/`.
+- a link:https://cs3org.github.io/cs3apis/#cs3.storage.provider.v1beta1.ResourceId[CS3 _id_ based reference], uniquely identifying a xref:#resources.adoc[_resource_] in the xref:./namespaces.adoc[_namespace_] of a xref:#storage-providers.adoc[_storage provider_]. It consists of a `storage provider id` and an `opaque id`. The `storage provider id` must NOT start with a `/`.
+
+[NOTE]
+====
+The `/` is important because currently the static xref:#storage-space-registries.adoc[_storage registry_] uses a map to look up which xref:#storage-providers.adoc[_storage provider_] is responsible for the resource. Paths must be prefixed with `/` so there can be no collisions between paths and storage provider ids in the same map.
+====
+
+
+== Storage Drivers
+
+A _storage driver_ implements access to a xref:#storage-systems.adoc[_storage system_]:
+
+It maps the _path_ and _id_ based CS3 _references_ to an appropriate xref:#storage-systems.adoc[_storage system_] specific reference, e.g.:
+- eos file ids
+- posix inodes or paths
+- deconstructed filesystem nodes
+
+[WARNING]
+====
+_Proposed Change_
+iOS clients can only queue single requests to be executed in the background. The queue an upload and need to be able to identify the uploaded file after it has been uploaded to the server. The disconnected nature of the connection might cause workflows or manual user interaction with the file on the server to move the file to a different place or changing the content while the device is offline. However, on the device users might have marked the file as favorite or added it to other iOS specific collections. To be able to reliably identify the file the client can generate a `uuid` and attach it to the file metadata during the upload. While it is not necessary to look up files by this `uuid` having a second file id that serves exactly the same purpose as the `file id` is redundant.
+
+Another aspect for the `file id` / `uuid` is that it must be a logical identifier that can be set, at least by internal systems. Without a writeable fileid we cannot restore backups or migrate storage spaces from one storage provider to another storage provider.
+
+Technically, this means that every storage driver needs to have a map of a `uuid` to in internal resource identifier. This internal resource identifier can be
+- an eos fileid, because eos can look up files by id
+- an inode if the filesystem and the storage driver support looking up by inode
+- a path if the storage driver has no way of looking up files by id.
+ - In this case other mechanisms like inotify, kernel audit or a fuse overlay might be used to keep the paths up to date.
+ - to prevent excessive writes when deep folders are renamed a reverse map might be used: it will map the `uuid` to `:`, allowing to trade writes for reads
+
+====
+
+== Storage Providers
+
+== Technical concepts
+
+=== Storage Systems
+image::ocis/storage/storageprovider.drawio.svg[]
+
+A _storage provider_ manages multiple xref:#storage-space.adoc[_storage spaces_]
+by accessing a xref:#storage-systems.adoc[_storage system_] with a xref:#storage-drivers.adoc[_storage driver_].
+
+image::ocis/storage/storageprovider-spaces.drawio.svg[]
+
+== Storage Space Registries
+
+A xref:./spacesregistry.adoc[_storage spaces registry_] manages the xref:./namespaces.adoc[_namespace_] for a _user_
+
+== Storage Spaces
+A _storage space_ is a logical concept:
+It is a tree of xref:#resources.adoc[_resources_]_resources_
+with a single _owner_ (_user_ or _group_),
+a _quota_ and _permissions_, identified by a `storage space id`.
+
+image::ocis/storage/storagespace.drawio.svg[]
+
+Examples would be every user's home storage space, project storage spaces or group storage spaces. While they all serve different purposes and may or may not have workflows like antivirus scanning enabled, we need a way to identify and manage these subtrees in a generic way. By creating a dedicated concept for them this becomes easier and literally makes the codebase cleaner. A xref:#storage-space-registries.adoc[_storage space registry_] then allows listing the capabilities of xref:#storage-spaces.adoc[_storage spaces_], e.g. free space, quota, owner, syncable, root etag, upload workflow steps, ...
+
+Finally, a logical `storage space id` is not tied to a specific xref:#storage-providers.adoc[_storage provider_]. If the xref:#storage-drivers.adoc[_storage driver_] supports it, we can import existing files including their `file id`, which makes it possible to move xref:#storage-spaces.adoc[_storage spaces_] between xref:#storage-providers.adoc[_storage providers_] to implement storage classes, e.g. with or without archival, workflows, on SSDs or HDDs.
+
+== Shares
+_To be clarified: we are aware that xref:#storage-spaces.adoc[_storage spaces_] may be too 'heavyweight' for ad hoc sharing with groups. That being said, there is no technical reason why group shares should not be treated like xref:#storage-spaces.adoc[_storage spaces_] that users can provision themselves. They would share the quota with the users home xref:#storage-spaces.adoc[_storage space_] and the share initiator would be the sole owner. Technically, the mechanism of treating a share like a new xref:#storage-spaces.adoc[_storage space_] would be the same. This obviously also extends to user shares and even file individual shares that would be wrapped in a virtual collection. It would also become possible to share collections of arbitrary files in a single storage space, e.g. the ten best pictures from a large album._
+
+
+== Storage Systems
+Every _storage system_ has different native capabilities like id and path based lookups, recursive change time propagation, permissions, trash, versions, archival and more.
+A xref:#storage-providers.adoc[_storage provider_] makes the storage system available in the CS3 API by wrapping the capabilities as good as possible using a xref:./storagedrivers.adoc[_storage driver_].
+There might be multiple xref:./storagedrivers.adoc[_storage drivers_] for a _storage system_, implementing different tradeoffs to match varying requirements.
+
+=== Gateways
+A _gateway_ acts as a facade to the storage related services. It authenticates and forwards API calls that are publicly accessible.
diff --git a/modules/developer/pages/ocis/storage/users.adoc b/modules/developer/pages/ocis/storage/users.adoc
new file mode 100644
index 00000000..7c3eab74
--- /dev/null
+++ b/modules/developer/pages/ocis/storage/users.adoc
@@ -0,0 +1,61 @@
+= Users
+:toc: right
+:toclevels: 3
+
+TODO add this to the storage overview? or is this a different part? That should be started as a separate service ? And documented elsewhere, e.g. in the accounts?
+
+=== User and Group provisioning
+
+In oc10 users are identified by a username, which cannot change, because it is used as a foreign key in several tables. For oCIS we are internally identifying users by a UUID, while using the username in the WebDAV and OCS APIs for backwards compatability. To distinguish this in the URLs we are using `` instead of ``. You may have encountered ``, which refers to a template that can be configured to build several path segments by filling in user properties, e.g. the first character of the username (`{{substr 0 1 .Username}}/{{.Username}}`), the identity provider (`{{.Id.Idp}}/{{.Username}}`) or the email (`{{.Mail}}`)
+
+[WARNING]
+====
+Make no mistake, the link:https://doc.owncloud.com/server/developer_manual/core/apis/provisioning-api.html[OCS Provisioning API] uses `userid` while it actually is the username, because it is what you use to login.
+====
+
+
+We are currently working on adding link:https://github.com/owncloud/ocis/pull/1930[user management through the CS3 API] to handle user and group provisioning (and deprovisioning).
+
+=== Demo driver
+
+This is a simple user driver for testing. It contains three users:
+----
+einstein:relativity
+marie:radioactivity
+richard:superfluidity
+----
+In order to use the `demo` driver you need to export the relevant environment variable:
+----
+export STORAGE_USERS_DRIVER=demo
+----
+
+=== JSON driver
+
+In order to switch from the `ldap` driver to JSON based users you need to export the relevant environment variables:
+----
+export STORAGE_USERS_DRIVER=json
+export STORAGE_USERS_JSON=/path/to/users.json
+----
+
+For the format of the users.json have a look at the link:https://github.com/cs3org/reva/blob/master/examples/oc-phoenix/users.demo.json[reva examples]
+
+=== LDAP driver
+
+This is the default user driver.
+
+If the following defaults don't match your environment then change them accordingly:
+----
+export STORAGE_LDAP_HOSTNAME=localhost
+export STORAGE_LDAP_PORT=9126
+export STORAGE_LDAP_BASE_DN='dc=ocis,dc=test'
+export STORAGE_LDAP_USER_FILTER='(&(objectclass=posixAccount)(cn=%s))'
+export STORAGE_LDAP_GROUP_FILTER='(&(objectclass=posixGroup)(cn=%s))'
+export STORAGE_LDAP_BIND_DN='cn=reva,ou=sysusers,dc=ocis,dc=test'
+export STORAGE_LDAP_BIND_PASSWORD=reva
+export STORAGE_LDAP_USER_SCHEMA_UID=uid
+export STORAGE_LDAP_USER_SCHEMA_MAIL=mail
+export STORAGE_LDAP_USER_SCHEMA_DISPLAYNAME=sn
+export STORAGE_LDAP_USER_SCHEMA_CN=cn
+----
+
+Then restart the `bin/storage users` and `bin/storage auth-basic` services for the changes to take effect.
diff --git a/modules/developer/pages/ocis/storage_registry_discovery.adoc b/modules/developer/pages/ocis/storage_registry_discovery.adoc
new file mode 100644
index 00000000..3fa16c5e
--- /dev/null
+++ b/modules/developer/pages/ocis/storage_registry_discovery.adoc
@@ -0,0 +1,104 @@
+= Storage Registry Discovery
+:toc: right
+:toclevels: 3
+
+== Introduction
+
+In order for an oCIS client to access oCIS storage spaces for an End-User, the client needs to know where the oCIS instance is. oCIS uses WebFinger link:http://tools.ietf.org/html/rfc7033[RFC7033] to locate the oCIS instance for an End-User.
+
+This discovery is optional. If the client has another way of discovering the OpenID instance, e.g. when logging in with a username a static domain might be configured or the domain in the URL might be used.
+
+For guest accounts that do not have an OIDC issuer or whose IdP is not part of a trusted federation clients may fall back to a local IdP.
+
+== User Input using E-Mail Address Syntax
+
+To find the oCIS instance for the given user input in the form of an e-mail address `joe@example.com`, the WebFinger parameters are as follows:
+
+| WebFinger Parameter | Value |
+|-|-|
+| `resource` | `acct:joe@example.com` |
+| `host` | `example.com` |
+| `rel` | http://owncloud.com/specs/ocis/1.0/instance |
+
+Note that in this case, link:http://tools.ietf.org/html/draft-ietf-appsawg-acct-uri-07[the `acct:` scheme] is prepended to the identifier.
+
+The client (relying party) would make the following WebFinger request to discover the oCIS instance location (with line wraps within lines for display purposes only):
+
+----
+ GET /.well-known/webfinger
+ ?resource=acct%3Ajoe%40example.com
+ &rel=http%3A%2F%2Fowncloud.com%2Fspecs%2Focis%2F1.0%2Finstance
+ HTTP/1.1
+ Host: example.com
+
+ HTTP/1.1 200 OK
+ Content-Type: application/jrd+json
+
+ {
+ "subject": "acct:joe@example.com",
+ "links":
+ [
+ {
+ "rel": "http://owncloud.com/specs/ocis/1.0/instance",
+ "href": "https://cloud.example.com"
+ }
+ ]
+ }
+----
+
+// SHORTCODE: {{< hint >}}
+Note: the `example.com` domain is derived from the email.
+// SHORTCODE: {{< /hint >}}
+
+[CAUTION]
+====
+The `https://cloud.example.com` domain above would point to the ocis instance.
+TODO that ins ocis web ... not the registry ... hmmmm
+maybe introduce an ocis provider which then has an `/.well-known/ocis-configuration`, similar to `/.well-known/openid-configuration`?
+It would contain
+- the ocis domain, e.g. `https://cloud.example.com`
+- the web endpoint, e.g. `https://cloud.example.com`
+- the registry / drives endpoint, e.g. `https://cloud.example.com/graph/v0.1/drives/me` see link:https://github.com/owncloud/ocis/pull/1827[Add draft of adr for spaces API. #1827]
+
+
+example:
+----
+HTTP/1.1 200 OK
+ Content-Type: application/json
+
+ {
+ "instance": "https://cloud.example.com",
+ "graph_endpoint": "https://cloud.example.com/graph/v0.0",
+ "ocis_web_config": "https://cloud.example.com/web/config.json",
+ "issuer": "https://idp.example.com",
+ }
+----
+
+`graph_endpoint` is the open-graph-api endpoint that is used to list storage spaces at e.g. `https://cloud.example.com/graph/v0.1/me/drives`.
+
+`ocis_web_config` points ocis web to the config for the instance. Maybe we can add more config in the `/.well-known/ocis-configuration` to replace the config.json? Is this the new status.php? How safe is it to expose all this info ...?
+
+The `issuer` could be used to detect the issuer that is used if no other issuer is found ... might be a fallback_issuer, but actually we may decide to skid the OIDC discovery and rely on this property. Maybe we need it if no IdP is present yet or the `/.well-known/openid-configuration` is not set up / reachable.
+
+
+====
+
+
+== Obtaining oCIS Provider Configuration Information
+Using the `instance` location discovered as described above or by other means, the oCIS Provider's configuration information can be retrieved.
+
+oCIS Providers supporting Discovery MUST make a JSON document available at the path formed by concatenating the string `/.well-known/openid-configuration` to the `instance`. The syntax and semantics of `.well-known` are defined in link:http://tools.ietf.org/html/rfc5785[RFC5785] and apply to the `instance` value when it contains no path component. `ocis-configuration` MUST point to a JSON document compliant with this specification and MUST be returned using the `application/json` content type.
+
+=== oCIS Provider Configuration Request
+
+An oCIS Provider Configuration Document MUST be queried using an HTTP GET request at the previously specified path.
+
+The client (relying party) would make the following request to the instance https://example.com to obtain its Configuration information, since the Issuer contains no path component:
+
+ GET /.well-known/openid-configuration HTTP/1.1
+ Host: example.com
+If the Issuer value contains a path component, any terminating / MUST be removed before appending /.well-known/openid-configuration. The RP would make the following request to the Issuer https://example.com/issuer1 to obtain its Configuration information, since the Issuer contains a path component:
+
+ GET /issuer1/.well-known/openid-configuration HTTP/1.1
+ Host: example.com
+Using path components enables supporting multiple issuers per host. This is required in some multi-tenant hosting configurations. This use of .well-known is for supporting multiple issuers per host; unlike its use in RFC 5785 [RFC5785], it does not provide general information about the host.
\ No newline at end of file
diff --git a/modules/developer/pages/service-independent/index.adoc b/modules/developer/pages/service-independent/index.adoc
new file mode 100644
index 00000000..20706acb
--- /dev/null
+++ b/modules/developer/pages/service-independent/index.adoc
@@ -0,0 +1,6 @@
+= Service Independent Settings
+:toc: right
+:toclevels: 3
+
+
+Some components programmed are not bound to a service but are valid for all of ocis. These are for example environment variables that are used before any service gets started. For ocis CLI commands that are service independent, see the xref:../cli-commands/service_independent_cli.adoc[Service Independent CLI] documentation.
diff --git a/modules/developer/pages/service-independent/service_independent_envvars.adoc b/modules/developer/pages/service-independent/service_independent_envvars.adoc
new file mode 100644
index 00000000..b593102f
--- /dev/null
+++ b/modules/developer/pages/service-independent/service_independent_envvars.adoc
@@ -0,0 +1,37 @@
+= Service Independent Envvars
+:toc: right
+:toclevels: 3
+
+The following environment variables are service independent. You will find the respective code in the `ocis-pkg/` directory. See the link:https://doc.owncloud.com/ocis/7.3/deployment/services/env-vars-special-scope.html[Admin Documentation - Environment Variables with Special Scopes] for a comprehensive list and explanation.
+
+
+[NOTE]
+====
+See the xref:../services/general-info/envvars/.adoc[Environment Variables] documentation for common and important details on envvars.
+====
+
+
+== Service Registry
+
+This package configures the service registry which will be used to look up for example the service addresses.
+
+Available registries are:
+
+- nats-js-kv (default)
+- memory
+
+To configure which registry to use, you have to set the environment variable `MICRO_REGISTRY`, and for all except `memory` you also have to set the registry address via `MICRO_REGISTRY_ADDRESS` and other envvars.
+
+== Startup Related Envvars
+
+These envvars define the startup of ocis and can for example add or remove services from the startup process such as `OCIS_ADD_RUN_SERVICES`.
+
+== Memory Limits
+
+[NOTE]
+====
+Note that this envvar is for development purposes only and not described in the admin docs.
+====
+
+
+oCIS will automatically set the go native `GOMEMLIMIT` to `0.9`. To disable the limit set `AUTOMEMLIMIT=off`. For more information take a look at the official link:https://go.dev/doc/gc-guide[Guide to the Go Garbage Collector].
diff --git a/modules/developer/pages/services/antivirus/configuration.adoc b/modules/developer/pages/services/antivirus/configuration.adoc
new file mode 100644
index 00000000..9cbf78c5
--- /dev/null
+++ b/modules/developer/pages/services/antivirus/configuration.adoc
@@ -0,0 +1,13 @@
+= Service Configuration
+:toc: right
+:toclevels: 3
+
+== Example YAML Config
+
+// AUTO-GENERATED CONTENT: services/_includes/antivirus-config-example.yaml
+[source,yaml]
+----
+// Include from: services/_includes/antivirus-config-example.yaml
+----
+
+// AUTO-GENERATED CONTENT: services/_includes/antivirus_configvars.md
diff --git a/modules/developer/pages/services/app-provider/configuration.adoc b/modules/developer/pages/services/app-provider/configuration.adoc
new file mode 100644
index 00000000..0c6e4bb0
--- /dev/null
+++ b/modules/developer/pages/services/app-provider/configuration.adoc
@@ -0,0 +1,13 @@
+= Service Configuration
+:toc: right
+:toclevels: 3
+
+== Example YAML Config
+
+// AUTO-GENERATED CONTENT: services/_includes/app-provider-config-example.yaml
+[source,yaml]
+----
+// Include from: services/_includes/app-provider-config-example.yaml
+----
+
+// AUTO-GENERATED CONTENT: services/_includes/app-provider_configvars.md
diff --git a/modules/developer/pages/services/app-provider/index.adoc b/modules/developer/pages/services/app-provider/index.adoc
new file mode 100644
index 00000000..74d27518
--- /dev/null
+++ b/modules/developer/pages/services/app-provider/index.adoc
@@ -0,0 +1,9 @@
+= App-Provider
+:toc: right
+:toclevels: 3
+
+== Abstract
+
+
+== Table of Contents
+
diff --git a/modules/developer/pages/services/app-registry/configuration.adoc b/modules/developer/pages/services/app-registry/configuration.adoc
new file mode 100644
index 00000000..749e1ab4
--- /dev/null
+++ b/modules/developer/pages/services/app-registry/configuration.adoc
@@ -0,0 +1,13 @@
+= Service Configuration
+:toc: right
+:toclevels: 3
+
+== Example YAML Config
+
+// AUTO-GENERATED CONTENT: services/_includes/app-registry-config-example.yaml
+[source,yaml]
+----
+// Include from: services/_includes/app-registry-config-example.yaml
+----
+
+// AUTO-GENERATED CONTENT: services/_includes/app-registry_configvars.md
diff --git a/modules/developer/pages/services/audit/configuration.adoc b/modules/developer/pages/services/audit/configuration.adoc
new file mode 100644
index 00000000..9f8491d5
--- /dev/null
+++ b/modules/developer/pages/services/audit/configuration.adoc
@@ -0,0 +1,13 @@
+= Service Configuration
+:toc: right
+:toclevels: 3
+
+== Example YAML Config
+
+// AUTO-GENERATED CONTENT: services/_includes/audit-config-example.yaml
+[source,yaml]
+----
+// Include from: services/_includes/audit-config-example.yaml
+----
+
+// AUTO-GENERATED CONTENT: services/_includes/audit_configvars.md
diff --git a/modules/developer/pages/services/auth-basic/configuration.adoc b/modules/developer/pages/services/auth-basic/configuration.adoc
new file mode 100644
index 00000000..42e6ebdf
--- /dev/null
+++ b/modules/developer/pages/services/auth-basic/configuration.adoc
@@ -0,0 +1,13 @@
+= Service Configuration
+:toc: right
+:toclevels: 3
+
+== Example YAML Config
+
+// AUTO-GENERATED CONTENT: services/_includes/auth-basic-config-example.yaml
+[source,yaml]
+----
+// Include from: services/_includes/auth-basic-config-example.yaml
+----
+
+// AUTO-GENERATED CONTENT: services/_includes/auth-basic_configvars.md
diff --git a/modules/developer/pages/services/auth-bearer/configuration.adoc b/modules/developer/pages/services/auth-bearer/configuration.adoc
new file mode 100644
index 00000000..dd0db6b3
--- /dev/null
+++ b/modules/developer/pages/services/auth-bearer/configuration.adoc
@@ -0,0 +1,13 @@
+= Service Configuration
+:toc: right
+:toclevels: 3
+
+== Example YAML Config
+
+// AUTO-GENERATED CONTENT: services/_includes/auth-bearer-config-example.yaml
+[source,yaml]
+----
+// Include from: services/_includes/auth-bearer-config-example.yaml
+----
+
+// AUTO-GENERATED CONTENT: services/_includes/auth-bearer_configvars.md
diff --git a/modules/developer/pages/services/auth-machine/configuration.adoc b/modules/developer/pages/services/auth-machine/configuration.adoc
new file mode 100644
index 00000000..f4daa999
--- /dev/null
+++ b/modules/developer/pages/services/auth-machine/configuration.adoc
@@ -0,0 +1,13 @@
+= Service Configuration
+:toc: right
+:toclevels: 3
+
+== Example YAML Config
+
+// AUTO-GENERATED CONTENT: services/_includes/auth-machine-config-example.yaml
+[source,yaml]
+----
+// Include from: services/_includes/auth-machine-config-example.yaml
+----
+
+// AUTO-GENERATED CONTENT: services/_includes/auth-machine_configvars.md
diff --git a/modules/developer/pages/services/eventhistory/configuration.adoc b/modules/developer/pages/services/eventhistory/configuration.adoc
new file mode 100644
index 00000000..3f289b45
--- /dev/null
+++ b/modules/developer/pages/services/eventhistory/configuration.adoc
@@ -0,0 +1,13 @@
+= Service Configuration
+:toc: right
+:toclevels: 3
+
+== Example YAML Config
+
+// AUTO-GENERATED CONTENT: services/_includes/eventhistory-config-example.yaml
+[source,yaml]
+----
+// Include from: services/_includes/eventhistory-config-example.yaml
+----
+
+// AUTO-GENERATED CONTENT: services/_includes/eventhistory_configvars.md
diff --git a/modules/developer/pages/services/frontend/configuration.adoc b/modules/developer/pages/services/frontend/configuration.adoc
new file mode 100644
index 00000000..25b90b7d
--- /dev/null
+++ b/modules/developer/pages/services/frontend/configuration.adoc
@@ -0,0 +1,13 @@
+= Service Configuration
+:toc: right
+:toclevels: 3
+
+== Example YAML Config
+
+// AUTO-GENERATED CONTENT: services/_includes/frontend-config-example.yaml
+[source,yaml]
+----
+// Include from: services/_includes/frontend-config-example.yaml
+----
+
+// AUTO-GENERATED CONTENT: services/_includes/frontend_configvars.md
diff --git a/modules/developer/pages/services/gateway/configuration.adoc b/modules/developer/pages/services/gateway/configuration.adoc
new file mode 100644
index 00000000..18546f3d
--- /dev/null
+++ b/modules/developer/pages/services/gateway/configuration.adoc
@@ -0,0 +1,13 @@
+= Service Configuration
+:toc: right
+:toclevels: 3
+
+== Example YAML Config
+
+// AUTO-GENERATED CONTENT: services/_includes/gateway-config-example.yaml
+[source,yaml]
+----
+// Include from: services/_includes/gateway-config-example.yaml
+----
+
+// AUTO-GENERATED CONTENT: services/_includes/gateway_configvars.md
diff --git a/modules/developer/pages/services/general-info/add-translations.adoc b/modules/developer/pages/services/general-info/add-translations.adoc
new file mode 100644
index 00000000..b44b99fa
--- /dev/null
+++ b/modules/developer/pages/services/general-info/add-translations.adoc
@@ -0,0 +1,107 @@
+= Add Translations
+:toc: right
+:toclevels: 3
+
+Services can have texts that need to be translated. These translations will be shown in the ownCloud Web UI. Compared to web, these translations:
+
+* Are located in the same Transifex project as the web, which is named link:https://app.transifex.com/owncloud-org/owncloud-web/translate/[ownCloud Web].
+* Have a name starting with `ocis-` for ease of identification.
+
+The process for _synchronisation_ with Transifex is already setup and nothing needs to be done here. For any translation, it is necessary to set it up in the respective service and tell to sync it.
+
+_IMPORTANT_\
+Translations are automatically synced on a daily basis in the night. To do so, there is an own repo that covers the process for ALL translations from all configured repos: link:https://github.com/owncloud/translation-sync[translation-sync]. If there is a manual "emergency" sync necessary, you only need to trigger link:https://drone.owncloud.com/owncloud/translation-sync[drone] via cli
+
+[source,bash]
+----
+drone cron exec owncloud/translation-sync nightly
+----
+Note that you need to be logged on in drone to execute the command.
+
+== Implementing ocis Translations
+
+The implementation example is a guide and shall show how to do it. You can derive at any time according to your needs.
+
+Note that paths are examples and can be adapted based on requirements.\
+Replace `` with the name of the respective service.\
+Translations have a `context` and a `translatable string`. The context is shown on Transifex but not translated and helps translators to get a context for the string to be translated.
+
+* Add the `OCIS_DEFAULT_LANGUAGE` envvar in `services//pkg/config/config.go`.\
+ For details see the userlog or notifications service code.
+
+* Add the `_TRANSLATION_PATH` envvar in `services//pkg/config/config.go`.\
+ For details see the userlog or notifications service code.
+
+* Use `"github.com/owncloud/ocis/v2/ocis-pkg/l10n"` for the translation.\
+ Use `l10n.Template` to define the translation string.\
+ Use `l10n.NewTranslator` or `l10n.NewTranslatorFromCommonConfig` to get the translator.\
+ Use `t.Get` to translate the string. See package for more advanced usage.
+
+* Create a config in `services//pkg/service/l10n/.tx/config` with the following content. Note that it is important to stick with `ocis-` to easily identify all ocis translations on Transifex:
+ ```
+ [main]
+ host = https://www.transifex.com
+
+ [o:owncloud-org:p:owncloud-web:r:ocis-]
+ file_filter = locale//LC_MESSAGES/.po
+ minimum_perc = 75
+ resource_name = ocis-
+ source_file = .pot
+ source_lang = en
+ type = PO
+ ```
+ Note: o: organization, p: project, r: resource
+
+* Create an empty file `services//pkg/service/l10n/locale/en/LC_MESSAGES/.po`. This is required for ocis to build. This file will be replaced nightly with the latest translations from Transifex.
+
+* Create a go file like `templates.go` in e.g. `ocis/services//pkg/service` that will define your translation sources like the following:
+ ```
+ // this comment will appear in transifex as context
+ var yourString = l10n.Template("Translation String")
+ ```
+
+* In the `Makefile` in the _ocis root_, add in the following section the service you want to synchronize translations with Transifex:
+ ```
+ # add a service here when it uses transifex
+ L10N_MODULES := \
+ services/notifications \
+ services/userlog \
+ services/graph \
+ services/activitylog \
+ services/
+ ```
+
+* In the `Makefile` of the _``_ add:\
+ _At the beginning:_
+ ```
+ # Where to write the files generated by this makefile.
+ OUTPUT_DIR = ./pkg/service/<...>/l10n
+ TEMPLATE_FILE = ./pkg/service/<...>/l10n/.pot
+ ```
+ _In the `.PHONY` list:_
+ ```
+ ############ translations ########
+ .PHONY: l10n-pull
+ l10n-pull:
+ cd $(OUTPUT_DIR) && tx pull --all --force --skip --minimum-perc=75
+
+ .PHONY: l10n-push
+ l10n-push:
+ cd $(OUTPUT_DIR) && tx push -s --skip
+
+ .PHONY: l10n-read
+ l10n-read: $(GO_XGETTEXT)
+ go-xgettext -o $(OUTPUT_DIR)/.pot \
+ --keyword=l10n.Template --add-comments -s \
+ pkg/service/templates.go
+
+ .PHONY: l10n-write
+ l10n-write:
+
+ .PHONY: l10n-clean
+ l10n-clean:
+ rm -f $(TEMPLATE_FILE);
+ ```
+
+* Add Description Text to README\
+ Add the full `Translations` and `Default Language` text blocks including their sub sections to the service readme. You can derive from the `activitylog` or `userlog` service for easy copy/paste.
diff --git a/modules/developer/pages/services/general-info/additional-information.adoc b/modules/developer/pages/services/general-info/additional-information.adoc
new file mode 100644
index 00000000..876df8a3
--- /dev/null
+++ b/modules/developer/pages/services/general-info/additional-information.adoc
@@ -0,0 +1,13 @@
+= Additional Information
+:toc: right
+:toclevels: 3
+
+This section contains information on general topics
+
+== GRPC Maximum Message Size
+
+ocis is using grpc for inter-service communication. When having a folder with a lot of files (25.000+, the size does not matter) and doing a `PROPFIND` on that folder, the server will run into errors. This is because the grpc message body becomes to big. With introduction of the envvar `OCIS_GRPC_MAX_RECEIVED_MESSAGE_SIZE`, the max size for the grpc body can be raised.
+
+NOTE: With a certain amount of files even raising the grpc message size will not suffice as the requests will run into network timeouts. Also generally the more files are in a folder, the longer it will take time to load.
+
+It is recommended to use `OCIS_GRPC_MAX_RECEIVED_MESSAGE_SIZE` only _temporary_ to copy files out of the folder (like via the web ui) and use the default value in general.
diff --git a/modules/developer/pages/services/general-info/envvars/deprecating-variables.adoc b/modules/developer/pages/services/general-info/envvars/deprecating-variables.adoc
new file mode 100644
index 00000000..6d27b578
--- /dev/null
+++ b/modules/developer/pages/services/general-info/envvars/deprecating-variables.adoc
@@ -0,0 +1,57 @@
+= Envvar Deprecation
+:toc: right
+:toclevels: 3
+
+
+== Deprecating Environment Variables
+
+Sometimes it is necessary to deprecate an environment variable to align the naming with conventions or remove it completely. We therefore added annotations to automate the _documentation_ process.
+
+The relevant annotations in the envvar struct tag are:
+
+* `deprecationVersion`\
+ The release an envvar is announced for deprecation.
+* `removalVersion`\
+ The version it is finally going to be removed is defined via the mandatory placeholder `%%NEXT_PRODUCTION_VERSION%%`, not an actual version number.
+* `deprecationInfo`\
+ The reason why it was deprecated.
+* `deprecationReplacement`\
+ Only if it is going to be replaced, not necessary if removed.
+
+[WARNING]
+====
+* During the development cycle, the value for the `removalVersion` must be set to `%%NEXT_PRODUCTION_VERSION%%`. This placeholder will be replaced by the real semantic-version number during the production releasing process.
+* Compared when introducing new envvars where you can use arbitrary alphabetic identifyers, the string for deprecation is fixed and cannot be altered.
+====
+
+
+For the documentation to show the correct value for the `removalVersion`, our docs helper scripts will automatically generate the correct version to be printed in the documentation. If `%%NEXT_PRODUCTION_VERSION%%` is found in the query, it will be replaced with `next-prod`, else the value found is used.
+
+=== Example
+
+[source,golang]
+----
+// Notifications defines the config options for the notifications service.
+type Notifications struct {
+RevaGateway string `yaml:"reva_gateway" env:"OCIS_REVA_GATEWAY;REVA_GATEWAY" desc:"CS3 gateway used to look up user metadata" deprecationVersion:"3.0" removalVersion:"%%NEXT_PRODUCTION_VERSION%%" deprecationInfo:"REVA_GATEWAY changing name for consistency" deprecationReplacement:"OCIS_REVA_GATEWAY"`
+...
+}
+----
+
+There are four different annotation variables that need to be filled:
+
+| Annotation |Description| Format|
+|---|---|---|
+| deprecationVersion | The version the variable will be deprecated | semver (e.g. 3.0)|
+| removalVersion | The version the variable will be removed from the codebase. Consider semver rules when finally removing a deprecated ennvar | `%%NEXT_PRODUCTION_VERSION%%` |
+| deprecationInfo | Information why the variable is deprecated, must start with the name of the variable in order to avoid confusion, when there are multiple options in the `env:`-field | string (e.g. NATS_NATS_HOST is confusing) |
+| deprecationReplacement | The name of the variable that is going to replace the deprecated one.| string (e.g. NATS_HOST_ADDRESS) |
+
+=== What Happens Next?
+
+To remove an environment variable, which needs to be done before the planned release has codefreeze:
+
+* Check if the envvar is also present in the REVA code and adapt if so.
+* The envvar needs to be removed from any occurrences in the ocis code.
+* The envvar must also be removed from the `docs/helpers/env_vars.yaml` file. This should be done in the same PR that removes the envvar from the code.
+* Notify docs. The added/deprecated/removed envvar tables need to be created/updated. The release notes will get a note about this change.
diff --git a/modules/developer/pages/services/general-info/envvars/env-var-deltas/4.0.0-5.0.0-added.adoc b/modules/developer/pages/services/general-info/envvars/env-var-deltas/4.0.0-5.0.0-added.adoc
new file mode 100644
index 00000000..02a2ce28
--- /dev/null
+++ b/modules/developer/pages/services/general-info/envvars/env-var-deltas/4.0.0-5.0.0-added.adoc
@@ -0,0 +1,266 @@
+:toc: right
+:toclevels: 3
+
+= Added Variables between oCIS 4.0.0 and oCIS 5.0.0
+
+| File | Variable | Description | Default |
+|-----------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|---------------------------------------|
+| ocis-pkg/shared/shared_types.go | `OCIS_CACHE_DISABLE_PERSISTENCE` | Disables persistence of the cache. Only applies when store type 'nats-js-kv' is configured. | `false` |
+| ocis-pkg/registry/registry.go | `MICRO_REGISTRY` (important change) | The Go micro registry type to use. Supported types are: 'memory', 'nats-js-kv' (default) and 'kubernetes'. Note that 'nats', 'etcd', 'consul' and 'mdns' are deprecated and will be removed in a later version. Only change on supervision of ownCloud Support. | `nats-js-kv` |
+| ocis-pkg/natsjsregistry/registry.go | `MICRO_REGISTRY_AUTH_USERNAME` | Optional when using nats to authenticate with the nats cluster. | |
+| | `MICRO_REGISTRY_AUTH_PASSWORD` | Optional when using nats to authenticate with the nats cluster. | |
+| services/antivirus/pkg/config/config.go | `OCIS_EVENTS_AUTH_USERNAME` | The username to authenticate with the events broker. The events broker is the ocis service which receives and delivers events between the services. | |
+| | `OCIS_EVENTS_AUTH_PASSWORD` | The password to authenticate with the events broker. The events broker is the ocis service which receives and delivers events between the services. | |
+| | `ANTIVIRUS_ICAP_SCAN_TIMEOUT` | Scan timeout for the ICAP client. Defaults to '5m' (5 minutes). See the Environment Variable Types description for more details. | 5m0s |
+| services/audit/pkg/config/config.go | `OCIS_EVENTS_AUTH_USERNAME` | The username to authenticate with the events broker. The events broker is the ocis service which receives and delivers events between the services. | |
+| | `OCIS_EVENTS_AUTH_PASSWORD` | The password to authenticate with the events broker. The events broker is the ocis service which receives and delivers events between the services. | |
+| services/auth-service/pkg/config/config.go | `OCIS_LOG_LEVEL;AUTH_SERVICE_LOG_LEVEL` | The log level. Valid values are: 'panic', 'fatal', 'error', 'warn', 'info', 'debug', 'trace'." | |
+| | `OCIS_LOG_PRETTY;AUTH_SERVICE_LOG_PRETTY` | Activates pretty log output. | |
+| | `OCIS_LOG_COLOR;AUTH_SERVICE_LOG_COLOR` | Activates colorized log output. | |
+| | `OCIS_LOG_FILE;AUTH_SERVICE_LOG_FILE` | The path to the log file. Activates logging to this file if set. | |
+| | `AUTH_SERVICE_DEBUG_ADDR` | Bind address of the debug server, where metrics, health, config and debug endpoints will be exposed. | |
+| | `AUTH_SERVICE_DEBUG_PPROF` | Enables pprof, which can be used for profiling. | |
+| | `AUTH_SERVICE_DEBUG_TOKEN` | Enables pprof, which can be used for profiling. | |
+| | `AUTH_SERVICE_DEBUG_ZPAGES` | Enables zpages, which can be used for collecting and viewing in-memory traces. | |
+| | `AUTH_SERVICE_GRPC_ADDR` | The bind address of the GRPC service. | |
+| | `AUTH_SERVICE_GRPC_PROTOCOL` | The transport protocol of the GRPC service. | |
+| | `OCIS_SERVICE_ACCOUNT_ID;AUTH_SERVICE_SERVICE_ACCOUNT_ID` | The ID of the service account the service should use. See the 'auth-service' service description for more details. | |
+| | `OCIS_SERVICE_ACCOUNT_SECRET;AUTH_SERVICE_SERVICE_ACCOUNT_SECRET` | The service account secret. | |
+| services/auth-service/pkg/config/reva.go | `OCIS_JWT_SECRET;AUTH_SERVICE_JWT_SECRET` | The secret to mint and validate jwt tokens. | |
+| services/auth-service/pkg/config/tracing.go | `OCIS_TRACING_ENABLED;AUTH_SERVICE_TRACING_ENABLED` | Activates tracing. | |
+| | `OCIS_TRACING_TYPE;AUTH_SERVICE_TRACING_TYPE` | The type of tracing. Defaults to '', which is the same as 'jaeger'. Allowed tracing types are 'jaeger' and '' as of now."` | |
+| | `OCIS_TRACING_ENDPOINT;AUTH_SERVICE_TRACING_ENDPOINT` | The endpoint of the tracing agent. | |
+| | `OCIS_TRACING_COLLECTOR;AUTH_SERVICE_TRACING_COLLECTOR` | The HTTP endpoint for sending spans directly to a collector, i.e. http://jaeger-collector:14268/api/traces. Only used if the tracing endpoint is unset. | |
+| services/clientlog/pkg/config/config.go | `OCIS_REVA_GATEWAY;CLIENTLOG_REVA_GATEWAY` | CS3 gateway used to look up user metadata | |
+| | `OCIS_EVENTS_ENDPOINT;CLIENTLOG_EVENTS_ENDPOINT` | The address of the event system. The event system is the message queuing service. It is used as message broker for the microservice architecture. | |
+| | `OCIS_EVENTS_CLUSTER;CLIENTLOG_EVENTS_CLUSTER` | The clusterID of the event system. The event system is the message queuing service. It is used as message broker for the microservice architecture. Mandatory when using NATS as event system. | |
+| | `OCIS_INSECURE;CLIENTLOG_EVENTS_TLS_INSECURE` | Whether to verify the server TLS certificates. | |
+| | `OCIS_EVENTS_TLS_ROOT_CA_CERTIFICATE;CLIENTLOG_EVENTS_TLS_ROOT_CA_CERTIFICATE` | The root CA certificate used to validate the server's TLS certificate. If provided NOTIFICATIONS_EVENTS_TLS_INSECURE will be seen as false. | |
+| | `OCIS_EVENTS_ENABLE_TLS;CLIENTLOG_EVENTS_ENABLE_TLS` | Enable TLS for the connection to the events broker. The events broker is the ocis service which receives and delivers events between the services.. | |
+| | `OCIS_EVENTS_AUTH_USERNAME;CLIENTLOG_EVENTS_AUTH_USERNAME` | The username to authenticate with the events broker. The events broker is the ocis service which receives and delivers events between the services.. | |
+| | `OCIS_EVENTS_AUTH_PASSWORD;CLIENTLOG_EVENTS_AUTH_PASSWORD` | The password to authenticate with the events broker. The events broker is the ocis service which receives and delivers events between the services.. | |
+| | `OCIS_JWT_SECRET;CLIENTLOG_JWT_SECRET` | The secret to mint and validate jwt tokens. | |
+| | `OCIS_SERVICE_ACCOUNT_ID;CLIENTLOG_SERVICE_ACCOUNT_ID` | The ID of the service account the service should use. See the 'auth-service' service description for more details. | |
+| | `OCIS_SERVICE_ACCOUNT_SECRET;CLIENTLOG_SERVICE_ACCOUNT_SECRET` | The service account secret. | |
+| services/clientlog/pkg/config/debug.go | `CLIENTLOG_DEBUG_ADDR` | Bind address of the debug server, where metrics, health, config and debug endpoints will be exposed. | |
+| | `CLIENTLOG_DEBUG_TOKEN` | Token to secure the metrics endpoint. | |
+| | `CLIENTLOG_DEBUG_PPROF` | Enables pprof, which can be used for profiling. | |
+| | `CLIENTLOG_DEBUG_ZPAGES` | Enables zpages, which can be used for collecting and viewing in-memory traces. | |
+| services/clientlog/pkg/config/log.go | `OCIS_LOG_LEVEL;CLIENTLOG_USERLOG_LOG_LEVEL` | The log level. Valid values are: 'panic', 'fatal', 'error', 'warn', 'info', 'debug', 'trace'." | |
+| | `OCIS_LOG_PRETTY;CLIENTLOG_USERLOG_LOG_PRETTY` | Activates pretty log output. | |
+| | `OCIS_LOG_COLOR;CLIENTLOG_USERLOG_LOG_COLOR` | Activates colorized log output. | |
+| | `OCIS_LOG_FILE;CLIENTLOG_USERLOG_LOG_FILE` | The path to the log file. Activates logging to this file if set. | |
+| services/clientlog/pkg/config/tracing.go | `OCIS_TRACING_ENABLED;CLIENTLOG_TRACING_ENABLED` | Activates tracing. | |
+| | `OCIS_TRACING_TYPE;CLIENTLOG_TRACING_TYPE` | The type of tracing. Defaults to '', which is the same as 'jaeger'. Allowed tracing types are 'jaeger' and '' as of now."` | |
+| | `OCIS_TRACING_ENDPOINT;CLIENTLOG_TRACING_ENDPOINT` | The endpoint of the tracing agent. | |
+| | `OCIS_TRACING_COLLECTOR;CLIENTLOG_TRACING_COLLECTOR` | The HTTP endpoint for sending spans directly to a collector, i.e. http://jaeger-collector:14268/api/traces. Only used if the tracing endpoint is unset. | |
+| services/eventhistory/pkg/config/config.go | `OCIS_PERSISTENT_STORE_AUTH_USERNAME;EVENTHISTORY_STORE_AUTH_USERNAME` | The username to authenticate with the store. Only applies when store type 'nats-js-kv' is configured. | |
+| | `OCIS_PERSISTENT_STORE_AUTH_PASSWORD;EVENTHISTORY_STORE_AUTH_PASSWORD` | The password to authenticate with the store. Only applies when store type 'nats-js-kv' is configured. | |
+| | `OCIS_EVENTS_AUTH_USERNAME;EVENTHISTORY_EVENTS_AUTH_USERNAME` | The username to authenticate with the events broker. The events broker is the ocis service which receives and delivers events between the services. | |
+| | `OCIS_EVENTS_AUTH_PASSWORD;EVENTHISTORY_EVENTS_AUTH_PASSWORD` | The password to authenticate with the events broker. The events broker is the ocis service which receives and delivers events between the services. | |
+| services/frontend/pkg/config/config.go | `OCIS_ENABLE_RESHARING` | Changing this value is NOT supported. Enables the support for resharing in the clients. | |
+| | `FRONTEND_DEFAULT_LINK_PERMISSIONS` | Defines the default permissions a link is being created with. Possible values are 0 (= internal link, for instance members only) and 1 (= public link with viewer permissions). Defaults to 1. | |
+| | `FRONTEND_AUTO_ACCEPT_SHARES` | Defines if shares should be auto accepted by default. Users can change this setting individually in their profile. | true |
+| | `OCIS_CACHE_DISABLE_PERSISTENCE;FRONTEND_OCS_STAT_CACHE_DISABLE_PERSISTENCE` | Disable persistence of the cache. Only applies when using the 'nats-js-kv' store type. Defaults to false. | false |
+| | `OCIS_CACHE_AUTH_USERNAME;FRONTEND_OCS_STAT_CACHE_AUTH_USERNAME` | The username to use for authentication. Only applies when using the 'nats-js-kv' store type. | |
+| | `OCIS_CACHE_AUTH_PASSWORD;FRONTEND_OCS_STAT_CACHE_AUTH_PASSWORD` | The password to use for authentication. Only applies when using the 'nats-js-kv' store type. | |
+| | `FRONTEND_OCS_LIST_OCM_SHARES` | Include OCM shares when listing shares. See the OCM service documentation for more details. | |
+| | `OCIS_SHARING_PUBLIC_SHARE_MUST_HAVE_PASSWORD;FRONTEND_OCS_PUBLIC_SHARE_MUST_HAVE_PASSWORD` | Set this to true if you want to enforce passwords on all public shares. | |
+| | `OCIS_SHARING_PUBLIC_WRITEABLE_SHARE_MUST_HAVE_PASSWORD;FRONTEND_OCS_PUBLIC_WRITEABLE_SHARE_MUST_HAVE_PASSWORD` | Set this to true if you want to enforce passwords on Uploader, Editor or Contributor shares. | |
+| | `FRONTEND_OCS_INCLUDE_OCM_SHAREES` | Include OCM sharees when listing sharees. | |
+| | `OCIS_EVENTS_ENDPOINT;FRONTEND_EVENTS_ENDPOINT` | The address of the event system. The event system is the message queuing service. It is used as message broker for the microservice architecture. | |
+| | `OCIS_EVENTS_CLUSTER;FRONTEND_EVENTS_CLUSTER` | The clusterID of the event system. The event system is the message queuing service. It is used as message broker for the microservice architecture. Mandatory when using NATS as event system. | |
+| | `OCIS_INSECURE;FRONTEND_EVENTS_TLS_INSECURE` | Whether to verify the server TLS certificates. | |
+| | `FRONTEND_EVENTS_TLS_ROOT_CA_CERTIFICATE;OCS_EVENTS_TLS_ROOT_CA_CERTIFICATE` | The root CA certificate used to validate the server's TLS certificate. If provided NOTIFICATIONS_EVENTS_TLS_INSECURE will be seen as false. | |
+| | `OCIS_EVENTS_ENABLE_TLS;FRONTEND_EVENTS_ENABLE_TLS` | Enable TLS for the connection to the events broker. The events broker is the ocis service which receives and delivers events between the services. | |
+| | `OCIS_EVENTS_AUTH_USERNAME;FRONTEND_EVENTS_AUTH_USERNAME` | The username to authenticate with the events broker. The events broker is the ocis service which receives and delivers events between the services.. | |
+| | `OCIS_EVENTS_AUTH_PASSWORD;FRONTEND_EVENTS_AUTH_PASSWORD` | The password to authenticate with the events broker. The events broker is the ocis service which receives and delivers events between the services.. | |
+| | `OCIS_SERVICE_ACCOUNT_ID;FRONTEND_SERVICE_ACCOUNT_ID` | The ID of the service account the service should use. See the 'auth-service' service description for more details. | |
+| | `OCIS_SERVICE_ACCOUNT_SECRET;FRONTEND_SERVICE_ACCOUNT_SECRET` | The service account secret. | |
+| | `OCIS_PASSWORD_POLICY_DISABLED;FRONTEND_PASSWORD_POLICY_DISABLED` | Disable the password policy. Defaults to false if not set. | |
+| | `OCIS_PASSWORD_POLICY_MIN_CHARACTERS;FRONTEND_PASSWORD_POLICY_MIN_CHARACTERS` | Define the minimum password length. Defaults to 0 if not set. | 0 |
+| | `OCIS_PASSWORD_POLICY_MIN_LOWERCASE_CHARACTERS;FRONTEND_PASSWORD_POLICY_MIN_LOWERCASE_CHARACTERS` | Define the minimum number of lowercase characters. Defaults to 0 if not set. | 0 |
+| | `OCIS_PASSWORD_POLICY_MIN_UPPERCASE_CHARACTERS;FRONTEND_PASSWORD_POLICY_MIN_UPPERCASE_CHARACTERS` | Define the minimum number of uppercase characters. Defaults to 0 if not set. | 0 |
+| | `OCIS_PASSWORD_POLICY_MIN_DIGITS;FRONTEND_PASSWORD_POLICY_MIN_DIGITS` | Define the minimum number of digits. Defaults to 0 if not set. | 0 |
+| | `OCIS_PASSWORD_POLICY_MIN_SPECIAL_CHARACTERS;FRONTEND_PASSWORD_POLICY_MIN_SPECIAL_CHARACTERS` | Define the minimum number of special characters. Defaults to 0 if not set. | 0 |
+| | `OCIS_PASSWORD_POLICY_BANNED_PASSWORDS_LIST;FRONTEND_PASSWORD_POLICY_BANNED_PASSWORDS_LIST` | Path to the 'banned passwords list' file. See the documentation for more details. | |
+| services/gateway/pkg/config/config.go | `OCIS_CACHE_DISABLE_PERSISTENCE;GATEWAY_STAT_CACHE_DISABLE_PERSISTENCE` | Disables persistence of the stat cache. Only applies when store type 'nats-js-kv' is configured. Defaults to false. | false |
+| | `OCIS_CACHE_DISABLE_PERSISTENCE;GATEWAY_PROVIDER_CACHE_DISABLE_PERSISTENCE` | Disables persistence of the provider cache. Only applies when store type 'nats-js-kv' is configured. Defaults to false. | false |
+| | `OCIS_CACHE_AUTH_USERNAME;GATEWAY_PROVIDER_CACHE_AUTH_USERNAME` | The username to use for authentication. Only applies when store type 'nats-js-kv' is configured. | |
+| | `OCIS_CACHE_AUTH_PASSWORD;GATEWAY_PROVIDER_CACHE_AUTH_PASSWORD` | The password to use for authentication. Only applies when store type 'nats-js-kv' is configured. | |
+| | `OCIS_CACHE_DISABLE_PERSISTENCE;GATEWAY_CREATE_HOME_CACHE_DISABLE_PERSISTENCE` | Disables persistence of the create home cache. Only applies when store type 'nats-js-kv' is configured. Defaults to false. | |
+| | `OCIS_CACHE_AUTH_USERNAME;GATEWAY_CREATE_HOME_CACHE_AUTH_USERNAME` | The username to use for authentication. Only applies when store type 'nats-js-kv' is configured. | false |
+| | `OCIS_CACHE_AUTH_PASSWORD;GATEWAY_CREATE_HOME_CACHE_AUTH_PASSWORD` | The password to use for authentication. Only applies when store type 'nats-js-kv' is configured. | |
+| services/graph/pkg/config/cache.go | `OCIS_CACHE_DISABLE_PERSISTENCE;GRAPH_CACHE_DISABLE_PERSISTENCE` | Disables persistence of the cache. Only applies when store type 'nats-js-kv' is configured. Defaults to false. | false |
+| | `OCIS_CACHE_AUTH_USERNAME;GRAPH_CACHE_AUTH_USERNAME` | The username to authenticate with the cache. Only applies when store type 'nats-js-kv' is configured. | |
+| | `OCIS_CACHE_AUTH_PASSWORD;GRAPH_CACHE_AUTH_PASSWORD` | The password to authenticate with the cache. Only applies when store type 'nats-js-kv' is configured. | |
+| services/graph/pkg/config/config.go | `GRAPH_IDENTITY_SEARCH_MIN_LENGTH` | The minimum length the search term needs to have for unprivileged users when searching for users or groups. | |
+| | `OCIS_EVENTS_AUTH_USERNAME;GRAPH_EVENTS_AUTH_USERNAME` | The username to authenticate with the events broker. The events broker is the ocis service which receives and delivers events between the services. | |
+| | `OCIS_EVENTS_AUTH_PASSWORD;GRAPH_EVENTS_AUTH_PASSWORD` | The password to authenticate with the events broker. The events broker is the ocis service which receives and delivers events between the services. | |
+| | `OCIS_SERVICE_ACCOUNT_ID;GRAPH_SERVICE_ACCOUNT_ID` | The ID of the service account the service should use. See the 'auth-service' service description for more details. | |
+| | `OCIS_SERVICE_ACCOUNT_SECRET;GRAPH_SERVICE_ACCOUNT_SECRET` | The service account secret. | |
+| | `OCIS_ENABLE_RESHARING;GRAPH_ENABLE_RESHARING` | Changing this value is NOT supported. Enables the support for resharing in the clients. | |
+| services/idp/pkg/config/config.go | `IDP_LOGIN_BACKGROUND_URL` | Configure an alternative URL to the background image for the login page. | |
+| services/notifications/pkg/config/config.go | `OCIS_DEFAULT_LANGUAGE` | The default language used by services and the WebUI. If not defined, English will be used as default. See the documentation for more details. | |
+| | `OCIS_EVENTS_AUTH_USERNAME;NOTIFICATIONS_EVENTS_AUTH_USERNAME` | The username to authenticate with the events broker. The events broker is the ocis service which receives and delivers events between the services. | |
+| | `OCIS_EVENTS_AUTH_PASSWORD;NOTIFICATIONS_EVENTS_AUTH_PASSWORD` | The password to authenticate with the events broker. The events broker is the ocis service which receives and delivers events between the services. | |
+| | `OCIS_SERVICE_ACCOUNT_ID;NOTIFICATIONS_SERVICE_ACCOUNT_ID` | The ID of the service account the service should use. See the 'auth-service' service description for more details. | |
+| | `OCIS_SERVICE_ACCOUNT_SECRET;NOTIFICATIONS_SERVICE_ACCOUNT_SECRET` | The service account secret. | |
+| services/ocdav/pkg/config/config.go | `OCDAV_OCM_NAMESPACE` | The human readable path prefix for the ocm shares. | |
+| services/ocm/pkg/config/config.go | `SHARING_OCM_PROVIDER_AUTHORIZER_DRIVER` | Driver to be used to persist ocm invites. Supported value is only 'json'. | `json` |
+| | `OCM_HTTP_ADDR` | The bind address of the HTTP service. | |
+| | `OCM_HTTP_PROTOCOL` | The transport protocol of the HTTP service. | |
+| | `OCM_HTTP_PREFIX` | The path prefix where OCM can be accessed (defaults to /). | |
+| | `OCIS_SERVICE_ACCOUNT_ID;OCM_SERVICE_ACCOUNT_ID` | The ID of the service account the service should use. See the 'auth-service' service description for more details. | |
+| | `OCIS_SERVICE_ACCOUNT_SECRET;OCM_SERVICE_ACCOUNT_SECRET` | The service account secret. | |
+| | `OCIS_CORS_ALLOW_ORIGINS;OCM_CORS_ALLOW_ORIGINS` | A list of allowed CORS origins. See following chapter for more details: _Access-Control-Allow-Origin_ at https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Origin. See the Environment Variable Types description for more details. | |
+| | `OCIS_CORS_ALLOW_METHODS;OCM_CORS_ALLOW_METHODS` | A list of allowed CORS methods. See following chapter for more details: _Access-Control-Allow-Methods_ at https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Methods. See the Environment Variable Types description for more details. | |
+| | `OCIS_CORS_ALLOW_HEADERS;OCM_CORS_ALLOW_HEADERS` | A list of allowed CORS headers. See following chapter for more details: _Access-Control-Allow-Headers_ at https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Headers. See the Environment Variable Types description for more details. | |
+| | `OCIS_CORS_ALLOW_CREDENTIALS;OCM_CORS_ALLOW_CREDENTIALS` | Allow credentials for CORS.See following chapter for more details: _Access-Control-Allow-Credentials_ at https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Credentials. | |
+| | `OCM_GRPC_ADDR` | The bind address of the GRPC service. | |
+| | `OCM_GRPC_PROTOCOL` | The transport protocol of the GRPC service. | |
+| | `OCM_SCIENCEMESH_PREFIX` | URL path prefix for the ScienceMesh service. Note that the string must not start with '/'. | |
+| | `OCM_MESH_DIRECTORY_URL ` | URL of the mesh directory service. | |
+| | `OCM_OCMD_PREFIX` | URL path prefix for the OCMd service. Note that the string must not start with '/'. | |
+| | `OCM_OCMD_EXPOSE_RECIPIENT_DISPLAY_NAME` | Expose the display name of OCM share recipients. | |
+| | `OCM_OCM_INVITE_MANAGER_DRIVER` | Driver to be used to persist ocm invites. Supported value is only 'json'. | `json` |
+| | `OCM_OCM_INVITE_MANAGER_INSECURE` | Disable TLS certificate validation for the OCM connections. Do not set this in production environments. | |
+| | `OCM_OCM_INVITE_MANAGER_JSON_FILE` | Path to the JSON file where OCM invite data will be stored. If not defined, the root directory derives from $OCIS_BASE_DATA_PATH:/storage. | |
+| | `OCM_OCM_PROVIDER_AUTHORIZER_PROVIDERS_FILE` | Path to the JSON file where ocm invite data will be stored. If not defined, the root directory derives from $OCIS_BASE_DATA_PATH:/storage. | |
+| | `OCM_OCM_PROVIDER_AUTHORIZER_VERIFY_REQUEST_HOSTNAME` | Verify the hostname of the request against the hostname of the OCM provider. | |
+| | `OCM_OCM_CORE_DRIVER` | Driver to be used to persist ocm shares. Supported value is only 'json'. | `json` |
+| | `OCM_OCM_STORAGE_PROVIDER_INSECURE` | Disable TLS certificate validation for the OCM connections. Do not set this in production environments. | |
+| | `OCM_OCM_STORAGE_PROVIDER_STORAGE_ROOT` | Directory where the ocm storage provider persists its data like tus upload info files. | |
+| | `OCM_OCM_CORE_JSON_FILE` | Path to the JSON file where OCM share data will be stored. If not defined, the root directory derives from $OCIS_BASE_DATA_PATH:/storage. | |
+| | `OCM_OCM_SHARE_PROVIDER_DRIVER` | Driver to be used to persist ocm shares. Supported value is only 'json'. | `json` |
+| | `OCM_OCM_SHARE_PROVIDER_INSECURE` | Disable TLS certificate validation for the OCM connections. Do not set this in production environments. | |
+| | `OCM_WEBAPP_TEMPLATE` | Template for the webapp url. | |
+| | `OCM_OCM_SHAREPROVIDER_JSON_FILE` | Path to the JSON file where OCM share data will be stored. If not defined, the root directory derives from $OCIS_BASE_DATA_PATH:/storage. | |
+| services/ocm/pkg/config/debug.go | `OCM_DEBUG_ADDR` | Bind address of the debug server, where metrics, health, config and debug endpoints will be exposed. | |
+| | `OCM_DEBUG_TOKEN` | Token to secure the metrics endpoint. | |
+| | `OCM_DEBUG_PPROF` | Enables pprof, which can be used for profiling. | |
+| | `OCM_DEBUG_ZPAGES` | Enables zpages, which can be used for collecting and viewing in-memory traces. | |
+| services/ocm/pkg/config/log.go | `OCIS_LOG_LEVEL;OCM_LOG_LEVEL` | The log level. Valid values are: 'panic', 'fatal', 'error', 'warn', 'info', 'debug', 'trace'." | |
+| | `OCIS_LOG_PRETTY;OCM_LOG_PRETTY` | Activates pretty log output. | |
+| | `OCIS_LOG_COLOR;OCM_LOG_COLOR` | Activates colorized log output. | |
+| | `OCIS_LOG_FILE;OCM_LOG_FILE` | The path to the log file. Activates logging to this file if set. | |
+| services/ocm/pkg/config/tracing.go | `OCIS_TRACING_ENABLED;OCM_TRACING_ENABLED` | Activates tracing. | |
+| | `OCIS_TRACING_TYPE;OCM_TRACING_TYPE` | The type of tracing. Defaults to '', which is the same as 'jaeger'. Allowed tracing types are 'jaeger' and '' as of now."` | |
+| | `OCIS_TRACING_ENDPOINT;OCM_TRACING_ENDPOINT` | The endpoint of the tracing agent. | |
+| | `OCIS_TRACING_COLLECTOR;OCM_TRACING_COLLECTOR` | The HTTP endpoint for sending spans directly to a collector, i.e. http://jaeger-collector:14268/api/traces. Only used if the tracing endpoint is unset. | |
+| services/ocs/pkg/config/config.go | `OCIS_CACHE_STORE;OCS_PRESIGNEDURL_SIGNING_KEYS_STORE` | The type of the signing key store. Supported values are: 'redis-sentinel' and 'nats-js-kv'. See the text description for details. | |
+| | `OCIS_CACHE_STORE_NODES;OCS_PRESIGNEDURL_SIGNING_KEYS_STORE_NODES` | A list of nodes to access the configured store. Note that the behaviour how nodes are used is dependent on the library of the configured store. See the Environment Variable Types description for more details. | |
+| | `OCIS_CACHE_TTL;OCS_PRESIGNEDURL_SIGNING_KEYS_STORE_TTL` | Default time to live for signing keys. See the Environment Variable Types description for more details. | |
+| | `OCIS_CACHE_AUTH_USERNAME;OCS_PRESIGNEDURL_SIGNING_KEYS_STORE_AUTH_USERNAME` | The username to authenticate with the store. Only applies when store type 'nats-js-kv' is configured. | |
+| | `OCIS_CACHE_AUTH_PASSWORD;OCS_PRESIGNEDURL_SIGNING_KEYS_STORE_AUTH_PASSWORD` | The password to authenticate with the store. Only applies when store type 'nats-js-kv' is configured. | |
+| services/policies/pkg/config/config.go | `OCIS_EVENTS_AUTH_USERNAME;POLICIES_EVENTS_AUTH_USERNAME` | The username to authenticate with the events broker. The events broker is the ocis service which receives and delivers events between the services. | |
+| | `OCIS_EVENTS_AUTH_PASSWORD;POLICIES_EVENTS_AUTH_PASSWORD` | The password to authenticate with the events broker. The events broker is the ocis service which receives and delivers events between the services. | |
+| services/policies/pkg/config/tracing.go | `OCIS_TRACING_ENABLED;POLICIES_TRACING_ENABLED` | Activates tracing. | |
+| | `OCIS_TRACING_TYPE;POLICIES_TRACING_TYPE` | The type of tracing. Defaults to '', which is the same as 'jaeger'. Allowed tracing types are 'jaeger' and '' as of now."` | |
+| | `OCIS_TRACING_ENDPOINT;POLICIES_TRACING_ENDPOINT` | The endpoint of the tracing agent. | |
+| | `OCIS_TRACING_COLLECTOR;POLICIES_TRACING_COLLECTOR` | The HTTP endpoint for sending spans directly to a collector, i.e. http://jaeger-collector:14268/api/traces. Only used if the tracing endpoint is unset. | |
+| services/postprocessing/pkg/config/config.go | `POSTPROCESSING_RETRY_BACKOFF_DURATION` | The base for the exponential backoff duration before retrying a failed postprocessing step. See the Environment Variable Types description for more details. | |
+| | `POSTPROCESSING_MAX_RETRIES` | The maximum number of retries for a failed postprocessing step. | |
+| | `OCIS_EVENTS_AUTH_USERNAME;POSTPROCESSING_EVENTS_AUTH_USERNAME` | The username to authenticate with the events broker. The events broker is the ocis service which receives and delivers events between the services. | |
+| | `OCIS_EVENTS_AUTH_PASSWORD;POSTPROCESSING_EVENTS_AUTH_PASSWORD` | The password to authenticate with the events broker. The events broker is the ocis service which receives and delivers events between the services. | |
+| | `OCIS_PERSISTENT_STORE_AUTH_USERNAME;POSTPROCESSING_STORE_AUTH_USERNAME` | The username to authenticate with the store. Only applies when store type 'nats-js-kv' is configured. | |
+| | `OCIS_PERSISTENT_STORE_AUTH_PASSWORD;POSTPROCESSING_STORE_AUTH_PASSWORD` | The password to authenticate with the store. Only applies when store type 'nats-js-kv' is configured. | |
+| services/postprocessing/pkg/config/tracing.go | `OCIS_TRACING_ENABLED;POSTPROCESSING_TRACING_ENABLED` | Activates tracing. | |
+| | `OCIS_TRACING_TYPE;POSTPROCESSING_TRACING_TYPE` | The type of tracing. Defaults to '', which is the same as 'jaeger'. Allowed tracing types are 'jaeger' and '' as of now."` | |
+| | `OCIS_TRACING_ENDPOINT;POSTPROCESSING_TRACING_ENDPOINT` | The endpoint of the tracing agent. | |
+| | `OCIS_TRACING_COLLECTOR;POSTPROCESSING_TRACING_COLLECTOR` | The HTTP endpoint for sending spans directly to a collector, i.e. http://jaeger-collector:14268/api/traces. Only used if the tracing endpoint is unset. | |
+| services/proxy/pkg/config/config.go | `OCIS_CACHE_AUTH_USERNAME;PROXY_OIDC_USERINFO_CACHE_AUTH_USERNAME` | The username to authenticate with the cache. Only applies when store type 'nats-js-kv' is configured. | |
+| | `OCIS_CACHE_AUTH_PASSWORD;PROXY_OIDC_USERINFO_CACHE_AUTH_PASSWORD` | The password to authenticate with the cache. Only applies when store type 'nats-js-kv' is configured. | |
+| | `OCIS_CACHE_STORE;PROXY_PRESIGNEDURL_SIGNING_KEYS_STORE` | The type of the signing key store. Supported values are: 'redis-sentinel' and 'nats-js-kv'. See the text description for details. | |
+| | `OCIS_CACHE_STORE_NODES;PROXY_PRESIGNEDURL_SIGNING_KEYS_STORE_NODES` | A list of nodes to access the configured store. Note that the behaviour how nodes are used is dependent on the library of the configured store. See the Environment Variable Types description for more details. | |
+| | `OCIS_CACHE_TTL;PROXY_PRESIGNEDURL_SIGNING_KEYS_STORE_TTL` | Default time to live for signing keys. See the Environment Variable Types description for more details. | |
+| | `OCIS_CACHE_DISABLE_PERSISTENCE;PROXY_PRESIGNEDURL_SIGNING_KEYS_STORE_DISABLE_PERSISTENCE` | Disables persistence of the store. Only applies when store type 'nats-js-kv' is configured. Defaults to true. | |
+| | `OCIS_CACHE_AUTH_USERNAME;PROXY_PRESIGNEDURL_SIGNING_KEYS_STORE_AUTH_USERNAME` | The username to authenticate with the store. Only applies when store type 'nats-js-kv' is configured. | |
+| | `OCIS_CACHE_AUTH_PASSWORD;PROXY_PRESIGNEDURL_SIGNING_KEYS_STORE_AUTH_PASSWORD` | The password to authenticate with the store. Only applies when store type 'nats-js-kv' is configured. | |
+| | `OCIS_SERVICE_ACCOUNT_ID;PROXY_SERVICE_ACCOUNT_ID` | The ID of the service account the service should use. See the 'auth-service' service description for more details. | |
+| | `OCIS_SERVICE_ACCOUNT_SECRET;PROXY_SERVICE_ACCOUNT_SECRET` | The service account secret. | |
+| services/search/pkg/config/config.go | `OCIS_SERVICE_ACCOUNT_ID;SEARCH_SERVICE_ACCOUNT_ID` | The ID of the service account the service should use. See the 'auth-service' service description for more details. | |
+| | `OCIS_SERVICE_ACCOUNT_SECRET;SEARCH_SERVICE_ACCOUNT_SECRET` | The service account secret. | |
+| services/search/pkg/config/content.go | `SEARCH_EXTRACTOR_TIKA_CLEAN_STOP_WORDS` | Defines if stop words should be cleaned or not. See the documentation for more details. | |
+| services/search/pkg/config/search.go | `OCIS_EVENTS_AUTH_USERNAME;SEARCH_EVENTS_AUTH_USERNAME` | The username to authenticate with the events broker. The events broker is the ocis service which receives and delivers events between the services. | |
+| | `OCIS_EVENTS_AUTH_PASSWORD;SEARCH_EVENTS_AUTH_PASSWORD` | The password to authenticate with the events broker. The events broker is the ocis service which receives and delivers events between the services. | |
+| services/settings/pkg/config/config.go | `SETTINGS_SERVICE_ACCOUNT_IDS;OCIS_SERVICE_ACCOUNT_ID` | The list of all service account IDs. These will be assigned the hidden 'service-account' role. Note: When using 'OCIS_SERVICE_ACCOUNT_ID' this will contain only one value while 'SETTINGS_SERVICE_ACCOUNT_IDS' can have multiple. See the 'auth-service' service description for more details about service accounts. | |
+| | `OCIS_DEFAULT_LANGUAGE` | The default language used by services and the WebUI. If not defined, English will be used as default. See the documentation for more details. | |
+| | `OCIS_CACHE_DISABLE_PERSISTENCE;SETTINGS_CACHE_DISABLE_PERSISTENCE` | Disables persistence of the cache. Only applies when store type 'nats-js-kv' is configured. Defaults to false. | |
+| | `OCIS_CACHE_AUTH_USERNAME;SETTINGS_CACHE_AUTH_USERNAME` | The username to authenticate with the cache. Only applies when store type 'nats-js-kv' is configured. | |
+| | `OCIS_CACHE_AUTH_PASSWORD;SETTINGS_CACHE_AUTH_PASSWORD` | The password to authenticate with the cache. Only applies when store type 'nats-js-kv' is configured. | |
+| | `OCIS_EVENTS_AUTH_USERNAME;SETTINGS_EVENTS_AUTH_USERNAME` | The username to authenticate with the cache. Only applies when store type 'nats-js-kv' is configured. | |
+| | `OCIS_EVENTS_AUTH_PASSWORD;SETTINGS_EVENTS_AUTH_PASSWORD` | The password to authenticate with the cache. Only applies when store type 'nats-js-kv' is configured. | |
+| services/sharing/pkg/config/config.go | `OCIS_SHARING_PUBLIC_WRITEABLE_SHARE_MUST_HAVE_PASSWORD;SHARING_PUBLIC_WRITEABLE_SHARE_MUST_HAVE_PASSWORD` | Set this to true if you want to enforce passwords on Uploader, Editor or Contributor shares. If not using the global OCIS_SHARING_PUBLIC_WRITEABLE_SHARE_MUST_HAVE_PASSWORD, you must define the FRONTEND_OCS_PUBLIC_WRITEABLE_SHARE_MUST_HAVE_PASSWORD in the frontend service. | |
+| | `OCIS_SHARING_PUBLIC_SHARE_MUST_HAVE_PASSWORD;SHARING_PUBLIC_SHARE_MUST_HAVE_PASSWORD` | Set this to true if you want to enforce passwords on all public shares. | |
+| | `OCIS_EVENTS_AUTH_USERNAME;SHARING_EVENTS_AUTH_USERNAME` | Username for the events broker. | |
+| | `OCIS_EVENTS_AUTH_PASSWORD;SHARING_EVENTS_AUTH_PASSWORD` | Password for the events broker. | |
+| | `OCIS_PASSWORD_POLICY_DISABLED;SHARING_PASSWORD_POLICY_DISABLED` | Disable the password policy. Defaults to false if not set. | |
+| | `OCIS_PASSWORD_POLICY_MIN_CHARACTERS;SHARING_PASSWORD_POLICY_MIN_CHARACTERS` | Define the minimum password length. Defaults to 0 if not set. | 0 |
+| | `OCIS_PASSWORD_POLICY_MIN_LOWERCASE_CHARACTERS;SHARING_PASSWORD_POLICY_MIN_LOWERCASE_CHARACTERS` | Define the minimum number of lowercase characters. Defaults to 0 if not set. | 0 |
+| | `OCIS_PASSWORD_POLICY_MIN_UPPERCASE_CHARACTERS;SHARING_PASSWORD_POLICY_MIN_UPPERCASE_CHARACTERS` | Define the minimum number of uppercase characters. Defaults to 0 if not set. | 0 |
+| | `OCIS_PASSWORD_POLICY_MIN_DIGITS;SHARING_PASSWORD_POLICY_MIN_DIGITS` | Define the minimum number of digits. Defaults to 0 if not set. | 0 |
+| | `OCIS_PASSWORD_POLICY_MIN_SPECIAL_CHARACTERS;SHARING_PASSWORD_POLICY_MIN_SPECIAL_CHARACTERS` | Define the minimum number of special characters. Defaults to 0 if not set. | 0 |
+| | `OCIS_PASSWORD_POLICY_BANNED_PASSWORDS_LIST;SHARING_PASSWORD_POLICY_BANNED_PASSWORDS_LIST` | Path to the 'banned passwords list' file. See the documentation for more details. | |
+| services/sse/pkg/config/config.go | `OCIS_LOG_LEVEL;SSE_LOG_LEVEL` | The log level. Valid values are: 'panic', 'fatal', 'error', 'warn', 'info', 'debug', 'trace'." | |
+| | `OCIS_LOG_PRETTY;SSE_LOG_PRETTY` | Activates pretty log output. | |
+| | `OCIS_LOG_COLOR;SSE_LOG_COLOR` | Activates colorized log output. | |
+| | `OCIS_LOG_FILE;SSE_LOG_FILE` | The path to the log file. Activates logging to this file if set. | |
+| | `SSE_DEBUG_ADDR` | Bind address of the debug server, where metrics, health, config and debug endpoints will be exposed. | |
+| | `SSE_DEBUG_TOKEN` | Token to secure the metrics endpoint. | |
+| | `SSE_DEBUG_PPROF` | Enables pprof, which can be used for profiling. | |
+| | `SSE_DEBUG_ZPAGES` | Enables zpages, which can be used for collecting and viewing in-memory traces. | |
+| | `OCIS_EVENTS_ENDPOINT;SSE_EVENTS_ENDPOINT` | The address of the event system. The event system is the message queuing service. It is used as message broker for the microservice architecture. | |
+| | `OCIS_EVENTS_CLUSTER;SSE_EVENTS_CLUSTER` | The clusterID of the event system. The event system is the message queuing service. It is used as message broker for the microservice architecture. Mandatory when using NATS as event system. | |
+| | `OCIS_INSECURE;SSE_EVENTS_TLS_INSECURE` | Whether to verify the server TLS certificates. | |
+| | `OCIS_EVENTS_TLS_ROOT_CA_CERTIFICATE;SSE_EVENTS_TLS_ROOT_CA_CERTIFICATE` | The root CA certificate used to validate the server's TLS certificate. If provided NOTIFICATIONS_EVENTS_TLS_INSECURE will be seen as false. | |
+| | `OCIS_EVENTS_ENABLE_TLS;SSE_EVENTS_ENABLE_TLS` | Enable TLS for the connection to the events broker. The events broker is the ocis service which receives and delivers events between the services.. | |
+| | `OCIS_EVENTS_AUTH_USERNAME;SSE_EVENTS_AUTH_USERNAME` | The username to authenticate with the events broker. The events broker is the ocis service which receives and delivers events between the services.. | |
+| | `OCIS_EVENTS_AUTH_PASSWORD;SSE_EVENTS_AUTH_PASSWORD` | The password to authenticate with the events broker. The events broker is the ocis service which receives and delivers events between the services.. | |
+| | `OCIS_CORS_ALLOW_ORIGINS;SSE_CORS_ALLOW_ORIGINS` | A list of allowed CORS origins. See following chapter for more details: _Access-Control-Allow-Origin_ at https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Origin. See the Environment Variable Types description for more details. | |
+| | `OCIS_CORS_ALLOW_METHODS;SSE_CORS_ALLOW_METHODS` | A list of allowed CORS methods. See following chapter for more details: _Access-Control-Allow-Methods_ at https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Methods. See the Environment Variable Types description for more details. | |
+| | `OCIS_CORS_ALLOW_HEADERS;SSE_CORS_ALLOW_HEADERS` | A list of allowed CORS headers. See following chapter for more details: _Access-Control-Allow-Headers_ at https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Headers. See the Environment Variable Types description for more details. | |
+| | `OCIS_CORS_ALLOW_CREDENTIALS;SSE_CORS_ALLOW_CREDENTIALS` | Allow credentials for CORS.See following chapter for more details: _Access-Control-Allow-Credentials_ at https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Credentials. | |
+| | `SSE_HTTP_ADDR` | The bind address of the HTTP service. | |
+| | `SSE_HTTP_ROOT` | The root path of the HTTP service. | |
+| | `OCIS_JWT_SECRET;SSE_JWT_SECRET` | The secret to mint and validate jwt tokens. | |
+| services/sse/pkg/config/tracing.go | `OCIS_TRACING_ENABLED;SSE_TRACING_ENABLED` | Activates tracing. | |
+| | `OCIS_TRACING_TYPE;SSE_TRACING_TYPE` | The type of tracing. Defaults to '', which is the same as 'jaeger'. Allowed tracing types are 'jaeger' and '' as of now."` | |
+| | `OCIS_TRACING_ENDPOINT;SSE_TRACING_ENDPOINT` | The endpoint of the tracing agent. | |
+| | `OCIS_TRACING_COLLECTOR;SSE_TRACING_COLLECTOR` | The HTTP endpoint for sending spans directly to a collector, i.e. http://jaeger-collector:14268/api/traces. Only used if the tracing endpoint is unset. | |
+| services/storage-system/pkg/config/config.go | `OCIS_CACHE_DISABLE_PERSISTENCE;STORAGE_SYSTEM_CACHE_DISABLE_PERSISTENCE` | Disables persistence of the cache. Only applies when store type 'nats-js-kv' is configured. Defaults to false. | false |
+| | `OCIS_CACHE_AUTH_USERNAME;STORAGE_SYSTEM_CACHE_AUTH_USERNAME` | Username for the configured store. Only applies when store type 'nats-js-kv' is configured. | |
+| | `OCIS_CACHE_AUTH_PASSWORD;STORAGE_SYSTEM_CACHE_AUTH_PASSWORD` | TPassword for the configured store. Only applies when store type 'nats-js-kv' is configured. | |
+| services/storage-users/pkg/config/config.go | `OCIS_GATEWAY_GRPC_ADDR;STORAGE_USERS_GATEWAY_GRPC_ADDR` | The bind address of the gateway GRPC address. | |
+| | `OCIS_MACHINE_AUTH_API_KEY;STORAGE_USERS_MACHINE_AUTH_API_KEY` | Machine auth API key used to validate internal requests necessary for the access to resources from other services. | |
+| | `STORAGE_USERS_CLI_MAX_ATTEMPTS_RENAME_FILE` | The maximum number of attempts to rename a file when a user restores a file to an existing destination with the same name. The minimum value is 100. | |
+| | `OCIS_EVENTS_AUTH_USERNAME;STORAGE_USERS_EVENTS_AUTH_USERNAME` | The username to authenticate with the events broker. The events broker is the ocis service which receives and delivers events between the services. | |
+| | `OCIS_EVENTS_AUTH_PASSWORD;STORAGE_USERS_EVENTS_AUTH_PASSWORD` | The password to authenticate with the events broker. The events broker is the ocis service which receives and delivers events between the services. | |
+| | `OCIS_CACHE_DISABLE_PERSISTENCE;STORAGE_USERS_STAT_CACHE_DISABLE_PERSISTENCE` | Disables persistence of the stat cache. Only applies when store type 'nats-js-kv' is configured. Defaults to false. | false |
+| | `OCIS_CACHE_DISABLE_PERSISTENCE;STORAGE_USERS_FILEMETADATA_CACHE_DISABLE_PERSISTENCE` | Disables persistence of the file metadata cache. Only applies when store type 'nats-js-kv' is configured. Defaults to false. | false |
+| | `OCIS_CACHE_AUTH_USERNAME;STORAGE_USERS_FILEMETADATA_CACHE_AUTH_USERNAME` | The username to authenticate with the cache store. Only applies when store type 'nats-js-kv' is configured. | |
+| | `OCIS_CACHE_AUTH_PASSWORD;STORAGE_USERS_FILEMETADATA_CACHE_AUTH_PASSWORD` | The password to authenticate with the cache store. Only applies when store type 'nats-js-kv' is configured. | |
+| | `OCIS_CACHE_DISABLE_PERSISTENCE;STORAGE_USERS_ID_CACHE_DISABLE_PERSISTENCE` | Disables persistence of the id cache. Only applies when store type 'nats-js-kv' is configured. Defaults to false. | false |
+| | `OCIS_CACHE_AUTH_USERNAME;STORAGE_USERS_ID_CACHE_AUTH_USERNAME` | The username to authenticate with the cache store. Only applies when store type 'nats-js-kv' is configured | |
+| | `OCIS_CACHE_AUTH_PASSWORD;STORAGE_USERS_ID_CACHE_AUTH_PASSWORD` | The password to authenticate with the cache store. Only applies when store type 'nats-js-kv' is configured. | |
+| | `OCIS_SERVICE_ACCOUNT_ID;STORAGE_USERS_SERVICE_ACCOUNT_ID` | The ID of the service account the service should use. See the 'auth-service' service description for more details. | |
+| | `OCIS_SERVICE_ACCOUNT_SECRET;STORAGE_USERS_SERVICE_ACCOUNT_SECRET` | The service account secret. | |
+| services/userlog/pkg/config/config.go | `OCIS_DEFAULT_LANGUAGE` | The default language used by services and the WebUI. If not defined, English will be used as default. See the documentation for more details. | |
+| | `OCIS_PERSISTENT_STORE_AUTH_USERNAME;USERLOG_STORE_AUTH_USERNAME` | The username to authenticate with the store. Only applies when store type 'nats-js-kv' is configured. | |
+| | `OCIS_PERSISTENT_STORE_AUTH_PASSWORD;USERLOG_STORE_AUTH_PASSWORD` | The password to authenticate with the store. Only applies when store type 'nats-js-kv' is configured. | |
+| | `OCIS_EVENTS_AUTH_USERNAME;USERLOG_EVENTS_AUTH_USERNAME` | The username to authenticate with the events broker. The events broker is the ocis service which receives and delivers events between the services. | |
+| | `OCIS_EVENTS_AUTH_PASSWORD;USERLOG_EVENTS_AUTH_PASSWORD` | The password to authenticate with the events broker. The events broker is the ocis service which receives and delivers events between the services. | |
+| | `OCIS_SERVICE_ACCOUNT_ID;USERLOG_SERVICE_ACCOUNT_ID` | The ID of the service account the service should use. See the 'auth-service' service description for more details. | |
+| | `OCIS_SERVICE_ACCOUNT_SECRET;USERLOG_SERVICE_ACCOUNT_SECRET` | The service account secret. | |
+| services/web/pkg/config/options.go | `WEB_OPTION_LOGIN_URL` | Specifies the target URL to the login page. This is helpful when an external IdP is used. This option is disabled by default. Example URL like: https://www.myidp.com/login. | | |
+| | `WEB_OPTION_DISABLED_EXTENSIONS` | A list to disable specific Web extensions identified by their ID. The ID can e.g. be taken from the 'index.ts' file of the web extension. Example: 'com.github.owncloud.web.files.search,com.github.owncloud.web.files.print'. See the Environment Variable Types description for more details. | |
+| | `WEB_OPTION_USER_LIST_REQUIRES_FILTER` | Defines whether one or more filters must be set in order to list users in the Web admin settings. Set this option to 'true' if running in an environment with a lot of users and listing all users could slow down performance. Defaults to 'false'. | false |
+| | `WEB_OPTION_EMBED_ENABLED` | Defines whether Web should be running in 'embed' mode. Setting this to 'true' will enable a stripped down version of Web with reduced functionality used to integrate Web into other applications like via iFrame. Setting it to 'false' or not setting it (default) will run Web as usual with all functionality enabled. See the text description for more details. | |
+| | `WEB_OPTION_EMBED_TARGET` | Defines how Web is being integrated when running in 'embed' mode. Currently, the only supported options are '' (empty) and 'location'. With '' which is the default, Web will run regular as defined via the 'embed.enabled' config option. With 'location', Web will run embedded as location picker. Resource selection will be disabled and the selected resources array always includes the current folder as the only item. See the text description for more details. | |
+| | `WEB_OPTION_EMBED_MESSAGES_ORIGIN` | Defines a URL under which Web can be integrated via iFrame in 'embed' mode. Note that setting this is mandatory when running Web in 'embed' mode. Use '*' as value to allow running the iFrame under any URL, although this is not recommended for security reasons. See the text description for more details. | |
+| | `WEB_OPTION_EMBED_DELEGATE_AUTHENTICATION` | Defines whether Web should require authentication to be done by the parent application when running in 'embed' mode. If set to 'true' Web will not try to authenticate the user on its own but will require an access token coming from the parent application. Defaults to being unset. | |
+| | `WEB_OPTION_EMBED_DELEGATE_AUTHENTICATION_ORIGIN` | Defines the host to validate the message event origin against when running Web in 'embed' mode with delegated authentication. Defaults to event message origin validation being omitted, which is only recommended for development setups. | |
+| | `WEB_OPTION_CONCURRENT_REQUESTS_RESOURCE_BATCH_ACTIONS` | Defines the maximum number of concurrent requests per file/folder/space batch action. Defaults to 4. | |
+| | `WEB_OPTION_CONCURRENT_REQUESTS_SSE` | Defines the maximum number of concurrent requests in SSE event handlers. Defaults to 4. | |
+| | `WEB_OPTION_CONCURRENT_REQUESTS_SHARES_CREATE` | Defines the maximum number of concurrent requests per sharing invite batch. Defaults to 4. | |
+| | `WEB_OPTION_CONCURRENT_REQUESTS_SHARES_LIST` | Defines the maximum number of concurrent requests when loading individual share information inside listings. Defaults to 2. | |
diff --git a/modules/developer/pages/services/general-info/envvars/env-var-deltas/4.0.0-5.0.0-removed.adoc b/modules/developer/pages/services/general-info/envvars/env-var-deltas/4.0.0-5.0.0-removed.adoc
new file mode 100644
index 00000000..02a9cd46
--- /dev/null
+++ b/modules/developer/pages/services/general-info/envvars/env-var-deltas/4.0.0-5.0.0-removed.adoc
@@ -0,0 +1,16 @@
+:toc: right
+:toclevels: 3
+
+= Removed Variables between oCIS 4.0.0 and oCIS 5.0.0
+
+| File | Variable | Replacement | Description |
+|------------------------------------------|--------------------------------------|-------------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| services/auth-basic/pkg/config/config.go | `LDAP_BIND_PASSWORD` | `OCIS_LDAP_BIND_PASSWORD` | Password to use for authenticating the 'bind_dn'. |
+| services/graph/pkg/config/config.go | `LDAP_BIND_PASSWORD` | `OCIS_LDAP_BIND_PASSWORD` | Password to use for authenticating the 'bind_dn'. |
+| services/groups/pkg/config/config.go | `LDAP_BIND_PASSWORD` | `OCIS_LDAP_BIND_PASSWORD` | Password to use for authenticating the 'bind_dn'. |
+| services/idp/pkg/config/config.go | `LDAP_BIND_PASSWORD` | `OCIS_LDAP_BIND_PASSWORD` | Password to use for authenticating the 'bind_dn'. |
+| services/sharing/pkg/config/config.go | `SHARING_EVENTS_TLS_ROOT_CA_CERT` | `SHARING_EVENTS_TLS_ROOT_CA_CERTIFICATE` | The root CA certificate used to validate the server's TLS certificate. If provided SHARING_EVENTS_TLS_INSECURE will be seen as false. |
+| services/users/pkg/config/config.go | `LDAP_BIND_PASSWORD` | `OCIS_LDAP_BIND_PASSWORD` | Password to use for authenticating the 'bind_dn'. |
+| | `LDAP_USER_SCHEMA_ID_IS_OCTETSTRING` | `OCIS_LDAP_USER_SCHEMA_ID_IS_OCTETSTRING` | Set this to true if the defined 'ID' attribute for users is of the 'OCTETSTRING' syntax. This is e.g. required when using the 'objectGUID' attribute of Active Directory for the user ID's. |
+| services/web/pkg/config/options.go | `WEB_OPTION_IMPRINT_URL` | To be configured via the `theme.json` file | Specifies the target URL for the imprint link valid for the ocis instance in the account menu. |
+| | `WEB_OPTION_PRIVACY_URL` | To be configured via the `theme.json` file | Specifies the target URL for the privacy link valid for the ocis instance in the account menu. |
diff --git a/modules/developer/pages/services/general-info/envvars/env-var-deltas/5.0.0-7.0.0-added.adoc b/modules/developer/pages/services/general-info/envvars/env-var-deltas/5.0.0-7.0.0-added.adoc
new file mode 100644
index 00000000..be1d5704
--- /dev/null
+++ b/modules/developer/pages/services/general-info/envvars/env-var-deltas/5.0.0-7.0.0-added.adoc
@@ -0,0 +1,132 @@
+:toc: right
+:toclevels: 3
+
+Note that the links provided in the service column are non functional when clicked.
+
+| Service | Variable | Description | Default |
+| --- | --- | --- | --- |
+| xref:deployment/services/env-vars-special-scope.adoc[Special Scope Envvars] | OCIS_ASSET_THEMES_PATH | Serve ownCloud themes from a path on the filesystem instead of the builtin assets. If not defined, the root directory derives from $OCIS_BASE_DATA_PATH/web/assets/themes | /var/lib/ocis/web/assets/themes |
+| | OCIS_DISABLE_VERSIONING | Disables versioning of files. When set to true, new uploads with the same filename will overwrite existing files instead of creating a new version. | false |
+| | OCIS_SHOW_USER_EMAIL_IN_RESULTS | Include user email addresses in responses. If absent or set to false emails will be omitted from results. Please note that admin users can always see all email addresses. | false |
+| | OCIS_TRANSLATION_PATH | (optional) Set this to a path with custom translations to overwrite the builtin translations. Note that file and folder naming rules apply, see the documentation for more details. | |
+| | OCIS_WOPI_DISABLE_CHAT | Disable chat in the office web frontend. This feature applies to OnlyOffice and Microsoft. | false |
+| xref:{s-path}/activitylog.adoc[Activitylog] | ACTIVITYLOG_TRANSLATION_PATH | (optional) Set this to a path with custom translations to overwrite the builtin translations. Note that file and folder naming rules apply, see the documentation for more details. | |
+| xref:{s-path}/antivirus.adoc[Antivirus] | ANTIVIRUS_WORKERS | The number of concurrent go routines that fetch events from the event queue. | 10 |
+| xref:{s-path}/auth-app.adoc[Auth-App] | AUTH_APP_DEBUG_ADDR | Bind address of the debug server, where metrics, health, config and debug endpoints will be exposed. | 127.0.0.1:9245 |
+| | AUTH_APP_DEBUG_PPROF | Enables pprof, which can be used for profiling. | false |
+| | AUTH_APP_DEBUG_TOKEN | Token to secure the metrics endpoint. | |
+| | AUTH_APP_DEBUG_ZPAGES | Enables zpages, which can be used for collecting and viewing traces in-memory. | false |
+| | AUTH_APP_ENABLE_IMPERSONATION | Allows admins to create app tokens for other users. Used for migration. Do NOT use in productive deployments. | false |
+| | AUTH_APP_GRPC_ADDR | The bind address of the GRPC service. | 127.0.0.1:9246 |
+| | AUTH_APP_GRPC_PROTOCOL | The transport protocol of the GRPC service. | tcp |
+| | AUTH_APP_JWT_SECRET | The secret to mint and validate jwt tokens. | |
+| | AUTH_APP_LOG_COLOR | Activates colorized log output. | false |
+| | AUTH_APP_LOG_FILE | The path to the log file. Activates logging to this file if set. | |
+| | AUTH_APP_LOG_LEVEL | The log level. Valid values are: 'panic', 'fatal', 'error', 'warn', 'info', 'debug', 'trace'. | |
+| | AUTH_APP_LOG_PRETTY | Activates pretty log output. | false |
+| | AUTH_APP_MACHINE_AUTH_API_KEY | The machine auth API key used to validate internal requests necessary to access resources from other services. | |
+| | AUTH_APP_SKIP_USER_GROUPS_IN_TOKEN | Disables the encoding of the user’s group memberships in the access token. This reduces the token size, especially when users are members of a large number of groups. | false |
+| | AUTH_APP_TRACING_COLLECTOR | The HTTP endpoint for sending spans directly to a collector, i.e. http://jaeger-collector:14268/api/traces. Only used if the tracing endpoint is unset. | |
+| | AUTH_APP_TRACING_ENABLED | Activates tracing. | false |
+| | AUTH_APP_TRACING_ENDPOINT | The endpoint of the tracing agent. | |
+| | AUTH_APP_TRACING_TYPE | The type of tracing. Defaults to '', which is the same as 'jaeger'. Allowed tracing types are 'jaeger' and '' as of now. | |
+| xref:{s-path}/collaboration.adoc[Collaboration] | COLLABORATION_APP_ADDR | The URL where the WOPI app is located, such as https://127.0.0.1:8080. | https://127.0.0.1:9980 |
+| | COLLABORATION_APP_DESCRIPTION | App description | Open office documents with Collabora |
+| | COLLABORATION_APP_ICON | Icon for the app | image-edit |
+| | COLLABORATION_APP_INSECURE | Skip TLS certificate verification when connecting to the WOPI app | false |
+| | COLLABORATION_APP_LICENSE_CHECK_ENABLE | Enable license checking to edit files. Needs to be enabled when using Microsoft365 with the business flow. | false |
+| | COLLABORATION_APP_NAME | The name of the app which is shown to the user. You can chose freely but you are limited to a single word without special characters or whitespaces. We recommend to use pascalCase like 'CollaboraOnline'. | Collabora |
+| | COLLABORATION_APP_PRODUCT | The WebOffice app, either Collabora, OnlyOffice, Microsoft365 or MicrosoftOfficeOnline. | Collabora |
+| | COLLABORATION_APP_PROOF_DISABLE | Disable the proof keys verification | false |
+| | COLLABORATION_APP_PROOF_DURATION | Duration for the proof keys to be cached in memory, using time.ParseDuration format. If the duration can’t be parsed, we’ll use the default 12h as duration | 12h |
+| | COLLABORATION_CS3API_DATAGATEWAY_INSECURE | Connect to the CS3API data gateway insecurely. | false |
+| | COLLABORATION_DEBUG_ADDR | Bind address of the debug server, where metrics, health, config and debug endpoints will be exposed. | 127.0.0.1:9304 |
+| | COLLABORATION_DEBUG_PPROF | Enables pprof, which can be used for profiling. | false |
+| | COLLABORATION_DEBUG_TOKEN | Token to secure the metrics endpoint. | |
+| | COLLABORATION_DEBUG_ZPAGES | Enables zpages, which can be used for collecting and viewing in-memory traces. | false |
+| | COLLABORATION_GRPC_ADDR | The bind address of the GRPC service. | 127.0.0.1:9301 |
+| | COLLABORATION_GRPC_PROTOCOL | The transport protocol of the GRPC service. | tcp |
+| | COLLABORATION_HTTP_ADDR | The bind address of the HTTP service. | 127.0.0.1:9300 |
+| | COLLABORATION_LOG_COLOR | Activates colorized log output. | false |
+| | COLLABORATION_LOG_FILE | The path to the log file. Activates logging to this file if set. | |
+| | COLLABORATION_LOG_LEVEL | The log level. Valid values are: 'panic', 'fatal', 'error', 'warn', 'info', 'debug', 'trace'. | |
+| | COLLABORATION_LOG_PRETTY | Activates pretty log output. | false |
+| | COLLABORATION_STORE | The type of the store. Supported values are: 'memory', 'nats-js-kv', 'redis-sentinel', 'noop'. See the text description for details. | nats-js-kv |
+| | COLLABORATION_STORE_AUTH_PASSWORD | The password to authenticate with the store. Only applies when store type 'nats-js-kv' is configured. | |
+| | COLLABORATION_STORE_AUTH_USERNAME | The username to authenticate with the store. Only applies when store type 'nats-js-kv' is configured. | |
+| | COLLABORATION_STORE_DATABASE | The database name the configured store should use. | collaboration |
+| | COLLABORATION_STORE_NODES | A list of nodes to access the configured store. This has no effect when 'memory' store is configured. Note that the behaviour how nodes are used is dependent on the library of the configured store. See the Environment Variable Types description for more details. | [127.0.0.1:9233] |
+| | COLLABORATION_STORE_TABLE | The database table the store should use. | |
+| | COLLABORATION_STORE_TTL | Time to live for events in the store. Defaults to '30m' (30 minutes). See the Environment Variable Types description for more details. | 30m0s |
+| | COLLABORATION_TRACING_COLLECTOR | The HTTP endpoint for sending spans directly to a collector, i.e. http://jaeger-collector:14268/api/traces. Only used if the tracing endpoint is unset. | |
+| | COLLABORATION_TRACING_ENABLED | Activates tracing. | false |
+| | COLLABORATION_TRACING_ENDPOINT | The endpoint of the tracing agent. | |
+| | COLLABORATION_TRACING_TYPE | The type of tracing. Defaults to '', which is the same as 'jaeger'. Allowed tracing types are 'jaeger' and '' as of now. | |
+| | COLLABORATION_WOPI_DISABLE_CHAT | Disable chat in the office web frontend. This feature applies to OnlyOffice and Microsoft. | false |
+| | COLLABORATION_WOPI_PROXY_SECRET | Optional, the secret to authenticate against the ownCloud Office365 WOPI proxy. This secret can be obtained from ownCloud via the office365 proxy subscription. | |
+| | COLLABORATION_WOPI_PROXY_URL | The URL to the ownCloud Office365 WOPI proxy. Optional. To use this feature, you need an office365 proxy subscription. If you become part of the Microsoft CSP program (https://learn.microsoft.com/en-us/partner-center/enroll/csp-overview), you can use WebOffice without a proxy. | |
+| | COLLABORATION_WOPI_SECRET | Used to mint and verify WOPI JWT tokens and encrypt and decrypt the REVA JWT token embedded in the WOPI JWT token. | |
+| | COLLABORATION_WOPI_SHORTTOKENS | Use short access tokens for WOPI access. This is useful for office packages, like Microsoft Office Online, which have URL length restrictions. If enabled, a persistent store must be configured. | false |
+| | COLLABORATION_WOPI_SRC | The WOPI source base URL containing schema, host and port. Set this to the schema and domain where the collaboration service is reachable for the wopi app, such as https://office.owncloud.test. | https://localhost:9300 |
+| xref:{s-path}/frontend.adoc[Frontend] | FRONTEND_APP_HANDLER_SECURE_VIEW_APP_ADDR | Service name or address of the app provider to use for secure view. Should match the service name or address of the registered CS3 app provider. | com.owncloud.api.collaboration |
+| | FRONTEND_MAX_CONCURRENCY | Maximum number of concurrent go-routines. Higher values can potentially get work done faster but will also cause more load on the system. Values of 0 or below will be ignored and the default value will be used. | 1 |
+| xref:{s-path}/gateway.adoc[Gateway] | GATEWAY_APP_REGISTRY_ENDPOINT | The endpoint of the app-registry service. Can take a service name or a gRPC URI with the dns, kubernetes or unix protocol. | com.owncloud.api.app-registry |
+| | GATEWAY_AUTH_APP_ENDPOINT | The endpoint of the auth-app service. Can take a service name or a gRPC URI with the dns, kubernetes or unix protocol. | com.owncloud.api.auth-app |
+| | GATEWAY_AUTH_BASIC_ENDPOINT | The endpoint of the auth-basic service. Can take a service name or a gRPC URI with the dns, kubernetes or unix protocol. | com.owncloud.api.auth-basic |
+| | GATEWAY_AUTH_BEARER_ENDPOINT | The endpoint of the auth-bearer service. Can take a service name or a gRPC URI with the dns, kubernetes or unix protocol. | |
+| | GATEWAY_AUTH_MACHINE_ENDPOINT | The endpoint of the auth-machine service. Can take a service name or a gRPC URI with the dns, kubernetes or unix protocol. | com.owncloud.api.auth-machine |
+| | GATEWAY_AUTH_SERVICE_ENDPOINT | The endpoint of the auth-service service. Can take a service name or a gRPC URI with the dns, kubernetes or unix protocol. | com.owncloud.api.auth-service |
+| | GATEWAY_GROUPS_ENDPOINT | The endpoint of the groups service. Can take a service name or a gRPC URI with the dns, kubernetes or unix protocol. | com.owncloud.api.groups |
+| | GATEWAY_OCM_ENDPOINT | The endpoint of the ocm service. Can take a service name or a gRPC URI with the dns, kubernetes or unix protocol. | com.owncloud.api.ocm |
+| | GATEWAY_PERMISSIONS_ENDPOINT | The endpoint of the permissions service. Can take a service name or a gRPC URI with the dns, kubernetes or unix protocol. | com.owncloud.api.settings |
+| | GATEWAY_SHARING_ENDPOINT | The endpoint of the shares service. Can take a service name or a gRPC URI with the dns, kubernetes or unix protocol. | com.owncloud.api.sharing |
+| | GATEWAY_STORAGE_PUBLIC_LINK_ENDPOINT | The endpoint of the storage-publiclink service. Can take a service name or a gRPC URI with the dns, kubernetes or unix protocol. | com.owncloud.api.storage-publiclink |
+| | GATEWAY_STORAGE_SHARES_ENDPOINT | The endpoint of the storage-shares service. Can take a service name or a gRPC URI with the dns, kubernetes or unix protocol. | com.owncloud.api.storage-shares |
+| | GATEWAY_STORAGE_USERS_ENDPOINT | The endpoint of the storage-users service. Can take a service name or a gRPC URI with the dns, kubernetes or unix protocol. | com.owncloud.api.storage-users |
+| | GATEWAY_USERS_ENDPOINT | The endpoint of the users service. Can take a service name or a gRPC URI with the dns, kubernetes or unix protocol. | com.owncloud.api.users |
+| xref:{s-path}/graph.adoc[Graph] | GRAPH_AVAILABLE_ROLES | A comma separated list of roles that are available for assignment. | [b1e2218d-eef8-4d4c-b82d-0f1a1b48f3b5 a8d5fe5e-96e3-418d-825b-534dbdf22b99 fb6c3e19-e378-47e5-b277-9732f9de6e21 58c63c02-1d89-4572-916a-870abc5a1b7d 2d00ce52-1fc2-4dbc-8b95-a73b73395f5a 1c996275-f1c9-4e71-abdf-a42f6495e960 312c0871-5ef7-4b3a-85b6-0e4074c64049] |
+| | GRAPH_MAX_CONCURRENCY | The maximum number of concurrent requests the service will handle. | 20 |
+| | GRAPH_TRANSLATION_PATH | (optional) Set this to a path with custom translations to overwrite the builtin translations. Note that file and folder naming rules apply, see the documentation for more details. | |
+| xref:{s-path}/ocm.adoc[OCM] | OCM_OCM_INVITE_MANAGER_TIMEOUT | Timeout specifies a time limit for requests made to OCM endpoints. | 30s |
+| | OCM_OCM_INVITE_MANAGER_TOKEN_EXPIRATION | Expiry duration for invite tokens. | 24h0m0s |
+| | OCM_OCM_STORAGE_DATA_SERVER_URL | URL of the data server, needs to be reachable by the data gateway provided by the frontend service or the user if directly exposed. | http://localhost:9280/data |
+| xref:{s-path}/postprocessing.adoc[Postprocessing] | POSTPROCESSING_WORKERS | The number of concurrent go routines that fetch events from the event queue. | 3 |
+| xref:{s-path}/proxy.adoc[Proxy] | PROXY_AUTOPROVISION_CLAIM_DISPLAYNAME | The name of the OIDC claim that holds the display name. | name |
+| | PROXY_AUTOPROVISION_CLAIM_EMAIL | The name of the OIDC claim that holds the email. | email |
+| | PROXY_AUTOPROVISION_CLAIM_GROUPS | The name of the OIDC claim that holds the groups. | groups |
+| | PROXY_AUTOPROVISION_CLAIM_USERNAME | The name of the OIDC claim that holds the username. | preferred_username |
+| | PROXY_CSP_CONFIG_FILE_LOCATION | The location of the CSP configuration file. | |
+| | PROXY_ENABLE_APP_AUTH | Allow app authentication. This can be used to authenticate 3rd party applications. Note that auth-app service must be running for this feature to work. | false |
+| | PROXY_EVENTS_AUTH_PASSWORD | The password to authenticate with the events broker. The events broker is the ocis service which receives and delivers events between the services. | |
+| | PROXY_EVENTS_AUTH_USERNAME | The username to authenticate with the events broker. The events broker is the ocis service which receives and delivers events between the services. | |
+| | PROXY_EVENTS_CLUSTER | The clusterID of the event system. The event system is the message queuing service. It is used as message broker for the microservice architecture. | ocis-cluster |
+| | PROXY_EVENTS_ENABLE_TLS | Enable TLS for the connection to the events broker. The events broker is the ocis service which receives and delivers events between the services. | false |
+| | PROXY_EVENTS_ENDPOINT | The address of the event system. The event system is the message queuing service. It is used as message broker for the microservice architecture. Set to a empty string to disable emitting events. | 127.0.0.1:9233 |
+| | PROXY_EVENTS_TLS_INSECURE | Whether to verify the server TLS certificates. | false |
+| | PROXY_EVENTS_TLS_ROOT_CA_CERTIFICATE | The root CA certificate used to validate the server’s TLS certificate. If provided PROXY_EVENTS_TLS_INSECURE will be seen as false. | |
+| xref:{s-path}/sharing.adoc[Sharing] | SHARING_USER_JSONCS3_MAX_CONCURRENCY | Maximum number of concurrent go-routines. Higher values can potentially get work done faster but will also cause more load on the system. Values of 0 or below will be ignored and the default value will be used. | 1 |
+| xref:{s-path}/sse.adoc[SSE] | SSE_KEEPALIVE_INTERVAL | To prevent intermediate proxies from closing the SSE connection, send periodic SSE comments to keep it open. | 0s |
+| xref:{s-path}/storage-users.adoc[Storage-Users] | STORAGE_USERS_OCIS_GENERAL_SPACE_PATH_TEMPLATE | Template string to construct the paths of the projects space roots. | |
+| | STORAGE_USERS_OCIS_MAX_CONCURRENCY | Maximum number of concurrent go-routines. Higher values can potentially get work done faster but will also cause more load on the system. Values of 0 or below will be ignored and the default value will be used. | 1 |
+| | STORAGE_USERS_OCIS_PERSONAL_SPACE_PATH_TEMPLATE | Template string to construct the paths of the personal space roots. | |
+| | STORAGE_USERS_PERMISSION_ENDPOINT | Endpoint of the permissions service. The endpoints can differ for 'ocis', 'posix' and 's3ng'. | com.owncloud.api.settings |
+| | STORAGE_USERS_POSIX_GENERAL_SPACE_PATH_TEMPLATE | Template string to construct the paths of the projects space roots. | projects/{{.SpaceId}} |
+| | STORAGE_USERS_POSIX_PERMISSIONS_ENDPOINT | Endpoint of the permissions service. The endpoints can differ for 'ocis', 'posix' and 's3ng'. | com.owncloud.api.settings |
+| | STORAGE_USERS_POSIX_PERSONAL_SPACE_PATH_TEMPLATE | Template string to construct the paths of the personal space roots. | users/{{.User.Username}} |
+| | STORAGE_USERS_POSIX_ROOT | The directory where the filesystem storage will store its data. If not defined, the root directory derives from $OCIS_BASE_DATA_PATH/storage/users. | /var/lib/ocis/storage/users |
+| | STORAGE_USERS_POSIX_SCAN_DEBOUNCE_DELAY | The time in milliseconds to wait before scanning the filesystem for changes after a change has been detected. | 1s |
+| | STORAGE_USERS_POSIX_USE_SPACE_GROUPS | Use space groups to manage permissions on spaces. | false |
+| | STORAGE_USERS_POSIX_WATCH_FOLDER_KAFKA_BROKERS | Comma-separated list of kafka brokers to read the watchfolder events from. | |
+| | STORAGE_USERS_POSIX_WATCH_PATH | Path to the watch directory/file. Only applies to the 'gpfsfileauditlogging' and 'inotifywait' watcher, in which case it is the path of the file audit log file/base directory to watch. | |
+| | STORAGE_USERS_POSIX_WATCH_TYPE | Type of the watcher to use for getting notified about changes to the filesystem. Currently available options are 'inotifywait' (default), 'gpfswatchfolder' and 'gpfsfileauditlogging'. | |
+| | STORAGE_USERS_S3NG_GENERAL_SPACE_PATH_TEMPLATE | Template string to construct the paths of the projects space roots. | |
+| | STORAGE_USERS_S3NG_PERSONAL_SPACE_PATH_TEMPLATE | Template string to construct the paths of the personal space roots. | |
+| | STORAGE_USERS_SERVICE_NAME | Service name to use. Change this when starting an additional storage provider with a custom configuration to prevent it from colliding with the default 'storage-users' service. | storage-users |
+| xref:{s-path}/thumbnails.adoc[Thumbnails] | THUMBNAILS_MAX_CONCURRENT_REQUESTS | Number of maximum concurrent thumbnail requests. Default is 0 which is unlimited. | 0 |
+| | THUMBNAILS_MAX_INPUT_HEIGHT | The maximum height of an input image which is being processed. | 7680 |
+| | THUMBNAILS_MAX_INPUT_IMAGE_FILE_SIZE | The maximum file size of an input image which is being processed. Usable common abbreviations: [KB, KiB, MB, MiB, GB, GiB, TB, TiB, PB, PiB, EB, EiB], example: 2GB. | 50MB |
+| | THUMBNAILS_MAX_INPUT_WIDTH | The maximum width of an input image which is being processed. | 7680 |
+| xref:{s-path}/userlog.adoc[Userlog] | USERLOG_MAX_CONCURRENCY | Maximum number of concurrent go-routines. Higher values can potentially get work done faster but will also cause more load on the system. Values of 0 or below will be ignored and the default value will be used. | 1 |
+| xref:{s-path}/web.adoc[Web] | WEB_ASSET_APPS_PATH | Serve ownCloud Web apps assets from a path on the filesystem instead of the builtin assets. If not defined, the root directory derives from $OCIS_BASE_DATA_PATH/web/assets/apps | /var/lib/ocis/web/assets/apps |
+| | WEB_ASSET_CORE_PATH | Serve ownCloud Web assets from a path on the filesystem instead of the builtin assets. If not defined, the root directory derives from $OCIS_BASE_DATA_PATH/web/assets/core | /var/lib/ocis/web/assets/core |
+| | WEB_ASSET_THEMES_PATH | Serve ownCloud themes from a path on the filesystem instead of the builtin assets. If not defined, the root directory derives from $OCIS_BASE_DATA_PATH/web/assets/themes | /var/lib/ocis/web/assets/themes |
diff --git a/modules/developer/pages/services/general-info/envvars/env-var-deltas/5.0.0-7.0.0-deprecated.adoc b/modules/developer/pages/services/general-info/envvars/env-var-deltas/5.0.0-7.0.0-deprecated.adoc
new file mode 100644
index 00000000..5090b9b0
--- /dev/null
+++ b/modules/developer/pages/services/general-info/envvars/env-var-deltas/5.0.0-7.0.0-deprecated.adoc
@@ -0,0 +1,22 @@
+:toc: right
+:toclevels: 3
+
+Note that the links provided in the service column are non functional when clicked.
+
+| Service | Variable | Description | Removal Version | Deprecation Info |
+| --- | --- | --- | --- | --- |
+| xref:{s-path}/clientlog.adoc[Clientlog] | CLIENTLOG_REVA_GATEWAY | CS3 gateway used to look up user metadata | %%NEXT_PRODUCTION_VERSION%% | CLIENTLOG_REVA_GATEWAY removed for simplicity. |
+| xref:{s-path}/frontend.adoc[Frontend] | FRONTEND_OCS_ADDITIONAL_INFO_ATTRIBUTE | Additional information attribute for the user like {{.Mail}}. | %%NEXT_PRODUCTION_VERSION%% | The OCS API is deprecated |
+| | FRONTEND_OCS_ENABLE_DENIALS | EXPERIMENTAL: enable the feature to deny access on folders. | %%NEXT_PRODUCTION_VERSION%% | The OCS API is deprecated |
+| | FRONTEND_OCS_INCLUDE_OCM_SHAREES | Include OCM sharees when listing sharees. | %%NEXT_PRODUCTION_VERSION%% | FRONTEND_OCS_INCLUDE_OCM_SHAREES, the OCS API is deprecated |
+| | FRONTEND_OCS_LIST_OCM_SHARES | Include OCM shares when listing shares. See the OCM service documentation for more details. | %%NEXT_PRODUCTION_VERSION%% | FRONTEND_OCS_LIST_OCM_SHARES, the OCS API is deprecated |
+| | FRONTEND_OCS_PERSONAL_NAMESPACE | Home namespace identifier. | %%NEXT_PRODUCTION_VERSION%% | The OCS API is deprecated |
+| | FRONTEND_OCS_PREFIX | URL path prefix for the OCS service. Note that the string must not start with '/'. | %%NEXT_PRODUCTION_VERSION%% | The OCS API is deprecated |
+| | FRONTEND_OCS_SHARE_PREFIX | Path prefix for shares as part of an ocis resource. Note that the path must start with '/'. | %%NEXT_PRODUCTION_VERSION%% | The OCS API is deprecated |
+| | FRONTEND_OCS_STAT_CACHE_AUTH_PASSWORD | The password to use for authentication. Only applies when using the 'nats-js-kv' store type. | %%NEXT_PRODUCTION_VERSION%% | FRONTEND_OCS_STAT_CACHE_AUTH_PASSWORD, the OCS API is deprecated |
+| | FRONTEND_OCS_STAT_CACHE_AUTH_USERNAME | The username to use for authentication. Only applies when using the 'nats-js-kv' store type. | %%NEXT_PRODUCTION_VERSION%% | FRONTEND_OCS_STAT_CACHE_AUTH_USERNAME, the OCS API is deprecated |
+| | FRONTEND_OCS_STAT_CACHE_DISABLE_PERSISTENCE | Disable persistence of the cache. Only applies when using the 'nats-js-kv' store type. Defaults to false. | %%NEXT_PRODUCTION_VERSION%% | FRONTEND_OCS_STAT_CACHE_DISABLE_PERSISTENCE, the OCS API is deprecated |
+| | FRONTEND_OCS_STAT_CACHE_STORE | The type of the cache store. Supported values are: 'memory', 'redis-sentinel', 'nats-js-kv', 'noop'. See the text description for details. | %%NEXT_PRODUCTION_VERSION%% | FRONTEND_OCS_STAT_CACHE_STORE, the OCS API is deprecated |
+| | FRONTEND_OCS_STAT_CACHE_STORE_NODES | A list of nodes to access the configured store. This has no effect when 'memory' store is configured. Note that the behaviour how nodes are used is dependent on the library of the configured store. See the Environment Variable Types description for more details. | %%NEXT_PRODUCTION_VERSION%% | FRONTEND_OCS_STAT_CACHE_STORE_NODES, the OCS API is deprecated |
+| | FRONTEND_OCS_STAT_CACHE_TABLE | The database table the store should use. | %%NEXT_PRODUCTION_VERSION%% | The OCS API is deprecated |
+| | FRONTEND_OCS_STAT_CACHE_TTL | Default time to live for user info in the cache. Only applied when access tokens has no expiration. See the Environment Variable Types description for more details. | %%NEXT_PRODUCTION_VERSION%% | FRONTEND_OCS_STAT_CACHE_TTL, the OCS API is deprecated |
diff --git a/modules/developer/pages/services/general-info/envvars/env-var-deltas/5.0.0-7.0.0-removed.adoc b/modules/developer/pages/services/general-info/envvars/env-var-deltas/5.0.0-7.0.0-removed.adoc
new file mode 100644
index 00000000..ac2b4c28
--- /dev/null
+++ b/modules/developer/pages/services/general-info/envvars/env-var-deltas/5.0.0-7.0.0-removed.adoc
@@ -0,0 +1,56 @@
+:toc: right
+:toclevels: 3
+
+Note that the links provided in the service column are non functional when clicked.
+
+| Service | Variable | Description | Default |
+| --- | --- | --- | --- |
+| xref:deployment/services/env-vars-special-scope.adoc[Special Scope Envvars] | OCIS_CACHE_SIZE | The maximum quantity of items in the user info cache. Only applies when store type 'ocmem' is configured. Defaults to 512 which is derived from the ocmem package though not exclicitly set as default. | 0 |
+| | OCIS_DECOMPOSEDFS_METADATA_BACKEND | The backend to use for storing metadata. Supported values are 'messagepack' and 'xattrs'. The setting 'messagepack' uses a dedicated file to store file metadata while 'xattrs' uses extended attributes to store file metadata. Defaults to 'messagepack'. | messagepack |
+| | OCIS_ENABLE_RESHARING | Changing this value is NOT supported. Enables the support for re-sharing in the clients. | false |
+| | OCIS_PERSISTENT_STORE_SIZE | The maximum quantity of items in the store. Only applies when store type 'ocmem' is configured. Defaults to 512 which is derived from the ocmem package though not exclicitly set as default. | 0 |
+| xref:{s-path}/antivirus.adoc[Antivirus] | ANTIVIRUS_ICAP_TIMEOUT | Timeout for the ICAP client. | 0 |
+| xref:{s-path}/eventhistory.adoc[Eventhistory] | EVENTHISTORY_STORE_SIZE | The maximum quantity of items in the store. Only applies when store type 'ocmem' is configured. Defaults to 512 which is derived and used from the ocmem package though no explicit default was set. | 0 |
+| xref:{s-path}/frontend.adoc[Frontend] | FRONTEND_ENABLE_RESHARING | Changing this value is NOT supported. Enables the support for re-sharing in the clients. | false |
+| | FRONTEND_OCS_STAT_CACHE_SIZE | Max number of entries to hold in the cache. | 0 |
+| xref:{s-path}/gateway.adoc[Gateway] | GATEWAY_CREATE_HOME_CACHE_SIZE | The maximum quantity of items in the cache. Only applies when store type 'ocmem' is configured. Defaults to 512 which is derived from the ocmem package though not explicitly set as default. | 0 |
+| | GATEWAY_PROVIDER_CACHE_SIZE | The maximum quantity of items in the cache. Only applies when store type 'ocmem' is configured. Defaults to 512 which is derived from the ocmem package though not explicitly set as default. | 0 |
+| xref:{s-path}/graph.adoc[Graph] | GRAPH_CACHE_SIZE | The maximum quantity of items in the store. Only applies when store type 'ocmem' is configured. Defaults to 512 which is derived from the ocmem package though not explicitly set as default. | 0 |
+| | GRAPH_ENABLE_RESHARING | Changing this value is NOT supported. Enables the support for re-sharing. | false |
+| xref:{s-path}/ocm.adoc[OCM] | OCM_OCM_PROVIDER_AUTHORIZER_VERIFY_REQUEST_HOSTNAME | Verify the hostname of the incoming request against the hostname of the OCM provider. | false |
+| xref:{s-path}/postprocessing.adoc[Postprocessing] | POSTPROCESSING_STORE_SIZE | The maximum quantity of items in the store. Only applies when store type 'ocmem' is configured. Defaults to 512 which is derived from the ocmem package though not exclicitly set as default. | 0 |
+| xref:{s-path}/proxy.adoc[Proxy] | PROXY_OIDC_USERINFO_CACHE_SIZE | The maximum quantity of items in the user info cache. Only applies when store type 'ocmem' is configured. Defaults to 512 which is derived from the ocmem package though not explicitly set as default. | 0 |
+| xref:{s-path}/settings.adoc[Settings] | SETTINGS_CACHE_SIZE | The maximum quantity of items in the cache. Only applies when store type 'ocmem' is configured. Defaults to 512 which is derived from the ocmem package though not exclicitly set as default. | 0 |
+| | SETTINGS_DATA_PATH | The directory where the filesystem storage will store ocis settings. If not defined, the root directory derives from $OCIS_BASE_DATA_PATH:/settings. | /var/lib/ocis/settings |
+| | SETTINGS_STORE_TYPE | Store type configures the persistency driver. Supported values are 'metadata' and 'filesystem'. Note that the value 'filesystem' is considered deprecated. | metadata |
+| xref:{s-path}/sharing.adoc[Sharing] | SHARING_ENABLE_RESHARING | Changing this value is NOT supported. Enables the support for resharing. | false |
+| xref:{s-path}/storage-system.adoc[Storage-System] | STORAGE_SYSTEM_CACHE_SIZE | The maximum quantity of items in the user info cache. Only applies when store type 'ocmem' is configured. Defaults to 512 which is derived from the ocmem package though not exclicitly set as default. | 0 |
+| | STORAGE_SYSTEM_OCIS_METADATA_BACKEND | The backend to use for storing metadata. Supported values are 'messagepack' and 'xattrs'. The setting 'messagepack' uses a dedicated file to store file metadata while 'xattrs' uses extended attributes to store file metadata. Defaults to 'messagepack'. | messagepack |
+| xref:{s-path}/storage-users.adoc[Storage-Users] | STORAGE_USERS_FILEMETADATA_CACHE_SIZE | The maximum quantity of items in the user info cache. Only applies when store type 'ocmem' is configured. Defaults to 512 which is derived from the ocmem package though not exclicitly set as default. | 0 |
+| | STORAGE_USERS_ID_CACHE_SIZE | The maximum quantity of items in the user info cache. Only applies when store type 'ocmem' is configured. Defaults to 512 which is derived from the ocmem package though not exclicitly set as default. | 0 |
+| | STORAGE_USERS_OCIS_METADATA_BACKEND | The backend to use for storing metadata. Supported values are 'messagepack' and 'xattrs'. The setting 'messagepack' uses a dedicated file to store file metadata while 'xattrs' uses extended attributes to store file metadata. Defaults to 'messagepack'. | messagepack |
+| | STORAGE_USERS_S3NG_METADATA_BACKEND | The backend to use for storing metadata. Supported values are 'xattrs' and 'messagepack'. The setting 'xattrs' uses extended attributes to store file metadata while 'messagepack' uses a dedicated file to store file metadata. Defaults to 'xattrs'. | messagepack |
+| The `Store` service has been removed completely | STORE_DATA_PATH | The directory where the filesystem storage will store ocis settings. If not defined, the root directory derives from $OCIS_BASE_DATA_PATH:/store. | /var/lib/ocis/store |
+| | STORE_DEBUG_ADDR | Bind address of the debug server, where metrics, health, config and debug endpoints will be exposed. | 127.0.0.1:9464 |
+| | STORE_DEBUG_PPROF | Enables pprof, which can be used for profiling. | false |
+| | STORE_DEBUG_TOKEN | Token to secure the metrics endpoint. | |
+| | STORE_DEBUG_ZPAGES | Enables zpages, which can be used for collecting and viewing in-memory traces. | false |
+| | STORE_GRPC_ADDR | The bind address of the GRPC service. | 127.0.0.1:9460 |
+| | STORE_LOG_COLOR | Activates colorized log output. | false |
+| | STORE_LOG_FILE | The path to the log file. Activates logging to this file if set. | |
+| | STORE_LOG_LEVEL | The log level. Valid values are: 'panic', 'fatal', 'error', 'warn', 'info', 'debug', 'trace'. | |
+| | STORE_LOG_PRETTY | Activates pretty log output. | false |
+| | STORE_TRACING_COLLECTOR | The HTTP endpoint for sending spans directly to a collector, i.e. http://jaeger-collector:14268/api/traces. Only used if the tracing endpoint is unset. | |
+| | STORE_TRACING_ENABLED | Activates tracing. | false |
+| | STORE_TRACING_ENDPOINT | The endpoint of the tracing agent. | |
+| | STORE_TRACING_TYPE | The type of tracing. Defaults to '', which is the same as 'jaeger'. Allowed tracing types are 'jaeger' and '' as of now. | |
+| xref:{s-path}/userlog.adoc[Userlog] | USERLOG_STORE_SIZE | The maximum quantity of items in the store. Only applies when store type 'ocmem' is configured. Defaults to 512 which is derived from the ocmem package though not exclicitly set as default. | 0 |
+| xref:{s-path}/web.adoc[Web] | WEB_ASSET_PATH | Serve ownCloud Web assets from a path on the filesystem instead of the builtin assets. | |
+| | WEB_OPTION_DISABLE_PREVIEWS | Set this option to 'true' to disable previews in all the different web file listing views. This can speed up file listings in folders with many files. The only list view that is not affected by this setting is the trash bin, as it does not allow previewing at all. | false |
+| | WEB_OPTION_HOME_FOLDER | Specifies a folder that is used when the user navigates 'home'. Navigating home gets triggered by clicking on the 'All files' menu item. The user will not be jailed in that directory, it simply serves as a default location. A static location can be provided, or variables of the user object to come up with a user specific home path can be used. This uses the twig template variable style and allows picking a value or a substring of a value of the authenticated user. Examples are '/Shares', '/{{.Id}}' and '/{{substr 0 3 .Id}}/{{.Id}'. | |
+| | WEB_OPTION_HOVERABLE_QUICK_ACTIONS | Set this option to 'true' to hide quick actions (buttons appearing on file rows) and only show them when the user hovers over the row with his mouse. Defaults to 'false'. | false |
+| | WEB_OPTION_OPEN_LINKS_WITH_DEFAULT_APP | Specifies whether single file link shares should be opened with the default app or not. If not opened by the default app, the Web UI just displays the file details. | true |
+| | WEB_OPTION_PREVIEW_FILE_MIMETYPES | A list of mimeTypes to specify which ones will be previewed in the UI. For example, to only preview jpg and text files, set this option to 'image/jpeg,text/plain'. See the Environment Variable Types description for more details. | [image/gif image/png image/jpeg text/plain image/tiff image/bmp image/x-ms-bmp application/vnd.geogebra.slides] |
+| | WEB_OPTION_ROUTING_ID_BASED | Enable or disable fileIds being added to the URL. Defaults to 'true', because otherwise spaces with name clashes cannot be resolved correctly. Note: Only disable this if you can guarantee on the server side, that spaces of the same namespace cannot have name clashes. | true |
+| | WEB_OPTION_SHARING_RECIPIENTS_PER_PAGE | Sets the number of users shown as recipients in the dropdown menu when sharing resources. | 200 |
+| | WEB_OPTION_SIDEBAR_SHARES_SHOW_ALL_ON_LOAD | Sets the list of the (link) shares list in the sidebar to be initially expanded. Default is a collapsed state, only showing the first three shares. | false |
diff --git a/modules/developer/pages/services/general-info/envvars/env-var-deltas/7.0.0-7.1.0-added.adoc b/modules/developer/pages/services/general-info/envvars/env-var-deltas/7.0.0-7.1.0-added.adoc
new file mode 100644
index 00000000..16e11618
--- /dev/null
+++ b/modules/developer/pages/services/general-info/envvars/env-var-deltas/7.0.0-7.1.0-added.adoc
@@ -0,0 +1,16 @@
+:toc: right
+:toclevels: 3
+
+Note that the links provided in the service column are non functional when clicked.
+
+| Service | Variable | Description | Default |
+| --- | --- | --- | --- |
+| xref:{s-path}/frontend.adoc[Fontend] | FRONTEND_CONFIGURABLE_NOTIFICATIONS | Allow configuring notifications via web client. | false |
+| xref:{s-path}/notifications.adoc[Notifications] | NOTIFICATIONS_STORE | The type of the store. Supported values are: 'memory', 'nats-js-kv', 'redis-sentinel', 'noop'. See the text description for details. | nats-js-kv |
+| | NOTIFICATIONS_STORE_AUTH_PASSWORD | The password to authenticate with the store. Only applies when store type 'nats-js-kv' is configured. | |
+| | NOTIFICATIONS_STORE_AUTH_USERNAME | The username to authenticate with the store. Only applies when store type 'nats-js-kv' is configured. | |
+| | NOTIFICATIONS_STORE_DATABASE | The database name the configured store should use. | notifications |
+| | NOTIFICATIONS_STORE_NODES | A list of nodes to access the configured store. This has no effect when 'memory' store is configured. Note that the behaviour how nodes are used is dependent on the library of the configured store. See the Environment Variable Types description for more details. | [127.0.0.1:9233] |
+| | NOTIFICATIONS_STORE_TABLE | The database table the store should use. | |
+| | NOTIFICATIONS_STORE_TTL | Time to live for notifications in the store. Defaults to '336h' (2 weeks). See the Environment Variable Types description for more details. | 336h0m0s |
+| xref:{s-path}/settings.adoc[Settings] | SETTINGS_TRANSLATION_PATH | (optional) Set this to a path with custom translations to overwrite the builtin translations. Note that file and folder naming rules apply, see the documentation for more details. | |
diff --git a/modules/developer/pages/services/general-info/envvars/env-var-deltas/7.0.0-7.1.0-deprecated.adoc b/modules/developer/pages/services/general-info/envvars/env-var-deltas/7.0.0-7.1.0-deprecated.adoc
new file mode 100644
index 00000000..0e2b8a5e
--- /dev/null
+++ b/modules/developer/pages/services/general-info/envvars/env-var-deltas/7.0.0-7.1.0-deprecated.adoc
@@ -0,0 +1,24 @@
+:toc: right
+:toclevels: 3
+
+Note that the links provided in the service column are non functional when clicked.
+
+Note that these environment variables were listed for deprecation in 7.0.0 already. Removal has been delayed for an upcoming production version. They are listed here for consistency.
+
+| Service | Variable | Description | Removal Version | Deprecation Info |
+| --- | --- | --- | --- | --- |
+| xref:{s-path}/clientlog.adoc[Clientlog] | CLIENTLOG_REVA_GATEWAY | CS3 gateway used to look up user metadata | %%NEXT_PRODUCTION_VERSION%% | CLIENTLOG_REVA_GATEWAY removed for simplicity. |
+| xref:{s-path}/frontend.adoc[Frontend] | FRONTEND_OCS_ADDITIONAL_INFO_ATTRIBUTE | Additional information attribute for the user like {{.Mail}}. | %%NEXT_PRODUCTION_VERSION%% | The OCS API is deprecated |
+| | FRONTEND_OCS_ENABLE_DENIALS | EXPERIMENTAL: enable the feature to deny access on folders. | %%NEXT_PRODUCTION_VERSION%% | The OCS API is deprecated |
+| | FRONTEND_OCS_INCLUDE_OCM_SHAREES | Include OCM sharees when listing sharees. | %%NEXT_PRODUCTION_VERSION%% | FRONTEND_OCS_INCLUDE_OCM_SHAREES, the OCS API is deprecated |
+| | FRONTEND_OCS_LIST_OCM_SHARES | Include OCM shares when listing shares. See the OCM service documentation for more details. | %%NEXT_PRODUCTION_VERSION%% | FRONTEND_OCS_LIST_OCM_SHARES, the OCS API is deprecated |
+| | FRONTEND_OCS_PERSONAL_NAMESPACE | Home namespace identifier. | %%NEXT_PRODUCTION_VERSION%% | The OCS API is deprecated |
+| | FRONTEND_OCS_PREFIX | URL path prefix for the OCS service. Note that the string must not start with '/'. | %%NEXT_PRODUCTION_VERSION%% | The OCS API is deprecated |
+| | FRONTEND_OCS_SHARE_PREFIX | Path prefix for shares as part of an ocis resource. Note that the path must start with '/'. | %%NEXT_PRODUCTION_VERSION%% | The OCS API is deprecated |
+| | FRONTEND_OCS_STAT_CACHE_AUTH_PASSWORD | The password to use for authentication. Only applies when using the 'nats-js-kv' store type. | %%NEXT_PRODUCTION_VERSION%% | FRONTEND_OCS_STAT_CACHE_AUTH_PASSWORD, the OCS API is deprecated |
+| | FRONTEND_OCS_STAT_CACHE_AUTH_USERNAME | The username to use for authentication. Only applies when using the 'nats-js-kv' store type. | %%NEXT_PRODUCTION_VERSION%% | FRONTEND_OCS_STAT_CACHE_AUTH_USERNAME, the OCS API is deprecated |
+| | FRONTEND_OCS_STAT_CACHE_DISABLE_PERSISTENCE | Disable persistence of the cache. Only applies when using the 'nats-js-kv' store type. Defaults to false. | %%NEXT_PRODUCTION_VERSION%% | FRONTEND_OCS_STAT_CACHE_DISABLE_PERSISTENCE, the OCS API is deprecated |
+| | FRONTEND_OCS_STAT_CACHE_STORE | The type of the cache store. Supported values are: 'memory', 'redis-sentinel', 'nats-js-kv', 'noop'. See the text description for details. | %%NEXT_PRODUCTION_VERSION%% | FRONTEND_OCS_STAT_CACHE_STORE, the OCS API is deprecated |
+| | FRONTEND_OCS_STAT_CACHE_STORE_NODES | A list of nodes to access the configured store. This has no effect when 'memory' store is configured. Note that the behaviour how nodes are used is dependent on the library of the configured store. See the Environment Variable Types description for more details. | %%NEXT_PRODUCTION_VERSION%% | FRONTEND_OCS_STAT_CACHE_STORE_NODES, the OCS API is deprecated |
+| | FRONTEND_OCS_STAT_CACHE_TABLE | The database table the store should use. | %%NEXT_PRODUCTION_VERSION%% | The OCS API is deprecated |
+| | FRONTEND_OCS_STAT_CACHE_TTL | Default time to live for user info in the cache. Only applied when access tokens has no expiration. See the Environment Variable Types description for more details. | %%NEXT_PRODUCTION_VERSION%% | FRONTEND_OCS_STAT_CACHE_TTL, the OCS API is deprecated |
diff --git a/modules/developer/pages/services/general-info/envvars/env-var-deltas/7.0.0-7.1.0-removed.adoc b/modules/developer/pages/services/general-info/envvars/env-var-deltas/7.0.0-7.1.0-removed.adoc
new file mode 100644
index 00000000..e09f6cd0
--- /dev/null
+++ b/modules/developer/pages/services/general-info/envvars/env-var-deltas/7.0.0-7.1.0-removed.adoc
@@ -0,0 +1,7 @@
+:toc: right
+:toclevels: 3
+
+Note that the links provided in the service column are non functional when clicked.
+
+| Service | Variable | Description | Default |
+| --- | --- | --- | --- |
diff --git a/modules/developer/pages/services/general-info/envvars/env-var-deltas/7.1.0-7.2.0-added.adoc b/modules/developer/pages/services/general-info/envvars/env-var-deltas/7.1.0-7.2.0-added.adoc
new file mode 100644
index 00000000..a1711022
--- /dev/null
+++ b/modules/developer/pages/services/general-info/envvars/env-var-deltas/7.1.0-7.2.0-added.adoc
@@ -0,0 +1,13 @@
+:toc: right
+:toclevels: 3
+
+Note that the links provided in the service column are non functional when clicked.
+
+| Service | Variable | Description | Default |
+| --- | --- | --- | --- |
+| xref:deployment/services/env-vars-special-scope.adoc[Special Scope Envvars] | OCIS_CLAIM_MANAGED_SPACES_CLAIMNAME | The name of the claim used to manage Spaces. | |
+| | OCIS_CLAIM_MANAGED_SPACES_ENABLED | Enables Space management through OIDC claims. See the text description for more details. | false |
+| | OCIS_CLAIM_MANAGED_SPACES_MAPPING | (Optional) Mapping of OIDC roles to ocis Space roles. Example: 'oidcroleA:viewer,oidcroleB:manager' | [] |
+| | OCIS_CLAIM_MANAGED_SPACES_REGEXP | The regular expression that extracts Space IDs and roles from a claim. | |
+| | OCIS_MAX_TAG_LENGTH | Define the maximum tag length. Defaults to 100 if not set. Set to 0 to not limit the tag length. Changes only impact the validation of new tags. | 100 |
+| xref:{s-path}/search.adoc[search] | SEARCH_ENGINE_BLEVE_SCALE | Enable scaling of the search index (bleve). If set to 'true', the instance of the search service will no longer have exclusive write access to the index. Note when scaling search, all instances of the search service must be set to true! For 'false', which is the default, the running search service has exclusive access to the index as long it is running. This locks out other search processes tying to access the index. | false |
diff --git a/modules/developer/pages/services/general-info/envvars/env-var-deltas/7.1.0-7.2.0-deprecated.adoc b/modules/developer/pages/services/general-info/envvars/env-var-deltas/7.1.0-7.2.0-deprecated.adoc
new file mode 100644
index 00000000..92f69c83
--- /dev/null
+++ b/modules/developer/pages/services/general-info/envvars/env-var-deltas/7.1.0-7.2.0-deprecated.adoc
@@ -0,0 +1,7 @@
+:toc: right
+:toclevels: 3
+
+Note that the links provided in the service column are non functional when clicked.
+
+| Service | Variable | Description | Removal Version | Deprecation Info |
+| --- | --- | --- | --- | --- |
diff --git a/modules/developer/pages/services/general-info/envvars/env-var-deltas/7.1.0-7.2.0-removed.adoc b/modules/developer/pages/services/general-info/envvars/env-var-deltas/7.1.0-7.2.0-removed.adoc
new file mode 100644
index 00000000..d920e658
--- /dev/null
+++ b/modules/developer/pages/services/general-info/envvars/env-var-deltas/7.1.0-7.2.0-removed.adoc
@@ -0,0 +1,24 @@
+:toc: right
+:toclevels: 3
+
+Note that the links provided in the service column are non functional when clicked.
+
+| Service | Variable | Description | Default |
+| --- | --- | --- | --- |
+| xref:{s-path}/clientlog.adoc[clientlog] | CLIENTLOG_REVA_GATEWAY | CS3 gateway used to look up user metadata | com.owncloud.api.gateway |
+| xref:{s-path}/frontend.adoc[frontend] | FRONTEND_OCS_ADDITIONAL_INFO_ATTRIBUTE | Additional information attribute for the user like {{.Mail}}. | {{.Mail}} |
+| | FRONTEND_OCS_ENABLE_DENIALS | EXPERIMENTAL: enable the feature to deny access on folders. | false |
+| | FRONTEND_OCS_INCLUDE_OCM_SHAREES | Include OCM sharees when listing sharees. | false |
+| | FRONTEND_OCS_LIST_OCM_SHARES | Include OCM shares when listing shares. See the OCM service documentation for more details. | true |
+| | FRONTEND_OCS_PERSONAL_NAMESPACE | Home namespace identifier. | /users/{{.Id.OpaqueId}} |
+| | FRONTEND_OCS_PREFIX | URL path prefix for the OCS service. Note that the string must not start with '/'. | ocs |
+| | FRONTEND_OCS_PUBLIC_SHARE_MUST_HAVE_PASSWORD | Set this to true if you want to enforce passwords on all public shares. | true |
+| | FRONTEND_OCS_PUBLIC_WRITEABLE_SHARE_MUST_HAVE_PASSWORD | Set this to true if you want to enforce passwords for writable shares. Only effective if the setting for 'passwords on all public shares' is set to false. | false |
+| | FRONTEND_OCS_SHARE_PREFIX | Path prefix for shares as part of an ocis resource. Note that the path must start with '/'. | /Shares |
+| | FRONTEND_OCS_STAT_CACHE_AUTH_PASSWORD | The password to use for authentication. Only applies when using the 'nats-js-kv' store type. | |
+| | FRONTEND_OCS_STAT_CACHE_AUTH_USERNAME | The username to use for authentication. Only applies when using the 'nats-js-kv' store type. | |
+| | FRONTEND_OCS_STAT_CACHE_DISABLE_PERSISTENCE | Disable persistence of the cache. Only applies when using the 'nats-js-kv' store type. Defaults to false. | false |
+| | FRONTEND_OCS_STAT_CACHE_STORE | The type of the cache store. Supported values are: 'memory', 'redis-sentinel', 'nats-js-kv', 'noop'. See the text description for details. | memory |
+| | FRONTEND_OCS_STAT_CACHE_STORE_NODES | A list of nodes to access the configured store. This has no effect when 'memory' store is configured. Note that the behaviour how nodes are used is dependent on the library of the configured store. See the Environment Variable Types description for more details. | [127.0.0.1:9233] |
+| | FRONTEND_OCS_STAT_CACHE_TABLE | The database table the store should use. | |
+| | FRONTEND_OCS_STAT_CACHE_TTL | Default time to live for user info in the cache. Only applied when access tokens has no expiration. See the Environment Variable Types description for more details. | 5m0s |
diff --git a/modules/developer/pages/services/general-info/envvars/env-var-deltas/7.2.0-7.3.0-added.adoc b/modules/developer/pages/services/general-info/envvars/env-var-deltas/7.2.0-7.3.0-added.adoc
new file mode 100644
index 00000000..14dd46f1
--- /dev/null
+++ b/modules/developer/pages/services/general-info/envvars/env-var-deltas/7.2.0-7.3.0-added.adoc
@@ -0,0 +1,7 @@
+:toc: right
+:toclevels: 3
+
+| Service | Variable | Description | Default |
+| --- | --- | --- | --- |
+| collaboration | COLLABORATION_APP_PRODUCT_EDITION | The WebOffice app edition defines the capabilities specific to the product such as CE - Community Edition, EE - Enterprise Edition DE - Developer Edition, etc. Currently supported values are limited to OnlyOffice and are: 'ce', 'ee' or 'de' and default to empty which is equal to ce). See the documentation for more details. | |
+| | COLLABORATION_WOPI_ENABLE_MOBILE | Enable the mobile web view for office app. This feature applies to OnlyOffice. See the documentation for more details. | false |
diff --git a/modules/developer/pages/services/general-info/envvars/env-var-deltas/7.2.0-7.3.0-deprecated.adoc b/modules/developer/pages/services/general-info/envvars/env-var-deltas/7.2.0-7.3.0-deprecated.adoc
new file mode 100644
index 00000000..48a88a18
--- /dev/null
+++ b/modules/developer/pages/services/general-info/envvars/env-var-deltas/7.2.0-7.3.0-deprecated.adoc
@@ -0,0 +1,5 @@
+:toc: right
+:toclevels: 3
+
+| Service | Variable | Description | Removal Version | Deprecation Info |
+| --- | --- | --- | --- | --- |
diff --git a/modules/developer/pages/services/general-info/envvars/env-var-deltas/7.2.0-7.3.0-removed.adoc b/modules/developer/pages/services/general-info/envvars/env-var-deltas/7.2.0-7.3.0-removed.adoc
new file mode 100644
index 00000000..285e239b
--- /dev/null
+++ b/modules/developer/pages/services/general-info/envvars/env-var-deltas/7.2.0-7.3.0-removed.adoc
@@ -0,0 +1,5 @@
+:toc: right
+:toclevels: 3
+
+| Service | Variable | Description | Default |
+| --- | --- | --- | --- |
diff --git a/modules/developer/pages/services/general-info/envvars/env-var-deltas/7.3.0-8.0.0-added.adoc b/modules/developer/pages/services/general-info/envvars/env-var-deltas/7.3.0-8.0.0-added.adoc
new file mode 100644
index 00000000..76ea44ff
--- /dev/null
+++ b/modules/developer/pages/services/general-info/envvars/env-var-deltas/7.3.0-8.0.0-added.adoc
@@ -0,0 +1,32 @@
+:toc: right
+:toclevels: 3
+
+| Service | Variable | Description | Default |
+| --- | --- | --- | --- |
+| xref:{s-path}/collaboration.adoc[Collaboration] | COLLABORATION_WOPI_DISABLED_EXTENSIONS | List of extensions to disable: Disabling an extension will make it unavailable to the Office web front end. The list is comma-separated with no spaces between the items, such as 'docx,xlsx,pptx'. | [] |
+| xref:{s-path}/graph.adoc[Graph] | GRAPH_LDAP_EXTERNAL_ID_ATTRIBUTE | LDAP attribute that references the external ID of users during the provisioning process. The final ID is provided by an external identity provider. If it is not set, a default attribute will be used instead. | owncloudExternalID |
+| | GRAPH_LDAP_REQUIRE_EXTERNAL_ID | If enabled, the 'OCIS_LDAP_USER_SCHEMA_EXTERNAL_ID' is used as primary identifier for the provisioning API. | false |
+| | OCIS_LDAP_USER_SCHEMA_EXTERNAL_ID | LDAP attribute that references the external ID of users during the provisioning process. The final ID is provided by an external identity provider. If it is not set, a default attribute will be used instead. | owncloudExternalID |
+| | OCIS_LDAP_INSTANCE_MAPPER_BASE_DN | BaseDN of the 'instancename to instanceid' mapper in LDAP. Requires OCIS_MULTI_INSTANCE_ENABLED. | |
+| | OCIS_LDAP_INSTANCE_MAPPER_ENABLED | The InstanceMapper allows mapping instance names (user readable) to instance IDs (machine readable) based on an LDAP query. See other _INSTANCE_MAPPER_ env vars. Requires OCIS_MULTI_INSTANCE_ENABLED. | false |
+| | OCIS_LDAP_INSTANCE_MAPPER_ID_ATTRIBUTE | LDAP Attribute of the instance ID. Requires OCIS_MULTI_INSTANCE_ENABLED. | |
+| | OCIS_LDAP_INSTANCE_MAPPER_NAME_ATTRIBUTE | LDAP Attribute of the instance name. Requires OCIS_MULTI_INSTANCE_ENABLED. | |
+| | OCIS_LDAP_CROSS_INSTANCE_REFERENCE_TEMPLATE | Template for the users unique reference across oCIS instances. Requires OCIS_MULTI_INSTANCE_ENABLED. | |
+| | OCIS_LDAP_INSTANCE_URL_TEMPLATE | Template for the instance URL. Requires OCIS_MULTI_INSTANCE_ENABLED. | |
+| | OCIS_LDAP_GROUP_AFFILIATION_ATTRIBUTE | LDAP Attribute to signal which instance the group is belonging to. Requires OCIS_MULTI_INSTANCE_ENABLED. | |
+| | OCIS_LDAP_PRECISE_SEARCH_ATTRIBUTE | LDAP Attribute to be used for searching users on other instances. Requires OCIS_MULTI_INSTANCE_ENABLED. | |
+| | OCIS_LDAP_USER_GUEST_ATTRIBUTE | LDAP Attribute to signal the user is guest of an instance. Requires OCIS_MULTI_INSTANCE_ENABLED. | |
+| | OCIS_LDAP_USER_MEMBER_ATTRIBUTE | LDAP Attribute to signal the user is member of an instance. Requires OCIS_MULTI_INSTANCE_ENABLED. | |
+| | OCIS_MULTI_INSTANCE_QUERY_TEMPLATE | The regular expression extracting username and instancename from a user provided search. | |
+| xref:{s-path}/proxy.adoc[Proxy] | PROXY_FORCE_STRICT_TRANSPORT_SECURITY | Force emission of the Strict-Transport-Security header on all responses, including plain HTTP requests. See also: PROXY_TLS | false |
+| | OCIS_MULTI_INSTANCE_ENABLED | Enable multiple instances of Infinite Scale. | false |
+| | OCIS_MULTI_INSTANCE_GUEST_CLAIM | The claim name for the 'guestOf' property | guestOf |
+| | OCIS_MULTI_INSTANCE_GUEST_ROLE | The role that should be assigned to a guest user | user-light |
+| | OCIS_MULTI_INSTANCE_INSTANCEID | The unique id of this instance | c1f28cf2-d363-4671-a8fe-8d7a80b36b87 |
+| | OCIS_MULTI_INSTANCE_MEMBER_CLAIM | The claim name for the 'memberOf' property | memberOf |
+| xref:{s-path}/storage-publiclink.adoc[Storage-Publiclink] | STORAGE_PUBLICLINK_STORE_STORE | The type of the store. Supported values are: 'memory', 'nats-js-kv', 'redis-sentinel', 'noop'. See the text description for details. | nats-js-kv |
+| | STORAGE_PUBLICLINK_STORE_NODES | A list of nodes to access the configured store. This has no effect when 'memory' store is configured. Note that the behaviour how nodes are used is dependent on the library of the configured store. See the Environment Variable Types description for more details. | [127.0.0.1:9233] |
+| | STORAGE_PUBLICLINK_STORE_DATABASE | The database name the configured store should use. | |
+| | STORAGE_PUBLICLINK_STORE_TABLE | The database table the store should use. | |
+| | STORAGE_PUBLICLINK_STORE_AUTH_USERNAME | The username to authenticate with the store. Only applies when store type 'nats-js-kv' is configured. | |
+| | STORAGE_PUBLICLINK_STORE_AUTH_PASSWORD | The password to authenticate with the store. Only applies when store type 'nats-js-kv' is configured. | |
diff --git a/modules/developer/pages/services/general-info/envvars/env-var-deltas/7.3.0-8.0.0-deprecated.adoc b/modules/developer/pages/services/general-info/envvars/env-var-deltas/7.3.0-8.0.0-deprecated.adoc
new file mode 100644
index 00000000..48a88a18
--- /dev/null
+++ b/modules/developer/pages/services/general-info/envvars/env-var-deltas/7.3.0-8.0.0-deprecated.adoc
@@ -0,0 +1,5 @@
+:toc: right
+:toclevels: 3
+
+| Service | Variable | Description | Removal Version | Deprecation Info |
+| --- | --- | --- | --- | --- |
diff --git a/modules/developer/pages/services/general-info/envvars/env-var-deltas/7.3.0-8.0.0-removed.adoc b/modules/developer/pages/services/general-info/envvars/env-var-deltas/7.3.0-8.0.0-removed.adoc
new file mode 100644
index 00000000..7b58b12e
--- /dev/null
+++ b/modules/developer/pages/services/general-info/envvars/env-var-deltas/7.3.0-8.0.0-removed.adoc
@@ -0,0 +1,6 @@
+:toc: right
+:toclevels: 3
+
+| Service | Variable | Description | Default |
+| --- | --- | --- | --- |
+| xref:{s-path}/frontend.adoc[Frontend] | OCIS_SHOW_USER_EMAIL_IN_RESULTS | Include user email addresses in responses. If absent or set to false emails will be omitted from results. Please note that admin users can always see all email addresses. | false |
diff --git a/modules/developer/pages/services/general-info/envvars/env-var-deltas/index.adoc b/modules/developer/pages/services/general-info/envvars/env-var-deltas/index.adoc
new file mode 100644
index 00000000..291cef62
--- /dev/null
+++ b/modules/developer/pages/services/general-info/envvars/env-var-deltas/index.adoc
@@ -0,0 +1,37 @@
+= Deltas Between Versions
+:toc: right
+:toclevels: 3
+
+== General Information
+
+This section provides information about `added`, `removed` and `deprecated` environment variables between two major/minor versions.
+
+[WARNING]
+====
+* When creating a new release, this step should be completed _before_ the new `stable-x.y` branch is created. Then, all changes will go cleanly into this stable branch.
+* If the changes required are not part of the stable branch created for the release process, you must backport all `added`, `removed` and `deprecated` files created from the described process below into the stable branch. Backporting `env_vars.yaml`to the stable branch is not required and can be omitted.
+====
+
+
+To create the changed envvar tables, you must proceed the following steps in order:
+
+1. Install, if not already done, the converter for adoc to markdown tables: `npm install -g downdoc`\
+This is only required when converting adoc to markdown tables but it is highly recommended to show them in the dev docs too!
+
+1. Run `make docs-local` from the ocis root.\
+Usually, a file named `env_vars.yaml` gets changed. Check for validity. If issues are found, fix them in the service sources first which need to be merged before you rerun make. For details how to do so, see xref:../new-release-process.md#maintain-the-env_varsyaml-file.adoc[Maintain the 'env_vars.yaml' File]. Any delta information is based on an actual `env_vars.yaml` file which is pulled _from master_ by the python script described below!
+
+1. Configure the Python script `docs/helpers/changed_envvars.py` variables for the new version.\
+Note that you _must_ use semver and not code names!
+
+1. Run the python script from the ocis root such as `python3 docs/helpers/changed_envvars.py`.\
+Note that the script pulls data from the master branch as a base reference, therefore the `env_vars.yaml` file must be kept up to date. The adoc tables generated are used for the admin documentation and form the basis for Markdown.
+
+1. As the script cannot determine the link target (xref:) in the `Service` column, you must adapt these manually in the generated adoc files according to the file name and printed name. Envvars starting with `OCIS_` are displayed differently in the `Service` column because the file name and printed name cannot be easily identified and must be resolved differently. You have to check where they are defined, unlike the others where the name provides a clue. The final xref path must be corrected manually in all cases. Only one entry per identical service is required to generate an easy block view. Delete the cell content except for the pipe symbol (`|`) to make it easier to read. See existing files for an example.
+
+1. Change into the directory that contains the generated adoc files and run `npx downdoc ` for each of the newly generated `added`, `removed` and `deprecated` files. This will generate markdown files for the dev docs.
+
+1. Add in each markdown file on top the following sentence:\
+`Note that the links provided in the service column are non functional when clicked.`, including a newline.
+
+1. Create a PR and merge it.
diff --git a/modules/developer/pages/services/general-info/envvars/envvar-naming-scopes.adoc b/modules/developer/pages/services/general-info/envvars/envvar-naming-scopes.adoc
new file mode 100644
index 00000000..495dbe75
--- /dev/null
+++ b/modules/developer/pages/services/general-info/envvars/envvar-naming-scopes.adoc
@@ -0,0 +1,76 @@
+= Envvar Naming Scopes
+:toc: right
+:toclevels: 3
+
+
+The scope of an environment variable can be derived from its name. Therefore, it is important to follow the correct naming scheme to enable easy and proper identification. This is important when either:
+
+- a new local envvar is introduced.
+- a new global envvar is added to an existing local envvar.
+
+== Envvar Definition
+
+- A variable that is only used in a particular service is a _local envvar_.
+- A variable that is used in more than one service is a _global envvar_.
+- If applicapable, a global envvar has a local counterpart.
+- Variables that are not limited to any service are by definition global.
+
+== Naming Scope
+
+=== Local Envvars
+
+A local envvar always starts with the service name such as `POSTPROCESSING_LOG_FILE`.
+
+=== Global Envvars
+
+A global envvar always starts with `OCIS_` like `OCIS_LOG_FILE`.
+
+Note that this envvar is the global representation of the local example from above.
+
+To get a list of global envvars used in all services, see the link:https://doc.owncloud.com/ocis/next/deployment/services/env-vars-special-scope.html#global-environment-variables[Global Environment Variables] table in the ocis admin documentation.
+
+=== Reserved Envvar Names
+
+Services and their local envvars _MUST NOT_ be named `extended` or `global`. These are reserved names for the automated documentation process.
+
+== Lifecycle of Envvars
+
+The envvar struct tag contains at maximum the following key/value pairs to document the lifecycle of a config variable:
+
+* `introductionVersion`
+* `deprecationVersion`
+* `removalVersion`
+* `deprecationInfo`
+* `deprecationReplacement`
+
+=== Introduce new Envvars
+
+* If a _new_ envvar is introduced, the entire structure must be added, including the `introductionVersion` field. Note that 'introduced' means, that the new envvar was not present in any of the services.
+
+[NOTE]
+====
+ * During development, set the `introductionVersion` to a short, _alphabetic code name_ that represents the upcoming release such as `releaseX` or the project name for that release such as `Daledda`.
+ * This identifier stays constant until the release receives its final production semantic-version number.
+ * Although the pipeline checks the semver string when a PR is created, you can perform this check upfront manually by entering the following command from the ocis root:
+
+ ```bash
+ .make/check-env-var-annotations.sh
+ ```
+====
+
+
+ The doc helper scripts render these alphabetic identifiers verbatim. They appear in the next (master) branch of the admin documentation exactly as they are entered.
+
+* See the xref:./new-release-process/.adoc[Set the Correct IntroductionVersion] documentation before starting a new release candidate.
+
+=== Adding Envvars to Existing Ones
+
+If an envvar has been introduced with a particular release, the `introductionVersion` got a semver value accordingly. If an additional envvar is added to this existing one such as a global envvar, the introduction version _must not_ be changed.
+
+=== Deprecate Existing Envvars
+
+See the xref:./deprecating-variables.adoc[deprecation rules] documentation for more details.
+
+== Separating Multiple Envvars
+
+When multiple envvars are defined for one purpose like a global and local one, use `;` (semicolon) to properly separate the envvars in go code. Though it is possible to separate with `,` (comma) according go rules, the current implementation of the docs generation process only recognizes semicolons as separator.
diff --git a/modules/developer/pages/services/general-info/envvars/index.adoc b/modules/developer/pages/services/general-info/envvars/index.adoc
new file mode 100644
index 00000000..1e94ff73
--- /dev/null
+++ b/modules/developer/pages/services/general-info/envvars/index.adoc
@@ -0,0 +1,9 @@
+= Environment Variables
+:toc: right
+:toclevels: 3
+
+== General Information
+
+This section provides general information how to manage environment variables.
+
+Additionally read the link:https://github.com/owncloud/ocis/tree/master/docs/helpers#readme[helper README] for internal details how envvars are managed.
diff --git a/modules/developer/pages/services/general-info/envvars/new-release-process.adoc b/modules/developer/pages/services/general-info/envvars/new-release-process.adoc
new file mode 100644
index 00000000..0544fe36
--- /dev/null
+++ b/modules/developer/pages/services/general-info/envvars/new-release-process.adoc
@@ -0,0 +1,62 @@
+= Release Process for Envvars
+:toc: right
+:toclevels: 3
+
+
+_IMPORTANT_\
+For a new ocis release, some tasks are necessary to be done _before_ releasing. Follow the steps carefully to avoid issues. Most of the docs related tasks are not part of the CI. With each step finished successfully, the next step can be started. Sometimes, due to last minute changes, steps need to be redone!
+
+The following can be done at any time but it must be done _latest_ when no envvar changes are made which is just before a new release gets finally tagged. The data generated _must_ be part of the upcoming release and be merged before tagging/branching!
+
+== Special Scope Envvars
+
+Ask the developers if envvars of this type have been changed (added or removed). See the xref:./special-envvars.md#special-scope-envvars.adoc[Special Envvars] documentation for more details on how to manage such a change.
+
+== Extended Envvars
+
+* From the ocis root run:\
+`sudo make docs-clean`\
+`make docs-generate`\
+Discard any changes in `env_vars.yaml`!
+* Check if there is a change in the `extended-envars.yaml` output.\
+If so, process xref:./special-envvars.md#fixing-changed-items.adoc[Extended Envvars - Fixing Changed Items].
+* When done, re-run `make docs-generate` and check if the output matches the expectations in `./docs/services/_includes/adoc/extended_configvars.adoc`.
+
+== Ordinary Envvars
+
+=== Set the Correct IntroductionVersion
+
+* Once the release is cut, _before_ creating the first release candidate, replace them with the actual semantic version (e.g. `releaseX` → `8.1.0`). To find these placeholders in `introductionVersion` keys, you can run a helper script by issuing the following command:
+ ```bash
+ docs/ocis/helpers/identify_envvar_placeholder_names.sh
+ ```
+
+[NOTE]
+====
+ A new production version _MUST NOT_ contain any alphabetic identifyers but the semantic version only, using _major, minor and a patch version, which is always 0!_.
+====
+
+
+* Create a PR and merge it _before_ taking the next step maintaining the `env_vars.yaml` file! Do not forget to rebase your local git repo.
+
+=== Maintain the 'env_vars.yaml' File
+
+This is _mandatory for a new release_ !
+
+* From the ocis root run:\
+`sudo make docs-clean`\
+`make docs-generate`\
+Any changes in `env_vars.yaml` are now considered.
+* This file will most likely show changes and merging them is _essential_ as base for _added/removed or deprecated envvars_ (envvar deltas). Note that this file will get additions/updates only, but items never get deleted automatically !!\
+[NOTE]
+====
+Note that due to how the code is currently designed, _things may get shifted_ around though no real changes have been introduced.
+====
+
+* With a new branch, remove all envvars from the `env_vars.yaml` file manually that have formerly been deprecated _and removed_ from the code.
+* Commit the changes and merge it.\
+Now, `env_vars.yaml` is up to date in the repo in master. Next steps depend on this updated file!
+
+=== Create Envvar Delta Files
+
+* Create xref:./env-var-deltas/.adoc[Envvar Deltas Between Versions] files according the linked description.
diff --git a/modules/developer/pages/services/general-info/envvars/special-envvars.adoc b/modules/developer/pages/services/general-info/envvars/special-envvars.adoc
new file mode 100644
index 00000000..a470e840
--- /dev/null
+++ b/modules/developer/pages/services/general-info/envvars/special-envvars.adoc
@@ -0,0 +1,82 @@
+= Special Envvars
+:toc: right
+:toclevels: 3
+
+
+Handling these envvars properly is very important for the automated doc process for both the developer and the admin docs!
+
+== Special Scope Envvars
+
+Variables with special scope are only related to a deployment method such as `OCIS_RUN_SERVICES`. These variables cannot be gathered automatically, rarely change, can be viewed and must be maintained manually via the link:https://doc.owncloud.com/ocis/next/deployment/services/env-vars-special-scope.html[admin documentation].
+
+== Extended Envvars
+
+Environment variables with extended scope are not included in a service. They are rarely added or removed, though their code location can change during development.
+
+They are variables that must be present before the core or services start up because they depend on information such as the path to configuration files. Therefore, they are not bound to services like other environment variables. Extended environment variables are identified via `os.Getenv` and are usually defined via a subfolder of `ocis-pkg`. The real envvar name cannot be automatically assigned and must be defined manually via the code in the generated `extended_vars.yaml` file.
+
+While generating the ocis Developer Documentation, the `extended_vars.yaml` file located in `/docs/helpers/` might be updated which needs special care to finalize the process. When merged, an `extended_configvars.adoc` file is internally generated from it. This file, along with the others, is moved to the `doc` branch. The process runs automatically, and no additional effort is required. The admin docs picks this .adoc file for further processing.
+
+The file for the master (`docs`) branch is located at:\
+`https://github.com/owncloud/ocis/tree/docs/services/_includes/adoc/extended_configvars.adoc`\
+respectivle in any `docs-stable-x.y` branch.
+
+=== General Info
+
+The process behind updating the `extended_vars.yaml` is non-destructive. This means, that the process checks the code if values found match those in the file already present. If differences occur, only _new_ content blocks are added, independent if it is new or moved code. The file is recreated when deleted - try to avoid this and maintain the changed one.
+
+This also means, that if generating the docs result in a change in the `extended_vars.yaml` file, manual action _must_ be taken and the final changes need to be committed/pushed/merged. If this is not done, the `extended_configvars.adoc` will contain invalid and/or corrupt data.
+
+It can happen that extended envvars are found but do not need to be published as they are for internal use only. Those envvars can be defined to be ignored for further processing.
+
+_IMPORTANT:_
+
+- _First Time Identification_\
+ Once an extended envvar has been identified, it is added to the `extended_vars.yaml` file found, but never changed or touched by the process anymore. There is one exception with respect to single/double quote usage. While you can (and will) manually define a text like: `"'/var/lib/ocis'"`, quotes are transformed by the process in the .yaml file to: `'''/var/lib/ocis'''`. There is no need to change this back, as the final step transforms this correctly for the adoc table.
+
+- _Item Naming_\
+ An extended envvar may not have the right naming. It may appear as `name: _registryEnv`. In case, this envvar needs to be named properly like `name: MICRO_REGISTRY` which can only be done in close alignment with development.
+
+- _Automatic Data Population_:\
+ `rawname`, `path` and `foundincode` are automatically filled by the program.\
+ _IMPORTANT_: DO NOT EDIT THESE VALUES MANUALLY - except the line number in the `path` key.
+
+- _Manual Data Population_:\
+ The following keys can and must be updated manually: `name`, `type`, `default_value`, `description`, `do_ignore`\
+ For the `path` key, _only_ the line number of the value may be changed, see fixing values below.
+
+- _Item Uniqueness_\
+ The identification, if an envvar is already present in the yaml file, is made via the `rawname` and the `path` identifier which includes the line number. _If there is a change in the source file shifting line numbers, new items will get added and old ones do not get touched._ Though technically ok, this can cause confusion to identify which items are correctly present or just added additionally just be cause code location has changed. If there are multiple occurrences of the same `rawname` value, check which one contains relevant data and set `do_ignore` to `false` and all others to `true`. When there are two identical blocks with different source references, mostly the one containing a proper `default_value` is the active one. Populate the false block with the envvar data to be used.
+
+- _Sort Ordering_\
+ Do not change the sort order of extended envvar blocks as they are automatically reordered alphabetically.
+
+- _Mandatory Key Values_\
+ Because extended envvars do not have the same structural setup as "normal" envvars (like type, description or defaults), this info needs to be provided manually once - for each valid block. Any change of this info will be noticed during the next CI run, the corresponding `extended_configvars.adoc` file will be generated, changes moved to the docs branch and published in the next admin docs build. See the following example with all keys listed and populated:
+ ```yaml
+ rawname: registryAddressEnv
+ path: ocis-pkg/registry/registry.go:44
+ foundincode: true
+ name: MICRO_REGISTRY_ADDRESS
+ type: string
+ default_value: ""
+ description: The bind address of the internal go micro framework. Only change on
+ supervision of ownCloud Support.
+ do_ignore: false
+ ```
+
+=== Fixing Changed Items
+
+If there is a change in `extended_vars.yaml` which you can identify via git when running e.g. `make -C docs docs-generate`, read the <> section first and follow the items listed below afterwards.
+
+- _Fixing Items_\
+ If an item has been identified as additionally added such as there was a change in the code location only, it is mostly sufficient to just fix the line number in the `path` key of the existing/correct one and double check by removing the newly added ones. Then, re-run `make -C docs docs-generate`. If the fix was correct, no new items of the same will re-appear.
+
+- _Remove Orphaned Items_\
+ To get rid of items with wrong line numbers, check `rawname` the `path` and correct the _existing ones_, especially the one containing the description and which is marked `do_ignore` false. Only items that have a real line number match need to be present, orphaned items can safely be removed.
+
+ You can double-check valid items by creating a dummy branch, delete the `extended_vars.yaml` and run `make -C docs docs-generate` to regenerate the file having only items with valid path references. With that info, you can remove orphaned items from the live file. Note to be careful on judging only on `foundincode` set to false indicating an item not existing anymore. Fix all items first, when rerunning `make -C docs docs-generate`, this may change back to true!
+
+ I an envvar has been removed from the code completely, you can also remove the respective entry block from the file.
+
+- When all is set, create a PR and merge it.
diff --git a/modules/developer/pages/services/general-info/index.adoc b/modules/developer/pages/services/general-info/index.adoc
new file mode 100644
index 00000000..42909dbd
--- /dev/null
+++ b/modules/developer/pages/services/general-info/index.adoc
@@ -0,0 +1,7 @@
+= General Information
+:toc: right
+:toclevels: 3
+
+== General Information
+
+This section provides general information valid for all services.
diff --git a/modules/developer/pages/services/general-info/new-service-checklist.adoc b/modules/developer/pages/services/general-info/new-service-checklist.adoc
new file mode 100644
index 00000000..0e28f824
--- /dev/null
+++ b/modules/developer/pages/services/general-info/new-service-checklist.adoc
@@ -0,0 +1,49 @@
+= New Service Checklist
+:toc: right
+:toclevels: 3
+
+When a new service gets introduced, this checklist is a good starting point for things that need to be completed before the service gets published (merged). This list is without claim of completeness or correct sort order.
+
+== New Service Checklist
+
+Use this checklist with copy/paste in your PR - right from the beginning. It renders correctly in your PR.
+
+[source,markdown]
+----
+- [ ] Services MUST NOT be named `extended` or `global`. These are reserved names for the automated documentation process.
+- [ ] Provide a README.md for that service in the root folder of that service.
+ - Use CamelCase for section headers.
+- [ ] For images and example files used in README.md:
+ - Create a folder named `md-sources` on the same level where README.md is located. Put all the images and example files referenced by README.md into this folder.
+ - Use absolute references like `https://raw.githubusercontent.com/owncloud/ocis/master/services//md-sources/file` to make the content accessible for both README.md and owncloud.dev
+ bad `
`
+ good `
`
+- [ ] If new CLI commands are introduced, those commands must be described in the README.md.
+ - Commands are added to `ocis/pkg/command`
+- [ ] If new global envvars are introduced, the name must start with `OCIS_`.
+- [ ] Add the service to the makefile in the ocis repo root.
+- [ ] Service startup:
+ - add it to `ocis/pkg/command/services.go`
+ - Include for automatic startup:
+ - add it to `ocis/pkg/runtime/service/service.go`
+ - Exclude from automatic startup:
+ - add it to the `populate optional services` block in `ocis/pkg/runtime/service/service.go`
+ - Add the service config to `ocis-pkg/config/defaultconfig.go`
+- [ ] If the service is using service accounts, add it to `ocis/pkg/init/init.go`
+- [ ] Check that the service properly responds to `ocis health` and has `/healthz` and `/readyz` endpoints
+- [ ] Add the service to `.drone.star` to enable CI.
+- [ ] Inform doc team in an *early stage* to review the readme AND the environment variables created.
+ - The description must reflect the behaviour AND usually has a positive code quality impact.
+- [ ] Create proper description strings for envvars - see other services for examples, especially when it comes to multiple values. This must include:
+ - base description, set of available values, description of each value.
+- [ ] When suggested commits are created for text changes, and you agree, collect them to a batch and commit them. Do not forget to rebase locally to avoid overwriting the changes made.
+- [ ] If new envvars are introduced which serve the same purpose but in multiple services, an additional envvar must be added at the beginning of the list starting with `OCIS_` (global envvar).
+- [ ] Ensure that a service has a debug port
+- [ ] If the new service introduces a new port:
+ - The port must be added to [port-ranges.md](https://github.com/owncloud/ocis/blob/master/docs/services/general-info/port-ranges.md) and to the README.md file.
+- [ ] Make sure to have a function `FullDefaultConfig()` in `pkg/config/defaults/defaultconfig.go` of your service. It is needed to create the documentation.
+- [ ] Add metrics to the code to enable monitoring. See the proxy service for implementation details.
+ - Plus add documentation about monitoring in the README.md file
+- [ ] When the service requires translations that have to be covered by the service and are not sourced by web, see the [add translation]({{< ref "./add-translations.md" >}}) documentation for more details.
+- [ ] If the service requires a `cache` or `store`, check existing services for implementation and add a documentation in the README.md
+----
diff --git a/modules/developer/pages/services/general-info/port-ranges.adoc b/modules/developer/pages/services/general-info/port-ranges.adoc
new file mode 100644
index 00000000..125ff47d
--- /dev/null
+++ b/modules/developer/pages/services/general-info/port-ranges.adoc
@@ -0,0 +1,207 @@
+= Port Ranges
+:toc: right
+:toclevels: 3
+
+oCIS services often need a port to expose their services to other services or the outside world. As users may have many different extensions running on the same machine, we should track port usage in the oCIS ecosystem. In the best case, we ensure that each extension uses a non-colliding port range, to make life easier for users.
+
+This page tracks the knowingly used port ranges.
+
+Feel free to "reserve" a free port range when you're developing an extension by adding your extension to the list (see the edit button in the top right corner).
+
+If you're developing a non-public extension, we recommend using ports outside of the ranges listed below.
+
+We also suggest using the last port in your extensions' range as a debug/metrics port.
+
+== Allocations
+
+| Port range | Service |
+|------------|----------------------------------------------------------------------------------------|
+| 9000-9010 | xref:../../../ocis/index.adoc[reserved for Infinite Scale] |
+| 9100-9104 | xref:../web/index.adoc[web] |
+| 9105-9109 | link:https://github.com/owncloud/ocis-hello[hello] |
+| 9110-9114 | xref:../ocs/index.adoc[ocs] |
+| 9115-9119 | xref:../webdav/index.adoc[webdav] |
+| 9120-9124 | xref:../graph/index.adoc[graph] |
+| 9125-9129 | xref:../policies/index.adoc[policies] |
+| 9130-9134 | xref:../idp/index.adoc[idp] |
+| 9135-9139 | xref:../sse/index.adoc[sse] |
+| 9140-9141 | xref:../frontend/index.adoc[frontend] |
+| 9142-9143 | xref:../gateway/index.adoc[gateway] |
+| 9144-9145 | xref:../users/index.adoc[users] |
+| 9146-9147 | xref:../auth-basic/index.adoc[auth-basic] |
+| 9148-9149 | xref:../auth-bearer/index.adoc[auth-bearer] |
+| 9150-9153 | xref:../sharing/index.adoc[sharing] |
+| 9154-9156 | xref:../storage-shares/index.adoc[storage-shares] |
+| 9157-9159 | xref:../storage-users/index.adoc[storage-users] |
+| 9160-9162 | xref:../groups/index.adoc[groups] |
+| 9163 | xref:../ocdav/index.adoc[ocdav] |
+| 9164 | xref:../groups/index.adoc[groups] |
+| 9165 | xref:../app-provider/index.adoc[app-provider] |
+| 9166-9169 | xref:../auth-machine/index.adoc[auth-machine] |
+| 9170-9174 | xref:../notifications/index.adoc[notifications] |
+| 9175-9179 | xref:../storage-publiclink/index.adoc[storage-publiclink] |
+| 9180-9184 | FREE (formerly used by accounts) |
+| 9185-9189 | xref:../thumbnails/index.adoc[thumbnails] |
+| 9190-9194 | xref:../settings/index.adoc[settings] |
+| 9195-9197 | xref:../activitylog/index.adoc[activitylog] |
+| 9198-9199 | xref:../auth-service/index.adoc[auth-service] |
+| 9200-9204 | xref:../proxy/index.adoc[proxy] |
+| 9205-9209 | xref:../proxy/index.adoc[proxy] |
+| 9210-9214 | xref:../userlog/index.adoc[userlog] |
+| 9215-9219 | xref:../storage-system/index.adoc[storage-system] |
+| 9220-9224 | xref:../search/index.adoc[search] |
+| 9225-9229 | xref:../audit/index.adoc[audit] |
+| 9230-9234 | xref:../nats/index.adoc[nats] |
+| 9235-9239 | xref:../idm/index.adoc[idm] |
+| 9240-9244 | xref:../app-registry/index.adoc[app-registry] |
+| 9245-9249 | xref:../auth-app/index.adoc[auth-app] |
+| 9250-9254 | link:https://github.com/owncloud/ocis/tree/master/ocis/pkg/runtime[ocis server (runtime)] |
+| 9255-9259 | xref:../postprocessing/index.adoc[postprocessing] |
+| 9260-9264 | xref:../clientlog/index.adoc[clientlog] |
+| 9265-9269 | xref:../clientlog/index.adoc[clientlog] |
+| 9270-9274 | xref:../eventhistory/index.adoc[eventhistory] |
+| 9275-9279 | xref:../webfinger/index.adoc[webfinger] |
+| 9280-9284 | xref:../ocm/index.adoc[ocm] |
+| 9285-9289 | FREE |
+| 9290-9294 | FREE |
+| 9295-9299 | FREE |
+| 9300-9304 | xref:../collaboration/index.adoc[collaboration] |
+| 9305-9309 | FREE |
+| 9310-9314 | FREE |
+| 9315-9319 | FREE |
+| 9320-9324 | FREE |
+| 9325-9329 | FREE |
+| 9330-9334 | FREE |
+| 9335-9339 | FREE |
+| 9340-9344 | FREE |
+| 9345-9349 | FREE |
+| 9350-9354 | xref:../ocdav/index.adoc[ocdav] |
+| 9355-9359 | FREE |
+| 9360-9364 | FREE |
+| 9365-9369 | FREE |
+| 9370-9374 | FREE |
+| 9375-9379 | FREE |
+| 9380-9384 | FREE |
+| 9385-9389 | FREE |
+| 9390-9394 | FREE |
+| 9395-9399 | FREE |
+| 9400-9404 | FREE |
+| 9405-9409 | FREE |
+| 9410-9414 | FREE |
+| 9415-9419 | FREE |
+| 9420-9424 | FREE |
+| 9425-9429 | FREE |
+| 9430-9434 | FREE |
+| 9435-9439 | FREE |
+| 9440-9444 | FREE |
+| 9445-9449 | FREE |
+| 9450-9454 | FREE |
+| 9455-9459 | FREE |
+| 9460-9464 | FREE (formerly used by store-service) |
+| 9465-9469 | FREE |
+| 9470-9474 | FREE |
+| 9475-9479 | FREE |
+| 9480-9484 | FREE |
+| 9485-9489 | FREE |
+| 9490-9494 | FREE |
+| 9495-9499 | FREE |
+| 9500-9504 | FREE |
+| 9505-9509 | FREE |
+| 9510-9514 | FREE |
+| 9515-9519 | FREE |
+| 9520-9524 | FREE |
+| 9525-9529 | FREE |
+| 9530-9534 | FREE |
+| 9535-9539 | FREE |
+| 9540-9544 | FREE |
+| 9545-9549 | FREE |
+| 9550-9554 | FREE |
+| 9555-9559 | FREE |
+| 9560-9564 | FREE |
+| 9565-9569 | FREE |
+| 9570-9574 | FREE |
+| 9575-9579 | FREE |
+| 9580-9584 | FREE |
+| 9585-9589 | FREE |
+| 9590-9594 | FREE |
+| 9595-9599 | FREE |
+| 9600-9604 | FREE |
+| 9605-9609 | FREE |
+| 9610-9614 | FREE |
+| 9615-9619 | FREE |
+| 9620-9624 | FREE |
+| 9625-9629 | FREE |
+| 9630-9634 | FREE |
+| 9635-9639 | FREE |
+| 9640-9644 | FREE |
+| 9645-9649 | FREE |
+| 9650-9654 | FREE |
+| 9655-9659 | FREE |
+| 9660-9664 | FREE |
+| 9665-9669 | FREE |
+| 9670-9674 | FREE |
+| 9675-9679 | FREE |
+| 9680-9684 | FREE |
+| 9685-9689 | FREE |
+| 9690-9694 | FREE |
+| 9695-9699 | FREE |
+| 9700-9704 | FREE |
+| 9705-9709 | FREE |
+| 9710-9714 | FREE |
+| 9715-9719 | FREE |
+| 9720-9724 | FREE |
+| 9725-9729 | FREE |
+| 9730-9734 | FREE |
+| 9735-9739 | FREE |
+| 9740-9744 | FREE |
+| 9745-9749 | FREE |
+| 9750-9754 | FREE |
+| 9755-9759 | FREE |
+| 9760-9764 | FREE |
+| 9765-9769 | FREE |
+| 9770-9774 | FREE |
+| 9775-9779 | FREE |
+| 9780-9784 | FREE |
+| 9785-9789 | FREE |
+| 9790-9794 | FREE |
+| 9795-9799 | FREE |
+| 9800-9804 | FREE |
+| 9805-9809 | FREE |
+| 9810-9814 | FREE |
+| 9815-9819 | FREE |
+| 9820-9824 | FREE |
+| 9825-9829 | FREE |
+| 9830-9834 | FREE |
+| 9835-9839 | FREE |
+| 9840-9844 | FREE |
+| 9845-9849 | FREE |
+| 9850-9854 | FREE |
+| 9855-9859 | FREE |
+| 9860-9864 | FREE |
+| 9865-9869 | FREE |
+| 9870-9874 | FREE |
+| 9875-9879 | FREE |
+| 9880-9884 | FREE |
+| 9885-9889 | FREE |
+| 9890-9894 | FREE |
+| 9895-9899 | FREE |
+| 9900-9904 | FREE |
+| 9905-9909 | FREE |
+| 9910-9914 | FREE |
+| 9915-9919 | FREE |
+| 9920-9924 | FREE |
+| 9925-9929 | FREE |
+| 9930-9934 | FREE |
+| 9935-9939 | FREE |
+| 9940-9944 | FREE |
+| 9945-9949 | FREE |
+| 9950-9954 | FREE |
+| 9955-9959 | FREE |
+| 9960-9964 | FREE |
+| 9965-9969 | FREE |
+| 9970-9974 | FREE |
+| 9975-9979 | FREE |
+| 9980-9984 | FREE |
+| 9985-9989 | FREE |
+| 9990-9994 | FREE |
+| 9995-9999 | FREE |
diff --git a/modules/developer/pages/services/general-info/registry.adoc b/modules/developer/pages/services/general-info/registry.adoc
new file mode 100644
index 00000000..cc107425
--- /dev/null
+++ b/modules/developer/pages/services/general-info/registry.adoc
@@ -0,0 +1,39 @@
+= Registry
+:toc: right
+:toclevels: 3
+
+To be able to communicate with each other, services need to register in a common registry.
+
+
+== Configuration
+
+The type of registry to use can be configured with the `MICRO_REGISTRY` environment variable. Supported values are:
+
+=== `nats-js-kv` (Default)
+
+Set the environment variable to `nats-js-kv` or leave it empty to use a nats-js key value store as registry.
+
+- Note: If not running build-in nats, `MICRO_REGISTRY_ADDRESS` needs to be set to the address of the nats-js cluster, which is the same value as `OCIS_EVENTS_ENDPOINT`.
+- Optional: Use `MICRO_REGISTRY_AUTH_USERNAME` and `MICRO_REGISTRY_AUTH_PASSWORD` to authenticate with the nats cluster.
+
+=== `kubernetes`
+
+When deploying in a kubernetes cluster, the Kubernetes registry can be used. Additionally, the `MICRO_REGISTRY_ADDRESS` environment variable needs to be set to the url of the Kubernetes registry.
+
+=== `memory`
+
+Setting the environment variable to `memory` starts an in-memory registry. This only works with the single binary deployment.
+
+=== Deprecated Registries
+
+These registries are currently working but will be removed in a later version. It is recommended to switch to a supported one.
+
+- `nats`\
+ Uses a registry based on nats streams. Requires `MICRO_REGISTRY_ADDRESS` to be set.
+- `etcd`\
+ Uses an etcd cluster as the registry. Requires `MICRO_REGISTRY_ADDRESS` to be set.
+- `consul`\
+ Uses `HashiCorp Consul` as registry. Requires `MICRO_REGISTRY_ADDRESS` to be set.
+- `mdns`\
+ Uses multicast dns for registration. This type can have unwanted side effects when other devices in the local network use mdns too.
+
diff --git a/modules/developer/pages/services/graph/configuration.adoc b/modules/developer/pages/services/graph/configuration.adoc
new file mode 100644
index 00000000..eca9b3a7
--- /dev/null
+++ b/modules/developer/pages/services/graph/configuration.adoc
@@ -0,0 +1,13 @@
+= Service Configuration
+:toc: right
+:toclevels: 3
+
+== Example YAML Config
+
+// AUTO-GENERATED CONTENT: services/_includes/graph-config-example.yaml
+[source,yaml]
+----
+// Include from: services/_includes/graph-config-example.yaml
+----
+
+// AUTO-GENERATED CONTENT: services/_includes/graph_configvars.md
\ No newline at end of file
diff --git a/modules/developer/pages/services/graph/unified-roles.adoc b/modules/developer/pages/services/graph/unified-roles.adoc
new file mode 100644
index 00000000..9b40c794
--- /dev/null
+++ b/modules/developer/pages/services/graph/unified-roles.adoc
@@ -0,0 +1,37 @@
+= Unified Roles
+:toc: right
+:toclevels: 3
+
+
+== Create a New Built-in Role
+
+To create a new built-in role, it is necessary to:
+
+- Create role in Reva
+- Update Reva in oCIS
+- Add newly created role to oCIS
+
+=== Add Role to Reva
+
+In the link:https://github.com/owncloud/reva[Reva repository], add the role into the `/pkg/conversions/role.go` file:
+
+1. Add a role name constant for this role. See the existing ones for how this is setup
+1. Add a new function to create a new role struct with the role name constant and desired permissions
+1. Add the role to the `RoleFromName` function
+1. In `/pkg/conversions/role_test.go`, extend unit tests to cover the new role
+
+=== Add Role to oCIS
+
+After adding the role to Reva and updating the Reva in oCIS, it is necessary to add the role to oCIS as well:
+
+1. Generate UUID for the role
+1. In `/services/graph/pkg/unifiedrole/roles.go`, add the role ID generated in the first step as a constant
+1. In `/services/graph/pkg/unifiedrole/roles.go`, add translatable role display name and description variables
+1. In `/services/graph/pkg/unifiedrole/roles.go`, add role variable with a function to create the role\
+The function should first create the role struct using the function from Reva and return the `UnifiedRoleDefinition` struct.
+1. In `/services/graph/pkg/unifiedrole/filter.go`, add the role into the `buildInRoles` function
+1. In `/services/graph/pkg/config/defaults/defaultconfig.go`, if the role is not intended to be enabled by default, add the role ID into the `_disabledByDefaultUnifiedRoleRoleIDs` constant
+1. In `/services/graph/pkg/unifiedrole/export_test.go`, add the role variable
+1. In `/services/graph/pkg/unifiedrole/roles_test.go`, extend unit tests to cover the new role
+1. In `/services/web/pkg/theme/theme.go`, add the role into the `common.shareRoles`
+2. In `/services/graph/README.md`, add the role to the list of built-in roles
diff --git a/modules/developer/pages/services/groups/configuration.adoc b/modules/developer/pages/services/groups/configuration.adoc
new file mode 100644
index 00000000..937a28b0
--- /dev/null
+++ b/modules/developer/pages/services/groups/configuration.adoc
@@ -0,0 +1,13 @@
+= Service Configuration
+:toc: right
+:toclevels: 3
+
+== Example YAML Config
+
+// AUTO-GENERATED CONTENT: services/_includes/groups-config-example.yaml
+[source,yaml]
+----
+// Include from: services/_includes/groups-config-example.yaml
+----
+
+// AUTO-GENERATED CONTENT: services/_includes/groups_configvars.md
diff --git a/modules/developer/pages/services/groups/index.adoc b/modules/developer/pages/services/groups/index.adoc
new file mode 100644
index 00000000..b147093f
--- /dev/null
+++ b/modules/developer/pages/services/groups/index.adoc
@@ -0,0 +1,9 @@
+= Groups
+:toc: right
+:toclevels: 3
+
+== Abstract
+
+
+== Table of Contents
+
diff --git a/modules/developer/pages/services/idm/admin_password_reset.adoc b/modules/developer/pages/services/idm/admin_password_reset.adoc
new file mode 100644
index 00000000..650cd0b6
--- /dev/null
+++ b/modules/developer/pages/services/idm/admin_password_reset.adoc
@@ -0,0 +1,18 @@
+= Resetting a lost administrator password
+:toc: right
+:toclevels: 3
+
+== Resetting a lost administrator password
+By default, when using oCIS with the builtin IDM an ad generates the
+user `admin` (DN `uid=admin,ou=users,o=libregraph-idm`) if, for any
+reason, the password of that user is lost, it can be reset using
+the `resetpassword` sub-command:
+
+----
+ocis idm resetpassword
+----
+
+It will prompt for a new password and set the password of that user
+accordingly. Note: As this command is accessing the idm database directly
+will only work while ocis is not running and nothing else is accessing
+database.
diff --git a/modules/developer/pages/services/idm/configuration.adoc b/modules/developer/pages/services/idm/configuration.adoc
new file mode 100644
index 00000000..8ae2c786
--- /dev/null
+++ b/modules/developer/pages/services/idm/configuration.adoc
@@ -0,0 +1,13 @@
+= Service Configuration
+:toc: right
+:toclevels: 3
+
+== Example YAML Config
+
+// AUTO-GENERATED CONTENT: services/_includes/idm-config-example.yaml
+[source,yaml]
+----
+// Include from: services/_includes/idm-config-example.yaml
+----
+
+// AUTO-GENERATED CONTENT: services/_includes/idm_configvars.md
\ No newline at end of file
diff --git a/modules/developer/pages/services/idm/configuration_hints.adoc b/modules/developer/pages/services/idm/configuration_hints.adoc
new file mode 100644
index 00000000..e33d5993
--- /dev/null
+++ b/modules/developer/pages/services/idm/configuration_hints.adoc
@@ -0,0 +1,43 @@
+= Configuration Hints
+:toc: right
+:toclevels: 3
+
+== TLS Server Certificates
+By default IDM generates a self-signed certificate and key on first startup to be
+able to provide TLS protected services. The certificate is stored in
+`idm/ldap.crt` inside the oCIS base data directory. The key is in
+`idm/ldap.key` in the same directory. You can use a custom server
+certificate by setting the `IDM_LDAPS_CERT` and `IDM_LDAPS_KEY`.
+
+== Default / Demo Users
+On startup IDM creates a set of default services users that are needed
+internally to provide access to IDM to other oCIS services. These users are stored
+in a separate subtree. The base DN of that subtree is:
+`ou=sysusers,o=libregraph-idm`. The service users are:
+
+* `uid=libregraph,ou=sysusers,o=libregraph-idm`: This is the only user with write
+ access to the LDAP tree. It is used by the Graph service to look up, create, delete and
+ modify users and groups.
+* `uid=idp,ou=sysusers,o=libregraph-idm`: This user is used by the IDP service to
+ perform user lookups for authentication.
+* `uid=reva,ou=sysusers,o=libregraph-idm`: This user is used by the "reva" services
+ `user`, `group` and `auth-basic`.
+
+IDM is also able to create link:../../../ocis/getting-started/demo-users[Demo Users]
+upon startup.
+
+== Access via LDAP command line tools
+For testing purposes it is sometimes helpful to query IDM using the ldap
+command line clients. To e.g. list all users, this command can be used:
+
+----
+ldapsearch -x -H ldaps://127.0.0.1:9235 -x -D uid=libregraph,ou=sysusers,o=libregraph-idm -w idm -b o=libregraph-idm objectclass=inetorgperson
+----
+
+When using the default configuration with the self-signed server certificate,
+you might need to switch off the certificate validation using the `LDAPTL_REQCERT` env
+variable:
+
+----
+LDAPTLS_REQCERT=never ldapsearch -x -H ldaps://127.0.0.1:9235 -x -D uid=libregraph,ou=sysusers,o=libregraph-idm -w idm -b o=libregraph-idm objectclass=inetorgperson
+----
diff --git a/modules/developer/pages/services/idp/configuration.adoc b/modules/developer/pages/services/idp/configuration.adoc
new file mode 100644
index 00000000..86e24287
--- /dev/null
+++ b/modules/developer/pages/services/idp/configuration.adoc
@@ -0,0 +1,13 @@
+= Service Configuration
+:toc: right
+:toclevels: 3
+
+== Example YAML Config
+
+// AUTO-GENERATED CONTENT: services/_includes/idp-config-example.yaml
+[source,yaml]
+----
+// Include from: services/_includes/idp-config-example.yaml
+----
+
+// AUTO-GENERATED CONTENT: services/_includes/idp_configvars.md
\ No newline at end of file
diff --git a/modules/developer/pages/services/idp/theming.adoc b/modules/developer/pages/services/idp/theming.adoc
new file mode 100644
index 00000000..0ca2f1c8
--- /dev/null
+++ b/modules/developer/pages/services/idp/theming.adoc
@@ -0,0 +1,45 @@
+= Theming
+:toc: right
+:toclevels: 3
+
+
+== Intro
+Our default IDP UI is built with the link:https://github.com/libregraph/lico[LibreGraph Connect] React app. Even though this app comes already with a simple theming options, we have compiled our own edited version of the app with more advanced changes than the default theming offers. Because of that, it is not possible at the moment to do any kind of easy theming and including custom theme means again compiling custom assets.
+
+== Customizing assets
+Depending on what changes you wish to do with the theme, there are several files you can edit. All of them are located in the `idp/ui` folder.
+
+=== Static assets
+If you wish to add static assets like images, CSS, etc., you can add them to `idp/ui/public/static`. The `public` folder also contains the `index.html` file which can be adjusted to your needs.
+
+=== CSS
+LibreGraph Connect is built with link:https://github.com/Kopano-dev/kpop[kpop], a collection of React UI components. To include any custom styles on top of that collection, you can define them in the `idp/ui/src/app.css` file. These rules will take precedence over the kpop.
+
+=== Containers
+Layouts of all pages are located in the `idp/ui/src/containers` folder. By editing any of files in that folder, you can do any kind of changes in the layout and create advanced themes. It is, however, important to be careful when touching this code as it imports also actions which are responsible for the login flow.
+
+==== What pages to theme
+- Login
+ - Login - login form used to authenticate the users
+ - Consent - consent page used to authorise apps for already signed-in users
+ - Chooseaccount - page with a list of accounts to choose from
+- Goodbye
+ - Goodbyescreen - goodbye message displayed to users after they signed out
+- Welcome
+ - Welcomescreen - welcome message displayed to users after they signed in
+
+=== Components
+`idp/ui/src/components` folder contains all custom components which are then imported into containers.
+
+=== Images
+Every image placed in `idp/ui/src/images` can be directly import into components or containers and will be optimized when compiling assets.
+
+=== Locales
+If you need to edit or add new locales, you can do so with json files in the `idp/ui/src/locales` folder. If adding new locale, make sure to add it also in the `index.js` file in the same folder.
+
+== Building assets
+In order to build all assets, run `pnpm build` in the `idp` folder. This script will compile all assets and output them into `idp/assets` folder.
+
+At this point, you have two possible ways how to deploy your new theme:
+- run `make generate` in the root folder of your oCIS clone and generate the new assets
+- start the IDP service directly with custom assets by specifying the env var `IDP_ASSET_PATH`
diff --git a/modules/developer/pages/services/index.adoc b/modules/developer/pages/services/index.adoc
new file mode 100644
index 00000000..085cfc00
--- /dev/null
+++ b/modules/developer/pages/services/index.adoc
@@ -0,0 +1,11 @@
+= Services
+:toc: right
+:toclevels: 3
+
+The documentation of services is intended for developers and only reflects the state of the master branch of the ocis repo.
+
+[WARNING]
+====
+See the link:https://doc.owncloud.com/ocis/next/deployment/services/services.html[admin documentation] which provides versioned content suitable for administrators. This documentation also offers other useful information including deployment guides.
+====
+
diff --git a/modules/developer/pages/services/invitations/configuration.adoc b/modules/developer/pages/services/invitations/configuration.adoc
new file mode 100644
index 00000000..8aa3c673
--- /dev/null
+++ b/modules/developer/pages/services/invitations/configuration.adoc
@@ -0,0 +1,13 @@
+= Service Configuration
+:toc: right
+:toclevels: 3
+
+== Example YAML Config
+
+// AUTO-GENERATED CONTENT: services/_includes/invitations-config-example.yaml
+[source,yaml]
+----
+// Include from: services/_includes/invitations-config-example.yaml
+----
+
+// AUTO-GENERATED CONTENT: services/_includes/invitations_configvars.md
\ No newline at end of file
diff --git a/modules/developer/pages/services/nats/configuration.adoc b/modules/developer/pages/services/nats/configuration.adoc
new file mode 100644
index 00000000..65dbe2a4
--- /dev/null
+++ b/modules/developer/pages/services/nats/configuration.adoc
@@ -0,0 +1,13 @@
+= Service Configuration
+:toc: right
+:toclevels: 3
+
+== Example YAML Config
+
+// AUTO-GENERATED CONTENT: services/_includes/nats-config-example.yaml
+[source,yaml]
+----
+// Include from: services/_includes/nats-config-example.yaml
+----
+
+// AUTO-GENERATED CONTENT: services/_includes/nats_configvars.md
\ No newline at end of file
diff --git a/modules/developer/pages/services/notifications/configuration.adoc b/modules/developer/pages/services/notifications/configuration.adoc
new file mode 100644
index 00000000..227be8c7
--- /dev/null
+++ b/modules/developer/pages/services/notifications/configuration.adoc
@@ -0,0 +1,13 @@
+= Service Configuration
+:toc: right
+:toclevels: 3
+
+== Example YAML Config
+
+// AUTO-GENERATED CONTENT: services/_includes/notifications-config-example.yaml
+[source,yaml]
+----
+// Include from: services/_includes/notifications-config-example.yaml
+----
+
+// AUTO-GENERATED CONTENT: services/_includes/notifications_configvars.md
\ No newline at end of file
diff --git a/modules/developer/pages/services/ocdav/configuration.adoc b/modules/developer/pages/services/ocdav/configuration.adoc
new file mode 100644
index 00000000..2105c668
--- /dev/null
+++ b/modules/developer/pages/services/ocdav/configuration.adoc
@@ -0,0 +1,13 @@
+= Service Configuration
+:toc: right
+:toclevels: 3
+
+== Example YAML Config
+
+// AUTO-GENERATED CONTENT: services/_includes/ocdav-config-example.yaml
+[source,yaml]
+----
+// Include from: services/_includes/ocdav-config-example.yaml
+----
+
+// AUTO-GENERATED CONTENT: services/_includes/ocdav_configvars.md
diff --git a/modules/developer/pages/services/ocm/configuration.adoc b/modules/developer/pages/services/ocm/configuration.adoc
new file mode 100644
index 00000000..7eacce57
--- /dev/null
+++ b/modules/developer/pages/services/ocm/configuration.adoc
@@ -0,0 +1,13 @@
+= Service Configuration
+:toc: right
+:toclevels: 3
+
+== Example YAML Config
+
+// AUTO-GENERATED CONTENT: services/_includes/ocm-config-example.yaml
+[source,yaml]
+----
+// Include from: services/_includes/ocm-config-example.yaml
+----
+
+// AUTO-GENERATED CONTENT: services/_includes/ocm.md
diff --git a/modules/developer/pages/services/ocm/create_share_flow.adoc b/modules/developer/pages/services/ocm/create_share_flow.adoc
new file mode 100644
index 00000000..3bc7f5d9
--- /dev/null
+++ b/modules/developer/pages/services/ocm/create_share_flow.adoc
@@ -0,0 +1,59 @@
+= Create Share Flow
+:toc: right
+:toclevels: 3
+
+== OCM Create Share Flow
+
+// SHORTCODE: {{< mermaid class="text-center">}}
+sequenceDiagram
+ box Instance A
+ participant osp as ocmsharesprovider
+ participant gwa as Gateway A
+ participant httpa as ocs
+ end
+ actor usera as User A
+ box Instance B
+ participant httpb as ocmd
+ participant gwb as Gateway B
+ participant ocmc as OCMCore
+ end
+
+ Note over usera: A shares a resource with B
+ usera->>+httpa: CreateShare
+ httpa->>+gwa: GetInfoByDomain
+ Note left of gwa: GetInfoByDomain (ocmproviderauthorizer)
+ gwa-->>-httpa: return
+
+ httpa->>+gwa: GetAcceptedUser
+ Note left of gwa: GetAcceptedUser (ocminvitemanager)
+ gwa-->>-httpa: return
+
+ httpa->>+gwa: CreateOCMShare
+ gwa->>+osp: CreateOCMShare
+ osp->>+gwa: Stat
+ gwa-->>-osp: return
+
+ Note left of osp: store share in repo
+
+ osp->>+httpb: POST /shares
+ httpb->>+gwb: IsProviderAllowed
+ Note right of gwb: IsProviderAllowed (ocmproviderauthorizer)
+ gwb-->>-httpb: return
+
+ httpb->>+gwb: GetUser
+ Note right of gwb: GetUser (userprovider)
+ gwb-->>-httpb: return
+
+ httpb->>+gwb: CreateOCMCoreShare
+ gwb->>+ocmc: CreateOCMCoreShare
+ Note right of ocmc: StoreReceivedShare
+ ocmc-->>-gwb: return
+ gwb-->>-httpb: return
+ httpb-->>-osp: return
+ osp-->>-gwa: return
+ gwa-->>-httpa: return
+ httpa->>+gwa: Stat
+ Note left of gwa: Stat (storageprovider)
+ gwa-->>-httpa: return
+ httpa-->>-usera: return
+// SHORTCODE: {{< /mermaid >}}
diff --git a/modules/developer/pages/services/ocm/invitation_flow.adoc b/modules/developer/pages/services/ocm/invitation_flow.adoc
new file mode 100644
index 00000000..acac02d4
--- /dev/null
+++ b/modules/developer/pages/services/ocm/invitation_flow.adoc
@@ -0,0 +1,49 @@
+= Invitation flow
+:toc: right
+:toclevels: 3
+
+== OCM Invitation Flow
+
+// SHORTCODE: {{< mermaid class="text-center">}}
+sequenceDiagram
+ box Instance A
+ participant ima as InviteManager A
+ participant gwa as Gateway A
+ participant httpa as HTTP Api A (ocm, sm)
+ end
+ actor usera as User A
+ actor userb as User B
+ box Instance B
+ participant httpb as HTTP Api B (ocm, sm)
+ participant gwb as Gateway B
+ participant imb as InviteManager B
+ end
+
+ Note over usera: A creates invitation token
+ usera->>+httpa: POST /generate-invite (sciencemesh)
+ httpa->>+gwa: GenerateInviteToken
+ gwa->>+ima: GenerateInviteToken
+ Note left of ima: store token in repo
+ ima-->>-gwa: return token
+ gwa-->>-httpa: return token
+ httpa-->>-usera: return token
+
+ Note over usera,userb: A passes token to B
+
+ Note over userb: B accepts invitation
+ userb->>+httpb: POST /accept-invite (sciencemesh)
+ httpb->>+gwb: ForwardInvite
+ gwb->>+imb: ForwardInvite
+ imb->>+httpa: POST /invite-accepted (ocm)
+ httpa->>+gwa: AcceptInvite
+ gwa->>+ima: AcceptInvite
+ Note left of ima: get token from repo
+ Note left of ima: add remote user
+ ima-->>-gwa: return
+ gwa-->>-httpa: return remote user
+ httpa->>-imb: return remote user
+ Note right of imb: add remote user
+ imb-->>-gwb: return
+ gwb-->>-httpb: return
+ httpb-->>-userb: return
+// SHORTCODE: {{< /mermaid >}}
\ No newline at end of file
diff --git a/modules/developer/pages/services/ocs/configuration.adoc b/modules/developer/pages/services/ocs/configuration.adoc
new file mode 100644
index 00000000..410f32bc
--- /dev/null
+++ b/modules/developer/pages/services/ocs/configuration.adoc
@@ -0,0 +1,13 @@
+= Service Configuration
+:toc: right
+:toclevels: 3
+
+== Example YAML Config
+
+// AUTO-GENERATED CONTENT: services/_includes/ocs-config-example.yaml
+[source,yaml]
+----
+// Include from: services/_includes/ocs-config-example.yaml
+----
+
+// AUTO-GENERATED CONTENT: services/_includes/ocs_configvars.md
\ No newline at end of file
diff --git a/modules/developer/pages/services/policies/configuration.adoc b/modules/developer/pages/services/policies/configuration.adoc
new file mode 100644
index 00000000..1719bb08
--- /dev/null
+++ b/modules/developer/pages/services/policies/configuration.adoc
@@ -0,0 +1,13 @@
+= Service Configuration
+:toc: right
+:toclevels: 3
+
+== Example YAML Config
+
+// AUTO-GENERATED CONTENT: services/_includes/policies-config-example.yaml
+[source,yaml]
+----
+// Include from: services/_includes/policies-config-example.yaml
+----
+
+// AUTO-GENERATED CONTENT: services/_includes/policies_configvars.md
diff --git a/modules/developer/pages/services/postprocessing/configuration.adoc b/modules/developer/pages/services/postprocessing/configuration.adoc
new file mode 100644
index 00000000..0962e293
--- /dev/null
+++ b/modules/developer/pages/services/postprocessing/configuration.adoc
@@ -0,0 +1,13 @@
+= Service Configuration
+:toc: right
+:toclevels: 3
+
+== Example YAML Config
+
+// AUTO-GENERATED CONTENT: services/_includes/postprocessing-config-example.yaml
+[source,yaml]
+----
+// Include from: services/_includes/postprocessing-config-example.yaml
+----
+
+// AUTO-GENERATED CONTENT: services/_includes/postprocessing_configvars.md
diff --git a/modules/developer/pages/services/proxy/configuration.adoc b/modules/developer/pages/services/proxy/configuration.adoc
new file mode 100644
index 00000000..3974f58f
--- /dev/null
+++ b/modules/developer/pages/services/proxy/configuration.adoc
@@ -0,0 +1,13 @@
+= Service Configuration
+:toc: right
+:toclevels: 3
+
+== Example YAML Config
+
+// AUTO-GENERATED CONTENT: services/_includes/proxy-config-example.yaml
+[source,yaml]
+----
+// Include from: services/_includes/proxy-config-example.yaml
+----
+
+// AUTO-GENERATED CONTENT: services/_includes/proxy_configvars.md
\ No newline at end of file
diff --git a/modules/developer/pages/services/search/configuration.adoc b/modules/developer/pages/services/search/configuration.adoc
new file mode 100644
index 00000000..d2875e05
--- /dev/null
+++ b/modules/developer/pages/services/search/configuration.adoc
@@ -0,0 +1,13 @@
+= Service Configuration
+:toc: right
+:toclevels: 3
+
+== Example YAML Config
+
+// AUTO-GENERATED CONTENT: services/_includes/search-config-example.yaml
+[source,yaml]
+----
+// Include from: services/_includes/search-config-example.yaml
+----
+
+// AUTO-GENERATED CONTENT: services/_includes/search_configvars.md
diff --git a/modules/developer/pages/services/settings/bundles.adoc b/modules/developer/pages/services/settings/bundles.adoc
new file mode 100644
index 00000000..2cae71cc
--- /dev/null
+++ b/modules/developer/pages/services/settings/bundles.adoc
@@ -0,0 +1,71 @@
+= Settings Bundles
+:toc: right
+:toclevels: 3
+
+A _Settings Bundle_ is a collection of settings, uniquely identified by the key of the
+extension registering the bundle and the key of the bundle itself. Its purpose is to let
+oCIS services define settings and make them available to users. They are dynamically
+rendered into forms, available in the frontend.
+
+As of now we support five different types of settings:
+- boolean
+- integer
+- string
+- single choice list of integers or strings
+- multiple choice list of integers or strings
+
+Each _Setting_ is uniquely identified by a key within the bundle. Some attributes
+depend on the chosen type of setting. Through the information provided with the
+attributes of the setting, the settings frontend dynamically renders form elements,
+allowing users to change their settings individually.
+
+== Example
+
+[source,json]
+----
+{
+ "identifier": {
+ "extension": "ocis-accounts",
+ "bundleKey": "profile"
+ },
+ "displayName": "Profile",
+ "settings": [
+ {
+ "settingKey": "lastname",
+ "displayName": "Lastname",
+ "description": "Input for lastname",
+ "stringValue": {
+ "placeholder": "Set lastname"
+ }
+ },
+ {
+ "settingKey": "age",
+ "displayName": "Age",
+ "description": "Input for age",
+ "intValue": {
+ "min": "16",
+ "max": "200",
+ "step": "2",
+ "placeholder": "Set age"
+ }
+ },
+ {
+ "settingKey": "timezone",
+ "displayName": "Timezone",
+ "description": "User timezone",
+ "singleChoiceValue": {
+ "options": [
+ {
+ "stringValue": "Europe/Berlin",
+ "displayValue": "Europe/Berlin"
+ },
+ {
+ "stringValue": "Asia/Kathmandu",
+ "displayValue": "Asia/Kathmandu"
+ }
+ ]
+ }
+ }
+ ]
+}
+----
diff --git a/modules/developer/pages/services/settings/configuration.adoc b/modules/developer/pages/services/settings/configuration.adoc
new file mode 100644
index 00000000..39fbbca5
--- /dev/null
+++ b/modules/developer/pages/services/settings/configuration.adoc
@@ -0,0 +1,13 @@
+= Service Configuration
+:toc: right
+:toclevels: 3
+
+== Example YAML Config
+
+// AUTO-GENERATED CONTENT: services/_includes/settings-config-example.yaml
+[source,yaml]
+----
+// Include from: services/_includes/settings-config-example.yaml
+----
+
+// AUTO-GENERATED CONTENT: services/_includes/settings_configvars.md
\ No newline at end of file
diff --git a/modules/developer/pages/services/settings/glossary.adoc b/modules/developer/pages/services/settings/glossary.adoc
new file mode 100644
index 00000000..33749670
--- /dev/null
+++ b/modules/developer/pages/services/settings/glossary.adoc
@@ -0,0 +1,35 @@
+= Glossary
+:toc: right
+:toclevels: 3
+
+In the context of this extension and oCIS in general, we are using the following terminology.
+
+=== Configuration
+
+- System configuration
+- e.g. service host names and ports
+- Changes need to be propagated to other services
+- Typically modified on the CLI
+
+=== Settings
+
+- Application level settings
+- e.g. default language
+- Can be modified at runtime without restarting the service
+
+=== Preferences
+
+- User settings
+- Subset of "Settings"
+- e.g. preferred language of a user
+
+=== Settings Bundle
+
+- Collection of related settings
+- Registered by an oCIS extension
+
+=== Settings Value
+
+- Manifestation of a setting for a specific user
+- E.g. used for customization (at runtime) in `ocis-web`
+- Can be queried and modified by other oCIS services
diff --git a/modules/developer/pages/services/settings/values.adoc b/modules/developer/pages/services/settings/values.adoc
new file mode 100644
index 00000000..77548559
--- /dev/null
+++ b/modules/developer/pages/services/settings/values.adoc
@@ -0,0 +1,71 @@
+= Settings Values
+:toc: right
+:toclevels: 3
+
+A _Settings Value_ is the value an authenticated user has chosen for a specific setting, defined in a
+_settings bundle_.
+
+== Identifying settings values
+
+A _settings value_ is uniquely identified by four attributes. Three of them are coming from the definition of
+the setting within it's settings bundle (see xref:bundles.adoc[Settings Bundles]
+for an example). The fourth identifies the user.
+- extension: Key of the extension that registered the settings bundle,
+- bundleKey: Key of the settings bundle,
+- settingKey: Key of the setting as defined within the bundle,
+- accountUuid: The UUID of the authenticated user who has saved the setting.
+
+[NOTE]
+====
+When requests are going through `ocis-proxy`, the accountUuid attribute can be set to the static keyword `me`
+instead of using a real UUID. `ocis-proxy` will take care of minting the UUID of the authenticated user into
+a JWT, providing it in the HTTP header as `x-access-token`. That UUID is then used in this service, to replace
+`me` with the actual UUID of the authenticated user.
+====
+
+
+== Example of stored settings values
+
+[source,json]
+----
+{
+ "values": {
+ "language": {
+ "identifier": {
+ "extension": "ocis-accounts",
+ "bundleKey": "profile",
+ "settingKey": "language",
+ "accountUuid": "5681371f-4a6e-43bc-8bb5-9c9237fa9c58"
+ },
+ "listValue": {
+ "values": [
+ {
+ "stringValue": "de"
+ }
+ ]
+ }
+ },
+ "timezone": {
+ "identifier": {
+ "extension": "ocis-accounts",
+ "bundleKey": "profile",
+ "settingKey": "timezone",
+ "accountUuid": "5681371f-4a6e-43bc-8bb5-9c9237fa9c58"
+ },
+ "listValue": {
+ "values": [
+ {
+ "stringValue": "Europe/Berlin"
+ }
+ ]
+ }
+ }
+ }
+}
+----
+
+== gRPC endpoints
+Services can use gRPC endpoints of the `ValueService` to query and modify _settings values_.
+The gRPC endpoints require the same identifier attributes as described above, so for making a request to
+the `ValueService` you will have to make sure that the accountUuid of the authenticated user is available in
+your service at the time of the request.
diff --git a/modules/developer/pages/services/sharing/configuration.adoc b/modules/developer/pages/services/sharing/configuration.adoc
new file mode 100644
index 00000000..1b204a23
--- /dev/null
+++ b/modules/developer/pages/services/sharing/configuration.adoc
@@ -0,0 +1,13 @@
+= Service Configuration
+:toc: right
+:toclevels: 3
+
+== Example YAML Config
+
+// AUTO-GENERATED CONTENT: services/_includes/sharing-config-example.yaml
+[source,yaml]
+----
+// Include from: services/_includes/sharing-config-example.yaml
+----
+
+// AUTO-GENERATED CONTENT: services/_includes/sharing_configvars.md
diff --git a/modules/developer/pages/services/sharing/index.adoc b/modules/developer/pages/services/sharing/index.adoc
new file mode 100644
index 00000000..bcef766f
--- /dev/null
+++ b/modules/developer/pages/services/sharing/index.adoc
@@ -0,0 +1,10 @@
+= Sharing
+:toc: right
+:toclevels: 3
+
+== Abstract
+
+This service implements the CS3 link:https://cs3org.github.io/cs3apis/#cs3.sharing.link.v1beta1.LinkAPI[LinkAPI] to manage public links as well as the link:https://cs3org.github.io/cs3apis/#cs3.sharing.collaboration.v1beta1.CollaborationAPI[CollaborationAPI] to manage user and group shares.
+
+== Table of Contents
+
diff --git a/modules/developer/pages/services/sse/configuration.adoc b/modules/developer/pages/services/sse/configuration.adoc
new file mode 100644
index 00000000..0c6e4bb0
--- /dev/null
+++ b/modules/developer/pages/services/sse/configuration.adoc
@@ -0,0 +1,13 @@
+= Service Configuration
+:toc: right
+:toclevels: 3
+
+== Example YAML Config
+
+// AUTO-GENERATED CONTENT: services/_includes/app-provider-config-example.yaml
+[source,yaml]
+----
+// Include from: services/_includes/app-provider-config-example.yaml
+----
+
+// AUTO-GENERATED CONTENT: services/_includes/app-provider_configvars.md
diff --git a/modules/developer/pages/services/storage-publiclink/configuration.adoc b/modules/developer/pages/services/storage-publiclink/configuration.adoc
new file mode 100644
index 00000000..05f7ae85
--- /dev/null
+++ b/modules/developer/pages/services/storage-publiclink/configuration.adoc
@@ -0,0 +1,13 @@
+= Service Configuration
+:toc: right
+:toclevels: 3
+
+== Example YAML Config
+
+// AUTO-GENERATED CONTENT: services/_includes/storage-publiclink-config-example.yaml
+[source,yaml]
+----
+// Include from: services/_includes/storage-publiclink-config-example.yaml
+----
+
+// AUTO-GENERATED CONTENT: services/_includes/storage-publiclink_configvars.md
diff --git a/modules/developer/pages/services/storage-publiclink/index.adoc b/modules/developer/pages/services/storage-publiclink/index.adoc
new file mode 100644
index 00000000..68d0cae5
--- /dev/null
+++ b/modules/developer/pages/services/storage-publiclink/index.adoc
@@ -0,0 +1,52 @@
+= storage-publiclink
+:toc: right
+:toclevels: 3
+
+
+
+== Abstract
+
+
+
+== Table of Contents
+
+* <>
+* <>
+
+== Brute Force Protection
+
+The brute force protection will prevent access to public links if wrong
+passwords are entered. The implementation is very similar to a rate limiter,
+but taking into account only wrong password attempts.
+
+This feature is enabled by default with predefined settings.
+
+If you want to disable this feature, set the related configuration values to 0.
+
+By default, you're allowed a maximum of 5 failed attempts in 1 hour:
+
+* `STORAGE_PUBLICLINK_BRUTEFORCE_MAXATTEMPTS=5`
+* `STORAGE_PUBLICLINK_BRUTEFORCE_TIMEGAP=1h`
+
+You can adjust those values to your liking in order to define the failure rate
+threshold (5 failures per hour, by default).
+
+If the failure rate threshold is exceeded, the public link will be blocked
+until such rate goes below the threshold. This means that it will remain
+blocked for an undefined time: a couple of seconds in the best case, or up
+to `STORAGE_PUBLICLINK_BRUTEFORCE_TIMEGAP` in the worst case.
+
+If the public link is blocked by the brute force protection, it will be blocked
+for all the users. Any attempt with a false password will restart the trigger.
+
+Note that this feature uses the configurable store. No setting changes need to
+be made when using defaults.
+== Example Yaml Config
+// AUTO-GENERATED CONTENT: services/_includes/storage-publiclink-config-example.yaml
+[source,yaml]
+----
+// Include from: services/_includes/storage-publiclink-config-example.yaml
+----
+
+// AUTO-GENERATED CONTENT: services/_includes/storage-publiclink_configvars.md
+
diff --git a/modules/developer/pages/services/storage-shares/configuration.adoc b/modules/developer/pages/services/storage-shares/configuration.adoc
new file mode 100644
index 00000000..5f3c1317
--- /dev/null
+++ b/modules/developer/pages/services/storage-shares/configuration.adoc
@@ -0,0 +1,13 @@
+= Service Configuration
+:toc: right
+:toclevels: 3
+
+== Example YAML Config
+
+// AUTO-GENERATED CONTENT: services/_includes/storage-shares-config-example.yaml
+[source,yaml]
+----
+// Include from: services/_includes/storage-shares-config-example.yaml
+----
+
+// AUTO-GENERATED CONTENT: services/_includes/storage-shares_configvars.md
diff --git a/modules/developer/pages/services/storage-shares/index.adoc b/modules/developer/pages/services/storage-shares/index.adoc
new file mode 100644
index 00000000..9400f04d
--- /dev/null
+++ b/modules/developer/pages/services/storage-shares/index.adoc
@@ -0,0 +1,9 @@
+= Storage-Shares
+:toc: right
+:toclevels: 3
+
+== Abstract
+
+
+== Table of Contents
+
diff --git a/modules/developer/pages/services/storage-system/configuration.adoc b/modules/developer/pages/services/storage-system/configuration.adoc
new file mode 100644
index 00000000..5bc28f0f
--- /dev/null
+++ b/modules/developer/pages/services/storage-system/configuration.adoc
@@ -0,0 +1,13 @@
+= Service Configuration
+:toc: right
+:toclevels: 3
+
+== Example YAML Config
+
+// AUTO-GENERATED CONTENT: services/_includes/storage-system-config-example.yaml
+[source,yaml]
+----
+// Include from: services/_includes/storage-system-config-example.yaml
+----
+
+// AUTO-GENERATED CONTENT: services/_includes/storage-system_configvars.md
diff --git a/modules/developer/pages/services/storage-users/configuration.adoc b/modules/developer/pages/services/storage-users/configuration.adoc
new file mode 100644
index 00000000..73816226
--- /dev/null
+++ b/modules/developer/pages/services/storage-users/configuration.adoc
@@ -0,0 +1,13 @@
+= Service Configuration
+:toc: right
+:toclevels: 3
+
+== Example YAML Config
+
+// AUTO-GENERATED CONTENT: services/_includes/storage-users-config-example.yaml
+[source,yaml]
+----
+// Include from: services/_includes/storage-users-config-example.yaml
+----
+
+// AUTO-GENERATED CONTENT: services/_includes/storage-users_configvars.md
diff --git a/modules/developer/pages/services/thumbnails/configuration.adoc b/modules/developer/pages/services/thumbnails/configuration.adoc
new file mode 100644
index 00000000..d0b298bc
--- /dev/null
+++ b/modules/developer/pages/services/thumbnails/configuration.adoc
@@ -0,0 +1,13 @@
+= Service Configuration
+:toc: right
+:toclevels: 3
+
+== Example YAML Config
+
+// AUTO-GENERATED CONTENT: services/_includes/thumbnails-config-example.yaml
+[source,yaml]
+----
+// Include from: services/_includes/thumbnails-config-example.yaml
+----
+
+// AUTO-GENERATED CONTENT: services/_includes/thumbnails_configvars.md
\ No newline at end of file
diff --git a/modules/developer/pages/services/userlog/configuration.adoc b/modules/developer/pages/services/userlog/configuration.adoc
new file mode 100644
index 00000000..5557b8a5
--- /dev/null
+++ b/modules/developer/pages/services/userlog/configuration.adoc
@@ -0,0 +1,13 @@
+= Service Configuration
+:toc: right
+:toclevels: 3
+
+== Example YAML Config
+
+// AUTO-GENERATED CONTENT: services/_includes/userlog-config-example.yaml
+[source,yaml]
+----
+// Include from: services/_includes/userlog-config-example.yaml
+----
+
+// AUTO-GENERATED CONTENT: services/_includes/userlog_configvars.md
diff --git a/modules/developer/pages/services/users/configuration.adoc b/modules/developer/pages/services/users/configuration.adoc
new file mode 100644
index 00000000..92ca65fb
--- /dev/null
+++ b/modules/developer/pages/services/users/configuration.adoc
@@ -0,0 +1,13 @@
+= Service Configuration
+:toc: right
+:toclevels: 3
+
+== Example YAML Config
+
+// AUTO-GENERATED CONTENT: services/_includes/users-config-example.yaml
+[source,yaml]
+----
+// Include from: services/_includes/users-config-example.yaml
+----
+
+// AUTO-GENERATED CONTENT: services/_includes/users_configvars.md
diff --git a/modules/developer/pages/services/users/index.adoc b/modules/developer/pages/services/users/index.adoc
new file mode 100644
index 00000000..12e5065b
--- /dev/null
+++ b/modules/developer/pages/services/users/index.adoc
@@ -0,0 +1,9 @@
+= Users
+:toc: right
+:toclevels: 3
+
+== Abstract
+
+
+== Table of Contents
+
diff --git a/modules/developer/pages/services/web/configuration.adoc b/modules/developer/pages/services/web/configuration.adoc
new file mode 100644
index 00000000..6fd15a4e
--- /dev/null
+++ b/modules/developer/pages/services/web/configuration.adoc
@@ -0,0 +1,13 @@
+= Service Configuration
+:toc: right
+:toclevels: 3
+
+== Example YAML Config
+
+// AUTO-GENERATED CONTENT: services/_includes/web-config-example.yaml
+[source,yaml]
+----
+// Include from: services/_includes/web-config-example.yaml
+----
+
+// AUTO-GENERATED CONTENT: services/_includes/web_configvars.md
\ No newline at end of file
diff --git a/modules/developer/pages/services/web/releasing.adoc b/modules/developer/pages/services/web/releasing.adoc
new file mode 100644
index 00000000..d40c5944
--- /dev/null
+++ b/modules/developer/pages/services/web/releasing.adoc
@@ -0,0 +1,32 @@
+= Releasing
+:toc: right
+:toclevels: 3
+
+
+== Releasing
+
+The next generation Web Frontend is shipped as an oCIS Extension. The `ocis-web` extension is also embedded in the single binary and part of the `ocis server` command.
+
+To update this package within all the deliveries, we need to update the package in the following chain from the bottom to the top.
+
+=== Package Hierarchy
+
+- link:https://github.com/owncloud/ocis[ocis]
+ - link:https://github.com/owncloud/ocis/tree/master/web[ocis-web]
+ - link:https://github.com/owncloud/ocis/tree/master/ocis-pkg[ocis-pkg]
+ - link:https://github.com/owncloud/web[ownCloud Web]
+
+==== Prerequisites
+
+Before updating the assets, make sure that link:https://github.com/owncloud/web[ownCloud Web] has been released first
+and take note of its release tag name.
+
+==== Updating ocis-web
+
+1. Create a branch `update-web-$version` in the link:https://github.com/owncloud/ocis[ocis repository]
+2. Change into web package folder via `cd web`
+3. Inside `web/`, update the `Makefile` so that the WEB_ASSETS_VERSION variable references the currently released version of https://github.com/owncloud/web
+4. Move to the changelog (`cd ../changelog/`) and add a changelog file to the `unreleased/` folder (You can copy an old web release changelog item as a template)
+5. Move to the repo root (`cd ..`)and update the WEB_COMMITID in the `/.drone.env` file to the commit id from the released version (unless the existing commit id is already newer)
+6. _Optional:_ Test the changes locally by running `cd ocis && go run cmd/ocis/main.go server`, visiting link:https://localhost:9200[https://localhost:9200] and confirming everything renders correctly
+7. Commit your changes, push them and link:https://github.com/owncloud/ocis/pulls[create a PR]
diff --git a/modules/developer/pages/services/webdav/configuration.adoc b/modules/developer/pages/services/webdav/configuration.adoc
new file mode 100644
index 00000000..4718840b
--- /dev/null
+++ b/modules/developer/pages/services/webdav/configuration.adoc
@@ -0,0 +1,13 @@
+= Service Configuration
+:toc: right
+:toclevels: 3
+
+== Example YAML Config
+
+// AUTO-GENERATED CONTENT: services/_includes/webdav-config-example.yaml
+[source,yaml]
+----
+// Include from: services/_includes/webdav-config-example.yaml
+----
+
+// AUTO-GENERATED CONTENT: services/_includes/webdav_configvars.md
\ No newline at end of file
diff --git a/modules/developer/pages/services/webfinger/configuration.adoc b/modules/developer/pages/services/webfinger/configuration.adoc
new file mode 100644
index 00000000..77cabb8e
--- /dev/null
+++ b/modules/developer/pages/services/webfinger/configuration.adoc
@@ -0,0 +1,13 @@
+= Service Configuration
+:toc: right
+:toclevels: 3
+
+== Example YAML Config
+
+// AUTO-GENERATED CONTENT: services/_includes/webfinger-config-example.yaml
+[source,yaml]
+----
+// Include from: services/_includes/webfinger-config-example.yaml
+----
+
+// AUTO-GENERATED CONTENT: services/_includes/webfinger_configvars.md
diff --git a/modules/developer/partials/nav.adoc b/modules/developer/partials/nav.adoc
new file mode 100644
index 00000000..fb63924e
--- /dev/null
+++ b/modules/developer/partials/nav.adoc
@@ -0,0 +1,191 @@
+* xref:index.adoc[Developer Documentation]
+* xref:ocis/index.adoc[oCIS]
+** xref:ocis/development/index.adoc[Development]
+*** xref:ocis/development/getting-started.adoc[Getting Started]
+*** xref:ocis/development/build.adoc[Building]
+*** xref:ocis/development/testing.adoc[Testing]
+*** xref:ocis/development/debugging.adoc[Debugging]
+*** xref:ocis/development/profiling.adoc[Profiling]
+*** xref:ocis/development/tracing.adoc[Tracing]
+*** xref:ocis/development/extensions.adoc[Extensions]
+*** xref:ocis/development/envvars.adoc[Environment Variables]
+*** xref:ocis/development/continuous-integration.adoc[Continuous Integration]
+*** xref:ocis/development/beta-testplan.adoc[Beta Test Plan]
+*** Unit Testing
+**** xref:ocis/development/unit-testing/index.adoc[Overview]
+**** xref:ocis/development/unit-testing/testing-ginkgo.adoc[Ginkgo]
+**** xref:ocis/development/unit-testing/testing-pkg.adoc[Testing Package]
+** xref:ocis/adr/index.adoc[Architecture Decision Records]
+*** xref:ocis/adr/0001-introduce-accounts-service.adoc[0001 Accounts Service]
+*** xref:ocis/adr/0002-persist-accounts-using-cs3-storage.adoc[0002 CS3 Account Persistence]
+*** xref:ocis/adr/0003-external-user-management.adoc[0003 External User Management]
+*** xref:ocis/adr/0004-support-hot-migration.adoc[0004 Hot Migration]
+*** xref:ocis/adr/0005-cs3-api-account-management.adoc[0005 CS3 API Account Management]
+*** xref:ocis/adr/0006-service-discovery.adoc[0006 Service Discovery]
+*** xref:ocis/adr/0007-api-for-spaces.adoc[0007 API for Spaces]
+*** xref:ocis/adr/0008-configuration.adoc[0008 Configuration]
+*** xref:ocis/adr/0009-extension-template.adoc[0009 Extension Template]
+*** xref:ocis/adr/0010-policy-enforcement.adoc[0010 Policy Enforcement]
+*** xref:ocis/adr/0011-global-url-format.adoc[0011 Global URL Format]
+*** xref:ocis/adr/0012-tracing.adoc[0012 Tracing]
+*** xref:ocis/adr/0013-locking.adoc[0013 Locking]
+*** xref:ocis/adr/0014-microservices-runtime.adoc[0014 Microservices Runtime]
+*** xref:ocis/adr/0015-events.adoc[0015 Events]
+*** xref:ocis/adr/0016-files-metadata.adoc[0016 Files Metadata]
+*** xref:ocis/adr/0017-allow-read-only-external-user-management.adoc[0017 Read-Only External User Management]
+*** xref:ocis/adr/0018-file-search-api.adoc[0018 File Search API]
+*** xref:ocis/adr/0019-file-search-index.adoc[0019 File Search Index]
+*** xref:ocis/adr/0020-file-search-query-language.adoc[0020 File Search Query Language]
+*** xref:ocis/adr/0021-service-accounts.adoc[0021 Service Accounts]
+*** xref:ocis/adr/0022-sharing-and-space-management-api.adoc[0022 Sharing and Space Management API]
+*** xref:ocis/adr/0023-index-and-store-metadata.adoc[0023 Index and Store Metadata]
+*** xref:ocis/adr/0024-msgpack-metadata.adoc[0024 Msgpack Metadata]
+*** xref:ocis/adr/0025-distributed-search-index.adoc[0025 Distributed Search Index]
+*** xref:ocis/adr/0026-application-based-user-settings.adoc[0026 Application-Based User Settings]
+*** xref:ocis/adr/0027-new-share-jail.adoc[0027 New Share Jail]
+*** xref:ocis/adr/0028-activities-service.adoc[0028 Activities Service]
+** xref:ocis/flow-docs/index.adoc[Flow Documentation]
+*** xref:ocis/flow-docs/login-flow.adoc[Login Flow]
+*** xref:ocis/flow-docs/public-upload-flow.adoc[Public Upload Flow]
+*** xref:ocis/flow-docs/request-flow.adoc[Request Flow]
+** xref:ocis/storage/index.adoc[Storage]
+*** xref:ocis/storage/terminology.adoc[Terminology]
+*** xref:ocis/storage/spaces.adoc[Spaces]
+*** xref:ocis/storage/users.adoc[Users]
+*** xref:ocis/storage/namespaces.adoc[Namespaces]
+*** xref:ocis/storage/storagedrivers.adoc[Storage Drivers]
+*** xref:ocis/storage/spacesprovider.adoc[Spaces Provider]
+*** xref:ocis/storage/spacesregistry.adoc[Spaces Registry]
+*** xref:ocis/storage/proposedchanges.adoc[Proposed Changes]
+*** xref:ocis/storage-backends/index.adoc[Storage Backends]
+**** xref:ocis/storage-backends/cephfs.adoc[CephFS]
+**** xref:ocis/storage-backends/dcfsnfs.adoc[DCFS NFS]
+**** xref:ocis/storage-backends/eos.adoc[EOS]
+** xref:ocis/guides/index.adoc[Guides]
+*** xref:ocis/guides/ocis-mini-eval.adoc[Mini Evaluation]
+*** xref:ocis/guides/ocis-local-docker.adoc[Local Docker Setup]
+*** xref:ocis/guides/ocis-and-containers.adoc[Containers]
+*** xref:ocis/guides/migrate-data-rclone.adoc[Migrate Data with rclone]
+*** xref:ocis/guides/ai_assisted_dev.adoc[AI-Assisted Development]
+** xref:ocis/identity-provider/index.adoc[Identity Provider]
+*** xref:ocis/identity-provider/oidc.adoc[OIDC]
+*** xref:ocis/identity-provider/ldap-active-directory.adoc[LDAP / Active Directory]
+** xref:ocis/deployment/index.adoc[Deployment (Developer)]
+*** xref:ocis/deployment/ocis_hello.adoc[Hello World]
+*** xref:ocis/deployment/ocis_full.adoc[Full Setup]
+*** xref:ocis/deployment/ocis_ldap.adoc[With LDAP]
+*** xref:ocis/deployment/ocis_keycloak.adoc[With Keycloak]
+*** xref:ocis/deployment/oc10_ocis_parallel.adoc[OC10 Parallel]
+*** xref:ocis/deployment/kubernetes.adoc[Kubernetes]
+*** xref:ocis/deployment/systemd.adoc[Systemd]
+*** xref:ocis/deployment/continuous_deployment.adoc[Continuous Deployment]
+*** xref:ocis/deployment/basic-remote-setup.adoc[Basic Remote Setup]
+*** xref:ocis/deployment/bridge.adoc[Bridge]
+*** xref:ocis/deployment/preparing_server.adoc[Preparing the Server]
+*** xref:ocis/deployment/monitoring-tracing.adoc[Monitoring and Tracing]
+*** xref:ocis/deployment/ubernauten.adoc[Ubernauten Example]
+** xref:ocis/releasing_guide/index.adoc[Releasing Guide]
+*** xref:ocis/releasing_guide/releasing_guide.adoc[Process]
+*** xref:ocis/releasing_guide/troubleshooting.adoc[Troubleshooting]
+** xref:ocis/config.adoc[Configuration]
+** xref:ocis/metrics.adoc[Metrics]
+** xref:ocis/migration.adoc[Migration]
+** xref:ocis/backup.adoc[Backup]
+** xref:ocis/build-docs.adoc[Building the Docs]
+** xref:ocis/release_notes.adoc[Release Notes]
+** xref:ocis/release_roadmap.adoc[Release Roadmap]
+** xref:ocis/license.adoc[License]
+** xref:ocis/storage_registry_discovery.adoc[Storage Registry Discovery]
+** xref:ocis/getting-started/index.adoc[Getting Started]
+*** xref:ocis/getting-started/demo-users.adoc[Demo Users]
+* xref:architecture/index.adoc[Architecture]
+** xref:architecture/upload-processing.adoc[Upload Processing]
+** xref:architecture/efficient-stat-polling.adoc[Efficient Stat Polling]
+** xref:architecture/protocol-changes.adoc[Protocol Changes]
+** xref:architecture/posixfs-storage-driver.adoc[PosixFS Storage Driver]
+** xref:architecture/collaborative-storage.adoc[Collaborative Storage]
+** xref:architecture/services-communication.adoc[Services Communication]
+* xref:apis/index.adoc[APIs]
+** xref:apis/grpc_apis/index.adoc[gRPC APIs]
+** xref:apis/http/index.adoc[HTTP APIs]
+*** xref:apis/http/authorization.adoc[Authorization]
+*** xref:apis/http/tus_upload.adoc[TUS Upload]
+*** xref:apis/http/graph/index.adoc[Graph API]
+**** xref:apis/http/graph/users.adoc[Users]
+**** xref:apis/http/graph/groups.adoc[Groups]
+**** xref:apis/http/graph/permissions.adoc[Permissions]
+**** xref:apis/http/graph/role.adoc[Roles]
+**** xref:apis/http/graph/spaces.adoc[Spaces]
+*** xref:apis/http/webdav/index.adoc[WebDAV API]
+* xref:cli-commands/index.adoc[CLI Commands]
+** xref:cli-commands/create-new-cli-command.adoc[Create a New CLI Command]
+** xref:cli-commands/document-cli-commands.adoc[Document CLI Commands]
+** xref:cli-commands/service_dependent_cli.adoc[Service-Dependent CLI]
+** xref:cli-commands/service_independent_cli.adoc[Service-Independent CLI]
+* xref:clients/index.adoc[Clients]
+** xref:clients/rclone/index.adoc[rclone]
+*** xref:clients/rclone/webdav-sync-basic-auth.adoc[WebDAV Sync — Basic Auth]
+*** xref:clients/rclone/webdav-sync-oidc.adoc[WebDAV Sync — OIDC]
+* xref:services/index.adoc[Services]
+** xref:services/general-info/index.adoc[General Information]
+*** xref:services/general-info/new-service-checklist.adoc[New Service Checklist]
+*** xref:services/general-info/port-ranges.adoc[Port Ranges]
+*** xref:services/general-info/registry.adoc[Registry]
+*** xref:services/general-info/additional-information.adoc[Additional Information]
+*** xref:services/general-info/add-translations.adoc[Adding Translations]
+*** Environment Variables
+**** xref:services/general-info/envvars/index.adoc[Overview]
+**** xref:services/general-info/envvars/envvar-naming-scopes.adoc[Naming and Scopes]
+**** xref:services/general-info/envvars/special-envvars.adoc[Special Env Vars]
+**** xref:services/general-info/envvars/deprecating-variables.adoc[Deprecating Variables]
+**** xref:services/general-info/envvars/new-release-process.adoc[Release Process]
+**** xref:services/general-info/envvars/env-var-deltas/index.adoc[Version Deltas]
+** xref:services/antivirus/configuration.adoc[Antivirus]
+** xref:services/app-provider/index.adoc[App Provider]
+** xref:services/app-registry/configuration.adoc[App Registry]
+** xref:services/audit/configuration.adoc[Audit]
+** xref:services/auth-basic/configuration.adoc[Auth Basic]
+** xref:services/auth-bearer/configuration.adoc[Auth Bearer]
+** xref:services/auth-machine/configuration.adoc[Auth Machine]
+** xref:services/eventhistory/configuration.adoc[Event History]
+** xref:services/frontend/configuration.adoc[Frontend]
+** xref:services/gateway/configuration.adoc[Gateway]
+** xref:services/graph/configuration.adoc[Graph]
+*** xref:services/graph/unified-roles.adoc[Unified Roles]
+** xref:services/groups/index.adoc[Groups]
+** xref:services/idm/configuration.adoc[IDM]
+*** xref:services/idm/admin_password_reset.adoc[Admin Password Reset]
+*** xref:services/idm/configuration_hints.adoc[Configuration Hints]
+** xref:services/idp/configuration.adoc[IDP]
+*** xref:services/idp/theming.adoc[Theming]
+** xref:services/invitations/configuration.adoc[Invitations]
+** xref:services/nats/configuration.adoc[NATS]
+** xref:services/notifications/configuration.adoc[Notifications]
+** xref:services/ocdav/configuration.adoc[OCDAV]
+** xref:services/ocm/configuration.adoc[OCM]
+*** xref:services/ocm/invitation_flow.adoc[Invitation Flow]
+*** xref:services/ocm/create_share_flow.adoc[Create Share Flow]
+** xref:services/ocs/configuration.adoc[OCS]
+** xref:services/policies/configuration.adoc[Policies]
+** xref:services/postprocessing/configuration.adoc[Postprocessing]
+** xref:services/proxy/configuration.adoc[Proxy]
+** xref:services/search/configuration.adoc[Search]
+** xref:services/settings/configuration.adoc[Settings]
+*** xref:services/settings/bundles.adoc[Bundles]
+*** xref:services/settings/values.adoc[Values]
+*** xref:services/settings/glossary.adoc[Glossary]
+** xref:services/sharing/index.adoc[Sharing]
+** xref:services/sse/configuration.adoc[SSE]
+** xref:services/storage-publiclink/index.adoc[Storage Public Link]
+** xref:services/storage-shares/index.adoc[Storage Shares]
+** xref:services/storage-system/configuration.adoc[Storage System]
+** xref:services/storage-users/configuration.adoc[Storage Users]
+** xref:services/thumbnails/configuration.adoc[Thumbnails]
+** xref:services/userlog/configuration.adoc[Userlog]
+** xref:services/users/index.adoc[Users]
+** xref:services/web/configuration.adoc[Web]
+*** xref:services/web/releasing.adoc[Releasing]
+** xref:services/webdav/configuration.adoc[WebDAV]
+** xref:services/webfinger/configuration.adoc[Webfinger]
+* xref:service-independent/index.adoc[Service-Independent Config]
+** xref:service-independent/service_independent_envvars.adoc[Environment Variables]