Indiekit Demo publisher

Commentaire de pull request · PR #1016 feat: filter the list of posts by post type and text · @rmdes

All three done, and a suggestion on the fourth.

1. Filters in a details. The search is inside one now, collapsed unless a search term
is in use. I left the post types outside it, as a row of links rather than a select:
choosing one is a single click, it takes one row, and the current filter is visible without
opening anything. Collapsing them would surface the current filter only once you are
already filtering, which is when you least need telling. Happy to move them inside if you
would rather.

They reuse the navigation component with a navigation--filters modifier, which already
has the markup and the a[aria-current="true"] styling, so this adds a modifier and not a
component. The colours are the --color-offset / --color-on-offset pair tag uses, and
the current link swaps them, so the contrast is the same in both colour schemes.

2. Heading and page title. Both done. On your worry about this not adapting to further
filters, I think there is a rule that avoids the problem: the heading states what the
controls do not already show. A post type is marked on its own link, so the heading need
not repeat it in a sentence; a search term sits in a collapsed details, so it does get
played back. Any filter added later follows the same rule without new sentences.

613 posts
Note · 613 posts
Note · 613 posts matching “lunch”
Note · No posts
No posts matching “lunch”

The document title is that text prefixed with the page heading, exactly as you described:
Published posts: Note · 613 posts matching “lunch”. The empty states take the same shape,
so the title still says which search found nothing — your No posts found matching ‘[QUERY]’.

That needs three new keys rather than the twelve a sentence per combination would need,
reusing the two empty-state keys already on the branch.

The post type is a prefix rather than part of the sentence for a second reason: post type
names are not translatable. Every post type plugin hardcodes an English singular name
("Note", "Article", "RSVP") and none ships a locale file, so “613 [TYPE] posts”
renders in German as “613 Note Beiträge”. As a standalone label it reads as a label in any
language.

3. Localisation. Yes please to Localazy access — that would be very welcome. en.json
carries the three new keys and I have not touched the other fourteen files.

Two things follow from that, both worth knowing before you look at it in your own language.
Until the keys are translated, a non-English admin UI shows the English counts next to
translated controls — “Articles publiés: Note · 2 posts” in French. And noneMatching
keeps its existing translations, which do not interpolate the search term, so those read as
the unqualified sentence: true, just less specific than the English.

There is also a one-line i18n commit on the branch, which is why. A key that exists only in
en.json was rendered as the key itself in the other locales rather than as English —
defaultLocale covers an unknown locale, not a missing key inside a known one — so a
French page showed a literal posts.posts.count. retryInDefaultLocale makes it fall back
to the English string, and an existing translation still wins. Every locale file is
complete on main today, so it changes nothing visible; it just makes the window between a
new key and a Localazy sync harmless. There is a test for it.

It also saves me guessing plural categories, which I would get wrong: Polish needs
one/few/many and Serbian one/few/other, while Chinese and Indonesian need only
other. Localazy knows CLDR; I do not.

4. The range suffix. I have left (showing posts 1 to 40) out and would suggest leaving
it out, but it is your call. Paging is cursor-based, so a page does not know its own offset:
working out “41 to 80” means a second count query on every page load, on top of the total,
for something pagination already covers with next and previous. If you do want it, it is
one extra countDocuments.

Two things I noticed while in there.

_count is not new — it is yours. You added it in f42a9869 (“include private count value
in endpoint responses”) in June 2022, and 9bc6a357 removed it a year later when paging
became cursor-based, but the consumers added in cb541d42 stayed. So endpoint-posts has
read micropubResponse._count as undefined ever since, and endpoint-files still does.
This branch restores the property and uses it, applying the same string-uid guard
getCursor applies so it never reports posts that paging cannot reach. I have left
endpoint-files alone, since it has no filter UI to show a count in.

Separately, limit is not carried into the next and previous links, so paging from
?limit=1 falls back to the default page size. main builds those hrefs as ?after=<uid>
with nothing else, so this is not from this branch and I have not touched it.

Two follow-ups I would rather keep separate, both needing a decision rather than code:

• Counts on the post type links. These count the collection, not the query — a count
  that moved with your search would be the wrong number for deciding where to look. That
  makes them a different thing from _count, and no Micropub extension defines a surface
  for them.
• Status and sort controls. q=source has no parameter for either.

Ouvrir sur GitHub →

Commit sur main · 5308a2f · @paulrobertlloyd

This is to prevent Railway using Docker to deploy the development environment

Ouvrir sur GitHub →

Commit sur main · 871d174 · @rmdes

fix(indiekit): send the token to introspect in the request body

Ouvrir sur GitHub →

Commit sur main · bb86ea1 · @paulrobertlloyd

This is to prevent Railway using Docker to deploy the development environment

Ouvrir sur GitHub →

Revue de pull request (APPROVED) · PR #1019 ci: move Docker files to sub-folder · @rmdes

Looks good. I built the branch with docker build -f docker/Dockerfile . and it works, with docker/Dockerfile.dockerignore picked up (a 3.9 MB build context against 14 MB on disk). The other Dockerfile mentions left in the repo are all about the one create-indiekit generates for users, so nothing else needs to move. One knock-on: building from a checkout is now -f docker/Dockerfile rather than a plain docker build .; I’ll update the quickstart’s instructions once this is merged.

Ouvrir sur GitHub →

Revue de pull request (APPROVED) · PR #1019 ci: move Docker files to sub-folder · @rmdes

Looks good. I built the branch with docker build -f docker/Dockerfile . and it works, with docker/Dockerfile.dockerignore picked up (a 3.9 MB build context against 14 MB on disk). The other Dockerfile mentions left in the repo are all about the one create-indiekit generates for users, so nothing else needs to move. One knock-on: building from a checkout is now -f docker/Dockerfile rather than a plain docker build .; I’ll update the quickstart’s instructions once this is merged.

Ouvrir sur GitHub →

Commit sur main · 2d43d60 · @rmdes

fix(indiekit): send the token to introspect in the request body

Ouvrir sur GitHub →

Commit sur main · d84b207 · @rmdes

build: add an official runtime container image

Ouvrir sur GitHub →

Commentaire de pull request · PR #1016 feat: filter the list of posts by post type and text · @paulrobertlloyd

Nice! Couple of things…

1. Let’s put the filters inside a details component so that they are hidden/collapsed by default. That way they don’t take up too much screen space when not in use. The open attribute should be added if a post type or search filter is being used.
2. Thinking about the accessibility of showing a subset of filtered items:
   • There should be a h2 above the items indicating what’s being shown
   • The page title should be updated to play back this same information
3. Adding localisations is a bit more involved than updating the JSON files (at least for them to be managed via Localazy). New keys are added thus:
   1. Add/update en.json
   2. localazy upload (adds any new keys to locale dictionary)
   3. Add localisations in the Localazy UI
   4. localazy download (downloads updated localisation files)

I can add you as a contributor to Localazy if you’d like? Otherwise I can do the above once we’ve agreed on the localisations needed and their respective keys.

Playing back search results

Here’s an initial suggestion for the heading/page title. I realise this is possibly a bit much (would also need to think how this would need to adapt should further filters be added). Open to suggestions!

No filters applied

• No posts
• 1 post
• 2 posts
• 41 posts (showing posts 1 to 40)

Post type filter applied

• No [TYPE] posts
• 1 [TYPE] post
• 2 [TYPE] posts
• 41 [TYPE] posts (showing posts 1 to 40)

Search filter applied

• No posts found matching ‘[QUERY]’
• 1 post found matching ‘[QUERY]’
• 2 posts found matching ‘[QUERY]’
• 41 posts found matching ‘[QUERY]’ (showing posts 1 to 40)

Post type and search filter applied

• No [TYPE] posts found matching ‘[QUERY]’
• 1 [TYPE] post found matching ‘[QUERY]’
• 2 [TYPE] posts found matching ‘[QUERY]’
• 41 [TYPE] posts found matching ‘[QUERY]’ (showing posts 1 to 40)

The page title should use this same text, prefixed with ‘Published posts: ’

Ouvrir sur GitHub →

Pull request (OPEN) · PR #1019 ci: move Docker files to sub-folder · @paulrobertlloyd

This is to prevent Railway using Docker to deploy the development environment. This is important because Railway always picks Docker as builder.

Ouvrir sur GitHub →

Commit sur main · b791821 · @paulrobertlloyd

Disable noImplicitAny checks as these are many and various and need addressing separately

Ouvrir sur GitHub →

Commit sur main · 11335b9 · @rmdes

docs: run Indiekit in a container

Ouvrir sur GitHub →

Commit sur main · 2f22f32 · @paulrobertlloyd

Disable noImplicitAny checks as these are many and various and need addressing separately

Ouvrir sur GitHub →

Commit sur main · 29ceaa9 · @rmdes

docs: run Indiekit in a container

Ouvrir sur GitHub →

Commit sur main · ebbc9b4 · @rmdes

ci: publish the container image on release and preview channels

Ouvrir sur GitHub →

Commit sur main · cb22077 · @rmdes

build: add an official runtime container image

Ouvrir sur GitHub →

Commentaire de pull request · PR #960 build: official container image with release and manual preview channels · @rmdes

I wanted to test the workflow, so I ran docker-preview by hand from main to confirm it works: it did (run 38438316241), and pushed preview-31 and preview-31-7563895. So the indiekit package exists now; it just needs switching to public in its package settings. (docker-release can’t build v1.0.0-beta.31 itself, as that tag predates the Dockerfile, so release images start with beta.32.)

Ouvrir sur GitHub →

Commentaire de pull request · PR #960 build: official container image with release and manual preview channels · @rmdes

Thanks for merging! No image has been published yet, since docker-release only runs on a published release and beta.31 came out before the merge. Could you start the workflow by hand for v1.0.0-beta.31, or would you rather wait for beta.32? Once the indiekit package exists, it’ll need setting to public in its package settings (org admin) for docker pull ghcr.io/getindiekit/indiekit:beta to work for everyone; the quickstart is waiting on that tag.

Ouvrir sur GitHub →

Pull request (OPEN) · PR #1018 fix(indiekit): send the token to introspect in the request body · @rmdes

Fixes #1017

introspectToken sends the token as a form-encoded token parameter in the POST body (RFC 7662 §2.1) instead of in the URL. The Authorization header is unchanged.

The introspection mocks now match that request (no query string, token in the body), so the existing introspectToken tests fail on main with Mock dispatch not matched for path '/introspect?token=JWT'. An endpoint-auth test covers the other side: a token sent only in the body is accepted.

Ouvrir sur GitHub →

Issue ouverte · Issue #1017 Access tokens are sent in the introspection URL, so they end up in access logs · @rmdes

introspectToken in packages/indiekit/lib/token.js sends the token being checked in the URL as well as in the Authorization header:

introspectionUrl.searchParams.append(“token”, bearerToken);

The introspection endpoint never reads it from there (it reads request.body.token, then the header), so the URL copy does nothing but leak a long-lived access token into access logs, and into any proxy or external IndieAuth server’s logs on the way. On a deployment every Micropub request without a session leaves a line like:

POST /auth/introspect?token=eyJhbGciOiJIUzI1NiIs… HTTP/1.1

RFC 7662 §2.1 has the client send the token as a form-encoded token parameter in the POST body.

Related to #1006.

Ouvrir sur GitHub →

Pull request (OPEN) · PR #1016 feat: filter the list of posts by post type and text · @rmdes

Refs #843.

The list of posts can’t be narrowed down at all. Micropub q=source already supports filter and category (#991), but the posts interface doesn’t use them, and there’s no way to filter by post type.

Micropub

• q=source accepts a post-type parameter, from the Query for Post List Micropub extension. Like filter and category, its value is cast to a string before it reaches the database. It combines with the other filters and with after/before paging.
• README updated.

Posts

• A form above the list of posts lets you choose a post type (from the publication’s configured post types) and search names and content. Values are passed to the Micropub endpoint as post-type and filter, so the list stays a Micropub client and doesn’t care how posts are stored.
• The next and previous page links keep the filters. They are built with URLSearchParams, so search text such as lunch & dinner survives paging.
• If no posts match, the list says “No posts match these filters” instead of “No posts”.
• The form uses the existing fieldset, select, input and button components, so it looks like the rest of the interface. That stacks the fields vertically. A compact single-row layout would need new styles, which I’ve left out for now.

Only en.json has the new strings.

Status, sort order and per-type counts, which my fork has, would each need a new Micropub query feature, so I’ve left them for later.

Tests

• Micropub: filtering by post type alone and combined with filter, with real posts seeded into the test database.
• Posts: the filtered list, the form keeping its values, filters kept in the pagination links, and the no-matches message.
• endpoint-micropub and endpoint-posts tests pass (221/221, Node 24.17); lint and typecheck are clean.

Ouvrir sur GitHub →

Commentaire de pull request · PR #1014 fix(syndicator-mastodon): favourite and reblog statuses on other servers · @rmdes

Opened from the wrong repository; replaced by #1015.

Ouvrir sur GitHub →

Pull request (OPEN) · PR #1015 fix(syndicator-mastodon): favourite and reblog statuses on other servers · @rmdes

Refs #843.

Likes and reposts are syndicated as native favourites and reblogs, but only when the status is on the syndicator’s own server. Liking a status on any other instance is skipped, and endpoint-syndicate reports it as “did not return a URL”. Without the ActivityPub plugin, that’s the only route a like has to the fediverse, so for most likes nothing happens.

Replies already resolve statuses on other servers (resolveRemoteStatus, #927). This uses the same step for likes and reposts:

• postFavourite and postReblog take the status ID from the URL when the status is on this server, and otherwise resolve it with v2/search (resolve: true).
• post() no longer drops likes and reposts of other servers’ URLs up front.
• A repost with content (a quote status) is syndicated when the reposted URL resolves to a status.
• URLs that don’t resolve to a status (a blog post, say) are still not syndicated, so defaults are unchanged and there are no new options.

Opt-in statuses for likes and reposts of URLs that aren’t statuses (syndicateExternalLikes / syndicateExternalReposts) can follow separately, depending on the discussion in #843.

Tests

• Unit tests for favouriting and reblogging a status on another server, the same through post(), quote statuses of a remote status, and skipping URLs that don’t resolve.
• The two existing “doesn’t post a favourite/repost of a URL” tests now use the mocked unresolvable URL, since every like and repost now searches first.
• Syndicator, endpoint-syndicate and endpoint-share syndication tests pass (73/73, Node 24.17).

Ouvrir sur GitHub →

Pull request (CLOSED) · PR #1014 fix(syndicator-mastodon): favourite and reblog statuses on other servers · @rmdes

Refs #843.

Likes and reposts are syndicated as native favourites and reblogs, but only when the status is on the syndicator’s own server. Liking a status on any other instance is skipped, and endpoint-syndicate reports it as “did not return a URL”. Without the ActivityPub plugin, that’s the only route a like has to the fediverse, so for most likes nothing happens.

Replies already resolve statuses on other servers (resolveRemoteStatus, #927). This uses the same step for likes and reposts:

• postFavourite and postReblog take the status ID from the URL when the status is on this server, and otherwise resolve it with v2/search (resolve: true).
• post() no longer drops likes and reposts of other servers’ URLs up front.
• A repost with content (a quote status) is syndicated when the reposted URL resolves to a status.
• URLs that don’t resolve to a status (a blog post, say) are still not syndicated, so defaults are unchanged and there are no new options.

Opt-in statuses for likes and reposts of URLs that aren’t statuses (syndicateExternalLikes / syndicateExternalReposts) can follow separately, depending on the discussion in #843.

Tests

• Unit tests for favouriting and reblogging a status on another server, the same through post(), quote statuses of a remote status, and skipping URLs that don’t resolve.
• The two existing “doesn’t post a favourite/repost of a URL” tests now use the mocked unresolvable URL, since every like and repost now searches first.
• Syndicator, endpoint-syndicate and endpoint-share syndication tests pass (73/73, Node 24.17).

Ouvrir sur GitHub →

Commentaire d’issue · Issue #843 Syndicator-mastodon only works for Notes post type, others fail · @rmdes

@eclecticpassions sorry, I closed the loop too early here. Digging back in on beta.31, there are two separate things going on.

Likes and reposts. Indiekit prefers native actions: like a Mastodon post and it gets favourited, rather than a new status being posted that links to it. The bug is that “native” currently only works for posts on your own server. post() checks isSameOrigin(like-of, serverUrl), so liking a status on any other instance is skipped and reported as “did not return a URL”. The syndicator already resolves remote statuses for replies (resolveRemoteStatus, #927). Likes and reposts just need the same step, so a like of a status on another server becomes a real favourite. This doesn’t change any defaults or add an option, and without the ActivityPub plugin it’s the only way a like reaches the fediverse.

For URLs that can’t be resolved, such as a blog post that isn’t on the fediverse, I’d keep today’s behaviour by default and add opt-in syndicateExternalLikes / syndicateExternalReposts options. They’d post a status with your comment and a link instead. @paulrobertlloyd, does that fit what you meant by an opt-out, or did you also want a way to turn off native favourites for same-server posts?

The posts list. The type/search filters you used came from my fork, which queried the database directly, so they didn’t carry over. Micropub q=source upstream already supports filter and category. I’ll add a post-type filter and a filter form on the posts page that uses them.

I’ll open PRs for the cross-server likes fix first, then the posts filter.

Ouvrir sur GitHub →

Commit sur main · 7563895 · @paulrobertlloyd

Disable noImplicitAny checks as these are many and various and need addressing separately

Ouvrir sur GitHub →

Commit sur main · b9556e0 · @rmdes

docs: run Indiekit in a container

Ouvrir sur GitHub →

Commit sur main · 5471323 · @rmdes

ci: publish the container image on release and preview channels

Ouvrir sur GitHub →

Commit sur main · ec8afbc · @rmdes

build: add an official runtime container image

Ouvrir sur GitHub →

Commit sur main · 66ed24d · @rmdes

Release and manually published previews cover the need; a daily multi-arch build spends Actions minutes and leaves a main-<sha> version in the registry per run for nobody in particular. nightly also stops being a reserved channel name in the preview workflow, since no workflow claims it any more.

Ouvrir sur GitHub →

Commit sur main · 6cf3a69 · @rmdes

ci: publish the container image on release, nightly and preview channels

Ouvrir sur GitHub →

Commit sur main · 307bb7a · @rmdes

build: add an official runtime container image

Ouvrir sur GitHub →

Commit sur main · 05b9348 · @rmdes

docs: run Indiekit in a container

Ouvrir sur GitHub →

Commit sur main · f2ebed1 · @paulrobertlloyd

ci: move husky to devDependencies, use prepare script

Ouvrir sur GitHub →

Commit sur main · 6475f6e · @paulrobertlloyd

chore: update dependencies

Ouvrir sur GitHub →

Commit sur main · 01a0570 · @paulrobertlloyd

chore: update dependencies

Ouvrir sur GitHub →

Commit sur main · 5412a52 · @paulrobertlloyd

ci: use node 26 for local development

Ouvrir sur GitHub →

Commit sur main · 78e1de5 · @paulrobertlloyd

This isn’t needed when running Node 26+

Ouvrir sur GitHub →

Commit sur main · f7f01ab · @paulrobertlloyd

ci: move husky to devDependencies, use prepare script

Ouvrir sur GitHub →

Commit sur main · d2d771c · @paulrobertlloyd

ci: move lerna to devDependencies

Ouvrir sur GitHub →

Commit sur main · f52bc42 · @paulrobertlloyd

chore: update dependencies

Ouvrir sur GitHub →

Commit sur main · 33ab4ad · @paulrobertlloyd

ci: move husky to devDependencies, use prepare script

Ouvrir sur GitHub →

Commit sur main · 309cd7f · @paulrobertlloyd

This isn’t needed when running Node 26+

Ouvrir sur GitHub →

Commit sur main · 8ccfc60 · @paulrobertlloyd

ci: move lerna to devDependencies

Ouvrir sur GitHub →

Commit sur main · 92afa25 · @paulrobertlloyd

ci: use node 26 for local development

Ouvrir sur GitHub →

Commentaire de pull request · PR #960 build: official container image with release and manual preview channels · @paulrobertlloyd

I’ve moved all the dependencies to devDependencies (and removed the sharp override which was only needed if running tests locally on Node 24; have updated .nvmrc to use Node 26).

Ouvrir sur GitHub →

Commit sur main · af6ad6d · @paulrobertlloyd

chore: update dependencies

Ouvrir sur GitHub →

Commit sur main · cdcbc5b · @paulrobertlloyd

ci: move husky to devDependencies, use prepare script

Ouvrir sur GitHub →

Commit sur main · b703b9f · @paulrobertlloyd

ci: move lerna to devDependencies

Ouvrir sur GitHub →

Commit sur main · c95acc1 · @paulrobertlloyd

This isn’t needed when running Node 26+

Ouvrir sur GitHub →