At , we're working hard to launch something at ATmosphereConf. We're building a platform for user data agency: giving users full and transparent control of where their data flows on the internet. Naturally, building a privacy-first platform, we're thinking about permissioned data.
Currently we're building pear: a permission-enforcing ATProtocol repository, tied to your ATProtocol identity through a service, as defined in the DID document (for now). To build confidence in our design, we've been working on a few toy demos. The first one of these is greensky, and it's exactly what it sounds like ... ! The demo itself is not all that, but under the hood we are using it to proof out the abstractions we created for permissioned data.
Dropping a link early in a post is always risky, but I encourage you to read the rest of the post. This is a toy demo, my design skills are a bit lacking (hello infra engineer!), but hopefully I manage to convey to you what we're steadily building up towards through writing :)
🦠
In later posts, we'll be diving deeper into our design with motivating examples and our other demos. But for now we're throwing this out as a way to ask some questions about what permissioned data means for the ATmosphere. While building greensky, we encountered all these questions and more, despite building a demo with pretty limited functionality! We thought about:
How can we design more contextually, so as a user it really feels like "now I am entering a public square" or "now I am entering a more private forum"?
The greensky demo doesn't do a great job of this -- the feel of the main feed is quite similar to the feel of the private post permalink, which is basically a private chat thread. Though we do link out to Bluesky both out of convenience and as a way of simulating this.
How do we design for experiences where we might operate in public and private contexts simultaneously?
The greensky demo tries to do this with different color borders around posts but ... I know we could do better.
The greensky demo also never shows replies outside of the context of its parent post -- it would then need to show a visibility badge like (🔒 Followers of <@handle>).
How can experiences give users full control over their data, while not overwhelming them with technicalities of the underlying system?
The greensky demo gives users the ability to post to followers or specific users. Technically speaking, however, users can go back and modify the original people they shared a post with, or even modify the permissions on replies, so a different set of people can see the reply than who saw the post that the reply was to (the power of data ownership! It's up to the user who owns that piece of data). The options here are overwhelmingly endless. How can we design for experiences that strike a balance?
These questions essentially boil down to: What does permissioned data feel like on ATProtocol?
🍃
At the ATmosphereConf, I'll be co-facilitating a workshop for imagining alternate social modalities (that hopefully can be built on ATProtocol!) with , , and . While preparing for this workshop, I've been reflecting on how privacy and consent are key factors that enable us to actually inhabit multiple modalities (modalities = a multiplicity of forms) in the physical world.
For example, take parties. In the span of a couple hours of attending a party, I might go from having a one-on-one conversation with the host to telling a funny story to the whole room to sharing photos out on social media to taking polaroids with my friends to hanging out in a corner to gossip about other attendees with my fellow anti-socials. That's just a typical night. But online, today, this variance in modality, so highly contextual and deeply human, is nearly impossible. There is no "party app" that allows us to do such a thing, or whatever the equivalent is for other "apps". (When I think of ATProtocol as a post-app protocol, it's this focus on experiences over apps that I resonate with most). Today, for the large part, one app = one account = one sort of modality online. Even the platforms most well-positioned to offer us a plurality of experiences because they have the most resources ($), typically only allow a few modes -- close friends lists, private accounts, public accounts, to take Instagram as an example. And in spite of those limited options, people still come up with creative ways to adequately express themselves -- I'm thinking of finstas and group accounts.
So imagine what would be possible if highly granular ways to share little bits of our identity with others was built into the Internet (the protocols!) as a first principle. To us, this is what permissioned data is really about.
Of course, such variety of experience is only enabled by the integrity of the space: we gossip in the corner with our friends if we're sure no one else can hear us (and it's not secretly mic-ed up!). I might not be telling that funny story if another crowd or even another person was in the room. So how do we actually build that kind of integrity online (with ATProtocol)? That's a question that will have to wait for our next couple of posts. Whatever we build, we intend to be compatible with where the ecosystem lands in the future, but for now we're focusing on key use cases that are not actively being built for.
Until then, stay partying my friends.
-Arushi 🪅
P.S. In my head I've been remapping "PDS" from "personal data server" to "public data server". A true "personal data server", I think, could do much, much more. It would enable us to walk into a party online, and actually interact with different people, in different contexts, in different ways. In ATProtocol, the PDS seems like the perfect locus from which people can wield agency over their experiences online -- a way to own the whole of your online identity and reveal bits and pieces of it in different contexts...