34`vt` is also fast! Operations all happen concurrently whenever possible. Watch 62 files get cloned in 0.17 seconds!
35
36`vt` is still in beta, and we'd love your feedback! Join [the Val Town Discord](https://discord.gg/hd9U4GGB) to leave feedback. Vt is built entirely within Val Town "userspace" (with the public API), and the codebase can be found at <https://github.com/val-town/vt> .
37
38## Try it out!
48
49
50Respond yes to the prompt, and ensure you select to create an API key with user read & project read+write permissions.
51
52Then try cloning one of your projects with `vt clone`!
72
73
74One of the very first sight of Val Town "localdev" came with Pomdtr's [Val Town vscode extension](https://marketplace.visualstudio.com/items?itemName=pomdtr.valtown). The extension was pretty straightforward, it hooked into the Val Town API to let you edit your vals locally and then push them to Val Town. It was made pre-project era, so it only supports traditional Vals. VSCode runs on electron, and gives extension developers a lot of power; the extension also offered web previews, and the ability to use Val Town SQL and blobstore.
75
76A bit later, I came along and implemented a fuse file system for Val Town vals, also pre-project era. Fuse is a Linux protocol that lets you implement arbitrary file systems in userspace. By implementing a fuse Val Town file system, all edits locally are instantly reflected on the Val Town website, and vice versa (if you update remotely, then if you try to save locally your editor will say something along the lines of "more recent edits found, are you sure you want to write"). Fuse is very powerful -- writes, reads, and all other file system syscalls can be handled with whatever response you want.
90We decided to rewrite it mostly for compatibility reasons. Linux offers native fuse support, but MacOS and Windows definitely do not. For Mac, there's a project called [MacFuse](https://macfuse.github.io/) that acts as a kernel extension to provide fuse support to Mac. However, it's not totally stable, and [Apple is deprecating kernel extensions](https://developer.apple.com/support/kernel-extensions/) and it may not be the best long term solution. There's a really cool project called [fuse-t](https://www.fuse-t.org/) that takes a different approach, where it implements the fuse protocol by forwarding fuse to NFS (network file system), a protocol that Macs do naively support.
91
92One idea we had to avoid dealing with fuse was to build a generic FTP server, largely inspired by Pomdtr's [Webdav](https://www.val.town/x/pomdtr/webdav/code/webdav.ts) server. His server works totally in userspace and maps the Val Town API to Webdav really nicely. [Webdav](https://en.wikipedia.org/wiki/WebDAV) is a generic "file system" ish (it's quite limited) protocol over HTTP, and making a FTP server would just be implementing on a fancier file transfer protocol that's more capable. What's nice about using protocols like these is that you can then just use `rclone` for mounting or syncing.
93
94In addition to compatibility issues, implementing a fuse backend is just plain complicated. The way `valfs` worked, on [every write syscall](https://github.com/404Wolf/valfs/blob/418eff73b080fe8cdb7fe7f7afd3fe30dbae2720/valfs/vals/valfile.go#L116C1-L153C2), `valfs` would have to parse the file, extract metadata, and do multiple API calls. Even though `vt` is a total rewrite, many design choices for `vt` came from `vtfs`, like considerations on how we handle metadata, the notion that "a val is a file," and more.
95
96At its core, `vt` was built to be a decentralized synchronization tool. Unlike `vtfs`, where the sync is guaranteed and live, syncing happens asynchronously with `vt` (even when "live syncing" with `vt watch`, which is only "psudo-live" since you could create conflicts by updating state on the website while watching). We rebuilt `vt` in typescript with `Deno`, because, well, we (and our community) love typescript and Deno, there's an official [typescript sdk](https://docs.val.town/api/sdk/) for Val Town, and because we have hopes of turning `vt` into a esm library in the future (so you can use `vt` in your own, non-val-town workflows).
97
98We originally wanted to host `vt` itself on Val Town, where we would begin development with git and github, and then eventually transition to using `vt` itself to continue development of `vt` (bootstrapping!).
141One of the most important use cases of `vt` is "watch" functionality. There's a lot of reasons for this. One of the big ones is that, as you (and maybe your favorite LLM) edit your code locally, it is really handy to remove the friction of syncing with Val Town.
142
143From the beginning, my plan for this was to implement "git" behavior first (pushing and pulling), and then just doing file system watching to add live syncing using [Deno.watchFs](https://docs.deno.com/api/deno/~/Deno.watchFs) to handle file system events.
144
145
222I spent a long time working on setting up a pipe where I would handle consecutive writes, writes that start at index i, end at index i+k, and then a new write that starts at index i+k+1, etc, as a special case. Eventually, I got something working!
223
224For `vtfs` I was using [Openapi Generator](https://github.com/OpenAPITools/openapi-generator), and it turned out that Val Town's OpenAPI specification didn't accept file sizes on the order of my tests -- where the response would include the file size, it was an integer, not a `format: int64` (long).
225
226
