Currently impossible to get a user's own account

[bocops]

Some of our account-related methods, namely verifyCredentials() and updateCredentials(), return a CredentialAccount instead of an Account since the last snapshot release.

In our code, these entities are completely separate out of necessity (inheritance and data classes don't mix well), although Mastodon does not make this distinction. While some parts of the documentation specifically mention a "CredentialAccount" entity, others refer to the returned data as "an Account entity, with the source parameter included" (example: https://docs.joinmastodon.org/client/authorized/).

There doesn't seem to be any other way to retrieve the user's own account other than using verifyCredentials(), so I'd argue that this function is really meant to be used that way, and we either shouldn't return a completely different entity, or at least offer some way of getting an Account from the returned CredentialAccount. Potential ways to do this include:

• add a nullable source to Account and get rid of the separate CredentialAccount
• add a separate function (e.g. getOwnAccount()) that internally still calls verifyCredentials() but returns data as an Account (or possibly Account? if credentials can not be verified)
• add a utility function that accepts a CredentialAccount and returns an Account

[PattaFeuFeu]

@bocops How do you feel about having CredentialAccount extend Account? You write “inheritance and data classes don't mix well”, but which part specifically do you mean?

[bocops]

Extending data classes is not possible in Kotlin, so we couldn't for example declare data class CredentialAccount(...) : Account(...) and then later just cast to get the user's own account as a simple Account.

[PattaFeuFeu]

Ah, wow, I had totally forgotten about that again. 😕

How do you feel about this approach? Not great, but could be an option?

[bocops]

If we do that, and considering that we (currently) use both Account and CredentialAccount as entities, wouldn't we need to do something like this?

abstract class AccountData {
    // ....
}

data class Account () : AccountData()

data class CredentialAccount(
    // additional data
) : AccountData()

And if we do that, it would still not be trivial to get an Account if the returned entity is a CredentialAccount, and vice versa.

For what it's worth, my own use case is this:

/**
 * Get account data for a currently signed in user.
 */
fun getUserData() : Account? {
    var account: Account? = null
    client?.let {
        try {
            account = it.accounts.verifyCredentials().execute() // no longer compiles
        } catch (b: BigBoneRequestException) {
            Log.d("Client", "Exception verifying credentials: ${b.message}; ${b.httpStatusCode}")
        }
    }
    return account
}

I want to use the user's account data just like I would use the account data of any other user the client might see, and verifyCredentials() despite its name just seems to be the natural way to get that information. I could use getAccount(id), but then I would need to retrieve the user's id first, so would need to use verifyCredentials() anyway. Maybe Mastodon offers some other way that I'm not seeing, but at the moment their "verification" endpoint just seems to be a misnamed "user account" endpoint. ;)