Wanted to say a quick hello as I’ve just joined the BSky team to do DevRel as of this week. I’m Alex, I’ve been in commercial open source and video archiving communities for some years, and I’ve even run my own Discourse server in the past and so have an appreciation for the admin community here
Please grab my attention for anything you’d like to see us document [better], any collaboration ideas you might have, or general BSky/ATProto feedback, either here or at @alex.bsky.team on Bluesky. Nice to meet you all!
Yes, please, the introspection URL mentioned on https://bsky.social/.well-known/oauth-authorisation-server doesn’t appear to do much, just like it doesn’t on the stock Typescript-based PDS, used by folks who want to self-host either. And speaking of self-hosted PDSes, they don’t provide any JWK keys to verify access tokens; only bluesky.social does that for the Bluesky PDS fleet.
If this could be documented or reviewed by the team, that would be ace!
Welcome Alex! Glad to have you and the BSky team drop in.
I think the possible backlog of collaboration is probably quite long, and I was wondering if there are particular thematic areas, or efforts that y’all have underway which might help guide some of the conversation!
Docs and writing are obviously a thing that the ecosystem has been working on.
There are also many builders adding to the ATmosphere in various different ways.
It might even be helpful to talk about where you’re focused, Bluesky stuff? ATProto stuff? A mix of the both?
Anyway, very nice to have you, we’re excited to get to chat more about the ecosystem!
That pull request allows asymmetrical JWT keys, such that you can build your own entryway server. I have another PR with a very minimal implementation of an entryway server.
Howdy Alex! Great to have a focused devrel contact on the bluesky team at last.
In anticipation of the “1.0 moment” described in the recent blog post, there are documentation and conventions not yet defined that are different for atproto that what devs off the street are used to. We need to make it as easy as possible to build with atproto. One example: login. Atproto login fields really only need a handle input and a go button, everything else happens on the PDS Oauth page. What should the text next to that handle input say? Log in with Atmosphere? Log in with ATproto? Log in with Bluesky? (I think no, but the placeholder could be a .bsky.social handle).
We the community I am sure would be happy to discuss what target use cases / developer archetypes to target and how best to make it easy for them to choose ATproto.
There are indeed many builders adding to the ATmosphere in different ways! My calendar is already filling up next week — I’m blocking out time to talk with @bmann.ca about next year’s Atmosphere conference, and to maybe figure out a way of streaming with @iame.li and talking more about video support in ATProto/BSky. Feel free to book into my calendar if you ever want some 1:1 voice/video time!
And yeah, a mix of Bluesky and ATProto stuff. Medium-term, we’d like to bring the docs closer together, but we have an SDK revamp and lots of other stuff happening on the way there. Exciting times!
As for my video archiving work — I used to be a working librarian/archivist, and just gave a talk at No Time to Wait (not ATProto-related) last week, recordings should be up soon!
Couldn’t agree more — as we revise our docs IA, I’m also going to try to publish some canonical “Concept” pages for how we handle DNS/handles, PDSes, etc.
Will be prioritizing this over the coming weeks, stay tuned.
I heard legends of a new TypeScript SDK and I’m very much looking forward to having some of the rough edges of lex-cli smoothed out or at least documented. Hope you have a great time and experience with the ATproto dev community, it’s a fun one
This is the way. I never understood why you have to enter in the domain of your PDS if that’s… in the DID doc… and the site you’re logging into has a searchable cache of all known DID Docs, including their services property and alsoKnownAs property… isn’t the domain all you need to figure out which PDS to go knock on?
Oh, and sorry for dragging us further down the rabbit hole, @alex.bsky.team , welcome to the ADHD hivemind that is this community! I work in a slight devrel-adjacent capacity on the https://dasl.ing stuff, so once you’ve got landlegs under you feel free to reach out on, e.g., bsky DMs with any questions about that can of worms.
In Oauth world, access & refresh tokens should always be considered opaque and should never be read by clients. OIDC has identity tokens (id_token) which *are* meant to be decoded (and verified) by clients. But atproto oauth does not support OIDC (as it is not possible to be compatible with the current OIDC spec given the distributed nature of atproto).
