MaxGabriel

Looks like population is up roughly 10% in that time period https://www.neilsberg.com/insights/oakland-ca-population-by-...

Any chance the first result was an ad? Those are definitely a popular phishing distribution mechanism, so getting your parents an adblocker could help

We have a similar check in our Haskell codebase, after running into two issues:

1. Nested database transactions could exhaust the transaction pool and deadlock 2. Same as you described with doing eg HTTP during transactions

We now have a compile time guarantee that no IO can be done outside of whitelisted things, like logging or getting the current time. It’s worked great! Definitely a good amount of work though.

One thing to add about performance: it's also pretty easy in Postgres to index only non-soft deleted data.

I think this is likely unnecessary for most use cases and is mostly a RAM saving measure, but could help in some cases.

This might stem from the domain I work in (banking), but I have the opposite take. Soft delete pros to me:

* It's obvious from the schema: If there's a `deleted_at` column, I know how to query the table correctly (vs thinking rows aren't DELETEd, or knowing where to look in another table)

* One way to do things: Analytics queries, admin pages, it all can look at the same set of data, vs having separate handling for historical data.

* DELETEs are likely fairly rare by volume for many use cases

* I haven't found soft-deleted rows to be a big performance issue. Intuitively this should be true, since queries should be O log(N)

* Undoing is really easy, because all the relationships stay in place, vs data already being moved elsewhere (In practice, I haven't found much need for this kind of undo).

In most cases, I've really enjoyed going even further and making rows fully immutable, using a new row to handle updates. This makes it really easy to reference historical data.

If I was doing the logging approach described in the article, I'd use database triggers that keep a copy of every INSERT/UPDATE/DELETEd row in a duplicate table. This way it all stays in the same database—easy to query and replicate elsewhere.

I’m the author of this post and a co-founder of Mercury. Let me know if you have any questions!

You’re correct that Mercury uses Haskell for its backend: https://serokell.io/blog/haskell-in-production-mercury

> AFAICT, Mercury only allows a single security key.

We allow multiple security keys. You can add more here: https://app.mercury.com/settings/security

> 6-10 digit numeric or alphanumeric code that could be copied out of the email message into a form field on the signin screen.

To be clear this is what we're trying to avoid. An easily typeable code like that can be typed into a phisher's website.

Oh good find, the link going through Mailgun as a redirect is a recent regression. We have a PR to fix that going live soon.

That said, our security team and I agree there is no security issue here. Mailgun already can see the text of the emails we send.

I’m the CTO of Mercury

You shouldn’t get the device verification requirement if you’ve used the device before (we store a permanent cookie to check this) or for the same IP. Any chance your cookies are being cleared regularly?

We added this after attackers created clones of http://mercury.com and took out Google ads for it. When customers entered their password and TOTP on the phishing site, the phisher would use their credentials to login and create virtual cards and buy crypto/gold/etc. The phisher would also redirect the user to the real Mercury and hope they figured it was a blip.

This device verification link we send authorizes the IP/device you open it on, which has almost entirely defeated the phishers.

Since WebAuthn is immune to this style of phishing attack, we don’t require device verification if you use it. I highly recommend using TouchID/FaceID or your device’s flavor of WebAuthn if you can—it’s more convenient and more secure. You can add it here: https://app.mercury.com/settings/security

That said, we are talking internally about your post and we do recognize that as IPv6 gets more traction IPs will rotate much more regularly, so we’ll think if we should loosen restrictions on being a same-IP match.

I think database schema docs are really valuable, so much so that I added tests that require docs for each table and column. But I still got asks that the docs needed more information, mostly from data science people (who otherwise need to go bug engineers, or end up writing bugs in their own SQL). So I wrote internal guidelines for documenting database tables, and eventually that became this blog post

Lemme know if you have any questions!

> Kener is a Open-Source

Should this be “an” in the page header?

100% open rate on transactional emails feels too high to me. Something like an e-commerce purchase might kick off multiple emails (purchase made, shipped, arrived), none of which the user opens

I’m the author of this post and a co-founder of Mercury. AMA!

It’s pretty common to use ad network mediators, which try multiple ad networks for an ad, to optimize for using high earning ones first, and falling back to others in case the first network didn’t have an ad to show.

(I helped make such a product 7 years ago)

Just as one data point, Mercury has hired maybe ~120 Haskell engineers in the last 4 years. Some of that is reflected in these job posts but we definitely hired a lot more than we posted on the subreddit.

If anyone from GitHub is reading, any idea if the double commit bug the merge queue had has been fixed?

https://github.com/orgs/community/discussions/36568

(This was an issue for us during the beta)

It’s also a huge vector for actual phishing, especially because google ads doesn’t use puny code, so it’s easy to buy ads for sites that differ by just a diacritic

Does anyone else get an infinite redirect loop visiting on mobile safari?

Edit: it’s fixed by requesting the desktop website.

"other banks" was a bit ambiguous, here's the list of banks for our partner Evolve: https://www.getevolved.com/openbanking/fdic-mercury/

You as the customer are the owner of record on the funds. The accounts are held by our partner banks at these other banks, as your agent and custodian (something like "Evolve Bank and Trust for benefit of Acme Corp).

The FDIC insurance applies to the business holding the funds; it is definitely not insuring Mercury itself.

You do need to use Mercury to withdraw the funds; we still run all the authorization and compliance rules around this, and there isn't a facility for you to go into eg United Texas Bank and ask for your money. That said, if Mercury were to go bankrupt tomorrow, your funds are held by our partner banks who have full KYC/KYB info on you would be able to access all your funds.

Hey, thanks Martin.

1. As others have said in the comments, I wouldn't assume all funds are 100% insured. It is trending that way but I think if you are a CFO managing 10s of millions, its responsible to consider other assets.

2. Our interest rates on Treasury are pretty competitive, up to 4.67% for the slightly-less-conservative fund MULSX (various conditions apply, depends on how much you hold in treasury, etc; see https://mercury.com/treasury for details).

We are OK not having the absolute highest interest rate offering. Our position is:

* The Mercury product is much better than what most banks offer, across features like searching transactions, WebAuthn logins, virtual cards, etc (You can try the whole website at https://demo.mercury.com/)

* Mercury is much better optimized for startups (eg compliance that understands startup needs, doesn't ask your CEO to go into a branch to send wires)

You can always get a higher interest rate by eg buying treasuries yourself. Our position is for most founders, investing in these mutual funds is a safe, no-brainer options that optimizes for safety while keeping the convenience of a single dashboard.

Hey all, I'm the CTO/a co-founder at Mercury. Here's background on this and where we are now:

- We currently work with two partner banks, Evolve Bank and Trust and Choice Financial

- Both our partner banks operate or are part of a sweep network (https://mercury.com/blog/company-news/understanding-bank-swe...), where they can move funds into other banks. Each bank your money is in increases FDIC coverage by 250K.

- For customers on our partner bank Evolve, this was bumped from 1mm to 3mm as of this morning. You get this automatically if you have accepted the T&Cs for the sweep program already; if you haven't you can do so at: https://mercury.com/settings/vault

- For customers on our partner bank Choice, you're still at 1mm FDIC insurance. We are working on getting you an Evolve savings account (or getting increased coverage from Choice) by tomorrow morning, or you can keep excess funds in Treasury (see below)

# treasury

- We also have a product called Mercury Treasury. This allows you to invest in mutual funds, the safest of which is a Vanguard Treasury Money Market fund (VUSXX), which invests primarily in short-term U.S. Treasury bills https://investor.vanguard.com/investment-products/mutual-fun...

- These securities are held in your name at Apex Clearing, which is https://www.apexclearing.com/

- They're not part of any fractional reserve system like with banks; every share of a mutual fund you hold is in your name and Apex can't lend against it (unless you give them permission which would be weird)

- You can automatically sweep any funds between our treasury product and your savings account. Liquidity is about 3 to 4 days.

- All treasury funds are visible on your Mercury dashboard, so you don't have to manually manage fund movements or keep track of your total balance across websites

- You also earn interest on these

AMA if you'd like, though caveat I'm jumping between a lot of Slack messages right now

Founders Fund hasn’t invested in Mercury

List of investors here:

https://mercury.com/about

Another benefit, queues can enforce ordering, and limit concurrency.

This can be helpful for avoiding resource contention, or hitting an API limit.