individual atproto uis are already remixing data from different apps. so the concept of an "app" blends — each product is a prism over the shared ecosystem. and if nothing except authorship is firmly gluing different pieces, could an application be glued together from different authors' pieces?
Feb 3, 2026 at 2:42 AM
AT Intents proposal
I work on Skyreader and have recently been trying to improve the cross-app sharing experience (e.g. “send this article to semble/margin/etc”). The problem I’m running into is each app integration requires a bespoke implementation and the “save to” UX starts to get cluttered as the number of integrations increases. What would be nice is if the atproto ecosystem had a standard and generic way for cross-app sharing that was usage aware so you could filter by apps you actually used. So I’ve put tog...
Artist app diary (1): the general idea - hilke thinks
How could an artist focused app on atproto look like? In the first episode of this 'artist app diary' I sketch some general ideas that I have in mind.
Lexicon Embeds Overview
ATProto’s inside out structure provides an opportunity for open, permissionless building on top of any component in the network, including its extensible data schema definition system, Lexicons. One of the opportunities this presents is users sharing their data and records with multiple apps. Those apps may be direct substitutions (different clients for microblogging say), or apps that use that data in a variety of ways, such as Popfeed an app which aggregates posts about a variety of media ty...
I finally put some ideas into words about the artist focused app that I would like to build on atproto. I am looking for collaborators, especially artists and UI designers.
Artist app diary (1): the general idea
hilkeu.leaflet.pubImagining atproto as a post-app protocol starts with materializing the social filesystem – decomposing apps and their data into materials and instruments. For the time being, this guestbook is a good example where the display element is a material and the sign element is an instrument.
dan
in any case, the end game is composing these little guys, whatever goes on behind the scenes. social components
some thoughts on atproto as a post-app paradigm
Ecosystem Plugins
notes.wesleyfinck.orgThis is partly why I think atproto needs a more convincing vision about being a post-app protocol. A future where atproto is a bunch of apps and each app governs their own lexicon diminishes a lot of its potential in the long-term.
Laurens
yeah i think i might actually, theres a very interesting story here that the main thing that matters is a focal point around which consensus over a lexicon can get formed
What's the intended app/user etiquette for atproto apps with regards to publishing to the same lexicon? Like, say I build an atproto app, would it catch users by surprise if the wrote to the same records (e.g. posts, likes, etc?) that show up in the bsky.app? Or should my app be isolated?
I don't disagree. The standalone experiences are not particularly "the thing". Atproto's glory emerges as competitive compatibility and inter-operation of apps arises more remix-y many-tools-together systems.
dame
hard pill to swallow for atproto developers/creators: 99% of potential users either do not care about, value, understand, or want to “own their own data” i see so many apps/projects lead with this “value prop”, but it’s not an important or meaningful consideration for most people
I'm thinking about how non-developers will feel about atproto. For example, will it take people by surprise that data entered into one app can show up somewhere else? More thoughts in this post.
How do we talk about atproto to non-developers? | Rachel Andrew
rachelandrew.co.ukATmospheric Apps
Things that use ATProto to create their own records (NOT Bluesky clients / Appviews)
import.py
Archivers AT
Brickster — Build anything, together.
BlueHarbor
Kimbia - A training journal that belongs to you.
Currents
