Breaking Changes

The changelog is essentially the git commit history, so I won't go into full details. But, anytime a change actually impacts the structure or function of the API (and thus will break frontends), I will document the date, version, and the change here.

May 17th, 2022:

• Changed userpages to have a true contentType, which is now 4. Thus, userpages are no longer "pages", they're just more content.
• You can now obtain the userpage using a standardized query macro !userpage(@uid), where you supply the uid in your values (the name of the parameter can be anything ofc). This way, frontends no longer have to ensure they're all using the same userpage query, the API will do it for you. If you're interested, it looks for the first content (by id) with contentType = 4 and createUserId = @uid and !notdeleted().

May 8th, 2022:

• Fixed leaking information on live events (should be any instance of leaking information, but specifically reported rethreading). HOWEVER, this means you should not assume that there's always something in objects which matches the live events in a live update. If you're creating your frontend to specifically scan the event list, know that some events may have no related content, messages, etc due to modified permissions.

April 23, 2022 9:57pm EST (v3.0.0.???):

• New websocket event type: selfbroadcast. You can communicate with other connected clients that are the same user. This breaks anything using api.js: if you are using a local copy of api.js, selfbroadcast will cause errors in the console, because it doesn't know how to handle that type. It shouldn't break the websocket, but I'm sure the messages are annoying. If you're updating api.js or using the direct link, the parameter list for WebsocketAutoConfig has been altered: the selfBroadcastHandler has been inserted BETWEEN errorEventListener and reconnectIntervalGenerator.

April 9th, 2022 10:45pm EST (v3.0.0.???):

• All types (codes, if you will) have changed from lowerCamelCase to under_score. This should not impact too much, BUT:
• All EVENT types have had _event appended to them. Now, when you receive live data, rather than the middle dictionary being message with a further message inside it, it is message_event.message.
• The event dictionary name for live data has been changed as well, so it is no longer called data, it is objects.
• The result dictionary name for request results has changed from data to objects as well.
• The result dictionary name for userlist results has changed from data to objects as well.

All together, what this means is that in your websocket, instead of doing this for live data: data.data.message.message you do: data.objects.message_event.message.

Instead of doing data.data.message for requests done inside the websocket, you do data.objects.message

Instead of doing data.data.user for a userlist response from the websocket, you do data.objects.user

April 8th, 2022 2:32pm EST (v3.0.0.251):

• User format changed: added createUserId and usersInGroup fields. You can mostly ignore these, unless you're working with groups
• User writability changed: can no longer set groups on user.

Note that the 'groups' field is not going away and most likely never will, but the 'usersInGroup' may be a temporary field just for now. I changed how groups work fundamentally, and so this is kind of a transition period for groups. However, it does NOT impact users, so you do not need to worry about 'usersInGroups', just ignore the field, UNLESS you have an endpoint in your frontend that manages groups.

April 7th, 2022 8:05pm EST (v3.0.0.245):

• All datetime formats in the database have been standardized to https://en.wikipedia.org/wiki/ISO_8601 format. The original format was like 2022-04-07 20:05:09.12345, the new format is 2022-04-07T20:05:09.12345Z.
• New datetime fields added after this point will only have 3 decimals of precision for seconds (millisecond precision)
• Removed AutoFixAllDates and AutoFixDates functions from api.js

December 2022:

• "Votes" changed to "engagement", different structure completely.
• "engagement" added to messages (not yet sent out in live updates though)
• All "vote" endpoints (for writing) changed to "engagement"

So before, you might vote "bad", "ok", or "good" on a page. You'd use the /api/shortcuts/vote endpoints (or something) to set votes on pages. The votes were available in the votes field, and might look something like:

{
   "bad" : 3,
   "ok" : 5,
   "good" : 0
}

But now, that field is engagement and it looks like:

{
   "vote" : {
      "bad" : 3,
      "ok" : 5
   }
}

The difference here is that engagement is an expansion of the voting system, letting you set arbitrary "types" of engagement and aggregating the data for each. Right now there are only "vote" types, but you could add "reaction" or anything else you want, it's arbitrary. This same structure is also available for messages. The new "engagement" endpoints are shown in the Shortcuts section of /api/swagger

December 19th 2022:

• Not necessarily "breaking", but data changes nonetheless: rethreading now stamps EVERY message with an "originalContentId":1234 value, to indicate the original room the message was posted in
• Furthermore, when rethreading, the first and last are stamped with additional metadata to describe the rethread. Something like: "rethread":{"date":"yeah",count:12,lastContentId:123,position:"start|end"}

More on the rethread metadata: the 'lastContentId' will generally be the same as the 'originalContentId' value, but if messages are rethreaded multiple times, the 'originalContentId' value will not change, whereas a new 'rethread' metadata is generated. So, if you only care about the last place the messages were rethreaded from, all data is in 'rethread'. However, if you also want to display where they came from originally, that's what the 'originalContentId' is for

October 23rd, 2023:

• Thumbnails split from uploads, used to be both went into uploads but now it defaults to uploads and thumbnails