devin ivy 🐋

here to serve 🫡

yup looks good

curl -s 'https://meadow.us-east.host.bsky.network/xrpc/com.atproto.sync.getRecord?did=did:plc:4ewnpnebeh7zuk5pbardaxqz&collection=app.bsky.feed.post&rkey=3lux3had5js27' | goat repo mst -

Adversarial ATProto PDS Migration www.da.vidbuchanan.co.uk/blog/adversa...

aka how to migrate your account if your old PDS explodes, and how to prepare for it in advance

proposing com.atproto.retr0.id.wasHere

"Social media users are tired of losing their identity and data every time a platform shuts down or pivots. In the ATProto ecosystem, users own their data and identities. Bluesky is the first big example, but a new wave of decentralized social networks is just beginning."

there are a handful of rules for packages published to jsr—if someone wants to help illustrate what the changes would look like for one of our packages to become compatible i think that would be a big help! would also love to hear more on how jsr improves the experience for deno users over npm.

currently traveling, but we will be looking at this when i return!

yep, that's right! i believe it should stay held until an account deletion. this behavior could conceivably change over time, but no current plans to change it.

wonder if @jeremykun.com may be able to offer some nice intuition for this

the spec on atproto.com was updated here: github.com/bluesky-soci...

but if you do run into any places that reference out-of-date info, flagging it or opening an issue is always appreciated!

Allow HTTPS `redirect_uris` from any origin by matthieusieben · Pull Request #3811 · bluesky-social/atproto This change removes the restriction of the redirect_uris urls to be on the same origin as the client id. Note that the ATProto spec needs to be adapted together with this PR. See this PR

happy to share the redirect uri origin limitation was lifted! as i recall the purpose was to err on the side of strictness while details of the client id metadata doc spec continued to solidify, to promote client compatibility. some deets: github.com/bluesky-soci... docs.bsky.app/blog/oauth-i...

usually he can achieve that in just two lines and it looks something like this

// no breakies
// -prf

yeah, lookin good—that is a nice summary of an end-to-end flow! since the contents of the permission sets are sensitive, the pds authenticating the lexicon record contents is going to be important. (and i expect you were counting that as part of record resolution!)

i was in there, also @bnewbold.net, @matthieu.bsky.team, @dholms.xyz, and @pfrazee.com all went pretty hard on this one.

new capabilities for atproto devs coming sooooon!

take a close look, and you'll find some pretty unique stuff going on in here. one of the key questions is: how will users understand what data they're providing an app access to when they login? lexicon authors will play a very important role... 👀

wait this is on the internet?

how big is it on disk in neo4j?

in and out, quick appview adventure | futur it's an appview, michael, how long could it take? tl;dr I'm running what is, to my knowledge, the first instance of the Bluesky AppView containing all\* data in the history of the network This took...

appviewappviewappview

- after 6 months, I'm running what is, afaik, the first full-network bluesky appview
- you can use it at zeppelin.social, query it at bsky.zeppelin.social, read about it at whtwnd.com/futur.blue/3..., & help me keep it up for more than a few weeks at github.com/sponsors/fut...

OAuth Improvements | Bluesky We've been making improvements to the end-user and developer experiences with atproto OAuth, and wanted to share some updates.

OAuth updates for app devs!

Over the past few weeks we've been chatting with devs and doing a pass over our SDKs and docs to address issues. This blog post summarizes the main changes we've made, some tweaks still in flight, and links to longer form writing about security and design trade-offs

protocol team is working on a proposal, but no promises

this is huge in the atproto setting where each client may interact w/ 1000s of auth servers. if the client has a breach, we can't lean on each auth server to respond by revoking creds: the client must be able to do it. we also don't want an attacker to mass revoke creds, hence client authentication.

lastly, client authentication is great and it helps in two ways. first, it secures the authn flow by allowing the auth server to confirm who it's handing creds. potentially more importantly, it also gives the client the ability to revoke credentials en masse...

second, (keeping that previous thought in mind) in the case of a "public" client, consider that all this can take place without the auth server actually authenticating who it's handing over the user's credentials to. yeah! but that's a feature, and it gives devs choice how to build. it's worth it.

first, the oauth authorization code flow is truly wild from a security standpoint: three-legged, user interaction, dynamic redirects, the browser security model in the mix. and in atproto the client and auth server have _no_ prior relationship with each other. it's no wonder oauth can be... a lot.

tried to give some intuition for how fraught the oauth authorization code flow is, how the atproto oauth profile secures it, and lots of info for app devs engaging closely with this.

a few things really jumped out at me while writing...

...hope everyone likes marquees, midis on autoplay, and friday deploys

ah, strange! is there any code you can share? i'd be curious to learn what process is taking place when you restore the session. typically i would expect it to be a local lookup of the user's credentials. on occasion it may perform a token refresh too, but this is the same as in the legacy system.

we've rolled out some small changes to the DID PLC directory which make it possible to register new key types as verificationMethod entries, for non-atproto use cases.

(this does not impact the PLC rotation key mechanism itself; that is still limited to P-256 and K-256)

have fun building on PLC!

it's the second part that makes it hard: the secret would need to be the same for the app running in your browser and the app running in my browser. the goal is for all instances of the app (e.g. in each of our browsers) to be able to authenticate itself as a single client, with a single client id.

yeah good q! the issue isn't crypto in the browser so much as it is the fact that there's no way for a browser-based app to keep a credential secret. the credential needs to be shared by all instances of the client, e.g. both when it appears in your browser and when it appears in my browser.