Bluesky Control Panel (Independent Publisher) #3711
Conversation
…nts requiring their own connector separate from app.bsky
krautrocker
changed the title
|
1.) Validation via paconn happens tomorrow. There's a few errors around schema and missing elements but nothing fatal. Clean-up. 2.) With the help of @troystaylor, we can confirm that two connectors are necessary - one for app.bsky endpoints and this connector for all other endpoints (ATProto, admin, chat, tools, if memory serves). 3.) For reference: https://github.com/bluesky-social/bsky-docs/blob/main/atproto-openapi-types/spec/api.json Though this did require some reworking, such as removing "const" from all (70+) connectors, which brings the total up to over 100 when counting the app.bsky endpoints. Feel free to contact me around contributing and maintaining. Lots going on here! =) |
|
@microsoft-github-policy-service agree company="Dan Romano aka IDR, Inc. dba SWOLCAT" |
- Added additional endpoints using docs as reference - Comprehensive but non-exhaustive list of endpoints and descriptions added to readme.md
|
Hello @krautrocker, Is this PR ready for review? if yes, kindly remove gitingore and checkin to the root folder. Also remove the Proposal word from the PR title.
|
krautrocker
changed the title
Delete .gitignore
- Validated with paconn, no errors
- Updated readme - Validated with paconn, no errors - Moved global definitions position Ready to test with a client and secret.
There was a problem hiding this comment.
Ready to test, but a few housekeeping items do remain. This PR is indeed different from this other PR #3711 but may merge the branches.
- Added connection parameters to apiProperties - Added policy templates to apiProperties - Validated with paconn, no errors
|
Three successful tests: 1.) Create Session
2.) Describe Server
3.) Check Account Status
|
|
Three actions working in a flow:
|
|
Reflecting on the past week of work. A heckuva lot has been done and I'm working to make connector definitions line up to the API definitions. 1.) Endpoints require QA. I burned through these to get us on the beach. Now, I need to go through the catalogue and conduct a good QA. This will involve the Bluesky OpenAPI definition file, though the definition will need to be modified to work in the connector (components vs security definitions, for example). Responses are present for success and failures. Defaults may need to be added to some endpoints. 2.) apiProperties feature connection parameters and policy templates. Params and templates help us authenticate and operate consistently across the many endpoints. No repeats or manual intervention necessary by using these. 3.) Two connectors...or all-in-one? The OpenAPI definition from Bluesky is quite large, but both the Bluesky Social and Control Panel connectors have global definitions (security, error responses, etc.), which reduces the size of the connector. Still, I'm not sure if all the endpoints can fit into one while not exceeding the size limit. If they don't breach the limit, then we have an opportunity for a single connector. 4.) Authentication Some back and forth here on what works and what doesn't. OAuth abandoned for now and tokens have taken the lead. Query string is also a possibility, and though it may theoretically work, this doesn't seem ideal. /**/ More tomorrow. Stay tuned. |
When submitting a connector, please make sure that you follow the requirements below, otherwise your PR might be rejected. We want to make you have a well-built connector, a smooth certification experience, and your users are happy :)
If this is your first time submitting to GitHub and you need some help, please sign up for this session.
apiDefinition.swagger.json, by runningpaconn validatecommand.apiProperties.jsonhas a valid brand color and doesn't use an invalid brand color,#007ee5or#ffffff. If this is an independent publisher connector, I confirm that I am not submitting a connector icon.If you are an Independent Publisher, you must also attest to the following to ensure a smooth publishing process: