HN user

stpn

504 karma
Posts16
Comments36
View on HN

(post author here)

I was curious about this since it kind of makes sense, but I offer a few reasons why I think this isn't the case:

- In the 10% noise case at least, the second descent eventually finds a minima that's better than the original local minima which suggests to me the model really is finding a better fit rather than just reducing itself to a similar smaller model

- If it were the case, I think we might also expect the error for larger models to converge to the performance of smaller models? But instead they converge lower and better

- I checked the logged gradient histograms I had for a the runs. While I'm still learning how to interpret the results, I didn't see signs of vanishing gradients where dead neurons later in the model prevented earlier layers from learning. Gradients do get smaller over time but that seems expected and we don't have big waves of neurons dying which is what I'd expect to have the larger network converge on the size of the smaller one.

Originally this was a privacy angle - the data is primarily stored on your device, with backend storage that’s treated like backup and sync only. I had plans for e2ee that built on this but it didn’t turn out to be a big differentiating factor.

Working in local-first turns out to be really nice for making the app feel super snappy. The responsiveness you see in the demo is the performance you can expect in day to day usage.

Sort of relatedly, I’ve been fighting Safari bug for years that feels like it has to be related to dates in js.

Safari’s saved credit card support works pretty well, but when I switch between US and Asia timezones the expiration date will shift by a month in one direction. My best guess is that they store the expiration as midnight local time on the 1st of the month in a js Date which can shift when you travel outside of that timezone.

It's sad to hear that the new app encrypts everything.

A long time ago I worked on hacking airplay support for sonos speakers and it wouldn't have been possible without inspecting a lot of plaintext wireshark traffic.

As much as I've have cited, loved, and recommended sourcegraph (even going so far as to help run the open source version at a previous co), I never paid a cent for the product.

I'm curious about the line of thinking in leaving open source behind, but it seems somewhat unsurprising in that lens.

I run a personal finance app that's built as a PWA (https://tender.run, my email is in my profile).

I would say running as a PWA has been a mixed bag. There are quite a few missing features across web platforms (for starters, background sync, full featured push notifications, haptics) that make it hard to be competitive with native apps. Every WWDC, we watch in hopes that Safari gets more PWA features, but it's a thin drip. There's a reason so many apps repackage into electron/cordova/whatever shells.

As other folks in thread have pointed out, it's probably worth thinking through why a product works particularly as a PWA vs alternative distribution methods.

There’s an overview for how our app is built here: https://tender.run/blog/tender-and-crdts

We haven’t written much about our server-side sqlite. I’d say our write workloads are easily within what sqlite can do for now. At one point we looked into doing per-customer databases for scaling write perf (since sharding by customer can be a lot cheaper in sqlite than other dbs), but it’s not necessary yet.

We use the client-side sqlite as part of making the app work locally and offline, so it wouldn’t make sense.

The materialized view isn’t a huge perf problem for now, and I expect we’d switch to using triggers or similar without too much difficulty.

We run sqlite at https://tender.run, both in our backend (as a primary data store, backed by litefs) and on the client (as a index and cache).

In general works really great, esp. in terms of speed. There are some limitations worth knowing though - for instance, figuring out making write throughput reasonable with the combination of wal mode, busy timeout, and begin immediate.

Another that I've had to work around recently is the lack of materialized views - you can make and query from a view, but it's just a select statement that gets shoved into queries that use it. To get the perf of a materialized view, you'd have to do something manual and custom. For the most part, this isn't an issue simply due to how fast sqlite is, but in the browser it's a bit more significant because of how much slower the wasm-compiled sqlite is.

Oh yes, to be clear we’re not collecting any of that data ourselves, but it is in our stripe account. I suppose that data isn’t in _our system_ per se, but the arrangement is still relying on our privacy intentions over any systematic guarantee (“we simply don’t have this data”) we could give.

I really love this sentiment.

Unfortunately, it also seems really hard to build many kinds of applications in a way that follows this line of thinking. I've been building a personal finance app with privacy in mind, but there are some places where you might begrudgingly "hold" a users' data that are just unavoidable. For instance, if we want to be a serious competitor and have bank integrations, then plaid etc. will require you to run a server that can see the data, even if you don't want it.

We also don't collect names in our app, just an email, but good luck collecting payments, avoiding fraud or reporting taxes without collecting name and address.

We've built our system to be as minimally invasive (e.g. in the above, financial data is only proxied to the user's device, never stored on the server), but that's only the "intention" part - there's just not a way to take the full measure.

Hah - I too am a former personal capital (and mint) user.

We've thought about if we want to tackle those features and become an all-encompassing personal finance, but it certainly is a wide feature set to cover for our team. Right now we're focused on polishing our small feature set, though I appreciate the feedback.

I've been running sqlite and litefs in production for my side project over the last year or so now.

It really is quite nice how much database you get for the cost and maintenance overhead required when litefs is thrown in the mix.

I've been working on a local-first personal finance/expense tracker called Tender: https://tender.run

Tender runs as a PWA and uses the Automerge crdt and sqlite via wasm. The app more or less runs entirely in your browser (works offline!), though our server proxies connections to pull in plaid/splitwise data.

Feature-wise, we're targeting folks who do want to manage their expenses but not have to do fine-grained budgeting. There's tools for tracking getting paid back and a splitwise integration as well. The app is desktop-centric right now, but we're working on getting a good mobile workflow together too.

Since everything is browser-based, it was actually quite easy to get a demo sandbox environment working. You can give it a quick spin here: https://demo.tender.run

I am actually currently working on something like this - inbox zero style (don't have swipe gestures built yet) finances tool where you check/set the category. What's old is new I guess.

Is basil still around? Would be interested in taking a look.

I did consider those sorts of systems but decided against.

One facet of that is that I’d like ro support e2e encryption, which feels harder to do in something electricsql and co (since the postgres sees fields for replication). e2e2 seems more obvious in automerge (though, also not supported out of the box), and I recently encountered secsync.com which looks like a new-ish project that could get there.

I’m really excited to see the influx of local-first frameworks though. A lot of these solutions also weren’t nearly as mature when I started working on tender about a year ago. If I were starting now instead of a year prior, I might try to go with github.com/vlcn-io/cr-sqlite which seems to share ideals with my architecture, and automerge has some issues I've run into.