Trezy

Release v1.10.0 · gamesgamesgamesgamesgames/happyview 1.10.0 (2026-03-05) Bug Fixes add support for did:web when resolving DIDs (1bc5114) Features resolve and proxy unrecognized XRPCs (ee43d05)

A new release already wuuuuuuuuuuuuut 🧵
github.com/gamesgamesga...

Honestly same. I was asking folks in the atproto touchers discord yesterday. I'm sure there's lots that I haven't covered yet.

UGH. Github Actions being down is really putting a kink in what I want to get done by the end of the week. 😞

Oh no... did I just make it worse? 🤣

If it helps, I just pushed everything for my PDS stack this morning. The repo includes my Grafana dashboards, as well as the scripts I use the pull the data from the PDS.
github.com/gamesgamesga...

A dashboard for my PDS. It shows tons of stats, charts, and graphs.

Ha, I spent a decent chunk of yesterday on the same thing. I feel this very muchly. 🤣

A doozy indeed. HappyView v1.9.0 is out, and this one's all about making the Lua scripting layer way more powerful. 🧵
#atproto

Oh man... I'm wrapping up testing now. The next release of @happyview.dev is gonna be a doozy. I think it's the biggest update since first release. It's packed with /a lot/ of cool features.
#atproto

I'm pretty sure I already have answers for this! You, me, and @cjfulton.bsky.social should hop on a call to discuss. ❤️

Oh... I didn't realize the lexicons could live elsewhere? I thought the lexicon spec defined that they need to live in the repo with that handle... I must have misunderstood something.

What's the value of separating the accounts? I don't follow. 🤔

To get a catalog of games on protocol for this whole project I'm working on. The goal is for it to get smaller over time as developers claim their games and migrate the records and blobs to their own repos.

I can get the CAR file now! It's much smaller than I expected at 675 MB (675,401,953 bytes).

Yeah, this fixed it! 💙

you wouldn't download a CAR

New version of Cirrus supports streaming CAR downloads from getRepo. This should massively improve memory usage for large repos. Thanks @trezy.codes for the report.

Fewer records than I thought, tho! 643,281 records. The vast majority (362,378 records) are games.gamesgamesgamesgames.game, with games.gamesgamesgamesgames.org.credit coming in at 265,544 records for second place.

@pfrazee.com @bnewbold.net Just letting y'all know that I'm in the midst of migrating the PDS for @gamesgamesgamesgames.games to a new server. The current PDS is probably gonna start throwing errors for a lot of the requests from automod. I should be fully migrated in the next few hours, tho.

I finally have an actual number.

2,076,938 blobs. That's how many are stored in the @gamesgamesgamesgames.games repo. 😅

Brookie! I'm working on it! 🤣

i feel like i just cast a spell reading this

Finished late last night. ~1.5 million records (~2.5 GB CAR). More than 2 million blobs (190 GB storage).

Now it's causing issues across the network. 😅

Yes please! 😀

You're not wrong! I don't want to discourage the idea, either. I'm just more focused on what's possible with the existing infra today. 😀

I think the idea of `satisifies` is really great, but I think it's really an answer to a different problem.

I think my biggest gripe with this is it would have a significant impact on infrastructure.
- The lexicon schema has to be updated to support `satisfies`
- PDS needs to support the new XRPC
- Tap needs to be able to take `satisfies` instead of just target collections

Whether it's called a Generic or an Interface or a Primitive or whatever, I'm not sure I'm finding the semantic value in it as a new schema type.
- Generic: This is... information about another record?

I may be missing something there, tho.

The other lexicons schema types all tell us something significant about the greater intent of the lexicon:
- Record: This is just data
- Query: This retrieves things
- Procedure: This changes things
- Subscription: This is a persistent connection and these are the messages it'll send.

That's pretty much just pedantic, tho, right? The only difference would be that the lexicon for the generic would use "type": "generic" instead of "type": "record"? I'm not saying that wouldn't be valuable, I'm just not sure it makes a significant difference.

I imagine it's the second option, tho this would be a lot harder to index.

Good point about the nsid! I updated the article to use community.lexicon.generic instead.

As for the $type, did I mess that up somewhere in the article? The $type fields all look correct to me, but maybe I'm missing something. 🤔

That said, this solution falls down if your `satisfies` target ever changes. It's not supposed to by the lexicon spec, but in reality it absolutely could. 🤔