Leaflet stream

(a short bonus post because I need an example of a Leaflet post with an image embedding as a heading, and figured I might as well write something)

Sebastian Vogelsang, whose the developer of Flashes and working on the commons moderation service for Eurosky posted a very interesting question this week which got me thinking.

The idea behind the Eurosky commons moderation service is as follows:

• Developers can register their apps with Eurosky.
• Eurosky acts as the endpoint where participating apps can send content reports.
• Eurosky then provides moderation decisions that can be shared across apps using the same lexicon.

So far, so good. But the problem is that not all apps are the same. Vogelsang makes a distinction between consumer apps and producer apps. The distinction is simple:

• Producer apps are predominantly used to create content.
• Consumer apps are predominantly used to consume content.

For Vogelsang and the Eurosky team the question is: how should the costs of running the commons moderation layer be split across all participating apps, and should there be a distinction between the different types of apps?

I think thats a good question, and I don't yet have a clear answer to that.

But for me, this distinction between producer and consumer apps has been stuck in my mind for the last few days.

The current social networking era of the Big Tech platforms sees everyone use the same app to access a platform. Musk uses the same X app when he posts 150 times per day as any rando who just wants to scroll their feed. Same with TikTok, Insta, etc, the power users who are responsible for creating the content use the same app to access the network as the lurker who follows 3 people and scrolls for 5 minutes a week.

Social media is well known to follow a power law curve regarding how content on the network is created and consumed. As a rule of thumb, most networks follow a 1-9-90 split, with 1% of people creating original content, 9% occasionally contributing and 90% lurking.

It is one of the quirks of how the current Big Tech platforms work that these very different groups of people all use the same app to access the platform. It is clear that their experience, use case and needs are extremely different. For example, notification management is an absolute must if you are a creator with a big account (and even then it's often a mess), but for a lurker this matters much less. A lurker prioritises good feeds that gives them the content they are looking for. Also important for some creators, but other big accounts often don't have the time to read through feeds anyway so they only need the most relevant highlights.

The cool part of open social networks is that we get to move away from the paradigm of building the same app for very different types of people to access a network. Instead we can now build different apps that respect the needs of different groups of people.

However, what interests me about Vogelsang's post is that this also creates new challenges as a result. Should producer apps and consumer apps be treated different, when it comes to shared moderation costs, for example? Currently ATProto lexicon records do not indicate with which app a post was made. Apps could start adding a custom field to posts to indicate the source. Is that desirable? I don't know!

Only thing I do know is that you give people the freedom to build their own tools/apps/software, they might actually do that, and over time a network like atproto ends up much more diverse, stranger and unique as a result.

I was chatting with Sebastian Vogelsang (who's behind Flashes, Skeets and Eurosky), and he mentioned that he had recently given a presentation about atproto for media people. I asked him what his method was for explaining atproto. He said that compared atproto to wire services, and that this was a comparison that landed really well with the audience.

I've never heard of explaining atproto by comparing it to wire services before, and I think its actually a pretty smart way of explaining atproto and its value for media. It's probably an explanation best suited for people who are familiar with media, but I wanted to share this with, since I think more people might use this comparison in the right context (and shoutout to Sebastian for this!)

The idea is pretty simple: wire services, like Associated Press, Reuters and Agence France-Presse, work by creating news articles by their own journalists, which they then sell in bulk to other news organisations. A wire services aggregates news reporting, they have reporters around the world so they can cover all the news. These news articles get aggregated by the wire services into a continuous stream of news. Others news organisations usually do not have staff around the globe, but do want to fill their newspaper/tvshow/website/whatever with all global news. As a result, many news organisations buy a subscription from one of the wire services, and they get access to a continuous stream of news articles they can use.

Atproto has some quite similar dynamics, but instead of news articles by Reuters journalists, it is now user generated content (posts/videos/blogs/etc). The aggregation and relay is done by a relay, and anyone can plug into this stream of user generated content to build any social media platform they want. Obvious differences is that connecting to a relay is free, running a relay is cheap, and you cannot stop people from posting even if you wanted to.

One of the challenges with the open social web is in story telling: how do you explain all this complicated technical stuff to people? Often analogues to other internet protocol get made: activitypub is like email, atproto is like websites, etc etc. Comparing atproto to wire services takes the analogy away from the internet, to a world that a specific target audience knows well, in a comparison that holds up reasonably well on a high level.

Bonus advantage is that this analogy explains what the best place for economic value creation is for media people. Most people in media have (understandably) no interest in being a wire service: you want to buy from a wire service, place the article in your own branding, and provide enough value that people will use your news platform over any of the other news platforms.

This is sorta similar with atproto: all the low level infrastructure stuff is just that: infrastructure. There is no real money in running relays (or any other supportive infrastructure). The value is in building the app that people will use to view the content on the entire network. Currently Bluesky PBC has captured virtually everyone. But there is space for a whole lot more competitors to acquire some of this market share as well

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.