#mastodon

Arbeite übrigens daran, daß #Mammuthus - wie #Mastodon - öffentliche Beiträge pro Nutzendem auch als #RSS-Feed ausgeben kann. Im Labor sieht es aktuell schon gut aus.

Hier wird dann das gleiche URL-Schema wie bei Mastodon genutzt: Die Kurzschreibweise mit dem @-Symbol und einem angehängten .rss.

Demnach sollte es dann möglich sein, diesen Feed mit jedem RSS-konformen Reader zu abonnieren.

Mehr zum Thema RSS bzw. Web-Feeds:
https://de.wikipedia.org/wiki/RSS_(Web-Feed)

Übrigens, zum Thema #ActivityPub und so...

Ich sehe hier #Mastodon-Instanzen, die "Add"- und "Remove"-Aktivitäten föderieren, die keine "id" enthalten...

Das mag meine Software aktuell nicht... und irgendwo meine ich mich dunkel zu erinnern, daß ein "id"-Feld eigentlich Pflicht wäre... grübel...

#Mammuthus

@pachli@mastodon.social

Hi #Pachli, Hi Nik,

regarding the current Pachli 2.7.1 i have the feeling, there may be an issue regarding the display of the used app information.

Two fields in the #API response: application[name] and application[website].

If application[name] is set, but application[website] is not (it's nullable), it looks like the application[name] is not shown in Pachli.

Could you verify that? TIA.

CC @nikclayton@mastodon.social

P.S.: First seen with #Mammuthus as instance server type, but also found one sample from an instance using #Mastodon.

Wenn doch #Mastodon und Clients wie #Tusky bloß endlich eine Methode fänden, wie man ALT-Texte (Bildbeschreibungen) permanent speichern könnte.......

Wenigstens im eigenen Account........

Aber was weiß ich schon. Auf mich hört ja keine/r.

#Fediverse-Client #Tokodon

Tokodon ist ein Fediverse-Client für den #Desktop und nutzt die #Mastodon-#Client-#API, um sich mit Konten auf kompatiblen Instanzen zu verbinden.

Nach eigenen Angaben handelt es sich bei Tokodon um einen Mastodon-Client für #Linux (im Rahmen des #KDE-Projekts).

Website des Projekts:
https://apps.kde.org/de/tokodon/

Tokodon im Fediverse:
@tokodon@kde.social

(Medien: 1)

ActivityPub und Mastodon-Beiträge

#ActivityPub ist ein gern genutztes #Kommunikationsprotokoll im #Fediverse, mit dem sich Instanzen untereinander unterhalten und austauschen.

Die fediversale Plattform #Mastodon nennt die dortigen Beiträge #Tröts bzw. auf Englisch #Toots oder auch intern #Status (#statuses).

So weit, so gut. Nur kennt natürlich ActivityPub keine Mastodon-Bezeichnung wie #Tröt, #Toot oder Status.

ActivityPub bzw. das #Activity #Vocabulary kennt bzw. definiert Objekte wie etwa #Artikel (#Article), Audio, Dokument (Document), Ereignis (Event) und weitere.

Hier kommt der Objekttyp #Notiz (ggf. auch Mitteilung oder Hinweis, im englischen Original "#Note") ins Spiel.

Dies ist der Typ von Objekt, den Instanzen untereinander austauschen, wenn es um die Beiträge geht, die man auf einer Mastodon-Instanz verfaßt.

Auf Seiten der Mastodon-#Software versucht diese, einige andere Objekttypen bestmöglich zu konvertieren.

Eine explizite maximale Beitragslänge wird vom #Vokabular übrigens nicht vorgegeben. Das Objekt wird beschrieben als kurzes geschriebenes Werk, typischerweise nicht länger als ein einzelner Absatz.

Zum weiteren Einstieg ins Thema (für technisch Interessierte):
https://www.w3.org/TR/activitystreams-vocabulary/#dfn-note
https://www.w3.org/TR/activitypub/
https://docs.joinmastodon.org/spec/activitypub/#status

Dem geneigten Lesenden mag aufgefallen sein, daß das #W3C das "Activity Vocabulary" auf Mai 2017 datiert, "ActivityPub" allerdings auf Januar 2018.

#ActivityVocabulary

(Medien: 2)

ActivityPub und Mastodon-Umfragen

#ActivityPub ist ein gern genutztes #Kommunikationsprotokoll im #Fediverse, mit dem sich Instanzen untereinander unterhalten und austauschen. Die fediversale Plattform #Mastodon unterstützt Umfragen.

So weit, so gut. Nur, die Art und Weise, wie Mastodon Umfragen umsetzt, paßt nicht 100%ig zu der in ActivityPub bzw. im #Activity #Vocabulary definierten Form.

Demnach wäre eine #Frage (engl. #Question) nämlich eigentlich eine Aktivität und kein Objekt. Mastodon behandelt eine Frage allerdings als Objekt. Dies kann zu Verständigungsproblemen zwischen verschiedenen Instanztypen im Fediverse führen.

Mastodon-Instanzen untereinander verstehen sich. Auch #Mammuthus versteht sich auf Umfragen im Mastodon-Stil. Bei weiteren Fediverse-Plattformen (wie etwa #Friendica, #Pixelfed, #Firefish, etc.) wäre dies im Einzelfall zu klären.

Zum weiteren Einstieg ins Thema (für technisch Interessierte):
https://www.w3.org/TR/activitystreams-vocabulary/#dfn-question
https://docs.joinmastodon.org/spec/activitypub/#Question

Dem geneigten Lesenden mag aufgefallen sein, daß das #W3C das "Activity Vocabulary" auf Mai 2017 datiert, "ActivityPub" allerdings auf Januar 2018. Und letzteres keinen expliziten Bezug zu einer "Question" nimmt.

#Activity#Vocabulary #Poll #Umfrage #Umfragen

(Medien: 2)

#Fediverse-Client #MastoDeck

MastoDeck ist ein Fediverse-Client als alternative #Weboberfläche und nutzt die #Mastodon-#Client-#API, um sich mit Konten auf kompatiblen Instanzen zu verbinden.

Der sich nach eigenen Angaben in einer offenen Beta-Phase befindliche Mastodon-#Web-Client wird von Álex Barredo entwickelt.

Website des Projekts:
https://mastodeck.com/

MastoDeck im Fediverse:
@mastodeck@mastodon.social

(Medien: 1)

Das Fediverse im Stadt-Modell erläutert

Im #Fediverse ist die Rede von Instanzen, die zusammen kommunizieren und gemeinsam das föderierte Universum bilden. Da kommen technische Begriffe ins Spiel wie Server, Software, Protokoll usw. usf. - und Produkte wie #Mastodon, #Friendica, #Pixelfed und viele mehr sowie Protokolle wie #ActivityPub... und viele Details mehr.

Wie kann man sich das vorstellen, wenn wir mal davon ausgehen würden, daß Instanzen Städte auf einem Planeten sind?

Nehmen wir also mal an, eine #Instanz bzw. ein #Server bzw. ein #Knotenpunkt im #Fediversum wäre eine Stadt auf einem Planeten. Inklusive Bevölkerung. Diese Stadt kann auf einem Eigenbau basieren oder sie nutzt einen Bauplan für eine spezielle Art von Stadt. Dieser Bauplan wäre dann eine Serversoftware wie Mastodon oder #Firefish oder eine andere.

Leute können sich in einer bereits gebauten Stadt ansiedeln oder eine eigene Stadt aufbauen. Da viele Baupläne für speziell ausgerichtete Städte frei verfügbar existieren (Open Source!), kann diese neue Gemeinschaft auf Basis eines solchen Bauplans eine neue Stadt errichten. Oder etwas eigenes bauen, weil... und hier kommen wir zum nächsten Punkt.

Die Städte auf diesem Planeten sind durch Wege verbunden. Diese Wege sind genormt, damit die Städte sich untereinander austauschen können und die jeweiligen Stadtverwaltungen wissen, wie sie mit Informationen und Botschaften, die über diese Wege übermittelt werden, umgehen und nicht wie ein Ochs' vorm Berg dastehen. Viele Wege nutzen die Norm "ActivityPub". Dies erlaubt dann auch komplett neue Typen von Städten, sofern diese über standardisierte Wege an vorhandene Städe angeschlossen werden.

Soweit so klar?

Instanzen entsprechen Städten, die #User der Instanzen der jeweiligen Stadtbevölkerung, die #Administration einer Instanz entspricht der Stadtverwaltung einer Stadt, unterschiedliche Arten von #Serversoftware bzw. Baupläne regeln die Art des Stadtaufbaus und Protokolle entsprechen genormten Wegen zwischen Städten.

Was passiert nun, wenn ein Bewohner in Stadt A einer Bewohnerin in Stadt B folgen will? Im Hintergrund wird die Stadtverwaltung von Stadt A tätig und schickt über den Weg (zwischen den Städten) eine Botschaft zu Stadt B. Dort nimmt die Stadtverwaltung von Stadt B den Folgewunsch entgegen und bearbeitet ihn. Akzeptiert die Bewohnerin von Stadt B Folgeanfragen ohne manuelle Überprüfung ihrerseits, kann ihre Stadtverwaltung gleich im Hintergrund eine Bestätigungsbotschaft über den Weg zu Stadt A zurückschicken. Die Stadtverwaltungen der Städte A und B kennen nun die Folgebeziehung zwischen den beiden Bewohnenden und können gewissermaßen einen Vermerk im Stadtarchiv vornehmen. Wenn nun die Bewohnerin in Stadt B einen neuen Beitrag verfaßt, weiß ihre Stadtverwaltung, daß sie eine Botschaft mit diesem Beitrag über die Wegeverbindung zu Stadt A schicken muß, weil dort ein Bewohner Interesse angemeldet hat bzw. folgt. Die Stadtverwaltung von Stadt A weiß auch Bescheid und kann den Beitrag aus Stadt B für ihren Bewohner präsentieren.

Immer noch klar?

Macht dieses Städtegleichnis den Aufbau des föderierten Universums nun verständlicher, ändert es nichts oder wird es noch komplizierter? ;-)

Achso, die Fediverse-Adresse entspricht gewissermaßen dem Namen und der Anschrift der jeweiligen Bewohnenden der Städte. Die Adresse beinhaltet den Namen und die Stadt. Innerhalb einer Stadt reicht der Name aus, aber bei Botschaften zwischen Städten muß Namen und Stadt genannt werden. Und ja, das ist einer Telefonnummer mit Vorwahl nicht unähnlich.

Völlig verwirrt? Oder bestens ins Bild gesetzt?

Viel Spaß im Fediverse!

#Fediverse-Client #Pinafore

Pinafore ist ein Fediverse-Client als alternative #Weboberfläche und nutzt die #Mastodon-#Client-#API, um sich mit Konten auf kompatiblen Instanzen zu verbinden.

Der nach eigenen Angaben auf Geschwindigkeit und Einfachheit fokussierte Mastodon-#Web-Client wird von Nolan Lawson (@nolan@toot.cafe) entwickelt.

Website des Projekts:
https://pinafore.social/

Pinafore im Fediverse:
@pinafore@fosstodon.org

(Medien: 1)