Post

Ethan Graf
@eagraf.dev

Check out my first blog! As the ATmosphere moves towards permissioned data, how do we make sure privacy is really preserved? Can we build a permissioned data app today? All that and more in the post 👀📅

Habitat@habitat.network

@eagraf.dev with part 1 of how we're building a personal calendar on ATprotocol and what we're thinking about (differently!) for permissioned data

habitat.leaflet.pubcalendar pt. 1: ATProtocol beyond AppViewsour approach to permissioned data (part 1!)

4 reposts28 likes

daniel holmgren 🫠
@dholms.at

good post, thanks for sharing! i think you're right to hone in on this question/tension, it's probably the trickiest thing about the design space excited for the next entry & to see what you guys are cooking on

daniel holmgren 🫠
@dholms.at

it sounds like you're still advocating that 3rd party clients have access to data (to allow interoperability) but that for personal/small world use cases like calendars, 3rd party backends should not. is that right?

Ethan Graf
@eagraf.dev

Yup, exactly. A 3rd party client might also be malicious of course, but since the software runs on your machine, what it does with your data will be a lot more transparent

Mark
@uppy-hacker.bsky.social

good stuff Ethan - energised by what you've already described in some detail, the hints re: tackling some of the harder challenges, and especially the closing remarks around values-based motivations. Look forward to the next episode!

Meos Labs
@getmeos.com

Permissioned data on ATProto is such an interesting problem space. What's your current thinking on how to handle revocation once someone's already been granted access?

💭 arushi
@offline.arushibandi.com

This definitely guided some of our choices. We're doing read-time checks, and we never sync actual record content between PDS'es (just info about records) so users won't see record content post-revocation (though they might be able to see historical versions of a record they once had access to).