Proposal: Streamlining ATProtoKit Session Configuration for Better Usability and Flexibility

[MasterJ93]

As it stands, there does seem that there’s some difficulty with using ATProtocolConfiguration. At the same time, based on what I’m reading in terms of what people want to see, this class is going to end up getting very, very bloated, trying to do too much for too many use cases, and as a result, it will fail in all of them. I don’t like this and we need to separate things. As a result, this is what I want to do (part of this was in the works, but the following is more fleshed out).

• ATProtocolConfiguration will be only for app password-related management. This is because 1) it’s the most widely used way of logging into atproto services, and 2) OAuth in atproto is still in the early phase. Overtime, this might change, but for right now, this is how things are.

• SessionConfiguration will be the generic protocol that will ATProtoKit will accept for session management. This will have the basic things that the class will use in order to handle authentication requests. While OAuth is still being implemented, there are some who are using packages that include atproto OAuth. For that use case, I highly recommend using this protocol for the most flexibility and integrate that library with this protocol.

• The implementations for createAccount, getSession, refreshSession, resumeSession, and deleteSession will be moved over to SessionConfiguration as default implementations. ATProtocolConfiguration will use the default implementations as-is. This means that, if you don’t agree with the way it’s implemented, you can always override this with your own class, pass your class to ATProtoKit, and experience the same results.

• The helper methods will move over to the ATProtoTools class.

• One of the things that I’ve seen people have difficulty with is the UserSession struct. This was supposed to be a portable way to move properties related to the user account and it was supposed to be straightforward. Unfortunately, it seems this has caused more trouble than what it’s worth and I apologize for that. But I don’t want to lose these properties either since these can potentially be very important for developers if they need it. Therefore, I’ve opted to move them into SessionConfiguration. Now, you have direct access to them without the need to use the session method.

• There will be a new initializer. This initializer will let you pass an access token and refresh token, as well as, optionally, the URL of the Personal Data Server (PDS). The access token is optional as well if you feel you want to always have the session refreshed for every app launch. This will fix the issue where you want to pass in the tokens for each app launch.

• For security reasons, ATProtocolConfiguration will set the appPassword field to private. While the initializer will still take the password, it will only use it once. authenticate will remove it from the field when it has completed the authentication. If this is too much, however, then I could probably make it public, but it is your responsibility to set it to nil.

• ATOAuthConfiguration will still be developed, especially for those who just want something straightforward without the need for an additional dependency. But this will still take some time. I hope to have an experimental version as a separate branch in the coming weeks.

This should be it. With that said, some people may actually set like it the way it is now. For that use case, I will create another class that works a similar way to how it works now. However, it will be considered deprecated and I would encourage you to try out this new way instead.

This is something I need substantial feedback and I implore you to let me know what you think of this. Please let your voice be heard so I know what pain points that haven’t been addressed with this proposal and what seems to work for you. Thank you for taking your time in reading this.