Other than being cleaner, it has some other benefits:
- Better error messaging when providing the wrong DID in the proxy
- The appview service would be discoverable on the protocol (right now did:web:app.bsky.app doesn't even exist), making it easier for a client to swap between appviews
- Better error messaging when providing the wrong DID in the proxy
- The appview service would be discoverable on the protocol (right now did:web:app.bsky.app doesn't even exist), making it easier for a client to swap between appviews
Comments
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)
@bnewbold.net thoughts?
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
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