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.

@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?..

@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.

@tootapp @lain @Gargron @WAHa_06x36 could you... decode this number? It's still a number, right?

@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.
Show more
Show more

@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...
@tootapp @WAHa_06x36 @Gargron @charlag @lain as mentioned repeatedly yesterday, that “assumption” isn’t expressed anywhere in the api spec.

Pleromas FlakeIDs are in accordance with the PUBLISHED SPEC.
Toot!s usage of the ids is not.
@tootapp @Gargron @WAHa_06x36 @lain @charlag and pleromas implementation is STILL in compliance with that.

If the grand high ninky nonk wanted that to be an integer, then he should have noted that this was an integer.

@dgold Not any longer, as the docs have been updated to be specific about this:

@dgold Updated again now:

"All IDs are encoded as string representations of integers"

@tootapp right there under ‘status’

id String 0.1.0

And in reply:

reply_to_id. String

@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.

@Gargron @tootapp @WAHa_06x36 @lain @charlag it’s what you have published as a guide to interacting with servers running your software.

What would you like app developers to work off?
Sign in to participate in the conversation

Follow friends and discover new ones. Publish anything you want: links, pictures, text, video. This server is run by the main developers of the Mastodon project. Everyone is welcome as long as you follow our code of conduct!