David

I just started working on a project that I forked from Dave, which is a really great project with a good team of contributors. It looks like the project has been archived, so it’s time to fork, and see what new things I can learn with their current implementation. They’ve got a number of library implementations that I haven’t had a lot of exposure to, such as cobra, and viper. They are utilizing some good Go core concepts such as context. I’m also taking a different approach to writing code, with copilot and also bard.

A.I.

The landscape for development with A.I. has improved for when I’m parsing through code that I’ve never seen before. Instead of there being a magic block of code that I don’t understand. I can dump functions into bard, request a code block as a response, ask for detailed comments, and when the original writer of that function doesn’t leave detail comments - no matter how mundane that comment might seem - I can now read code more like a story as opposed to reading the code like it’s a secret message. I’m not dumping on the developers. Sometimes, I’m smooth brain (slang). I need to write Golang because it literlly stops me from writing things that I wont understand later. I’ve written some small Go projects that I can easily wrap my head around later - these are projects that are multiple packages, serve a small purpose, and don’t really do a lot.

Before David

Before I started working on this, I was working on a Go project that would replace minimodem. In short, minimodem is a drop-in software replacement for the Bell202 modem. You can pipe strings into the software modem, and receive AFSK sound which screams out into your headphones into your, now, bleeding eardrums. I’ve been wanting to write a version of minimodem in Go for a long time. However, I also want forward error correction - so Hamming Codes, and Reed-Solomon Code would be some very important topics to cover. Google’s Bard does a pretty good job at covering some of these forward error correction core concepts, but sometimes it takes shortcuts that don’t make sense. Eventually, I’ll be able to approach that project at a later date, but for now - I need something that’s a little more useful in my day to day tasks. I started looking for something that already existed and is already mostly functional for my needs. I stumbled on Dave after I had been using dufs for several months. Dufs had this to say about receiving webdav response headers on Windows #307… and while true… it’s not exactly helpful. Perhaps Microsoft Network Developers will read that at some point.

Missing support

Dufs is great - when running my own server. If you reverse proxy with TLS, you can have a web based front end for dragging and dropping files to your home server. Dufs has basic-auth. Cool! Simple. When I saw that Dave had a config yaml file with bcrypt password, and a simple admin hierarchy, I was ready to ditch dufs for Dave. Launching Dave is simple.

dave --config=config.yaml

nice.

My music library

Yes. I still listen to .mp3’s while everyone else spends $15 a month on music they’ve already paid for 20 years ago. I can easily back up my music library on a $10 usb stick, and I don’t need curated playlists. There’s an issue though. I’m not going to store my music entire library on my phone, and I really don’t want to go back to paying for Spotify (call me old school). I can install a webdav music player on my phone, type in the webdav endpoint, and now I’ve got my own little Spotify, basically for free. However, I’ve got to type in my password to some phone app that I don’t trust. Dave doesn’t have controllable CRUD operations in the config file. It’s got multiple users? cool. CORS? cool. TLS support - if you’re not using letsencrypt? cool. Also, typical “bind address and bind port.” cool cool. It makes a lot of complex things very simple.

Dave vs. David

Since Dave became archived, and I needed a feature without being blocked on the pull request. I forked the project. Currently, I don’t think the fork will go upstream based on the fact that project is archived. When reading some of the issues on Dave, it became a bit more clear that people have different ideas of how simple (or complex) they want their own implementations of Dave. Adding complexity or any CRUD operations means more cycles. It’s just a fact. If a user needs to get checked for authorization before each write operation - Dave isn’t Dave anymore. It’s no longer simple. It gets a tiny bit slower with more features. What if I wanted to log data being sent to the server? - maybe so that I could cap uploads for users? In other words, give each user an upper bound of maybe 100Gb similar to having a custom bucket (or IAM) policy on a per user basis. Now, I would need to implement postgres||badger request? slower. Insert more features. Dave gets a little slower on every request. So that’s where David begins. After refactoring a lot of the original codebase with more detailed comments (and more to come), I’ve learned quite a bit. I’m grateful to the developers that wrote Dave - it’s, seriously, an awesome project. Hopefully, I can find some interesting ways to continue to expand David to a decent extension of its parent project. I’m networking!

Thanks for Reading

Please check out David. If you want to run the most simple cloud server where you can mount your cloud storage to any machine, anywhere. David is the way to go. Be sure to explore making a user with read only permissions, and you can use passwords on apps you don’t necessarily trust - and you can sleep knowing that you wont lose your data due to a database leak on a server you don’t have control over. ❤️