> Your username can be your website. I'm @bradgessler.com.

But more importantly, you have to verify that you own the domain. I can't sign up as google.com

Those arguments are applicable to X as well, though.

1. Your username can be your website. On Bluesky, domain verification (by DNS) maps to a `did:plc` identifier – ˋAppView`s (bsky.app, the Bluesky smartphone app, etc.) only look up to plc.directory, a “database” owned by Bluesky. For your username to REALLY be your domain name, Bluesky would need to support the `did:web` kind of identifiers, which they don’t. In short, your username maps to an internal database, which is what X does too.

2. Bluesky’s basically Twitter before it needed to give money back to investors. I’d bet money that we will be seeing more broken features ten years from now when Bluesky will have to focus on how to give the money back to investors.

(Yes, I am slightly biased towards ActivityPub, even though Bluesky has better architecture.)

This is the reason I initially got on the waitlist to join Bluesky.

11 years ago I made a social media aggregator where users had to have a verified domain to join - think using your domain as username and using you domain to authenticate your social media profiles. My show HN: https://news.ycombinator.com/item?id=6529523

This probably sounds silly but in the end I didn’t actually use Bluesky because they don’t support emoji domains.

It’s going to go the way of Threads and Mastadon. Lukewarm results at best, but glad you are enjoying it.

Very nifty, I like it quite a bit.

I wonder if instead of black+repeating images (assumption here is that's the display and not an artifact of the firehose, the same unique image often repeats a lot in the same short instance) it'd be cleaner to have some sort of exponential backoff queue (the closer it is to empty the slower it empties like 0.5s/numInQueue, last element in queue will wait no less than 0.5s but also wait for the next element to queue). This would make the flow a bit more consistent, never blank, and never repeating.

Also if images kept their aspect ratio.

I like the concept, but it is flashing way too fast. Maybe do a random selection every 1 sec, rather than a straight fire hose ?

Is there any way to make it flash less? I'm not epileptic, and I appreciate that you put a warning first, but it's still highly unpleasant after around 2 seconds. If I could look at it for a bit long it would be a cool experiment.

I've got the perfect soundtrack for it (flashing lights warning) https://www.youtube.com/watch?v=wNtxgxYY7sI&t=66s

> feels like a misty-eyed throwback to 2005.

Feels like let's get people to invest in our platform and once they're locked in make them pay.

Only two outcomes: either everyone can access it or only few big companies can. While not ideal, the former is much better.

Better that everyone have access to the data rather than just a couple large corporations.

TBF, a walk down the street where cctv cameras are present is likely already training data for some AI.

I think researchers want vintage data thats not contaminated with llm vomit

I think that's another issue; there is no viable way to migrate social media data as if it were possible it would be abused mostly.

There are some apps (OpenVibe and Yup) that let you post to multiple places.

I was consuming the full authenticated firehose (not jetstream) with tens of megabytes of RAM with python+sqlite (unfortunately I ran out of bandwidth on my cheapo VPS, I've yet to refactor to use jetstream instead)

say more? I thought the protocol was designed to be able to handle decentralization

The firehose of peak twitter was 80MB/s of compressed json IIRC. That more around x00k posts/s