Paul Rohr

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

Every day they are choosing harm.

Every day we are choosing care.

On the need for effective participatory governance:

"Past research on platforms such as Reddit, Stack Exchange, Tumblr, and DeviantArt reveals a recurring pattern: when platform policies conflict with community values, communities tend to push back."

What else is that beard hiding?

> The point of decentralization is to guarantee the rights of individuals and communities on the Internet.

> Once you introduce shared resources ... then you need to govern those resources. This is where pure p2p falls down; it has no answer for the governance of shared resources.

How mature is your political theory of decentralization?

« We call it an "architectural" right because it emerges from the design of the network. By viewing the architectural rights in aggregate, we can get a clear sense of how a network operates. »

@pfrazee.com, June 2018

I'm really looking forward to this formal analysis when you get a chance to write it up

Specifically, how would the client/server rights for HTTPS (as described in your OG essay) compare to the rights held by:

- all atproto apps vs.
- participants in the bsky network?

Architectural rights When we examine a large-scale social computing network, we need to discover how power is assigned within the network. Who is given authority to do what, and under which circumstances? This kind of information will help us understand the dynamics of the network. As authority may be used for personal, political, and commercial advantage, we need to think carefully about its assignment.

A right will dictate what a user is able to do. It will vary for different roles and configurations. We consider it a "right" because it is embedded into the protocols, and is therefore difficult to modify or take away. We call it an "architectural" right because it emerges from the design of the network. By viewing the architectural rights in aggregate, we can get a clear sense of how a network operates.

Architectural rights emerge naturally. They do not need to be formally designed to exist in a network. However, this is a cause to consider them explicitly, not an excuse to ignore them. If rights are not made explicit, they will emerge by accident, and may be assigned unfairly.

But we're still missing an enumeration of the "architectural rights" which emerge from the specific ways each technology is organized

Yep. Today's essay provides a nice contrast against the two more familiar modes of decentralization -- federated hosts + magical meshes -- with a focus on the practical constraints of supporting specific UXes at scale

GitHub - pfrazee/infocivics: Information Civics paper Information Civics paper. Contribute to pfrazee/infocivics development by creating an account on GitHub.

Dunno whether he was using the term earlier, but git blame suggests he beat you to it by ~8 years 😉

In a world with Honest Trailers-style campaign posters featuring philosophers instead of politicians...

#Project2025

On another branch of the multiverse, this totally would've been me

samesies

Dunno if you were planning to go anywhere near this far, but I'm certainly looking forward to whatever subset you choose to write up

Thanks for doing this!

And then finally, you could move onto the most advanced stuff, like yet another document on patterns for leveraging non-AT data from sidecar services

When is it worth migrating data to become lexicon-native vs. when are you better off answering AT queries from data stores in other formats?

Armed with that baseline vocabulary, subsequent documents could then describe which levels of experiences can be supported by querying:

- PDSes (or CARs) directly,
- @microcosm.blue services, +/or
- custom appviews

Because knowing you don't usually have to jump to that final level is huge