thanks for chiming in here, @cicko - good points. regarding your questions, @krst: for sync and p2p, the difference in the grpc ports indeed doesn’t matter. these are simply two ports the desktop client can use to connect to anytype-heart.
with that in mind, the cli is fully capable of syncing objects, files, etc. even if the sync nodes in the any network are unavailable, you can still sync via p2p or through your self-hosted nodes. this isn’t specific to the cli, but rather a general capability of anytype’s decentralized architecture.
“Build with it” makes it sound like I have a clue of what I am doing but I am hoping to be able to configure it with N8N for some flows!
Would it be possible to allow to change the listening port to listen for external requests as well?
The “–listen-address” flag doesn’t exist when I try to run it with serve or start service.
Thinking that it could simplify the setup for us with external proxies already in place and it feels like most of the use cases is by accessing it externally. Or what was the reasoning behind only having it accessible by local host?
that’s on oversight on my end, sorry about that. it is available on the auth create and auth login command, but should be on the serve and service install as well. i’ve fixed it in v0.1.2!
Should the anytype update command work for Windows? I have it running as a service but the update returns the following error. I’ve tried it with the service started and stopped, from an elevated command prompt.
c:\Program Files\anytype-cli>anytype update
Checking for updates…
Updating from v0.1.1 to v0.1.2…
Downloading anytype-cli-v0.1.2-windows-amd64.zip…
✗ update failed: Failed to install: failed to replace binary at C:\Program Files\anytype-cli\anytype.exe. To get the latest version, reinstall from repository: GitHub - anyproto/anytype-cli: A command-line interface for interacting with Anytype.
I think I know the answer, but has the support for self-hosted instances been added to this?
UPDATE: I figured it out! The env variable is `ANY_SYNC_NETWORK` and the command is `anytype space join “https://invite.any.coop/{cid}#{key}” --network “NETWORK_ID_HERE”`
Apologies if this is obvious, but if I am in self hosted setup and spin up this headless client, is that a bit redundant? I’m wondering what the use case of the self hosted server would be if I can just have this headless client running and essentially always syncing in “local-only” mode.
the self hosted server can’t expose the API that the headless client can
and on the other hand you can’t sync with the headless client globally
you also can’t have multiple accounts with the headless client
I also have a better feeling with the server as the “master of truth”. if something gets messed up in local only mode just with clients, you can get screwed.
Thanks for making this, I would like to try it out, but I have one question: Can the CLI be used to export my spaces as markdown files? I would like automate exporting to create backups in markdown format.
support for self-hosted networks in the anytype-cli is available with