but should apps see our data?

thinking small on ATProtocol

View post on Bluesky

I'm going to start this post out by saying, hi, I'm here to make friends. But also, this post is in part a response to https://dholms.leaflet.pub/3meluqcwky22a and https://ngerakines.leaflet.pub/3mf5wu6fs6225, and some ~questions~ and ~feelings~ I have about private permissioned data and how it might get built on ATProtocol. But also, let's be friends :-). And a warning: this post got longer than I had initially hoped.

A little bit of a backstory: when @eagraf.dev, @sashankg.bsky.social (my collaborators!) and I first started discussing our dreams for the internet, which is what is now culminating in @habitat.network, we weren't really thinking about open social at all. We were thinking about wanting to keep our data in our homes. We were thinking about how to share that data directly with friends without middlemen data scroungers. We were learning about IPFS and Ink & Switch, experimenting with libp2p. But we were also starting to ask some of the meaty questions that ATProtocol addresses, like, if I really do own my data, how do other people know how to fetch it? and who is the authority of my identity -- do i need to store it on the blockchain like a bro?

I bring this up not to say we thought of ATProtocol before ATProtocol, but because it's interesting that when approaching some of the biggest problems on the internet -- credible exit from large social networks and personal data ownership -- there seems to be a convergence on some core ideas out of necessity and practicality; decentralized user identities, a shared data schema language, the ability to self-host. Even though, at first glance, these problems differ wildly in scale (home server nerd vs. global public square). To me, that is what make ATProtocol so powerful. And as an engineer, I guess that's why I keep thinking about permissioned data: an elegant solution on the protocol would be so lovely, tying together the pieces for a foundation of both the massive and the hyperlocal.

Where does trust come from and where does it go?

There's a phrase I've heard a couple of times in private data discussions: "trust flows from the user". The implication of this being that if a user implicitly trusts a given app by using it, then developers should respect that choice in order to respect user trust, thereby possibly unloading responsibility of user data authorization and safety onto that app server, which operates separately from the PDS and could independently make other choices with that data. I had an immediate strong disagree reaction both with this idea and this statement, and couldn't quite put my finger on why for a while. Because I do think trust flows from the user ... but I don't think it quite flows in that way. Trust flows from the user to ... other users. Typically in share modals in applications. Not to developers, and not to apps. I've never quite experienced "trusting an app". I use software because I find them useful or necessary or exciting, and though I try to make healthy privacy choices and trust the right apps and developers, more often I end up giving up on trust altogether out of apathy of what is currently the state of privacy online. Which I sense might be the norm ...

My gut reaction to the idea that we need to trust apps with authorization is so strong because it feels antithetical to ATProtocol (or my vision of what it can be) if it's possible to build massive surveillance engines on the protocol, just like the ones we have today. This is a hypothetical ... but is it? It's easy enough to index the whole network right now. Slap a sticky product on top of that that enough people use and it feels like we're right back to where we started. Not to mention the mess it leaves for the user, say, if I want my friend to see a piece of data, but I don't trust the app she's using to view it, but who am I to be keeping track of what clients my friends use to do whatever they do online? But if I don't then does that leave me exposed in some way? And the dream (!) is a flourishing of apps and experiences on the protocol! Delegating trust to apps means needing to lock down and be choosy about which apps I authorize to my account. And again, I don't even care about trusting apps. I care about trusting people.

This all seems to be complicated partly by the fact that ATProtocol started out building for the billion-user use case. There are certain types of apps that simply need a bird's eye view (no pun intended, doubly). But is this really the default app? It all feels a bit chicken and egg, like the apps we have today need to see private data because they serve big world use cases, and there are no small world use cases on ATProtocol because private data doesn't exist yet. What about personal software, like a notes app? Or a future dinner party? Or a feed with just four people? Do those really need aggregators or indexes or even back-end servers?

What if big world use cases were just one case that permissioned data solves for? What if we had public data, and permissioned data that could be aggregated, and also permissioned data that is authorized at read-time by the PDS and never aggregated? Can we have it all?

I have to say I'm biased. I am not a Twitter person, or really a Bluesky person, or a social-media person in general. I am most excited about what could happen if ATProtocol 🤝 local-first software for private data use cases. As a little sneak peek, that is exactly what we're thinking about at @habitat.network (with much inspiration from the broader ideas circulating), and why I felt a bit like chiming in on this discussion. We hope to build a PDS with permissioned data where apps don't need to be given special powers; they are built strictly local-first, with additional primitives in the PDS should putRecord/getRecord/listRecords fail to be enough. I know @ngerakines.me said the protocol's got it all already, but the more I think about the potential of ATProtocol, the more I feel yes, and-- to what the protocol and ecosystem could provide (yes to community-owned PDSes, and yes to the PDS enforcing permissions, and maybe yes to remote hydration?). I'm excited to dive in.

An aside

I believe ATProtocol has the guts to be the next generation of the internet. But I also believe that won't happen unless it's as easy to build an "app" as it is to build a website. If web 1.0 was a flourishing of handmade and static read-only sites and web 2.0 has been about the introduction of user-based publishing which lead to the conglomeration of data into mega-apps, then my hope for the next iteration of the web is to achieve the data affordances of web 2.0 with the ease of creation afforded by web 1.0. And I believe that this is exactly what ATProtocol enables us to do. I also believe that this next iteration might look a lot different from what we currently experience online, might get built differently, might fulfill different desires and needs from the internet and offline life too.

So the question I keep asking is: what does it take to make ATProtocol the default way to build on the internet? And I think this question is so interesting because it forces me to ask not just technical questions, but also the socio-technical, and the practical. Simply put, if it requires running a big server to build on ATProtocol, then that probably limits who is going to be building apps (I think, even with AI). But I digress.

Do we either have private lives or not?

Why E2EE? - Real Housewives of San Francisco

The last thing I've been thinking about is this piece by @tessa.germnetwork.com. At what point does permission-ed data feel private enough? Is it really only E2EE? I have my own answer, and that's when it's in my house (no engineer can read it except me 😎) and my friends gotta ask my network directly for it. But then again, complete control over your data online is an illusion. No matter what you do, you can't stop a screenshot. I guess it all comes down to who you trust.

Finally, okay, I'll shut up now

We're so close (so close!) to getting @habitat.network to a place where we can share more, though I don't want to classically promise too much and under deliver. Stay tuned. On my part, I'll probably keep lurking.

-Arushi ⚙️