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 Note
s.
Dabei könnte es so einfach sein!
@deadsuperhero schreibt auf seinem Blog, dass er eigentlich gerne Article
s 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:
attachment
attributedTo
audience
content
context
name
icon
image
inReplyTo
published
replies
summary
tag
updated
url
to
bto
cc
bcc
mediaType
- …und mehr
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.
- The vocabulary currently consists of 806 Types, 1474 Properties 14 Datatypes, 90 Enumerations and 480 Enumeration members. – https://schema.org/docs/schemas.html ↩︎
@pfefferle Ist denn dein Post jetzt als Article oder Note verpackt? Er kommt ja bestens formatiert an.
Rate mal ☺️
@pfefferle Öhm … du hast in den Settings was geändert. o.O
Es gibt nur noch Notes und WordPress Format. Da war vorher mehr. Ich hab immer nur Notes belassen, damit kein Salat rauskommt.
Ich hab’s aktuell auch auf „Note“, genau aus dem Grund!
@pfefferle auch spannend: ich bekomme alle deine Antworten in den Stream gespült, aber nicht, worauf du antwortest.
🤔
@pfefferle ah! Weil @notiz.blog alles boosted:
@dominik @pfefferle Geht mir, je nachdem, womit ich on bin, genauso. Es stellt sich noch ein weiteres Problem dar. Hubzilla schreibt im Thread nicht @ anwen die Antwort gerichtet ist. In Akkoma/Mastodon wird sie zwar korrekt als Teil der Diskussion angezeigt, aber der Empfänger bekommt keine Benachrichtigung.
@dominik @pfefferle Ja, der Thread ist vogelwild. 😄
Was denn, was denn? Das passt doch alles!?!
@pfefferle hm.
@pfefferle @dominik Ist das nicht eh ein Mastodonding mit den fehlenden Replies? Fedilab und Sengi machen das recht gut allerdings. Im Firefox hab ich ein Addon "Substitoot" dafür. Damit komm ich meistens gut klar. Den FediFetcher hab ich z. Zt. nicht mehr laufen. Der hat Unmengen an Content eingeholt (nomen est omen).
@morph 🤷🏻♂️ das Problem sind gar nicht die fehlenden Replies – die würde ich sicher sehen, wenn ich den Antwortenden auch folgen würde. Das Problem ist, dass ich die Antworten von @pfefferle völlig kontextlos im Hauptstream habe, da sie von @notiz.blog geboosted werden.
@dominik @pfefferle Ja, der Zähler neben dem Reply Icon ist auch immer auf Null. Als wären's Posts ohne Kontext.
@morph @pfefferle hm. Zumindest das sieht bei mir okay aus. Ich entfolgte nun @notiz.blog und ich denke, das hat geholfen
@pfefferle Hoffentlich macht John Mastodon da mal was dran.
@hamiller_friendica @wolf
@pfefferle @hamiller_friendica @wolf Ich ja auch! 🙂
@pfefferle @deadsuperhero wie ist es bei anderen Serversoftware (Friendica, Pleroma, Hubzilla, den xxx-keys…)?
Auf Friendi.ca und Pixelfed sehen `Article` aus wie sie sollen! Die anderen hab ich schon lange nicht mehr getestet.
@wolf Zumindest beherrschen Friendica, Hubzilla und Streams den Typ Article.
Friendica verwendet den ja auch, wenn man beim Erstellen des Beitrags einen Titel mit angibt.
@pfefferle @deadsuperhero
@ɟloʍ Hubzilla stellt Article vollständig dar aber sendet auch nur Notes aus genau dem selben Grund…
@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“…
@pfefferle @hamiller_friendica @wolf Blöde Frage, warum verlinkt ihr @Gargron nicht?
@NickBohle
weil es müßig und frustrierend ist. In Mastodon wurde ignoranter Weise leider schon immer versucht, eigene „Standards“ durch sture Ignoranz und nicht einhalten von Standards zu etablieren. Das restliche Fedi nutzt in einer Art „Selbstzensur“ sinnvolle Funktion nicht, weil man ja auch für die Mastis sinnvoll lesbar bleiben will. Viele posten z.B. auch nicht mehr als 4 Bilder, weil das 5. ja den Mastis vorenthalten wird…
@Gargron@mastodon.social @pfefferle @hamiller_friendica
Ich glaube @Gargron weiß bescheid und die Community arbeitet ja auch dran es schrittweise zu verbessern…
@pfefferle Verstehe ich. Die andere Perspektive wäre dennoch: eine Note sollte i.d.R. kürzer als ein Paragraph sein (lange Notes werden eingeklappt). Typischerweise enthält diese wenig Markup. Das Ziel ist es, dass man das prima in Mastodon lesen kann. Etwaige Bilder gehören zum ganzen Text.
Ein Artikel könnte schnell auch mal mehr Bilder haben, die auch zu bestimmten Textstellen gehören, und mehr Markup. Mastodon sagt: in unserer UI liest man das besser nicht, sondern auf der Originalseite.
@pfefferle Ich glaube es gibt einfach mehr Unterschiede, die eine Rolle spielen, als die reine Länge.
@pfefferle Und dass Mastodon immer noch die unformatierte Summary benutzt, ist ja hoffentlich nicht mehr lange so 🙂
Dennoch ist es leider erschreckend, wie viel Einfluss Mastodon, ohne es überhaupt zu wollen, hier auf andere Entwicklungen hat.
@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 einArticle
einfach genauso wie eineNote
behandelt würde.BTW: Mich würde interessieren, wie Threads damit umgehen wird.
@Michael Vogel
Eingebettete Bilder werden aus
Notes
relativ unschön entfernt. Diese sollten denk ich inArticle
erhalten bleiben…@mario Klar gibt es Steigerungspotential, aber im Moment ist es ja eher eine absichtliche Limitierung.
@Michael Vogel ja voll…
@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).
@pfefferle @linos Es wäre ja immer möglich, dass ein
Article
automatisch einen Disclaimer enthält, der darauf hinweist, dass man bei Formatierungsproblemen zum Originalbeitrag springen soll.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
They do support title, summary and link for Articles!
@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 😉
Das ist ein bisschen die Idee von @deadsuperhero, dass der Sender beeinflusst wie der Empfänger es anzeigen soll. In meinen Augen ist das aber gegen die Idee vom Fediverse. Als Sender sollte ich meine Inhalte „nur“ semantisch korrekt auszeichnen müssen und der Rest liegt beim Empfänger.
Deshalb ist es mir wichtig, dass Mastodon & Co. die Typen besser berücksichtigt als sie es jetzt gerade tun.
@pfefferle @heluecht @mario @skeptiker @wolf @NickBohle @hamiller_friendica @deadsuperhero
Bin ich voll bei Dir!
Ich werde jedoch eher Typen jenseits von Note und Article haben und dann wird es spannend. Ebenso mit Erweiterungen, die erst einmal entstehen müssen und dann standardisiert werden müssen.
@pfefferle @heluecht @mario @skeptiker @wolf @NickBohle @hamiller_friendica @deadsuperhero
Es wird inkompatible Typen zwischen verschiedenen Anwendungen geben. Und ich fände es schön, wenn mein Xyz. Auch als Note in Mastodon, etc. ansprechend angezeigt wird, auch wenn ein Zielsystem mit meinem xyz nichts anzufangen weiß.
Was macht denn Mastodon mit Events aus Mobilizon ?
@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:
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.🙄
@heluecht @pfefferle @deadsuperhero Ich stimme @Gargron da auch immer noch zu. Vielleicht wäre ein UI-Hinweis auf Mastodon-Seite, dass das Objekt konvertiert und wohl unvollständig ist eine denkbare Verbesserung.
Aus Sicht der Blogger wäre es vielleicht eine interessante Erweiterung per Post den Objekt-Typ definieren zu können. Manche Beiträge lassen sich gut zur Gänze auf Plattformen wie Mastodon lesen, andere vielleicht auch nicht so gut.
@Gargron @pfefferle @linos @deadsuperhero Naja, dieses ganze „Schau es Dir doch auf der Originalseite an“ klappt in dem Moment nicht mehr, wenn es ein nicht-öffentlicher Beitrag ist.
@pfefferle @deadsuperhero Meinem Eindruck nach tut sich da niemand schwer. Mir fallen ständig irgendwelche Unstimmigkeiten zwischen den einzelnen Frontends auf. 🙂
@Michael Vogel
Nachvollziehbar. Mastodon kam später ins Rennen und müsste durch die Programmierer so gestaltet werden, dass es mit dem restlichen Fediverse kompatibel ist.
@pfefferle@notiz.blog @pfefferle@mastodon.social @deadsuperhero My basic German knowledge made me understand Fediverse has the forever issue that traditional World Wide Web has: standards are in our hands if we want, but every service goes through their own path without using proper rules, and they mess all up. Same with Accessibility, meant as the compatibility with assistive tech. But interoperability is accessibility as well, beyond disability and so on.