|
|
|
|
|
by zimpenfish
646 days ago
|
|
From what I've seen, Mastodon sticks to the spec but a lot of clients and servers then stick to Mastodon's interpretation of the spec rather than the spec. e.g. for status IDs, the spec says "String (cast from an integer but not guaranteed to be a number)", Mastodon uses numerical IDs, some clients[1] see this as "Ah, IDs are numbers!" and break horribly when they're not numerically parseable (Akkoma, Pleroma, GotoSocial...) (IIRC there was another thing where `created_at` is described as "The date when this status was created" but the type is given as "String (ISO 8601 Datetime)" which led some code to crash when Mastodon started outputting just dates instead of datetimes.) [1] Including some from people who Really Should Know Better. |
|
I'm currently implementing parts of the spec, and there are parts (like fully handling context correctly) that feels like far more pain than it is worth vs. just handling occasional breakage.
It feels like a very ivory tower spec of the kind you wouldn't be likely to write if you built a complete reference implementation first.
But it's very on-brand as a W3C spec.
I'd love to see a revision that deprecates and simplifies a whole lot of things.