Hacker Newsnew | past | comments | ask | show | jobs | submit | GregorStocks's commentslogin

Looks like they do:

> You can also manually install skills by adding them to ~/.claude/skills.


I've always thought that this article overstates the promise of CRDTs with regard to conflict resolution. For toy cases like a TODO list, yes, you can define your operations such that a computer can automatically reconcile conflicts - e.g. you only support "add" and "mark as complete", and if something gets marked as complete twice, that's fine.

But once you get past toy examples, you start wanting to support operations like "edit", and there generally isn't a way to infer the user's intent there. Like, if my cookie recipe starts with 100g of sugar, and I modify it on my phone to use 200g of sugar, and I modify it on my desktop to use 150g of honey instead of 100g of sugar, there are a bunch of ways to reconcile that:

1. Stick with 200g of sugar, drop the 1.5x honey substitution.

2. Stick with 150g of honey, drop the 2x.

3. Merge them - 300g of honey.

4. Merge them - 150g of honey and 50g of sugar.

There's no way for any automated system to infer my intent there. So you've got to either:

1. Ask the user to resolve the conflict. This means you have to build out the whole "resolve this merge conflict for me" UI and the promise of "conflict-free" has not been fulfilled.

2. Arbitrarily choose an option and silently merge. This risks badly surprising the user and losing changes.

3. Arbitrarily choose an option, but expose the fact that you've auto-resolved a conflict and allow the user to manually re-resolve. This requires even more UI work than option 1.

4. Constrain your data model to only allow representing intents that can be deterministically resolved. In practice I think this is too severe of a constraint to allow building anything other than toy apps.

IMO #1 and #3 are the least-bad options, but I don't think they're consistent with the expectations you'd have for CRDTs after reading this article.

(FWIW, https://automerge.org/docs/reference/documents/conflicts/ is the relevant documentation for their Automerge library. It looks like they've chosen option 3.)


Arbitrarily choose an option, but expose the fact that you've auto-resolved a conflict and allow the user to manually re-resolve. This requires even more UI work than option 1.

This is what every "cloud file sharing" provider like Dropbox is doing. If there is a conflict, the version on the server is "the right one", and your locally conflicted file is copied on the side with some annotation in the file name.


Yeah, but Dropbox is sort of playing on easy mode, because the data is "just files" and you can manually resolve the conflict with regular old text editors, etc. If you don't expose your app's data model in the file system (and on a phone you generally wouldn't), that means you need to write something custom to resolve the conflicts.


You might be interested in Tiller Money https://www.tillerhq.com/. They provide something very much along these lines, with the output being an auto-updating Google Sheet that you can do whatever you like with. You do still need to update credentials sometimes, but I've been using it for a few years and it works quite well.


I've never heard of this! I've seen millions of ads over the last few years, why haven't any of them been for this! I will check it out, thank you!


Do note that Tiller and Personal Capital both use(d?) the same mechanism to scrape data: Yodlee

https://www.yodlee.com/


I would assume most of their early customers were not using Plaid exclusively, because they only supported a handful of very big banks. Every company that I've seen select Plaid as a vendor has either done so after considering many alternatives, or used Plaid data alongside data from other providers.


When Plaid originally launched, their value proposition was much higher-quality connections to the top dozen or so most popular institutions in the United States - fewer data quality issues and better integration with MFA than you could get by screen-scraping. Since those banks have about half the bank accounts in the US, that's pretty nice. They later started supporting long-tail banks (the 15,000 or so other institutions in the United States), although without the same data-quality advantage as they have for the big banks.

From the perspective of a new startup, Plaid also has a much more modern API and treats documentation as a much higher priority than most of their competitors - you can get up and running in an afternoon, which is absolutely not the case for every provider in the space.

Plaid also had much better support, at least in the early days - level 1 support was a native English speaker with deep technical knowledge of the product, level 2 support was a founder of the company.


Yodlee had direct data api access to bank databases before Plaid was a sperm in an investors pocket. Its been more than a screen scraper for a long time.


Well, I don't have experience with the quality of Yodlee's data, but I can certainly confirm that around 2014 there were Plaid competitors who had much worse support for big banks than Plaid did. Compared to Yodlee, Plaid might have just been competing on price, developer experience, and support.


Well, if you never put any transactions on the card, it's liable to get closed by the bank without notice - I had that happen with my oldest credit card after a few years of not using it, which hurt my credit score because you want your credit lines to be as old as possible.


Is this powered by Plaid? What's the user experience when you can't pull a full year+ of transactions?


In production, the delay I'd expect is about six hours, but for certain institutions it'll be much higher. Pending transaction support doesn't exist for all institutions, so in the worst case you could swipe your card on a Friday afternoon and not see it in Plaid until the transaction actually clears early Monday morning.


It looks like the credentials in credentials.json are your Plaid access key/secret/etc, not your bank account username/password. If an attacker gets them, they'd have read-only access to your bank account until you rotate your Plaid creds, but they wouldn't be able to do anything as simple as logging into your bank account and transferring all your money out.

EDIT: It's actually worse than that, see comment from erichurkman below.


Careful, because Plaid also gives you access to your account's routing and account numbers [0]. I'm not sure if the way this library works gives access to those, but with a routing & account number a thief _can_ write checks, debit your account, etc.

[0] https://plaid.com/products/auth/


Are routing and account numbers considered “secret”? Potentially any one of the handful of people I still write checks to could be unscrupulous and write checks, debit my account, etc., right?


Correct; that's why Knuth started issuing fake checks instead of real checks for people that found mistakes in his works: https://en.wikipedia.org/wiki/Knuth_reward_check


So he started committing a felony? That doesn't seem like a great idea, interstate bank fraud gets you investigated really quickly.


More background: https://www-cs-faculty.stanford.edu/~knuth/news08.html

Current account 'balances' for people he no longer wrote personal checks to: https://www-cs-faculty.stanford.edu/~knuth/boss.html


I must be missing something but making fake checks, with fake banking information is a felony. What am I missing? The links don't explain how this criminal.


Yes! That’s why I recently had to go through the annoyance of changing checking accounts when someone stole the mail of one of the few vendors I still send checks to. Actually, I would have taken the risk, but my bank would not.


Yeah, good point - I figured Auth wouldn't be enabled on a free developer account, but it looks like it actually is these days: https://plaid.com/pricing.


Thanks for the clarification, that's a little better.

Still...

EDIT: See the other response to this comment by erichurkman, this is still a potential vector for unauthorized payments, transfers, and withdrawals.


The current global currency is the US dollar. Most countries do not allow you to pay taxes in dollars. Why are Bitcoins different?


The USD is a pretty lousy global currency. You can't exactly use it anywhere in any sort of transaction. I've only ever heard of a handful of places outside of the States where the local currency is terrible enough that local people prefer to hold and transact in USD over long periods of time. A true global currency would be one that you could use to buy practically anything, anywhere, whether it was a very large or very small transaction.

Regardless, Bitcoin has several advantages. For one thing, you're not dependent upon continually obtaining a flow of paper notes from a foreign country that may lie halfway around the world. For another, you can divide Bitcoin to extremely small and precise quantities - the dollar on the other hand doesn't scale as well to economies where a penny may start to approach a significant individual unit of money.

There are of course many other advantages of Bitcoin that make it attractive for people in many different countries to adopt. The fact that you can transmit and receive it to and from anywhere in the world, with the same certainty of transaction confirmation as cash in hand, without the need to either physically ship cash or rely on a network of physical cash shipment, is a pretty good one, especially as the world grows ever smaller.

A final advantage would be that you are never hostage to the political dangers of a nation-state controlled currency (i.e. a small group of rich white men can at any point decide to devalue your savings, to the point of destruction, by printing an unlimited amount of the currency.)


Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: