Follow

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.

@WAHa_06x36 @tootapp What are they then? Mastodon sends its IDs as strings too because of JSON integer overflow

@WAHa_06x36 @tootapp Is that basically UUIDs? I suppose that really fucks with the ability to calculate toot gaps (although it should still be possible with more effort if their API responses include next/prev links)

That being said, the Mastodon REST API was never intended to be used by anything but Mastodon, so maybe it's a good thing.

@Gargron @WAHa_06x36 Just their own completely custom format. I think it's the same type of snowflake ID, just with more bits.

Why on earth this would be necessary I don't know.

@Gargron @WAHa_06x36 @tootapp Then why not let people take a stab at creating a working "S" for the C2S part of ActivityPub in Mastodon?

@Gargron @tootapp Also, I filed a PR to the docs to clarify this as they don’t mention it, which seems to be how they thought this would work.

@Gargron @tootapp @WAHa_06x36 mastodon ids are sortable strings, new pleroma ids (flake ids) are sortable strings. I think if apps stop working they made assumptions that aren't valid according to the mastodon api docs.

@lain @tootapp @WAHa_06x36 If I understand correctly, the difference is in the encoding. Mastodon IDs are numeric in nature, so you can treat them as a big integer.

@Gargron @WAHa_06x36 @tootapp judging from the documented API this is incidental. It's unfortunate that some clients rely on this behaviour, but many don't, so I don't think it's too hard to fix if an app wants to support it.

@lain @Gargron @WAHa_06x36 Mastodon ids are 64-bit integers, represented as strings.

@charlag Custom hash table database, as no existing solution worked without massive bloat.

@lain @charlag @Gargron @WAHa_06x36 Except Toot!, because you broke a core assumption of the Mastodon client API that I am relying on.

@charlag @lain @Gargron @WAHa_06x36 It’s too big to fit the hash table, and of course I have no guarantee Pleroma won’t just change its mind again.

@lain @charlag @Gargron @WAHa_06x36 I did check with Eugen that this is what is intended, and will remain the case for the foreseeable future.

@tootapp @WAHa_06x36 @Gargron @charlag yeah, it's unfortunate. I wish it could be otherwise, but these changes were necessary long term and are (as far as I can tell) still valid according to Mastodon docs.

@lain @charlag @Gargron @WAHa_06x36 Why though? 64 bit is enough for Mastodon, why not for you? There was no problem before, but now you have introduced one.

@lain @charlag @Gargron @WAHa_06x36 The only way Toot will ever work with Pleroma again is if you have a mapping back to 64 bits, though, or if you get back to being compatible with the API as it exists in Mastodon.

@tootapp @WAHa_06x36 @Gargron @charlag sure, you don't have to change your app, but we'll not switch back the ids.
@tootapp @lain @charlag @Gargron @WAHa_06x36

that's not really a problem: the apps we recommend people use are the ones we have certified as compatible anyway. we have never certified Toot as a Pleroma-compatible app precisely because of this attitude ;)

@DarckCrystale Yes. Looking into whether the mapping idea is feasible now.

@tootapp @lain @charlag @Gargron @WAHa_06x36 To be clear we are already compatible with the Mastodon API. Gargron previously stated several times that IDs are not integers, they are strings. I can dig up the toots again if you want, or you can look at his commentary in the Snowflake pull request for Mastodon, or various other clues that it's not an integer.
@WAHa_06x36 sorry but no, you can't say "oh it's a string but treat it as an integer".

It's either a string or it's not. Anything else are assumptions and badly designed software, broken code.

It's a string.

See those quotes?

{
"id": "101330783379224338",
"created_at": "2018-12-30T15:50:49.150Z",

It's a string.
@feld @WAHa_06x36 Note also that "created_at" is documented as "String (Datetime)"

"id" is documented as "String".
@WAHa_06x36 @feld If there's no spec, and vague documentation, stick to what the documentation says. All the rest would be betting on unspecified and undocumented implementation behaviour.

@href @feld I am sticking to what I have asked the devs, and had them confirm.

@WAHa_06x36 @feld They didn't confirm enough to document it. No one's perfect, stick to what the docs says. Eugen could get hit by a bus and remplaced by another BDFL who changes them.

Once it's in the docs, it's written and acted. You can trust this and only this.

@href @feld You are still treating the docs as if they are a spec. They are not.

@feld Are you saying the deva don’t know what their own code actually does?

@tootapp or you could just stringsort i mean really where's the hard part
@tootapp Well... that just seems you had way too much fun overengineering that part :p most people aren't going to handle more notices at a time than their JS-bound frontends...
@charlag @WAHa_06x36 @tootapp @Gargron @lain Tusky works just fine indeed, I'm sending this from it rn with the flake ids backend

@lain Also, Mastodon IDs are *not* sortable strings, they are sortable integers, represented as strings. "9" < "10" in the Mastodon API, which is not true for regular string comparison.

@tootapp sure, but i thought they all have the same character length and don't just start with 1.

@lain They don't. They are are represented as regular integers, as far as I know. Comparing them as strings is wrong.

@tootapp right, now Toot! can't be used at all to connect to pleroma instances.

@tootapp @jk I know you've been looking at building an instance, would you have been keeping this in mind?

@OldBrushNewPaper @tootapp I've had a pleroma instance for about a month and shutdown my mastodon instance last week.. never heard of toot and have no issues with tusky.
Sign in to participate in the conversation
Mastodon

Server run by the main developers of the project 🐘 It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!