tokio_tungstenite even

No, I use the tungstenite crate. Reusing a lot of what the CBOR implementation used (connection logic, server drops/timeouts, etc)

Thanks for the tip though!

Mostly done:

👍 Replaced CBOR Firehose with JSON Jetstream (drastically reduced event stream)
👍 Replaced Diesel with SQLx (async and remove OS client libs)
👍 Message parser down to ~12% of a single Hetzner VCPU
👎 Websocket connection to Jetstream slower, but multiple servers available for redundancy

The #rustlang Bluesky feed is showing its age; I built it when Bluesky was in beta using a hacky DAG-CBOR implementation.

I'm now updating it to use Jetstream/JSON for reduced bandwidth, power usage and easier on my wallet.

Maybe a few more restarts during this transition, but no other changes! 🤞

This is now implemented, future posts from @rust-lang.org should now appear in the rustlang feed

Good idea. My current implementation looks at message content only (keywords with weights), but I can probably add a list of usernames to the filtering as well. I will look into it tonight!

I customize. A lot. Probably too much. Historically, using private git repos with notes on how to re-apply configs.

Learned about "dotfile managers" recently, and tried chezmoi - loving it.

Highly recommended if you have lots of unmanaged app configs.

(Note: Addictive)

www.chezmoi.io

Perhaps a good candidate for a macro, future_vec!(...)

Well written Chris, you can really tell a lot of thought and work went into this! Smart move to abstract away the tokio specifics, both for future maintenance and clearer examples.

I just don't like the pin-box-future vec thing, I understand why it's needed and all, but... 🥴

Astro is awesome

I feel this needs a unicode/terminal/nerdfont symbol variant asap

A feed can return a cursor along with the list of posts. The cursor tells the client more posts exist. How the cursor is handled is entirely up to the feed service though - it's just a string.

The #rustlang feed now supports pagination so you should hopefully be able to scroll back around a week or so.

bsky.app/profile/robb...

What if version control was AWESOME? YouTube video by Sympolymathesy by Chris Krycho

It's a really nice alternative to git CLI, I like this overview video by @chriskrycho.com: www.youtube.com/watch?v=2otj...

@steveklabnik.com also has a nice tutorial/overview/guide: steveklabnik.github.io/jujutsu-tuto...

You can jump effortlessly between jj and git commands so it's easy to try out

Hi Jonas, no sorry. It's quite a messy project but others have asked for the source so I might clean it up and make it public. Yeah the feed parser (listening to and filtering out rust events) is Tokio based. The feed generator (serving the feed) is Actix so also Tokio behind the scenes.

It actually only pulls in the reply with Rust in it. The bluesky client then shows you the larger context/thread.

I think for that a simple search on the hashtag is easier. This feed is supposed to draw in stuff from Rust keywords and URLs, like crates.io as well. Sure it pulls in the odd rusty car post, but I don't mind. It's built by humans for humans. You should've seen it a year ago.

Tre sista bokstäverna i förnamnet framlänges, tre första i efternamnet baklänges blir man lem

The Rustlang feed does indeed identify specific keywords, save links to those posts in a database and provide a feed endpoint to list them.

The AT Protocol provides a "firehose" that you can subscribe to via WebSockets, it spits out everything that happens in the network in real time.

That's cool, to each their own.

I started with Visual Studio bloated with various addons and quite recently moved towards more lightweight editors and IDEs. Day job requires me to be in Windows alot still (unfortunately) and Zed ain't there just yet.

I guess Helix makes you hurt even more then? 😜

Zed - The editor for what's next Zed is a high-performance, multiplayer code editor from the creators of Atom and Tree-sitter.

Zed is promising zed.dev

It's quite easy to connect a websocket to the firehose URL and start deserializing messages, filtering out what you need. It does require a bit of work with the CBOR crates and types, at least the ones available at that time. Maybe it's easier now. (The header and message is combined/a union)

I built the Rustlang feed here on Bluesky in Rust, the feed parser uses around 5-7MB RAM and is very easy on the CPU. Async message handling from firehose, no regex (only keywords). I have a separate service for generating and handling requests to the feed, an Actix service.

Added two more things to that strange list of tools that, when first explained or read about, seem superfluous and unnecessary, but after some hands-on experience, become part of your core tools:

jj and TailwindCSS

(and sorry Rustlang feed viewers for this feed not updating yesterday)

Turns out I used a 32-bit integer (i32 in Rust) to store the sequence number, and it overflowed. Which means that sometime yesterday sequence numbers on Bluesky passed 2,147,483,647 😁 Upgraded to i64, so next time this happens will be on sequence number 9,223,372,036,854,775,807

@atproto.com ‪Custom built feed is unable to deserialize com.atproto.sync.subscribeRepos commit payloads since yesterday - has anything changed in that message structure?

Clarification: jj does not find and use public keys from ~/.ssh for various jj git commands. Some workarounds and an open PR is available.

Thanks alot! This is a really nice safety belt when exploring jj in an active Git team. A bit surprised I haven't seen it before in beginner tutorials.

Unfortunately the repositories I work with are strictly behind SSH/key auth, which does not seem to be supported by jj yet. 😢

I feel like I need the basic "how to survive with jj alongside a git team" first, to properly start exploring it. Most tutorials and examples I've seen feel constructed to highlight jj features rather than reflect real life