#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 -
I wonder when we'll see custom domain #WebFinger in the #Fediverse / #ActivityPub ?
For example, I want to use:
* @-live.youronly.one for my #Streams account
* @-sns.youronly.one for my #Firefish account
* @-photos.youronly.one for my #Pixelfed account
* @-mblog.youronly.one for my #Mastodon account
* @-reading.youronly.one for my #BookWyrm accountIdeally, even if I move to a new host/service, I can use the same WebFinger.
#MycelialWeb #MyceliumNetwork #ActivityPub2 #AP #AP2 #Portability #AccountPortability #Nomadic #NomadicIdentity #SNS #SocialWeb #SocialMedia #SocialNetwork
-
👋 Hallo zusammen!
Ich bin Marcel, Baujahr '95, und habe eine Leidenschaft für Fotografie sowie Server-Projekte. Besonders fasziniert mich die Digitalisierung und Optimierung von Prozessen. Auch wenn ich erst mit dem Coden begonnen habe, kriege ich die meisten Dinge zum Laufen. 😄
Nach meiner Registrierung am 1.4.2023 auf @[email protected] habe ich mich jetzt dazu ermutigt, auf Procial umzuziehen. Ich war schon lange ein Fan von Misskey (oder Firefish) und habe endlich eine deutsche Instanz gefunden, die zu mir passt.
Freue mich auf den Austausch mit euch! 🚀
#Fediverse #Misskey #Firefish #ServerLife #Digitalisierung #Fotografie #Docker #TechLife #Coding #OpenSource #Umzug #Photographer #TechCommunity -
Hoping my Firefish community finds this content useful.
:firefish: Deep Dive - Group Chats :firefish:
TL;DR - Firefish Chat provides some much desired safety guardrails compared to Mastodon. There's some needed polish, but the bones are solid.
#Firefish #Fediverse #DirectMessages -
Conversations, Group chats, Private mentions, Direct messages, Channels - all features on fediverse platforms, but are they the same?
I examined the specifics of Firefish Group Chats and explored the differences between it and other fedi platforms with similar functionality.
-
06 - Clips und oder Lesezeichen in Calckey/Firefish
https://tube.tchncs.de/w/j1PHwCJh2nmR36tqkx1RqQ
#Misskey #Calckey #Firefish #Sharkey #IceShrimp #Catodon #Fediverse #FediTip #FediTipp -
CozyFish UI - Gitlab → voici la page Gitlab de mes fichiers custom CSS et thèmes pour Firefish :chick_aww:
Les 2 ont été créés pour aller ensemble mais le custom CSS fonctionne normalement très bien avec les autres thèmes par défaut de Firefish (j'utilise les variables de couleurs dans le css)
Vous pouvez me conseiller, me réprimander parceque j'ai mal fait la page gitlab, contribuer (en rendant le code plus propre ou en ajoutant des fonctionnalités), ou partager si le projet vous plaiiit :boost_requested:
#UiUx #UiDesign #Ui #Ux #CustomCSS #Firefish #UserExperience #CSS #Fediverse #Design #Theme #CustomTheme -
olalala fuat que j'aille dormir, je suis retombé dans le rabbit hole de la customisation
j'ai changé totalement de thème en m'inspirant en partie de kwak.cab, jai redesigné les hashtags, mentions et URL et quelques autres trucs d'accessibilité (vrai thème opaque notamment)
j'essaie d'avoir quelque chose de cohérent, lisible et simple
#customCSS #firefish #iceshrimp -
Custom CSS pour Firefish]
Modifications esthétiques
- Modification des ombres
- Cache la flèche dans les threads (celle pour aller au post du dessus)
- Cache les popups quand on hover un pseudo
- Cache les emojis des pseudos (dans les boosts)
- Cache l'image de fond sur les profils (qd le flou est activé)
- Notification : réglage du padding des icones (boosts, reply, favori, etc) et changement de la couleur des icones de boosts (pour coller avec celle des boosts)
- Changement des icônes de : URL, upload, plugin / extension, copie de lien, boost, reply, post public, non-listé, local et message privé
- Modification des contours des notes
- Modification du label des instances (sur les posts)
- Content warning : typo plus grande, majuscule + couleur et contour pour plus de visibilité
- Boosts : ajout de dégradé et grain pour plus de visibilité, cache la date et style du boost, déplace le texte de boost vers la gauche
- Cache partiellement le post parent d'une réponse
- Cacher les séparateurs de date (dans les feeds)
Modifications de fonctionnalités
- Cache nos propres boosts, réponses et posts dans les feeds
- Cache le bouton boost si une image n'a pas de description
Résolutions de bugs
- Possibilité de redimensionner une zone de texte verticalement
#UiUx #UiDesign #Ui #Ux #CustomCSS #Firefish #UserExperience #CSS #Fediverse #Design -
Toutes mes customs sont sur cette page
Soucis et solutions pour Firefish
Vous y trouverez mes thèmes, codes CSS et les problèmes que je rencontre avec Firefish (expérience, bug, etc)
Si vous avez aussi des soucis ou des solutions, vous pouvez m'envoyer un MP ou répondre à ce post pour que je les ajoute :ablobcat_sip_zoom:
:boost_requested:
#UiUx #UiDesign #Ui #Ux #CustomCSS #Firefish #UserExperience #CSS #Fediverse #Design -
@volkris The belief that each Fediverse project is a different graphical front-end app for the exact same technological back-end is complete non-sense. It sounds like all Fediverse projects run the self-same back-end Web server technology and just put different Web interfaces or mobile apps on top.
#Firefish, formerly known as #CalcKey, is quite a bit different from #Mastodon. And it's still microblogging based on #ActivityPub.
#Friendica is vastly different from Mastodon, also because its base protocol is #DFRN and not ActivityPub. It has an add-on for ActivityPub connectivity.
#Hubzilla and #Streams are even more different from Mastodon. They're based on two versions of #Zot, and they even have an architecture that's extremely different from all other Fediverse projects, even Friendica included, and that wouldn't even be possible with ActivityPub. -
Found 83 new servers and 140 servers died off since 9 hours ago. Check out the Monthly and Daily Stats by software or server or the entire fediverse.
25,956 servers checked. 12,755,199 Total Users, 2,232,478 Monthly Active Users today vs 2,257,849 yesterday for the entire fediverse.
New #fediverse servers found:
nonprofits.masto.host a #mastodon server from France
mastodon.pandapa.ws a #mastodon server from Private
mastodon.hotmilk.space a #mastodon server from United States
ccf.sh a #lemmy server from United States
wf.sofita.noho.st a #writefreely server from Greece
tenfoot.social a #mastodon server from Private
social.fromabyss.com a #mastodon server from United States
fire9.de a #firefish server from Germany
social.learnaddict.academy a #mastodon server from France
relyma.club a #lemmy server from Private
hexbear.net a #lemmy server from France
mastodon.girondi.net a #mastodon server from Sweden
social.aimeee.site a #firefish server from United States
vunzi.com a #lemmy server from Finland
lemmy.enfugue.ai a #lemmy server from United States
emil.nexus a #firefish server from United States
thehanger.social a #mastodon server from Portugal
firefish.boo a #firefish server from United States
lemmy.kirby.run a #lemmy server from United States
gts.romeov.me a #gotosocial server from United States
drykath.red a #mastodon server from United States
akbkuku.org a #mastodon server from United States
msk.mozc-plasma.tech a #misskey server from Private
mk.mii.gay a #misskey server from Germany
soc.dudenas.lt a #firefish server from Lithuania
osplin.monster a #mastodon server from Finland
pl.teleyal.blog a #pleroma server from Germany
mastodon.tsubame-jnr.f5.si a #mastodon server from Japan
bitl.dev a #microblogpub server from Private
fastcompany.social a #mastodon server from Portugal
from-tw.xyz a #baca server from Japan
lemmy.tigor.web.id a #lemmy server from Private
mastodon.lug.ts.it a #mastodon server from France
a.bnuuy.fyi a #gotosocial server from Netherlands
go.warpspeedtv.com a #owncast server from United States
magpie.depht.com a #pleroma server from Netherlands
social.zop.se a #mastodon server from France
mast.yourautisticlife.com a #mastodon server from United States
ohuton.ippainetai.com a #misskey server from Private
ticker.hostdon.ne.jp a #mastodon server from Singapore
faerie.monster a #mastodon server from Portugal
skree.social a #mastodon server from United States
lemmy.co.nz a #lemmy server from Australia
sumanko.com a #mastodon server from Private
pixelfed.techguy.social a #pixelfed server from United States
embracethevoid.net a #mastodon server from United States
vrch.hostdon.ne.jp a #mastodon server from Japan
yetanother.catin.space a #gotosocial server from Private
smilodon.chatslibres.com a #mastodon server from France
misskey.wichi.jp a #misskey server from Private
un.petitp.eu a #mastodon server from Germany
gtsfeditest.zackboe.hm a #gotosocial server from United States
social.lobster.city a #akkoma server from United States
firefish.keks.club a #firefish server from Germany
live.birdcat.cafe a #owncast server from United States
mi.kimama-lab.net a #misskey server from Private
borderland.tokyo a #mastodon server from Japan
tracyverse.social a #mastodon server from Private
fedi.wondernetwork.com a #mastodon server from France
mastodon.accolade.digital a #mastodon server from United States
takanoriskey.toppu.jp a #misskey server from Japan
furuyoni-misskey.morphball.net a #misskey server from Japan
stream.nocci.xyz a #owncast server from Germany
ferry.pm a #mastodon server from United States
owncast.rabidlogic.net a #owncast server from United States
peertube.shadowfr69.eu a #peertube server from France
cld2a.ains-no-misskey.com a #misskey server from Private
linglings.party a #misskey server from South Korea
social.nltech.fr a #mastodon server from France
social.arediss.com a #mastodon server from France
mellowcodelabs.social a #mastodon server from Portugal
social.aleteoryx.me a #mastodon server from United States
essjax.com a #mastodon server from Portugal
mastodon.gregnilsen.com a #mastodon server from France
ssul.one a #pleroma server from Singapore
uni.vuwuv.com a #akkoma server from Japan
eepy.moe a #firefish server from United States
ff.pikopublishing.page a #firefish server from United Kingdom
eei-misskey.com a #misskey server from Private
7a4.pp.ua a #pleroma server from Ukraine
pickey.net a #misskey server from Japan
stormwaltz.net a #mastodon server from Portugal
zlatex.club a #mastodon server from PortugalDead servers: topia.hostdon.ne.jp
hydrocelestis.com
fed.astar.moe
art.librepunk.club
lemmy.giggly.de
social.plant-based.place
skabel.se
git.nuls.dev
moefan-mastodon.net
social.ralsina.me
ma.zcx.cc
fedi.timmorgner.de
mastodon3.stibma.com
mastodon.hutt.social
roguerevan.com
den6262.hostdon.ne.jp
momoirodouhu.mydns.jp
choirofeyes.social
sns.mzyy94.com
mastodon.bleh.au
not.alazy.dev
toot.kingj.net
s.carltheobesecat.online
misskey.styxem.xyz
lemmy.gsp8181.co.uk
mi.torpedo.works
lemmy.recursed.net
mastodon.suzy.is
lemmy.grygon.com
cit-msky.14kw13.com
diggit.xyz
mastodon.k6qw.com
lemmy.davidbuckley.ca
ucn.social
mastodon.smither.org
m.soopy.moe
blog.optional.page
phoebus.cc
pix.campbellwireless.net
misskey.yeonji.net
lemmy.bulwarkob.com
mastodon.fenix-cantina.com
mastodon.firefly.land
fedi.mpthl.ee
indg.club
lemmy.k6qw.com
mast.liaw.me
lemmy.bayern
lemmy.eldarerathis.com
lemmy.coeus.icu
twit.cryolog.in
gay.fesse.pet
sowhois.gay
pilk.social
f.soopy.moe
valentinekindahot.fr
gts.bmgn.rs
ioc.dev
fedi.somedevfox.ru
md.ggtea.org
misskey.fenix-cantina.com
www.omgwtfbbq1337.de
social.logilab.org
mastodan.infra.enoki.tech
lunsford.xyz
mastodon.miao.dev
linkall.uk
mastodon.fi
gaygeeks.nl
videos.mattwilson.org
tube.frischesicht.de
amicale.net
bslounge.com
gnusocial.wmsci.com
m.iamkonstantin.eu
social.kcseb.digital
pixel.jabbxi.de
estrella.misskey.masato.jp
gnubox.org
masto.reiuji.chat
azunyan.info
mastodon.mindlesstux.com
social.styxem.xyz
loli.exposed
sunspot.icu
forsaken.technology
sad.cab
social.freyachat.eu
pleroma.tcweb.org
fedi.fullvoid.de
navinot.com
elephant.ugrash.org
www.librepunk.club
mastodon.campbellwireless.net
pals.chat
f.tkte.ch
sevvie.ltd
toot.cryolog.in
calckey.geppaku.com
mastodon.cmnr.eu
www.melyanna.net
mstdn.vector1.dev
mastodon.pachamamita.de
social.spainco.net
misfitropolis.club
mstdn.tenjuu.net
pleroma.diyarciftci.xyz
p.lu
calckey.nz
brieseland.de
producers.social
mdx.ggtea.org
ap.wolnespoleczenstwo.org
gts.han.do
pleroma.foxarmy.org
axwax.eu
dyfed.saintnet.tech
kuicker.koogle.sk
mastodon.cyprin.eu
a.soopy.moe
hackers.radio
social.hecker.xyz
theden.gay
friendica.donky.social
hub.adrelien.com
coredump.social
thisis.nosocialnet.work
social.circles.fi
social.pigelet.org
500.social
mastotest.jmessage.org
microblog.heavy.rocks
catholicchurch.social
0xa1.social
modak.boo
baudigital.social
gts.kelbie.scot
mk.paritybit.ca
mstdn.ja1ykl.com
cloudfiction.socialHelp others find a home, send them to fediverse.observer
-
Since this is my #personal #friendica server, I'll add #YetAnotherIntroduction post. 😃
I am what I would consider a pretty boring dad to five kiddos, from Lawrence KS. I'm most definitely #introverted, and in a past life I'd much rather be #reading a good book or playing some #JRPG on whatever system is current.
These days, I can generally be found at home, doing the #WorkFromHome thing as an application #SystemAdministrator dealing with lots of #OracleCloud fun (...not).
Downtime has me learning #clojure, #typescript, #angular, #emacs and basically anything shiny that catches my eye.
I've been #keto for the last few years, doing maintenance mode for most of that time, with no plans to change any time soon. It's a lifestyle for me, not a diet.
I've got a handful of accounts on the #fediverse, one of which is my single user #mastodon instance. I'm trying different things out to see which I prefer most.
@swrogers -- My First Friendica Account
@swrogers -- My Main Friendica Account, and main fedi account
@swrogers -- My personal mastodon instance
@swrogers -- My personal #FireFish instance
@[email protected] -- Over on the official Fire Fish instance
@[email protected] -- Over on Infosec Exchange
@swrogers -- My main image uploading section, on #pixelfed socialI'm sure I've got more fediverse account out there, somewhere...it's not quite a #GottaGetThemAll deal, but it sure does seem like it!
-
One of the most confusing aspects of the #Fediverse for newcomers is how to follow someone. Especially if the person is not on your own server -- it is not immediately obvious.
Here are three simple ways to follow people:
On #Mastodon: https://thefedi.wiki/mastodon/user/following
On #Firefish: https://thefedi.wiki/firefish/user/following
#thefediwiki #userguide -
Imagine being able to curate your own lists of posts, and the option to share that list with anyone on the internet.
#Firefish has the answer, in Clips: https://thefedi.wiki/firefish/user/clips
#theFediWidi #UserGuide -
#Introduction / #NeuHier / #Pinned / #FireFish
Griaß Eich! Mein Name ist Markus und ich komm aus #Wien, #Österreich.
Dieser 🌟private Account🌟 ist nur für Freunde und Familie gedacht ist, die ich persönlich kenne. Also bitte nicht bös sein, wenn ich Deine Follow-Anfrage nicht annehme 🥺
Neben privatem Shitposting und Herumgesuder treib ich mich auch in den Bereichen #IT #Linux #InformationSecurity #Gaming usw. herum.
Meine öffentlichen #Fotografie Accounts gibt es hier
⤵️⤵️⤵️⤵️⤵️
Silver, Light, and Skin 🔞
#Boudoir / #Aktfotografie / #NudePhotography / #SilverLightAndSkin
@[email protected]
WET-Photo 🎸
#KonzertFotografie / #ConcertPhotography / #wetphoto
@[email protected]
@[email protected]
Alter #Mastodon Account (hierher migriert)
@[email protected] -
Nachdem ich ein paar Jahre vorwiegend #Mastodon nutzte, gefällt mir #Firefish immer besser.
Meine #Follower könnte ich zu dem neuen #Account umziehen...aaber Followerzahlen sind hier ja nicht >das< #Kriterium sondern eher die #Qualität des Mitteilens und Austauschens, auch deshalb meine Bitte:
Wer weiterhin mit mir und dem was ich so mache und denke in #Verbindung bleiben möchte, folge mir gern hier:
Würde mich freuen, Euch dort zu sehen ...
-
@[email protected] Did I say that I like #self-hosting? Let me count:
- Alderaan - RPi4 - GravCMS & #Postmarks
- Jakku - RPi4 - #Mastodon
- Corellia - RPi4 - #Pixelfed & #Firefish
- Coruscant - RPi3 - #MagicMirror
- Dantooine - RPi2 - Python bots farm
- Dagobah - RPi3 - Local DNS & ReverseProxy
- Tatooine - RPi4 - #Nextcloud
- Butxaca - RPi1 - Retired Torrent box
- GameBoy - RPiZero - #RetroPie
🥰 -
#Frage an deutschsprachige #FireFish Nutzer:
DieBeitrag teilenSchaltfläche verdeckt teilweise das Eingabefeld bei neuen #Posts mit mobilen Geräten.
@[email protected] schlägt vor, den Text zu kürzen.
Was meint Ihr wenn das geändert würde aufSenden?
Oder habt ihr einen besseren Vorschlag?
Würde nächste Woche versuchen die Übersetzung anzupassen.
#Useability #Interface #Design -
It would be nice, #FireFish where able to store the last reading position of all the timelines and starting at this position after next login or reopen the apps.
Maybe, there is such a #setting, that I'm not found yet?
#Timeline #Start #lastReading #Useability #Kaiteki
@[email protected] @[email protected] -
These are essentially #baitAndSwitch attacks.
A few days ago we brainstormed how #I2P might be able to democratise #contentDelivery in #Fediverse, in ways that protect users.
See our #GlutPlug post.
We hope that #Mastodon, #Akkoma, #FireFish and #Epicyon are able to seriously consider how they might do this. App developers for #Tusky and #Fedilab also.
-
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 -
@「 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 😭.
-
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. :-)
