instead of passing a (possibly gigantic) array from JS, we get
PostgreSQL to look at the value in the `meta` table directly
tested the `federation/instances` endpoint, and the `QueryService`
methods; I have not tested the charts
* SP-2025-03.1 always wrap icon&thumbnail URLs
if they're not HTTP URLs, the frontend won't be able to display them
anyway (`<img src="mailto:…">` or '<div stile="background-image:
url(nntp:…)">` aren't going to work!), so let's always run them through the
media proxy, which will fail harder (fetching a `javascript:` URL
won't do anything in the backend, might do something in the frontend)
and will always protect the client's address in cases like `gemini:`
where the browser could try to fetch
* SP-2025-03.2 use object binding for more styles
interpolating a random (remote-controlled!) string into a `style`
attribute is a bad idea; using VueJS object binding, we should get
proper quoting and therefore safe parse failures instead of CSS
injections / XSS
* SP-2025-03.3 slightly more robust "self" URL handling
parse URLs instead of treating them as strings; this is still not
perfect, but the `URL` class only handles full URLs, not relative
ones, so there's so way to ask it "give me a URL object that
represents this resource relative to this base URL"
notice that passing very weird URLs to `MkUrl` and `MkUrlPreview` will
break the frontend (in dev mode) because there's an untrapped `new
URL(…)` that may explode; production builds seem to safely ignore the
error, though
---------
Co-authored-by: dakkar <dakkar@thenautilus.net>
* Exclude blocked instance note from most timelines
* Exclude blocked instance note from FTT timelines
* Exclude blocked instance note from featured
* fix type
* enhance(backend): use composite index for ordering notes by user
Signed-off-by: eternal-flame-AD <yume@yumechi.jp>
* fixup! enhance(backend): use composite index for ordering notes by user
---------
Signed-off-by: eternal-flame-AD <yume@yumechi.jp>
@Oneric explained:
> Spec says query params must be included in the signature; Mastodon
> being Mastodon used to always exclude it though and for
> compatibility everyone followed this. At some point GtS decided to
> follow spec instead which caused interop issues, but succeeded in
> getting Mastodon (and others like *oma) to accept incoming requests
> with (and also still without) query params though outgoing requests
> remaing query-param-free. Some still only accept query-param-less
> requests though and GtS uses a retry mechanism to resend any request
> failing with 401 with an query-parama-less signature once. (Also
> see:
> https://docs.gotosocial.org/en/latest/federation/http_signatures/ )
>
> So for incoming requests both versions need to be checked. For
> outgoing requests, unless you want to jump through retry hoops like
> GtS, omitting query-params is the safer bet for now (presumably this
> will only change if Mastodon ever decides to send out requests
> signed with query params)
