Paul Rohr

ATProtocol Patterns: Record Elicitation Record elicitation is a pattern where a client asks an AppView to construct a record from the user's intent, rather than building it locally. This lets the AppView handle business logic, validation, and schema complexity while the client retains full authority over what gets written to the user's repository.

Check out my new blog post, 'ATProtocol Patterns: Record Elicitation'. In ATProtocol, only the user's client can write to their repo. But what if the AppView has information the client doesn't?

Insofar as OAuth effectively delegates PDS access, it should almost certainly be the latter

On that point, I suspect you're both violently agreeing 😉

If I understand @fry69.dev correctly, the question is about mental models. What domain should people associate their "bsky password" with:

- an application (.app) or
- an identity/network (.social)?

That password/domain binding encapsulates a ton of trust, so it's worth taking time to decide:

- which domain earns that trust,
- how clear that OAuth flow is, +
- what level of access is granted

... preferably in as few words as possible

( See the linked 🧵s for more on what that may require )

I've been saying for nearly a year that getting the UX right for bsky's OAuth deployment is a major inflection point for reinforcing users mental models

If we phrase things right, people will learn that this password UX controls access to my identity + slices of my atmosphere data (via my PDS)

Not sure I understand your ActivityPub analogy, though

The "store + forward" model of AP inboxes is a very different storage paradigm from the separation of concerns (PDS vs. indexes) enabled by the AT sync model

App designers used to the former often miss the radical potential of the latter 😉

Fair enough. Migrating to take advantage of atproto's decentralized storage model makes the most sense when it enables core features your users value

If you're better off delivering those from your centralized web infra, then AT-powered features will remain a bolt-on for a subset of your users

Naive question:

Is there a world in which it'd make sense to "enable" (not force) them to use atproto accounts you host on their behalf?

Would that create awkward UX flows for existing users who already have other atproto accounts they'd rather use for this?

Or do you prefer to not be that host?

Software Design is weird. It is undoubtedly the most impactful medium shaping the world today, yet even those of us working in it know very little of its history. We have no broadly-read books, no docu-series, no video essays. Most see the works of the past as obsolete rather than a rich heritage.

Sure, but feel free to use favicons if you find 'em (+ are capable of caching them)

As you point out, this is an easy, obvious convention to start supporting for anyone who wants to encourage branding support for PDS operators

Whether you or @pds.ls go first matters less

The friendly header is great, but for similar reasons, it's probably worth including the full PDS hostname for mushrooms:

Inkcap (US East)
Bluesky-hosted PDS

This account's data is stored on a Personal Data Server (PDS): inkcap.us-east.host.bsky.network. A PDS is ...

Yep. Suspension is a great example of the difference between:

- pruning from an appview's indexes (reflects app moderation policy) vs.

- deleting from my PDS (expresses my choice of who to follow)

Composable Trust, Part 1: Communities Without Credible Exit We guarantee that users aren’t subject to platforms. Yet communities are still subject to their stewards. Can we fix this?

Moderating @furryli.st always made me feel that something was missing from atproto. If we disappeared, so too would the community we built

This feeling’s finally crystallized into this proposal: Composable Trust

We created identities that survive platform failure. Lets do the same for communities!

Forest bathing, winter edition

Stop asking for permission. Build the thing you want to build.

A screenshot showing the setup boxen

Started to flesh out the amount of services which you can cryptographically verify you have access to using @keytrace.dev

GitHub, DNS, Masto, Bsky, npm, Tangled, PGP, Twitter, LinkedIn, Instagram, Reddit & Hacker News

YouTube video by NPR Music Buddy Guy: Tiny Desk Concert

Instantly transported back over four decades to the night we rushed to see one of Buddy Guy's last performances at the Checkerboard Lounge on 43rd Street in Chicago

Awestruck that we still have the privilege of living in his world today

The best way to get reliably consistent counts across an entire network is to directly measure the actual traffic ... exactly the kind of solution atproto was designed to make easy

Debug, tune, + audit the code for that service once, then everybody can trust (or clone) the results going forward

By contrast, atproto's public dataflows are inherently inspectable with whatever sampling accuracy is desired -- either DIY it, or peek at someone else's (easily verified) counts

Unclear why *anyone* would prefer aggregating lower-quality partial caches (nodeinfo) to full-fidelity wire-based counts

You're being very polite

Because of inherent limitations on how fedi traffic flows, they can't get usage info without polling instances for cached stats + coping with a growing number of implementation "quirks"/errors

( With enough pruning, something is better than nothing )

Global map of social network user data storage for Fediverse (Mastodon, Pixelfed, etc.) instances Service-specific icons for each geolocated instance are scaled based on the number of MAUs each currently supports. Prominent icons depicted at this zoom level include: bookwyrm (North America) pixelfed (Europe) lemmy (South America) ASIDE: Tables with the corresponding MAU counts are linked from the main page, but it's unclear whether there's an accessible way to extract the geolocation data depicted on this map

Global map of social network user data storage for Atmosphere (Bluesky, Leaflet, etc.) PDSes Service-specific icons for each geolocated instance are scaled based on the number of MAUs each currently supports. Prominent icons depicted at this zoom level include: bridgy-fed, blacksky (North America) wafrn, tangled (Europe) generic PDS (Asia) ASIDE: Tables with the corresponding MAU counts are linked from the main page, but it's unclear whether there's an accessible way to extract the geolocation data depicted on this map

4. Finally, #dataviz folks may also enjoy the linked maps showing where the various account hosts are geolocated

Kudos to @ricci.io for all the effort building + sharing such flexible tools for exploring these metrics!

3. It also measures ecosystems for a number of protocols beyond that pair of overall AP vs. AT dials:

ap = fedi software
at = bsky trusted verifiers

https = web serving
git = public forges
smtp = email services
dns = hosting
tls = certs

... with the least mature ones being most concentrated

A few notes about this fascinating dashboard built by @ricci.io:

1. The quoted pair of dials measure accounts across entire ecosystems, not just a single social media experience

2. They're quantified in terms of MAUs (AP = 1.2M, AT = 5.5M), rather than accounts created

TIL about a pair of centralization metrics:

- Herfindahl–Hirschman Index
- Shannon Index

The former comes from economic analyses of market share + competition, while the latter is an ecological analysis of entropy + diversity

( See ALT text for an overview. More details linked from the OG page )

This is a heckuva compliment:

"And once we started, it was actually easier to build something that works for any atproto record than to build a bespoke scheduling system just for ourselves."

“protocol is fun for dev“ seems like one of those things that has been undervalued

The Bluesky Dictionary Can Bluesky say every word in the English language? Well this is your chance to find out.

ok as a word nerd this is very cool:

The Bluesky Dictionary by @avibagla.com

www.avibagla.com/blueskydictionary/

(via @j4ck.xyz)

reading "users shouldn’t feel they’re dealing with weird behavior just because they’re on a decentralized protocol" and i feel like we don't really appreciate how radical that is as a concept in the grand scheme of things

Goldilocks unit of social context:

"Buckets give us a few things we’ve been missing. They provide a natural unit of access control that is neither too granular (per-record) nor too coarse (per-app). They handle dynamic membership. And they give applications something concrete to sync and index."

More apps that have the stated benefit of making you lifelong friends