Most of the discussions I see about ATProto interoperability focus on lexicons. E.g. how to share lexicons, how to coordinate on defining and modifying them, what namespace should they be under, and so on. As much as I think these discussions are important, I don’t think they should hold apps back from exploring forms of interoperability that don't require sharing lexicons.

From the context of Semble, I see two forms of interoperability making sense. Perhaps these will also work for other folks' use-cases.

Lexicon Mapping

The first type of interop is taking a record of one lexicon and mapping it to another. For example, if someone bookmarks a url with @kipclip.com, Semble can listen to the firehose for community.lexicon.bookmarks.bookmark record creation events and convert it to a network.cosmik.card record (with provenance). The bookmark would then show up as a card in Semble.

For these cases, I think it’s important that it’s an opt-in “integration” where various settings can be configured. E.g. how to convert tags to collections (if at all). This approach also ensures the user consents to their non-Semble data being visible in Semble.

Above is an example of how various ATmosphere integrations could be enabled and configured in Semble. Picture the list on the left including Kipclip as well.

Activity Types

The other type of interop doesn’t require any kind of record mapping. Instead, the original record is displayed as a separate activity type in the app. In Semble, this could show up in our explore feed as different feed activities.

The example here demonstrates how we could show links from Bluesky posts as well as bookmarks from other apps, like @monomarks.at. This could also be configurable by letting users toggle which activity types they want to see in their feed.

What’s nice about this approach is that the notion of an “activity” keeps things flexible without needing to introduce new concepts into Semble.

Furthermore, these activities could still show up on the users Semble profile, but instead of being under the Card tab, they could show up in an Activity tab (not yet implemented!).

A Pragmatic Approach

On the protocol builder spectrum of pragmatism vs rigour, I see the discussions around shared lexicon best practices leaning towards the right. For a healthy ecosystem in the nascent stages we find ourselves, though, I think we’ll want a spread of solutions across the spectrum.

I’m excited to hear other ideas!