Tidy up use of first person in docs. Since I don't run the only server, referring to "me" in the docs was ambiguous and probably reads oddly to the other server owners.

static/apidocs/openapi.yml

@@ -7,9 +7,9 @@ info:
 
     You can find out more information about Spothole at https://spothole.app/help, and specifically about creating a client to this API at https://spothole.app/help/usage/clients.
     
-    While I provide this API for free, there are some conditions of use that you must adhere to. These are not onerous, but ensure the API can remain available to everyone. These apply even if you are getting an AI to write your client software for you. See https://spothole.app/help/usage/clients#terms for details.
+    The main Spothole server at `spothole.app` provides this API for free, subject to some conditions of use that you must adhere to. These are not onerous, but ensure the API can remain available to everyone. These apply even if you are getting an AI to write your client software for you. See https://spothole.app/help/usage/clients#terms for details. Owners of other Spothole servers may adopt the same conditions or set their own, so if you are using a different server, check with its owner.
     
-    If you want to submit spots from your client, an API key is required. Please contact the server owner for a key if you want to use this functionality.
+    If you want to submit spots from your client, some Spothole servers require an API key. API keys are issued by the owner of each Spothole server, not by the Spothole developer, so contact the owner of the server you want to use.
     
     ## Changelog
 
@@ -34,14 +34,14 @@ info:
     
     If your client submits spots via POST `/spot` and uses upstream submission, replace `submit_upstream` and `upstream_provider` in the `handling` object with an `upstream_providers` list, and turn `upstream_credentials` into a map where the key is the provider name, and the value is another map of credential name to value.
 
-    Some Spothole servers, including `spothole.app`, require a CAPTCHA to submit spots via the web interface, which third-party clients can't solve. If you want your client to submit spots to such a server, ask the server operator for an API key, and send it in the `X-API-Key` request header with each add spot request.
+    Some Spothole servers, including `spothole.app`, require a CAPTCHA to submit spots via the web interface, which third-party clients can't solve. If you want your client to submit spots to such a server, ask the server owner for an API key, and send it in the `X-API-Key` request header with each add spot request.
     
     You are encouraged to move to the `v3` API endpoints as soon as possible. To upgrade, replace `v2` with `v3` in the URLs your code calls, then rename any use of the fields, query parameters and values listed above, and handle `activities` being a list rather than a single `sig` value. If you use the activity reference lookup, call `/lookup/activityref?activity=...&id=...` instead of `/lookup/sigref?sig=...&id=...`.
 
     ### 2.2
     
     * Renamed AMSAT SIG to "Satellite" as AMSAT is a specific organisation not just a general term for satellite QSOs
-    * Removed `alert_type` from alert data. Contest, DXpedition and Satellite alerts now give those values in `sig` instead, alongside the existing outdoor activity programmes. Teeeeechnically a breaking change but AlertType is so new I doubt anyone is using it yet, so slipped this one in anyway. Sorry :)
+    * Removed `alert_type` from alert data. Contest, DXpedition and Satellite alerts now give those values in `sig` instead, alongside the existing outdoor activity programmes. Teeeeechnically a breaking change but AlertType is so new that it's unlikely anyone is using it yet, so this one slipped in anyway. Sorry :)
     * Added QRP, RaDAR Rally, /AM and /MM activities
     * Added `has_refs` and `alerts_possible` to Activity data
     * Added `dx_grid`, `dx_latitude` and `dx_longitude` to alert data
@@ -74,7 +74,7 @@ info:
     
     #### Upgrading a client from v1 to v2 API endpoints
     
-    In v2.0 of Spothole, the `v1` API endpoints will be maintained for backwards compatibility, so I don't break everyone's
+    In v2.0 of Spothole, the `v1` API endpoints will be maintained for backwards compatibility, so as not to break everyone's
     clients on day one. So if you have written a client against the `v1` API, you shouldn't notice anything breaking.
     However, you are strongly encouraged to move to `v2` API endpoints as soon as possible.
     
@@ -88,9 +88,9 @@ info:
     top-level `handling` object which in later versions will allow you to control sending spots upstream to cluster and
     xOTA sites.
     
-    I don't think anyone was sending me QRZ/HamQTH credentials from their clients, or querying the `/options` call, so
-    updating clients for changes there should be confined to Spothole's own web interface. If you were doing that and
-    I haven't noticed, please carefully note the breaking changes listed above.
+    It's unlikely that any third-party clients were sending QRZ/HamQTH credentials to Spothole, or querying the
+    `/options` call, so updating clients for changes there should be confined to Spothole's own web interface. If you
+    were doing that, please carefully note the breaking changes listed above.
     
     ### 1.5
     
@@ -121,6 +121,7 @@ info:
     * Removed band colour and icon information from spots.
     * Moved activation_score from top-level in Spot and Alert to be part of the SIGRef
   contact:
+    name: Ian Renton, M0TRT (Spothole developer)
     email: ian@ianrenton.com
   license:
     name: The Unlicense
@@ -128,7 +129,10 @@ info:
   version: 3.0
 
 servers:
+  - url: /api/v3
+    description: This Spothole server
   - url: https://spothole.app/api/v3
+    description: The main Spothole server
 
 tags:
   - name: Spots
@@ -547,7 +551,7 @@ components:
       name: X-API-Key
       in: header
       description: >
-        An API key issued by the server operator. On servers that protect spot submission, a valid API key allows
+        An API key issued by the server owner. On servers that protect spot submission, a valid API key allows
         the spot to be submitted without a CAPTCHA token. Not required on servers that don't protect spot submission.
       schema:
         type: string