Das Fediverse tut sich schwer, das volle Potential der verschiedenen Activity-Objects auszunutzen, hauptsächlich aus Angst, sie falsch oder schlecht darzustellen und deshalb teilen die meisten großen Netzwerke leider nur Notes.

Dabei könnte es so einfach sein!

@deadsuperhero schreibt auf seinem Blog, dass er eigentlich gerne Articles veröffentlichen will, aber (hauptsächlich) durch Mastodon zu Note gezwungen wird, wenn er sicher gehen will, dass der Text vollständig dargestellt wird.

Here’s the problem, though: the biggest player in the space, Mastodon, does a poor job of supporting Article. Instead, every post Mastodon uses is instead a Note. From a semantic point of view, it might not seem like there’s a lot of difference between the two: both are effectively texts posts that can contain some formatting markup, both can hold an arbitrary amount of characters, and both can effectively be used to represent a full article.

A Content-Fallback Mechanism for the Fediverse

Ironischerweise zeigt Mastodon eine föderierte Note vollständig an, auch wenn der Text weit über die eigentlich erlaubten 500 Zeichen hinaus geht, bei einem Article wird statt dessen aber nur die kurze summary benutzt.

Seine Idee: Ein Content-Fallback Mechanismus!

Das heißt jede Aktivität, egal von welchem Typ, liefert zusätzlich zu dem spezifischen Objekt, eine standardisierte Note (content-fallback):

{
  "@context":[
    "https://www.w3.org/ns/activitystreams",
    {
      "Hashtag":"as:Hashtag"
    }
  ],
  "id":"https://wedistribute.org/2024/04/iftas-dsa-guide/",
  "type":"Article",
  "content-fallback": {
    "content":"IFTAS, the dedicated Trust & Safety organization ...",
    "mediaType":"text/plain",
    "summary":"",
    "tag":[{
      "href":"https://wedistribute.org/tags/fediverse",
      "name":"#fediverse",
      "type":"Hashtag"
    }],
    "type":"Note",
    "updated":"2024-04-11T20:55:29Z"
  }
}Code-Sprache: JSON / JSON mit Kommentaren (json)

Ich verstehe das Problem und finde die Idee generell nicht schlecht, aber eigentlich bietet ActivityPub alles Nötige schon von Haus aus! ActivityPub oder besser ActivityStreams ist so aufgebaut, dass alle Objekte von einem Art Base-Object abgeleitet werden. Das heißt Article, Note, Event oder Place, haben ein gleiches Minimal-Set an Attributen:

Und auch wenn beispielsweise Place oder Event einige spezifische Eigenschaften haben, die nicht jede Plattform „kennt“ und „versteht“, sollte es immer möglich sein, die Beschreibung (content oder summary) und den Titel (name) anzuzeigen.

Das Prinzip ist ähnlich wie, wenn nicht sogar inspiriert durch, schema.org/Thing. Auch hier basieren alle Objekte letztendlich auf einem Thing und trotz der wesentlich größeren Anzahl1 an Objekten und Attributen, können Suchmaschinen sich immer sicher sein, dass es zumindest einen name, eine description und eine url zum Anzeigen gibt.

Bevor wir über also über ein `content-fallback` nachdenken, sollten wir (meiner Meinung nach) erst einmal dafür sorgen, dass die vorhanden Möglichkeiten richtig genutzt werden.

  1. The vocabulary currently consists of 806 Types, 1474 Properties 14 Datatypes, 90 Enumerations and 480 Enumeration members. – https://schema.org/docs/schemas.html ↩︎

50 Kommentare zu “It’s a Thing!

  1. @pfefferle Da bin ich ganz deiner Meinung.

    Dass Mastodon und andere Anwendungen entscheiden, was vollständig und was nur (mittels summary, title, url…) konvertiert dargestellt wird, finde ich auch richtig. Schließlich wird ja auch die gesamte User Experience danach gestaltet.

    Aber es bleibt die Frage: Wie geht man mit noch unbekannten Typen um? Wie macht man deutlich, dass z.B. eine PodcastEpisode auch eine Erweiterung des Basistyps ist? Oder muss man das gar nicht?

    • Genau…

      Trotzdem nutzt Mastodon die Typen vollkommen inkonsequent. Schreibe ich einen Artikel unter 500 Zeichen, nimmt Mastodon trotzdem die unformatierte „Summary“. Schreibe ich dagegen eine 5000 Zeichen lange „Note“ wird sie trotz der lokalen Limitierung vollständig angezeigt.

      Das heißt dass Mastodon die „Note“ wie einen“Article“ behandelt und den „Article“ wie eine „Note“…

    • @linos Das Spannende ist ja, dass – wie @pfefferle bereits erwähnt hat, eine Note komplett dargestellt wird. D.h. es würde vollkommen ausreichen, wenn ein Article einfach genauso wie eine Note behandelt würde.

      BTW: Mich würde interessieren, wie Threads damit umgehen wird.

      • @Michael Vogel

        Das Spannende ist ja, dass – wie @Matthias Pfefferle bereits erwähnt hat, eine Note komplett dargestellt wird. D.h. es würde vollkommen ausreichen, wenn ein Article einfach genauso wie eine Note behandelt würde.

        Eingebettete Bilder werden aus Notes relativ unschön entfernt. Diese sollten denk ich in Article erhalten bleiben…

      • @heluecht @pfefferle Meiner Ansicht nach wäre es in vielen Fällen ausreichend, aber leider eben nicht in allen. Wichtig ist, wenn die empfangende Anwendung den "content" darstellt, dass dieser möglichst genauso informativ ist wie im original. Wenn also z.B. eine Tabelle verworfen wird ist das blöd und es sollte lieber verlinkt werden. Es hängt schon auch davon ab, wie komplex der Inhalt ist.

        • @pfefferle @linos Es gibt immer den Link zum Originalpost. D.h. wenn ein Inhalt mal etwas blöde formatiert aussieht, kann man immer noch auf den Originalbeitrag gehen. Aber es ist doch unumstritten, dass es für einen Großteil der Beiträge gut funktionieren würde.

          • @heluecht @pfefferle Ich sehe das ähnlich und würde auch eher dazu tendieren das einfach zu machen. Ein mögliches Gegenargument ist nur, dass ein "misslungener" Einzelfall vielleicht mehr Vertrauensverlust verursacht, bei Menschen die das Fediverse nutzen, als ein noch nicht vorhandenes Feature.

            Vielleicht gab es ja eh schon Diskussionen auf SocialHub oder so, was ein Artikel alles mindestens können sollte (auf der Empfängerseite).

  2. Does Mastodon actually use summary? (Or does it only do so for Notes? I thought Articles just got a link and nothing else.)

    (My main gripe with Mastodon isn’t that it doesn’t support Article, it is that is a pretty bad feed reader. There are much better readers for long-form posts.)

    I currently also “disguise” my Articles as Notes, and include only a title—marked up “incorrectly,” alas—excerpt, and permalink.

    But I’d love it if Mastodon (rather than try and become a full-fledged feed reader) would be able to “natively” recognize Articles’ (titles and) summaries!

    /cc @deadsuperhero

  3. @pfefferle @deadsuperhero Das ist übel, wird sich aber nicht vermeiden lassen. Ich hatte mal erwähnt, dass ich gerne eine Instanz fragen möchte, welche Typen sie denn versteht/akzeptiert, dann könnte "mein" Server reagieren und entsprechend übersetzen. Theoretisch würde es reichen, wenn ich Erfahre Mastondon in Version x.y, der Rest könnte statisch sein. Eine weitere Idee wäre eine "zentrale" (natürlich nicht, aber das geht noch nicht in meinen Kopf) zu haben, die Mapping Infos bereitstellt 😉

  4. @pfefferle @deadsuperhero Ich habe schon 2018 ein Issue im Repository von Mastodon erstellt, dass sich um die Problematik kümmert: github.com/mastodon/mastodon/i…

    Im Issue github.com/mastodon/mastodon/i… (auch von 2018) gibt es diesen Kommentar:

    I believe what we do now is convert an Article object into title + URL to the original, so you can view the post as it’s supposed to be, rather than trying to display it internally. So, I think this is resolved.

    Ich würde mich sehr freuen, wenn sich da etwas ändern würde. Aber ich sehe es nicht als Aufgabe, dass wir um Mastodon herumarbeiten. Es gibt augenscheinlich Mastodon-Forks, die Article unterstützen. Vielleicht kann jemand einen diesbezüglichen PR stellen.

  5. @Michael Vogel

    Aber ich sehe es nicht als Aufgabe, dass wir um Mastodon herumarbeiten.

    Nachvollziehbar. Mastodon kam später ins Rennen und müsste durch die Programmierer so gestaltet werden, dass es mit dem restlichen Fediverse kompatibel ist.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert