This dependency was unused in the client.
The use of it in the server can be replaced entirely by the
secureRndstr function, with some slight modifications.
That function could probably be refactored a bit more as well.
They did not really fit into the DbResolver because they may fetch data
from remote instances even though DbResolver is only supposed to access
the database.
The table that is affected here was not properly purged of old entries. It only holds
data that is needed while a 3rd party authorization is in progress but not finished.
The code that typeorm generated for this migration is a bit wonky because it should
probably have dropped one column and created another one. But if we clear out all entries
it should work regardless and I'm feeling lazy right now. :P
This also simplifies API authentication a bit by not having to fetch
the App that is related to a token.
The restriction of 1 token per app is also lifted. This was not a
constraint in the database but it was enforced by the code and
kinda wrong schema the auth_session table had.
This is basically a shim on top of the existing API.
Instead of the 3rd party, the web UI generates the authorization session.
The data that the API returns is slightly adjusted so that only one
API call is necessary instead of two.
This reverts commit e446a11bb7.
Turns out this wasn't really the source of the referenced issue and
someone was able to run with the original commit fine, so adding this
back for now.
Some hashtags sent from Mastodon were erroneously displayed as links.
This is because Mastodon seems to mangle hashtags containing non-ASCII
codepoints (such as e.g. umlauts). This lead to the previous code which
depended on the list of hashtags to not recognize a hashtag. Instead,
the `rel="tag"` microformat is recognized instead.
This makes the `htmlToMfm` wrapper function unnecessary so it was removed.
Changelog: Fixed
This adds in wildcard matching. For instance:
- `*.bad.tld` will match: `very.bad.tld`
- `bad.*` will match: `bad.something`
- `*.bad.*` will match: `very.bad.evil`
Changelog: Changed
This setting is unnecessary because DeepL free keys can be detected
easily according to <https://www.deepl.com/docs-api/api-access/authentication/>:
> DeepL API Free authentication keys can be identified easily by the suffix ":fx"
Changelog: Removed
There are now separate web and queue workers.
The configuration entry `clusterLimit` has been replaced by
`clusterLimits` which allows separate configuration of web and
queue workers.
Changelog: Changed
Now that Node 18 is the new LTS version of Node, it should be safe to
support ES2022 features. The install docs have already been updated to
recommend Node 18.x in 41a710854e.
This will break support on Node 16.x and earlier.
Also update TypeScript to 4.9 which contains various typechecking
improvements: https://devblogs.microsoft.com/typescript/announcing-typescript-4-9/
Ref: FoundKeyGang/FoundKey#238
Changelog: Changed
The thing that previously presumably hindered this was that the VAPID
keys had to be set up. Previously admins had to do this, but this is a bad
idea for multiple reasons:
1) The meaning of "public key" and "private key" was not well documented
in the settings.
2) Giving out a private key over the API, even just for admins, sounds
like a bad idea.
Co-authored-by: Francis Dinh <normandy@biribiri.dev>
Copy over the MONTH constant from the client code and the time constants
for active{Halfyear,Month}.
Also instead of adding and deleting `respository` from the nodeinfo for
version 2.0, only add in the repository URL in the 2.1 endpoint.
Use the distinct query thingy so we don't have to make the Set work
so hard. This is also uniform code with the "everyone" above so should
hopefully be easier to understand.
This fixes a few type errors like removing `software.respository` in
NodeInfo 2.0 and updating `metadata.repositoryUrl` to not use the
now removed meta `repositoryUrl` field.
Co-authored-by: Francis Dinh <normandy@biribiri.dev>
Reviewed-on: FoundKeyGang/FoundKey#221
Remove the several filter functions in different places by filtering
directly in the database.
Instead of a QueryBuilder, use the plain find function.
Refactor a for loop awaiting several promises individually, use
Array.map and await Promise.all to make better use of promises.
This should reduce the performance hit when adding large numbers of
instances to the deliver queue by making the check for suspended and
dead instances a bulk operation.
Changelog: Changed
Reviewed-on: FoundKeyGang/FoundKey#215
The UUIDs are no longer used for errors and all errors should now have
a descriptive message attached to them. Also, all errors should now have
the proper HTTP status code for a reply instead of the generic 400 and 500
response codes. Because the errors all have more specific error codes, the
"kind" of client or server is also abolished.
- Add a rate limit analogous to request-reset-password.
See also a0ef32f4f6.
- Delete an expired reset request if found.
- Return a proper error.
- Use time constants.
Changelog: Changed
Since you are also allowed to react to your own notes, it seems sensible
that you should be allowed to like your own gallery posts.
Analogous to commit 4c5aa9e538.
Changelog: Changed
`createdAt` in `insertNote` now will default to the current date.
Also refactor poll insert:
Instead of testing hasPoll, just do a null check on data.poll since it's
a more reliable indicator for whether a poll exists (and also tsc won't
complain about data.poll being possibly null).
This should also have better latency due to being a single query.
Furthermore, it's no longer a linear scan, since host is indexed.
Would be cool to simplify it further to a single query for blocks also...
Why exactly are blocks not in the db?
It works by having a day-long cache of
"when did we last successfully communicate with this instance?"
Anything over a specified threshold (1 month) will act as though the instance
is suspended - all outgoing jobs are dropped on processing.
The day-long cache is in place because the ordering is necessarily a
linear scan.
Once an instance comes back online, we will detect that is the case as soon as
we receive an activity from them (which will update the "last communicated at")
field.
Potential future TODOs:
* Improve the caching system, it's actually pretty inefficient as it is.
CacheBox with a call override?
* Think of ways to make it not-a-linear-scan, since the instances table can get
pretty big. It's around 4500 on toast cafe.
ChangeLog: Added
I'm not sure how it managed to work so far, but the function is the default
export, using the namespace like a function should not have worked,
maybe something under the hood was correcting it back
This is oriented on this paragraph from the AP spec:
> Additionally, if an object is addressed to the Public special collection,
> a server MAY deliver that object to all known sharedInbox endpoints
> on the network.
This makes it consistent with `outgoingAddressFamily`, reducing
potential confusion.
For compatibility reasons, numbers are still permitted for `redis.family`
with the following mapping:
- `dual` = `0`
- `ipv4` = `4`
- `ipv6` = `6`
Changelog: Changed
This adds a new optional `sourceLang` parameter to the `notes/translate`
endpoint. If not set, the old behaviour is used, else this sets the
`source_lang` parameter to the DeepL API call which makes it use the
source language specified instead of using autodetection.
Changelog: Changed
Ref: FoundKeyGang/FoundKey#33
HTTP GET parameters are not to be specified in the requestBody but in
the parameters. This commit fixes that although admittedly it is kind
of a bodge and not perfect, but it is a start.
Changelog: Fixed
Also remove the contributors list from about-foundkey (renamed from
about-misskey).
Some comments that referenced Misskey were also translated to English.
Closes: FoundKeyGang/FoundKey#141
GNU Social's follow request IDs are larger than the 128 character limit
of the follow_request.requestId column. This prevents follow requests
from GNU Social instances from being handled by Foundkey instances.
The solution is to make the requestId column larger.
Fixes FoundKeyGang/FoundKey#146
Turns out `getMany` doesn't work with the specific query used, so use
`getRawMany` instead.
Also fixup the predicate used in userInfo to use the correct field
names.
Exploiting this before should already have been rather difficult because you
would need to know or guess the notification's ID. It is also of relatively
low security impact.
Changelog: Fixed
In #134, the mention `MfmNode` handler was made async to allow the
mentionedUsers query to be used there. This however changed the return
type of that handler to be a `Promise`, causing a `TypeError` in
`appendChildren`.
This fixes the `TypeError` by making every handler and the `appendChildren`
function also async and awaiting on the processed children.
This also attempts to fix the types issue with handlers by casting to
the newly defined `HandlerFunc` type instead of to `any`.
The mentionedUsers query was being run on every post, regardless of
whether a mention was in it or not.
This resulted in an SQL query ending in `WHERE userId IN ()` which is
not allowed in PostgreSQL.
Reference: FoundKeyGang/FoundKey#132
Changelog: Fixed
The column mentionedRemoteUsers on the note table in the database is
firstly in the wrong type since it contains JSON data but is typed as
text. Secondly it seems redundant, since that data can be acquired by
using the note.mentions column to fetch the respective data instead.
Co-authored-by: Francis Dinh <normandy@biribiri.dev>
Removed the misc/get-note-html module which was only used in one place.
Instead of it, the general MFM to HTML functionality has been improved to
take care of the use cases of that module as well.
Co-authored-by: Francis Dinh <normandy@biribiri.dev>