Rolling this out probably requires careful sequencing 1. Publish a did doc for did:web:api.bsky.app with a bsky_appview service definition 2. Update the bsky app to add the atproto-proxy header to relevant requests (probably requires changes to lex-cli and @atproto/ packages) - ThreadSky

tom.sherman.is • 5 days ago

Rolling this out probably requires careful sequencing

1. Publish a did doc for did:web:api.bsky.app with a bsky_appview service definition
2. Update the bsky app to add the atproto-proxy header to relevant requests (probably requires changes to lex-cli and @atproto/ packages)

Comments

tom.sherman.is•5 days ago

3. Eventually remove support for this fall through routing within the PDS (when all clients have updated to be passing the appropriate header)

@bnewbold.net thoughts?

divy.zone•5 days ago

yeah, that's all well-outlined. has not been widely advertised, but clients _can_ use our appview in exactly this way today by service proxying to did:web:api.bsky.app#bsky_appview. check it out: https://api.bsky.app/.well-known/did.json

tom.sherman.is•5 days ago

Ah, nice. Didn't realise the did:web already existed

I might raise a PR to the bsky client to add this header in, then - being explicit would be nice and allow for third party implementations to skip implementing this fall through and continue to be able to use https://bsky.app

bnewbold.net•5 days ago

yup, your overall take is about right.

the did:web was only set up in the past month or two.

it has been convenient/simple in some ways to have the app.bsky.* lexicons "auto-route", but I think that "special magic" is/has become more confusing over time

bnewbold.net•5 days ago

a related "magic" we need to deprecate is having 'bsky.social' (the entryway) forward/route some endpoints.

I suspect the PR against social-app might be... big? but i'm not sure, and needs to happen at some point

bnewbold.net•5 days ago

we are not planning to make the appview end-user configurable in the version of the app that we run in prod, fwiw. we would expect folks to use different branding in the app if they chose an alternative. a bit on us to help whitelabel the app by default

tom.sherman.is•5 days ago

Yeah I was just trying to think through how you'd do it, I dunno if there's a better way than having a big list of all of the AppView routes 😅 altho I suppose maybe you could route add the AppView did service when you see a app.bsky prefixed NSID in the http client

tom.sherman.is•5 days ago

cc @retr0.id

pfrazee.com•5 days ago

longterm I want us to move away from the pds-proxy model and into the oauth flow that has the server handle all communication with the pds

right now we have to hardcode some business logic in the PDS to provide "ready sticky" behavior, which aint great

pfrazee.com•5 days ago

read sticky*

Comments

Posting Rules

Reply