there are ways around it.

- use coinjoin with something like wasabi wallet(https://wasabiwallet.io/)

- purchase BTC with cash

All software has bugs. This is same as claiming ETH will always get hacked because of the DAO hack.

As far as I can tell there is no fundamental design flaws in Solana that makes it so that it will always go down. There are bugs in the networking stack that are being fixed.

An no, "engineers" don't bring it up. I run a validator and only i'm incentivized to restart it back up because of my stake.

Eth or Bitcoin have never been down. If this software is especially bad then ..

what is the right demand when stripe should be supporting?

Currently there are 93M wallets holding stablecoins with a weekly transfer of 373B[0].

[0] https://app.rwa.xyz/stablecoins

This is no different from ETH, Lido staking has ~30% market share[0].

Stake centralizing != less security. no amount of stake can allow validators to steal your funds, this affects only censorship resistance. So actual validator count is more important than superminority.

In case of USDC I'm assuming Circle should be running their own validator, which is the source of truth.

As someone who has used most networks, Solana has the best experience for transacting USDC.

[0] https://dune.com/hildobby/eth2-staking

Tried Supabase but currently only use their Auth.

The server to database latency was very high(few hundred ms) whereas Planetscale DB in the same region gives sub 10ms.

Still great option for most projects that can do with these issues.

I struggle to imagine projects that can do with a db latency of several hundred ms? Something fully async maybe, any human interaction would be incredibly slow

And functions often have multiple db calls not just one. The latency would be a deal breaker no?

How far was the server from the Supabase instance?

I have a toy project with a server on Fly.io and the DB on Supabase within the same city

When sending API requests to the server, my end user latency was around 25ms-100ms (depending on the endpoint and how many DB calls it was doing)

Now with Supabase on Fly, that API latency is down to 17ms-70ms. But Supabase on Fly is still in alpha so it's not relevant for production yet

Same region, different provider. Also, their JS API has to do a round trip every time you set auth credentials on the backend, so it's at least 2 round trips for a single query.

same aws region as supabase instance using a single query.

I've been using turso.tech for my current side project project and happy with it so far. iirc, their sqlite is deployed using fly.io too.

pretty cool to include xkcd for the loading screen :)

I've tried doing this read & updates using Postgrest and row-level-security using Supabase. When it works its an amazing experience but even for semi complex stuff you would still need to use Postgres RPC, which is still another "API" layer. I find writing API using SQL a nigtmare.

Simple queries like this don't work on Postgrest: `update likes set likes = likes + 1;`

User-agent: GPTBot Disallow: /

ATMO you shouldn't have to maintain knowledge of what kind of crawler bot exist and having to maintain deny list. It should be the opposite, only expressedly allowed content should be crawled by mainaining allow lists.

You can do the opposite since the inception of robots.txt: User-agent: * Disallow: / and then whitelist google bot and whatnot. Most of the web is already configured this way. Just check robots.txt of any major website, e.g. https://twitter.com/robots.txt

The Allow: directive was an extension to robots.txt added later.

That was my gut reaction too, but presumably unless it becomes regulated, at least some competitors to OpenAI won't respect any robots.txt and thus any open content might be training data.

User-Agent: <new technology category>Bot

Steem has an interesting approach to solve this.

Steemit[1] is the reddit alternative built on Steem[2].

[1] https://steemit.com/ [2] https://steem.com/