That sounds like centralizing
Bluesky migrates to single-tenant SQLite
201–210 of 247 posts
Re: Bluesky migrates to single-tenant SQLite
#202Earlier quoted context omitted.
It's probably not healthy to have broken cryptographic hashes running around. If you don't need a secure hash there are plenty of fast non-cryptographic hashes.
There's nothing about security here. By this logic you should probably stop using hashmaps, then? :)
That's literally not their logic.
They said:
if you need security don't use md5.
If you don't need security, use something faster than md5.
md5 is neither secure nor fast, why use it at all?
Re: Bluesky migrates to single-tenant SQLite
#203Slightly related: is Bluesky moderated good enough or do I get lots of rightwing and conspiracy crap like on twitter currently? I‘d really love to have some more civilized hub again that isn’t full of hate and anti-intellectualism.
It seems a lot nicer than Twitter. Though I'd wonder how much of that is just that it's invite-only right now. I haven't really gotten into it, for a variety of reasons (happy enough with Mastodon for most stuff, no decent client apps, vaguely suspicious of the involvement of Dorsey) but it seems... fine?
Re: Bluesky migrates to single-tenant SQLite
#204Slightly related: is Bluesky moderated good enough or do I get lots of rightwing and conspiracy crap like on twitter currently? I‘d really love to have some more civilized hub again that isn’t full of hate and anti-intellectualism.
Are you assuming that hate and anti-intellectualism are exclusively a rightwing thing?
Not exclusively, but on the mainstream internet in 2023? Yeah, more or less, bar a few tankies.
Re: Bluesky migrates to single-tenant SQLite
#205I am curious, does the HN folks know if bluesky is more active than nostr or the mastodon network?
Bluesky is much smaller than Mastodon, but how active it feels will depend on who you're following. It also has an Algorithm (TM); I never really missed this when I went from Twitter to Mastodon as I mostly used the linear timeline anyway, but I gather that some people find that Mastodon feels empty/inactive without one.
Re: Bluesky migrates to single-tenant SQLite
#206Earlier quoted context omitted.
You're right, as usual. AppView is on a Postgres cluster with read replicas doing timeline generation (and other things) on-demand. We're in the process of moving it toward a beefy ScyllaDB cluster designed around a fanout-on-write system. The v1 backend system was optimized for rapid development and served us well. The v2 backend will be somewhat less flexible (no joins!) but is designed for much higher scale.
Does the BGS pull all the tenant‘s individual SQLite data? Or do the PDS push new posts to the BGS?
The BGS (which is an atproto "relay" service) subscribes to all PDS event streams on the entire network, and aggregates and relays them.
This way it's possible to get all network data from a single place (the BGS) rather than having to connect to every PDS, which is simpler for consumers and dramatically reduces the workload of PDS hosts.
Some details about event streams here, although the APIs are still evolving: https://atproto.com/specs/event-stream
Re: Bluesky migrates to single-tenant SQLite
#207Earlier quoted context omitted.
I wish there were ways to enforce this on the db so you never accidentally grabbed a table lock during these operations. definitely have shot myself in the foot with postgres on this
> I wish there were ways to enforce this on the db so you never accidentally grabbed a table lock during these operations. You can use a linter for PostgreSQL migrations https://squawkhq.com/
And squitch is a wonderful Perl tool for this as well
Re: Bluesky migrates to single-tenant SQLite
#208Is Bluesky still invite only?
It is, but not as a "growth hack" or anything. It's just a way of limiting growth while the system is scaled (in terms of the backend and abuse prevention). There's a dedicated waitlist for developers that will get you access quite quickly: https://atproto.com/blog/call-for-developers
It's pretty hard not to see it as a growth hack given that posts can't even be viewed without an account. That seems pretty transparently to be a system to create a feeling of FOMO/exclusivity, to make it so that you don't only need an account to participate, you need an account to even see what the network is or to follow anyone on it at all.
As a comparison, Cohost limited account setup when it launched as a way to limit growth. But it didn't lock viewing the entire site behind an account requirement because... come on. What does that have to do with scaling, we all know why that restriction is there :)
To be fair, it seems to be working. Needing to seek out and find invite codes means that signups are more visible -- signup codes get shared over social media and that means mentioning Bluesky publicly and keeping it in people's minds. It also forces people to ask publicly about access, which makes the network feel more exclusive and turns every signup or expression of interest into an advertisement for the network. It's a good marketing strategy, and I suspect that a nontrivial portion of Bluesky's current buzz comes from that marketing strategy, so I can understand why it hasn't been abandoned yet. I mean, look at the current thread; if people didn't need to coordinate publicly on HN to get access then this subthread wouldn't exist and then there wouldn't be a public thread where a bunch of people express interest in trying out the network -- and that publicly expressed interest in this very subthread makes Bluesky feel more in-demand.
In fact, this is such an effective marketing strategy that I've seen Bluesky users complain that invite codes are too common now and that their invite codes aren't in as much demand as they used to be. That FOMO loop is so powerful that it's even affecting the people who already have access to the network who enjoyed the feeling of being in control of an artificially scarce resource.
But sure, all of this is definitely not a growth hack, I believe you ;)
Regardless of whether it's good marketing, the account requirements make the platform a lot less relevant in any serious discussions about the direction of social media, because despite its plans for the future for federation and access, what Bluesky is today is a platform that is in practice even more locked down than Twitter is.
Re: Bluesky migrates to single-tenant SQLite
#209Will the BGS also be federated, or is that to be the centralized big spider in Bluesky's web?
The BGS is a "dumb" relay and mirror of the network, so it generally shouldn't matter which one your client app is ultimately sourcing data from.
But yes, anyone is free to operate a BGS. It does necessarily require a non-trivial amount of storage, compute, and bandwidth. A funded startup, well-funded non-profit, or any just about any cloud provider could likely afford to run one.
It's also entirely possible to operate a BGS that only mirrors a slice of the network (for instance, only users in one country) if desired, which could in some cases make it affordable for a single user or small coop to operate.
Re: Bluesky migrates to single-tenant SQLite
#210What do they mean by "Since SQLite does not support concurrent transactions" - it supports them, as long as you don't access the .db file through a file share (UNC, or NFS, etc) - https://www.sqlite.org/wal.html I've been using this to update/read db from multiple threads/processes on the same machine. You can also do snapshotting with the sqlite backup API, if you want consistent view, and to not hold on transaction…
This is the tradeoff of SQLite, it is extremely fast, as long as you only mostly have one user. With WAL you can get multiple readers, but it doesn't scale the same way that e.g. PostgreSQL does