Some clients not supported

[penalosa]

I imagine this is known, but to list some that I've tried which don't work:

• https://mastodon.social/@MonaApp/109506252875971252 (fails to log in)
• https://mastodon.cloud/@icecubesapp (shows an "instance not supported" message)

[xtuc]

Have you tried again since? We did many changes to support other clients.

[riaf]

I was interested in this issue so I did a little bit of research on IceCubesApp. I noticed that the "instance not supported" message is no longer there, but the sign in button was still not active. I think this issue can be resolved by adding the "configuration" attribute to the /api/v1/instance, as I was able to proceed further by adding that attribute in my repository (although the data was not correct, though haha).

However, I have not thoroughly investigated the internal yet, but it seems that the POST request to /api/v1/apps is being sent as a form instead of JSON and the Content-Type is missing from the request header, causing it to not be handled correctly.

So, I think that fixing this issue may require both modifications in the wildebeest project and in each of the client apps.

[riaf]

Sorry for forgetting to report this. I just realized that IceCubesApp cannot handle the response from a POST request to /api/v1/apps correctly because there is no id attribute in the response.

[DataDrivenMD]

I can confirm that IceCubes app remains incompatible. The problem seems to stem from an incomplete implementation of the GET /api/v2/instance endpoint (as previously mentioned by @riaf). The app hangs while trying to retrieve the instance metadata, though it's not entirely clear which attributes it needs to proceed.

In any case, once that roadblock is cleared, I expect that we'll hit this other roadblock I filed under issue #253

[bretcarmichael]

Ivory for iOS by Tapbots is also incompatible. After authentication, when authorized permissions, a message is returned that it (Wildebeest) is not a Mastodon server.

[DataDrivenMD]

I reached out to the Tapbots team to ask how they determine whether the server is Mastodon-compatible. Awaiting their response.

[DataDrivenMD]

Heard back from the Tapbots team. They said they require post/statuses/toots to have numerical IDs. Wildebeest uses UUIDs.

Separately, while digging into the issue, I noticed that Wildebeest uses the ActivityPub URI as the Mastodon account number. Clients that expect an integer value are going to reject this, too.

I'm not sure there's an easy fix to the incompatibilities we're uncovering because the underlying data model conflates two namespaces: ActivityPub and Mastodon. In fact, several Mastodon-specific properties are hard-coded into ActivityPub (AP) typescript interfaces. There are also several Mastodon-required AP types missing from the code base (that's why polling doesn't work).

Digging even deeper, the AP type Link extends APObject, but the W3C spec explicit defines these types as disjoint because Link is semantically distinct. From a performance standpoint, Link (and by extension Mention) are tiny compared to APObject. It makes me wonder if the "Worker exceeded resources" errors are, in part, due to wasteful resource allocation stemming erroneous type inheritence

@xtuc - there's a lot of work left to do in order to assert that Wildebeest is Mastodon-compatible. Not sure how you want to proceed, and it would be helpful to get a better sense for Cloudflare's roadmap for this specific project.

[xtuc]

Thanks for digging into it @DataDrivenMD .

They said they require post/statuses/toots to have numerical IDs. Wildebeest uses UUIDs.

The Mastodon documentation is clear about ID being String (cast from an integer but not guaranteed to be a number). It's perfectly valid for Wildebeest to use UUIDs, official Mastodon apps are able to use any format of ID (that said, this is not true for the notification endpoint on iOS which is a violation of their own spec).

Clients that expect an integer value are going to reject this, too.

Ivory also assumes ID are integers ,by the way, that's why it's breaking at the moment. The author is aware of the issue.

In fact, several Mastodon-specific properties are hard-coded into ActivityPub (AP) typescript interfaces.

Mastodon is layered on top of ActivityPub for simplicity. Specific Mastodon infos are handled by dedicated D1 tables. Feel free to open specific issues for confusion between Mastodon and ActivityPub in types.

There are also several Mastodon-required AP types missing from the code base (that's why polling doesn't work).

Wildebeest is fairly new and we have missing features. Feel free to open specific issues too so we can implement them.

the AP type Link extends APObject

I haven't checked in the spec but that sounds like a mistake. Should be relatively easy to fix I think.

It makes me wonder if the "Worker exceeded resources" errors are, in part, due to wasteful resource allocation stemming erroneous type inheritence

I don't think so but I haven't traced the worker to be sure. Wildebeest doesn't hold many APObject in memory, so I expect the difference in structure size to be insignificant.

Edit: I wrote this comment before seeing all your PRs, thanks for the help!

[DataDrivenMD]

@xtuc No worries. The asynchronous communication across several issues & PRs makes it a bit challenging to collaborate on a project of this complexity. I'm aware of the #Wildebeest Discourse channel within the CF Discourse server-- it would be helpful to know when you (or others on the CF team working on Wildebeest) will be logged into the CF Discourse channel to flesh out some of the lingering questions in a (slightly more) synchronous medium

[xtuc]

@DataDrivenMD sure, feel free to reach out on Discord. My username should be sven.

[celso]

We've been fixing issues and adjusting the APIs to improve client compatibility. Elk and Mammoth are now working, and we fixed a few issues on Mastodon for iOS.

The docs have a detailed list now:

https://github.com/cloudflare/wildebeest/blob/main/docs/supported-clients.md