Cordy/Cairn
2
1
Fork 0
Code Issues 20 Pull requests Projects Releases Packages Wiki Activity Actions

Decision: Nextcloud "Trusted servers" compatibility (status.php + federation handshake + directory sync?) #455

New issue
Closed
opened 2026-09-09 20:09:20 +00:00 by Cordy · 5 comments
Cordy commented 2026-09-09 20:09:20 +00:00
Owner
Copy link

Context

Nikola tried adding files-bao to NC's Federation admin → "No server to federate with found". NC 34 probed /.well-known/ocm/status.php → our 401 → NC log: "No Nextcloud server." Question raised: shouldn't Cairn be addable there, like the other players?

What "Trusted servers" actually is (research, 2026-09)

Not OCM. It is NC-family compat with three layers: (1) status.php probe ("is this a Nextcloud-like?"), (2) shared-secret handshake via /ocs/v2.php/apps/federation/…, (3) periodic system address book sync (CardDAV) exchanging the full user list. Its only function is share-dialog autocomplete of remote users; it gates no sharing whatsoever (confirmed in #117 research and by NC docs).

Who can be added today: ownCloud 10 yes (ships status.php, same lineage). OpenCloud/oCIS yes at probe level (ships a status.php compat endpoint). Seafile no — no status.php, cannot be added, and has no equivalent feature of its own.

Options for Cairn

  • Tier 0 — status quo: not addable; direct-address + invite sharing works regardless. Cost: NC admins get a confusing red herring in their UI.
  • Tier 1 — status.php shim only: NC accepts the add, but the entry sits forever unverified (handshake endpoints missing) — a permanently yellow/red row is arguably worse than a clean refusal.
  • Tier 2 — full compat: shim + shared-secret handshake + system address book. Green row, autocomplete works. Privacy cost: exports the complete user directory to every trusted peer — the mini-lookup-server pattern #117 explicitly rejected, and it contradicts our user-owned-contacts model.
  • Tier 3 — middle path (candidate): shim + handshake (green row) + an address book that serves only users who opted in (per-user toggle, default off). NC admins see a first-class citizen; the directory stays sovereign. Differentiator-compatible.

Ask

Decide tier. If >0: mockup for the opt-in surface first, then house TDD build; document in handbook federation-ocm.md ("appearing in Nextcloud's Trusted servers" section) either way — including, for tier 0, an explicit "why not" paragraph.

House rules: karpathy-guidelines, Superpowers brainstorming before any build.

## Context Nikola tried adding files-bao to NC's Federation admin → "No server to federate with found". NC 34 probed `/.well-known/ocm/status.php` → our 401 → NC log: "No Nextcloud server." Question raised: shouldn't Cairn be addable there, like the other players? ## What "Trusted servers" actually is (research, 2026-09) Not OCM. It is NC-family compat with three layers: (1) `status.php` probe ("is this a Nextcloud-like?"), (2) shared-secret handshake via `/ocs/v2.php/apps/federation/…`, (3) periodic **system address book sync** (CardDAV) exchanging the full user list. Its only function is share-dialog **autocomplete** of remote users; it gates no sharing whatsoever (confirmed in #117 research and by NC docs). Who can be added today: **ownCloud 10** yes (ships status.php, same lineage). **OpenCloud/oCIS** yes at probe level (ships a status.php compat endpoint). **Seafile** no — no status.php, cannot be added, and has no equivalent feature of its own. ## Options for Cairn - **Tier 0 — status quo:** not addable; direct-address + invite sharing works regardless. Cost: NC admins get a confusing red herring in their UI. - **Tier 1 — status.php shim only:** NC accepts the add, but the entry sits forever unverified (handshake endpoints missing) — a permanently yellow/red row is arguably worse than a clean refusal. - **Tier 2 — full compat:** shim + shared-secret handshake + system address book. Green row, autocomplete works. **Privacy cost: exports the complete user directory to every trusted peer** — the mini-lookup-server pattern #117 explicitly rejected, and it contradicts our user-owned-contacts model. - **Tier 3 — middle path (candidate):** shim + handshake (green row) + an address book that serves **only users who opted in** (per-user toggle, default off). NC admins see a first-class citizen; the directory stays sovereign. Differentiator-compatible. ## Ask Decide tier. If >0: mockup for the opt-in surface first, then house TDD build; document in handbook federation-ocm.md ("appearing in Nextcloud's Trusted servers" section) either way — including, for tier 0, an explicit "why not" paragraph. House rules: karpathy-guidelines, Superpowers brainstorming before any build.
Cordy commented 2026-09-09 20:26:27 +00:00
Author
Owner
Copy link

Tier-3 steering design (mockup ocm-directory-optin-mockup.html, rev 1, awaiting Nikola):

Four stacked gates, each owned by the right party. (1) Server on the allow-list — admin, exists today. (2) Directory compat enabled — admin, new master toggle in a Directory tab beside Status/Servers in the OCM topic (status endpoint + handshake live only while on; uses the same Apply/Discard bar). (3) Handshake completed — automatic, shown per server as verified/pending with last-sync stamp. (4) User opted in — a "Let trusted servers list me" card at the top of Federated → Contacts, default off for everyone, IdP and local users identical.

Key properties: the admin sees a live tally (e.g. "3 of 14 users opted in") but has no control to list anyone — consent stays with the user, mirroring the #117 user-owned-contacts decision. The user card names exactly what is exposed (display name + federated address, nothing else) and shows gate chips ("directory not enabled" / "2 servers verified" / "you: listed") so a toggle never silently does nothing. Opt-out removes the user from the next sync; opted-out users never appear in any address-book response. Removing a server from the allow-list drops its handshake.

Tier-3 steering design (mockup `ocm-directory-optin-mockup.html`, rev 1, awaiting Nikola): **Four stacked gates, each owned by the right party.** (1) Server on the allow-list — admin, exists today. (2) Directory compat enabled — admin, new master toggle in a **Directory** tab beside Status/Servers in the OCM topic (status endpoint + handshake live only while on; uses the same Apply/Discard bar). (3) Handshake completed — automatic, shown per server as verified/pending with last-sync stamp. (4) **User opted in** — a "Let trusted servers list me" card at the top of Federated → Contacts, default off for everyone, IdP and local users identical. Key properties: the admin sees a live tally (e.g. "3 of 14 users opted in") but has no control to list anyone — consent stays with the user, mirroring the #117 user-owned-contacts decision. The user card names exactly what is exposed (display name + federated address, nothing else) and shows gate chips ("directory not enabled" / "2 servers verified" / "you: listed") so a toggle never silently does nothing. Opt-out removes the user from the next sync; opted-out users never appear in any address-book response. Removing a server from the allow-list drops its handshake.
Cordy commented 2026-09-09 20:54:42 +00:00
Author
Owner
Copy link

Decisions (Nikola, 2026-09-09) — supersedes the rev-1 mockup's steering:

  1. Naming: the toggle title must cover both families. Note: "OCM peers' trusted servers" would mislabel — trusted servers is not OCM, it is Nextcloud/ownCloud-family compat. Working copy: "Appear in Nextcloud & ownCloud trusted-server lists"; final wording at mockup rev 2.
  2. No separate master toggle. Allow-listing a server is trusting it — a second "enable directory" switch is redundant and invites operator confusion. Directory compat (status endpoint + handshake) is active from the moment a legacy-dialect (NC/oC) server is added to the allow-list; removing the server drops its handshake. Pure-OCM peers (OpenCloud invites) are unaffected — no trusted-servers concept there. The Directory tab becomes visibility only: handshake state per server, last sync, entries served.
  3. Listing model: operator + quiet per-user opt-out. Trusting a server lists everyone by default (operator's conscious decision, zero user action, no confusion); a single quiet per-user escape ("don't list me to trusted servers") is honoured at sync time — kept deliberately unobtrusive, placement decided at mockup rev 2. Rationale: matches the NC/oC model UX-wise while strengthening the data-protection position, since the directory discloses every user's name + federated address to third-party servers.
  4. Kept distinct: directory listing ≠ acceptance policy. The per-server "Accept shares from" (invited contacts / any) continues to govern whose shares are accepted; being discoverable never bypasses it.

Build remains gated on: #454 root cause first, then mockup rev 2 → approval → house TDD.

**Decisions (Nikola, 2026-09-09)** — supersedes the rev-1 mockup's steering: 1. **Naming:** the toggle title must cover both families. Note: "OCM peers' trusted servers" would mislabel — trusted servers is not OCM, it is Nextcloud/ownCloud-family compat. Working copy: "Appear in Nextcloud & ownCloud trusted-server lists"; final wording at mockup rev 2. 2. **No separate master toggle.** Allow-listing a server *is* trusting it — a second "enable directory" switch is redundant and invites operator confusion. Directory compat (status endpoint + handshake) is active from the moment a legacy-dialect (NC/oC) server is added to the allow-list; removing the server drops its handshake. Pure-OCM peers (OpenCloud invites) are unaffected — no trusted-servers concept there. The **Directory tab becomes visibility only**: handshake state per server, last sync, entries served. 3. **Listing model: operator + quiet per-user opt-out.** Trusting a server lists everyone by default (operator's conscious decision, zero user action, no confusion); a single quiet per-user escape ("don't list me to trusted servers") is honoured at sync time — kept deliberately unobtrusive, placement decided at mockup rev 2. Rationale: matches the NC/oC model UX-wise while strengthening the data-protection position, since the directory discloses every user's name + federated address to third-party servers. 4. **Kept distinct:** directory listing ≠ acceptance policy. The per-server "Accept shares from" (invited contacts / any) continues to govern whose shares are accepted; being discoverable never bypasses it. Build remains gated on: #454 root cause first, then mockup rev 2 → approval → house TDD.
Cordy commented 2026-09-09 21:20:21 +00:00
Author
Owner
Copy link

Listing model revised (Nikola, 2026-09-09) — supersedes point 3 of the previous decision comment.

Relationship-derived, per-server listing. A user is included in the directory served to trusted server X iff:

  • they have an invited contact on X, or
  • they have sent a federated share to X or accepted one from X (accepted, not merely received — a stranger cannot force-list anyone), or
  • they explicitly enabled "list me on this server" in Federated → Contacts (per-server override; the same place offers "stop listing me" to sever a derived listing).

Default with no relationship: not listed. This is per-(user, server) — technically clean because each trusted server fetches the address book itself, authenticated by its own handshake secret, so we serve each server its own subset.

Recorded properties:

  • Granularity ends at the server wall: once listed to X, all users of X see the entry (NC-side limitation, no design of ours reaches past it). Documented in the handbook.
  • First contact still requires a typed full address (inherent chicken-and-egg); after a user's first exchange with anyone on X, everyone on X can autocomplete them.
  • Confirmed: the surviving admin surface is the allow-list alone (coarse gate), mirroring the Reva/oCIS provider-list + user-owned-contacts architecture — which is what #117 already built. Directory tab stays visibility-only.
  • Unchanged: directory listing ≠ acceptance policy ("Accept shares from" still governs).

Next step when #455 is picked up (after #454 root cause): mockup rev 2 on this model → approval → house TDD build.

**Listing model revised (Nikola, 2026-09-09) — supersedes point 3 of the previous decision comment.** **Relationship-derived, per-server listing.** A user is included in the directory served to trusted server X iff: - they have an invited contact on X, **or** - they have **sent** a federated share to X or **accepted** one from X (accepted, not merely received — a stranger cannot force-list anyone), **or** - they explicitly enabled "list me on this server" in Federated → Contacts (per-server override; the same place offers "stop listing me" to sever a derived listing). Default with no relationship: **not listed**. This is per-(user, server) — technically clean because each trusted server fetches the address book itself, authenticated by its own handshake secret, so we serve each server its own subset. Recorded properties: - Granularity ends at the server wall: once listed to X, all users of X see the entry (NC-side limitation, no design of ours reaches past it). Documented in the handbook. - First contact still requires a typed full address (inherent chicken-and-egg); after a user's first exchange with anyone on X, everyone on X can autocomplete them. - Confirmed: the surviving admin surface is the allow-list alone (coarse gate), mirroring the Reva/oCIS provider-list + user-owned-contacts architecture — which is what #117 already built. Directory tab stays visibility-only. - Unchanged: directory listing ≠ acceptance policy ("Accept shares from" still governs). Next step when #455 is picked up (after #454 root cause): mockup rev 2 on this model → approval → house TDD build.
Cordy closed this issue 2026-09-10 23:25:50 +00:00
Cordy commented 2026-09-10 23:33:34 +00:00
Author
Owner
Copy link

Shipped in v0.6.158, live on both dogfoods — cairn_build_info{version="v0.6.158"} verified, and https://files-bao.c0rdyceps.ch/status.php already answers the probe JSON (active because nextcloud.c0rdyceps.ch sits on the allow-list as a legacy-dialect server).

Built exactly to the locked decisions + approved rev-2 mockups, house TDD (backend red witnessed on the runner; wire formats pinned against the actual Nextcloud federation-app source):

  • Compat surface (internal/ocm/directory.go, mounted on the public mux, active only while a legacy server is allow-listed): status.php, OCS request-shared-secret (allow-list gated; async callback fetches the secret, retrying once with a trailing slash — the classic NC url-hash mismatch), get-shared-secret always 403 (Cairn never initiates), and the CardDAV system address book at remote.php/dav/addressbooks/system/system/system — REPORT sync-collection with per-server sync tokens, 404 tombstones via a cumulative Gone list (an opted-out user is actively deleted from the NC side, not just omitted), per-user vCards carrying CLOUD:user@instance.
  • Relationship-derived per-(user, server) listing exactly as decided: override wins both ways, then contact → sent → accepted; merely received never lists; default not listed; candidates enumerated from our own state only (no IdP enumeration).
  • UI: admin Directory tab (visibility only), Status row "Nextcloud & ownCloud compat", legacy product sub-line, sharpened legacy Remove confirm, and the "Where you appear" card in Federated → Contacts with the derivation always named and one link per row. i18n ×4. One mockup deviation, recorded: the admin tally shows the entries count without "of N users" — under OIDC the instance cannot enumerate its user total honestly.
  • Docs: handbook section incl. the no-trailing-slash note and the server-wall granularity. Audit verb ocm-directory-override.

Dogfood test path (Nikola): on Nextcloud → Settings → Federation, add files-bao.c0rdyceps.ch (no trailing slash). The add should now be accepted; the row goes green after NC's background job completes the handshake (cron — may take a few minutes) and the first address-book sync runs (occ federation:sync-addressbooks forces it). After that, nikola-test should autocomplete in NC's share dialog for Cordyborski — nikola-test is listed to that server by derivation (accepted shares). The Cairn side is visible under Administration → Open Cloud Mesh → Directory and, as a user, Federated → Contacts → Where you appear. Any handshake trouble now logs as trusted-servers … lines in the pod log.

Shipped in **v0.6.158**, live on both dogfoods — `cairn_build_info{version="v0.6.158"}` verified, and `https://files-bao.c0rdyceps.ch/status.php` already answers the probe JSON (active because nextcloud.c0rdyceps.ch sits on the allow-list as a legacy-dialect server). Built exactly to the locked decisions + approved rev-2 mockups, house TDD (backend red witnessed on the runner; wire formats pinned against the actual Nextcloud federation-app source): - **Compat surface** (`internal/ocm/directory.go`, mounted on the public mux, active only while a legacy server is allow-listed): `status.php`, OCS `request-shared-secret` (allow-list gated; async callback fetches the secret, retrying once with a trailing slash — the classic NC url-hash mismatch), `get-shared-secret` always 403 (Cairn never initiates), and the CardDAV system address book at `remote.php/dav/addressbooks/system/system/system` — REPORT sync-collection with per-server sync tokens, 404 tombstones via a cumulative Gone list (an opted-out user is actively deleted from the NC side, not just omitted), per-user vCards carrying `CLOUD:user@instance`. - **Relationship-derived per-(user, server) listing** exactly as decided: override wins both ways, then contact → sent → accepted; merely received never lists; default not listed; candidates enumerated from our own state only (no IdP enumeration). - **UI:** admin Directory tab (visibility only), Status row "Nextcloud & ownCloud compat", legacy product sub-line, sharpened legacy Remove confirm, and the "Where you appear" card in Federated → Contacts with the derivation always named and one link per row. i18n ×4. One mockup deviation, recorded: the admin tally shows the entries count without "of N users" — under OIDC the instance cannot enumerate its user total honestly. - **Docs:** handbook section incl. the no-trailing-slash note and the server-wall granularity. Audit verb `ocm-directory-override`. **Dogfood test path (Nikola):** on Nextcloud → Settings → Federation, add `files-bao.c0rdyceps.ch` (no trailing slash). The add should now be accepted; the row goes green after NC's background job completes the handshake (cron — may take a few minutes) and the first address-book sync runs (`occ federation:sync-addressbooks` forces it). After that, nikola-test should autocomplete in NC's share dialog for Cordyborski — nikola-test is listed to that server by derivation (accepted shares). The Cairn side is visible under Administration → Open Cloud Mesh → Directory and, as a user, Federated → Contacts → Where you appear. Any handshake trouble now logs as `trusted-servers …` lines in the pod log.
Cordy commented 2026-09-11 20:00:22 +00:00
Author
Owner
Copy link

Live end-to-end confirmation (2026-09-11), after v0.6.159–161 follow-ups:

19:59:42 GET  /ocs-provider/ → 401 (NC discovery probe, falls back to defaults)
19:59:42 REPORT /remote.php/dav/addressbooks/system/system/system → 207
19:59:42 GET  /remote.php/dav/addressbooks/system/system/system/nikola-test.vcf → 200

Nextcloud completed the handshake (Cairn Directory tab: verified), ran its address-book sync, and downloaded exactly one vCard — the single user with a derived relationship to that server. Row green on the NC side; nikola-test autocompletes in its share dialog. The sovereign per-(user, server) directory works as designed against a real Nextcloud 34.

Follow-up fixes that made it work, all shipped: v0.6.159 (Directory tab in ADM_TABS, neutral placeholder), v0.6.160 (in-app remove-server dialog), v0.6.161 (handshake callback follows the peer's OCS discovery — NC 34 serves the legacy GET /ocs/v2.php/cloud/shared-secret flavour, not the modern federation path). Operator-side prerequisites found during dogfooding, now in the handbook's troubleshooting picture: the NC instance must have overwrite.cli.url set to its public name (it identifies itself with it in the handshake), and NC only turns the row green after its first address-book sync, which is a slow timed job — occ federation:sync-addressbooks forces it.

**Live end-to-end confirmation (2026-09-11), after v0.6.159–161 follow-ups:** ``` 19:59:42 GET /ocs-provider/ → 401 (NC discovery probe, falls back to defaults) 19:59:42 REPORT /remote.php/dav/addressbooks/system/system/system → 207 19:59:42 GET /remote.php/dav/addressbooks/system/system/system/nikola-test.vcf → 200 ``` Nextcloud completed the handshake (Cairn Directory tab: verified), ran its address-book sync, and downloaded exactly **one** vCard — the single user with a derived relationship to that server. Row green on the NC side; nikola-test autocompletes in its share dialog. The sovereign per-(user, server) directory works as designed against a real Nextcloud 34. Follow-up fixes that made it work, all shipped: v0.6.159 (Directory tab in `ADM_TABS`, neutral placeholder), v0.6.160 (in-app remove-server dialog), v0.6.161 (handshake callback follows the peer's OCS discovery — NC 34 serves the legacy `GET /ocs/v2.php/cloud/shared-secret` flavour, not the modern federation path). Operator-side prerequisites found during dogfooding, now in the handbook's troubleshooting picture: the NC instance must have `overwrite.cli.url` set to its public name (it identifies itself with it in the handshake), and NC only turns the row green after its first address-book sync, which is a slow timed job — `occ federation:sync-addressbooks` forces it.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
fix-escguard
fix-vard
fix-middot
fix-552d
fix-552c
fix-543
scout-tf
v0.6.265
v0.6.264
v0.6.263
v0.6.262
v0.6.261
v0.6.260
v0.6.259
v0.6.258
v0.6.257
v0.6.256
v0.6.255
v0.6.254
v0.6.253
v0.6.252
v0.6.251
v0.6.250
v0.6.249
v0.6.248
v0.6.247
v0.6.246
v0.6.245
v0.6.244
v0.6.243
v0.6.242
v0.6.241
v0.6.240
v0.6.239
v0.6.238
v0.6.237
v0.6.236
v0.6.235
v0.6.234
v0.6.233
v0.6.232
v0.6.231
v0.6.230
v0.6.229
v0.6.228
v0.6.227
v0.6.226
v0.6.225
v0.6.224
v0.6.223
v0.6.222
v0.6.221
v0.6.220
v0.6.219
v0.6.218
v0.6.217
v0.6.216
v0.6.215
v0.6.214
v0.6.213
v0.6.212
v0.6.211
v0.6.210
v0.6.209
v0.6.208
v0.6.207
v0.6.206
v0.6.205
v0.6.204
v0.6.203
v0.6.202
v0.6.201
v0.6.200
v0.6.199
v0.6.198
v0.6.197
v0.6.196
v0.6.195
v0.6.194
v0.6.193
v0.6.192
v0.6.191
v0.6.190
v0.6.189
v0.6.188
v0.6.187
v0.6.186
v0.6.185
v0.6.184
v0.6.183
v0.6.182
v0.6.181
v0.6.180
v0.6.179
v0.6.178
v0.6.177
v0.6.176
v0.6.175
v0.6.174
v0.6.173
v0.6.172
v0.6.171
v0.6.170
v0.6.169
v0.6.168
v0.6.167
v0.6.166
v0.6.165
v0.6.164
v0.6.163
v0.6.162
v0.6.161
v0.6.160
v0.6.159
v0.6.158
v0.6.157
v0.6.156
v0.6.155
v0.6.154
v0.6.153
v0.6.152
v0.6.151
v0.6.150
v0.6.149
v0.6.148
v0.6.147
v0.6.146
v0.6.145
v0.6.144
v0.6.143
v0.6.142
v0.6.141
v0.6.140
v0.6.139
v0.6.138
v0.6.137
v0.6.136
v0.6.135
v0.6.134
v0.6.133
v0.6.132
v0.6.131
v0.6.130
v0.6.129
v0.6.128
v0.6.127
v0.6.126
v0.6.125
v0.6.124
v0.6.123
v0.6.122
v0.6.121
v0.6.120
v0.6.119
v0.6.118
v0.6.117
v0.6.116
v0.6.115
v0.6.114
v0.6.113
v0.6.112
v0.6.111
v0.6.110
v0.6.109
v0.6.108
v0.6.107
v0.6.106
v0.6.105
v0.6.104
v0.6.103
v0.6.102
v0.6.101
v0.6.100
v0.6.99
v0.6.98
v0.6.97
v0.6.96
v0.6.95
v0.6.94
v0.6.93
v0.6.92
v0.6.91
v0.6.90
v0.6.89
v0.6.88
v0.6.87
v0.6.86
v0.6.85
v0.6.84
v0.6.83
v0.6.82
v0.6.81
v0.6.80
v0.6.79
v0.6.78
v0.6.77
v0.6.76
v0.6.75
v0.6.74
v0.6.73
v0.6.72
v0.6.71
v0.6.70
v0.6.69
v0.6.68
v0.6.67
v0.6.66
v0.6.65
v0.6.64
v0.6.63
v0.6.62
v0.6.61
v0.6.60
v0.6.59
v0.6.58
v0.6.57
v0.6.56
v0.6.55
v0.6.54
v0.6.53
v0.6.52
v0.6.51
v0.6.50
v0.6.49
v0.6.48
v0.6.47
v0.6.46
v0.6.45
v0.6.44
v0.6.43
v0.6.42
v0.6.41
v0.6.40
v0.6.39
v0.6.38
v0.6.37
v0.6.36
v0.6.35
v0.6.34
v0.6.33
v0.6.32
v0.6.31
v0.6.30
v0.6.29
v0.6.28
v0.6.25
v0.6.24
v0.6.23
v0.6.22
v0.6.21
v0.6.20
v0.6.19
v0.6.18
v0.6.17
v0.6.16
v0.6.15
v0.6.14
v0.6.12
v0.6.11
v0.6.10
v0.6.9
v0.6.8
v0.6.7
v0.6.6
v0.6.5
v0.6.4
v0.6.3
v0.6.2
v0.6.1
v0.6.0
v0.5.7
v0.5.6
v0.5.5
v0.5.4
v0.5.3
v0.5.2
v0.5.1
v0.5.0
v0.4.12
v0.4.11
v0.4.10
v0.4.9
v0.4.8
v0.4.7
v0.4.6
v0.4.5
v0.4.4
v0.4.3
v0.4.2
v0.4.1
v0.3.30
v0.3.29
v0.3.28
v0.3.27
v0.3.26
v0.3.25
v0.3.24
v0.3.23
v0.3.22
v0.3.21
v0.3.20
v0.3.19
v0.3.18
v0.3.17
v0.3.16
v0.3.15
v0.3.14
v0.3.13
v0.3.12
v0.3.11
v0.3.10
v0.3.9
v0.3.8
v0.3.7
v0.3.6
v0.3.5
v0.3.4
v0.3.3
v0.3.2
v0.3.1
v0.3.0
v0.2.7
v0.2.6
v0.2.5
v0.2.4
v0.2.3
v0.2.2
v0.2.1
v0.2.0
v0.0.3
v0.0.2
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
v0.7 — Closed beta (dogfood + hardening)
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: Cordy/Cairn#455
No description provided.
Delete branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?