@tootapp Would you be able to help us with compatibility with toot!? The Takahe API is mastodon-compatible and works with most clients, but toot! is showing users a blank timeline and we're not getting any errors on our end.
@tktech Hmm, I am guessing that means either missing a required field in statuses or setting an existing field to an incompatible value.
@tootapp I thought that might be the case, so I did a diff between Mastodon's /timeline/public and our /timeline/public. One thing I noticed was that Mastodon's dates were precise the the microsecond, so I tried tweaking that, no change. There are a couple optional fields that we specify that mastodon doesn't usually, but everything else _looks_ identical. toot's the only client having trouble loading the timeline at the moment :(
@tktech I tried going to look on tkte.ch but it seems I need an account?
(Also, noticed a small discrepancy: You return 400 when login is needed, while Mastodon returns 422. I was going to use that to check if you need to login to view a timeline and show a more helpful error screen.)
@tootapp Thanks for taking a look! We'll update the status code. Hm, you shouldn't need to login for the public timeline, https://f.tkte.ch/api/v1/timelines/public returns A-ok without logging into toot! Happy to make you an account for debugging. If you're up for it, we're on Discord (https://discord.gg/qvQ39tAMvf), IRC, whatever you'd like to help debug.
@tootapp Fixed that bug, the public timeline is public again :) Regarding the status code, what API endpoint are you expecting 422 from? If I hit https://mastodon.social/api/v1/timelines/home without giving it a token, I get a 401 which is what I'd expect.
@tktech "Exception during array parsing: The data couldn’t be read because it isn’t in the correct format. (Date string does not match format expected by formatter.)
Index 5 ▸ created_at", so as I suspected. Format needs to be very exact.
I am expecting 422 from https://f.tkte.ch/api/v1/timelines/public if the public timeline is not, in fact, public. That is something Mastodon supports, but if you don't, no need to worry about it. /home will never be loaded except when authenticated.
@tootapp Awesome, I've fixed timestamps on f.tkte.ch to be identical (chopping to reduce precision down to 3 digits) to Mastodon and I've added a setting to enable/disable the public timeline API and return a 422 if it's disabled. Still not seeing any results, so I'm guessing there's another field that's failing validation :(
@tktech "Exception during array parsing: The data couldn’t be read because it isn’t in the correct format. (Invalid URL string.)
Index 2 ▸ tags ▸ Index 0 ▸ url"
iOS' URL parser is also very strict. Usually this is caused by spaces in URLs, which is technically against the spec.
@tktech I can spot "url": "https://mastodon.social/@acegikmo", where the @ probably is against spec.
@tootapp Okay, this one should be fixed now. We were returning relative urls to hashtags, where it looks like Mastodon always returns absolute URLs.
For the @ in the user URL, it looks like it's okay. It's _technically_ against the spec, but the NSURL seems to parse fine and Mastodon is doing the same thing in its URL field.
@tootapp Had 2 more folks ask about Toot! today :) Bought a copy myself, very smooth UX. Excited to get this working!
@tktech All right, yeah, makes sense. Clients won’t know what relative URLs are relative against anyway so should be absolute.
@tootapp We're still not getting timelines, so we must still be failing on something else :(
A user reported this one: https://github.com/jointakahe/takahe/pull/275#issuecomment-1365281545, I'm guessing you expect the header and header_static keys to be missing completely if not set, instead of `null`? This might be worth changing on your side since I know other servers are sending null here.
@tktech Hmm, I have header and header_static down as required fields, and Mastodon sends .../missing.png if they are not filled in.
@tktech The specs have them as neither optional nor nullable: https://docs.joinmastodon.org/entities/Account/#header
@tootapp hmm so this one is toot! being stricter than the spec? I can send a temporary image for now, I'll have to create one for the header. Did you see any other errors or is this our last one on the timeline parsing?
Edit: ah! Whoops, didn't see the neither. Fix incoming!
@tootapp Alright our output is now a lot closer to mastodon.social, and I've removed a bunch of optional fields to make things easier to debug. What's the parser dying on now?
@tootapp Interesting, alrighty. My understanding was that a missing `Link` header implies that there's no next or previous page available. We'll add support for it but I'm not sure what to do in that case (what happens when a site only has a single status?) I will have to investigate.
It wasn't noticed initially because the clients tested against so far like Tusky are doing the pagination directly without using the Link header.
@tktech Yeah, doing it that way only works as long as the IDs in the actual data are sequential, which they are not in places like follower lists.
@tktech Also, there's always going to be a previous page available, because that is where newer entries would go when they appear. I think a missing next means the end of the timeline, but there should always be a previous. If both are missing that means an empty timeline, which is why Toot! will show an empty timeline in that case.
@tktech mastodon.social returns 'link: <https://mastodon.social/api/v1/timelines/public?max_id=109587048907649843>; rel="next", <https://mastodon.social/api/v1/timelines/public?min_id=109587049292283879>; rel="prev"', when I tried it now.