removed parent as this should not be a hard requirement but a nice to have feature

sync might be a little ambiguous, especially with our upcoming T584 changes. Maybe something like claim or own instead?

via GH#32

I agree, storing posts.json comes with challenges. But, a few things:

I'd say yes, we should support being authenticated for multiple users on one host. So .writefreely/host/username.ini or .writefreely/host/username/config.ini. As for the location to store posts, see T584#10089.

second iteration for structure and hierarchy

Another question, do we want to have write.as as the default? as above. Or as a host like others, so we would require writefreely CLI users to either specify a host or set a default. I'm leaning towards this myself.

I've been thinking about this one this morning.

This is dependent on backend changes (T637: Support more attributes when creating a collection).

I threw together an offline importer for this: rWFM / https://github.com/writeas/wf-migrate -- for reference in building this into the web application.

any CLI flags provided should override the stored preferences

This task will include the full new directory structure.

I don't think we should store the posts.json and use it for subsequent requests. For example, when would it expire? There may be more posts on the remote or something may have changed.