Wow, that went by quickly!

It is now nearly the end of my second week at Bluesky, during which I have reviewed a number of old Github issues, merged some fixes to quasi-undocumented features that community members were asking for, had some exciting conversations about conference planning, and chatted with many of you in the Atmosphere about what you're doing, what you're most excited to see in the future, and what we can do better with a non-zero devrel headcount :)

Most of all, I want to say thank you all so much for the enthusiastic reception. This is not my first rodeo, and I know how intimidating it can be (for all of us) to intrude on a space where people have been pursuing passion projects within a community they know and trust, and then try to establish a routine of regular work, best practices, boundaries mutual respect, and everything that comes with it. You (the you reading this) have been great, and have given me a great starting point for improving our docs and other surfaces that help us all do the work we want to be doing.

For one thing: this is actually a blog now, as opposed to last week's detached post floating out in the ether (oops). Thank you to the Leaflet devs and to everyone who reached out about this; I'll be publishing in this same spot on a weekly basis from here on out, so feel free to bookmark it.

And on that note: let's talk social graphs. I've been practicing my Atmosphere pitch for a couple of upcoming CFPs, and I recently wrote this about social graphs in other parts of the web:

>> Social graphs are a well-understood technology. Using infrastructure and standardized protocols that are usually de facto controlled by large, commercial platforms, they provide a way of structuring and querying data about individual nodes (often users) in a network and the relationships (edges) between these nodes. They are theoretically extensible, and social graph data can typically also be represented using open standards like RDF which can be published and consumed by other authorities participating in a network. However, trying to enable participation or federation this way is frequently wishful thinking, and does not really facilitate scaling that social graph beyond a particular API representation of rows in one organization’s database.

Right now, one of the strongest parts of an Atmosphere app pitch — even if you're talking to an audience that isn't necessarily all in on decentralized protocols or microblogging on their own — is that any new apps can automatically benefit from the critical mass of data that Bluesky users are already seeding the network with. Each Atmosphere app can declare its own schema (aka Lexicon), which establish the record types used by a given app. These records are associated with a user's own data repository (which they can migrate to any PDS they like) and can be read by any other app built on the Atmosphere. This way users get to both a) own and b) span their graphs across the network.

One of the coolest examples I've so far seen of actually reusing the Bluesky Lexicon in another app — a totally allowable thing to do — is anisota, a swiping-style game (a bit like Reigns for anyone who played that) that creates cards from all the interactions present in your personal data repository and gamifies (sorry) engaging with them in some way — e.g. with a bookmark or a like — before you run out of "stamina" by depleting the deck. It's a totally unique, and totally "Atmospheric" (trying to make this catch on as a way of saying "idiomatic to the Atmosphere") use case, and it can only get more creative the more non-Bluesky Lexicons that you have in your data repository.

In the meantime, here's to 40 million users on Bluesky — that counter should tick over sometime before Friday morning at this rate!