The original Jetstream is really cool - it's incredibly easy to start consuming the Bluesky firehose - you don't even need to use a server, you can consume it directly in the browser.
Sort of on a tangent to the actual content of the page, but what documentation system/CMS is this particular web page UI? It seems very fast and relatively uncluttered for the menu on the left side, content pane, top horizontal menu bar.
If I'm understanding this codebase right, it's a hand-rolled framework based on MDX and Next.js; the UI elements you're referring to were designed from scratch and aren't based on any existing CMS theme.
No sure I agree on fast. At least on mobile the sidebar has an show/hide slide animation that takes a sizeable fraction of a second. In fact is one of the slowest animations for this I have seen.
I disable animations entirely on devices I use where possible. They just waste time and that adds up if you use something regularly.
I haven't looked at it on mobile, that's unfortunate to hear. I don't see any animation when interacting with it on a desktop browser, snapping open a left side header menu item to see sub-items seems instant.
Yeah, I see what you mean now, I am looking at it on mobile and that animated slider to show or hide the entire menu seems like it takes unnecessarily long.
Also the VC-backed funding for this infrastructure will run out eventually. It's not self-sustaining, and Bluesky have no viable route to profitability.
I wonder if it would be a good idea to remake DNS on top of bluesky. The basic idea is that, if you own a domain name, you post DNS updates in a bluesky feed. The firehose itself is authoritative. DNS servers sit downstream of the firehose. All the updates to domain names get written into a database, and they essentially just respond to queries hitting that database. This would let anyone (with enough bandwidth) run a fast domain name server.
We could use this to fix some of DNS's long running problems. Like, we could add upstream cryptographic signatures to DNS records. And put TLS certificates in there too. We might be able to ditch TTL entries. In a DNS server, records should update via server-push from the firehose. You shouldn't have to wait for TTL to expire.
I've built my own client for Twitter. I'm using a library that a random guy maintains. It has its problems, but all of them can be worked around, and overall it feels solid, especially considering the fact that it's done by a single person.
Then I had to add bsky support when everyone and their mother migrared there. I used the atproto Python library and holy smokes, whener I need to touch that part of the code I feel sad.
I'm all for whatever atproto expansion and whatever's going on here, mainly it harks back to early Twitter days (tho also for better or worse, watching them build Bluesky in realtime isn't the best), but when they have outages like last week a good chunk of service unreachable/down for many hours with little update on https://status.bsky.app/ and then whatever history just basically disappears as if nothing ever goes wrong, it's not a good vibe.
Despite all the openness and github repos and what not it's very difficult to get straight answers or just like find a place where issues or changes to the platform are addressed easily.
I updated my browser demo to use the new Jetstream just now - hit "connect" and scroll down the page to see the events flowing past: https://tools.simonwillison.net/bluesky-firehose
This is new jetstream:
wss://jetstream.us-east.bsky.network/subscribe
If I'm understanding this codebase right, it's a hand-rolled framework based on MDX and Next.js; the UI elements you're referring to were designed from scratch and aren't based on any existing CMS theme.
I disable animations entirely on devices I use where possible. They just waste time and that adds up if you use something regularly.
Also the VC-backed funding for this infrastructure will run out eventually. It's not self-sustaining, and Bluesky have no viable route to profitability.
We could use this to fix some of DNS's long running problems. Like, we could add upstream cryptographic signatures to DNS records. And put TLS certificates in there too. We might be able to ditch TTL entries. In a DNS server, records should update via server-push from the firehose. You shouldn't have to wait for TTL to expire.
I think it'd make a nice little system.
Then I had to add bsky support when everyone and their mother migrared there. I used the atproto Python library and holy smokes, whener I need to touch that part of the code I feel sad.
Didn't they terminate free API access? How does your client work?
Related:
Bluesky's active user base is shrinking as its focus expands beyond the app
https://news.ycombinator.com/item?id=49263461
Despite all the openness and github repos and what not it's very difficult to get straight answers or just like find a place where issues or changes to the platform are addressed easily.