Skip to main content


Das mit den Kommentaren ist schnell erklärt: Die Anzahl der Kommentare neben dem Symbol zeigt die Anzahl der direkten Kommentare an. D.h. 25 Leute haben direkt den Beitrag kommentiert, insgesamt befinden sich aber mehr Kommentare im Beitrag.

Und das mit den Likes und Reshares ist auch einfach erklärt: Wir müssen mit Limits beim Holen der Kommentare, Likes und Reshares arbeiten, ansonsten läuft der Speicher über. Die Zahl neben den Icons ist die korrekte Zahl.

@Michael Vogel
Ok, diese Limitierungen versteh ich.
ABER warum sind in der /network-Timeline andere Zahlen bei der Textbeschreibung wie wenn ich den Beitrag direkt anzeige?
Und warum werden für die Icons nicht die selben Zahlen verwendet, wie für die textliche Beschreibung der Likes und Reshares?
Und warum sind Likes auf einmal per Emoji-Reaktion und nicht beim Like-Button gezählt?

Auf der network-Seite gelten knappere Limits als auf der Einzelseite. Die Zahlen neben den Icons werden direkt per SQL berechnet, dadurch müssen keine Limits beachtet werden.

Das mit dem Like und Emoji-Reaktionen ist etwas, das gelegentlich passiert. Wieso, das weiß ich noch nicht.

@Michael Vogel Ja aber dann lassen wir doch bitte die Zahlen weg, bevor da irreführende und nicht zusammenstimmende Zahlen dort stehen.
@jakob 🇦🇹 ✅ @Michael Vogel
Du meinst die Zahlenangaben zu den klickbaren Likes oder Reshare, korrekt?
Ja, wenn die Angabe ungenau ist und zu Irritationen führen kann, dann sollte sie u.U. nicht mehr angezeigt werden oder der Wert neben den Icon übernommen werden. Wichtig ist jedoch, dass die Funktion als Solche erhalten bleibt. Sie wird von vielen Nutzenden nachgefragt.
Aber am Smartphone sind wieder die richtigen Zahlen beim Text, und keine bei den Buttons...
Es ist aber für mich immer noch unklar, warum die Anzahl der likes und shares als Text am Smartphone und am Desktop unterschiedlich ist...

@Sascha 😎 🏴

Das Preview ist ein wenig gewöhnungsbedürftig. 😁

Funktioniert nicht immer den Erwartungen entsprechend.

@Sascha 😎 🏴
Ok. Ich hätte das Problem mit dem Prieview eher so wahrgenommen, dass Youtube-Links meist gut funktionieren, bei Peertube gibt es immer wieder mal Probleme (oder war's umgekehrt?), die Quellen werden manchmal nicht korrekt oder gar nicht geparst und dargestellt werden.
Das Verteilen ist dann noch einmal ein Layer Komplexität drüber.

@Sascha 😎 🏴 Ich hab dich schon verstanden.

😀

@Sascha 😎 🏴 @jakob 🇦🇹 ✅
Das ist in verteilten Netzen wie den Fediverse schon immer so. Da unterscheiden sich die Plattformen nicht. Es ist immer nur eine ungefähre Angabe, wenn du nicht selbst der Versendet bist.
@Sascha 😎 🏴 @jakob 🇦🇹 ✅
Genau so ist es. Das war u.A. ein Kritikpunkte an Mastodon von verschiedenen Großköpfen.
@Sascha 😎 🏴 Als sie von Twitter kamen, waren Likes und Reshare ihre Währung. Auf Mastodon und im gesamten Fediverse ist diese Anzeige aber ungenau. Ergo waren ihre Werteschemata kaputt und Mastodon war blöd, weil es anders als zentrale Dienste funktioniert.
@Sascha 😎 🏴
'gefällt mir' und 'gefällt mir nicht' sind in Richtung anderer Plattformen wichtig. Und auch grundsätzlich habe ich nichts gegen die Bezeichnung einzuwenden. Das ist aber immer auch eine Typfrage

@Sascha 😎 🏴

AP hat die Emoji-Reactions mit dabei.

Pleroma nutzt sie, Friendica hatte sie kurzzeitig, zeigt sie auch an, wenn welche kommen.

@ONE ✔

@ONE
This entry was edited (1 year ago)
Sie wurden nicht entfernt. Wir können sie anzeigen, aber selber nicht senden.

@one @sascha @heluecht

Könnt Ihr genauer erläutern, wo und wie #ActivityPub Emoji-Reaktionen unterstützen soll?

Das "Activity Vocabulary" kennt "Like" und "Dislike"...

https://www.w3.org/TR/activitystreams-vocabulary/#activity-types

Es gibt zwei unterschiedliche Umsetzungen. Bei der einen (von Misskey), wird ein "Like" gesendet und zusätzlich ein Content übertragen. Bei der Umsetzung von Pleroma wurde das Protokoll erweitert.

@heluecht @one @sascha

Bei #Pleroma sind mir neulich schon Unterschiede in der Implementation im Vergleich zu #Mastodon aufgefallen (an anderer Stelle).

Wenn #Pleroma #ActivityPub "erweitert", würde es die Kompatibilität zum Standard brechen...!?!

ActivityPub ist dafür gebaut, erweitert zu werden. Friendica überträgt z.B. auch zusätzliche Felder für ein paar Daten, die wir die Diaspora-Kommunikation benötigen.

@heluecht @one @sascha

Weiß das W3C davon? 😉

Und ich dachte, #Diaspora unterstützt überhaupt kein #ActivityPub!?!

@sascha @heluecht @one

Ganz genau... wenn jede Implementation beliebig von der Empfehlung (Recommendation) abweicht, kann man sich ein Standardprotokoll auch sparen... 😉

Ernsthaft, beliebig neue Felder zu nutzen, mag vereinzelt 'ne nette Idee sein, bringt aber zwangsläufig Probleme in der Kommunikation mit sich...

Vergleiche mal die Art, wie #Microsoft & Co. z.B. den E-Mail-Standard unterlaufen... 🙁

AP wurde extra so gebaut, dass man es erweitern kann. Und bezüglich ActivityPub und AP: Ja, es unterstützt es nicht. Aber bei der "Friendica zu Friendica"-Kommunikation müssen wir zusätzliche Daten übertragen, damit Friendica-Kommentare auch zu Diaspora übertragen werden.
Es gibt eine gewisse Koordination der Entwickler: https://socialhub.activitypub.rocks/

@heluecht

Hab' die URL zwar in meinen Bookmarks, bin aber ziemlich selten da... 😉

@jakob @one @sascha

https://socialhub.activitypub.rocks/

@Sascha 😎 🏴 Wenn ich das richtig verstanden habe, dann werden die zusätzlichen Angaben für Diaspora über das Disapora Protokoll versendet. Das ist also ein Handling das in Friendica stattfindet und an der Außenkante nicht transparent wird.
Da das Diaspora Protokoll nicht gebastelt ist, wird deine Beschreibung dem Ganzen nicht gerecht. Es sind verschiedene Protokolle, die von Friendica unterstützt werden.

@Michael Vogel @Nordnick :verified: @jakob 🇦🇹 ✅ @ONE ✔

This entry was edited (1 year ago)

@feb

So hatte ich das verstanden und im Hinterkopf: #Friendica unterstützt mehrere Protokolle.

@heluecht @jakob @one @sascha

Moin am Montagmorgen an alle... 😀