mastodon integration is forgotten instantly

[tastytea]

Describe the bug

i can add a mastodon API connection, it looks like it succeeded, the access token is visible on my instance.

but träwelling instantly forgets it exists and shows it as not connected. it worked up until recently, i think the last time i used it was 2-3 weeks ago?

i'm using sharkey 2024.3.3

Steps to reproduce

1. go to https://traewelling.de/settings/security/login-providers
2. connect to sharkey instance
3. try to post a new status
4. look at https://traewelling.de/settings/security/login-providers again to see that the integration is disconnected

Browser console logs

No response

Browser

firefox 127.0.1

[MrKrisKrisu]

We currently only support "real" mastodon connections.
See #2560

[CutestNekoAqua]

We currently only support "real" mastodon connections. See #2560

This seems to be a different issue and it seems to be resulting in your commit from 3 weeks ago. Having the same issue on akkoma. Seems to be a issue with Traewelling requesting things out of scope I think?
I wrote the original Calckey Mastodon API and tested it against traewelling. Removing connections just because some instances return a 401 error that aren't official Mastodon instances doesn't seem like the right approach.

Additionally, all random instance errors while fetching an instance are being classified as "not a Mastodon instance," which gives the impression that all internal Traewelling errors on the API side are being labeled with an "official Mastodon only" policy.

There's a small difference between supporting Mastodon and supporting the Mastodon API. As a Mastodon-compatible software developer, I'd suggest focusing on supporting the API rather than just the official Mastodon instances. Otherwise, there is a risk of alienating a significant portion of users that would have loved the platform otherwise. That, I would not count as the spirit, FOSS software should life in.

[HerrLevin]

I think the main problem is that we're currently using a library, that's tailored to mastodon itself and not the Mastodon API.

But I'm not entirely sure why removing accounts from an instance that returns a 401 is not adhering to the official documentation. As mentioned here, the instance returns a 401 when the API requires an authenticated user. Since we're requesting the account data with the credentials of the account itself, we have to assume, that our credentials for the API were revoked. (This is mostly a fallback for us because we had this exact situation, that some instances returned 401 and users couldn't recreate their API token, etc.)

Please let me know if the above mentioned API is not the one you meant or if I'm misinterpreting the documentation here. I'm fine with using only 404/410 for account removal, if that extends our compatibility.

[tastytea]

i made a bug report to Sharkey: https://activitypub.software/TransFem-org/Sharkey/-/issues/574.

[CutestNekoAqua]

I think the main problem is that we're currently using a library, that's tailored to mastodon itself and not the Mastodon API.

But I'm not entirely sure why removing accounts from an instance that returns a 401 is not adhering to the official documentation. As mentioned here, the instance returns a 401 when the API requires an authenticated user. Since we're requesting the account data with the credentials of the account itself, we have to assume, that our credentials for the API were revoked. (This is mostly a fallback for us because we had this exact situation, that some instances returned 401 and users couldn't recreate their API token, etc.)

Please let me know if the above mentioned API is not the one you meant or if I'm misinterpreting the documentation here. I'm fine with using only 404/410 for account removal, if that extends our compatibility.

no in this case its a issue of "401 can be returned when there was a issue while making the request" which is different from "this api key i got is invalid". :)

[HerrLevin]

no in this case its a issue of "401 can be returned when there was a issue while making the request" which is different from "this api key i got is invalid". :)

Can you point me to the location where the documentation states this behavior? I can't find it and this sounds more like 400 to me. 🫣