space join fails with "get data from IPFS: could not find" against the production Anytype Network (v0.3.6 / anytype-heart v0.50.10)

Description

anytype space join <invite-link> consistently fails when joining a space hosted on the production (non-self-hosted) Anytype Network. Every attempt over two days has failed with the same IPFS/IPLD "could not find" error while viewing the invite, using a freshly generated invite link each time.

Environment

• anytype-cli: v0.3.6 (latest release; bundles anytype-heart v0.50.10)
• OS: Debian 13, unprivileged LXC container (Proxmox), runs headless as a systemd user service (anytype service)
• Network: production Anytype Network, not self-hosted. ~/.config/anytype/data/<acc>/nodeconf/*.yml is fully populated with the production any-sync nodes (prod-any-sync-node1..15.anyclub.org, prod-any-sync-filenode1..3.anyclub.org, prod-any-sync-coordinator{1,2,3}.anytype.io, consensus/naming/pp nodes), networkId: N83gJpVd9MuNRZAuJLZ7LiMntTThhPc6DtzWWVjb1M3PouVU
• Account: created via anytype auth create; anytype auth status reports logged in with an active session

Steps to reproduce

1. anytype auth create jarvis-bot — succeeds
2. anytype service install && anytype service start — succeeds
   (one unrelated snag first: the systemd user session needs /run/user/0; resolved with loginctl enable-linger root)
3. From Anytype Desktop (macOS, current version): space → Members → invite link, role Viewer, auto-approval enabled
4. anytype space join "anytype://invite/?cid=...&key=..."

Expected behavior

Bot account joins the space (or at least a join request is submitted).

Actual behavior

✗ Failed to view invite: space invite view error: get invite from store: get data from IPFS: ipld: could not find <cid>, get invite

It fails at the invite-view stage, before any join request is sent. Link parsing itself succeeds — the CID and key are extracted correctly, and passing --invite-cid / --invite-key explicitly behaves identically.

Troubleshooting already done

• Regenerated the invite link many times over two days — same error every time, different CIDs. Most recent attempt (today): invite CID bafybeifopi7b66xbi44xhzmt4foahaozh4vhtlkevm2ftbknauarwnulua, auto-approval enabled → same error.
• Enabled "auto approval" on the link.
• anytype service restart.
• Confirmed outbound connectivity from the container: TCP 443 to prod-any-sync-filenode1.anyclub.org, prod-any-sync-coordinator1.anytype.io and api.anytype.io all succeed; curl https://api.anytype.io returns HTTP 302.
• Confirmed the account is logged in and active (anytype auth status).
• anytype space list works and returns the bot's own space — so the client is talking to the network fine for other operations; only invite view fails.

Relevant service logs

A 502 from the file-sync backend during a space-info fetch (seen once, timing correlates with a join attempt):

{"level":"ERROR","logger":"filesync","msg":"update space usage in background","error":"get space info: unexpected error: unexpected error, code: 502; code: 502"}

A service crash + systemd auto-restart (unclear if related):

anytype.service: Main process exited, code=exited, status=2/INVALIDARGUMENT

Also present in logs (possibly expected, unclear if relevant):

{"level":"ERROR","logger":"deviceService","msg":"failed to apply device state: apply on empty tree disallowed"}
globalName was not found for our own identity in Naming Service

Question

Is anytype space join against the production Anytype Network fully supported in v0.3.6? All documentation and community resources (SELF-HOSTED.md, the any-sync-dockercompose wiki) target self-hosted deployments.

If it is supported, "could not find CID" on invite view suggests either the invite object is not propagated to / readable from the production filenodes for CLI-created accounts, or the CLI's invite-view path resolves the CID differently than Desktop does. Happy to provide more logs or run diagnostics.

Start by reproducing anytype space join with a production invite and inspect the invite-view stage that reports get data from IPFS: ipld: could not find. Compare the CLI behavior with the documented production and self-hosted setup, using the supplied service logs and network checks. Done means identifying whether production joining is supported and resolving or clearly documenting the cause of the missing invite CID.