Ben Johnson

@adoublef There's some docs on [determining the primary node](https://fly.io/docs/litefs/primary/) and you could also [track the primary via the event stream](https://fly.io/docs/litefs/events/). Your replica will need to do some kind of RPC...

@ralferoo If you're using Consul leases then you can already muck around with the database state by destroying Consul data from a compromised node. We'll also be adding write forwarding...

@ralferoo That's a fair point. I'll keep this issue open. Someone else suggested primary-initiated replication (https://github.com/superfly/litefs/issues/24) where the primary would make the HTTP request to connect to the replicas and...

Yeah, I think something like [GitHub Actions expressions](https://docs.github.com/en/actions/learn-github-actions/expressions) is a good idea. I'll need to actually do a real mini-parser though instead of the regex hack that I currently have...

I think the issue you might be referring to is Write Forwarding (https://github.com/superfly/litefs/issues/56), however, that has a lot of latency when you try to do it from distant regions. LiteFS...

> > that has a lot of latency when you try to do it from distant regions > That's actually fine for me because I'd just fire-and-forget in this case...

> To be clear, the Sydney cache database would be the one that's locked right? The Denver cache wouldn't be locked right? And just because the database is locked for...

If you’re hitting the “internal” DNS then you should use http instead of https. You’ll also need to use the internal port that your server running on (if it’s not...

I agree the names are not great since the FUSE "mount" and the volume "mount" are different. I don't love `access-dir` either. Also, `volume-dir` won't necessarily always be a volume...

I could see `fuse-dir` or `fuse-mount-dir` or something like that. `database-dir` seems confusing though. 😂