Instead of throwing an IdentifiableError which then just always gets
converted into an ApiError, the getter can just throw the same ApiError
directly. This makes it more convenient to use and thus more endpoints
have been refactored to use it to reduce code repetition.
The default of the library used is to require either of the "date" or
"x-date" headers. It does not seem sensible to pass on this default.
It may be to fix federation with another software but that software
should be considered broken, and it does not seem reasonable to
potentially get an outdated signature just to fix federation with some
buggy software.
This parameter is a duplicate of fileIds and was marked as deprecated
before. This removes that parameter and therefore simplifies the API
endpoint's schema.
Changelog: Removed
Adding a reaction may delete a previous reaction to the same note,
thus consequently this needs to be in the rate limiting group if this
happens. Otherwise the rate limit can be circumvented.
Changelog: Fixed
The `sort` parameter for /api/drive/show is now more unified with
other endpoints which use +createdAt for sort instead of +created.
closes FoundKeyGang/FoundKey#109
Changelog: Added
This changes the pagination of the drive/show API endpoint to use the
offset variant of pagination and allows to specify a sorting.
closes FoundKeyGang/FoundKey#362
Minor adjustment: The 'name' columns have the same max length.
Major adjustment: Rename both columns to be "parentId" and update
all references of this name in the backend. API parameters are not
changed, since that would be an unnecessary breaking change.
Since looking up a channel by ID should be the most often needed use
case, the data structure is now more optimized towards this. The code
is also simplified by using optional chaining where possible.
In this vein, the server will now enforce that channel IDs are unique
and not reused.
Changelog: Changed
The `quiet` argument has been removed from `deleteNote` (or `deleteNotes`
respectively) since it was not used anywhere and it does not seem a good
idea to not update statistics in some cases.
This should also fix an issue where cascade deletions mean that statistics
are not properly updated or streaming clients not properly informed of
deletions. This case was seemingly not considered before, even though
there was some handling for cascade deleted notes.
This is going to improve how cascade deletion impacts the delivery queue,
because cascade-deleted notes will now be grouped for delivery.
Changelog: Fixed