Pleroma users send complaints verging on extremely rude to Mastodon app devs, justify it with the fact that Mastodon documentation only specifies IDs being encoded as strings in JSON, not that they are in base 10 or 64 bit. I posit that the Mastodon API documentation is descriptive rather then prescriptive, and the API was never intended to be implemented by non-Mastodon software, and therefore prior assumptions of app devs based on Mastodon API's observable behaviour were not wrong. (2/2)
It is regrettable that I was only notified about this after the ID change already took place, because we could have clarified things and involved the Mastodon app devs, and have some say in the matter.
Now clarifying an already existing API of ours would be exclusionary towards Pleroma. If you heard about our documentation changing to specify IDs as 64 bit numbers yesterday, it has been changed again today afternoon to keep Pleroma compatible.
@gargron "app devs are definitely not to blame here"
making assumptions about an API is totally not the assumer's fault, not at all
@a_breakin_glass I made assumptions, which I checked with Eugen and the Mastodon devs, and they confirmed they were good and intended assumptions.
@WAHa_06x36 but it still isn't a reliable assumption
@a_breakin_glass But it is. It is now also documented.
@WAHa_06x36 not currently
@WAHa_06x36 it doesn't specify the base and so on, though
@a_breakin_glass That's just being intentionally obtuse.
@WAHa_06x36 how? the type of integer encoded by the string isn't specified
@Gargron this is why I pull from master...
@Xyc0 Not sure what you mean to be honest! Do you pull the docs from master?
@Gargron for my pleroma instance.
I have no idea how they do releases but one dev branch merge broke things.
oh geez this sounds like a giant mess.
@Gargron I would never assume an ID string in JSON would ever be a 64 bit number. Twitter went string in their ID (unfortunately they had to have id_string, because they were dumb when they first came out and used a 32 bit number on the key "id"). Also, due to JSON's idiocy on number overflow, a string is best. If someone made an assumption on their client, that is their issue, not Mastodon's, IMHO.
@Gargron "the API was never intended to be implemented by non-Mastodon software"
that says it all; no blame/anger is justified.
Long post Show more
@kaniini @WAHa_06x36 hey, I'm not sure why you replied that, there were really some random rude people coming out of nowhere. Not saying it's your fault or anything but I've personally banned some people.
GPL is incompatible with App Store, unfortunately (see VLC case e.g.) but permissive licenses are.
Long post Show more
@kaniini How are you planning to handle web push notifications in Pleroma? Notification payloads have a number-typed notfication id field.
@WAHa_06x36 Pleroma already supports web push notifications. Notification objects indeed have a numeric ID (notification_id) and that is presented accordingly.
@kaniini So notifications do not use the new-style ids?
@kaniini All right. Looking into what is needed to use string IDs now.
@kaniini Robin Hood hashing lets you get very compact hash tables, so it is already about as compact as it can get, and really fast. Also, touching that is a bit too likely to introduce problems so I will just use hashes of strings there when needed. The main thing to fix is the timeline cache format, which has so far just been a long array of ints.
@kaniini The current cache format is basically a fixed-size hash table at the start of a file, followed by actual entry data. The hash table contains (key, offset, timestamp) tuples. This works great for a cache, as you can just mmap() the start of the file for really fast lookups of where the actual data is. Occasionally, the oldest entries will be discarded and the trailing data compacted.
@Gargron bit dishonest as only one app was effected afaik and most app devs are on good terms without pleroma devs with no "rudeness" at all
@doublah At least two apps, and there has been plenty of rudeness going about.
@heluecht I think maybe you misunderstand. The Mastodon REST API (client-to-server) was designed specifically for Mastodon, in stark comparison to ActivityPub, which was designed by a working group as a standard through a bureaucratic process at the W3C. Pleroma or Misskey emulating it was not an intended use case that was planned for. It's an "on your own risk" thing that they do.
@Gargron That's why documentation and specification are seperate documents …
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!