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

@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 @lain @Gargron @WAHa_06x36 I do, for the cache database layer.

@tootapp l we do it as well for the same reason and I made sure that SQLite will do the thing I need.
https://github.com/tuskyapp/Tusky/blob/3ab78a19bcf9fa9212f27869805ca653d6638bfb/app/src/main/java/com/keylesspalace/tusky/db/TimelineDao.kt#L44

What do you use for such persistence?

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

@charlag @WAHa_06x36 @tootapp @Gargron yeah, they are sortable, most clients work just fine.

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

@tootapp @WAHa_06x36 @Gargron @charlag you don't have that guarantee in mastodon either...

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

@tootapp @WAHa_06x36 @Gargron @charlag mostly to annoy app developers :p real reason is here: https://git.pleroma.social/pleroma/pleroma/merge_requests/645

Tldr: scaling + privacy.

@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 ;)

@tootapp @lain @charlag @gargron @WAHa_06x36 seriously?

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

@tootapp or you could just stringsort i mean really where's the hard part

@sascha Rewriting a custom caching database layer?

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

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

@lain @tootapp

!g how to leftpad a string with zeros?