Just realised that it's been 10 years since my "database inside-out" talk (www.youtube.com/watch?v=fU9h...atproto.com/articles/atp...
AT Protocol is the tech developed at Bluesky for open social networking. In this article we're going to explore AT Proto from the perspective of distributed backend engineering.
Thanks Nick !
Thrilled to be contributing to the incredible protocol that Bluesky is built on ๐คฉ
We got a blog post out summarizing our launch of OAuth for AT Protocol, and what work remains. This has been a huge project led by @matthieu.bsky.team with input from a bunch of standards folks and devs. Big milestone for building all sorts of clients, apps, and integrations on atproto.
We are very happy to release the initial specification of OAuth for AT Protocol! This is expected to be the primary authentication and authorization system between atproto client apps and PDS instance...
Bluesky makes it possible for users and orgs *outside Bluesky* to label content for misinformation or other issues. You subscribe to these in the app, and can unsubscribe at any time. Stackable moderation is one of our most novel experiments, so I'm excited that @newsdetective.bsky.social is here
So hang in there, and please share any feedback you may have on Github discussions so we don't risk loosing track of them! Thanks ๐
Hey Mary, The feedback you (and others) are providing is super valuable to us. We haven't announced dev-preview yet and we will probably need to tweak some stuff. Part of the reason why we took the more conservative approach was to be able to relax requirements later on.
Yep, we encountered that issue too. The workaround we think of is to rely on local storage with exportable keys if we detect that the browser is in lockdown mode... I am not aware of other means to persist non-exportable keys in Safari.
Since our trust model revolved around domain name, and because that stands a better chance of being standardized, we decided not to use ATproto identifiers, or DIDs, for OAuth.
The issue with ATuri everywhere is that there is no way a user can just trust a did:plc made of random chars. The only information in a distributed network that the average user knows how to validate (sure, to a limited extend) is the domain name.
When we designed OAuth, we had the following considerations (more or less in that order of importance): - Security - Trust between the user and client - Standadizability of our choices - Ease of adoption (DX)