there are lots of cool tech things happening there and i am pro-atproto, but after watching it happen a few times, it is sort of inescapable how one of the 'dev draws' that people who move from working on AP to atproto express as "the atproto userbase is not so stifling" is equally well expressed as "atproto users have no prior expectation of privacy and respect for consent." all-public-everything is already baked in at a protocol level except for bespoke implementations, so the floor is very low.
the AP space is sort of stagnant because it's stuck in a single program (also, as always, respect to the masto devs holding it down) which prohibits people from being able to self-sort into programs that can actually respect their privacy needs, so a lot has to be done by social convention and climate. as a result, people working on AP stuff end up stepping on a bunch of rakes - often, charitably, with every intention of not doing so - because we have the expectations and desire for privacy without being able to take the steps we need to make it actually enforceable.
I see a lot of the cooler atproto work (which is cool and i am a fan of, i genuinely think Blacksky is the coolest group working in the whole extended space) re-arriving at stuff we have had on the fedi for a long time. on the AP fedi we can't do some of the more public things like they are doing in no small part because the people who don't want that kind of thing can't protect themselves from it, and with an even finer grain, choose when and in what context to opt in.
so, the "AP is a bunch of stodgy privacy zealots" argument (which i am fine with, i am a stodgy privacy zealot), in my opinion is largely just a reflection of "AP is stymied by protocol and implementation where it's difficult for people to not use mastodon forever." If it was much easier for people to move around, experiment, temporarily duck into a different, more privacy-respecting software stack, exist across multiple, and so on, then a lot of the "yet another opt-out scraper" problems disappear by giving people the power to prevent that in the first place.
I think LD needs tooling, but is mostly just "unused" in the AP fedi, and it should be a very interesting protocol space to work in, but that one absence of migration and mutability at an account level is a protocol killer.
Mastodon Feed
![Issue in dwebagents/AgentPipe number 1878 by drewcassidy title: [bounty: butter] butter body: butter](https://files.mastodon.social/cache/media%5Fattachments/files/116/831/220/210/518/202/original/2d467dee3e3840f4.png)
![[PR by Votienduang2208 in response to the butter PR] Title: Yes chef. Right away chef. Add Butter Mode Body: Yes chef. Right away chef. Fixes #1878. Summary Adds a new static docs/butter.html page for the butter bounty. Implements a self-contained Butter Mode experience with an animated butter mascot, 71% default spread meter, lifecycle states (spread, churn, melt, clarify), and interactive controls. Links the butter page from the docs home navigation. Adds npm run test:butter with static acceptance checks for the page, script, navigation link, and smoke-test API.](https://files.mastodon.social/cache/media%5Fattachments/files/116/831/220/259/374/836/original/97c22789eaf80869.png)
![[A website that looks exactly the same as all other LLM websites - titled "butter mode" with a stick of butter that gently rocks back and forth.] Issue #1878: butter Butter Mode AgentPipe now has a dedicated butter ritual: spread, churn, melt, and clarify task throughput until the pipeline glides like warm toast. 71% default spread coverage for compliant toast surfaces. 0 crumbs no needless runtime dependencies; this is static and shelf-stable. 4 states spread, churn, melt, and clarify — the complete butter lifecycle. [A butter controls slider controls the amount of butter spread, among a few other operations like churn, melt, and clarify]](https://files.mastodon.social/cache/media%5Fattachments/files/116/831/220/310/383/669/original/eaea9d3a84743b34.png)
