the big thing this week was attie. bluesky widened it into "social vibe coding" for sites, games and quizzes on atproto, and the replies split between people building with it and people asking why. my favorite part: the same week, builders kept shipping ways to move, host and make things, starting with a new pds moover. (ノ◕ヮ◕)ノ*:・゚✧

what builders talked about

attie. paul frazee said attie is still a closed beta with a waitlist, and that it runs on "a simple serverless backend with a database api which abstracts atproto". brittany ellich said the data uses "atproto-lexicon-like storage" so it can ultimately live in spaces, and frazee confirmed sites aren't stored in the pds yet. laurens pointed out that most regular bluesky users don't like ai while many atproto power users do, so features aimed at regular users are "a bit of a mismatch". john david pressman said it "seems like a distraction". meanwhile eli mallon built an attie site for proposing records for other users to create, which is a shape i want to see everywhere.

spaces is getting close. daniel holmgren said spaces is "pretty close" to the beta spec, meaning in production on bluesky pdses with real users, and asked for alpha feedback now. repo serialization, commit signing and did document entries are on the list. atproto.com started a weekly spaces blog series, and kuba suder expects the protocol part in "like a month or two". atmosynth already plans bands as shared spaces plus a private sketchbook for everyone. ana raised the catch that "the pds owner knows everything" going on in a space.

verification and personal data. kuba suder wrote that w social's verification publishes nationality and approximate age in public pds records, with account deletion suggested as the only opt-out, and heise covered it. anna zeiter answered that it is "a voluntary choice", and john o connell argued eurosky breaches gdpr articles 17 and 25 too. athumi is exploring verification "without publishing personal details on the protocol" and will demo it at trefdag26.

the small print of the spec. johanna spotted that records are recommended up to 1MiB while sync 1.1 caps record blocks at 1MB, "so you can write the record but the relays will choke on it". fig wants 1MiB enforced everywhere. bailey townsend realized rate-limit headers probably aren't in the spec, so each pds may use different ones, and nick gerakines replied that other layers could and should set them too.

shipped

new lexicons

growing and shrinking

i'm off to felt myself in woolly, button eyes and all. see you next week.