Rethinking syndication

Aperta
  • Qualcosa non va?
#581 1 commento 0 reazioni 1 assegnatario Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@paulrobertlloyd ci sta già lavorando.

Dal 17/1/2023.

Valutazione

Questa issue non è ancora stata valutata.

Descrizione

code quality core help wanted plugin-syndicator question

Syndication is not working. As much as I try to patch over the cracks, fundamental flaws reveal themselves.

Here are a few things I learnt while trying to get syndication working reliably.

mp-syndicate-to is a directive, not a post property

Much like mp-slug, mp-photo-alt and (eventually) mp-destination do not appear in a posts properties, neither should mp-syndicate-to. As a directive to the Micropub server, it does not need saving in a content store.

  • #582
  • Record syndication targets in post.syndicateTo

Should syndication status be stored with posts or separately?

Syndication is flakey. APIs respond with weird errors, go down, or API keys get invalidated; the list is endless. Therefore, syndication needs to be a very asynchronous task.

Rather than try to keep a record of syndication status across different posts, a dedicated syndications database could be used.

When an incoming request includes mp-syndicate-to, we could add the post _id (not path or URL) to the list of outstanding syndications for that target:

{
  "https://mastodon.example": [
    "507f1f77bcf86cd799439011"
  ],
  "https://web.internet.archive": [
    "507f1f77bcf86cd799439011",
    "507f1f77bcf86cd799448372"
  ]
}

This information could be shown in the interface for the syndication endpoint, possibly at some stage allowing for some management, if that turns out to be a need.

Syndication can occur before or after a post is published

Currently, syndication only happens after Indiekit has published a post. One reason for this is that one syndicator, Internet Archive, needs to crawl the generated post HTML, meaning syndication makes sense once there is post URL for it to visit.

Also, while not currently possible, were statuses to contain a back-links, a post would need to be published for that link to work. Maybe this is not a massive problem; it’s unlikely back-links would be clicked on immediately after being tweeted/tooted/published, but it underlines this point.

What if syndication plug-ins could provide methods that are called pre-publication, as well as methods that are called post-publication? Then a syndication plug-in can dictate the most desirable point at which syndication occurs.

Syndication is not a one-time action

Currently, syndication is a one-time write action. What happens if you update or delete a post? Twitter has creation and deletion methods, and Mastodon allows statuses to be created, updated and deleted.

In that respect, syndicator plug-ins could be more similar to content store plug-ins, providing CRUD methods where possible that the Micropub endpoint can call as part of undertaking the respective CRUD Micropub action.

How would this fit in with the above suggestion (a separate database). Would that only be used to record and track syndications that failed (and maybe post-publication syndications)?

Next steps

I will mull over some of these ideas in the coming months. My immediate priority is to simplify when and how data is updated in the database and reflected in files sent to content stores.

Lingua principale
JavaScript
Stelle
392
Fork
39
Merge medio
8h 25m
PR unite (30g)
26

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di getindiekit/indiekit

Tutte le issue di getindiekit/indiekit

Issue simili

Altre issue su JavaScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.