Vala Write.as API client

Hey there,

I started work on a Vala Write.as Client. I think all that’s left is some Collections API bindings. I understand there’s a CLI that the official Write.as Desktop app uses, but I’m hoping a Vala Client will make it easier for people to distribute apps through various package managers and back-end build systems.

Just as a quick question, for most users, Publishing Directly to a Collection would be the ideal default option in an app?

From the API, it sounds like if I want a drafts/online sync, I could publish anonymously or just post to no Collection. Then, when I want it on a blog, I can Move a Post to a Collection?

First, this is great @kmwallio — thanks for working on it.

Yes, I’d say publishing to a collection would be the ideal default option.

This is a sound option, but part of me wonders if there’s a way to store the post locally along with some metadata like which collection it should be published to. Then, when the online sync occurs, the post can be officially published (or moved) to the collection.

That might be a little more tricky to manage though — especially if you have to authenticate and then see whether that collection a user wants to publish to is connected to that user. Perhaps having the online/sync default to anonymous posts will make things easier. Would love to get your take on that though!

Yup, I’m planning on having YAML front-matter on the local disk.

Thanks for the tips. I’m still playing with the UI/interface to figure out how much I can integrate with Write.as. From the looks of it, I might just focus on getting a list of collections to publish to, and just allowing for post new and update existing.

Not a problem! That’s probably the best place to start with — you can always iterate upon it.

Is there any immediate use case you’re using for the Vala client? I can definitely see this being great for a Linux-based Markdown editor.

I actually have it in a github branch right now, and I teased this image on twitter.

I’m still trying to figure out how to reliably and securely store credentials/secrets with libsecret, but right now it has a clear disclosure that secrets will be stored in plain text until that’s sorted. Then I’ll work on finishing up the remaining parts of the API and cleaning up some of the JSON parsing code.

Edit: Not sure if I should create another topic to ask this, but the developers page doesn’t have guidance on branding/phrasing on using/referring to Write.as or Write Freely. Currently I’m stealing images from the github repo :scream_cat: . Should there always be a . in the Write.as, and it looks like the logos/branding are the same for both, so is it fine to use the logo for both and refer to them differently?

ThiefMD looks awesome! I’ll have to give it a shot on my Linux VM. Would also be more than happy to test out the Write.as connection when that get’s pushed.

No worries! We have a brand guide that could help here @kmwallio. It definitely could be in a more accessible place for developers and include more to help with branding/phrasing. The page does include official images along with an answer to one of your questions:

Written Write.as (with the dot). Pronounced “ write as ” (without the dot).

Thanks! I guess I’m getting to the point where I might need to reach on on e-mail for approval / any desired copy writing assistance (not copyright, but making sure I don’t bring shame on the Write.as name?). Would hello@write.as be appropriate for that sort of guidance?

This is the documentation I currently have drafted. If it’s always writefreelyinstallation.site/api, I can remove the need to provide /api in the login prompt. If there’s an ask for sign-up links or things like that, let me know, or let me know if I should reach out over to e-mail to continue the conversation instead.

A post was split to a new topic: WriteFreely Branding

I split off answers about branding into a new topic: WriteFreely Branding – feel free to continue that discussion there!

That’s correct, the /api/ path will always be there, so you can simply ask for the host (e.g. writefreelyinstallation.site).

No need to add sign-up links unless you think it’d make the experience better for users. In that case, we’d recommend simply sending people to Write.as or the WriteFreely instances page, where they can find a community to join.