最近の検索
検索オプション
Pleroma users should be aware that Pleroma has introduced breaking changes in their implementation of the Mastodon client API, which mean Toot! will no longer work at all with the latest version of Pleroma.
Pleroma is breaking some fundamental assumptions Toot! makes about IDs, and which can't easily be changed.
@tootapp What are they changing?
@WAHa_06x36 @tootapp What are they then? Mastodon sends its IDs as strings too because of JSON integer overflow
@lain @Gargron @tootapp @WAHa_06x36 if they're still sortable as strings, Tusky will work just fine. Not sure why it should break any other client. Does anyone really convert them to integers?..
@lain @charlag @Gargron @WAHa_06x36 Except Toot!, because you broke a core assumption of the Mastodon client API that I am relying on.
Pleromas FlakeIDs are in accordance with the PUBLISHED SPEC.
Toot!s usage of the ids is not.
@dgold @charlag @lain @WAHa_06x36 @tootapp The Mastodon documentation is not a spec and the Mastodon REST API is intended for Mastodon's internal use, not as a client-to-server standard.
@shadowfacts @charlag @WAHa_06x36 @dgold @lain @tootapp I consider Mastodon apps to be part of the Mastodon ecosystem. I do not see why you need to pretend to have misunderstood me, when it is obvious that the Mastodon REST API was not intended to be the Pleroma REST API or Pixelfed REST API.
@Gargron @shadowfacts @WAHa_06x36 @dgold @lain @tootapp I'm sorry but if you're saying that so that no one blames you for not documenting that then it is a wasted effort. There are multiple parties and different people assumed different things about implicit contracts. If Mastodon would change their ids, apps could break in absolutely the same way because it's not documented. You're not obliged to provide API for Pleroma, Pleroma is not obliged to follow it.
@charlag @Gargron @shadowfacts @WAHa_06x36 @dgold @lain The thing here is, the Mastodon API provides more than what is mentioned in the docs. That means the docs are not enough to remove-implement the API, but they are enough to consume the API.
@lain @charlag @Gargron @tootapp @WAHa_06x36 @dgold @shadowfacts You should have cooperated with more application developers. This situation could be avoided if hearing with the application developer in advance rather than trusting only insufficient documents.
@miya @charlag @dgold @tootapp @WAHa_06x36 @lain @Gargron @shadowfacts
We have never expressed Pleroma support, then so the frequency of looking at Pleroma's community is very low. https://mastodon.juggler.jp/@tateisu/101436082701177563
Nice change to the documentation there, you pair of spiteful maggots.
Is there any reason you’ve done that, other that just to win the Most Monumental Asshats of the Day Award? Do you think this is all some sort of game, that you just happen to be playing?
Are there other developers who get the royal we treatment, or is that just for @WAHa_06x36?
Cruciatus in crucem. Eas in crucem!
@shadowfacts @lain @WAHa_06x36 @tootapp @charlag @miya
@dgold @lain @miya @charlag @WAHa_06x36 @tootapp @shadowfacts @Gargron You should not use the API document as a disclaimer to force app developers to respond.
The API document is originally intended to make an application using the API. We do not generate IDs by the application, so it usually is not necessary to describe how the ID should be generated.
I'm concerned that we're talking past each other, so please forgive any misunderstanding.
One shouldn't use an API document to query developers use of something not in the API document? That's what API documents are *for* - setting out the methods of using the API.
Why have *you* changed the entire API documentation to reflect the choices made **by one developer**?? This wasn't the case yesterday, this was done by *you*.
Yes, you don't generate IDs by the application - but other server implementations can create IDs in accordance with your API to facilitate interoperability. Mastodon isn't the sole member of the Fediverse, its just one. Other servers have implemented this API to ensure the widest availability of clients. Why have you changed your API, without discussion or rationale, to ignore those other servers and deny their users cross compatibility with your API?
@Gargron @lain @shadowfacts
@dgold @lain @shadowfacts @Gargron
The Mastodon API document is not intended to create compatible APIs. It is intended to create an application using Mastodon's API.
After seeing your(s) point of view, I felt "part of the information necessary for creating the application is undocumented", so I provided a short 1-line PR.
I just revealed the undocumented part, so I think that there are no Mastodon applications whose implementation will be changed by this PR.
@tateisu @dgold @lain @shadowfacts Maybe someone from Pleroma should've gotten in touch with me before the decision was made so we could have a discussion. Surely even just encoding your 128-bit IDs in base-10 would be better than base-62 for compatibility. Mastodon and Pleroma now both use snowflake IDs, but why 128-bit over 64, when that is plenty enough? Now it's too late and we have to scramble to untangle the situation while app devs receive abuse from Pleroma users...
@tateisu@mastodon.juggler.jp@Gargron @dgold @lain @shadowfacts
However, in reality, there are only two options: "Pleroma withdraws breaking ID modification" or "support for Pleroma ID by application developer (who not saying support for Pleroma)"
If they keep singing "Mastodon API compatible" without retracting anything, that would be bad news for app developers.