First, catch up on Part 1: “Putting Social Media Back on the Internet.”
*
I think a lot about a post I saw on my Bluesky feed: “I just downloaded Bluesky’s new video app, Skylight.”
Web2 experiences—the experience of the walled garden that only grows through mergers and acquisitions, not interoperation—is the expectation the world’s social media users bring to our products. That’s why when I explain how Germ DM works with Bluesky and the rest of the ATmosphere, I often say:
You know how Facebook Messenger has all your friends from Facebook and Instagram and Threads in there? The experience is like that, except instead of one company owning and controlling all those different apps, we’re all different companies, pulling from a common protocol that holds your profile, posts, and friend graph.
Germ DM is very easy to use. So is Bluesky. So is Flashes, so is Skylight. But people still don’t really understand what’s going on.
How do we make sense of the ATmosphere to denizens of the walled garden?
How do we make sense of the ATmosphere to denizens of the walled garden?
At Germ, our goal is to make a messenger that is easy to understand and easy to use, so that it’s easier to share a Germ card than to share a phone number or Instagram handle. Today, people increasingly hesitate before sharing numbers and handles because they’ve learned the hard way that once you share one of these identifiers, the person you’re giving it to—whether they’re a new date, or a business—has it forever. Actually it is easier, already, to share a Germ card with a QR code than to look up someone’s Instagram handle—but building new habits is difficult.
At its core, Germ is about consent. We’ve built new tooling that lets people connect consensually, which means controlling what information they share and how long they’re connected for. Real consent is reversible. It’s also informed. (Read Jane Im’s paper about affirmative consent and social media UX.) That means our users need to understand what they’re doing. And now that we’ve integrated with the AT Protocol, our educational work has extended beyond our own protocol and product into this big new technological world.
Open social media is built for new kinds of agency and consent—the agency to own, and move, my data; and to withdraw and refuse consent to surveillance and manipulation on dominant social platforms. But it also creates new contexts in which to navigate consent. For us, creating UX that informs users what they are doing is integral to achieving their continual consent for the choices they make in our app.
Mass market consumer apps are rife with dark patterns, surveillance, addictive content and manipulation—and at the same time, they’re what five and a half billion people know.
Mass market consumer apps are rife with dark patterns, surveillance, addictive content and manipulation—and at the same time, they’re what five and a half billion people know. So we have the unenviable task of building something that is empowering in new ways, yet feels familiar. How can we introduce friction in the places people missed it, and not where they didn’t? How do we make both new and familiar patterns as easy as possible to navigate? Like: How do I onboard? How do I share my contact? How do I make sense of having multiple cards?
*
Now that Germ has integrated with atproto, I’ve been thinking much more about mass market understandings of social media sharing. Because updating our users’ mental models about what they’re creating, sharing, and storing when they use atproto inside of Germ is now part of my job.
Here are some things I don’t think web2 users understand yet about atproto and other open social protocols.
Here are some things I don’t think web2 users understand yet about atproto and other open social protocols:
Everything I do is completely public. Not just my posts but also my likes, my friend graphs, who I’ve blocked, who’s blocked me, and more. While everything I did on Facebook and even on the web was being stored, tracked, and profligately sold beyond what users were conditioned to expect, it wasn’t actually published. But everything I do on open social is as open as a public website. It may be being ignored like many websites are, but it also may be indexed or stored in ways I don’t know about.
Part of that indexing and storage is on other apps on the protocol, even if I’ve never used them. If I open Flashes or Skylight for the very first time, every photo or video I ever posted—not to Bluesky, I might start to understand, but on Bluesky to the AT Protocol—is there. I put it there myself, but I might not understand that.
Users of atproto have been clamoring for something: private data. I’m clamoring for it myself. What that generally means today is the ability to have a private profile, or private posts, so that I control which other users can see the information I’ve posted.
Privacy is connected to consent—who do I consent to share things with? But what does private mean, in open social?
Privacy is connected to consent—who do I consent to share things with?
But what does private mean, in open social?
The era of walled gardens gave social media users expectations based on a centralized architecture. When everyone on a platform is using technology built by the same company, that company can enforce consistent behavior across its products. A centralized, cloud-based architecture enables users to retract content that has already been shared, through features like disappearing messages, or the ability to change public profiles and posts to private—both behaviors where content that was previously visible to some set of users is no longer visible to them. For example, a major expectation around private profiles is that I can turn my previously public profile private, and everyone who could see my posts and photos one second ago suddenly will not be able to see them anymore.
On Facebook, this is possible. All activity is stored on Facebook’s servers, and never stored locally anywhere. So at any time, the company can stop showing a piece of data in any selection of users’ apps. But on open social protocols, content is published to the protocol and read by a variety of products. On atproto and other social protocols, sharing is more like sending an email—the other person has it, it’s out there. And it can’t be pulled back.
My hypothesis is that moving toward both disappearing messages in Germ and private profiles on atproto will require new design patterns that involve user education about new constraints.
Germ DM is also built on an open protocol that can (by design, not today) send messages to clients our company doesn’t control. So we resist features that are designed with the expectation that Germ can make promises about what happens when your content leaves your device—for example, with disappearing messages. My hypothesis is that moving toward both disappearing messages in Germ and private profiles on atproto will require new design patterns that involve user education about new constraints. Users might not have the privacy patterns around disappearing content they have on Instagram or even Signal, but consent means that they must achieve the privacy at least that they’re expecting.
Because privacy isn’t a static value, but rather a parameter based in people’s expectations. An end-to-end encrypted messaging session or call between 2 people; a political dinner for 500 ticketed guests; or a user’s set of social media data and metadata shared with 1,000 friends and stored with open internal access on the servers of a company with 100,000 employees… are all considered “private.”
The adoption of new technologies always involves a learning curve. Over the past few years, we’ve seen widening understanding of the algorithm, data brokers, and end-to-end encryption. The growth of interoperable protocols in social media will also entail folks learning more about where their data is stored, and who they’ve published it to.
The growth of interoperable protocols in social media will entail folks learning more about where their data is stored, and who they’ve published it to.
*
How have we at Germ navigated these new concepts when designing for accessibility, understanding, and consent in our product? As we integrated AT Protocol into Germ DM, both UX elements and writing needed to accurately and concisely reflect the relationship between Germ and AT Protocol, the data users create and the preferences they set in each product and protocol, where they are stored, and who can access them.
Some of the questions we discussed included, do people know what AT Protocol is?
Some of the questions we discussed included:
Do people know what AT Protocol is?
Our guess was that for the majority, the answer was no. In fact, we noticed that users of the Bluesky app never see the words “AT Protocol” in the UX itself. Yet instructions like “Log in with Bluesky” would be fundamentally inaccurate.
How do we create contact permissions?
When users followed friends in atproto apps, they weren’t making decisions about Germ. But the Germ app would like to infer relationships from AT Protocol. How should we communicate and highlight this to users?
Germ messages and cards are stored locally in our app, but now some information is also being pulled from and pushed to atproto. Relationships can begin because of atproto settings, but once they are confirmed in Germ, atproto settings (like whether you are friends) become irrelevant. How do we communicate this?
In the screenshots above, you can see some of the initial choices we've made.
The first screen introduces our users to Germ. We mention end-to-end encryption, but not the concept that E2EE content is stored locally on the user’s device, in the app.
In the second, we introduce the idea that there are two kinds of cards—cards built with AT Protocol, which we demarcate as “ATProto (Bluesky),” and another kind. This second kind is stored locally—again, not explained.
The third screen is Bluesky’s OAuth screen, exclusively naming Bluesky, not the protocol.
On the fourth screen, you can see my own personal cards. The top one is my atproto card, with the butterfly icon indicating a connection with my Bluesky profile. Ultimately, we'd like this graphic to reflect your chosen PDS. Underneath are my burner cards, with data that’s stored locally on my device.
The fifth screen shows the UX for blocking someone’s atproto card. As you can see, the user has the choice to block the other person just within the Germ app, or to send the blocking preference back to Bluesky. The copy here went through several revisions as we realized that the preference we send back to your PDS only governs your microblogging social graph on Bluesky or Blacksky, not on other products—so it would be misguided to say "Block on ATProto."
Reflecting on these screens now, I see even more deeply how important the concept of local-first is to what we’re doing and the choices users navigate. Yet many young people today don’t even know what a file is or how to find one on a computer!
Reflecting on these screens now, I see even more deeply how important the concept of local-first is to what we’re doing and the choices users navigate. Yet many young people today don’t even know what a file is or how to find one on a computer! Our atproto integration has created a hybrid structure where our default app is local-first, with all data stored inside your Germ app on your phone, with opt-in opportunities to sync certain profile and preference information with remote protocol data. How do we make this intuitive to the lay user?
Here’s another UX question on our minds: how do we communicate that once a pair of users connect in Germ, they can unfollow each other completely in the ATmosphere and their connection in Germ will persist? I expect there is a more mature visual language in Germ’s future that continues to educate users about what lives exclusively on your device and in end-to-end encrypted channels, and what is communicating with a public or semi-public cloud.
*
Germ DM manages relationships. But in our modern digital world, privileges, rights, and responsibilities lie with identities.
Germ DM manages relationships—in our app, identities are simply ways to categorize how you know people. Our vision of social networking lives inside the relationships you choose to keep alive, expressed through end-to-end encrypted messaging sessions.
But in our modern digital world, privileges, rights, and responsibilities lie with identities—what they hold, what they unlock, and who accepts them. The more time we spend integrating AT Protocol into Germ, the more I see the atproto handle—which is a representation of a Decentralized ID, a DID—as the object we're contending with. It’s the handle, sitting on top of the DID, that unlocks the personal data server—the backpack of posts, friends, and preferences that users can take with them from app to app—which we write to and read from to bring your external social world into the private environment of Germ.
In her interview this year with Wired, Bluesky CEO Jay Graber augured that people’s AT Protocol handles could be their next phone number or e-mail address— “potentially the last social identity you have to create.” If that is the case—or rather, to make it the case—we need to teach folks that this is, in fact, an AT Protocol handle—not a Bluesky one.
Part of this will come from the continued differentiation of AT Protocol as a brand, with a visual identity and UX language that all atproto apps, including Bluesky, can use to collectively identify what they're built on. We need to visually and linguistically communicate to users that we are all different applications pulling and pushing user data from a shared protocol. For Germ DM, that will make it easier to reflect what is and isn’t connected to your AT Protocol handle, and help people make informed decisions about what they’re sharing, how our app learned about them, and where this information is stored.
As the protocol matures, I hope we’ll see new ways for people to build trust in their handle and their PDS, to understand what’s being written to it, and to have faith in their access to it. Is there a future where an ATProtocol handle feels more like a Google account, in terms of durability, security, and utility across a huge interoperated ecosystem? But like, better? Because once upon a time, I chose to log into third-party sites with Twitter instead of Google, because I trusted them more. Now that company doesn’t exist. How do ATProto DIDs become the most trusted logins on the internet?
*
In the meantime, we’re all focused on shipping outstanding products. The last ten years have shown all of us that great products drive protocol adoption; they certainly drive the adoption of digital IDs. As we build in parallel, we learn even more quickly how the AT Protocol can be shaped to serve a decentralized ecosystem of products, data, and users.
There’s so much here already. The collection of products that make up the early ATmosphere is a nearly complete social media ecosystem in miniature, ready to be turbocharged:
Bluesky, Blacksky, and Northsky for microblogging and moderation.
Graze for feeds, news, community, and algorithmic choice.
Roundabout, Gander, and Eurosky for geopolitical communities.
Skylight for vertical video and e-commerce.
Stream.place for live video streaming.
Who’s got payments? Blacksky?
Smokesignals for events.
Leaflet for blogging.
Flashes for photos.
Popfeed for curation.
Roomy for extra-large group chats.
Germ DM for end-to-end encrypted messaging, voice and video calls, and maybe even multi-identity relationship management.
The task ahead of us isn’t just to build features; it’s to build trust in our products and their services, and new understandings of how they work, both independently and together. There are so many more lessons, products, and features ahead of us. I can’t wait to see what we build. I’m pretty sure it’s the future.
The task ahead of us isn’t just to build features; it’s to build trust in our products and their services, and new understandings of how they work, both independently and together. I can’t wait to see what we build. I’m pretty sure it’s the future.
Read more about Germ DM at germnetwork.com or follow us @germnetwork.com.