I want to start a discussion about how to let users open an atproto object in another app. Obviously with ATproto there’s a lot more possibility for apps to just display/create an ATproto object themselves. But there are still situations when it’s important for apps to send the user to view/interact with the object in another app:
a lexicon they don’t support (e.g, app supports viewing app.bsky.feed.post, but not site.standard.document objects)
a feature they don’t support (e.g, a moderation tool that lets you review posts, but not create follows - or a view only app, where you can’t reply)
the user prefers to use a different app (e.g, user has a main app where they want to do most things, but sometimes uses a second one for it’s nice feed/discovery features)
Which leaves the question: Where to send them?
I have seen implementations that attempted to address this in a couple of ways:
1 - App developers select a single destination
e.g, the app just has a “Open in Bluesky” button
Pros:
Can work where the lexicon is “owned” by a specific app
Works for that single apps mobile app that can have intents for their own url
Works well for users who aren’t yet on Atmosphere
Cons:
Doesn’t really allow for multiple apps
(how many do we already have that support app.bsky.feed.post?)
Doesn’t allow user preference or choice
2 - The object has a canonical url
e.g, extracting the url from site.standard.publication
Pros:
Choice resides with author of the object
Works well for users who aren’t yet on Atmosphere
Cons:
Not supported by most lexicons
Doesn’t allow for user preference or choice
Then I’ve also seen some interesting discussions that allow for more options:
3 - Implement custom app picker
Apps could have public declarations about what lexicons they support, and developers can all read this and implement an app picker in their own apps
Pros:
Allows for user choice
Supports multiple apps
Cons:
Needs standardisation and uptake first
Each app has to implement their own open in other app picker?
4 - Implement user preference objects
Users could have public (or maybe in private spaces) declarations about their preferred apps, which can be shown as the app to open with
Pros:
Allows for user choice
Cons:
Needs standardisation and uptake first
Doesn’t work for signed out users, or those who aren’t yet on the Atmosphere
Hi, ya it’s interesting and tricky problem space! There is a similar discussion happening in this thread. Funny enough I’m almost done drafting a proposal that attempts to tackle it, will try to get it out in the next couple of days.
This proposal is really cool! I’ve been working on something overlapping with at-intents but I think aligning on your proposal is a good idea.
Few ideas from at-intents we might want to consider incorporating:
support more verbs than just open. maybe a small open set (e.g. “save”, “share”, “subscribe”) to handle more than just navigation?
use the user’s own repo as a discovery source. an app someone uses can leave “usage” records to create personalized open/share lists and even populate it without an appview
I like how this uses a mix of approaches, to offer something that provides better coverage overall.
And I fully agree that user choice of where to interact with an atproto object should take precedence over the object authors or lexicon creator.
You highlight that this pattern already somewhat exists with files an apps in your OS, which I think is a great angle to take this. I don’t expect every app on my computer to implement an app picker, I expect it to delegate it to the OS. I’d like to explore if that’s something we should lean into now. While there isn’t a unified layer all atproto apps run on, they do run on OS/browser layers that offer some of this functionality. For example: Android app picker could be triggered by web URLs, custom URI schemes, or even if we decided to make the atproto object an actual file. Web Share APIs offer some similar controls too. I guess what it doesn’t help with is discovery, or if a user hasn’t installed any compatible apps yet.
Another part of your proposal that got me thinking was the idea of the community XRPC endpoint. If we’re open to that type of centralisation (which I agree is nicer than some of the other options), then what if we had a community appview picker. A url I can send users to, for any lexicon, then instead of telling me which apps can support that lexicon, it just shows those options directly to the user. That way each app doesn’t need to implement their own and it offers more privacy (my app doesn’t need to know what other apps they use, and allows preference lexicons to stay in shared spaces).
And if the community keeps this service open, we could allow mobile apps to register intents to that url. This would mean my users can open the atproto object in a other app, using nothing but the mobile OS controls, without me having any knowledge of what app they use. The community appview picker remains as a fallback for when the OS can’t (e.g, no matching apps installed).