Sketching com.atproto.server.createActorAuth

[dholms.xyz]

Hey y’all, chatted with with @ngerakines.me for a few minutes this morning. Sounds like my response came off more aggro than I intended it. I’m sorry, I didn’t mean to be aggressive or dismissive of the proposals here. My intention was just to give a sense of my considerations when weighing these options.

The biggest is that this is just at a different layer of the stack than the Atmosphere Groups lexicon standard that we’re working on in the working group. Which is not to say that it isn’t relevant to it. But it requires a new protocol mechanism, and that process is quite a bit more involved and moves more slowly. I’m worried about making that work a dependency for the Atmosphere Groups work.

I really appreciate the on-the-ground feedback on the need for this. And to be clear I’m not pushing back against the need for account delegation! As I mentioned, it’s probably the thing I’m most interested in working on from a protocol perspective after spaces are out!

---

Couple quick responses to posts since then:

@nel.pet

In Tranquil “delegated accounts” are accounts where the OAuth login method isn’t a password or a passkey or the like but rather a nested OAuth session with another atproto account that is one of the defined “controllers”.

Wow thanks for sharing! I actually didn’t realize that Tranquil had this feature. But this is basically exactly what I’m proposing we do for Atmosphere Groups! Does it work cross-PDS? As @nel.pet says, this has the big advantage of Just Working without any required extra machinery. I’d be interested in any other learnings you’ve had from this or rough edges that you’ve run into. I’ll definitely be taking a look at what Tranquil has done.

@zicklag.dev

I feel like if this were the situation, that Roomy would quite possibly just opt for the opaque “Perform any action on your Roomy communities” permission on the OAuth consent screen and continue to use XRPC “proxying” to allow users to take any action authorized for their account under the community.

I need to know more about Roomy’s particular setup. But if these are Roomy XRPCs, then you can wrap them up in permission sets that define the different levels of access.

@lou.gg

A delegation token, issued by the community PDS itself, would remedy a whole chunk of this. Instead of, on every write request, needing to check if the user is authorized to do a thing, then getting the session, potentially refreshing a token, then writing the record for the user, we could simply tell the PDS that the user is allowed to write a certain type of record in a certain location, then be done with it.

Another relevant thing that we want to do is add developer API tokens that you can create to control an account programatically. These would be more like standard API tokens that you’re used to using in SDKs, but they would encode OAuth scopes and would be long-lived and not need all that refresh logic. That’s actually a much much lower lift from a protocol perspective. If the main issue is wrangling session refreshes, this may be able to help in the shorter term