CustomCollectionModelBinder's `as IList` cast does not work for HashSet,
breaking the code around trailing []s in query arguments.
The values are still being treated as a set in the query so adding the
same value multiple times shouldn't do anything except hit the max limit
quicker.
The intention was to aid clients which may not be doing their own
deduplication but I haven't really observed that behavior in the wild
and I doubt it's anything too much to expect from clients.
That said, testing on mastodon.social shows Mastodon itself may be doing
deduplication here before checking the limit, though I'm not entirely sure
if this will ever be noticed in the wild.
Inline media can be created by:
1. Attach media to note as usual
2. Copy media URL (public one, for remote instances)
3. Use the new $[media url ] MFM extension to place it wherever you
wish. (The trailing space is necessary as the parser currently
treats the closing ] as a part of the URL)
The Iceshrimp frontend may make this easier later on (by having a
"copy inline MFM" button on attachments, maybe?)
Federates as <img>, <video>, <audio>, or <a download> HTML tags
depending on the media type for interoperability. (<a download> is
not handled for incoming media yet).
The media will also be present in the attachments field, both as a
fallback for instance software that do not support inline media,
but also for MFM federation to discover which media it is allowed to
embed (and metadata like alt text and sensitive-ness). This is not
required for remote instances sending inline media, as it will be
extracted out from the HTML.
The Iceshrimp frontend does not render inline media yet. That is
blocked on #67.
This does technically match Mastodon's behavior, but it doesn't match the behavior of iceshrimp-js, or the Iceshrimp.NET web API. It's also very confusing.
Instead of backfilling every note we come across that has a reply
collection, only schedule a backfill job if someone wants to see the
replies (on GET MastoAPI /context, or Iceshrimp API /descendants)
Reply backfilling is also done on a ThreadIdOrId basis as opposed to the
previous way of backfilling individual notes. This allows us finer
grained control over the recursion and frees up the job queue, alongside
allowing for easier implementation of context collection backfill in the
future (by mapping each context collection to a thread)
---
Currently, note threads are implicit based on the "threadId" column of a
note, which can be null (where it's the same as the note's "id")
This commit turns note threads into an actual entity, and as a part of
that, makes "threadId" non-nullable (by specifically setting it to "id"
for those cases)
This is done to attach extra metadata to the entire thread, currently
just the time of when it was last backfilled, but more may be added in
the future (the context collection associated with this thread, for example)
---
The data format for backfill jobs have backwards-incompatibly changed
since the introduction of the feature. We can drop all old jobs without
causing too much trouble as they will be re-scheduled on demand
---
Signed-off-by: Laura Hausmann <laura@hausmann.dev>
