Leaflet stream

An overview of the last week or so of news related to atproto tech. News about specific atproto software and apps are for another update, as well as the larger socio-economic context of the open social networks. This update is focused on developers and other people who are interested in the more technical aspects of atproto. For more news on the open social web you can check out my writing at connectedplaces.online, or check out my Leaflet for shorter updates.

• Bluesky has been taking the first tentative steps to submit atproto to the IETF standards process. The company just published their Internet Draft of atproto. Internet Drafts are documents within the IETF process that do not hold formal standings, and are made for the purpose of reviews and comments. The first formal step is via organising a Birds of a Feather Meeting at the IETF Montreal conference this November.
• Some musings by Bluesky CTO Paul Frazee on the naming of 'AppView', and if this part of the atproto infrastructure should have a different name.
• QuickDID is a new tool that handles handle resolution for atproto. QuickDID is a resolver that focuses on a single function, resolving atproto handles to DIDs. It is available to self host or can be used at https://quickdid.smokesignal.tools/.
• PDS Gatekeeper is a microservice that adds 2FA to self hosted PDSes.
• Previously I wrote about how the different book review platforms on atproto (bookhive.buzz, skylight.my, paperbnd.club) all use different lexicons, which prevents interoperability between then. The developer of Bookhive.buzz wrote a response thread why they chose separate lexicons; the problem is in data standards for books itself. Paperbnd and Skylight use standardised book identifiers (ISBN and OpenLibrary), but as these standards still have ambiguity, Bookhive.buzz stores all the data about the books on the PDS instead.
• A first pass at making fanfic archives on atproto.
• An extensive 2-part implementation guide for building OAuth applications on atproto, for both web and mobile.
• ATPage was a tool to publish HTML website to your atproto PDS. The tool is now sunset, with some reflections by the developer here, and why they are now switching to using Leaflet.
• Bluesky Jetstream Live is a tool to view relay outputs.
• More developers are starting to write weekly reflections on their atproto development work. Bailey Townsend writes about updates to AT Toolbox, PDS Gatekeeper and adding a landing page to their self hosted PDS. @bad-example.com writes about microcosms, some hiccups with relays, and a demo app to store small amounts of arbitrary data privately on a PDS.

Small note beforehand: If you've followed me before, you likely know that I write a weekly ATmosphere Report with all the news about Bluesky and the ATmosphere every week, over at connectedplaces.online. These weeks I'm switching it up a little, by splitting the report up into smaller parts and publishing them separately. The entire ATmosphere Report will still be published (and emailed) regularly as well, and this posts will be made more accessible on my own website soon.

This edition contains the atproto tech news and links of the last two weeks. It focuses on the tech and protocol side of the network, and thus assumes some familiarity with what's going on in the network.

Bluesky PBC is setting the first step in having atproto potentially become an IETF standard. This November in Montreal they will hold a Birds of a Feather meeting at the IETF conference. "The purpose of a BOF is to make sure that a good charter with good milestones can be created, that there are enough people willing to do the work needed in order to create standards, and that any standards would get adoption." This is a first step for atproto towards becoming an official IETF standard:

Bluesky has enabled the 'show more/show less' buttons on their Discover feed to be used by custom feeds as well. The update came from independent developer Grace Kind, and I think her response shows the power of open networks:

• Red Dwarf is a client for Bluesky, that takes a very different approach under the hood. It does not use an AppView, instead it relies solely on Constellation and PDSes to display all data. The code is now available on Tangled, and Red Dwarf demonstrates it is possible to build a Bluesky client with a significantly different architecture under the hood.
• Bluesky engineer Bryan Newbold published a guide on "ecommended atproto data limits and lexicon-schema-agnostic validation behaviors".
• A guide to hosting the rsky-relay implementation. rsky-relay is an implementation of the atproto relay in Rust, made by the Blacksky Algorithms team.
• Streamplace explains how their Indexer system works.
• Some previews of an upcoming new project called Slices, which is an "appview for building appviews". Developer Chad Miller has used this to create a search interface for Tangled, as a demonstration of the capabilities of Slices.
• A proposal on how to build encrypted messaging combining atproto with email's SMPT, with a demo of how it works here. Smoke Signal's Nick Gerakines wrote a response blog as well on the project.
• The weekly update for microcosm, with a deep dive into the current ecosystem of relays in the ATmosphere.
• Comparing the different (indie) relays that are active, now with some additional features.
• A one-click deployment of a PDS on Coolify.
• A new tool that displays all your 'bookmarks' (meaning posts you replied to with a 📌).
• Graphtracks is a new custom API that aggregates atproto firehose data into accessible formats for other developers to build upon.
• Tangled-pages allows you to host a website via a Tangled repo.
• A tool that converts Whitewind posts into Leaflet posts.
• A demonstration of email 2FA on a self-hosted PDS, which is now also available on Blacksky.
• A prototype of a browser that can handle atproto handles, DIDs, as well as regular web pages.
• A first version of OAuth Scopes for the atproto Identity Rust Components.
• An extensive article on the technical challenges when building a general-purpose recommendation feed.
• A sneak peak at an If This Than AT system, which came out of the recent ATProto NYC Community Hack Day.

Small note beforehand: If you've followed me before, you likely know that I write a weekly ATmosphere Report with all the news about Bluesky and the ATmosphere every week, over at connectedplaces.online. These weeks I'm switching it up a little, by splitting the report up into smaller parts and publishing them separately. The entire ATmosphere Report will still be published (and emailed) at the end of the week as well.

With that, here is all the atproto software news and updates of the past week or so:

• Paperbnd is a new book review platform on atproto, with all the features you'd expect from a GoodReads alternative. Paperbnd focuses on interoperability with culture review app Popfeed, by using the same lexicons. It is made by the same developer, and it is effective a book-only version of the platform.The main challenge with review platforms on atproto so far has been getting sustained usage by people. Splitting the Popfeed app into a separate place for books might help here with branding, and by using the same lexicon it maintains interoperability and community growth.
• BookHive.buzz is another book review platform on atproto, and they released their own iOS app recently. BookHive.buzzh uses a different lexicon than Paperbnd/Popfeed, making them not interoperable.
• That both platforms (as well as Skylights.my, another culture view platform) use their own lexicons effectively leads to a splitting of the community over the platforms: you cannot see a review someone made on BookHive if you use the Popfeed app. There are roughly three outcomes here: (1) review platforms settle on a single shared lexicon to use, (2) review platforms display data from the other platforms in their apps, (3) the platforms stay separate. I'm curious to see which direction this will develop in.
• Snowpost is a new writing platform on atproto that focuses on simplicity and ease-of-use. Snowpost is a minimalist execution compared to other writing platforms like Whitewind or Leaflet. It uses markdown, which is stored as a blob on your PDS.
• Offprint is another writing platform that has been announced to be currently in development, with the explicit goal of taking on Substack. Offprint is not yet available, only screenshots of the design are shared. The space for writing platforms on atproto that want to take on Substack is definitely heating up however.
• Back in May, Bluesky started testing a new feature for selected accounts to add their YouTube or Twitch livestreams, where Bluesky will show on their profile picture if they are currently livestreaming. This feature has now been expanded to include atproto streaming platform Streamplace.
• Bluesky wants to know how much demand their is for an in-line translation feature.
• Git collaboration platform Tangled allows users to self-host 'knots', which are simple headless servers that store Git repositories. This means your entire codebase is not stored on your PDS, but on this independent server instead. Tangled has made some updates under the hood, which makes hosting a knot easier, and gives the Tangled AppView more independence and new features, such as showing trending repositories.
• Writing and publishing platform Leaflet now supports comments on articles. These are not Bluesky posts, but are their own lexicon. Leaflet now also supports Youtube embeddings in their posts.
• Bluesky client Anisota now gives users more granular control when it comes to muting accounts and keywords.

Small note beforehand: If you've followed me before, you likely know that I write a weekly ATmosphere Report with all the news about Bluesky and the ATmosphere every week, over at connectedplaces.online. These weeks I'm switching it up a little, by splitting the report up into smaller parts and publishing them separately. The entire Bluesky Report will still be published (and emailed) at the end of the week as well.

With that out of the way, here is a collection of interesting links related to Bluesky and the ATmosphere:

• Blacksky founder Rudy Fraser has an extensive article in New_Public that explains in detail how Blacksky works and why it matters: "Blacksky’s rsky guarantees our community a seat at the table, and ensures that we can leave and easily make our own table if we need to".
• The Techdirt podcast has a conversation between Bluesky board member Mike Masnick and Rudy Fraser. They talk about Blacksky, growth, content moderation and more.
• Bluesky CEO: I turned a Twitter research project into a rival company—‘we’ve achieved what a lot of people said was impossible’ - CNBC interviews Jay Graber.
• Wherever you get your Podcasts, a blog on Language in a decentralized future.
• Northsky, the cooperative that is building their own social media platform on ATProto for the 2SLGBTQIA+ community, explains their cooperative structure and how they are planning to roll out PDS migration in their latest newsletter update.
• Brainstorming an ATProto Notifications Inbox - a blog post by A New Social's Anuj Ahooja on the potential for an app that gives you notifications for all ATProto platforms.
• did:plc Considered Harmful, a blog criticising how did:plc governance is still fully dependent on Bluesky PBC.
• A helpful explainer video on how ATProto works (for varying definitions of 'helpful').
• An exploration on how to measure the 'health' of the ATmopshere, comparing usage of Bluesky versus all other apps on the network.
• what is anisota.net? - some personal reflections on the new bluesky client Anisota by its creator Dame, as well as some future plans. This response by Bluesky engineer Bryan Newbold is also a good illustration of how Bluesky thinks about decentralisation and building open protocols: allow people to bootstrap their projects by using other product's infrastructure, and let them gradually evolve into their own independent product or platform.
• What happens when you let people on Bluesky control your printer.
• A blog about creating a visual representation of all the post Bluesky. The visualisation itself can be seen here.

Calls for people to get off Substack pop up regularly on the open social web. People argue against writers using Substack predominantly based on three reasons:

• Substack does not do enough to moderate Nazi content.
• Substack creates lock-in for their writers, making it harder and harder to people to migrate to other platforms later.
• Substack is expensive.

Regarding Nazi content, Substack's co-founder Hamish McKenzie told The Verge that it will not remove or demonetise Nazi content, after which more and more people started calling the place a nazi bar. This viewpoint has fairly widespread on networks like Bluesky and the fediverse, even as many writers on these platforms still depend on Substack. This viewpoint got further entrenched when the Substack app recently send out a push alert to promote a Nazi blog.

A new post by the Beehiiv CEO (another newsletter platform) talks about how Substack is creating further lock-in on the platform. There are multiple aspects to this:

• Substack now allows you to 'follow' writers, which is different than subscribing to their email newsletter. This 'follow' social graph is owned by Substack, and will migrate with the writer if they move to a different platform.
• People who have a paid subscription with a Substack writer have a direct payment connection with that writer through Stripe. If that writer would move to a different platform, these paid subscribers would automatically move over as well. Substack is pushing of people now to subscribe via Apple Pay instead. If a writer moves to a different platform, these subscriptions will not move with them. This creates significant lock-in to Substack, as moving to a different platform now means lost revenue for writers.

All these arguments present a 'negative' reason for writers to move away from Substack: Substack makes it hard to leave when you want to leave the platform because you think the platform is bad. The argument is mainly focused on people perceiving Substack to be bad, whether 'bad' here means ethical, financial or other reasons.

But there is another good reason to be very careful with depending on Substack: it is also hard to leave Substack when you think other platforms are good.

One of the main values that people see for using Substack is a combination of:

• getting started for free
• in-build discovery and promotion mechanisms for growth
• does all the basic things of a newsletter writing platform well

It is especially the second part that makes Substack appealing. Growing a new blogging platform is incredibly hard, and anything that helps with discoverability and marketing is valuable.

The open social web (which I'm defining here as a combination of the fediverse, atmosphere, nostr and farcaster) consists of multiple different attempts to build an open protocol for social networks. The first step that all these networks start with is with microblogging, since that is the easiest modality to bootstrap. However, the second modality that gets widely experimented with on all these networks is with longform writing and publishing.

• the fediverse has WriteFreely, WordPress and Ghost.
• the ATmosphere has Leaflet, WhiteWind (as well as emerging platforms in development such as Offprint).
• Nostr has Yakihonne, Habla and npub.pro.
• Farcaster has Paragraph.

All these writing platforms take a slighly different approach, but they do have one thing in common: the recognition that the social graph is valuable for distribution and promotion of your writing. That is why people try to integrate writing platforms on these open protocol. It gives new affordance to its users, as well as promising to connect to a wider network that can be used for distribution and promotion.

I think that none of these platforms have truly cracked the code yet on how to build a next-generation distribution system for long-form writing. The main barrier here is actually on the microblogging side, where nobody seems to have figured out a good UX yet to combine short microblogs together with longform writing into a single destination that users enjoy.

The open social web is effectively a bet made by people, saying that they can create the infrastructure layer on which a new social web can be build. If this bet pays off, it means that we will see a wide variety of social platforms that are able to replace the current social platforms.

This bet is by no means guaranteed to pay off. The future of the open social web is still uncertain. But if it does, it changes the dynamic around Substack as well.

It is realistic, though far from certain, to imagine a situation where a platform on the open social web has managed to:

• increase their userbase to over a 100 million MAU
• build a UX that integrates long-form writing much more closely with the feeds-based system of most other platforms, with accompanying discovery systems to boot.

In that context, the argument for Substack also changes: instead of people not wanting to be on Substack because they feel the platform is bad (for various ethical/financial reasons), people do not want to be on Substack because they think other platforms are better.

One takeaway from Musk, Twitter and people migrating away to other platforms is that only a limited amount of people will move to different platforms because they think the original platform is bad. Providing a platform that does something new that the previous platform could not do is a much more compelling motivation for people to switch.

I do not think we are at a phase yet where the blogging platforms on the open social web provide a radically better experience than Substack can. However, I do think that enough different people and companies are tackling this challenge in a way that makes it likely that at some point someone will crack the code, and build a publishing platform that does provide a major advantage over Substack.

And that becomes a risk for writers who are dependent on Substack. So far, Substack building their walled garden has had relatively minor impact writers building their business on Substack. But if all the people building alternative writing platforms on the open social web have anything to say about it, there might just become a time where being dependent on Substack has some significant opportunity costs.

Here's a sentence for you:

Bounce is a new cross-protocol social graph migration tool that uses a protocol bridging service to create an mirror account on the sending protocol, which simulates the effect of sending your social graph across protocols.

If you understand everything that's going on here, congratulations on also having open-social-web-brainworms.

I'm gonna go out on a limb here and assume that this is not everyone though.

The Bounce service launched in beta today, and I think there are multiple stories going on at the same time:

• What the hell is cross-protocol account migration, and how does it work
• The impact on 'credible exit', and how moving to a different protocol impacts this
• the shaping of language, and building towards a shared understanding of what 'protocol bridging' even is.

For an explanation of what this is, Sarah Perez at TechCrunch as a good article which makes explains it as follows:

A New Social explains Bounce in more detail here:

Bluesky advertises itself with the idea of 'credible exit', the idea that you can meaningfully leave the service and take your social graph and data with you. Bluesky has mainly meant that in the context of ATProto:

• you can transfer your account to another data storage provider
• you can use other client/app on ATProto that is not the Bluesky app, if you disagree with Bluesky's ToS for example.

Bounce adds an additional layer to this all:

• you can now transfer your account to another protocol altogether.

In this way, the ability to use Bounce to migrate your social graph from Bluesky to Mastodon actually is a benefit to Bluesky: it further cements their claim of providing a credible exit. This lowers the barriers for people who are unsure about trying out Bluesky, there is now a way back.

One challenge for Bounce, as well as Bridgy Fed, is the lack of shared references to help explain what this all actually is. Understanding why bridging software like Bridgy Fed matters, requires knowledge of how the open social web protocols work.

It creates new kinds of artefacts, such as 'mirrored' accounts on the bridge, which are a new concept that people are largely not familiar with. Furthermore, this type of account does not even have a good name to define what it actually is.

• When you have an account on either the fediverse or atproto, and want to interact with people from the other network, you can do this with a bridging service like Bridgy Fed. When you do this, people often describe this as having a bridged account.
• Services like Bridgy Fed (and Bounce) work by creating an additional account on the Bridgy Fed platform, that passes messages between the networks. When people on the other network want to follow your account, they do not actually follow your account natively: they follow this additional account on the Bridgy Fed service.
• It is unclear what this additional account is actually called. TechCrunch also calls this 'a bridged account', but there is no clearly defined term for it. The A New Social Team prefers not to use 'bridged account' here (due to that term already used for the other meaning), but there is no clear alternative. Mirror account maybe?
• Without clear definitions and names, it becomes even harder to explain a process that is already hard enough to explain what it is. I'm not sure if people who would be interested in using a tool like Bounce understand that this means that this depends on another 'mirror' account that is operated by another organisation. Clearer naming might help here.

Recently I wrote about how decentralised networks lead to fragmentation and decentralisation in the underlying protocols that power them. People might see bridging as a temporary solution to a problem caused by developers with a Not Invented Here Syndrome. Instead, I see this fragmentation and protocols that are only partially compatible with each other as a logical result of giving people freedom to build and hack whatever they want. Sure, it leads to interoperability issues and it can be annoying, but it is also an unavoidable result from the social dynamics that are part of truly open networks.

That means that bridging services and other software that focuses on making incompatible software compatible with each other will be part of the open social web for a while longer. And that means that there is also a lot of work to be done regarding language and explanations of what these tools actually do, and how they impact regular users.