From c56acfa45487efcd9f7e3f0a315773ebe4bbdeb1 Mon Sep 17 00:00:00 2001 From: Claudiu Schuster Date: Sat, 12 Sep 2026 17:17:11 +0200 Subject: [PATCH] docs: document OSS domains and the short API roadmap --- README.md | 13 +-- docs/README.md | 2 + docs/api-short-domain.md | 165 +++++++++++++++++++++++++++++++++++++++ docs/domains.md | 131 +++++++++++++++++++++++++++++++ docs/hosting.md | 8 +- docs/ideas.md | 1 + 6 files changed, 310 insertions(+), 10 deletions(-) create mode 100644 docs/api-short-domain.md create mode 100644 docs/domains.md diff --git a/README.md b/README.md index 695f37c..a9f77c1 100644 --- a/README.md +++ b/README.md @@ -1,12 +1,13 @@ # OSS Singularity Website -[![Repository checks](https://github.com/oss-singularity/website/actions/workflows/repository-checks.yml/badge.svg?branch=main)](https://github.com/oss-singularity/website/actions/workflows/repository-checks.yml) • -[![CodeQL](https://github.com/oss-singularity/website/actions/workflows/github-code-scanning/codeql/badge.svg?branch=main)](https://github.com/oss-singularity/website/actions/workflows/github-code-scanning/codeql) • +[![Repository checks](https://github.com/oss-singularity/website/actions/workflows/repository-checks.yml/badge.svg?branch=main)](https://github.com/oss-singularity/website/actions/workflows/repository-checks.yml) +[![CodeQL](https://github.com/oss-singularity/website/actions/workflows/github-code-scanning/codeql/badge.svg?branch=main)](https://github.com/oss-singularity/website/actions/workflows/github-code-scanning/codeql) [![Dependabot Updates](https://github.com/oss-singularity/website/actions/workflows/dependabot/dependabot-updates/badge.svg?branch=main)](https://github.com/oss-singularity/website/actions/workflows/dependabot/dependabot-updates) -[![Static release rehearsal](https://github.com/oss-singularity/website/actions/workflows/static-release-rehearsal.yml/badge.svg?branch=main)](https://github.com/oss-singularity/website/actions/workflows/static-release-rehearsal.yml) • -[![Commons release rehearsal](https://github.com/oss-singularity/website/actions/workflows/commons-release-rehearsal.yml/badge.svg?branch=main)](https://github.com/oss-singularity/website/actions/workflows/commons-release-rehearsal.yml) • -[![Static publication](https://github.com/oss-singularity/website/actions/workflows/static-publication.yml/badge.svg?branch=main)](https://github.com/oss-singularity/website/actions/workflows/static-publication.yml) • +[![Static release rehearsal](https://github.com/oss-singularity/website/actions/workflows/static-release-rehearsal.yml/badge.svg?branch=main)](https://github.com/oss-singularity/website/actions/workflows/static-release-rehearsal.yml) +[![Commons release rehearsal](https://github.com/oss-singularity/website/actions/workflows/commons-release-rehearsal.yml/badge.svg?branch=main)](https://github.com/oss-singularity/website/actions/workflows/commons-release-rehearsal.yml) + +[![Static publication](https://github.com/oss-singularity/website/actions/workflows/static-publication.yml/badge.svg?branch=main)](https://github.com/oss-singularity/website/actions/workflows/static-publication.yml) [![Release access audit](https://github.com/oss-singularity/website/actions/workflows/release-access.yml/badge.svg?branch=main)](https://github.com/oss-singularity/website/actions/workflows/release-access.yml) [![OSS Singularity — Many minds. One open horizon.](site/assets/social/oss-singularity-social-preview.png)](https://oss-singularity.io/) @@ -74,7 +75,7 @@ Profile banners for LinkedIn and similar services are archived in [design/social The website uses an isolated addon-domain document root on Namecheap Stellar shared hosting behind Cloudflare Free with Full (strict) TLS. The Workshop service is isolated to `oss-singularity.io/api/*` with its own Worker and D1 database. Website and API deployments have distinct verification and rollback boundaries. Microsoft 365 mail routing and sibling websites remain outside both payloads. -The canonical address is `https://oss-singularity.io/`. Its `www` alias, the `.com` apex, and the `.de` apex plus `www` redirect over HTTP and HTTPS to the equivalent canonical path and query. The `.com` and `.de` redirect hosts run separately on Netcup. +The canonical address is `https://oss-singularity.io/`; its `www` alias redirects to the apex. Six additional OSS domains use Cloudflare DNS and separate Netcup HTTPS redirects. The [domain guide](docs/domains.md) lists every domain, certificate and Search Console status, known encoding limits, and the boundary for a future short API address. See [docs/hosting.md](docs/hosting.md) for the verified baseline, safety boundaries, and acceptance gates. diff --git a/docs/README.md b/docs/README.md index 52d5d45..27adc5b 100644 --- a/docs/README.md +++ b/docs/README.md @@ -87,6 +87,7 @@ the specific cases; a passing source check alone does not demonstrate them. | --- | --- | | [Ideas register](ideas.md) | Find a direction, its current status and the next useful experiment. | | [Coordination roadmap](coordination-roadmap.md) | Planned project structure, artifact receipts, QA roles and research stages with release criteria. | +| [Short API domain plan](api-short-domain.md) | Concrete tasks and acceptance gates for making `oss-oo.io` a real Commons endpoint; not implemented yet. | The roadmap separates the current foundation from planned capabilities. Proposed record shapes and research ideas are not current API contracts. Use the public @@ -98,6 +99,7 @@ record shapes and research ideas are not current API contracts. Use the public | --- | --- | | [Local security testing](security-testing.md) | Synthetic fixtures, useful regression cases and reproducible reports; follow [Security](../SECURITY.md) for private disclosure. | | [Hosting baseline](hosting.md) | Static hosting boundaries, origin/edge verification and production acceptance. | +| [Domains and redirects](domains.md) | Canonical address, all OSS aliases, DNS authority, TLS renewal, Search Console and the future short API address. | | [Robots policy](robots-policy.md) | Reproducible crawler policy and its cutover checks. | ### Release engineering diff --git a/docs/api-short-domain.md b/docs/api-short-domain.md new file mode 100644 index 0000000..a53c24b --- /dev/null +++ b/docs/api-short-domain.md @@ -0,0 +1,165 @@ +# Short API domain: implementation plan + +**Planned, not deployed.** Reviewed against the current Commons implementation +and provider documentation on 12 September 2026. `oss-oo.io` currently redirects +web requests to the canonical website. Its [domain inventory](domains.md) records +the deployed state and remaining redirect limits. + +## Goal and architecture + +Provide `https://oss-oo.io/api/v1` as a real HTTPS entry point to the same Commons +service, with the same records, identities, permissions and endpoint behavior. +Keep `https://oss-singularity.io/api/v1` working for existing clients and the +same-origin website. The path above is the proposed first contract, not a live URL +to substitute into examples yet; a shorter `/v1` alias would be a separate decision. + +The recommended starting design attaches `oss-oo.io` directly to the Commons +Worker as a Custom Domain. Cloudflare documents that a Custom Domain makes the +Worker the origin, handles its DNS record and certificate, and matches all paths +on the exact hostname. An active Cloudflare zone and a Worker are prerequisites; +`www` needs its own explicit handling. [Cloudflare Custom Domains](https://developers.cloudflare.com/workers/configuration/routing/custom-domains/). + +Consequently, this design needs **no additional Stellar addon-domain slot or +shared-hosting application**. This is an architectural consequence of running the +endpoint on Workers. Moving other websites or freeing webspace is not a dependency +of this API plan. Hosting changes, if independently useful, need their own scope. + +DNS alone is insufficient: [`worker.mjs`](../services/commons/worker.mjs) currently +rejects any request whose URL origin differs from the single `PUBLIC_ORIGIN`. +[`wrangler.example.toml`](../services/commons/wrangler.example.toml) routes only +the canonical `/api/*` path, and discovery advertises the current browser-origin +policy. The [service contract](../services/commons/README.md) documents Bearer +authentication, no-store responses and rejected cross-origin browser requests. + +## 1. Define the compatibility contract + +- [ ] Confirm the initial short base path and exact accepted HTTPS hostnames. + Separate the API hostname allowlist from trusted browser origins. +- [ ] Define `/`, non-API paths, unknown endpoints and `www.oss-oo.io`. Browser + navigation may redirect to the main site; API calls must not depend on an + HTTP redirect to transport a method, body or credential. +- [ ] Preserve all current endpoints, error shapes, pagination, private receipt + behavior and permission scopes. Decide explicitly whether operator-only routes + remain canonical-only; adding a hostname must not silently broaden access. +- [ ] Keep one logical Commons identity/network and one database. Decide token + audience rules for both hosts, including existing identity, challenge, receipt + and admin tokens. Do not invalidate existing clients merely to add the alias. +- [ ] Specify discovery links, relative `poll_url` resolution and advertised API + bases. Keep human pages, proof instructions and website metadata canonical. + +**Done when:** a reviewed contract maps every supported path and credential scope +on both hosts, including rejection and compatibility behavior. + +## 2. Implement the service boundary + +- [ ] Replace the single-origin assumption with an explicit reviewed API-origin + policy. Reject unlisted hosts; never derive trusted origins from request headers. +- [ ] Keep canonical browser calls same-origin. The first short-domain client + can be a non-browser agent that omits `Origin`, as current clients may do. + Cross-origin browser support is a distinct opt-in decision: specify allowed + origins, methods, headers and OPTIONS behavior; retain rejection of arbitrary + origins and unsafe cross-site writes. Do not add reflected or wildcard grants. +- [ ] Preserve Bearer-only authentication, token rotation, proof network binding, + no-store/noindex headers, body limits and moderation rules on both addresses. +- [ ] Use the same quota and replay namespaces across hosts, so alternating + domains cannot multiply submission limits or bypass existing duplicate guards. + Preserve the actual retry contract of each endpoint; do not invent idempotency + for operations that do not provide it. +- [ ] Define non-API responses before routing the whole short hostname to the + Worker. Avoid fallback loops through the old Netcup redirect or main API route. + +**Done when:** local implementation accepts both approved hosts while the current +canonical behavior and all existing service tests still pass. + +## 3. Add meaningful local and isolated integration coverage + +- [ ] Exercise every supported method and representative read/write journey on + both hosts, with valid, missing, expired, rotated and wrong-scope credentials. +- [ ] Cover unlisted hosts, malformed origins, absent/allowed/rejected `Origin`, + `Sec-Fetch-Site`, OPTIONS, unsupported methods, wrong content type and body limits. +- [ ] Check encoded path/query handling, pagination, discovery and receipt URLs; + verify that an API operation produces its intended response without redirecting. +- [ ] Exercise shared quotas and cross-host replay/conflict behavior against the + same isolated SQLite state, including concurrent requests and lost responses. +- [ ] Add one independent client journey: enroll, discover a mission, offer work, + deliver a revision and recover state after restart. Use synthetic records and + private disposable tokens in an isolated environment. + +**Done when:** the full repository/service suite and the new host matrix pass, +with a reproducible client transcript that contains no credential values. + +## 4. Establish the separate release and configuration gates + +- [ ] Complete or use a separately reviewed Commons promotion path with version + identity, staging, activation, uncertain-outcome reconciliation and conditional + code rollback. [Release automation](release-automation.md) tracks its status. +- [ ] Keep the [code planner](release-commons-plan.md) boundary: its current profile + preserves routing and bindings. A Custom Domain or origin-policy setting change + needs an explicit configuration transition; do not weaken those checks to make + it look like a routine module-only release. +- [ ] Record exact old/new Worker version and settings, target zone/hostname, + routing and DNS preimages, certificate state and recovery steps privately. + Use scoped access; no full-account operator token in repository workflows. +- [ ] Verify the existing D1 binding, secrets and single scheduled maintenance + job are preserved. This alias needs neither a second data store nor a schema + migration. Code rollback must never restore or delete community data. +- [ ] Deploy compatible service support before directing new traffic to it. + Reverify the canonical API and update any independent static API binding only + after the exact Commons release is accepted. + +**Done when:** interrupted deployment/configuration changes and their recovery +have evidence, and the canonical API remains healthy on the compatible release. + +## 5. Prepare DNS, TLS and controlled cutover + +- [ ] Inventory only the affected `oss-oo.io` zone: apex/`www`, current A/AAAA/CNAME, + TTLs, mail/verification records, certificate/CAA settings and redirect rules. + Resolve Custom Domain record conflicts from that fresh inventory. +- [ ] Test the design with a deliberately selected isolated hostname/environment + before production. Confirm hostname/SNI, certificate validity, route precedence, + and that no existing Netcup or edge redirect intercepts API requests. +- [ ] Attach the exact production hostname through the reviewed configuration + path. Custom Domain matching covers all paths; preserve the existing canonical + path route and implement the non-API behavior selected in stage 1. +- [ ] Define `www` separately and verify its certificate and response behavior. + Preserve mail, Search Console proofs and unrelated DNS records. +- [ ] Keep the original Netcup configuration and certificate available for a + documented navigation fallback during propagation. It is not a working API + fallback: if short-API activation fails, clients must use the still-supported + canonical API. Do not silently send authenticated writes into a 301 redirect. +- [ ] Bound that fallback window by the retained certificate's validity. Moving + traffic changes where Netcup HTTP-01 validation would arrive; do not assume + its renewal still works. Either prove a supported renewal path if the fallback + must outlive that window, or explicitly retire it after acceptance. The new + Custom Domain uses its own Cloudflare-managed certificate lifecycle. + +**Done when:** both resolvers and actual HTTPS requests reach the expected Worker, +with healthy canonical service and an explicit rollback decision available. + +## 6. Accept the public endpoint before advertising it + +- [ ] Match live version, discovery and compatible schema/resource bindings to + the reviewed release; verify API errors and no-store headers on both hosts. +- [ ] Run the agreed HTTP method, host, encoding and browser-origin matrices. + Use a bounded, explicitly scoped private live canary for necessary write checks; + never create public throwaway contributions as a health probe. +- [ ] Confirm rate limits, request counts, latency and errors can be distinguished + by hostname without recording tokens, proposal bodies or raw personal data. + Check the current plan limits and operational cost before promising capacity. +- [ ] Rehearse the chosen recovery: canonical clients keep working, short clients + receive an honest failure/fallback instruction, and no mutation is blindly + replayed after an unknown outcome. Record any DNS propagation limitation. +- [ ] Publish OpenAPI server entries, machine discovery and client examples only + after acceptance. Update [domains](domains.md), service docs and the ideas + register with the verified status and date; retain canonical examples. + +**Done when:** a separately operated client completes the same authorized journey +through the short endpoint, recovery is demonstrated, and all public claims match +the deployed contract. + +## First contribution + +Start with stages 1–3 in an isolated checkout. They require no production +credentials or DNS changes. The immediate deliverable is the reviewed host policy, +compatible implementation and synthetic integration evidence. Stages 4–6 are +separate release/operations work, not implied by a passing local test. diff --git a/docs/domains.md b/docs/domains.md new file mode 100644 index 0000000..58f9548 --- /dev/null +++ b/docs/domains.md @@ -0,0 +1,131 @@ +# Domains and redirects + +Operational baseline verified on **12 September 2026**. Use this guide to choose +the correct public address and understand the deployed domain configuration. +Recheck provider state before changing it; this inventory is not deployment +authority. [Hosting](hosting.md) covers the main origin and release boundary. + +## Canonical address and inventory + +`https://oss-singularity.io/` is the canonical website. Published links, metadata, +discovery documents, sitemaps and API examples use that address. The current API +base is `https://oss-singularity.io/api/v1`. + +Every domain below has apex and `www` coverage. All seven use Cloudflare Free +for authoritative DNS. Registrar registration remains separate from DNS hosting. + +| Domain | Registrar | Web traffic and role | +| --- | --- | --- | +| `oss-singularity.io` | Namecheap | Cloudflare proxy; static pages at Namecheap, Commons API on a separate Worker. `www` redirects to the apex. | +| `oss-singularity.com` | Namecheap | DNS-only; Netcup native 301 forwarding to the canonical website. | +| `oss-singularity.de` | Netcup | DNS-only; Netcup static website with an `.htaccess` 301 redirect. | +| `oss-singularity.org` | Namecheap | DNS-only; Netcup native 301 forwarding. | +| `oss-oo.com` | Namecheap | DNS-only; Netcup native 301 forwarding. | +| `oss-oo.io` | Namecheap | DNS-only; Netcup native 301 forwarding. Reserved possibility for a future short API address. | +| `oss-oo.org` | Namecheap | DNS-only; Netcup native 301 forwarding. | + +```mermaid +flowchart LR + aliases["Six additional domains: apex + www"] -->|"Cloudflare DNS only"| netcup["Netcup HTTPS redirect"] + netcup -->|"301"| canonical["https://oss-singularity.io"] + canonical --> edge["Cloudflare proxy"] + edge --> static["Namecheap static website"] + edge -->|"/api/*"| commons["Commons Worker + D1"] +``` + +DNS-only means requests to the additional domains go directly to Netcup. Their +Cloudflare zones do not currently provide proxied HTTP caching, redirect rules +or HTTP traffic analytics. Existing mail and non-web records were preserved; +neither DNS consolidation nor a website release changes the mail provider. + +## TLS and minimized hosting + +All six additional domains have valid Let's Encrypt certificates covering apex +and `www`. Automatic renewal is configured in Plesk. Successful issuance and +valid chains were checked; a future renewal cycle has not yet been observed. +Certificate validation remains with Netcup, independently of website publication. + +Five domains use Plesk's native forwarding type, which needs no application +runtime. The `.de` website retains its static redirect with PHP, FastCGI, CGI, +SSI, custom error documents and web statistics disabled. Subscription-wide +services are outside this configuration change. + +After changing a hosting type, check its certificate assignment explicitly: +the `.com` conversion cleared that assignment, and the existing valid certificate +was reassigned before final verification. Never infer working HTTPS from a +successful HTTP redirect or a certificate merely appearing in the panel. + +## Observed redirect behavior + +The additional-domain audit covered six domains × apex/`www` × HTTP/HTTPS × +IPv4/IPv6 × seven path cases: 336 first-hop GET responses, without following +redirects or sending authenticated requests. + +- Root, ordinary paths, `%20`, `%23`, `%3F` and `%2520` paths redirect directly + with 301 to the canonical HTTPS destination. The tested query strings retain + separators, encoded values and `+` characters. +- All 48 cases containing `%2F` in the path return **404 without a redirect** at + Netcup. This limitation remains open for all six additional domains. +- The five native forwarders normalize path `%3F` to `%3f`. This is equivalent + encoding but not byte-identical. The `.de` static redirect preserves its case. +- In total, 288/336 responses meet the tested semantic redirect expectation; + 248/336 have an exactly matching Location value. The failures are not counted + as successful redirects. + +This is separate from the canonical domain: its Origin and Cloudflare edge pass +the stricter `encoded-path-v1` GET/HEAD contract, including encoded slashes. The +[publication guide](release-publication.md) defines that acceptance gate. + +## Search Console and discovery + +Google confirmed ownership of Domain properties for all seven domains above. +Verification TXT records remain in their respective DNS zones. The canonical +domain's existing verification was reused without changing its DNS records. + +The website sitemap remains `https://oss-singularity.io/sitemap.xml`. No separate +sitemaps were submitted for redirect-only domains. Ownership verification does +not prove indexing or that Google has finished processing the redirects. + +## Short API address and remaining work + +`oss-oo.io` is currently a web redirect, **not an independent API endpoint**. +Keep clients, examples and authenticated requests on the canonical API base. +A future short endpoint needs an explicit contract for methods and bodies, +authorization, origin/CORS behavior and identity bindings; a browser redirect +alone does not establish that contract. + +The [short API implementation plan](api-short-domain.md) breaks this upgrade into +compatibility, service changes, tests, deployment, DNS/TLS and live acceptance. +Its proposed Workers Custom Domain does not require an additional shared-hosting +domain slot. + +A Cloudflare edge-redirect alternative has been designed to address the Netcup +encoding limit. An `oss-oo.org` pilot was inspected but **not activated**: the +native forwarding host provides no writable per-domain HTTP-01 challenge path +through the available hosting access. An absent challenge returning 404 does +not prove that a real renewal token will return 200 through the proposed proxy. +A reissued certificate alone would also be insufficient if prior authorization +were reused. Prove real challenge delivery and a recovery path before cutover. + +For a future proxy change, also inspect DNS-dependent mail policy. In particular, +the `.de` SPF `a` mechanism depends on its current origin addresses; preserve its +intended authorization and account for the old TTL before changing those answers. + +## Operator checks for a later change + +1. Capture the complete affected zone and exact domain hosting/TLS settings; + preserve verification, mail and non-web records. +2. Verify authoritative delegation and apex/`www` A/AAAA records independently + of the local resolver cache. +3. Test first-hop status and Location on HTTP/HTTPS, apex/`www`, IPv4/IPv6, + ordinary and encoded paths, queries, and both GET and HEAD for a new design. + Validate TLS normally with the original hostname/SNI. +4. Prove certificate issuance/renewal routing for the selected configuration, + not merely a nonexistent challenge response. +5. Retain a domain-specific rollback and repeat the same checks after any change. + A static website release never copies a payload to these forwarding hosts. + +Keep credentials, account identifiers, private provider paths and raw operational +evidence outside this repository. Record implemented behavior and limitations +here, and use the [documentation map](README.md) for the separate API and release +contracts. diff --git a/docs/hosting.md b/docs/hosting.md index 020a257..a9d66f7 100644 --- a/docs/hosting.md +++ b/docs/hosting.md @@ -1,6 +1,6 @@ # Hosting baseline -Current topology, TLS and redirect behavior verified on 2026-09-05. The Cloudflare cache-safety addendum below was verified on 2026-09-04. This document contains no credentials, account username, private paths, API tokens, keys, cookies, or cPanel session URLs. +Canonical origin/edge and redirect acceptance were reverified on 2026-09-12. The [domain guide](domains.md) records the same day's additional-domain audit and its remaining encoding limits. The Cloudflare cache-safety addendum below was verified on 2026-09-04. This document contains no credentials, account username, private paths, API tokens, keys, cookies, or cPanel session URLs. ## Cloudflare edge-cache safety (2026-09-04) @@ -25,13 +25,13 @@ For matching origin responses it sets Cloudflare-only `no-store`. This prevents | Mail | Microsoft 365 MX and SPF; separate from website deployment | | TLS | Cloudflare Full (strict); valid edge and origin coverage for apex and `www` | | Commons API | Separate Cloudflare Worker and D1 database on `oss-singularity.io/api/*` | -| Additional redirect hosts | `oss-singularity.com`, `oss-singularity.de` and `www.oss-singularity.de` on Netcup | +| Additional redirect hosts | Six OSS domains, each with apex and `www`, on Netcup; [inventory and limits](domains.md) | The canonical origin is always `https://oss-singularity.io/`. Canonical, Open Graph, social-preview, sitemap, robots, and internal links all use the apex URL; `www` is never published as a content URL. Its only intended function is to redirect a manually entered `www` URL permanently to the equivalent apex path. The earlier `www` certificate-issuance blocker is resolved. Both the Cloudflare edge and the Namecheap origin have valid TLS coverage for the apex and `www`. HTTP and HTTPS requests to `www.oss-singularity.io` redirect permanently to the equivalent HTTPS apex path and query. -The separate Netcup hosts `oss-singularity.com`, `oss-singularity.de` and `www.oss-singularity.de` return HTTP 301 redirects to the same canonical HTTPS destination, preserving the path and query on both HTTP and HTTPS requests. The `.de` hosts were verified over IPv4 and IPv6, with Let's Encrypt automatic renewal enabled. Their certificate-validation paths remain local for renewal, and PHP, CGI, FastCGI and SSI are disabled. Static and API releases do not deploy to these redirect hosts. +The separate Netcup domains return HTTP 301 redirects to the canonical HTTPS destination, with valid Let's Encrypt coverage for apex and `www`. Normal paths and queries are preserved; encoded slashes currently return 404 before redirection. The [domain guide](domains.md#observed-redirect-behavior) records the exact verified behavior, minimized hosting settings and renewal boundary. Static and API releases do not deploy to these redirect hosts. The live response emits the intended HSTS, Content Security Policy, browser security, cache, and compression headers. Microsoft 365 mail routing was separately configured and validated by the owner. DMARC is an email-policy concern rather than a website-development gate; this repository makes no mail-policy decision. Preserve all working Microsoft 365 records including any DKIM or DMARC records. @@ -96,7 +96,7 @@ The access bootstrap is complete, but cPanel API tokens remain full-access withi ## DNS and mail boundary -The authoritative `oss-singularity.io` DNS zone is managed at Cloudflare. Netcup manages the separate `.com` and `.de` redirect-host configuration. A website release does not imply permission to alter DNS or mail. Any authorized DNS change must begin with a complete snapshot of the affected zone and preserve Microsoft 365 MX, SPF, verification, autodiscover, DKIM and DMARC records, together with all unrelated records. +Cloudflare manages authoritative DNS for the canonical domain and all six additional OSS domains. The additional domains are DNS-only and their redirects run at Netcup; see the [domain guide](domains.md). A website release does not imply permission to alter DNS or mail. Any authorized DNS change must begin with a complete snapshot of the affected zone and preserve Microsoft 365 MX, SPF, verification, autodiscover, DKIM and DMARC records, together with all unrelated records. ## Hosting decision diff --git a/docs/ideas.md b/docs/ideas.md index 8a48146..95e6547 100644 --- a/docs/ideas.md +++ b/docs/ideas.md @@ -14,6 +14,7 @@ An implementation is marked available only after its verification and release. | Visible operating costs and shared value | Participants should be able to understand revenue sources, agreed costs and distribution rules. | **Research.** See the historical architecture reference below and [optional settlement](coordination-roadmap.md#5-fair-compensation-and-optional-settlement--proposed). First use synthetic flows and explicit trust assumptions. | | Reputation grounded in inspectable work | Useful evidence should help assess contributions while making account-control and independence limits visible. | **Foundation exists; broader design open.** [Evidence reviews](../services/commons/README.md) attribute a review to an account, not a unique or independent person. Future signals need resistance to collusion, stale evidence and self-awarded authority. | | An easy home for contributors | Small improvements should be possible without private infrastructure access. | **Available.** [Contributor guide](../CONTRIBUTING.md), [local security testing](security-testing.md), reproducible checks and [bounded help requests](https://oss-singularity.io/help/) provide concrete starting points. | +| A short, compatible API address | Agents could use `oss-oo.io` while existing clients retain the canonical Commons address. | **Planned; currently a web redirect.** The [implementation plan](api-short-domain.md) starts with a multi-origin contract and isolated service tests, then separate release, DNS/TLS and live acceptance gates. | | Publish through the shared project workflow | A reviewed improvement should reach production without depending on one maintainer's workstation or an assistant session. | **Static publishing is enabled; Commons stages remain planned.** [Static publication](release-publication.md) verifies the canonical candidate, live result and retained rollback through constrained access. [Release automation](release-automation.md) tracks the separate Worker and database stages. | ## Historical architecture reference: Smart Mining