This deletes as many files as necessary to ensure the drive quota for
remote users is kept. Previously only one file would have been deleted
for each file added.
Changelog: Fixed
Co-authored-by: CGsama <CGsama@outlook.com>
Co-authored-by: tamaina <tamaina@hotmail.co.jp>
Instead of checking this configuration in the respective component (queue)
or not at all (server), the configuration can be checked when starting the
respective workers.
This log level replaces the "MK_QUIET" environment variable to unify
the interface in a sensible way. This also removes the "MK_VERBOSE"
environment variable which was unused.
To avoid a circular dependency this requires moving the log level
definitions. Also to avoid a circular dependency the env.ts file cannot
use a logger and instead uses plain `console.log`.
This resulted in endless ping-pong traffic on the websocket, happening
every interval of network latency to the server (e.g. for me, with 40ms
latency to my server, it was about every 40ms). On my server this ended
up taking about 20% of foundkey's CPU usage. Now, just send pings every
30s, and check if we have received any pong's in last 60 seconds to
check that the connection is still alive.
Changelog: Fixed
This makes the returned values `localFollowingCount`,
`remoteFollowingCount`, `followingCount`, `localFollowersCount`,
`remotefollowersCount`, `followersCount` optional on the API endpoint
`users/stats`.
Changelog: Fixed
The `data` field is not used anywhere in the logger. While it would
be possible to send structured data through syslog, it seems unnecessary
at present and also the way in which this structured data would have to be
provided sounds too cumbersome to implement for no real value.
The CacheableUser, CacheableLocalUser and CacheableRemoteUser are
identical types to User, ILocalUser and IRemoteUser so it seems
nonsensical to have different types for them.
The distinction for "DetailedInstanceMetadata" does no longer exist
since commit 9022ab9f2a.
The `DetailedInstanceMetadata` and `LiteInstanceMetadata` have
therefore been removed, leaving only `InstanceMetadata`.
Changelog: Removed
When rendering the HTML for outgoing activities, the mentions are now
matched case insensitive and should also work properly for IDNs. The
username is also compared case insensitive. Mentions of local users
are also handled properly independed of whether the hostname was given
or omitted.
The query to get mentions is now also only executed once instead of
for each mention individually.
Changelog: Fixed
While refactoring the previous commit, it seemed like the previous
authors expected that a system account could be registered somehow
and that this would be an error condition. However, as now made
explicit with this, it is not possible to register a system account.
This means that any account by that name could only ever have been
created by the system itself so fetching them should be fine and not
an error condition.
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
The issue was that the detection in the drive component did not see the
contents of `paginationElem.items` because the ref was not properly
exposed. The value of the exposed property was a Proxy of an empty
array that was not a reference to the actual items array. Thus, when
checking if the item already exists or not, it never saw the item and
added it as if new.
closes FoundKeyGang/FoundKey#367
closes FoundKeyGang/FoundKey#368
Changelog: Fixed
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
These messages are wrong when using the newly added filter and there
are no filtering results. Instead of adding yet another separate
message for an empty pagination, just show the default empty thingy
the pagination component provides already.
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.
The error UUIDs were removed from the backend and trying to match against the IDs
no longer works. This can produce confusing UI behaviour when displaying errors.
closes FoundKeyGang/FoundKey#363
Changelog: Fixed
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
I am not sure why ref's were used here before, since all changes to
those refs could only be from the same page the user was already on.
It seems the ColdDeviceStorage.ref was causing some circular thingies
that went wrong.
closes FoundKeyGang/FoundKey#353
Changelog: Fixed
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