The function GEN_RANDOM_UUID was only introduced to built in postgresql
in version 13, however, the installation guide specifies that version 12
should be sufficient.
The following endpoints are removed:
- `api/i/favorites`
- `api/notes/favorites/create`
- `api/notes/favorites/delete`
The following endpoints are changed:
- `api/notes/state`
- `api/users/stats`
closes FoundKeyGang/FoundKey#374
Changelog: Removed
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.