#firefish — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #firefish, aggregated by home.social.
-
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!
-
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!
-
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!
-
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!
-
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!
-
I think you'd like Misskey. Anytime some development here pops up, the source is always Misskey.
I first joined the Fediverse on May 30, 2023, so Firefish was on its way out and buggy at the time, since its last update came before the project was all but abandoned. I'm told that before then, it was fun to use. But nevertheless, it was still Misskey under the hood.
-
-
Чет не распарсил :-( Миска не подходит? А -омас это что?
Чтобы не ограничинваться пиксельфедью, попробуй глянуть на https://vernissage.photos/
P.S. А на https://dvd.chat выделяют 200 Гб на рыло, фоточки хранятся в исходном формате и есть кошачьи ушки на аватарку. Но это #firefish
-
Fedistar v1.12.6
=> https://fedistar.netMulti-column Fediverse client application for desktop
- Supporting SNS
- - Mastodon
- - Pleroma
- - Friendica
- - Firefish
- - Gotosocial
- - Pixelfed
- - Akkoma (Unofficial)
- - Sharkey (Unofficial)
- - Hometown (Unofficial)
- - Iceshrimp (Unofficial)
- Multiple accounts management
- Multiple columns
- You can see timelines without sign in
- Desktop notification
- Streaming update
- Send reactions from another accounts
- Change column widthChangelog:
=> https://github.com/h3poteto/fedistar/releases/tag/v1.12.6#Fediverse #Mastodon #Pleroma #Friendica #Firefish #Gotosocial #Pixelfed #Akkoma #Sharkey #Hometown #Iceshrimp
-
Is there any reason to always see the "Mark all notifications as read" button, even when there are no unread notifications, besides cluttering the UI? Just made it appear only when unread notifications are over zero. Will deploy later today on catodon.rocks, along with the dedicated Direct messages page.
#Catodon #Sharkey #Firefish -
Here's the latest feature in Catodon's develop, for the upcoming 26.04 release - another suggestion by @germ !
As you may know, Catodon has Firefish's "threads in timeline" feature, which greatly declutters timelines for threads (instead of seeing 1st/2nd+2nd/3rd+3rd/4th etc, you just see 1st/2nd/3rd/4th once), but it can still get annoying with really long threads.
So, here's the improved edition: Collapsed threads. You will never see a thread longer than three posts - you'll get the collapsed version, with a link to view the full thread, and an indicator of how many more posts it has.
Also displayed in profile pages, which didn't have threads until now.
#Catodon :catodon: #Firefish -
The time has come and I'm beyond excited 😁
We just opened registrations on catodon.rocks.
I know that Catodon created a lot of expectations when Firefish fell apart, and I'm sure many of you were disappointed to see it not going anywhere for a long time. This time I am doing it on my own, so things will happen the way they should have. And, although you can now check it out for youselves, I will say this: I firmly believe that it's better, on every level, than Firefish ever was. I was in both projects, I love them both, but Catodon combines the best features of Firefish and Sharkey, while also being very debloated, being much more comprehensible, and adding actually useful stuff - and I have more plans for the future.
I'd love to hear your feedback on the UX of Catodon, and see how we can improve it further! Let's create the fedi experience we deserve =)
:catodon:
#Catodon #Fediverse #Firefish #Sharkey
RE: https://catodon.rocks/notes/ajo1s763f05z0002 -
Sharkey/Misskey users: Would it make a real difference to you if you could only upload media files instead of any file to your Drive? I'm thinking of restricting it to media files (and only from https) for Catodon, for security reasons. I doubt any of the users in our 3+ years old Firefish server uploaded any other type of file.
#Sharkey #Misskey #Firefish #Catodon -
CW: Misskey only allows for 512 characters of alt-text which is bad for my image posts; CW: long (over 8,600 characters), Fediverse meta, Fediverse-beyond-Mastodon meta, alt-text meta, character limit meta, content warning meta
Just the other day, I found something out. Something very inconvenient about Misskey and maybe also the Forkeys.
It should be commonly known that Misskey has a local limit of 3,000 characters for posts (which it refers to as "notes"). What is not so well-known is that Misskey has a limit of about 8,000 characters, probably 8,192 or so, for inbound messages, ironically fewer than this post is long. Also, it has a limit of 512 characters for alt-text, both locally and in-bound.
Mastodon has a character limit for in-bound content, too, at least for Note-type objects (not for Article-type objects because it refuses to render them fully and links to the original instead). To my best knowledge, it rejects messages with over 100,000 characters. As for its 1,500-charater limit for alt-text, it enforces that by truncating alt-text that's longer.
Misskey, in contrast, truncates everything that exceeds its limits while still letting it in. If your post is longer than the inbound limit of ca. 8,000, all excess characters are chopped off and thrown away. If your alt-text is longer than 512 characters, all excess characters are chopped off and thrown away.
I don't know which Forkey behaves how in this regard, seeing as all Forkeys I know about have a configurable local post character limit that can be adjusted to well over 8,000. But even if the inbound limit is configurable, too, I don't think any *key admin cranks it over 60,000 or over 70,000 or over 100,000. It's simply unimaginable that someone, anyone, could ever post that much at once if your idea of the Fediverse is pure microblogging.
Also, I don't know what *key users do when they come across a truncated post or what blind or visually-impaired *key users do when they come across a truncated alt-text. Do they even suspect that it's a truncated copy of something that's longer at its source and then go check the source? Either way, it's very inconvenient.
It's especially inconvenient for me. My longest posts by a gigantic margin are image posts with original images. They always have a long image description block in the post itself that tends to be tens of thousands of characters long. It contains highly detailed visual descriptions of all images in the post. It contains all explanations necessary to understand the post, the images and the descriptions. It contains verbatim transcripts of all bits of text within the borders of the image that I can read, no matter whether or not my audience can.
In addition, each image has a shorter description in the alt-text, along with a bit that announces the long description, including where to find it. I even used to explain how to get to that description for Mastodon users for whom the summary and content warning hides the post text, but not the images, depending on which Mastodon version and frontend they use. This alone took up several hundred characters in the alt-text. All in all, I got to a point in which my alt-texts always ended up either at precisely 1,500 characters or just a few characters short.
I myself am not really bound to character limits. I used to post images here on Hubzilla where I have over 16.7 million characters for the post, including all alt-texts. Now I post them on (streams) where I have over 24 million characters. I could theoretically write alt-texts as long as I want to, seeing as, unlike on Mastodon, they aren't separate text fields; instead, they're being woven into the image-embedding markup code in the post text.
Still, I stick to a maximum of 1,500 characters for alt-text to keep Mastodon from truncating it. If you post images into the Fediverse, the main audience for your alt-text is on Mastodon, and most of them don't understand that there's something, anything, out there in the Fediverse that does not work exactly like Mastodon. And 1,500 characters can be tight already.
But if I have to stay within Misskey's limits, I can hardly post images anymore. At least not with appropriate descriptions and explanations.
Since late 2024, I have been working on-and-off on a series of fairly simple avatar portraits or rather their image descriptions. The idea is for the long description to consist of a preamble that starts with a general summary, followed by explanations, then followed by visual descriptions of what all images in the post have in common. Next come the individual descriptions of each image. Each post shall have three or four images with three or four portraits each, all in the same pose, all with only minor differences in outfits, all with a neutral, bright white background.
In addition, of course, each image shall have an alt-text, and none of the alt-texts shall depend on each other.
Now, the problem is that I have to describe three or four individual portraits in each alt-text. I'm actually struggling to squeeze such a description plus the note that announces the long description into 1,500 characters, especially if I want to fulfill Veronica Lewis a.k.a. Veronica With Four Eyes' requirements for outfit descriptions to a tee in the alt-text as well (https://veroniiiica.com/how-to-write-alt-text-for-casual-outfits/, https://veroniiiica.com/writing-image-descriptions-for-red-carpet-outfits/; see also https://veroniiiica.com/how-to-write-alt-text-image-descriptions-visually-impaired/ and https://veroniiiica.com/how-to-create-visual-descriptions/).
But in 512 characters so that even Misskey users won't get a severely truncated version? This is absolutely impossible. Even if I limit the long description announcement to some 100 characters, even if I didn't walk people through how to get to the long description, I'd have fewer than 140 characters on average to describe each individual outfit.
The long description won't fare any better. Currently, the preamble starts with some 14,000 characters of explanations, most of which are necessary to understand the visual descriptions. But when Misskey goes and truncates the post at the 8,000-something mark, Misskey users won't even get to any visual description because all visual descriptions would be chopped off.
What makes matters worse is that the preamble grows the longer, the easier to understand I make it and the less I leave people with unexplained technical or jargon terms which you shouldn't use in image descriptions at all anyway. So the next time I go through it and rewrite it to make it easier to understand, I'll also make it even longer than it already is.
But what if I simply cut all the explanations? For one, I'd leave people to their own devices to understand extremely obscure niche content. They won't. My explanations aren't 14,000 characters long because I've artificially inflated them, but because there is so much to know before you understand the post and the images and the descriptions.
Besides, the visual descriptions alone won't fit into 8,192 characters either. What I currently have is over 5,000 characters of common visual description for all portraits in all images plus about 2,500 characters of individual visual description for the three portraits in the first image. That's over 7,500 characters altogether already. And I still have to describe nine portraits in another three images. The post will end up with some 15,000 characters of visual descriptions unless they grow longer when I simplify them again.
I guess users of Misskey or any Forkey will still have to put up with truncated alt-texts and truncated long descriptions in the future. But my future image posts will contain a paragraph at the beginning that explains that the post and/or the alt-text may be truncated on Misskey and the Forkeys, and that both are uncut at the source. Still, this means that *key users will have to put up with the extra hassle of opening my original post at a source with a quite cumbersome UI. And I've got my doubts that this UI is really accessible.
Unfortunately, this also means that *key users won't get any hashtags along with these posts. But then again, the handling of Identi.ca-style/Friendica-style hashtags with the number sign outside the link is broken on all *keys and will remain so for the foreseeable future.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Misskey #Forkey #Forkeys #Calckey #Firefish #Sharkey #CherryPick #Iceshrimp #Iceshrimp-JS #AltText #AltTextMeta #CWAltTextMeta #ImageDescription #ImageDescriptions #ImageDescriptionMeta #CWImageDescriptionMeta #CW #CWs #CWMeta #ContentWarning #ContentWarnings #ContentWarningMeta #CharacterLimit #CharacterLimits #CharacterLimitMeta #CWCharacterLimitMeta #A11y #Accessibility -
CW: Misskey only allows for 512 characters of alt-text which is bad for my image posts; CW: long (over 8,600 characters), Fediverse meta, Fediverse-beyond-Mastodon meta, alt-text meta, character limit meta, content warning meta
Just the other day, I found something out. Something very inconvenient about Misskey and maybe also the Forkeys.
It should be commonly known that Misskey has a local limit of 3,000 characters for posts (which it refers to as "notes"). What is not so well-known is that Misskey has a limit of about 8,000 characters, probably 8,192 or so, for inbound messages, ironically fewer than this post is long. Also, it has a limit of 512 characters for alt-text, both locally and in-bound.
Mastodon has a character limit for in-bound content, too, at least for Note-type objects (not for Article-type objects because it refuses to render them fully and links to the original instead). To my best knowledge, it rejects messages with over 100,000 characters. As for its 1,500-charater limit for alt-text, it enforces that by truncating alt-text that's longer.
Misskey, in contrast, truncates everything that exceeds its limits while still letting it in. If your post is longer than the inbound limit of ca. 8,000, all excess characters are chopped off and thrown away. If your alt-text is longer than 512 characters, all excess characters are chopped off and thrown away.
I don't know which Forkey behaves how in this regard, seeing as all Forkeys I know about have a configurable local post character limit that can be adjusted to well over 8,000. But even if the inbound limit is configurable, too, I don't think any *key admin cranks it over 60,000 or over 70,000 or over 100,000. It's simply unimaginable that someone, anyone, could ever post that much at once if your idea of the Fediverse is pure microblogging.
Also, I don't know what *key users do when they come across a truncated post or what blind or visually-impaired *key users do when they come across a truncated alt-text. Do they even suspect that it's a truncated copy of something that's longer at its source and then go check the source? Either way, it's very inconvenient.
It's especially inconvenient for me. My longest posts by a gigantic margin are image posts with original images. They always have a long image description block in the post itself that tends to be tens of thousands of characters long. It contains highly detailed visual descriptions of all images in the post. It contains all explanations necessary to understand the post, the images and the descriptions. It contains verbatim transcripts of all bits of text within the borders of the image that I can read, no matter whether or not my audience can.
In addition, each image has a shorter description in the alt-text, along with a bit that announces the long description, including where to find it. I even used to explain how to get to that description for Mastodon users for whom the summary and content warning hides the post text, but not the images, depending on which Mastodon version and frontend they use. This alone took up several hundred characters in the alt-text. All in all, I got to a point in which my alt-texts always ended up either at precisely 1,500 characters or just a few characters short.
I myself am not really bound to character limits. I used to post images here on Hubzilla where I have over 16.7 million characters for the post, including all alt-texts. Now I post them on (streams) where I have over 24 million characters. I could theoretically write alt-texts as long as I want to, seeing as, unlike on Mastodon, they aren't separate text fields; instead, they're being woven into the image-embedding markup code in the post text.
Still, I stick to a maximum of 1,500 characters for alt-text to keep Mastodon from truncating it. If you post images into the Fediverse, the main audience for your alt-text is on Mastodon, and most of them don't understand that there's something, anything, out there in the Fediverse that does not work exactly like Mastodon. And 1,500 characters can be tight already.
But if I have to stay within Misskey's limits, I can hardly post images anymore. At least not with appropriate descriptions and explanations.
Since late 2024, I have been working on-and-off on a series of fairly simple avatar portraits or rather their image descriptions. The idea is for the long description to consist of a preamble that starts with a general summary, followed by explanations, then followed by visual descriptions of what all images in the post have in common. Next come the individual descriptions of each image. Each post shall have three or four images with three or four portraits each, all in the same pose, all with only minor differences in outfits, all with a neutral, bright white background.
In addition, of course, each image shall have an alt-text, and none of the alt-texts shall depend on each other.
Now, the problem is that I have to describe three or four individual portraits in each alt-text. I'm actually struggling to squeeze such a description plus the note that announces the long description into 1,500 characters, especially if I want to fulfill Veronica Lewis a.k.a. Veronica With Four Eyes' requirements for outfit descriptions to a tee in the alt-text as well (https://veroniiiica.com/how-to-write-alt-text-for-casual-outfits/, https://veroniiiica.com/writing-image-descriptions-for-red-carpet-outfits/; see also https://veroniiiica.com/how-to-write-alt-text-image-descriptions-visually-impaired/ and https://veroniiiica.com/how-to-create-visual-descriptions/).
But in 512 characters so that even Misskey users won't get a severely truncated version? This is absolutely impossible. Even if I limit the long description announcement to some 100 characters, even if I didn't walk people through how to get to the long description, I'd have fewer than 140 characters on average to describe each individual outfit.
The long description won't fare any better. Currently, the preamble starts with some 14,000 characters of explanations, most of which are necessary to understand the visual descriptions. But when Misskey goes and truncates the post at the 8,000-something mark, Misskey users won't even get to any visual description because all visual descriptions would be chopped off.
What makes matters worse is that the preamble grows the longer, the easier to understand I make it and the less I leave people with unexplained technical or jargon terms which you shouldn't use in image descriptions at all anyway. So the next time I go through it and rewrite it to make it easier to understand, I'll also make it even longer than it already is.
But what if I simply cut all the explanations? For one, I'd leave people to their own devices to understand extremely obscure niche content. They won't. My explanations aren't 14,000 characters long because I've artificially inflated them, but because there is so much to know before you understand the post and the images and the descriptions.
Besides, the visual descriptions alone won't fit into 8,192 characters either. What I currently have is over 5,000 characters of common visual description for all portraits in all images plus about 2,500 characters of individual visual description for the three portraits in the first image. That's over 7,500 characters altogether already. And I still have to describe nine portraits in another three images. The post will end up with some 15,000 characters of visual descriptions unless they grow longer when I simplify them again.
I guess users of Misskey or any Forkey will still have to put up with truncated alt-texts and truncated long descriptions in the future. But my future image posts will contain a paragraph at the beginning that explains that the post and/or the alt-text may be truncated on Misskey and the Forkeys, and that both are uncut at the source. Still, this means that *key users will have to put up with the extra hassle of opening my original post at a source with a quite cumbersome UI. And I've got my doubts that this UI is really accessible.
Unfortunately, this also means that *key users won't get any hashtags along with these posts. But then again, the handling of Identi.ca-style/Friendica-style hashtags with the number sign outside the link is broken on all *keys and will remain so for the foreseeable future.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Misskey #Forkey #Forkeys #Calckey #Firefish #Sharkey #CherryPick #Iceshrimp #Iceshrimp-JS #AltText #AltTextMeta #CWAltTextMeta #ImageDescription #ImageDescriptions #ImageDescriptionMeta #CWImageDescriptionMeta #CW #CWs #CWMeta #ContentWarning #ContentWarnings #ContentWarningMeta #CharacterLimit #CharacterLimits #CharacterLimitMeta #CWCharacterLimitMeta #A11y #Accessibility -
CW: Misskey only allows for 512 characters of alt-text which is bad for my image posts; CW: long (over 8,600 characters), Fediverse meta, Fediverse-beyond-Mastodon meta, alt-text meta, character limit meta, content warning meta
Just the other day, I found something out. Something very inconvenient about Misskey and maybe also the Forkeys.
It should be commonly known that Misskey has a local limit of 3,000 characters for posts (which it refers to as "notes"). What is not so well-known is that Misskey has a limit of about 8,000 characters, probably 8,192 or so, for inbound messages, ironically fewer than this post is long. Also, it has a limit of 512 characters for alt-text, both locally and in-bound.
Mastodon has a character limit for in-bound content, too, at least for Note-type objects (not for Article-type objects because it refuses to render them fully and links to the original instead). To my best knowledge, it rejects messages with over 100,000 characters. As for its 1,500-charater limit for alt-text, it enforces that by truncating alt-text that's longer.
Misskey, in contrast, truncates everything that exceeds its limits while still letting it in. If your post is longer than the inbound limit of ca. 8,000, all excess characters are chopped off and thrown away. If your alt-text is longer than 512 characters, all excess characters are chopped off and thrown away.
I don't know which Forkey behaves how in this regard, seeing as all Forkeys I know about have a configurable local post character limit that can be adjusted to well over 8,000. But even if the inbound limit is configurable, too, I don't think any *key admin cranks it over 60,000 or over 70,000 or over 100,000. It's simply unimaginable that someone, anyone, could ever post that much at once if your idea of the Fediverse is pure microblogging.
Also, I don't know what *key users do when they come across a truncated post or what blind or visually-impaired *key users do when they come across a truncated alt-text. Do they even suspect that it's a truncated copy of something that's longer at its source and then go check the source? Either way, it's very inconvenient.
It's especially inconvenient for me. My longest posts by a gigantic margin are image posts with original images. They always have a long image description block in the post itself that tends to be tens of thousands of characters long. It contains highly detailed visual descriptions of all images in the post. It contains all explanations necessary to understand the post, the images and the descriptions. It contains verbatim transcripts of all bits of text within the borders of the image that I can read, no matter whether or not my audience can.
In addition, each image has a shorter description in the alt-text, along with a bit that announces the long description, including where to find it. I even used to explain how to get to that description for Mastodon users for whom the summary and content warning hides the post text, but not the images, depending on which Mastodon version and frontend they use. This alone took up several hundred characters in the alt-text. All in all, I got to a point in which my alt-texts always ended up either at precisely 1,500 characters or just a few characters short.
I myself am not really bound to character limits. I used to post images here on Hubzilla where I have over 16.7 million characters for the post, including all alt-texts. Now I post them on (streams) where I have over 24 million characters. I could theoretically write alt-texts as long as I want to, seeing as, unlike on Mastodon, they aren't separate text fields; instead, they're being woven into the image-embedding markup code in the post text.
Still, I stick to a maximum of 1,500 characters for alt-text to keep Mastodon from truncating it. If you post images into the Fediverse, the main audience for your alt-text is on Mastodon, and most of them don't understand that there's something, anything, out there in the Fediverse that does not work exactly like Mastodon. And 1,500 characters can be tight already.
But if I have to stay within Misskey's limits, I can hardly post images anymore. At least not with appropriate descriptions and explanations.
Since late 2024, I have been working on-and-off on a series of fairly simple avatar portraits or rather their image descriptions. The idea is for the long description to consist of a preamble that starts with a general summary, followed by explanations, then followed by visual descriptions of what all images in the post have in common. Next come the individual descriptions of each image. Each post shall have three or four images with three or four portraits each, all in the same pose, all with only minor differences in outfits, all with a neutral, bright white background.
In addition, of course, each image shall have an alt-text, and none of the alt-texts shall depend on each other.
Now, the problem is that I have to describe three or four individual portraits in each alt-text. I'm actually struggling to squeeze such a description plus the note that announces the long description into 1,500 characters, especially if I want to fulfill Veronica Lewis a.k.a. Veronica With Four Eyes' requirements for outfit descriptions to a tee in the alt-text as well (https://veroniiiica.com/how-to-write-alt-text-for-casual-outfits/, https://veroniiiica.com/writing-image-descriptions-for-red-carpet-outfits/; see also https://veroniiiica.com/how-to-write-alt-text-image-descriptions-visually-impaired/ and https://veroniiiica.com/how-to-create-visual-descriptions/).
But in 512 characters so that even Misskey users won't get a severely truncated version? This is absolutely impossible. Even if I limit the long description announcement to some 100 characters, even if I didn't walk people through how to get to the long description, I'd have fewer than 140 characters on average to describe each individual outfit.
The long description won't fare any better. Currently, the preamble starts with some 14,000 characters of explanations, most of which are necessary to understand the visual descriptions. But when Misskey goes and truncates the post at the 8,000-something mark, Misskey users won't even get to any visual description because all visual descriptions would be chopped off.
What makes matters worse is that the preamble grows the longer, the easier to understand I make it and the less I leave people with unexplained technical or jargon terms which you shouldn't use in image descriptions at all anyway. So the next time I go through it and rewrite it to make it easier to understand, I'll also make it even longer than it already is.
But what if I simply cut all the explanations? For one, I'd leave people to their own devices to understand extremely obscure niche content. They won't. My explanations aren't 14,000 characters long because I've artificially inflated them, but because there is so much to know before you understand the post and the images and the descriptions.
Besides, the visual descriptions alone won't fit into 8,192 characters either. What I currently have is over 5,000 characters of common visual description for all portraits in all images plus about 2,500 characters of individual visual description for the three portraits in the first image. That's over 7,500 characters altogether already. And I still have to describe nine portraits in another three images. The post will end up with some 15,000 characters of visual descriptions unless they grow longer when I simplify them again.
I guess users of Misskey or any Forkey will still have to put up with truncated alt-texts and truncated long descriptions in the future. But my future image posts will contain a paragraph at the beginning that explains that the post and/or the alt-text may be truncated on Misskey and the Forkeys, and that both are uncut at the source. Still, this means that *key users will have to put up with the extra hassle of opening my original post at a source with a quite cumbersome UI. And I've got my doubts that this UI is really accessible.
Unfortunately, this also means that *key users won't get any hashtags along with these posts. But then again, the handling of Identi.ca-style/Friendica-style hashtags with the number sign outside the link is broken on all *keys and will remain so for the foreseeable future.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Misskey #Forkey #Forkeys #Calckey #Firefish #Sharkey #CherryPick #Iceshrimp #Iceshrimp-JS #AltText #AltTextMeta #CWAltTextMeta #ImageDescription #ImageDescriptions #ImageDescriptionMeta #CWImageDescriptionMeta #CW #CWs #CWMeta #ContentWarning #ContentWarnings #ContentWarningMeta #CharacterLimit #CharacterLimits #CharacterLimitMeta #CWCharacterLimitMeta #A11y #Accessibility -
CW: Misskey only allows for 512 characters of alt-text which is bad for my image posts; CW: long (over 8,600 characters), Fediverse meta, Fediverse-beyond-Mastodon meta, alt-text meta, character limit meta, content warning meta
Just the other day, I found something out. Something very inconvenient about Misskey and maybe also the Forkeys.
It should be commonly known that Misskey has a local limit of 3,000 characters for posts (which it refers to as "notes"). What is not so well-known is that Misskey has a limit of about 8,000 characters, probably 8,192 or so, for inbound messages, ironically fewer than this post is long. Also, it has a limit of 512 characters for alt-text, both locally and in-bound.
Mastodon has a character limit for in-bound content, too, at least for Note-type objects (not for Article-type objects because it refuses to render them fully and links to the original instead). To my best knowledge, it rejects messages with over 100,000 characters. As for its 1,500-charater limit for alt-text, it enforces that by truncating alt-text that's longer.
Misskey, in contrast, truncates everything that exceeds its limits while still letting it in. If your post is longer than the inbound limit of ca. 8,000, all excess characters are chopped off and thrown away. If your alt-text is longer than 512 characters, all excess characters are chopped off and thrown away.
I don't know which Forkey behaves how in this regard, seeing as all Forkeys I know about have a configurable local post character limit that can be adjusted to well over 8,000. But even if the inbound limit is configurable, too, I don't think any *key admin cranks it over 60,000 or over 70,000 or over 100,000. It's simply unimaginable that someone, anyone, could ever post that much at once if your idea of the Fediverse is pure microblogging.
Also, I don't know what *key users do when they come across a truncated post or what blind or visually-impaired *key users do when they come across a truncated alt-text. Do they even suspect that it's a truncated copy of something that's longer at its source and then go check the source? Either way, it's very inconvenient.
It's especially inconvenient for me. My longest posts by a gigantic margin are image posts with original images. They always have a long image description block in the post itself that tends to be tens of thousands of characters long. It contains highly detailed visual descriptions of all images in the post. It contains all explanations necessary to understand the post, the images and the descriptions. It contains verbatim transcripts of all bits of text within the borders of the image that I can read, no matter whether or not my audience can.
In addition, each image has a shorter description in the alt-text, along with a bit that announces the long description, including where to find it. I even used to explain how to get to that description for Mastodon users for whom the summary and content warning hides the post text, but not the images, depending on which Mastodon version and frontend they use. This alone took up several hundred characters in the alt-text. All in all, I got to a point in which my alt-texts always ended up either at precisely 1,500 characters or just a few characters short.
I myself am not really bound to character limits. I used to post images here on Hubzilla where I have over 16.7 million characters for the post, including all alt-texts. Now I post them on (streams) where I have over 24 million characters. I could theoretically write alt-texts as long as I want to, seeing as, unlike on Mastodon, they aren't separate text fields; instead, they're being woven into the image-embedding markup code in the post text.
Still, I stick to a maximum of 1,500 characters for alt-text to keep Mastodon from truncating it. If you post images into the Fediverse, the main audience for your alt-text is on Mastodon, and most of them don't understand that there's something, anything, out there in the Fediverse that does not work exactly like Mastodon. And 1,500 characters can be tight already.
But if I have to stay within Misskey's limits, I can hardly post images anymore. At least not with appropriate descriptions and explanations.
Since late 2024, I have been working on-and-off on a series of fairly simple avatar portraits or rather their image descriptions. The idea is for the long description to consist of a preamble that starts with a general summary, followed by explanations, then followed by visual descriptions of what all images in the post have in common. Next come the individual descriptions of each image. Each post shall have three or four images with three or four portraits each, all in the same pose, all with only minor differences in outfits, all with a neutral, bright white background.
In addition, of course, each image shall have an alt-text, and none of the alt-texts shall depend on each other.
Now, the problem is that I have to describe three or four individual portraits in each alt-text. I'm actually struggling to squeeze such a description plus the note that announces the long description into 1,500 characters, especially if I want to fulfill Veronica Lewis a.k.a. Veronica With Four Eyes' requirements for outfit descriptions to a tee in the alt-text as well (https://veroniiiica.com/how-to-write-alt-text-for-casual-outfits/, https://veroniiiica.com/writing-image-descriptions-for-red-carpet-outfits/; see also https://veroniiiica.com/how-to-write-alt-text-image-descriptions-visually-impaired/ and https://veroniiiica.com/how-to-create-visual-descriptions/).
But in 512 characters so that even Misskey users won't get a severely truncated version? This is absolutely impossible. Even if I limit the long description announcement to some 100 characters, even if I didn't walk people through how to get to the long description, I'd have fewer than 140 characters on average to describe each individual outfit.
The long description won't fare any better. Currently, the preamble starts with some 14,000 characters of explanations, most of which are necessary to understand the visual descriptions. But when Misskey goes and truncates the post at the 8,000-something mark, Misskey users won't even get to any visual description because all visual descriptions would be chopped off.
What makes matters worse is that the preamble grows the longer, the easier to understand I make it and the less I leave people with unexplained technical or jargon terms which you shouldn't use in image descriptions at all anyway. So the next time I go through it and rewrite it to make it easier to understand, I'll also make it even longer than it already is.
But what if I simply cut all the explanations? For one, I'd leave people to their own devices to understand extremely obscure niche content. They won't. My explanations aren't 14,000 characters long because I've artificially inflated them, but because there is so much to know before you understand the post and the images and the descriptions.
Besides, the visual descriptions alone won't fit into 8,192 characters either. What I currently have is over 5,000 characters of common visual description for all portraits in all images plus about 2,500 characters of individual visual description for the three portraits in the first image. That's over 7,500 characters altogether already. And I still have to describe nine portraits in another three images. The post will end up with some 15,000 characters of visual descriptions unless they grow longer when I simplify them again.
I guess users of Misskey or any Forkey will still have to put up with truncated alt-texts and truncated long descriptions in the future. But my future image posts will contain a paragraph at the beginning that explains that the post and/or the alt-text may be truncated on Misskey and the Forkeys, and that both are uncut at the source. Still, this means that *key users will have to put up with the extra hassle of opening my original post at a source with a quite cumbersome UI. And I've got my doubts that this UI is really accessible.
Unfortunately, this also means that *key users won't get any hashtags along with these posts. But then again, the handling of Identi.ca-style/Friendica-style hashtags with the number sign outside the link is broken on all *keys and will remain so for the foreseeable future.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Misskey #Forkey #Forkeys #Calckey #Firefish #Sharkey #CherryPick #Iceshrimp #Iceshrimp-JS #AltText #AltTextMeta #CWAltTextMeta #ImageDescription #ImageDescriptions #ImageDescriptionMeta #CWImageDescriptionMeta #CW #CWs #CWMeta #ContentWarning #ContentWarnings #ContentWarningMeta #CharacterLimit #CharacterLimits #CharacterLimitMeta #CWCharacterLimitMeta #A11y #Accessibility -
CW: Misskey only allows for 512 characters of alt-text which is bad for my image posts; CW: long (over 8,600 characters), Fediverse meta, Fediverse-beyond-Mastodon meta, alt-text meta, character limit meta, content warning meta
Just the other day, I found something out. Something very inconvenient about Misskey and maybe also the Forkeys.
It should be commonly known that Misskey has a local limit of 3,000 characters for posts (which it refers to as "notes"). What is not so well-known is that Misskey has a limit of about 8,000 characters, probably 8,192 or so, for inbound messages, ironically fewer than this post is long. Also, it has a limit of 512 characters for alt-text, both locally and in-bound.
Mastodon has a character limit for in-bound content, too, at least for Note-type objects (not for Article-type objects because it refuses to render them fully and links to the original instead). To my best knowledge, it rejects messages with over 100,000 characters. As for its 1,500-charater limit for alt-text, it enforces that by truncating alt-text that's longer.
Misskey, in contrast, truncates everything that exceeds its limits while still letting it in. If your post is longer than the inbound limit of ca. 8,000, all excess characters are chopped off and thrown away. If your alt-text is longer than 512 characters, all excess characters are chopped off and thrown away.
I don't know which Forkey behaves how in this regard, seeing as all Forkeys I know about have a configurable local post character limit that can be adjusted to well over 8,000. But even if the inbound limit is configurable, too, I don't think any *key admin cranks it over 60,000 or over 70,000 or over 100,000. It's simply unimaginable that someone, anyone, could ever post that much at once if your idea of the Fediverse is pure microblogging.
Also, I don't know what *key users do when they come across a truncated post or what blind or visually-impaired *key users do when they come across a truncated alt-text. Do they even suspect that it's a truncated copy of something that's longer at its source and then go check the source? Either way, it's very inconvenient.
It's especially inconvenient for me. My longest posts by a gigantic margin are image posts with original images. They always have a long image description block in the post itself that tends to be tens of thousands of characters long. It contains highly detailed visual descriptions of all images in the post. It contains all explanations necessary to understand the post, the images and the descriptions. It contains verbatim transcripts of all bits of text within the borders of the image that I can read, no matter whether or not my audience can.
In addition, each image has a shorter description in the alt-text, along with a bit that announces the long description, including where to find it. I even used to explain how to get to that description for Mastodon users for whom the summary and content warning hides the post text, but not the images, depending on which Mastodon version and frontend they use. This alone took up several hundred characters in the alt-text. All in all, I got to a point in which my alt-texts always ended up either at precisely 1,500 characters or just a few characters short.
I myself am not really bound to character limits. I used to post images here on Hubzilla where I have over 16.7 million characters for the post, including all alt-texts. Now I post them on (streams) where I have over 24 million characters. I could theoretically write alt-texts as long as I want to, seeing as, unlike on Mastodon, they aren't separate text fields; instead, they're being woven into the image-embedding markup code in the post text.
Still, I stick to a maximum of 1,500 characters for alt-text to keep Mastodon from truncating it. If you post images into the Fediverse, the main audience for your alt-text is on Mastodon, and most of them don't understand that there's something, anything, out there in the Fediverse that does not work exactly like Mastodon. And 1,500 characters can be tight already.
But if I have to stay within Misskey's limits, I can hardly post images anymore. At least not with appropriate descriptions and explanations.
Since late 2024, I have been working on-and-off on a series of fairly simple avatar portraits or rather their image descriptions. The idea is for the long description to consist of a preamble that starts with a general summary, followed by explanations, then followed by visual descriptions of what all images in the post have in common. Next come the individual descriptions of each image. Each post shall have three or four images with three or four portraits each, all in the same pose, all with only minor differences in outfits, all with a neutral, bright white background.
In addition, of course, each image shall have an alt-text, and none of the alt-texts shall depend on each other.
Now, the problem is that I have to describe three or four individual portraits in each alt-text. I'm actually struggling to squeeze such a description plus the note that announces the long description into 1,500 characters, especially if I want to fulfill Veronica Lewis a.k.a. Veronica With Four Eyes' requirements for outfit descriptions to a tee in the alt-text as well (https://veroniiiica.com/how-to-write-alt-text-for-casual-outfits/, https://veroniiiica.com/writing-image-descriptions-for-red-carpet-outfits/; see also https://veroniiiica.com/how-to-write-alt-text-image-descriptions-visually-impaired/ and https://veroniiiica.com/how-to-create-visual-descriptions/).
But in 512 characters so that even Misskey users won't get a severely truncated version? This is absolutely impossible. Even if I limit the long description announcement to some 100 characters, even if I didn't walk people through how to get to the long description, I'd have fewer than 140 characters on average to describe each individual outfit.
The long description won't fare any better. Currently, the preamble starts with some 14,000 characters of explanations, most of which are necessary to understand the visual descriptions. But when Misskey goes and truncates the post at the 8,000-something mark, Misskey users won't even get to any visual description because all visual descriptions would be chopped off.
What makes matters worse is that the preamble grows the longer, the easier to understand I make it and the less I leave people with unexplained technical or jargon terms which you shouldn't use in image descriptions at all anyway. So the next time I go through it and rewrite it to make it easier to understand, I'll also make it even longer than it already is.
But what if I simply cut all the explanations? For one, I'd leave people to their own devices to understand extremely obscure niche content. They won't. My explanations aren't 14,000 characters long because I've artificially inflated them, but because there is so much to know before you understand the post and the images and the descriptions.
Besides, the visual descriptions alone won't fit into 8,192 characters either. What I currently have is over 5,000 characters of common visual description for all portraits in all images plus about 2,500 characters of individual visual description for the three portraits in the first image. That's over 7,500 characters altogether already. And I still have to describe nine portraits in another three images. The post will end up with some 15,000 characters of visual descriptions unless they grow longer when I simplify them again.
I guess users of Misskey or any Forkey will still have to put up with truncated alt-texts and truncated long descriptions in the future. But my future image posts will contain a paragraph at the beginning that explains that the post and/or the alt-text may be truncated on Misskey and the Forkeys, and that both are uncut at the source. Still, this means that *key users will have to put up with the extra hassle of opening my original post at a source with a quite cumbersome UI. And I've got my doubts that this UI is really accessible.
Unfortunately, this also means that *key users won't get any hashtags along with these posts. But then again, the handling of Identi.ca-style/Friendica-style hashtags with the number sign outside the link is broken on all *keys and will remain so for the foreseeable future.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Misskey #Forkey #Forkeys #Calckey #Firefish #Sharkey #CherryPick #Iceshrimp #Iceshrimp-JS #AltText #AltTextMeta #CWAltTextMeta #ImageDescription #ImageDescriptions #ImageDescriptionMeta #CWImageDescriptionMeta #CW #CWs #CWMeta #ContentWarning #ContentWarnings #ContentWarningMeta #CharacterLimit #CharacterLimits #CharacterLimitMeta #CWCharacterLimitMeta #A11y #Accessibility -
Now that the beta is out, I can start showing some of the changes I'm making! Let's start with the redesigned posting form, where I finally got to implement a design that I had first drafted back in Firefish (or was it Calckey?). At the top is the current Sharkey posting form, at the bottom the redesigned, more minimalistic Catodon posting form. This will also give you a general idea of my approach to UX design, and the direction of the new platform.
1. The "Post" button (with a larger font, and without the icon) is at the bottom right corner, closer to where your post would usually end.
2. The posting form expands as you write, a feature I ported from Firefish - which makes moving the Post button more useful, since it was in a kinda awkward position when writing longer posts.
3. The "X" closing button is at the top right corner, where most people would expect it to be.
4. Only the most frequently used icons are visible by default, decluttering the posting form for a cleaner look. The lower "..." menu opens on hover, meaning no extra click from desktops and laptops.
5. When you click "Show preview", the bottom row buttons stay between the typing area and the preview, instead of going all the way to the bottom. This makes it easier to access the buttons while having the preview open, and also keeps the "Show preview" button at the same point, so that you can expand/collapse the preview without having the button jump lower, as in Firefish and Sharkey.
#Catodon #Sharkey #Firefish #Misskey -
Yesteday I said #Catodon is returning, and I'd like to say a few more things.
Let me get this out of the way: I am building it with LLMs. To a big extent I don't know what I'm doing, and I am very aware of that. This will be an experiment. If any of this outrages you, please move on, this project is clearly not for you. If you are disrespectful in the comments, you will be blocked. Please don't tell me what I should or shouldn't do with my time. Thank you.
Those who have followed me for a long time, know that I used to be in #Firefish, then its lead dev moved on to different things leaving the project hanging, then we tried to start Catodon with another dev from the core team of Firefish, and I know that created great expectations and excitement to a lot of people (including me), until our lead dev also realized in the process that they couldn't dedicate the time needed for such a project. Then I was involved in Iceshrimp for a while, which was... let's say not a good fit, and since then I have been trying to find a dev who would like to work in a team effort. It has been years now, and I had no luck. But I still loved the first period of Firefish, I'm still interested in fedi, I still have a lot of ideas that I would like to bring to life. I am also still involved in a greek community server, and I want to build something for my friends and comrades there as well.
But I am not a software engineer, and this is not my calling. What I'm drawn to is design and UX. So I had more or less given up on the idea of Catodon, until I recently started experimenting with LLMs. Mind you, this whole AI craze left me cold until now - I had no use for it, so I stayed away. But for coding, in my case, it turns out to be an invaluable tool.
Would I have preferred to do this with an actual human instead? A thousand times yes. However, I know I really, really tried.
I also know it's bad for the environment. Planes are too, but we use them when needed. And anyway, I am not rich, I will be more or less as screwed as anyone by the ongoing destruction of the planet by the bourgeoisie. So I refuse to be victim blamed. The sad truth is that it's not an individual issue, it's a collective issue. No matter what they have told you, you will not stop the climate crisis if you stop using LLMs, airplanes, plastic straws or electricity altogether.
1/2 -
-
Dear friends and followers,
as you may have noticed, i am testing several fediverse services right now. I have working instances on #GoToSocial, #Sharkey, #Mastodon (Glitch Edition) and this one here on #Friendica.
Friendica has many small issues with ActivityPub compatibility, that are still there after the last update and are nagging on me during daily use. No previews, posts from Mastodon not showing up in the timeline or other similar nuisances. Yes, it has the best connectivity to other internet services to offer - together with #Hubzilla. It can even be used as a RSS reader. I have been running this instance for quite some time and these issues haven't got any better. I think it's time for a change.
GoToSocial is still in beta and has a lot of features missing. Figure. Too early to use it for an instance.
Sharkey - formerly known as #Firefish - is a fork of #Misskey with a great modern UI and visuals. And a lot more features to offer than Mastodon.
Last but not least there is Mastodon. Clean and simple UI, decent features and widely known.
The only thing i am sure about is, that i will close this instance in the near future. I have to choose between Sharkey and Mastodon, i guess.
This is the way. Stay tuned.
-
@crossgolf_rebel - kostenlose Kwalitätsposts @「 Jürgen 」:fedi_mastodon: So ist das. Es zeigt aber auch sehr deutlich den Unterschied zwischen dem Fediverse in der westlichen Welt und dem Fediverse in Ostasien.
So, wie bei uns im Westen das Fediverse im wesentlichen Mastodon ist, ist in Ostasien das Fediverse im wesentlichen *key. Die kennen auch Mastodon, aber das spielt da nur eine untergeordnete Rolle. Etwas, was dem Platzhirsch Misskey das Wasser nicht reichen kann, hat da einfach keine Chance.
In Ostasien gibt's im wesentlichen zwei Gründe für Forkeys. Zum einen ist Misskey eigentlich verbuggt bis zum Gehtnichtmehr. Die Bugs sind bekannt. Die Bugs sind in Issues auf GitHub dokumentiert. Aber es passiert einfach nix. Man könnte Pull Requests einreichen, mit denen ein Bug sofort aus der Welt geschafft werden könnte. Die werden aber einfach nicht gemerget.
Was machst du also? Du machst aus deinem Entwicklungsfork, mit dem du deinen Patch gebaut hast, ein eigenes Projekt mit eigenem Namen und haust das als direkte Konkurrenz zu Misskey raus. Also als Soft-Fork, wo du ab und an mal Commits von Misskey rüberholst und bei dir einpflegst. Oder wenn du an Misskeys Weiterentwicklung eh nicht glaubst, gleich als Hard-Fork, wo du letztlich die ganze Weiterentwicklung selbst machst.
Zum anderen gibt's immer wieder Ideen, wie die Usability von *key verbessert oder in andere Richtungen getrieben werden könnte. Das kann man natürlich nicht unbedingt mit Misskey selbst machen. Also macht man dafür eben einen Fork.
Die Featuritis westlicher Art in japanischen und südkoreanischen Forkeys kam doch eigentlich erst richtig auf, als man in Ostasien bemerkte, daß zum einen Misskey im Westen populärer wurde (immer mehr englische Notizen auf Misskey-Instanzen, immer mehr englische Issues auf GitHub, wo früher mal alle japanisch waren, etc.) und zum anderen Misskey im Westen geforkt wurde (ein Blick in die Liste der Forks des Misskey-Repository genügt).
Im Westen sind die Gründe für Forkeys etwas anders gelagert. Erstens wollten vermutlich besonders die ganz frühen westlichen Forkeys die Ästhetik verändern. Ich meine, vor ein paar Jahren hatte Misskey noch diese typische knallbunte Ästhetik von Shibuya und Akihabara und Manga und japanischen Verkaufsautomaten. Die Amis und Europäer wollten eher ein sachlicheres Aussehen haben, das Maid-Café in eine Studentenkneipe umgestalten, ungewohnte Melonenbrause durch gewohnte Cola ersetzen.
Zweitens, wo man schon mal dabei war: Features, Features, Features. Man war beeindruckt davon, was Misskey konnte, was das eigentlich als Standard und Goldstandard geltende Mastodon nicht konnte. Aber da ging noch was, da war noch Luft nach oben. Und weil verschiedene Entwickler verschiedene Vorstellungen hatten, was jetzt ein Forkey an Features haben soll, standen wohl einige Zeit vor allem FoundKey und Calckey in Konkurrenz zueinander.
Zu den Sachen, auf die sie sich einigen konnten, war, daß ein hartgecodetes Zeichenlimit von 3000 genauso Käse ist wie ein hartgecodetes Zeichenlimit von 500 auf Mastodon. Deswegen hat doch so ziemlich jeder Mastodon-Fork, der was auf sich hält, ein konfigurierbares Zeichenlimit. Und jeder Forkey, der was auf sich hält, auch.
Drittens: Bugfixes. Allerdings nicht nur von Misskey-Bugs, die von den Forkeys geerbt wurden, sondern ebenso von Bugs, die mit der Featuritis Einzug gehalten haben. Deswegen war Sharkey ("Hauptsache, erstmal Features") vs. Iceshrimp ("Hauptsache, erstmal Stabilität") das neue FoundKey vs. Calckey.
Viertens, das habe ich noch gar nicht erwähnt: ein nicht cishet-normatives Fediverse. Sogar eine Nische im Fediverse ganz ausdrücklich für Transpersonen, deren serverseitiger Unterbau selbst von Transpersonen entwickelt und gepflegt wird. Warum? Weil der Admin von misskey.io, der größten Misskey-Instanz überhaupt, durch das Shadowbanning entsprechender Begriffe mal eine gewisse Homophobie, Transphobie und generelle Queerphobie impliziert hat. Wohlgemerkt, der Admin von misskey.io, nicht irgendeiner der Entwickler von Misskey. Aber damit stand Misskey als Ganzes und wohl auch die ganze japanisch-südkoreanische Forkey-Szene doof da.
Hajkey hatte ich ja schon erwähnt. Von einer Transfrau entwickelter Forkey für eine von einer Transfrau gegründete Instanz. Noch offensichtlicher geht's fast schon gar nicht mehr: Hajkey war inspiriert von und benannt nach dem IKEA Blåhaj, dem plüschigen Transgender-Wappentier. Und auch Sharkey wurde von trans Instanzadmins angeschoben, um eine Pro-2SLGBTQQIA+-Alternative zu Misskey mit besonderem Fokus auf Transpersonen zu haben, die Misskey selbst in den Schatten stellt. Ich meine, warum ist das Maskottchen von Sharkey ein Anime-Mädchen in einem blauen Haianzug?
Sharkeys Ziel dürfte auch gewesen sein, einen Fediverse-Alleskönner zu bauen. Egal, was man im Fediverse machen will, egal, was man für Features braucht, sie sollten auf jeden Fall auch erhältlich sein von trans Entwicklern und nicht nur von Cishet-Männern. Wohl auch deshalb wurde Sharkey aufgebläht zu einem Featuremonster, das im Rahmen der Möglichkeiten von *key Friendica und sogar Hubzilla Konkurrenz zu machen versucht. Transpersonen sollten anstelle dieser beiden Anwendungen, die praktisch komplett von Cishet-Männern entwickelt und gepflegt werden, mit möglichst wenig Einschränkungen auch Sharkey nutzen können.
Das Problem im Westen ist nur, Entwickler zu finden und zu halten. Wie gesagt, in Fernost dominiert *key alles. Hier im Westen ist *key eine Nische. Hier ist alles Nische, was nicht Mastodon ist. Ein erheblicher Teil der Fediverse-Nutzer kennt nur Mastodon, glaubt gar, das Fediverse sei nur Mastodon. Ein paar mehr glauben, das Fediverse sei nicht viel mehr als Mastodon, PeerTube und Pixelfed. Geschätzt mindestens die Hälfte aller Fediverse-Nutzer glaubt, Mastodon sei die einzige auf Microblogging ausgelegte Anwendung im Fediverse.
Dazu kommt die Konkurrenz. Neben Mastodon gibt's ja nicht nur *key. Auch Pleroma und Akkoma wollen ein Stück vom Kuchen abhaben, und die dürften mindestens so bekannt sein wie *key. Daneben gibt's noch sehr viele weitere Projekte in sehr vielen weiteren Größenordnungen von snac2 über GoToSocial bis Mitra, die alle dasselbe wollen wie Mastodon und die *keys.
Entsprechend verteilen sich dann auch die fähigen Entwickler. Die meisten forken entweder Mastodon, um daraus etwas zu bauen mit Features, die "das Fediverse" dringend haben müßte, die aber schon Misskey längst hat. Nur haben sie von Misskey nie gehört und auch nicht von Pleroma oder Friendica oder sonstwas. Oder sie fangen ihre eigene Microblogging-Anwendung an mit denselben Beweggründen und demselben Basiswissen bzw. Mangel daran. Ich schätze, von denen wissen auch einige bis heute nicht, daß es Misskey und Pleroma gibt. Oder sie bauen irgendwas ganz anderes direkt gegen Mastodon.
Unter denen, die Misskey kennen, gibt's nicht viele fähige Entwickler. Das sieht man ja auch an den Smartphone-Apps: Reine Mastodon-Apps kommen gefühlt im Monatstakt. Aber es hat eine Ewigkeit gedauert, bis es auch nur eine einzige App gab, die direkt auf Misskey und die Forkeys ausgelegt war, geschweige denn stabil und nicht nur auf Japanisch und vielleicht noch Hangul verfügbar. Das heißt auch: Die paar wenigen fähigen Entwickler, die Misskey kennen, sind entweder schon irgendwo eingebunden oder gebrannte Kinder (oder Ostasiaten, die kein Englisch können, was die Kommunikation ziemlich erschweren würde).
Wer also Mitstreiter fürs eigene Projekt sucht, vor allem so vertrauenswürdige, daß die dann auch committen dürfen, wird keine finden. Gleichzeitig ist es aber absoluter Wahnsinn, einen Soft-Fork von Misskey alleine ohne jegliche Hilfe zu pflegen und weiterzuentwickeln, insbesondere, wenn der an Fahrt aufnimmt und von mehr und mehr Leuten genutzt wird. Genau daran ist Firefish letzten Endes eingegangen.
Im Grunde braucht es heutzutage gar nicht mehr diesen Wust an Forkeys, jedenfalls nicht im Westen. Das heißt, im Grunde könnte CherryPick rein technisch die meisten Anforderungen erschlagen, und noch dazu soll es bombenstabil sein. Nur hat man dann etwas, das so aussieht, wie Matcha oder Melonenbrause schmeckt, und wo die meisten Commits, die nicht von Misskey kommen, auf Japanisch oder Hangul beschrieben sind.
#Long #LongPost #CWLong #CWLongPost #LangerPost #CWLangerPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Misskey #Forkey #Forkeys #Calckey #Firefish #Iceshrimp #Sharkey #CherryPick #FoundKey #Hajkey -
@crossgolf_rebel - kostenlose Kwalitätsposts @「 Jürgen 」:fedi_mastodon: So ist das. Es zeigt aber auch sehr deutlich den Unterschied zwischen dem Fediverse in der westlichen Welt und dem Fediverse in Ostasien.
So, wie bei uns im Westen das Fediverse im wesentlichen Mastodon ist, ist in Ostasien das Fediverse im wesentlichen *key. Die kennen auch Mastodon, aber das spielt da nur eine untergeordnete Rolle. Etwas, was dem Platzhirsch Misskey das Wasser nicht reichen kann, hat da einfach keine Chance.
In Ostasien gibt's im wesentlichen zwei Gründe für Forkeys. Zum einen ist Misskey eigentlich verbuggt bis zum Gehtnichtmehr. Die Bugs sind bekannt. Die Bugs sind in Issues auf GitHub dokumentiert. Aber es passiert einfach nix. Man könnte Pull Requests einreichen, mit denen ein Bug sofort aus der Welt geschafft werden könnte. Die werden aber einfach nicht gemerget.
Was machst du also? Du machst aus deinem Entwicklungsfork, mit dem du deinen Patch gebaut hast, ein eigenes Projekt mit eigenem Namen und haust das als direkte Konkurrenz zu Misskey raus. Also als Soft-Fork, wo du ab und an mal Commits von Misskey rüberholst und bei dir einpflegst. Oder wenn du an Misskeys Weiterentwicklung eh nicht glaubst, gleich als Hard-Fork, wo du letztlich die ganze Weiterentwicklung selbst machst.
Zum anderen gibt's immer wieder Ideen, wie die Usability von *key verbessert oder in andere Richtungen getrieben werden könnte. Das kann man natürlich nicht unbedingt mit Misskey selbst machen. Also macht man dafür eben einen Fork.
Die Featuritis westlicher Art in japanischen und südkoreanischen Forkeys kam doch eigentlich erst richtig auf, als man in Ostasien bemerkte, daß zum einen Misskey im Westen populärer wurde (immer mehr englische Notizen auf Misskey-Instanzen, immer mehr englische Issues auf GitHub, wo früher mal alle japanisch waren, etc.) und zum anderen Misskey im Westen geforkt wurde (ein Blick in die Liste der Forks des Misskey-Repository genügt).
Im Westen sind die Gründe für Forkeys etwas anders gelagert. Erstens wollten vermutlich besonders die ganz frühen westlichen Forkeys die Ästhetik verändern. Ich meine, vor ein paar Jahren hatte Misskey noch diese typische knallbunte Ästhetik von Shibuya und Akihabara und Manga und japanischen Verkaufsautomaten. Die Amis und Europäer wollten eher ein sachlicheres Aussehen haben, das Maid-Café in eine Studentenkneipe umgestalten, ungewohnte Melonenbrause durch gewohnte Cola ersetzen.
Zweitens, wo man schon mal dabei war: Features, Features, Features. Man war beeindruckt davon, was Misskey konnte, was das eigentlich als Standard und Goldstandard geltende Mastodon nicht konnte. Aber da ging noch was, da war noch Luft nach oben. Und weil verschiedene Entwickler verschiedene Vorstellungen hatten, was jetzt ein Forkey an Features haben soll, standen wohl einige Zeit vor allem FoundKey und Calckey in Konkurrenz zueinander.
Zu den Sachen, auf die sie sich einigen konnten, war, daß ein hartgecodetes Zeichenlimit von 3000 genauso Käse ist wie ein hartgecodetes Zeichenlimit von 500 auf Mastodon. Deswegen hat doch so ziemlich jeder Mastodon-Fork, der was auf sich hält, ein konfigurierbares Zeichenlimit. Und jeder Forkey, der was auf sich hält, auch.
Drittens: Bugfixes. Allerdings nicht nur von Misskey-Bugs, die von den Forkeys geerbt wurden, sondern ebenso von Bugs, die mit der Featuritis Einzug gehalten haben. Deswegen war Sharkey ("Hauptsache, erstmal Features") vs. Iceshrimp ("Hauptsache, erstmal Stabilität") das neue FoundKey vs. Calckey.
Viertens, das habe ich noch gar nicht erwähnt: ein nicht cishet-normatives Fediverse. Sogar eine Nische im Fediverse ganz ausdrücklich für Transpersonen, deren serverseitiger Unterbau selbst von Transpersonen entwickelt und gepflegt wird. Warum? Weil der Admin von misskey.io, der größten Misskey-Instanz überhaupt, durch das Shadowbanning entsprechender Begriffe mal eine gewisse Homophobie, Transphobie und generelle Queerphobie impliziert hat. Wohlgemerkt, der Admin von misskey.io, nicht irgendeiner der Entwickler von Misskey. Aber damit stand Misskey als Ganzes und wohl auch die ganze japanisch-südkoreanische Forkey-Szene doof da.
Hajkey hatte ich ja schon erwähnt. Von einer Transfrau entwickelter Forkey für eine von einer Transfrau gegründete Instanz. Noch offensichtlicher geht's fast schon gar nicht mehr: Hajkey war inspiriert von und benannt nach dem IKEA Blåhaj, dem plüschigen Transgender-Wappentier. Und auch Sharkey wurde von trans Instanzadmins angeschoben, um eine Pro-2SLGBTQQIA+-Alternative zu Misskey mit besonderem Fokus auf Transpersonen zu haben, die Misskey selbst in den Schatten stellt. Ich meine, warum ist das Maskottchen von Sharkey ein Anime-Mädchen in einem blauen Haianzug?
Sharkeys Ziel dürfte auch gewesen sein, einen Fediverse-Alleskönner zu bauen. Egal, was man im Fediverse machen will, egal, was man für Features braucht, sie sollten auf jeden Fall auch erhältlich sein von trans Entwicklern und nicht nur von Cishet-Männern. Wohl auch deshalb wurde Sharkey aufgebläht zu einem Featuremonster, das im Rahmen der Möglichkeiten von *key Friendica und sogar Hubzilla Konkurrenz zu machen versucht. Transpersonen sollten anstelle dieser beiden Anwendungen, die praktisch komplett von Cishet-Männern entwickelt und gepflegt werden, mit möglichst wenig Einschränkungen auch Sharkey nutzen können.
Das Problem im Westen ist nur, Entwickler zu finden und zu halten. Wie gesagt, in Fernost dominiert *key alles. Hier im Westen ist *key eine Nische. Hier ist alles Nische, was nicht Mastodon ist. Ein erheblicher Teil der Fediverse-Nutzer kennt nur Mastodon, glaubt gar, das Fediverse sei nur Mastodon. Ein paar mehr glauben, das Fediverse sei nicht viel mehr als Mastodon, PeerTube und Pixelfed. Geschätzt mindestens die Hälfte aller Fediverse-Nutzer glaubt, Mastodon sei die einzige auf Microblogging ausgelegte Anwendung im Fediverse.
Dazu kommt die Konkurrenz. Neben Mastodon gibt's ja nicht nur *key. Auch Pleroma und Akkoma wollen ein Stück vom Kuchen abhaben, und die dürften mindestens so bekannt sein wie *key. Daneben gibt's noch sehr viele weitere Projekte in sehr vielen weiteren Größenordnungen von snac2 über GoToSocial bis Mitra, die alle dasselbe wollen wie Mastodon und die *keys.
Entsprechend verteilen sich dann auch die fähigen Entwickler. Die meisten forken entweder Mastodon, um daraus etwas zu bauen mit Features, die "das Fediverse" dringend haben müßte, die aber schon Misskey längst hat. Nur haben sie von Misskey nie gehört und auch nicht von Pleroma oder Friendica oder sonstwas. Oder sie fangen ihre eigene Microblogging-Anwendung an mit denselben Beweggründen und demselben Basiswissen bzw. Mangel daran. Ich schätze, von denen wissen auch einige bis heute nicht, daß es Misskey und Pleroma gibt. Oder sie bauen irgendwas ganz anderes direkt gegen Mastodon.
Unter denen, die Misskey kennen, gibt's nicht viele fähige Entwickler. Das sieht man ja auch an den Smartphone-Apps: Reine Mastodon-Apps kommen gefühlt im Monatstakt. Aber es hat eine Ewigkeit gedauert, bis es auch nur eine einzige App gab, die direkt auf Misskey und die Forkeys ausgelegt war, geschweige denn stabil und nicht nur auf Japanisch und vielleicht noch Hangul verfügbar. Das heißt auch: Die paar wenigen fähigen Entwickler, die Misskey kennen, sind entweder schon irgendwo eingebunden oder gebrannte Kinder (oder Ostasiaten, die kein Englisch können, was die Kommunikation ziemlich erschweren würde).
Wer also Mitstreiter fürs eigene Projekt sucht, vor allem so vertrauenswürdige, daß die dann auch committen dürfen, wird keine finden. Gleichzeitig ist es aber absoluter Wahnsinn, einen Soft-Fork von Misskey alleine ohne jegliche Hilfe zu pflegen und weiterzuentwickeln, insbesondere, wenn der an Fahrt aufnimmt und von mehr und mehr Leuten genutzt wird. Genau daran ist Firefish letzten Endes eingegangen.
Im Grunde braucht es heutzutage gar nicht mehr diesen Wust an Forkeys, jedenfalls nicht im Westen. Das heißt, im Grunde könnte CherryPick rein technisch die meisten Anforderungen erschlagen, und noch dazu soll es bombenstabil sein. Nur hat man dann etwas, das so aussieht, wie Matcha oder Melonenbrause schmeckt, und wo die meisten Commits, die nicht von Misskey kommen, auf Japanisch oder Hangul beschrieben sind.
#Long #LongPost #CWLong #CWLongPost #LangerPost #CWLangerPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Misskey #Forkey #Forkeys #Calckey #Firefish #Iceshrimp #Sharkey #CherryPick #FoundKey #Hajkey -
@crossgolf_rebel - kostenlose Kwalitätsposts @「 Jürgen 」:fedi_mastodon: So ist das. Es zeigt aber auch sehr deutlich den Unterschied zwischen dem Fediverse in der westlichen Welt und dem Fediverse in Ostasien.
So, wie bei uns im Westen das Fediverse im wesentlichen Mastodon ist, ist in Ostasien das Fediverse im wesentlichen *key. Die kennen auch Mastodon, aber das spielt da nur eine untergeordnete Rolle. Etwas, was dem Platzhirsch Misskey das Wasser nicht reichen kann, hat da einfach keine Chance.
In Ostasien gibt's im wesentlichen zwei Gründe für Forkeys. Zum einen ist Misskey eigentlich verbuggt bis zum Gehtnichtmehr. Die Bugs sind bekannt. Die Bugs sind in Issues auf GitHub dokumentiert. Aber es passiert einfach nix. Man könnte Pull Requests einreichen, mit denen ein Bug sofort aus der Welt geschafft werden könnte. Die werden aber einfach nicht gemerget.
Was machst du also? Du machst aus deinem Entwicklungsfork, mit dem du deinen Patch gebaut hast, ein eigenes Projekt mit eigenem Namen und haust das als direkte Konkurrenz zu Misskey raus. Also als Soft-Fork, wo du ab und an mal Commits von Misskey rüberholst und bei dir einpflegst. Oder wenn du an Misskeys Weiterentwicklung eh nicht glaubst, gleich als Hard-Fork, wo du letztlich die ganze Weiterentwicklung selbst machst.
Zum anderen gibt's immer wieder Ideen, wie die Usability von *key verbessert oder in andere Richtungen getrieben werden könnte. Das kann man natürlich nicht unbedingt mit Misskey selbst machen. Also macht man dafür eben einen Fork.
Die Featuritis westlicher Art in japanischen und südkoreanischen Forkeys kam doch eigentlich erst richtig auf, als man in Ostasien bemerkte, daß zum einen Misskey im Westen populärer wurde (immer mehr englische Notizen auf Misskey-Instanzen, immer mehr englische Issues auf GitHub, wo früher mal alle japanisch waren, etc.) und zum anderen Misskey im Westen geforkt wurde (ein Blick in die Liste der Forks des Misskey-Repository genügt).
Im Westen sind die Gründe für Forkeys etwas anders gelagert. Erstens wollten vermutlich besonders die ganz frühen westlichen Forkeys die Ästhetik verändern. Ich meine, vor ein paar Jahren hatte Misskey noch diese typische knallbunte Ästhetik von Shibuya und Akihabara und Manga und japanischen Verkaufsautomaten. Die Amis und Europäer wollten eher ein sachlicheres Aussehen haben, das Maid-Café in eine Studentenkneipe umgestalten, ungewohnte Melonenbrause durch gewohnte Cola ersetzen.
Zweitens, wo man schon mal dabei war: Features, Features, Features. Man war beeindruckt davon, was Misskey konnte, was das eigentlich als Standard und Goldstandard geltende Mastodon nicht konnte. Aber da ging noch was, da war noch Luft nach oben. Und weil verschiedene Entwickler verschiedene Vorstellungen hatten, was jetzt ein Forkey an Features haben soll, standen wohl einige Zeit vor allem FoundKey und Calckey in Konkurrenz zueinander.
Zu den Sachen, auf die sie sich einigen konnten, war, daß ein hartgecodetes Zeichenlimit von 3000 genauso Käse ist wie ein hartgecodetes Zeichenlimit von 500 auf Mastodon. Deswegen hat doch so ziemlich jeder Mastodon-Fork, der was auf sich hält, ein konfigurierbares Zeichenlimit. Und jeder Forkey, der was auf sich hält, auch.
Drittens: Bugfixes. Allerdings nicht nur von Misskey-Bugs, die von den Forkeys geerbt wurden, sondern ebenso von Bugs, die mit der Featuritis Einzug gehalten haben. Deswegen war Sharkey ("Hauptsache, erstmal Features") vs. Iceshrimp ("Hauptsache, erstmal Stabilität") das neue FoundKey vs. Calckey.
Viertens, das habe ich noch gar nicht erwähnt: ein nicht cishet-normatives Fediverse. Sogar eine Nische im Fediverse ganz ausdrücklich für Transpersonen, deren serverseitiger Unterbau selbst von Transpersonen entwickelt und gepflegt wird. Warum? Weil der Admin von misskey.io, der größten Misskey-Instanz überhaupt, durch das Shadowbanning entsprechender Begriffe mal eine gewisse Homophobie, Transphobie und generelle Queerphobie impliziert hat. Wohlgemerkt, der Admin von misskey.io, nicht irgendeiner der Entwickler von Misskey. Aber damit stand Misskey als Ganzes und wohl auch die ganze japanisch-südkoreanische Forkey-Szene doof da.
Hajkey hatte ich ja schon erwähnt. Von einer Transfrau entwickelter Forkey für eine von einer Transfrau gegründete Instanz. Noch offensichtlicher geht's fast schon gar nicht mehr: Hajkey war inspiriert von und benannt nach dem IKEA Blåhaj, dem plüschigen Transgender-Wappentier. Und auch Sharkey wurde von trans Instanzadmins angeschoben, um eine Pro-2SLGBTQQIA+-Alternative zu Misskey mit besonderem Fokus auf Transpersonen zu haben, die Misskey selbst in den Schatten stellt. Ich meine, warum ist das Maskottchen von Sharkey ein Anime-Mädchen in einem blauen Haianzug?
Sharkeys Ziel dürfte auch gewesen sein, einen Fediverse-Alleskönner zu bauen. Egal, was man im Fediverse machen will, egal, was man für Features braucht, sie sollten auf jeden Fall auch erhältlich sein von trans Entwicklern und nicht nur von Cishet-Männern. Wohl auch deshalb wurde Sharkey aufgebläht zu einem Featuremonster, das im Rahmen der Möglichkeiten von *key Friendica und sogar Hubzilla Konkurrenz zu machen versucht. Transpersonen sollten anstelle dieser beiden Anwendungen, die praktisch komplett von Cishet-Männern entwickelt und gepflegt werden, mit möglichst wenig Einschränkungen auch Sharkey nutzen können.
Das Problem im Westen ist nur, Entwickler zu finden und zu halten. Wie gesagt, in Fernost dominiert *key alles. Hier im Westen ist *key eine Nische. Hier ist alles Nische, was nicht Mastodon ist. Ein erheblicher Teil der Fediverse-Nutzer kennt nur Mastodon, glaubt gar, das Fediverse sei nur Mastodon. Ein paar mehr glauben, das Fediverse sei nicht viel mehr als Mastodon, PeerTube und Pixelfed. Geschätzt mindestens die Hälfte aller Fediverse-Nutzer glaubt, Mastodon sei die einzige auf Microblogging ausgelegte Anwendung im Fediverse.
Dazu kommt die Konkurrenz. Neben Mastodon gibt's ja nicht nur *key. Auch Pleroma und Akkoma wollen ein Stück vom Kuchen abhaben, und die dürften mindestens so bekannt sein wie *key. Daneben gibt's noch sehr viele weitere Projekte in sehr vielen weiteren Größenordnungen von snac2 über GoToSocial bis Mitra, die alle dasselbe wollen wie Mastodon und die *keys.
Entsprechend verteilen sich dann auch die fähigen Entwickler. Die meisten forken entweder Mastodon, um daraus etwas zu bauen mit Features, die "das Fediverse" dringend haben müßte, die aber schon Misskey längst hat. Nur haben sie von Misskey nie gehört und auch nicht von Pleroma oder Friendica oder sonstwas. Oder sie fangen ihre eigene Microblogging-Anwendung an mit denselben Beweggründen und demselben Basiswissen bzw. Mangel daran. Ich schätze, von denen wissen auch einige bis heute nicht, daß es Misskey und Pleroma gibt. Oder sie bauen irgendwas ganz anderes direkt gegen Mastodon.
Unter denen, die Misskey kennen, gibt's nicht viele fähige Entwickler. Das sieht man ja auch an den Smartphone-Apps: Reine Mastodon-Apps kommen gefühlt im Monatstakt. Aber es hat eine Ewigkeit gedauert, bis es auch nur eine einzige App gab, die direkt auf Misskey und die Forkeys ausgelegt war, geschweige denn stabil und nicht nur auf Japanisch und vielleicht noch Hangul verfügbar. Das heißt auch: Die paar wenigen fähigen Entwickler, die Misskey kennen, sind entweder schon irgendwo eingebunden oder gebrannte Kinder (oder Ostasiaten, die kein Englisch können, was die Kommunikation ziemlich erschweren würde).
Wer also Mitstreiter fürs eigene Projekt sucht, vor allem so vertrauenswürdige, daß die dann auch committen dürfen, wird keine finden. Gleichzeitig ist es aber absoluter Wahnsinn, einen Soft-Fork von Misskey alleine ohne jegliche Hilfe zu pflegen und weiterzuentwickeln, insbesondere, wenn der an Fahrt aufnimmt und von mehr und mehr Leuten genutzt wird. Genau daran ist Firefish letzten Endes eingegangen.
Im Grunde braucht es heutzutage gar nicht mehr diesen Wust an Forkeys, jedenfalls nicht im Westen. Das heißt, im Grunde könnte CherryPick rein technisch die meisten Anforderungen erschlagen, und noch dazu soll es bombenstabil sein. Nur hat man dann etwas, das so aussieht, wie Matcha oder Melonenbrause schmeckt, und wo die meisten Commits, die nicht von Misskey kommen, auf Japanisch oder Hangul beschrieben sind.
#Long #LongPost #CWLong #CWLongPost #LangerPost #CWLangerPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Misskey #Forkey #Forkeys #Calckey #Firefish #Iceshrimp #Sharkey #CherryPick #FoundKey #Hajkey -
@crossgolf_rebel - kostenlose Kwalitätsposts @「 Jürgen 」:fedi_mastodon: So ist das. Es zeigt aber auch sehr deutlich den Unterschied zwischen dem Fediverse in der westlichen Welt und dem Fediverse in Ostasien.
So, wie bei uns im Westen das Fediverse im wesentlichen Mastodon ist, ist in Ostasien das Fediverse im wesentlichen *key. Die kennen auch Mastodon, aber das spielt da nur eine untergeordnete Rolle. Etwas, was dem Platzhirsch Misskey das Wasser nicht reichen kann, hat da einfach keine Chance.
In Ostasien gibt's im wesentlichen zwei Gründe für Forkeys. Zum einen ist Misskey eigentlich verbuggt bis zum Gehtnichtmehr. Die Bugs sind bekannt. Die Bugs sind in Issues auf GitHub dokumentiert. Aber es passiert einfach nix. Man könnte Pull Requests einreichen, mit denen ein Bug sofort aus der Welt geschafft werden könnte. Die werden aber einfach nicht gemerget.
Was machst du also? Du machst aus deinem Entwicklungsfork, mit dem du deinen Patch gebaut hast, ein eigenes Projekt mit eigenem Namen und haust das als direkte Konkurrenz zu Misskey raus. Also als Soft-Fork, wo du ab und an mal Commits von Misskey rüberholst und bei dir einpflegst. Oder wenn du an Misskeys Weiterentwicklung eh nicht glaubst, gleich als Hard-Fork, wo du letztlich die ganze Weiterentwicklung selbst machst.
Zum anderen gibt's immer wieder Ideen, wie die Usability von *key verbessert oder in andere Richtungen getrieben werden könnte. Das kann man natürlich nicht unbedingt mit Misskey selbst machen. Also macht man dafür eben einen Fork.
Die Featuritis westlicher Art in japanischen und südkoreanischen Forkeys kam doch eigentlich erst richtig auf, als man in Ostasien bemerkte, daß zum einen Misskey im Westen populärer wurde (immer mehr englische Notizen auf Misskey-Instanzen, immer mehr englische Issues auf GitHub, wo früher mal alle japanisch waren, etc.) und zum anderen Misskey im Westen geforkt wurde (ein Blick in die Liste der Forks des Misskey-Repository genügt).
Im Westen sind die Gründe für Forkeys etwas anders gelagert. Erstens wollten vermutlich besonders die ganz frühen westlichen Forkeys die Ästhetik verändern. Ich meine, vor ein paar Jahren hatte Misskey noch diese typische knallbunte Ästhetik von Shibuya und Akihabara und Manga und japanischen Verkaufsautomaten. Die Amis und Europäer wollten eher ein sachlicheres Aussehen haben, das Maid-Café in eine Studentenkneipe umgestalten, ungewohnte Melonenbrause durch gewohnte Cola ersetzen.
Zweitens, wo man schon mal dabei war: Features, Features, Features. Man war beeindruckt davon, was Misskey konnte, was das eigentlich als Standard und Goldstandard geltende Mastodon nicht konnte. Aber da ging noch was, da war noch Luft nach oben. Und weil verschiedene Entwickler verschiedene Vorstellungen hatten, was jetzt ein Forkey an Features haben soll, standen wohl einige Zeit vor allem FoundKey und Calckey in Konkurrenz zueinander.
Zu den Sachen, auf die sie sich einigen konnten, war, daß ein hartgecodetes Zeichenlimit von 3000 genauso Käse ist wie ein hartgecodetes Zeichenlimit von 500 auf Mastodon. Deswegen hat doch so ziemlich jeder Mastodon-Fork, der was auf sich hält, ein konfigurierbares Zeichenlimit. Und jeder Forkey, der was auf sich hält, auch.
Drittens: Bugfixes. Allerdings nicht nur von Misskey-Bugs, die von den Forkeys geerbt wurden, sondern ebenso von Bugs, die mit der Featuritis Einzug gehalten haben. Deswegen war Sharkey ("Hauptsache, erstmal Features") vs. Iceshrimp ("Hauptsache, erstmal Stabilität") das neue FoundKey vs. Calckey.
Viertens, das habe ich noch gar nicht erwähnt: ein nicht cishet-normatives Fediverse. Sogar eine Nische im Fediverse ganz ausdrücklich für Transpersonen, deren serverseitiger Unterbau selbst von Transpersonen entwickelt und gepflegt wird. Warum? Weil der Admin von misskey.io, der größten Misskey-Instanz überhaupt, durch das Shadowbanning entsprechender Begriffe mal eine gewisse Homophobie, Transphobie und generelle Queerphobie impliziert hat. Wohlgemerkt, der Admin von misskey.io, nicht irgendeiner der Entwickler von Misskey. Aber damit stand Misskey als Ganzes und wohl auch die ganze japanisch-südkoreanische Forkey-Szene doof da.
Hajkey hatte ich ja schon erwähnt. Von einer Transfrau entwickelter Forkey für eine von einer Transfrau gegründete Instanz. Noch offensichtlicher geht's fast schon gar nicht mehr: Hajkey war inspiriert von und benannt nach dem IKEA Blåhaj, dem plüschigen Transgender-Wappentier. Und auch Sharkey wurde von trans Instanzadmins angeschoben, um eine Pro-2SLGBTQQIA+-Alternative zu Misskey mit besonderem Fokus auf Transpersonen zu haben, die Misskey selbst in den Schatten stellt. Ich meine, warum ist das Maskottchen von Sharkey ein Anime-Mädchen in einem blauen Haianzug?
Sharkeys Ziel dürfte auch gewesen sein, einen Fediverse-Alleskönner zu bauen. Egal, was man im Fediverse machen will, egal, was man für Features braucht, sie sollten auf jeden Fall auch erhältlich sein von trans Entwicklern und nicht nur von Cishet-Männern. Wohl auch deshalb wurde Sharkey aufgebläht zu einem Featuremonster, das im Rahmen der Möglichkeiten von *key Friendica und sogar Hubzilla Konkurrenz zu machen versucht. Transpersonen sollten anstelle dieser beiden Anwendungen, die praktisch komplett von Cishet-Männern entwickelt und gepflegt werden, mit möglichst wenig Einschränkungen auch Sharkey nutzen können.
Das Problem im Westen ist nur, Entwickler zu finden und zu halten. Wie gesagt, in Fernost dominiert *key alles. Hier im Westen ist *key eine Nische. Hier ist alles Nische, was nicht Mastodon ist. Ein erheblicher Teil der Fediverse-Nutzer kennt nur Mastodon, glaubt gar, das Fediverse sei nur Mastodon. Ein paar mehr glauben, das Fediverse sei nicht viel mehr als Mastodon, PeerTube und Pixelfed. Geschätzt mindestens die Hälfte aller Fediverse-Nutzer glaubt, Mastodon sei die einzige auf Microblogging ausgelegte Anwendung im Fediverse.
Dazu kommt die Konkurrenz. Neben Mastodon gibt's ja nicht nur *key. Auch Pleroma und Akkoma wollen ein Stück vom Kuchen abhaben, und die dürften mindestens so bekannt sein wie *key. Daneben gibt's noch sehr viele weitere Projekte in sehr vielen weiteren Größenordnungen von snac2 über GoToSocial bis Mitra, die alle dasselbe wollen wie Mastodon und die *keys.
Entsprechend verteilen sich dann auch die fähigen Entwickler. Die meisten forken entweder Mastodon, um daraus etwas zu bauen mit Features, die "das Fediverse" dringend haben müßte, die aber schon Misskey längst hat. Nur haben sie von Misskey nie gehört und auch nicht von Pleroma oder Friendica oder sonstwas. Oder sie fangen ihre eigene Microblogging-Anwendung an mit denselben Beweggründen und demselben Basiswissen bzw. Mangel daran. Ich schätze, von denen wissen auch einige bis heute nicht, daß es Misskey und Pleroma gibt. Oder sie bauen irgendwas ganz anderes direkt gegen Mastodon.
Unter denen, die Misskey kennen, gibt's nicht viele fähige Entwickler. Das sieht man ja auch an den Smartphone-Apps: Reine Mastodon-Apps kommen gefühlt im Monatstakt. Aber es hat eine Ewigkeit gedauert, bis es auch nur eine einzige App gab, die direkt auf Misskey und die Forkeys ausgelegt war, geschweige denn stabil und nicht nur auf Japanisch und vielleicht noch Hangul verfügbar. Das heißt auch: Die paar wenigen fähigen Entwickler, die Misskey kennen, sind entweder schon irgendwo eingebunden oder gebrannte Kinder (oder Ostasiaten, die kein Englisch können, was die Kommunikation ziemlich erschweren würde).
Wer also Mitstreiter fürs eigene Projekt sucht, vor allem so vertrauenswürdige, daß die dann auch committen dürfen, wird keine finden. Gleichzeitig ist es aber absoluter Wahnsinn, einen Soft-Fork von Misskey alleine ohne jegliche Hilfe zu pflegen und weiterzuentwickeln, insbesondere, wenn der an Fahrt aufnimmt und von mehr und mehr Leuten genutzt wird. Genau daran ist Firefish letzten Endes eingegangen.
Im Grunde braucht es heutzutage gar nicht mehr diesen Wust an Forkeys, jedenfalls nicht im Westen. Das heißt, im Grunde könnte CherryPick rein technisch die meisten Anforderungen erschlagen, und noch dazu soll es bombenstabil sein. Nur hat man dann etwas, das so aussieht, wie Matcha oder Melonenbrause schmeckt, und wo die meisten Commits, die nicht von Misskey kommen, auf Japanisch oder Hangul beschrieben sind.
#Long #LongPost #CWLong #CWLongPost #LangerPost #CWLangerPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Misskey #Forkey #Forkeys #Calckey #Firefish #Iceshrimp #Sharkey #CherryPick #FoundKey #Hajkey -
@crossgolf_rebel - kostenlose Kwalitätsposts @「 Jürgen 」:fedi_mastodon: So ist das. Es zeigt aber auch sehr deutlich den Unterschied zwischen dem Fediverse in der westlichen Welt und dem Fediverse in Ostasien.
So, wie bei uns im Westen das Fediverse im wesentlichen Mastodon ist, ist in Ostasien das Fediverse im wesentlichen *key. Die kennen auch Mastodon, aber das spielt da nur eine untergeordnete Rolle. Etwas, was dem Platzhirsch Misskey das Wasser nicht reichen kann, hat da einfach keine Chance.
In Ostasien gibt's im wesentlichen zwei Gründe für Forkeys. Zum einen ist Misskey eigentlich verbuggt bis zum Gehtnichtmehr. Die Bugs sind bekannt. Die Bugs sind in Issues auf GitHub dokumentiert. Aber es passiert einfach nix. Man könnte Pull Requests einreichen, mit denen ein Bug sofort aus der Welt geschafft werden könnte. Die werden aber einfach nicht gemerget.
Was machst du also? Du machst aus deinem Entwicklungsfork, mit dem du deinen Patch gebaut hast, ein eigenes Projekt mit eigenem Namen und haust das als direkte Konkurrenz zu Misskey raus. Also als Soft-Fork, wo du ab und an mal Commits von Misskey rüberholst und bei dir einpflegst. Oder wenn du an Misskeys Weiterentwicklung eh nicht glaubst, gleich als Hard-Fork, wo du letztlich die ganze Weiterentwicklung selbst machst.
Zum anderen gibt's immer wieder Ideen, wie die Usability von *key verbessert oder in andere Richtungen getrieben werden könnte. Das kann man natürlich nicht unbedingt mit Misskey selbst machen. Also macht man dafür eben einen Fork.
Die Featuritis westlicher Art in japanischen und südkoreanischen Forkeys kam doch eigentlich erst richtig auf, als man in Ostasien bemerkte, daß zum einen Misskey im Westen populärer wurde (immer mehr englische Notizen auf Misskey-Instanzen, immer mehr englische Issues auf GitHub, wo früher mal alle japanisch waren, etc.) und zum anderen Misskey im Westen geforkt wurde (ein Blick in die Liste der Forks des Misskey-Repository genügt).
Im Westen sind die Gründe für Forkeys etwas anders gelagert. Erstens wollten vermutlich besonders die ganz frühen westlichen Forkeys die Ästhetik verändern. Ich meine, vor ein paar Jahren hatte Misskey noch diese typische knallbunte Ästhetik von Shibuya und Akihabara und Manga und japanischen Verkaufsautomaten. Die Amis und Europäer wollten eher ein sachlicheres Aussehen haben, das Maid-Café in eine Studentenkneipe umgestalten, ungewohnte Melonenbrause durch gewohnte Cola ersetzen.
Zweitens, wo man schon mal dabei war: Features, Features, Features. Man war beeindruckt davon, was Misskey konnte, was das eigentlich als Standard und Goldstandard geltende Mastodon nicht konnte. Aber da ging noch was, da war noch Luft nach oben. Und weil verschiedene Entwickler verschiedene Vorstellungen hatten, was jetzt ein Forkey an Features haben soll, standen wohl einige Zeit vor allem FoundKey und Calckey in Konkurrenz zueinander.
Zu den Sachen, auf die sie sich einigen konnten, war, daß ein hartgecodetes Zeichenlimit von 3000 genauso Käse ist wie ein hartgecodetes Zeichenlimit von 500 auf Mastodon. Deswegen hat doch so ziemlich jeder Mastodon-Fork, der was auf sich hält, ein konfigurierbares Zeichenlimit. Und jeder Forkey, der was auf sich hält, auch.
Drittens: Bugfixes. Allerdings nicht nur von Misskey-Bugs, die von den Forkeys geerbt wurden, sondern ebenso von Bugs, die mit der Featuritis Einzug gehalten haben. Deswegen war Sharkey ("Hauptsache, erstmal Features") vs. Iceshrimp ("Hauptsache, erstmal Stabilität") das neue FoundKey vs. Calckey.
Viertens, das habe ich noch gar nicht erwähnt: ein nicht cishet-normatives Fediverse. Sogar eine Nische im Fediverse ganz ausdrücklich für Transpersonen, deren serverseitiger Unterbau selbst von Transpersonen entwickelt und gepflegt wird. Warum? Weil der Admin von misskey.io, der größten Misskey-Instanz überhaupt, durch das Shadowbanning entsprechender Begriffe mal eine gewisse Homophobie, Transphobie und generelle Queerphobie impliziert hat. Wohlgemerkt, der Admin von misskey.io, nicht irgendeiner der Entwickler von Misskey. Aber damit stand Misskey als Ganzes und wohl auch die ganze japanisch-südkoreanische Forkey-Szene doof da.
Hajkey hatte ich ja schon erwähnt. Von einer Transfrau entwickelter Forkey für eine von einer Transfrau gegründete Instanz. Noch offensichtlicher geht's fast schon gar nicht mehr: Hajkey war inspiriert von und benannt nach dem IKEA Blåhaj, dem plüschigen Transgender-Wappentier. Und auch Sharkey wurde von trans Instanzadmins angeschoben, um eine Pro-2SLGBTQQIA+-Alternative zu Misskey mit besonderem Fokus auf Transpersonen zu haben, die Misskey selbst in den Schatten stellt. Ich meine, warum ist das Maskottchen von Sharkey ein Anime-Mädchen in einem blauen Haianzug?
Sharkeys Ziel dürfte auch gewesen sein, einen Fediverse-Alleskönner zu bauen. Egal, was man im Fediverse machen will, egal, was man für Features braucht, sie sollten auf jeden Fall auch erhältlich sein von trans Entwicklern und nicht nur von Cishet-Männern. Wohl auch deshalb wurde Sharkey aufgebläht zu einem Featuremonster, das im Rahmen der Möglichkeiten von *key Friendica und sogar Hubzilla Konkurrenz zu machen versucht. Transpersonen sollten anstelle dieser beiden Anwendungen, die praktisch komplett von Cishet-Männern entwickelt und gepflegt werden, mit möglichst wenig Einschränkungen auch Sharkey nutzen können.
Das Problem im Westen ist nur, Entwickler zu finden und zu halten. Wie gesagt, in Fernost dominiert *key alles. Hier im Westen ist *key eine Nische. Hier ist alles Nische, was nicht Mastodon ist. Ein erheblicher Teil der Fediverse-Nutzer kennt nur Mastodon, glaubt gar, das Fediverse sei nur Mastodon. Ein paar mehr glauben, das Fediverse sei nicht viel mehr als Mastodon, PeerTube und Pixelfed. Geschätzt mindestens die Hälfte aller Fediverse-Nutzer glaubt, Mastodon sei die einzige auf Microblogging ausgelegte Anwendung im Fediverse.
Dazu kommt die Konkurrenz. Neben Mastodon gibt's ja nicht nur *key. Auch Pleroma und Akkoma wollen ein Stück vom Kuchen abhaben, und die dürften mindestens so bekannt sein wie *key. Daneben gibt's noch sehr viele weitere Projekte in sehr vielen weiteren Größenordnungen von snac2 über GoToSocial bis Mitra, die alle dasselbe wollen wie Mastodon und die *keys.
Entsprechend verteilen sich dann auch die fähigen Entwickler. Die meisten forken entweder Mastodon, um daraus etwas zu bauen mit Features, die "das Fediverse" dringend haben müßte, die aber schon Misskey längst hat. Nur haben sie von Misskey nie gehört und auch nicht von Pleroma oder Friendica oder sonstwas. Oder sie fangen ihre eigene Microblogging-Anwendung an mit denselben Beweggründen und demselben Basiswissen bzw. Mangel daran. Ich schätze, von denen wissen auch einige bis heute nicht, daß es Misskey und Pleroma gibt. Oder sie bauen irgendwas ganz anderes direkt gegen Mastodon.
Unter denen, die Misskey kennen, gibt's nicht viele fähige Entwickler. Das sieht man ja auch an den Smartphone-Apps: Reine Mastodon-Apps kommen gefühlt im Monatstakt. Aber es hat eine Ewigkeit gedauert, bis es auch nur eine einzige App gab, die direkt auf Misskey und die Forkeys ausgelegt war, geschweige denn stabil und nicht nur auf Japanisch und vielleicht noch Hangul verfügbar. Das heißt auch: Die paar wenigen fähigen Entwickler, die Misskey kennen, sind entweder schon irgendwo eingebunden oder gebrannte Kinder (oder Ostasiaten, die kein Englisch können, was die Kommunikation ziemlich erschweren würde).
Wer also Mitstreiter fürs eigene Projekt sucht, vor allem so vertrauenswürdige, daß die dann auch committen dürfen, wird keine finden. Gleichzeitig ist es aber absoluter Wahnsinn, einen Soft-Fork von Misskey alleine ohne jegliche Hilfe zu pflegen und weiterzuentwickeln, insbesondere, wenn der an Fahrt aufnimmt und von mehr und mehr Leuten genutzt wird. Genau daran ist Firefish letzten Endes eingegangen.
Im Grunde braucht es heutzutage gar nicht mehr diesen Wust an Forkeys, jedenfalls nicht im Westen. Das heißt, im Grunde könnte CherryPick rein technisch die meisten Anforderungen erschlagen, und noch dazu soll es bombenstabil sein. Nur hat man dann etwas, das so aussieht, wie Matcha oder Melonenbrause schmeckt, und wo die meisten Commits, die nicht von Misskey kommen, auf Japanisch oder Hangul beschrieben sind.
#Long #LongPost #CWLong #CWLongPost #LangerPost #CWLangerPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Misskey #Forkey #Forkeys #Calckey #Firefish #Iceshrimp #Sharkey #CherryPick #FoundKey #Hajkey -
@「 Jürgen 」:fedi_mastodon: @crossgolf_rebel - kostenlose Kwalitätsposts @Don di Dislessia Soweit ich weiß, war es so (man möge mich wiederum korrigieren; kursiv sind die "Forkeys höheren Grades", die nicht von Misskey geforkt wurden):
- Misskey
Der Ursprung in Japan. - Calckey
Soft-Fork von Misskey mit einigen Extrafeatures.
Entwickler hatte irgendwann keine Zeit/keinen Bock mehr. - Firefish
Fortführung von Calckey unter neuem Management. Wurde aufgrund einer massiven Werbeaktion eines begeisterten Nutzers mit viel Reichweite so populär, daß der Name "Calckey" irgendwann einfach doof war und das ganze Ding eine neue Identität bekam.
Entwickler verschwand irgendwann sang- und klanglos von der Bildfläche. Nach einem halben Jahr stellte sich raus: Entwickler hatte wegen Abschlußarbeit usw. keine Zeit mehr, nicht mal, sich zu verabschieden.
Wurde unter neuer Führung mit neuem Repository und neuer Leuchtturminstanz weitergeführt, aber ohne neue Website. Wurde wieder eingestellt, weil es für eine einzige Entwicklerin viel zuviel war, die ganzen alten Co-Entwickler von Firefish alle zu Iceshrimp gewechselt waren und keine neuen Mitentwickler angeheuert werden konnten. - Iceshrimp
Fork von Firefish von ehemaligen Firefish-Entwicklern. Rebased nach Misskey, weil es auf Firefish nicht weiterging. Erklärtes Ziel war, Stabilität über Calckeys Featuritis zu stellen.
Weil Misskeys Codebase an sich einiges an grundsätzlichen Macken hatte, wurde beschlossen, es ist einfacher, das ganze Zeugs von Grund auf neu zu schreiben, als zu versuchen, das alles auszubügeln. Und bei der Gelegenheit wollte man von JavaScript (TypeScript und Vue.js) weg. Also hat man angefangen, das ganze Ding in C# neu zu schreiben als Iceshrimp.NET. Ziel ist featuremäßige Deckungsgleichheit mit dem bisherigen Iceshrimp und gleichzeitig Anpassung an Mastodon. Iceshrimp.NET ist noch sehr unfertig.
Bei der Gelegenheit wurde das alte Iceshrimp in Iceshrimp-JS umbenannt und in den Wartungsmodus versetzt = gibt keine Weiterentwicklung und keine neuen Features mehr, nur Sicherheitspatches und evtl. Bugfixes. - Catodon
Soft-Fork von Firefish. Ziel war, ein Forkey zu haben, das sich in der Bedienung wie Mastodon anfühlt. Quasi Mastodon-Fassade mit *key-Struktur dahinter. Also ein Forkey für den möglichst leichten Umstieg von Mastodon nach *key.
Wurde, als Firefish endgültig eingestellt wurde und damit die Basis tot war, nach Iceshrimp rebased.
Nachdem Iceshrimp zu Iceshrimp-JS wurde und in den Wartungsmodus ging, hatte Catodon ein Problem: Man kann nicht einfach von etwas, das in TypeScript und Vue.js geschrieben ist, nach etwas rebasen, das in C# geschrieben ist (Iceshrimp.NET). Und zur Weiterentwicklung wäre ein Rebase nötig gewesen, weil man jetzt wieder eine fast tote Basis hatte. Aber nach Misskey wollte man nicht (siehe Hajkey weiter unten), und Sharkey war einerseits zu mächtig und andererseits zu kapriziös.
Inzwischen gehen Catodon die Instanzen ein. Die meisten dürften geschlossen worden sein. - Sharkey
Soft-Fork von Misskey mit dem Ziel, so ziemlich alles, was je für Forkeys an Features entwickelt worden war, in einen einzigen Forkey zu packen und noch mehr obendrauf.
Quasi das Yang zu Iceshrimps Yin. Machte lange den Eindruck, als gingen Features über Zuverlässigkeit. Sharkeys Implementation der Mastodon Client API war schon regelrecht legendär schlecht, und alle hofften auf den Retter, der daherkommt und die Implementation von Grund auf neu schreibt, weil sie als unrettbar im Eimer galt. Inzwischen soll Sharkey seine Zuverlässigkeit im Griff haben, zumindest insofern, wie auch Misskey zuverlässig ist.
Die Entwickler haben eine zweifelhafte Reputation. Unter anderem haben sie Crowdfunding-Gelder für einen Sharkey-Server gesammelt und von dem Geld einen Minecraft-Server aufgezogen, aber keinen Sharkey-Server. Mitunter wird deshalb zum Boykott von Sharkey aufgerufen. - CherryPick
Südkoreanischer Soft-Fork von Misskey. Tatsächlich älter als Sharkey, mindestens von 2021, aber später wurde wohl einiges von Sharkey nach CherryPick portiert. Das Ziel war, einen stabilen und zuverlässigen Forkey zu haben ohne die Macken von Sharkey und sogar ohne die Macken von Misskey, der aber gleichzeitig gut Features hat. Das ist wohl sogar weitestgehend gelungen.
Vom ästhetischen Stil her so ähnlich, wie Misskey früher mal war, also sehr auf den japanischen bzw. südkoreanischen Geschmack ausgelegt: bunt, grell, poppig, genki, kawaii. Alleine das zeigt, daß CherryPick von Misskey geforkt wurde, bevor Misskey gänzlich an den westlichen Geschmack angepaßt wurde.
Unklar, ob es Entwickler hat, die Englisch verstehen bzw. schreiben können; falls nicht, dann als Soft-Fork-Basis ungeeignet. Wäre ohne die Kommunikationsbarriere vermutlich der ultimative *key.
Mein letzter Stand: Bis auf eine Instanz im Großraum Washington, D.C. gibt es CherryPick-Instanzen nur in den Großräumen Tokyo und Seoul. War deshalb lange Zeit im westlichen Fediverse fast unbekannt. - FoundKey
Wohl der erste Forkey, der in PascalCase geschrieben wurde.
Meines Wissens direkter Soft-Fork von Misskey. Wird tatsächlich (oh Wunder) kleckerweise gepflegt, aber nicht für Instanzen mit mehr als 20 Nutzern empfohlen.
Ein paar andere *keys:- Hajkey
Soft-Fork von Calckey, der meines Wissens erst nach Firefish und dann nach Misskey rebased wurde. Wurde exklusiv nur für eine einzige Instanz entwickelt: transfem.social. Inzwischen eingestellt, weil wohl der Aufwand, so einen Wolpertinger nur für eine Instanz zu pflegen (man rebaset nicht mal eben von Firefish nach Misskey), zu groß war. transfem.social wurde entsprechend auf Sharkey umgestellt und ist da jetzt eine der größten Instanzen. - Neko
Soft-Fork von Misskey mit dem Ziel, es tauglich für Docker zu machen. Laut Repository nur für eine einzige Instanz gebaut. Ist nie released worden, was aber Wurscht ist, wenn es eh nur einen Admin als Zielgruppe hatte.git fetchkönnen Releases nämlich piepegal sein. - Meisskey
Japanischer Soft-Fork von Misskey von 2019 (!), der aber lange Zeit der Weiterentwicklung der Basis hinterherhinkte. Wird tatsächlich immer noch weiterentwickelt. - Leisskey
Wiederum japanischer Soft-Fork von Meisskey. Ist seit mindestens 2021 in Entwicklung, seit Februar 2023 aber eine ewige Beta, weil es seit damals keinen Release mehr gegeben hat. Dürfte zu den letzten noch in Entwicklung befindlichen "Forkeys 2. Grades" gehören. - Tanukey
Weiterer japanischer Soft-Fork von Misskey und daher so obskur im Westen, daß man schon die Websuche anstrengen muß, um das Repository zu finden (ist wohl im letzten Oktober von GitHub nach GitLab umgezogen). Noch ein Beispiel für *keys, bei denen selbst das Wissen über ihre Existenz Ostasien kaum je verlassen hat. - Backspacekey
Noch ein ambitionierter, aber eingeschlafener westlicher Misskey-Soft-Fork.
Siehe übrigens auch die Delightful Fediverse Experience: hier und hier.
Verglichen damit ist die Familie von Mistpark bis Forte schon wieder übersichtlich, vor allem, wenn die anderen mehreren Dutzend toten Forkeys mit dazugeholt werden. Immerhin stammt von Mistpark bis Forte über etwa 15 Jahre alles vom selben Schöpfer, der einfach nur sein eigenes Zeug geforkt hat.
#Long #LongPost #CWLong #CWLongPost #LangerPost #CWLangerPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Misskey #Forkey #Forkeys #Calckey #Firefish #Iceshrimp #IceshrimpJS #Iceshrimp.NET #Catodon #Sharkey #CherryPick #FoundKey #Hajkey #Neko #Meisskey #Leisskey #Tanukey #Backspacekey - Misskey
-
@「 Jürgen 」:fedi_mastodon: @crossgolf_rebel - kostenlose Kwalitätsposts @Don di Dislessia Soweit ich weiß, war es so (man möge mich wiederum korrigieren; kursiv sind die "Forkeys höheren Grades", die nicht von Misskey geforkt wurden):
- Misskey
Der Ursprung in Japan. - Calckey
Soft-Fork von Misskey mit einigen Extrafeatures.
Entwickler hatte irgendwann keine Zeit/keinen Bock mehr. - Firefish
Fortführung von Calckey unter neuem Management. Wurde aufgrund einer massiven Werbeaktion eines begeisterten Nutzers mit viel Reichweite so populär, daß der Name "Calckey" irgendwann einfach doof war und das ganze Ding eine neue Identität bekam.
Entwickler verschwand irgendwann sang- und klanglos von der Bildfläche. Nach einem halben Jahr stellte sich raus: Entwickler hatte wegen Abschlußarbeit usw. keine Zeit mehr, nicht mal, sich zu verabschieden.
Wurde unter neuer Führung mit neuem Repository und neuer Leuchtturminstanz weitergeführt, aber ohne neue Website. Wurde wieder eingestellt, weil es für eine einzige Entwicklerin viel zuviel war, die ganzen alten Co-Entwickler von Firefish alle zu Iceshrimp gewechselt waren und keine neuen Mitentwickler angeheuert werden konnten. - Iceshrimp
Fork von Firefish von ehemaligen Firefish-Entwicklern. Rebased nach Misskey, weil es auf Firefish nicht weiterging. Erklärtes Ziel war, Stabilität über Calckeys Featuritis zu stellen.
Weil Misskeys Codebase an sich einiges an grundsätzlichen Macken hatte, wurde beschlossen, es ist einfacher, das ganze Zeugs von Grund auf neu zu schreiben, als zu versuchen, das alles auszubügeln. Und bei der Gelegenheit wollte man von JavaScript (TypeScript und Vue.js) weg. Also hat man angefangen, das ganze Ding in C# neu zu schreiben als Iceshrimp.NET. Ziel ist featuremäßige Deckungsgleichheit mit dem bisherigen Iceshrimp und gleichzeitig Anpassung an Mastodon. Iceshrimp.NET ist noch sehr unfertig.
Bei der Gelegenheit wurde das alte Iceshrimp in Iceshrimp-JS umbenannt und in den Wartungsmodus versetzt = gibt keine Weiterentwicklung und keine neuen Features mehr, nur Sicherheitspatches und evtl. Bugfixes. - Catodon
Soft-Fork von Firefish. Ziel war, ein Forkey zu haben, das sich in der Bedienung wie Mastodon anfühlt. Quasi Mastodon-Fassade mit *key-Struktur dahinter. Also ein Forkey für den möglichst leichten Umstieg von Mastodon nach *key.
Wurde, als Firefish endgültig eingestellt wurde und damit die Basis tot war, nach Iceshrimp rebased.
Nachdem Iceshrimp zu Iceshrimp-JS wurde und in den Wartungsmodus ging, hatte Catodon ein Problem: Man kann nicht einfach von etwas, das in TypeScript und Vue.js geschrieben ist, nach etwas rebasen, das in C# geschrieben ist (Iceshrimp.NET). Und zur Weiterentwicklung wäre ein Rebase nötig gewesen, weil man jetzt wieder eine fast tote Basis hatte. Aber nach Misskey wollte man nicht (siehe Hajkey weiter unten), und Sharkey war einerseits zu mächtig und andererseits zu kapriziös.
Inzwischen gehen Catodon die Instanzen ein. Die meisten dürften geschlossen worden sein. - Sharkey
Soft-Fork von Misskey mit dem Ziel, so ziemlich alles, was je für Forkeys an Features entwickelt worden war, in einen einzigen Forkey zu packen und noch mehr obendrauf.
Quasi das Yang zu Iceshrimps Yin. Machte lange den Eindruck, als gingen Features über Zuverlässigkeit. Sharkeys Implementation der Mastodon Client API war schon regelrecht legendär schlecht, und alle hofften auf den Retter, der daherkommt und die Implementation von Grund auf neu schreibt, weil sie als unrettbar im Eimer galt. Inzwischen soll Sharkey seine Zuverlässigkeit im Griff haben, zumindest insofern, wie auch Misskey zuverlässig ist.
Die Entwickler haben eine zweifelhafte Reputation. Unter anderem haben sie Crowdfunding-Gelder für einen Sharkey-Server gesammelt und von dem Geld einen Minecraft-Server aufgezogen, aber keinen Sharkey-Server. Mitunter wird deshalb zum Boykott von Sharkey aufgerufen. - CherryPick
Südkoreanischer Soft-Fork von Misskey. Tatsächlich älter als Sharkey, mindestens von 2021, aber später wurde wohl einiges von Sharkey nach CherryPick portiert. Das Ziel war, einen stabilen und zuverlässigen Forkey zu haben ohne die Macken von Sharkey und sogar ohne die Macken von Misskey, der aber gleichzeitig gut Features hat. Das ist wohl sogar weitestgehend gelungen.
Vom ästhetischen Stil her so ähnlich, wie Misskey früher mal war, also sehr auf den japanischen bzw. südkoreanischen Geschmack ausgelegt: bunt, grell, poppig, genki, kawaii. Alleine das zeigt, daß CherryPick von Misskey geforkt wurde, bevor Misskey gänzlich an den westlichen Geschmack angepaßt wurde.
Unklar, ob es Entwickler hat, die Englisch verstehen bzw. schreiben können; falls nicht, dann als Soft-Fork-Basis ungeeignet. Wäre ohne die Kommunikationsbarriere vermutlich der ultimative *key.
Mein letzter Stand: Bis auf eine Instanz im Großraum Washington, D.C. gibt es CherryPick-Instanzen nur in den Großräumen Tokyo und Seoul. War deshalb lange Zeit im westlichen Fediverse fast unbekannt. - FoundKey
Wohl der erste Forkey, der in PascalCase geschrieben wurde.
Meines Wissens direkter Soft-Fork von Misskey. Wird tatsächlich (oh Wunder) kleckerweise gepflegt, aber nicht für Instanzen mit mehr als 20 Nutzern empfohlen.
Ein paar andere *keys:- Hajkey
Soft-Fork von Calckey, der meines Wissens erst nach Firefish und dann nach Misskey rebased wurde. Wurde exklusiv nur für eine einzige Instanz entwickelt: transfem.social. Inzwischen eingestellt, weil wohl der Aufwand, so einen Wolpertinger nur für eine Instanz zu pflegen (man rebaset nicht mal eben von Firefish nach Misskey), zu groß war. transfem.social wurde entsprechend auf Sharkey umgestellt und ist da jetzt eine der größten Instanzen. - Neko
Soft-Fork von Misskey mit dem Ziel, es tauglich für Docker zu machen. Laut Repository nur für eine einzige Instanz gebaut. Ist nie released worden, was aber Wurscht ist, wenn es eh nur einen Admin als Zielgruppe hatte.git fetchkönnen Releases nämlich piepegal sein. - Meisskey
Japanischer Soft-Fork von Misskey von 2019 (!), der aber lange Zeit der Weiterentwicklung der Basis hinterherhinkte. Wird tatsächlich immer noch weiterentwickelt. - Leisskey
Wiederum japanischer Soft-Fork von Meisskey. Ist seit mindestens 2021 in Entwicklung, seit Februar 2023 aber eine ewige Beta, weil es seit damals keinen Release mehr gegeben hat. Dürfte zu den letzten noch in Entwicklung befindlichen "Forkeys 2. Grades" gehören. - Tanukey
Weiterer japanischer Soft-Fork von Misskey und daher so obskur im Westen, daß man schon die Websuche anstrengen muß, um das Repository zu finden (ist wohl im letzten Oktober von GitHub nach GitLab umgezogen). Noch ein Beispiel für *keys, bei denen selbst das Wissen über ihre Existenz Ostasien kaum je verlassen hat. - Backspacekey
Noch ein ambitionierter, aber eingeschlafener westlicher Misskey-Soft-Fork.
Siehe übrigens auch die Delightful Fediverse Experience: hier und hier.
Verglichen damit ist die Familie von Mistpark bis Forte schon wieder übersichtlich, vor allem, wenn die anderen mehreren Dutzend toten Forkeys mit dazugeholt werden. Immerhin stammt von Mistpark bis Forte über etwa 15 Jahre alles vom selben Schöpfer, der einfach nur sein eigenes Zeug geforkt hat.
#Long #LongPost #CWLong #CWLongPost #LangerPost #CWLangerPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Misskey #Forkey #Forkeys #Calckey #Firefish #Iceshrimp #IceshrimpJS #Iceshrimp.NET #Catodon #Sharkey #CherryPick #FoundKey #Hajkey #Neko #Meisskey #Leisskey #Tanukey #Backspacekey - Misskey
-
@「 Jürgen 」:fedi_mastodon: @crossgolf_rebel - kostenlose Kwalitätsposts @Don di Dislessia Soweit ich weiß, war es so (man möge mich wiederum korrigieren; kursiv sind die "Forkeys höheren Grades", die nicht von Misskey geforkt wurden):
- Misskey
Der Ursprung in Japan. - Calckey
Soft-Fork von Misskey mit einigen Extrafeatures.
Entwickler hatte irgendwann keine Zeit/keinen Bock mehr. - Firefish
Fortführung von Calckey unter neuem Management. Wurde aufgrund einer massiven Werbeaktion eines begeisterten Nutzers mit viel Reichweite so populär, daß der Name "Calckey" irgendwann einfach doof war und das ganze Ding eine neue Identität bekam.
Entwickler verschwand irgendwann sang- und klanglos von der Bildfläche. Nach einem halben Jahr stellte sich raus: Entwickler hatte wegen Abschlußarbeit usw. keine Zeit mehr, nicht mal, sich zu verabschieden.
Wurde unter neuer Führung mit neuem Repository und neuer Leuchtturminstanz weitergeführt, aber ohne neue Website. Wurde wieder eingestellt, weil es für eine einzige Entwicklerin viel zuviel war, die ganzen alten Co-Entwickler von Firefish alle zu Iceshrimp gewechselt waren und keine neuen Mitentwickler angeheuert werden konnten. - Iceshrimp
Fork von Firefish von ehemaligen Firefish-Entwicklern. Rebased nach Misskey, weil es auf Firefish nicht weiterging. Erklärtes Ziel war, Stabilität über Calckeys Featuritis zu stellen.
Weil Misskeys Codebase an sich einiges an grundsätzlichen Macken hatte, wurde beschlossen, es ist einfacher, das ganze Zeugs von Grund auf neu zu schreiben, als zu versuchen, das alles auszubügeln. Und bei der Gelegenheit wollte man von JavaScript (TypeScript und Vue.js) weg. Also hat man angefangen, das ganze Ding in C# neu zu schreiben als Iceshrimp.NET. Ziel ist featuremäßige Deckungsgleichheit mit dem bisherigen Iceshrimp und gleichzeitig Anpassung an Mastodon. Iceshrimp.NET ist noch sehr unfertig.
Bei der Gelegenheit wurde das alte Iceshrimp in Iceshrimp-JS umbenannt und in den Wartungsmodus versetzt = gibt keine Weiterentwicklung und keine neuen Features mehr, nur Sicherheitspatches und evtl. Bugfixes. - Catodon
Soft-Fork von Firefish. Ziel war, ein Forkey zu haben, das sich in der Bedienung wie Mastodon anfühlt. Quasi Mastodon-Fassade mit *key-Struktur dahinter. Also ein Forkey für den möglichst leichten Umstieg von Mastodon nach *key.
Wurde, als Firefish endgültig eingestellt wurde und damit die Basis tot war, nach Iceshrimp rebased.
Nachdem Iceshrimp zu Iceshrimp-JS wurde und in den Wartungsmodus ging, hatte Catodon ein Problem: Man kann nicht einfach von etwas, das in TypeScript und Vue.js geschrieben ist, nach etwas rebasen, das in C# geschrieben ist (Iceshrimp.NET). Und zur Weiterentwicklung wäre ein Rebase nötig gewesen, weil man jetzt wieder eine fast tote Basis hatte. Aber nach Misskey wollte man nicht (siehe Hajkey weiter unten), und Sharkey war einerseits zu mächtig und andererseits zu kapriziös.
Inzwischen gehen Catodon die Instanzen ein. Die meisten dürften geschlossen worden sein. - Sharkey
Soft-Fork von Misskey mit dem Ziel, so ziemlich alles, was je für Forkeys an Features entwickelt worden war, in einen einzigen Forkey zu packen und noch mehr obendrauf.
Quasi das Yang zu Iceshrimps Yin. Machte lange den Eindruck, als gingen Features über Zuverlässigkeit. Sharkeys Implementation der Mastodon Client API war schon regelrecht legendär schlecht, und alle hofften auf den Retter, der daherkommt und die Implementation von Grund auf neu schreibt, weil sie als unrettbar im Eimer galt. Inzwischen soll Sharkey seine Zuverlässigkeit im Griff haben, zumindest insofern, wie auch Misskey zuverlässig ist.
Die Entwickler haben eine zweifelhafte Reputation. Unter anderem haben sie Crowdfunding-Gelder für einen Sharkey-Server gesammelt und von dem Geld einen Minecraft-Server aufgezogen, aber keinen Sharkey-Server. Mitunter wird deshalb zum Boykott von Sharkey aufgerufen. - CherryPick
Südkoreanischer Soft-Fork von Misskey. Tatsächlich älter als Sharkey, mindestens von 2021, aber später wurde wohl einiges von Sharkey nach CherryPick portiert. Das Ziel war, einen stabilen und zuverlässigen Forkey zu haben ohne die Macken von Sharkey und sogar ohne die Macken von Misskey, der aber gleichzeitig gut Features hat. Das ist wohl sogar weitestgehend gelungen.
Vom ästhetischen Stil her so ähnlich, wie Misskey früher mal war, also sehr auf den japanischen bzw. südkoreanischen Geschmack ausgelegt: bunt, grell, poppig, genki, kawaii. Alleine das zeigt, daß CherryPick von Misskey geforkt wurde, bevor Misskey gänzlich an den westlichen Geschmack angepaßt wurde.
Unklar, ob es Entwickler hat, die Englisch verstehen bzw. schreiben können; falls nicht, dann als Soft-Fork-Basis ungeeignet. Wäre ohne die Kommunikationsbarriere vermutlich der ultimative *key.
Mein letzter Stand: Bis auf eine Instanz im Großraum Washington, D.C. gibt es CherryPick-Instanzen nur in den Großräumen Tokyo und Seoul. War deshalb lange Zeit im westlichen Fediverse fast unbekannt. - FoundKey
Wohl der erste Forkey, der in PascalCase geschrieben wurde.
Meines Wissens direkter Soft-Fork von Misskey. Wird tatsächlich (oh Wunder) kleckerweise gepflegt, aber nicht für Instanzen mit mehr als 20 Nutzern empfohlen.
Ein paar andere *keys:- Hajkey
Soft-Fork von Calckey, der meines Wissens erst nach Firefish und dann nach Misskey rebased wurde. Wurde exklusiv nur für eine einzige Instanz entwickelt: transfem.social. Inzwischen eingestellt, weil wohl der Aufwand, so einen Wolpertinger nur für eine Instanz zu pflegen (man rebaset nicht mal eben von Firefish nach Misskey), zu groß war. transfem.social wurde entsprechend auf Sharkey umgestellt und ist da jetzt eine der größten Instanzen. - Neko
Soft-Fork von Misskey mit dem Ziel, es tauglich für Docker zu machen. Laut Repository nur für eine einzige Instanz gebaut. Ist nie released worden, was aber Wurscht ist, wenn es eh nur einen Admin als Zielgruppe hatte.git fetchkönnen Releases nämlich piepegal sein. - Meisskey
Japanischer Soft-Fork von Misskey von 2019 (!), der aber lange Zeit der Weiterentwicklung der Basis hinterherhinkte. Wird tatsächlich immer noch weiterentwickelt. - Leisskey
Wiederum japanischer Soft-Fork von Meisskey. Ist seit mindestens 2021 in Entwicklung, seit Februar 2023 aber eine ewige Beta, weil es seit damals keinen Release mehr gegeben hat. Dürfte zu den letzten noch in Entwicklung befindlichen "Forkeys 2. Grades" gehören. - Tanukey
Weiterer japanischer Soft-Fork von Misskey und daher so obskur im Westen, daß man schon die Websuche anstrengen muß, um das Repository zu finden (ist wohl im letzten Oktober von GitHub nach GitLab umgezogen). Noch ein Beispiel für *keys, bei denen selbst das Wissen über ihre Existenz Ostasien kaum je verlassen hat. - Backspacekey
Noch ein ambitionierter, aber eingeschlafener westlicher Misskey-Soft-Fork.
Siehe übrigens auch die Delightful Fediverse Experience: hier und hier.
Verglichen damit ist die Familie von Mistpark bis Forte schon wieder übersichtlich, vor allem, wenn die anderen mehreren Dutzend toten Forkeys mit dazugeholt werden. Immerhin stammt von Mistpark bis Forte über etwa 15 Jahre alles vom selben Schöpfer, der einfach nur sein eigenes Zeug geforkt hat.
#Long #LongPost #CWLong #CWLongPost #LangerPost #CWLangerPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Misskey #Forkey #Forkeys #Calckey #Firefish #Iceshrimp #IceshrimpJS #Iceshrimp.NET #Catodon #Sharkey #CherryPick #FoundKey #Hajkey #Neko #Meisskey #Leisskey #Tanukey #Backspacekey - Misskey
-
@「 Jürgen 」:fedi_mastodon: @crossgolf_rebel - kostenlose Kwalitätsposts @Don di Dislessia Soweit ich weiß, war es so (man möge mich wiederum korrigieren; kursiv sind die "Forkeys höheren Grades", die nicht von Misskey geforkt wurden):
- Misskey
Der Ursprung in Japan. - Calckey
Soft-Fork von Misskey mit einigen Extrafeatures.
Entwickler hatte irgendwann keine Zeit/keinen Bock mehr. - Firefish
Fortführung von Calckey unter neuem Management. Wurde aufgrund einer massiven Werbeaktion eines begeisterten Nutzers mit viel Reichweite so populär, daß der Name "Calckey" irgendwann einfach doof war und das ganze Ding eine neue Identität bekam.
Entwickler verschwand irgendwann sang- und klanglos von der Bildfläche. Nach einem halben Jahr stellte sich raus: Entwickler hatte wegen Abschlußarbeit usw. keine Zeit mehr, nicht mal, sich zu verabschieden.
Wurde unter neuer Führung mit neuem Repository und neuer Leuchtturminstanz weitergeführt, aber ohne neue Website. Wurde wieder eingestellt, weil es für eine einzige Entwicklerin viel zuviel war, die ganzen alten Co-Entwickler von Firefish alle zu Iceshrimp gewechselt waren und keine neuen Mitentwickler angeheuert werden konnten. - Iceshrimp
Fork von Firefish von ehemaligen Firefish-Entwicklern. Rebased nach Misskey, weil es auf Firefish nicht weiterging. Erklärtes Ziel war, Stabilität über Calckeys Featuritis zu stellen.
Weil Misskeys Codebase an sich einiges an grundsätzlichen Macken hatte, wurde beschlossen, es ist einfacher, das ganze Zeugs von Grund auf neu zu schreiben, als zu versuchen, das alles auszubügeln. Und bei der Gelegenheit wollte man von JavaScript (TypeScript und Vue.js) weg. Also hat man angefangen, das ganze Ding in C# neu zu schreiben als Iceshrimp.NET. Ziel ist featuremäßige Deckungsgleichheit mit dem bisherigen Iceshrimp und gleichzeitig Anpassung an Mastodon. Iceshrimp.NET ist noch sehr unfertig.
Bei der Gelegenheit wurde das alte Iceshrimp in Iceshrimp-JS umbenannt und in den Wartungsmodus versetzt = gibt keine Weiterentwicklung und keine neuen Features mehr, nur Sicherheitspatches und evtl. Bugfixes. - Catodon
Soft-Fork von Firefish. Ziel war, ein Forkey zu haben, das sich in der Bedienung wie Mastodon anfühlt. Quasi Mastodon-Fassade mit *key-Struktur dahinter. Also ein Forkey für den möglichst leichten Umstieg von Mastodon nach *key.
Wurde, als Firefish endgültig eingestellt wurde und damit die Basis tot war, nach Iceshrimp rebased.
Nachdem Iceshrimp zu Iceshrimp-JS wurde und in den Wartungsmodus ging, hatte Catodon ein Problem: Man kann nicht einfach von etwas, das in TypeScript und Vue.js geschrieben ist, nach etwas rebasen, das in C# geschrieben ist (Iceshrimp.NET). Und zur Weiterentwicklung wäre ein Rebase nötig gewesen, weil man jetzt wieder eine fast tote Basis hatte. Aber nach Misskey wollte man nicht (siehe Hajkey weiter unten), und Sharkey war einerseits zu mächtig und andererseits zu kapriziös.
Inzwischen gehen Catodon die Instanzen ein. Die meisten dürften geschlossen worden sein. - Sharkey
Soft-Fork von Misskey mit dem Ziel, so ziemlich alles, was je für Forkeys an Features entwickelt worden war, in einen einzigen Forkey zu packen und noch mehr obendrauf.
Quasi das Yang zu Iceshrimps Yin. Machte lange den Eindruck, als gingen Features über Zuverlässigkeit. Sharkeys Implementation der Mastodon Client API war schon regelrecht legendär schlecht, und alle hofften auf den Retter, der daherkommt und die Implementation von Grund auf neu schreibt, weil sie als unrettbar im Eimer galt. Inzwischen soll Sharkey seine Zuverlässigkeit im Griff haben, zumindest insofern, wie auch Misskey zuverlässig ist.
Die Entwickler haben eine zweifelhafte Reputation. Unter anderem haben sie Crowdfunding-Gelder für einen Sharkey-Server gesammelt und von dem Geld einen Minecraft-Server aufgezogen, aber keinen Sharkey-Server. Mitunter wird deshalb zum Boykott von Sharkey aufgerufen. - CherryPick
Südkoreanischer Soft-Fork von Misskey. Tatsächlich älter als Sharkey, mindestens von 2021, aber später wurde wohl einiges von Sharkey nach CherryPick portiert. Das Ziel war, einen stabilen und zuverlässigen Forkey zu haben ohne die Macken von Sharkey und sogar ohne die Macken von Misskey, der aber gleichzeitig gut Features hat. Das ist wohl sogar weitestgehend gelungen.
Vom ästhetischen Stil her so ähnlich, wie Misskey früher mal war, also sehr auf den japanischen bzw. südkoreanischen Geschmack ausgelegt: bunt, grell, poppig, genki, kawaii. Alleine das zeigt, daß CherryPick von Misskey geforkt wurde, bevor Misskey gänzlich an den westlichen Geschmack angepaßt wurde.
Unklar, ob es Entwickler hat, die Englisch verstehen bzw. schreiben können; falls nicht, dann als Soft-Fork-Basis ungeeignet. Wäre ohne die Kommunikationsbarriere vermutlich der ultimative *key.
Mein letzter Stand: Bis auf eine Instanz im Großraum Washington, D.C. gibt es CherryPick-Instanzen nur in den Großräumen Tokyo und Seoul. War deshalb lange Zeit im westlichen Fediverse fast unbekannt. - FoundKey
Wohl der erste Forkey, der in PascalCase geschrieben wurde.
Meines Wissens direkter Soft-Fork von Misskey. Wird tatsächlich (oh Wunder) kleckerweise gepflegt, aber nicht für Instanzen mit mehr als 20 Nutzern empfohlen.
Ein paar andere *keys:- Hajkey
Soft-Fork von Calckey, der meines Wissens erst nach Firefish und dann nach Misskey rebased wurde. Wurde exklusiv nur für eine einzige Instanz entwickelt: transfem.social. Inzwischen eingestellt, weil wohl der Aufwand, so einen Wolpertinger nur für eine Instanz zu pflegen (man rebaset nicht mal eben von Firefish nach Misskey), zu groß war. transfem.social wurde entsprechend auf Sharkey umgestellt und ist da jetzt eine der größten Instanzen. - Neko
Soft-Fork von Misskey mit dem Ziel, es tauglich für Docker zu machen. Laut Repository nur für eine einzige Instanz gebaut. Ist nie released worden, was aber Wurscht ist, wenn es eh nur einen Admin als Zielgruppe hatte.git fetchkönnen Releases nämlich piepegal sein. - Meisskey
Japanischer Soft-Fork von Misskey von 2019 (!), der aber lange Zeit der Weiterentwicklung der Basis hinterherhinkte. Wird tatsächlich immer noch weiterentwickelt. - Leisskey
Wiederum japanischer Soft-Fork von Meisskey. Ist seit mindestens 2021 in Entwicklung, seit Februar 2023 aber eine ewige Beta, weil es seit damals keinen Release mehr gegeben hat. Dürfte zu den letzten noch in Entwicklung befindlichen "Forkeys 2. Grades" gehören. - Tanukey
Weiterer japanischer Soft-Fork von Misskey und daher so obskur im Westen, daß man schon die Websuche anstrengen muß, um das Repository zu finden (ist wohl im letzten Oktober von GitHub nach GitLab umgezogen). Noch ein Beispiel für *keys, bei denen selbst das Wissen über ihre Existenz Ostasien kaum je verlassen hat. - Backspacekey
Noch ein ambitionierter, aber eingeschlafener westlicher Misskey-Soft-Fork.
Siehe übrigens auch die Delightful Fediverse Experience: hier und hier.
Verglichen damit ist die Familie von Mistpark bis Forte schon wieder übersichtlich, vor allem, wenn die anderen mehreren Dutzend toten Forkeys mit dazugeholt werden. Immerhin stammt von Mistpark bis Forte über etwa 15 Jahre alles vom selben Schöpfer, der einfach nur sein eigenes Zeug geforkt hat.
#Long #LongPost #CWLong #CWLongPost #LangerPost #CWLangerPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Misskey #Forkey #Forkeys #Calckey #Firefish #Iceshrimp #IceshrimpJS #Iceshrimp.NET #Catodon #Sharkey #CherryPick #FoundKey #Hajkey #Neko #Meisskey #Leisskey #Tanukey #Backspacekey - Misskey
-
@「 Jürgen 」:fedi_mastodon: @crossgolf_rebel - kostenlose Kwalitätsposts @Don di Dislessia Soweit ich weiß, war es so (man möge mich wiederum korrigieren; kursiv sind die "Forkeys höheren Grades", die nicht von Misskey geforkt wurden):
- Misskey
Der Ursprung in Japan. - Calckey
Soft-Fork von Misskey mit einigen Extrafeatures.
Entwickler hatte irgendwann keine Zeit/keinen Bock mehr. - Firefish
Fortführung von Calckey unter neuem Management. Wurde aufgrund einer massiven Werbeaktion eines begeisterten Nutzers mit viel Reichweite so populär, daß der Name "Calckey" irgendwann einfach doof war und das ganze Ding eine neue Identität bekam.
Entwickler verschwand irgendwann sang- und klanglos von der Bildfläche. Nach einem halben Jahr stellte sich raus: Entwickler hatte wegen Abschlußarbeit usw. keine Zeit mehr, nicht mal, sich zu verabschieden.
Wurde unter neuer Führung mit neuem Repository und neuer Leuchtturminstanz weitergeführt, aber ohne neue Website. Wurde wieder eingestellt, weil es für eine einzige Entwicklerin viel zuviel war, die ganzen alten Co-Entwickler von Firefish alle zu Iceshrimp gewechselt waren und keine neuen Mitentwickler angeheuert werden konnten. - Iceshrimp
Fork von Firefish von ehemaligen Firefish-Entwicklern. Rebased nach Misskey, weil es auf Firefish nicht weiterging. Erklärtes Ziel war, Stabilität über Calckeys Featuritis zu stellen.
Weil Misskeys Codebase an sich einiges an grundsätzlichen Macken hatte, wurde beschlossen, es ist einfacher, das ganze Zeugs von Grund auf neu zu schreiben, als zu versuchen, das alles auszubügeln. Und bei der Gelegenheit wollte man von JavaScript (TypeScript und Vue.js) weg. Also hat man angefangen, das ganze Ding in C# neu zu schreiben als Iceshrimp.NET. Ziel ist featuremäßige Deckungsgleichheit mit dem bisherigen Iceshrimp und gleichzeitig Anpassung an Mastodon. Iceshrimp.NET ist noch sehr unfertig.
Bei der Gelegenheit wurde das alte Iceshrimp in Iceshrimp-JS umbenannt und in den Wartungsmodus versetzt = gibt keine Weiterentwicklung und keine neuen Features mehr, nur Sicherheitspatches und evtl. Bugfixes. - Catodon
Soft-Fork von Firefish. Ziel war, ein Forkey zu haben, das sich in der Bedienung wie Mastodon anfühlt. Quasi Mastodon-Fassade mit *key-Struktur dahinter. Also ein Forkey für den möglichst leichten Umstieg von Mastodon nach *key.
Wurde, als Firefish endgültig eingestellt wurde und damit die Basis tot war, nach Iceshrimp rebased.
Nachdem Iceshrimp zu Iceshrimp-JS wurde und in den Wartungsmodus ging, hatte Catodon ein Problem: Man kann nicht einfach von etwas, das in TypeScript und Vue.js geschrieben ist, nach etwas rebasen, das in C# geschrieben ist (Iceshrimp.NET). Und zur Weiterentwicklung wäre ein Rebase nötig gewesen, weil man jetzt wieder eine fast tote Basis hatte. Aber nach Misskey wollte man nicht (siehe Hajkey weiter unten), und Sharkey war einerseits zu mächtig und andererseits zu kapriziös.
Inzwischen gehen Catodon die Instanzen ein. Die meisten dürften geschlossen worden sein. - Sharkey
Soft-Fork von Misskey mit dem Ziel, so ziemlich alles, was je für Forkeys an Features entwickelt worden war, in einen einzigen Forkey zu packen und noch mehr obendrauf.
Quasi das Yang zu Iceshrimps Yin. Machte lange den Eindruck, als gingen Features über Zuverlässigkeit. Sharkeys Implementation der Mastodon Client API war schon regelrecht legendär schlecht, und alle hofften auf den Retter, der daherkommt und die Implementation von Grund auf neu schreibt, weil sie als unrettbar im Eimer galt. Inzwischen soll Sharkey seine Zuverlässigkeit im Griff haben, zumindest insofern, wie auch Misskey zuverlässig ist.
Die Entwickler haben eine zweifelhafte Reputation. Unter anderem haben sie Crowdfunding-Gelder für einen Sharkey-Server gesammelt und von dem Geld einen Minecraft-Server aufgezogen, aber keinen Sharkey-Server. Mitunter wird deshalb zum Boykott von Sharkey aufgerufen. - CherryPick
Südkoreanischer Soft-Fork von Misskey. Tatsächlich älter als Sharkey, mindestens von 2021, aber später wurde wohl einiges von Sharkey nach CherryPick portiert. Das Ziel war, einen stabilen und zuverlässigen Forkey zu haben ohne die Macken von Sharkey und sogar ohne die Macken von Misskey, der aber gleichzeitig gut Features hat. Das ist wohl sogar weitestgehend gelungen.
Vom ästhetischen Stil her so ähnlich, wie Misskey früher mal war, also sehr auf den japanischen bzw. südkoreanischen Geschmack ausgelegt: bunt, grell, poppig, genki, kawaii. Alleine das zeigt, daß CherryPick von Misskey geforkt wurde, bevor Misskey gänzlich an den westlichen Geschmack angepaßt wurde.
Unklar, ob es Entwickler hat, die Englisch verstehen bzw. schreiben können; falls nicht, dann als Soft-Fork-Basis ungeeignet. Wäre ohne die Kommunikationsbarriere vermutlich der ultimative *key.
Mein letzter Stand: Bis auf eine Instanz im Großraum Washington, D.C. gibt es CherryPick-Instanzen nur in den Großräumen Tokyo und Seoul. War deshalb lange Zeit im westlichen Fediverse fast unbekannt. - FoundKey
Wohl der erste Forkey, der in PascalCase geschrieben wurde.
Meines Wissens direkter Soft-Fork von Misskey. Wird tatsächlich (oh Wunder) kleckerweise gepflegt, aber nicht für Instanzen mit mehr als 20 Nutzern empfohlen.
Ein paar andere *keys:- Hajkey
Soft-Fork von Calckey, der meines Wissens erst nach Firefish und dann nach Misskey rebased wurde. Wurde exklusiv nur für eine einzige Instanz entwickelt: transfem.social. Inzwischen eingestellt, weil wohl der Aufwand, so einen Wolpertinger nur für eine Instanz zu pflegen (man rebaset nicht mal eben von Firefish nach Misskey), zu groß war. transfem.social wurde entsprechend auf Sharkey umgestellt und ist da jetzt eine der größten Instanzen. - Neko
Soft-Fork von Misskey mit dem Ziel, es tauglich für Docker zu machen. Laut Repository nur für eine einzige Instanz gebaut. Ist nie released worden, was aber Wurscht ist, wenn es eh nur einen Admin als Zielgruppe hatte.git fetchkönnen Releases nämlich piepegal sein. - Meisskey
Japanischer Soft-Fork von Misskey von 2019 (!), der aber lange Zeit der Weiterentwicklung der Basis hinterherhinkte. Wird tatsächlich immer noch weiterentwickelt. - Leisskey
Wiederum japanischer Soft-Fork von Meisskey. Ist seit mindestens 2021 in Entwicklung, seit Februar 2023 aber eine ewige Beta, weil es seit damals keinen Release mehr gegeben hat. Dürfte zu den letzten noch in Entwicklung befindlichen "Forkeys 2. Grades" gehören. - Tanukey
Weiterer japanischer Soft-Fork von Misskey und daher so obskur im Westen, daß man schon die Websuche anstrengen muß, um das Repository zu finden (ist wohl im letzten Oktober von GitHub nach GitLab umgezogen). Noch ein Beispiel für *keys, bei denen selbst das Wissen über ihre Existenz Ostasien kaum je verlassen hat. - Backspacekey
Noch ein ambitionierter, aber eingeschlafener westlicher Misskey-Soft-Fork.
Siehe übrigens auch die Delightful Fediverse Experience: hier und hier.
Verglichen damit ist die Familie von Mistpark bis Forte schon wieder übersichtlich, vor allem, wenn die anderen mehreren Dutzend toten Forkeys mit dazugeholt werden. Immerhin stammt von Mistpark bis Forte über etwa 15 Jahre alles vom selben Schöpfer, der einfach nur sein eigenes Zeug geforkt hat.
#Long #LongPost #CWLong #CWLongPost #LangerPost #CWLangerPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Misskey #Forkey #Forkeys #Calckey #Firefish #Iceshrimp #IceshrimpJS #Iceshrimp.NET #Catodon #Sharkey #CherryPick #FoundKey #Hajkey #Neko #Meisskey #Leisskey #Tanukey #Backspacekey - Misskey
-
Misskey und Derivate, steigt ihr da durch?
Ich hab mal versucht herauszufinden wie sich das mit Misskey, Foundkey, Calckey, Firefish, Sharkey, Iceshrimp und Iceshrimp.NET verhält. Gerne korrigieren.
Misskey ist wohl der Ursprung und immer noch sehr aktiv in der Entwicklung. ✅
Foundkey ein früher Fork von Misskey, mittlerweile eingestellt. ❌
Calckey ein Fork von Foundkey, scheinbar auch nicht mehr aktiv weiterentwickelt. ❌
Firefish war dann wohl irgendwann ein neuer Name von Calckey. Wurde ebenfalls 2023 aufgelöst durch den Hauptentwickler. ❌
Iceshrimp war dann wohl wiederum ein Fork von Firefish. Es kommen scheinbar keine neuen Features mehr, da das Team sich auf eine Neuimplementierung mit .NET konzentriert (Iceshrimp.NET). 🟡
Firefish (neu) kurzes Aufbäumen des Firefish Projekts, Seti 2024 keine weiteren Commits mehr im Git Repository. ❌
Sharkey ein Fork des neuen Firefish, wohl das einzige Projekt neben Misskey, das noch aktiv weiterentwickelt wird (Iceshrimp.NET hat keine gemeinsame Codebasis mit Misskey mehr). ✅
Irgendwie schade, dass so viele enthusiastische Entwickler es nicht fertig bringen über eine längere Zeit gemeinsam an einer Variante zu arbeiten 😭.
-
Misskey und Derivate, steigt ihr da durch?
Ich hab mal versucht herauszufinden wie sich das mit Misskey, Foundkey, Calckey, Firefish, Sharkey, Iceshrimp und Iceshrimp.NET verhält. Gerne korrigieren.
Misskey ist wohl der Ursprung und immer noch sehr aktiv in der Entwicklung. ✅
Foundkey ein früher Fork von Misskey, mittlerweile eingestellt. ❌
Calckey ein Fork von Foundkey, scheinbar auch nicht mehr aktiv weiterentwickelt. ❌
Firefish war dann wohl irgendwann ein neuer Name von Calckey. Wurde ebenfalls 2023 aufgelöst durch den Hauptentwickler. ❌
Iceshrimp war dann wohl wiederum ein Fork von Firefish. Es kommen scheinbar keine neuen Features mehr, da das Team sich auf eine Neuimplementierung mit .NET konzentriert (Iceshrimp.NET). 🟡
Firefish (neu) kurzes Aufbäumen des Firefish Projekts, Seti 2024 keine weiteren Commits mehr im Git Repository. ❌
Sharkey ein Fork des neuen Firefish, wohl das einzige Projekt neben Misskey, das noch aktiv weiterentwickelt wird (Iceshrimp.NET hat keine gemeinsame Codebasis mit Misskey mehr). ✅
Irgendwie schade, dass so viele enthusiastische Entwickler es nicht fertig bringen über eine längere Zeit gemeinsam an einer Variante zu arbeiten 😭.
-
Misskey und Derivate, steigt ihr da durch?
Ich hab mal versucht herauszufinden wie sich das mit Misskey, Foundkey, Calckey, Firefish, Sharkey, Iceshrimp und Iceshrimp.NET verhält. Gerne korrigieren.
Misskey ist wohl der Ursprung und immer noch sehr aktiv in der Entwicklung. ✅
Foundkey ein früher Fork von Misskey, mittlerweile eingestellt. ❌
Calckey ein Fork von Foundkey, scheinbar auch nicht mehr aktiv weiterentwickelt. ❌
Firefish war dann wohl irgendwann ein neuer Name von Calckey. Wurde ebenfalls 2023 aufgelöst durch den Hauptentwickler. ❌
Iceshrimp war dann wohl wiederum ein Fork von Firefish. Es kommen scheinbar keine neuen Features mehr, da das Team sich auf eine Neuimplementierung mit .NET konzentriert (Iceshrimp.NET). 🟡
Firefish (neu) kurzes Aufbäumen des Firefish Projekts, Seti 2024 keine weiteren Commits mehr im Git Repository. ❌
Sharkey ein Fork des neuen Firefish, wohl das einzige Projekt neben Misskey, das noch aktiv weiterentwickelt wird (Iceshrimp.NET hat keine gemeinsame Codebasis mit Misskey mehr). ✅
Irgendwie schade, dass so viele enthusiastische Entwickler es nicht fertig bringen über eine längere Zeit gemeinsam an einer Variante zu arbeiten 😭.
-
Misskey und Derivate, steigt ihr da durch?
Ich hab mal versucht herauszufinden wie sich das mit Misskey, Foundkey, Calckey, Firefish, Sharkey, Iceshrimp und Iceshrimp.NET verhält. Gerne korrigieren.
Misskey ist wohl der Ursprung und immer noch sehr aktiv in der Entwicklung. ✅
Foundkey ein früher Fork von Misskey, mittlerweile eingestellt. ❌
Calckey ein Fork von Foundkey, scheinbar auch nicht mehr aktiv weiterentwickelt. ❌
Firefish war dann wohl irgendwann ein neuer Name von Calckey. Wurde ebenfalls 2023 aufgelöst durch den Hauptentwickler. ❌
Iceshrimp war dann wohl wiederum ein Fork von Firefish. Es kommen scheinbar keine neuen Features mehr, da das Team sich auf eine Neuimplementierung mit .NET konzentriert (Iceshrimp.NET). 🟡
Firefish (neu) kurzes Aufbäumen des Firefish Projekts, Seti 2024 keine weiteren Commits mehr im Git Repository. ❌
Sharkey ein Fork des neuen Firefish, wohl das einzige Projekt neben Misskey, das noch aktiv weiterentwickelt wird (Iceshrimp.NET hat keine gemeinsame Codebasis mit Misskey mehr). ✅
Irgendwie schade, dass so viele enthusiastische Entwickler es nicht fertig bringen über eine längere Zeit gemeinsam an einer Variante zu arbeiten 😭.
-
Misskey und Derivate, steigt ihr da durch?
Ich hab mal versucht herauszufinden wie sich das mit Misskey, Foundkey, Calckey, Firefish, Sharkey, Iceshrimp und Iceshrimp.NET verhält. Gerne korrigieren.
Misskey ist wohl der Ursprung und immer noch sehr aktiv in der Entwicklung. ✅
Foundkey ein früher Fork von Misskey, mittlerweile eingestellt. ❌
Calckey ein Fork von Foundkey, scheinbar auch nicht mehr aktiv weiterentwickelt. ❌
Firefish war dann wohl irgendwann ein neuer Name von Calckey. Wurde ebenfalls 2023 aufgelöst durch den Hauptentwickler. ❌
Iceshrimp war dann wohl wiederum ein Fork von Firefish. Es kommen scheinbar keine neuen Features mehr, da das Team sich auf eine Neuimplementierung mit .NET konzentriert (Iceshrimp.NET). 🟡
Firefish (neu) kurzes Aufbäumen des Firefish Projekts, Seti 2024 keine weiteren Commits mehr im Git Repository. ❌
Sharkey ein Fork des neuen Firefish, wohl das einzige Projekt neben Misskey, das noch aktiv weiterentwickelt wird (Iceshrimp.NET hat keine gemeinsame Codebasis mit Misskey mehr). ✅
Irgendwie schade, dass so viele enthusiastische Entwickler es nicht fertig bringen über eine längere Zeit gemeinsam an einer Variante zu arbeiten 😭.
-
Sharkey & Iceshrimp Instanzen
Ich habe die Liste ein wenig überarbeitet.
Da es für die Misskey-Forks keine Anzahl der aktiven User gibt, wie bei allen anderen Fediverse-Plattformen, sortiere ich jetzt nach der Anzahl der gerade aktiven User. Das ist zwar nur eine Momentaufnahme, aber trotzdem ein guter Hinweis dafür, ob auf der Instanz etwas los ist.
https://contentnation.net/de/favstarmafia/sharkey
#Sharkey
#Iceshrimp
#Firefish
#Instanzliste
RE: https://procial.tchncs.de/notes/ags2qegz9brg067o -
Seen quite a few posts about migrating away from corporate social media. While I have been able to post some alternatives such as #Mastodon #pixelfed #peertube and #loops there doesn't seem to be a #Fediverse alternative to #Facebook
I am on #friendica and good as it is, it's nothing like Facebook.
#Firefish was showing potential but that seems to have sunk. Just been looking at #sharkey and that doesn't seem to be it.
Any suggestions?
-
Mittlerweile bin ich jetzt schon über eine Woche auf fedia.social und also Zeit für ein erstes Fazit: #iceshrimp macht mit voller Timeline sehr viel mehr Spaß als die mikrigen paar Accounts, die ich im Testbetrieb mal hinzugefügt habe. Und da ich social Media vor allem am PC betreibe, kommen auch die Widgets sehr schön zur Geltung, hauptsächlich das für die Benachrichtigungen, die ich so direkt lesen kann ohne erst auf eine Unterseite gehen zu müssen.
Viel mehr habe ich allerdings auch noch nicht ausprobiert, nur einmal habe ich neben einem Like auch ein "Herzchen" vergeben, und dies hier dürfte der erste längere Beitrag sein. Und ich genieße sehr, dass ich nicht ständig auf eine mikrige Nummer von Restzeichen blicken muss :-)
Ein paar Unterschiede/Nachteile gibts natürlich auch, vermissen tue ich etwas die Möglichkeit von #Mastodon, auch Hashtags folgen zu können. Stattdessen gibts bei den #Misskey/#Firefish Forks sogenannte "Antennen", das sind Listen mit Kriterien (Stichwörter, Hashtags), die einen eigenen Feed mit entsprechenden Posts erzeugen. Was im Prinzip funktioniert, allerdings spuckt der Feed immer nur ein paar Posts aus, die auch nie besonders lange zurückliegen. Möglicherweise eine Servereinstellung, klicke ich dann z.B. auf einen Hashtag, kriege ich eine eine ganz normale Ausgabe wie auch nach einer Suche, ohne irgend eine Begrenzung der Anzahl von Beiträgen.
Und dann fehlen gelegentlich unter Beiträgen ein paar Kommentare, dies wird aber immer auch durch einen entsprechenden Hinweis oben auf der Seite angezeigt, mit einem Link zur entsprechenden Instanz. Kenne ich auch von Mastodon, war dort aber wesentlich seltener.
Für mich jetzt alles keine großen Probleme, vor allem nicht im Hinblick darauf, dass gerade die #iceshrimp Codebase neu geschrieben und hoffentlich auch irgendwann mal freigegeben wird. Das entsprechende Repository auf iceshrimp.dev ist auf jeden Fall aktiv, und ich bin da guter Hoffnung, dass die überarbeitete Version noch vieeeel besser wird. :-) -
@Robert Frank Wenn man selbst nur Mastodon nutzt, fühlt es sich piepschnurzegal an. Dann nimmt man eh das ganze Fediverse als nur Mastodon wahr und die Unterschiede zwischen Mastodon und Nicht-Mastodon fast überhaupt nicht.
Wenn man selbst aber etwas ganz anderes im Fediverse nutzt als Mastodon, dann ist es immens wichtig.
Ich selbst bin nicht auf Mastodon. Ich bin auf Hubzilla (https://hubzilla.org, https://de.wikipedia.org/wiki/Hubzilla, https://hub.netzgemeinde.eu/item/0a75de76-eb27-4149-b708-f20b2f79d392). Das funktioniert völlig anders als Mastodon, das hat ein völlig anderes Konzept als Mastodon, das wird von Mastodon völlig unabhängig entwickelt. Es hat Features, die auf Mastodon unvorstellbar sind. Noch dazu ist es zehn Monate älter als Mastodon. Es geht sogar zurück auf Friendica, das mehr als fünfeinhalb Jahre älter ist als Mastodon.
Aber wie du mit eigenen Augen sehen kannst, kann ich Mastodon-Tröts nicht nur empfangen, sondern auch von Hubzilla aus kommentieren.
Wenn jemand das komplette Fediverse meint, es aber "Mastodon" nennt, dann meint er mich zwar damit, spricht mich aber nicht an. Ich bin ja nicht auf Mastodon.
Wenn jemand einen meiner Posts oder Kommentare als "Tröt" bezeichnet in der Annahme, ich sei auch auf Mastodon, dann ist beides sachlich falsch.
Wenn jemand sich wünscht, "das Fediverse" möge endlich ein bestimmtes Feature einführen, nur weil Mastodon es nicht hat, dann kann ich mir nur vor den Kopf schlagen. In den allermeisten Fällen hat Hubzilla genau dieses Feature schon zehn Monate länger, als es Mastodon überhaupt gibt. Sehr häufig hat Friendica dieses Feature schon etliche Jahre länger, als es Mastodon überhaupt gibt. Das Fediverse hat dieses Feature also. Mastodon hat es nicht, aber das Fediverse hat es.
Wenn jemand dagegen ist, daß "das Fediverse" ein bestimmtes Feature einführt, dem sei gesagt: Höchstwahrscheinlich hat das Fediverse dieses Feature schon. Mastodon nicht, aber das Fediverse. Denn höchstwahrscheinlich hatten Friendica und Hubzilla es schon immer, also auch wieder länger, als es Mastodon überhaupt gibt.
Am besten war noch der Widerstand gegen Quote-Posts. "Das Fediverse" sollte die auf gar keinen Fall einführen, sagten einige. Der Witz: Pleroma, Akkoma, Misskey, Calckey, Firefish, CherryPick, Sharkey, Iceshrimp, Catodon, GoToSocial, Mitra, Friendica, Hubzilla, (streams), Forte usw., sie alle haben Quote-Posts. Und zwar schon länger, als es diese Debatte auf Mastodon überhaupt gibt. Und sie alle (außer GoToSocial) können widerstandslos jeden, aber auch wirklich jeden Mastodon-Tröt quote-posten.
Oder damals der Widerstand gegen Volltextsuche. Auf gar keinen Fall sollte "das Fediverse" Volltextsuche haben. Nur hatte das Fediverse schon längst Volltextsuche: Friendica war schon im Mai 2010 mit eingebauter Volltextsuche an den Start gegangen.
Ach ja: Zeichenlimits. Wer "Mastodon" und "Fediverse" gleichsetzt, für den hat auch das Fediverse ein festgelegtes Limit von 500 Zeichen. Friendica und Hubzilla hatten aber nie wirklich Zeichenlimits. In deren Kultur kommen auch keine Zeichenlimits vor. Aktuell haben sie übrigens ein "Limit" von über 16,7 Millionen Zeichen. Bis auf Threads hat alles im Fediverse ein sehr viel höheres Zeichenlimit als Mastodon. Entsprechend kriegen Nicht-Mastodon-Nutzer ständig auf den Deckel, wenn sie das angeblich von Gargron für das ganze Fediverse festgeschriebene Limit von 500 Zeichen überschreiten.
Also: Das Fediverse ist nicht nur Mastodon. Das Fediverse war auch nie nur Mastodon. Das Fediverse ist nicht nur ein Twitter-Klon. Das Fediverse hat sehr viel mehr Features als Mastodon. Und das Fediverse hat auch nicht überall dieselbe Kultur und wird sie auch nie haben.
CC: @Knust @Katharina Nocun
#Long #LongPost #CWLong #CWLongPost #LangerPost #CWLangerPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #QuotePost #QuotePosts #QuoteTweet #QuoteTweets #QuoteToot #QuoteToots #QuoteTröt #QuoteTröts #QuoteBoost #QuoteBoosts #Zeichenlimit #Zeichenlimits #ZeichenlimitMeta #CWZeichenlimitMeta #Fediverse #Mastodon #NichtNurMastodon #Pleroma #Akkoma #Misskey #Calckey #Firefish #CherryPick #Sharkey #Iceshrimp #Catodon #GoToSocial #Mitra #Friendica #Hubzilla #Streams #(streams) #Forte #MastodonZentrizität #MastodonNormativität -
@Robert Frank Wenn man selbst nur Mastodon nutzt, fühlt es sich piepschnurzegal an. Dann nimmt man eh das ganze Fediverse als nur Mastodon wahr und die Unterschiede zwischen Mastodon und Nicht-Mastodon fast überhaupt nicht.
Wenn man selbst aber etwas ganz anderes im Fediverse nutzt als Mastodon, dann ist es immens wichtig.
Ich selbst bin nicht auf Mastodon. Ich bin auf Hubzilla (https://hubzilla.org, https://de.wikipedia.org/wiki/Hubzilla, https://hub.netzgemeinde.eu/item/0a75de76-eb27-4149-b708-f20b2f79d392). Das funktioniert völlig anders als Mastodon, das hat ein völlig anderes Konzept als Mastodon, das wird von Mastodon völlig unabhängig entwickelt. Es hat Features, die auf Mastodon unvorstellbar sind. Noch dazu ist es zehn Monate älter als Mastodon. Es geht sogar zurück auf Friendica, das mehr als fünfeinhalb Jahre älter ist als Mastodon.
Aber wie du mit eigenen Augen sehen kannst, kann ich Mastodon-Tröts nicht nur empfangen, sondern auch von Hubzilla aus kommentieren.
Wenn jemand das komplette Fediverse meint, es aber "Mastodon" nennt, dann meint er mich zwar damit, spricht mich aber nicht an. Ich bin ja nicht auf Mastodon.
Wenn jemand einen meiner Posts oder Kommentare als "Tröt" bezeichnet in der Annahme, ich sei auch auf Mastodon, dann ist beides sachlich falsch.
Wenn jemand sich wünscht, "das Fediverse" möge endlich ein bestimmtes Feature einführen, nur weil Mastodon es nicht hat, dann kann ich mir nur vor den Kopf schlagen. In den allermeisten Fällen hat Hubzilla genau dieses Feature schon zehn Monate länger, als es Mastodon überhaupt gibt. Sehr häufig hat Friendica dieses Feature schon etliche Jahre länger, als es Mastodon überhaupt gibt. Das Fediverse hat dieses Feature also. Mastodon hat es nicht, aber das Fediverse hat es.
Wenn jemand dagegen ist, daß "das Fediverse" ein bestimmtes Feature einführt, dem sei gesagt: Höchstwahrscheinlich hat das Fediverse dieses Feature schon. Mastodon nicht, aber das Fediverse. Denn höchstwahrscheinlich hatten Friendica und Hubzilla es schon immer, also auch wieder länger, als es Mastodon überhaupt gibt.
Am besten war noch der Widerstand gegen Quote-Posts. "Das Fediverse" sollte die auf gar keinen Fall einführen, sagten einige. Der Witz: Pleroma, Akkoma, Misskey, Calckey, Firefish, CherryPick, Sharkey, Iceshrimp, Catodon, GoToSocial, Mitra, Friendica, Hubzilla, (streams), Forte usw., sie alle haben Quote-Posts. Und zwar schon länger, als es diese Debatte auf Mastodon überhaupt gibt. Und sie alle (außer GoToSocial) können widerstandslos jeden, aber auch wirklich jeden Mastodon-Tröt quote-posten.
Oder damals der Widerstand gegen Volltextsuche. Auf gar keinen Fall sollte "das Fediverse" Volltextsuche haben. Nur hatte das Fediverse schon längst Volltextsuche: Friendica war schon im Mai 2010 mit eingebauter Volltextsuche an den Start gegangen.
Ach ja: Zeichenlimits. Wer "Mastodon" und "Fediverse" gleichsetzt, für den hat auch das Fediverse ein festgelegtes Limit von 500 Zeichen. Friendica und Hubzilla hatten aber nie wirklich Zeichenlimits. In deren Kultur kommen auch keine Zeichenlimits vor. Aktuell haben sie übrigens ein "Limit" von über 16,7 Millionen Zeichen. Bis auf Threads hat alles im Fediverse ein sehr viel höheres Zeichenlimit als Mastodon. Entsprechend kriegen Nicht-Mastodon-Nutzer ständig auf den Deckel, wenn sie das angeblich von Gargron für das ganze Fediverse festgeschriebene Limit von 500 Zeichen überschreiten.
Also: Das Fediverse ist nicht nur Mastodon. Das Fediverse war auch nie nur Mastodon. Das Fediverse ist nicht nur ein Twitter-Klon. Das Fediverse hat sehr viel mehr Features als Mastodon. Und das Fediverse hat auch nicht überall dieselbe Kultur und wird sie auch nie haben.
CC: @Knust @Katharina Nocun
#Long #LongPost #CWLong #CWLongPost #LangerPost #CWLangerPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #QuotePost #QuotePosts #QuoteTweet #QuoteTweets #QuoteToot #QuoteToots #QuoteTröt #QuoteTröts #QuoteBoost #QuoteBoosts #Zeichenlimit #Zeichenlimits #ZeichenlimitMeta #CWZeichenlimitMeta #Fediverse #Mastodon #NichtNurMastodon #Pleroma #Akkoma #Misskey #Calckey #Firefish #CherryPick #Sharkey #Iceshrimp #Catodon #GoToSocial #Mitra #Friendica #Hubzilla #Streams #(streams) #Forte #MastodonZentrizität #MastodonNormativität -
@Robert Frank Wenn man selbst nur Mastodon nutzt, fühlt es sich piepschnurzegal an. Dann nimmt man eh das ganze Fediverse als nur Mastodon wahr und die Unterschiede zwischen Mastodon und Nicht-Mastodon fast überhaupt nicht.
Wenn man selbst aber etwas ganz anderes im Fediverse nutzt als Mastodon, dann ist es immens wichtig.
Ich selbst bin nicht auf Mastodon. Ich bin auf Hubzilla (https://hubzilla.org, https://de.wikipedia.org/wiki/Hubzilla, https://hub.netzgemeinde.eu/item/0a75de76-eb27-4149-b708-f20b2f79d392). Das funktioniert völlig anders als Mastodon, das hat ein völlig anderes Konzept als Mastodon, das wird von Mastodon völlig unabhängig entwickelt. Es hat Features, die auf Mastodon unvorstellbar sind. Noch dazu ist es zehn Monate älter als Mastodon. Es geht sogar zurück auf Friendica, das mehr als fünfeinhalb Jahre älter ist als Mastodon.
Aber wie du mit eigenen Augen sehen kannst, kann ich Mastodon-Tröts nicht nur empfangen, sondern auch von Hubzilla aus kommentieren.
Wenn jemand das komplette Fediverse meint, es aber "Mastodon" nennt, dann meint er mich zwar damit, spricht mich aber nicht an. Ich bin ja nicht auf Mastodon.
Wenn jemand einen meiner Posts oder Kommentare als "Tröt" bezeichnet in der Annahme, ich sei auch auf Mastodon, dann ist beides sachlich falsch.
Wenn jemand sich wünscht, "das Fediverse" möge endlich ein bestimmtes Feature einführen, nur weil Mastodon es nicht hat, dann kann ich mir nur vor den Kopf schlagen. In den allermeisten Fällen hat Hubzilla genau dieses Feature schon zehn Monate länger, als es Mastodon überhaupt gibt. Sehr häufig hat Friendica dieses Feature schon etliche Jahre länger, als es Mastodon überhaupt gibt. Das Fediverse hat dieses Feature also. Mastodon hat es nicht, aber das Fediverse hat es.
Wenn jemand dagegen ist, daß "das Fediverse" ein bestimmtes Feature einführt, dem sei gesagt: Höchstwahrscheinlich hat das Fediverse dieses Feature schon. Mastodon nicht, aber das Fediverse. Denn höchstwahrscheinlich hatten Friendica und Hubzilla es schon immer, also auch wieder länger, als es Mastodon überhaupt gibt.
Am besten war noch der Widerstand gegen Quote-Posts. "Das Fediverse" sollte die auf gar keinen Fall einführen, sagten einige. Der Witz: Pleroma, Akkoma, Misskey, Calckey, Firefish, CherryPick, Sharkey, Iceshrimp, Catodon, GoToSocial, Mitra, Friendica, Hubzilla, (streams), Forte usw., sie alle haben Quote-Posts. Und zwar schon länger, als es diese Debatte auf Mastodon überhaupt gibt. Und sie alle (außer GoToSocial) können widerstandslos jeden, aber auch wirklich jeden Mastodon-Tröt quote-posten.
Oder damals der Widerstand gegen Volltextsuche. Auf gar keinen Fall sollte "das Fediverse" Volltextsuche haben. Nur hatte das Fediverse schon längst Volltextsuche: Friendica war schon im Mai 2010 mit eingebauter Volltextsuche an den Start gegangen.
Ach ja: Zeichenlimits. Wer "Mastodon" und "Fediverse" gleichsetzt, für den hat auch das Fediverse ein festgelegtes Limit von 500 Zeichen. Friendica und Hubzilla hatten aber nie wirklich Zeichenlimits. In deren Kultur kommen auch keine Zeichenlimits vor. Aktuell haben sie übrigens ein "Limit" von über 16,7 Millionen Zeichen. Bis auf Threads hat alles im Fediverse ein sehr viel höheres Zeichenlimit als Mastodon. Entsprechend kriegen Nicht-Mastodon-Nutzer ständig auf den Deckel, wenn sie das angeblich von Gargron für das ganze Fediverse festgeschriebene Limit von 500 Zeichen überschreiten.
Also: Das Fediverse ist nicht nur Mastodon. Das Fediverse war auch nie nur Mastodon. Das Fediverse ist nicht nur ein Twitter-Klon. Das Fediverse hat sehr viel mehr Features als Mastodon. Und das Fediverse hat auch nicht überall dieselbe Kultur und wird sie auch nie haben.
CC: @Knust @Katharina Nocun
#Long #LongPost #CWLong #CWLongPost #LangerPost #CWLangerPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #QuotePost #QuotePosts #QuoteTweet #QuoteTweets #QuoteToot #QuoteToots #QuoteTröt #QuoteTröts #QuoteBoost #QuoteBoosts #Zeichenlimit #Zeichenlimits #ZeichenlimitMeta #CWZeichenlimitMeta #Fediverse #Mastodon #NichtNurMastodon #Pleroma #Akkoma #Misskey #Calckey #Firefish #CherryPick #Sharkey #Iceshrimp #Catodon #GoToSocial #Mitra #Friendica #Hubzilla #Streams #(streams) #Forte #MastodonZentrizität #MastodonNormativität -
@Robert Frank Wenn man selbst nur Mastodon nutzt, fühlt es sich piepschnurzegal an. Dann nimmt man eh das ganze Fediverse als nur Mastodon wahr und die Unterschiede zwischen Mastodon und Nicht-Mastodon fast überhaupt nicht.
Wenn man selbst aber etwas ganz anderes im Fediverse nutzt als Mastodon, dann ist es immens wichtig.
Ich selbst bin nicht auf Mastodon. Ich bin auf Hubzilla (https://hubzilla.org, https://de.wikipedia.org/wiki/Hubzilla, https://hub.netzgemeinde.eu/item/0a75de76-eb27-4149-b708-f20b2f79d392). Das funktioniert völlig anders als Mastodon, das hat ein völlig anderes Konzept als Mastodon, das wird von Mastodon völlig unabhängig entwickelt. Es hat Features, die auf Mastodon unvorstellbar sind. Noch dazu ist es zehn Monate älter als Mastodon. Es geht sogar zurück auf Friendica, das mehr als fünfeinhalb Jahre älter ist als Mastodon.
Aber wie du mit eigenen Augen sehen kannst, kann ich Mastodon-Tröts nicht nur empfangen, sondern auch von Hubzilla aus kommentieren.
Wenn jemand das komplette Fediverse meint, es aber "Mastodon" nennt, dann meint er mich zwar damit, spricht mich aber nicht an. Ich bin ja nicht auf Mastodon.
Wenn jemand einen meiner Posts oder Kommentare als "Tröt" bezeichnet in der Annahme, ich sei auch auf Mastodon, dann ist beides sachlich falsch.
Wenn jemand sich wünscht, "das Fediverse" möge endlich ein bestimmtes Feature einführen, nur weil Mastodon es nicht hat, dann kann ich mir nur vor den Kopf schlagen. In den allermeisten Fällen hat Hubzilla genau dieses Feature schon zehn Monate länger, als es Mastodon überhaupt gibt. Sehr häufig hat Friendica dieses Feature schon etliche Jahre länger, als es Mastodon überhaupt gibt. Das Fediverse hat dieses Feature also. Mastodon hat es nicht, aber das Fediverse hat es.
Wenn jemand dagegen ist, daß "das Fediverse" ein bestimmtes Feature einführt, dem sei gesagt: Höchstwahrscheinlich hat das Fediverse dieses Feature schon. Mastodon nicht, aber das Fediverse. Denn höchstwahrscheinlich hatten Friendica und Hubzilla es schon immer, also auch wieder länger, als es Mastodon überhaupt gibt.
Am besten war noch der Widerstand gegen Quote-Posts. "Das Fediverse" sollte die auf gar keinen Fall einführen, sagten einige. Der Witz: Pleroma, Akkoma, Misskey, Calckey, Firefish, CherryPick, Sharkey, Iceshrimp, Catodon, GoToSocial, Mitra, Friendica, Hubzilla, (streams), Forte usw., sie alle haben Quote-Posts. Und zwar schon länger, als es diese Debatte auf Mastodon überhaupt gibt. Und sie alle (außer GoToSocial) können widerstandslos jeden, aber auch wirklich jeden Mastodon-Tröt quote-posten.
Oder damals der Widerstand gegen Volltextsuche. Auf gar keinen Fall sollte "das Fediverse" Volltextsuche haben. Nur hatte das Fediverse schon längst Volltextsuche: Friendica war schon im Mai 2010 mit eingebauter Volltextsuche an den Start gegangen.
Ach ja: Zeichenlimits. Wer "Mastodon" und "Fediverse" gleichsetzt, für den hat auch das Fediverse ein festgelegtes Limit von 500 Zeichen. Friendica und Hubzilla hatten aber nie wirklich Zeichenlimits. In deren Kultur kommen auch keine Zeichenlimits vor. Aktuell haben sie übrigens ein "Limit" von über 16,7 Millionen Zeichen. Bis auf Threads hat alles im Fediverse ein sehr viel höheres Zeichenlimit als Mastodon. Entsprechend kriegen Nicht-Mastodon-Nutzer ständig auf den Deckel, wenn sie das angeblich von Gargron für das ganze Fediverse festgeschriebene Limit von 500 Zeichen überschreiten.
Also: Das Fediverse ist nicht nur Mastodon. Das Fediverse war auch nie nur Mastodon. Das Fediverse ist nicht nur ein Twitter-Klon. Das Fediverse hat sehr viel mehr Features als Mastodon. Und das Fediverse hat auch nicht überall dieselbe Kultur und wird sie auch nie haben.
CC: @Knust @Katharina Nocun
#Long #LongPost #CWLong #CWLongPost #LangerPost #CWLangerPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #QuotePost #QuotePosts #QuoteTweet #QuoteTweets #QuoteToot #QuoteToots #QuoteTröt #QuoteTröts #QuoteBoost #QuoteBoosts #Zeichenlimit #Zeichenlimits #ZeichenlimitMeta #CWZeichenlimitMeta #Fediverse #Mastodon #NichtNurMastodon #Pleroma #Akkoma #Misskey #Calckey #Firefish #CherryPick #Sharkey #Iceshrimp #Catodon #GoToSocial #Mitra #Friendica #Hubzilla #Streams #(streams) #Forte #MastodonZentrizität #MastodonNormativität -
@Robert Frank Wenn man selbst nur Mastodon nutzt, fühlt es sich piepschnurzegal an. Dann nimmt man eh das ganze Fediverse als nur Mastodon wahr und die Unterschiede zwischen Mastodon und Nicht-Mastodon fast überhaupt nicht.
Wenn man selbst aber etwas ganz anderes im Fediverse nutzt als Mastodon, dann ist es immens wichtig.
Ich selbst bin nicht auf Mastodon. Ich bin auf Hubzilla (https://hubzilla.org, https://de.wikipedia.org/wiki/Hubzilla, https://hub.netzgemeinde.eu/item/0a75de76-eb27-4149-b708-f20b2f79d392). Das funktioniert völlig anders als Mastodon, das hat ein völlig anderes Konzept als Mastodon, das wird von Mastodon völlig unabhängig entwickelt. Es hat Features, die auf Mastodon unvorstellbar sind. Noch dazu ist es zehn Monate älter als Mastodon. Es geht sogar zurück auf Friendica, das mehr als fünfeinhalb Jahre älter ist als Mastodon.
Aber wie du mit eigenen Augen sehen kannst, kann ich Mastodon-Tröts nicht nur empfangen, sondern auch von Hubzilla aus kommentieren.
Wenn jemand das komplette Fediverse meint, es aber "Mastodon" nennt, dann meint er mich zwar damit, spricht mich aber nicht an. Ich bin ja nicht auf Mastodon.
Wenn jemand einen meiner Posts oder Kommentare als "Tröt" bezeichnet in der Annahme, ich sei auch auf Mastodon, dann ist beides sachlich falsch.
Wenn jemand sich wünscht, "das Fediverse" möge endlich ein bestimmtes Feature einführen, nur weil Mastodon es nicht hat, dann kann ich mir nur vor den Kopf schlagen. In den allermeisten Fällen hat Hubzilla genau dieses Feature schon zehn Monate länger, als es Mastodon überhaupt gibt. Sehr häufig hat Friendica dieses Feature schon etliche Jahre länger, als es Mastodon überhaupt gibt. Das Fediverse hat dieses Feature also. Mastodon hat es nicht, aber das Fediverse hat es.
Wenn jemand dagegen ist, daß "das Fediverse" ein bestimmtes Feature einführt, dem sei gesagt: Höchstwahrscheinlich hat das Fediverse dieses Feature schon. Mastodon nicht, aber das Fediverse. Denn höchstwahrscheinlich hatten Friendica und Hubzilla es schon immer, also auch wieder länger, als es Mastodon überhaupt gibt.
Am besten war noch der Widerstand gegen Quote-Posts. "Das Fediverse" sollte die auf gar keinen Fall einführen, sagten einige. Der Witz: Pleroma, Akkoma, Misskey, Calckey, Firefish, CherryPick, Sharkey, Iceshrimp, Catodon, GoToSocial, Mitra, Friendica, Hubzilla, (streams), Forte usw., sie alle haben Quote-Posts. Und zwar schon länger, als es diese Debatte auf Mastodon überhaupt gibt. Und sie alle (außer GoToSocial) können widerstandslos jeden, aber auch wirklich jeden Mastodon-Tröt quote-posten.
Oder damals der Widerstand gegen Volltextsuche. Auf gar keinen Fall sollte "das Fediverse" Volltextsuche haben. Nur hatte das Fediverse schon längst Volltextsuche: Friendica war schon im Mai 2010 mit eingebauter Volltextsuche an den Start gegangen.
Ach ja: Zeichenlimits. Wer "Mastodon" und "Fediverse" gleichsetzt, für den hat auch das Fediverse ein festgelegtes Limit von 500 Zeichen. Friendica und Hubzilla hatten aber nie wirklich Zeichenlimits. In deren Kultur kommen auch keine Zeichenlimits vor. Aktuell haben sie übrigens ein "Limit" von über 16,7 Millionen Zeichen. Bis auf Threads hat alles im Fediverse ein sehr viel höheres Zeichenlimit als Mastodon. Entsprechend kriegen Nicht-Mastodon-Nutzer ständig auf den Deckel, wenn sie das angeblich von Gargron für das ganze Fediverse festgeschriebene Limit von 500 Zeichen überschreiten.
Also: Das Fediverse ist nicht nur Mastodon. Das Fediverse war auch nie nur Mastodon. Das Fediverse ist nicht nur ein Twitter-Klon. Das Fediverse hat sehr viel mehr Features als Mastodon. Und das Fediverse hat auch nicht überall dieselbe Kultur und wird sie auch nie haben.
CC: @Knust @Katharina Nocun
#Long #LongPost #CWLong #CWLongPost #LangerPost #CWLangerPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #QuotePost #QuotePosts #QuoteTweet #QuoteTweets #QuoteToot #QuoteToots #QuoteTröt #QuoteTröts #QuoteBoost #QuoteBoosts #Zeichenlimit #Zeichenlimits #ZeichenlimitMeta #CWZeichenlimitMeta #Fediverse #Mastodon #NichtNurMastodon #Pleroma #Akkoma #Misskey #Calckey #Firefish #CherryPick #Sharkey #Iceshrimp #Catodon #GoToSocial #Mitra #Friendica #Hubzilla #Streams #(streams) #Forte #MastodonZentrizität #MastodonNormativität -
And now that I think about it, that makes it two years since I started my #Friendica instance. I've been on the #Fediverse for much longer of course (including other #ActivityPub apps I've hosted here such as #Akkoma and #Firefish ), but still, happy #Fediversary to me!
-
And now that I think about it, that makes it two years since I started my #Friendica instance. I've been on the #Fediverse for much longer of course (including other #ActivityPub apps I've hosted here such as #Akkoma and #Firefish ), but still, happy #Fediversary to me! -
@Herr TurTur @crossgolf_rebel - kostenlose Kwalitätsposts @tux0r :openbsd: Die Idee hinter Sharkey war mal, in einen einzigen Forkey quasi alles auf einmal reinzuschmeißen bis hin zur Küchenspüle. Das fiel vor allem auf, als es noch mehr lebendige Forkeys zur Auswahl gab.
Und in der Zeit hatte Sharkey auch noch gewisse Macken, z. B. eine schon legendär unzuverlässige Implementation der Mastodon Client API, wo es hieß, am besten setzt sich einer hin und schreibt die neu. Wer was Zuverlässiges wollte, setzte damals auf Iceshrimp. Sharkey war für wagemutige Spielkinder, die sich an Hubzilla nicht rantrauten.
Inzwischen ist Calckey tot, Firefish ist tot, Iceshrimp-JS ist im Wartungsmodus (Iceshrimp.NET ist derweil noch meilenweit von "fertig" entfernt), Catodon ist auch schon siech, und das nur für eine Instanz gebaute Hajkey ist schon verwest.
CherryPick hat fast nur Server in den Großräumen Tokyo und Seoul und fühlt sich so auf den ostasiatischen Geschmack ausgelegt an wie vor ein paar Jahren noch Misskey selbst. Vielleicht erinnern sich ein paar noch daran, wie Misskey mal den Charme japanischer Verkaufsautomaten hatte.
Und der ganze noch lebende Rest scheint selbst mit Misskeys Entwicklung nicht mithalten zu können, also im Kern veraltet zu sein.
Derweil ist Sharkey wohl inzwischen ziemlich zuverlässig. So ist es zumindest im Westen zum einzigen noch nennenswerten Forkey avanciert.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Misskey #Forkey #Forkeys #Sharkey #Calckey #Firefish #Iceshrimp #Iceshrimp-JS #Iceshrimp.NET #Catodon #Hajkey #CherryPick -
@Herr TurTur @crossgolf_rebel - kostenlose Kwalitätsposts @tux0r :openbsd: Die Idee hinter Sharkey war mal, in einen einzigen Forkey quasi alles auf einmal reinzuschmeißen bis hin zur Küchenspüle. Das fiel vor allem auf, als es noch mehr lebendige Forkeys zur Auswahl gab.
Und in der Zeit hatte Sharkey auch noch gewisse Macken, z. B. eine schon legendär unzuverlässige Implementation der Mastodon Client API, wo es hieß, am besten setzt sich einer hin und schreibt die neu. Wer was Zuverlässiges wollte, setzte damals auf Iceshrimp. Sharkey war für wagemutige Spielkinder, die sich an Hubzilla nicht rantrauten.
Inzwischen ist Calckey tot, Firefish ist tot, Iceshrimp-JS ist im Wartungsmodus (Iceshrimp.NET ist derweil noch meilenweit von "fertig" entfernt), Catodon ist auch schon siech, und das nur für eine Instanz gebaute Hajkey ist schon verwest.
CherryPick hat fast nur Server in den Großräumen Tokyo und Seoul und fühlt sich so auf den ostasiatischen Geschmack ausgelegt an wie vor ein paar Jahren noch Misskey selbst. Vielleicht erinnern sich ein paar noch daran, wie Misskey mal den Charme japanischer Verkaufsautomaten hatte.
Und der ganze noch lebende Rest scheint selbst mit Misskeys Entwicklung nicht mithalten zu können, also im Kern veraltet zu sein.
Derweil ist Sharkey wohl inzwischen ziemlich zuverlässig. So ist es zumindest im Westen zum einzigen noch nennenswerten Forkey avanciert.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Misskey #Forkey #Forkeys #Sharkey #Calckey #Firefish #Iceshrimp #Iceshrimp-JS #Iceshrimp.NET #Catodon #Hajkey #CherryPick -
@Herr TurTur @crossgolf_rebel - kostenlose Kwalitätsposts @tux0r :openbsd: Die Idee hinter Sharkey war mal, in einen einzigen Forkey quasi alles auf einmal reinzuschmeißen bis hin zur Küchenspüle. Das fiel vor allem auf, als es noch mehr lebendige Forkeys zur Auswahl gab.
Und in der Zeit hatte Sharkey auch noch gewisse Macken, z. B. eine schon legendär unzuverlässige Implementation der Mastodon Client API, wo es hieß, am besten setzt sich einer hin und schreibt die neu. Wer was Zuverlässiges wollte, setzte damals auf Iceshrimp. Sharkey war für wagemutige Spielkinder, die sich an Hubzilla nicht rantrauten.
Inzwischen ist Calckey tot, Firefish ist tot, Iceshrimp-JS ist im Wartungsmodus (Iceshrimp.NET ist derweil noch meilenweit von "fertig" entfernt), Catodon ist auch schon siech, und das nur für eine Instanz gebaute Hajkey ist schon verwest.
CherryPick hat fast nur Server in den Großräumen Tokyo und Seoul und fühlt sich so auf den ostasiatischen Geschmack ausgelegt an wie vor ein paar Jahren noch Misskey selbst. Vielleicht erinnern sich ein paar noch daran, wie Misskey mal den Charme japanischer Verkaufsautomaten hatte.
Und der ganze noch lebende Rest scheint selbst mit Misskeys Entwicklung nicht mithalten zu können, also im Kern veraltet zu sein.
Derweil ist Sharkey wohl inzwischen ziemlich zuverlässig. So ist es zumindest im Westen zum einzigen noch nennenswerten Forkey avanciert.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Misskey #Forkey #Forkeys #Sharkey #Calckey #Firefish #Iceshrimp #Iceshrimp-JS #Iceshrimp.NET #Catodon #Hajkey #CherryPick