#calckey — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #calckey, aggregated by home.social.
-
@[email protected] dann werde ich dein Rabithole mal vertiefen.... 😁
Hallo und willkommen im #Fediverse :fediverse:
Dem Netzwerk wo so viel mehr möglich ist, als vielen überhaupt bewusst ist
https://fediversum.info/
Grüße mit #Calckey 👋 -
@[email protected] hallo und schön das ihr im #Fediverse seid.
Auch wenn ihr mich gerade nicht gegrüßt habt...😥
Ich winke mal traurig mit meinem #Calckey rüber -
@[email protected] @[email protected]
der Umstieg weg von Mastodon zu einem passenderenden Dienst im Fediverse 👍
Was ich mir nach über 10 Jahren von Journalisten wünsche, das sie das Fediverse endlich als Netzwerk akzepzieren und auch, das Mastodon nur eine von sehr vielen Softwares ist, um daran teilzunehmen.
https://fediversum.info/
geschrieben mit #Calckey, weil die Fesseln von Mastodon zu heftig sind
EDIT
wie übrigens die anderen 50% des Fediverse, die auch kein Maastodon verwenden 😉 -
@[email protected] @[email protected]
im Abo meiner Peertube Instanz und mit #Calckey -
@[email protected] für das Fediverse kannst du erst mal diesen link weiterreichen.
https://fediversum.info/
Man muss im Fediverse kein Mastodon verwenden.
Vielmehr ist es wichtig zu wissen, was der Dienst können soll und danach gehen, als alles mit Mastodon zu erschklagen, für das es nicht gedacht ist.
Grüße von einem Fediverse Nerd, der mit #Calckey unterwegs ist 😉 -
@[email protected] nein, tut es nicht.
Mit der Begründung kannst du jedes Fahrzeug auch als Trabant bezeichnen, egal ob es 4 Leute befördert oder 60. Ob es 700 kg Zulagung hat oder 60t
Mastodon ist nicht das Fediverse, wie übrigens 50% des Fediverse kein Mastodon benutzen.
Und nochmal, Mastodon ist kein #Calckey
Kannst du 7.500 Zeichen Schreiben?
Hast du eine integrierte Drive?
Kannst du Bildergalerien erstellen?
Kannst du Lesezeichen in Ordner sortiert ablegen?
Hast du Antennen, mit denen du Beiträge anhand eines Wortfilters in deine Timeline holen kannst (nicht Hashtags, die haben wir noch zusätzlich)?
und sehr viel mehr...
@[email protected] @[email protected] -
@[email protected] sagen wir es mal differenzierter 😉
Du und @[email protected] seid "auf" Mastodon, wenn man nur euch allein betrachtet. Da ihr euren Account auf einer Mastodoninstanz habt.
Wenn ihr das aber aus Sicht des gesamten Netzwerkes betrachtet, seid ihr mit Mastodon, im Fediverse aktiv.
Schau mal hier rein: https://fediversum.info/
Das gibt dir einen Enblick, mit was du so an Diensten sprichst im Fediverse
Mit der Auswahl der Software, entscheidet ihr nur für euch, wie das Netzwerk "aussieht", welche Funktionen ihr habt und was ihr machen könnt.
Eben aber nur für euch, nicht für das Netzwerk.
Ich könnte euch z.B. 14 Bilder schicken, von denen NMastodon leider 10 wegwirft und damit den Inhalt meiner Nachricht verfälscht.
Das sagt euch leider keiner.
Wer weiß, was euch damit schon alles vorenthalten wurde, ohne das ihr es mitbekommen habt.
anbei mal zwei Bilder der Instanzwolke. Eines Features unserer Software, die optisch darstellt, mit welchem Dienst verbundenen Instanzen betrieben werden
Grüße mit #Calckey 👋 -
@[email protected] bitte, sehr gerne doch.
Ich hätte noch weitere, falls Bedarf besteht.
Ich bin mit #Calckey im Fediverse unterwegs, das ist ähnlich wie #Sharkey. Weils nicht so einschränkt 😉
https://tube.tchncs.de/w/w8bVvpfaZLsSbQQkPUPjy9 -
@[email protected] Morjen und willkommen im #Fediverse 👋
Und, schon #Peertube entdeckt 😉
Grüße mit #Calckey, einem anderen Textdienst im Fediverse -
@[email protected] nein.
das kannst du von deiner Instanz aus machen, wo du zu Hause bist.
Das macht keinen Unterschied, ob du Friendica, Masto oder Sharkey nutzt.
Den Kanalnamen nach FediSchema in die Suche hauen und dann abonnieren 👍
Für deinen Dienst ist das Konto nur auf einer anderen Instanz, wie ich hier z.B. mit #Calckey
und, wir sehen uns doch auch und unterhalten uns 😉
Das ist der Sinn des Fediverse, das man sich Diensteübergreifend im selben Netzwerk befindet und austauschen kann
@[email protected] @[email protected] -
@[email protected] wäre schön, falsches "Wissen" ist so viel schlechter aus den köpfen zu bekommen.
Und es gibt schon genügend falsche Infos
Danke fürs ausbessern 👍
Grüße mit #Calckey -
@[email protected] Hallo und willkommen im #Fediverse :fediverse:
Dem Netzwerk wo so viel mehr möglich ist, als vielen überhaupt bewusst ist
https://fediversum.info/
Grüße mit #Calckey (nicht Mastodon 😉 ) -
@[email protected] Hallo und willkommen im Fediverse.
Grüße mit #Calckey 👋 -
@[email protected] falls es Fragen gibt oder so was, einfach melden.
https://fediversum.info/ gibt dir einen kleinen Einblick, was hier alles unterwegs ist. Aber wirklich nur einen kleinen.
Grüße mit #Calckey -
@[email protected] Hallo und willkommen im #Fediverse :fediverse:
Grüße mit #Calckey -
@[email protected] Hallo und willkommen im #Fediverse 👋
Dieses netzwerk ist noch um etliches größer und Mastodon nur ein Teil davon https://fediversum.info/
Grüße mit einem anderne Zugang, Namens #Calckey 👋 -
@[email protected] Hallo und willkommen im #Fediverse :fediverse: von den nicht begrüßten mit anderen Zugangssoftware wie unserer - #Calckey 🥴
Dem Netzwerk wo so viel mehr möglich ist, als vielen überhaupt bewusst ist
https://fediversum.info/ -
@[email protected] Use a different service in the Fediverse.
For example, the Misskey family, which includes IceShrimp, Misskey, Foundkey, Sharkey and so on; there, you can organise your bookmarks into folders
You can create as many of these folders as you need.
The same applies to the built-in cloud: files can be sorted into folders and are always ready for reuse.
#Fediverse #Sharkey #Calckey #Bookmark -
@[email protected] Hallo und willkommen im #Fediverse :fediverse:
Dem Netzwerk wo so viel mehr möglich ist, als vielen überhaupt bewusst ist
https://fediversum.info/
Und, das hier ist mehr als nur mastodon, Grüße von einem nichtbegrüßtem der #Calckey benutzt 😥 -
@[email protected] Hallo und willkommen im #Fediverse :fediverse:
Dem Netzwerk wo so viel mehr möglich ist, als vielen überhaupt bewusst ist
https://fediversum.info/
Also, das hier ist mehr als nur Mastodon 😉
Grüße mit #Calckey -
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 -
@[email protected] reminds me when I joined a #Calckey instance for the first time three years ago. :firefish_info:
-
@[email protected] @[email protected] @[email protected]
Und wir bekommen jedes Mal Prügel, wenn wir nur drauf hinweisen, das es mehr als nur Mastodon in diesem Netzwerk gibt 😥
Hat Mastodon schon toll gemacht, alle Hinweise auf andere Dienste aus ihrem Dienst rauszuhalten.....
Geschrieben mit #Calckey -
Hallo @[email protected] und willkommen im #Fediverse
Mastodon ist nur einer von vielen Zugängen in dieses Netzwerk
https://fediversum.info/
Und wofür es die Menschen hier nutzen, ist ganz unterschiedlich. Eben auch abhängig davon, welche Software man dafür verwendet.
Mastodon wie auch ein dutzend anderer Dienste bedienen die Menschen, die eher Kurznachrichten schreiben wollen.
Ebenso kann man das mit Pixelfed machen, das sich aber vorrangig auf Bilder spezialisiert, und es soll ähnlich dem alten Insta sein.
Dir wird in deiner Timeline alles möglech präsentiert werden können, seine es Videos, Termine, Buchbesprechungen, DIY Themen usw.
Was du mit all dem anfängst, ist dir überlassen 😉
Berieseln lassen oder einfach mitmachen
Grüße mit #Calckey, einem anderne Fediverse Dienst -
@[email protected] Hallo und willkommen im Fediverse
:fediverse:
Falls du leider Facebookartig unterwegs sein willst, auch dafüpr haben wir im Fediverse den passendne Zugang.
Schau dir mal bitte #Friendica an.
Das Fediverse ist sehr viel mehr, als der Zugang über Mastodon 😉
https://fediversum.info/
Grüße mit #Calckey 👋 -
@[email protected] Hallo und willkommen im #Fediverse :fediverse:
Dem Netzwerk wo so viel mehr möglich ist, als vielen überhaupt bewusst ist
https://fediversum.info/
Und Mastodon, ist nur eure Zugangssoftware in dieses Netzwerk, nicht die aller anderen 😉
Grüße mit #Calckey -
@[email protected] Morjen und willkommen im #Fediverse
Das hier ist das Fediverse und nur die Leute zu begrüßen, die deine Software benutzen...
Ähm, leicht unhöflich.
Aber, woher solltet ihr das auch wissen.....
Grüße mit dem Fediverse Zugang #Calckey -
@[email protected] du bist da in was weit größerem reingetappt 😉
Willkommen im #Fediverse
Grüße von einer #Calckey Instanz 👋 -
@[email protected] Hallo und willkommen im #Fediverse
egal welche Software du als Zugang benutzt 😉
Grüße mit #Calckey 👋 -
@crossgolf_rebel - kostenlose Kwalitätsposts @「 Jürgen 」:fedi_mastodon: So ist das. Es zeigt aber auch sehr deutlich den Unterschied zwischen dem Fediverse in der westlichen Welt und dem Fediverse in Ostasien.
So, wie bei uns im Westen das Fediverse im wesentlichen Mastodon ist, ist in Ostasien das Fediverse im wesentlichen *key. Die kennen auch Mastodon, aber das spielt da nur eine untergeordnete Rolle. Etwas, was dem Platzhirsch Misskey das Wasser nicht reichen kann, hat da einfach keine Chance.
In Ostasien gibt's im wesentlichen zwei Gründe für Forkeys. Zum einen ist Misskey eigentlich verbuggt bis zum Gehtnichtmehr. Die Bugs sind bekannt. Die Bugs sind in Issues auf GitHub dokumentiert. Aber es passiert einfach nix. Man könnte Pull Requests einreichen, mit denen ein Bug sofort aus der Welt geschafft werden könnte. Die werden aber einfach nicht gemerget.
Was machst du also? Du machst aus deinem Entwicklungsfork, mit dem du deinen Patch gebaut hast, ein eigenes Projekt mit eigenem Namen und haust das als direkte Konkurrenz zu Misskey raus. Also als Soft-Fork, wo du ab und an mal Commits von Misskey rüberholst und bei dir einpflegst. Oder wenn du an Misskeys Weiterentwicklung eh nicht glaubst, gleich als Hard-Fork, wo du letztlich die ganze Weiterentwicklung selbst machst.
Zum anderen gibt's immer wieder Ideen, wie die Usability von *key verbessert oder in andere Richtungen getrieben werden könnte. Das kann man natürlich nicht unbedingt mit Misskey selbst machen. Also macht man dafür eben einen Fork.
Die Featuritis westlicher Art in japanischen und südkoreanischen Forkeys kam doch eigentlich erst richtig auf, als man in Ostasien bemerkte, daß zum einen Misskey im Westen populärer wurde (immer mehr englische Notizen auf Misskey-Instanzen, immer mehr englische Issues auf GitHub, wo früher mal alle japanisch waren, etc.) und zum anderen Misskey im Westen geforkt wurde (ein Blick in die Liste der Forks des Misskey-Repository genügt).
Im Westen sind die Gründe für Forkeys etwas anders gelagert. Erstens wollten vermutlich besonders die ganz frühen westlichen Forkeys die Ästhetik verändern. Ich meine, vor ein paar Jahren hatte Misskey noch diese typische knallbunte Ästhetik von Shibuya und Akihabara und Manga und japanischen Verkaufsautomaten. Die Amis und Europäer wollten eher ein sachlicheres Aussehen haben, das Maid-Café in eine Studentenkneipe umgestalten, ungewohnte Melonenbrause durch gewohnte Cola ersetzen.
Zweitens, wo man schon mal dabei war: Features, Features, Features. Man war beeindruckt davon, was Misskey konnte, was das eigentlich als Standard und Goldstandard geltende Mastodon nicht konnte. Aber da ging noch was, da war noch Luft nach oben. Und weil verschiedene Entwickler verschiedene Vorstellungen hatten, was jetzt ein Forkey an Features haben soll, standen wohl einige Zeit vor allem FoundKey und Calckey in Konkurrenz zueinander.
Zu den Sachen, auf die sie sich einigen konnten, war, daß ein hartgecodetes Zeichenlimit von 3000 genauso Käse ist wie ein hartgecodetes Zeichenlimit von 500 auf Mastodon. Deswegen hat doch so ziemlich jeder Mastodon-Fork, der was auf sich hält, ein konfigurierbares Zeichenlimit. Und jeder Forkey, der was auf sich hält, auch.
Drittens: Bugfixes. Allerdings nicht nur von Misskey-Bugs, die von den Forkeys geerbt wurden, sondern ebenso von Bugs, die mit der Featuritis Einzug gehalten haben. Deswegen war Sharkey ("Hauptsache, erstmal Features") vs. Iceshrimp ("Hauptsache, erstmal Stabilität") das neue FoundKey vs. Calckey.
Viertens, das habe ich noch gar nicht erwähnt: ein nicht cishet-normatives Fediverse. Sogar eine Nische im Fediverse ganz ausdrücklich für Transpersonen, deren serverseitiger Unterbau selbst von Transpersonen entwickelt und gepflegt wird. Warum? Weil der Admin von misskey.io, der größten Misskey-Instanz überhaupt, durch das Shadowbanning entsprechender Begriffe mal eine gewisse Homophobie, Transphobie und generelle Queerphobie impliziert hat. Wohlgemerkt, der Admin von misskey.io, nicht irgendeiner der Entwickler von Misskey. Aber damit stand Misskey als Ganzes und wohl auch die ganze japanisch-südkoreanische Forkey-Szene doof da.
Hajkey hatte ich ja schon erwähnt. Von einer Transfrau entwickelter Forkey für eine von einer Transfrau gegründete Instanz. Noch offensichtlicher geht's fast schon gar nicht mehr: Hajkey war inspiriert von und benannt nach dem IKEA Blåhaj, dem plüschigen Transgender-Wappentier. Und auch Sharkey wurde von trans Instanzadmins angeschoben, um eine Pro-2SLGBTQQIA+-Alternative zu Misskey mit besonderem Fokus auf Transpersonen zu haben, die Misskey selbst in den Schatten stellt. Ich meine, warum ist das Maskottchen von Sharkey ein Anime-Mädchen in einem blauen Haianzug?
Sharkeys Ziel dürfte auch gewesen sein, einen Fediverse-Alleskönner zu bauen. Egal, was man im Fediverse machen will, egal, was man für Features braucht, sie sollten auf jeden Fall auch erhältlich sein von trans Entwicklern und nicht nur von Cishet-Männern. Wohl auch deshalb wurde Sharkey aufgebläht zu einem Featuremonster, das im Rahmen der Möglichkeiten von *key Friendica und sogar Hubzilla Konkurrenz zu machen versucht. Transpersonen sollten anstelle dieser beiden Anwendungen, die praktisch komplett von Cishet-Männern entwickelt und gepflegt werden, mit möglichst wenig Einschränkungen auch Sharkey nutzen können.
Das Problem im Westen ist nur, Entwickler zu finden und zu halten. Wie gesagt, in Fernost dominiert *key alles. Hier im Westen ist *key eine Nische. Hier ist alles Nische, was nicht Mastodon ist. Ein erheblicher Teil der Fediverse-Nutzer kennt nur Mastodon, glaubt gar, das Fediverse sei nur Mastodon. Ein paar mehr glauben, das Fediverse sei nicht viel mehr als Mastodon, PeerTube und Pixelfed. Geschätzt mindestens die Hälfte aller Fediverse-Nutzer glaubt, Mastodon sei die einzige auf Microblogging ausgelegte Anwendung im Fediverse.
Dazu kommt die Konkurrenz. Neben Mastodon gibt's ja nicht nur *key. Auch Pleroma und Akkoma wollen ein Stück vom Kuchen abhaben, und die dürften mindestens so bekannt sein wie *key. Daneben gibt's noch sehr viele weitere Projekte in sehr vielen weiteren Größenordnungen von snac2 über GoToSocial bis Mitra, die alle dasselbe wollen wie Mastodon und die *keys.
Entsprechend verteilen sich dann auch die fähigen Entwickler. Die meisten forken entweder Mastodon, um daraus etwas zu bauen mit Features, die "das Fediverse" dringend haben müßte, die aber schon Misskey längst hat. Nur haben sie von Misskey nie gehört und auch nicht von Pleroma oder Friendica oder sonstwas. Oder sie fangen ihre eigene Microblogging-Anwendung an mit denselben Beweggründen und demselben Basiswissen bzw. Mangel daran. Ich schätze, von denen wissen auch einige bis heute nicht, daß es Misskey und Pleroma gibt. Oder sie bauen irgendwas ganz anderes direkt gegen Mastodon.
Unter denen, die Misskey kennen, gibt's nicht viele fähige Entwickler. Das sieht man ja auch an den Smartphone-Apps: Reine Mastodon-Apps kommen gefühlt im Monatstakt. Aber es hat eine Ewigkeit gedauert, bis es auch nur eine einzige App gab, die direkt auf Misskey und die Forkeys ausgelegt war, geschweige denn stabil und nicht nur auf Japanisch und vielleicht noch Hangul verfügbar. Das heißt auch: Die paar wenigen fähigen Entwickler, die Misskey kennen, sind entweder schon irgendwo eingebunden oder gebrannte Kinder (oder Ostasiaten, die kein Englisch können, was die Kommunikation ziemlich erschweren würde).
Wer also Mitstreiter fürs eigene Projekt sucht, vor allem so vertrauenswürdige, daß die dann auch committen dürfen, wird keine finden. Gleichzeitig ist es aber absoluter Wahnsinn, einen Soft-Fork von Misskey alleine ohne jegliche Hilfe zu pflegen und weiterzuentwickeln, insbesondere, wenn der an Fahrt aufnimmt und von mehr und mehr Leuten genutzt wird. Genau daran ist Firefish letzten Endes eingegangen.
Im Grunde braucht es heutzutage gar nicht mehr diesen Wust an Forkeys, jedenfalls nicht im Westen. Das heißt, im Grunde könnte CherryPick rein technisch die meisten Anforderungen erschlagen, und noch dazu soll es bombenstabil sein. Nur hat man dann etwas, das so aussieht, wie Matcha oder Melonenbrause schmeckt, und wo die meisten Commits, die nicht von Misskey kommen, auf Japanisch oder Hangul beschrieben sind.
#Long #LongPost #CWLong #CWLongPost #LangerPost #CWLangerPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Misskey #Forkey #Forkeys #Calckey #Firefish #Iceshrimp #Sharkey #CherryPick #FoundKey #Hajkey -
@crossgolf_rebel - kostenlose Kwalitätsposts @「 Jürgen 」:fedi_mastodon: So ist das. Es zeigt aber auch sehr deutlich den Unterschied zwischen dem Fediverse in der westlichen Welt und dem Fediverse in Ostasien.
So, wie bei uns im Westen das Fediverse im wesentlichen Mastodon ist, ist in Ostasien das Fediverse im wesentlichen *key. Die kennen auch Mastodon, aber das spielt da nur eine untergeordnete Rolle. Etwas, was dem Platzhirsch Misskey das Wasser nicht reichen kann, hat da einfach keine Chance.
In Ostasien gibt's im wesentlichen zwei Gründe für Forkeys. Zum einen ist Misskey eigentlich verbuggt bis zum Gehtnichtmehr. Die Bugs sind bekannt. Die Bugs sind in Issues auf GitHub dokumentiert. Aber es passiert einfach nix. Man könnte Pull Requests einreichen, mit denen ein Bug sofort aus der Welt geschafft werden könnte. Die werden aber einfach nicht gemerget.
Was machst du also? Du machst aus deinem Entwicklungsfork, mit dem du deinen Patch gebaut hast, ein eigenes Projekt mit eigenem Namen und haust das als direkte Konkurrenz zu Misskey raus. Also als Soft-Fork, wo du ab und an mal Commits von Misskey rüberholst und bei dir einpflegst. Oder wenn du an Misskeys Weiterentwicklung eh nicht glaubst, gleich als Hard-Fork, wo du letztlich die ganze Weiterentwicklung selbst machst.
Zum anderen gibt's immer wieder Ideen, wie die Usability von *key verbessert oder in andere Richtungen getrieben werden könnte. Das kann man natürlich nicht unbedingt mit Misskey selbst machen. Also macht man dafür eben einen Fork.
Die Featuritis westlicher Art in japanischen und südkoreanischen Forkeys kam doch eigentlich erst richtig auf, als man in Ostasien bemerkte, daß zum einen Misskey im Westen populärer wurde (immer mehr englische Notizen auf Misskey-Instanzen, immer mehr englische Issues auf GitHub, wo früher mal alle japanisch waren, etc.) und zum anderen Misskey im Westen geforkt wurde (ein Blick in die Liste der Forks des Misskey-Repository genügt).
Im Westen sind die Gründe für Forkeys etwas anders gelagert. Erstens wollten vermutlich besonders die ganz frühen westlichen Forkeys die Ästhetik verändern. Ich meine, vor ein paar Jahren hatte Misskey noch diese typische knallbunte Ästhetik von Shibuya und Akihabara und Manga und japanischen Verkaufsautomaten. Die Amis und Europäer wollten eher ein sachlicheres Aussehen haben, das Maid-Café in eine Studentenkneipe umgestalten, ungewohnte Melonenbrause durch gewohnte Cola ersetzen.
Zweitens, wo man schon mal dabei war: Features, Features, Features. Man war beeindruckt davon, was Misskey konnte, was das eigentlich als Standard und Goldstandard geltende Mastodon nicht konnte. Aber da ging noch was, da war noch Luft nach oben. Und weil verschiedene Entwickler verschiedene Vorstellungen hatten, was jetzt ein Forkey an Features haben soll, standen wohl einige Zeit vor allem FoundKey und Calckey in Konkurrenz zueinander.
Zu den Sachen, auf die sie sich einigen konnten, war, daß ein hartgecodetes Zeichenlimit von 3000 genauso Käse ist wie ein hartgecodetes Zeichenlimit von 500 auf Mastodon. Deswegen hat doch so ziemlich jeder Mastodon-Fork, der was auf sich hält, ein konfigurierbares Zeichenlimit. Und jeder Forkey, der was auf sich hält, auch.
Drittens: Bugfixes. Allerdings nicht nur von Misskey-Bugs, die von den Forkeys geerbt wurden, sondern ebenso von Bugs, die mit der Featuritis Einzug gehalten haben. Deswegen war Sharkey ("Hauptsache, erstmal Features") vs. Iceshrimp ("Hauptsache, erstmal Stabilität") das neue FoundKey vs. Calckey.
Viertens, das habe ich noch gar nicht erwähnt: ein nicht cishet-normatives Fediverse. Sogar eine Nische im Fediverse ganz ausdrücklich für Transpersonen, deren serverseitiger Unterbau selbst von Transpersonen entwickelt und gepflegt wird. Warum? Weil der Admin von misskey.io, der größten Misskey-Instanz überhaupt, durch das Shadowbanning entsprechender Begriffe mal eine gewisse Homophobie, Transphobie und generelle Queerphobie impliziert hat. Wohlgemerkt, der Admin von misskey.io, nicht irgendeiner der Entwickler von Misskey. Aber damit stand Misskey als Ganzes und wohl auch die ganze japanisch-südkoreanische Forkey-Szene doof da.
Hajkey hatte ich ja schon erwähnt. Von einer Transfrau entwickelter Forkey für eine von einer Transfrau gegründete Instanz. Noch offensichtlicher geht's fast schon gar nicht mehr: Hajkey war inspiriert von und benannt nach dem IKEA Blåhaj, dem plüschigen Transgender-Wappentier. Und auch Sharkey wurde von trans Instanzadmins angeschoben, um eine Pro-2SLGBTQQIA+-Alternative zu Misskey mit besonderem Fokus auf Transpersonen zu haben, die Misskey selbst in den Schatten stellt. Ich meine, warum ist das Maskottchen von Sharkey ein Anime-Mädchen in einem blauen Haianzug?
Sharkeys Ziel dürfte auch gewesen sein, einen Fediverse-Alleskönner zu bauen. Egal, was man im Fediverse machen will, egal, was man für Features braucht, sie sollten auf jeden Fall auch erhältlich sein von trans Entwicklern und nicht nur von Cishet-Männern. Wohl auch deshalb wurde Sharkey aufgebläht zu einem Featuremonster, das im Rahmen der Möglichkeiten von *key Friendica und sogar Hubzilla Konkurrenz zu machen versucht. Transpersonen sollten anstelle dieser beiden Anwendungen, die praktisch komplett von Cishet-Männern entwickelt und gepflegt werden, mit möglichst wenig Einschränkungen auch Sharkey nutzen können.
Das Problem im Westen ist nur, Entwickler zu finden und zu halten. Wie gesagt, in Fernost dominiert *key alles. Hier im Westen ist *key eine Nische. Hier ist alles Nische, was nicht Mastodon ist. Ein erheblicher Teil der Fediverse-Nutzer kennt nur Mastodon, glaubt gar, das Fediverse sei nur Mastodon. Ein paar mehr glauben, das Fediverse sei nicht viel mehr als Mastodon, PeerTube und Pixelfed. Geschätzt mindestens die Hälfte aller Fediverse-Nutzer glaubt, Mastodon sei die einzige auf Microblogging ausgelegte Anwendung im Fediverse.
Dazu kommt die Konkurrenz. Neben Mastodon gibt's ja nicht nur *key. Auch Pleroma und Akkoma wollen ein Stück vom Kuchen abhaben, und die dürften mindestens so bekannt sein wie *key. Daneben gibt's noch sehr viele weitere Projekte in sehr vielen weiteren Größenordnungen von snac2 über GoToSocial bis Mitra, die alle dasselbe wollen wie Mastodon und die *keys.
Entsprechend verteilen sich dann auch die fähigen Entwickler. Die meisten forken entweder Mastodon, um daraus etwas zu bauen mit Features, die "das Fediverse" dringend haben müßte, die aber schon Misskey längst hat. Nur haben sie von Misskey nie gehört und auch nicht von Pleroma oder Friendica oder sonstwas. Oder sie fangen ihre eigene Microblogging-Anwendung an mit denselben Beweggründen und demselben Basiswissen bzw. Mangel daran. Ich schätze, von denen wissen auch einige bis heute nicht, daß es Misskey und Pleroma gibt. Oder sie bauen irgendwas ganz anderes direkt gegen Mastodon.
Unter denen, die Misskey kennen, gibt's nicht viele fähige Entwickler. Das sieht man ja auch an den Smartphone-Apps: Reine Mastodon-Apps kommen gefühlt im Monatstakt. Aber es hat eine Ewigkeit gedauert, bis es auch nur eine einzige App gab, die direkt auf Misskey und die Forkeys ausgelegt war, geschweige denn stabil und nicht nur auf Japanisch und vielleicht noch Hangul verfügbar. Das heißt auch: Die paar wenigen fähigen Entwickler, die Misskey kennen, sind entweder schon irgendwo eingebunden oder gebrannte Kinder (oder Ostasiaten, die kein Englisch können, was die Kommunikation ziemlich erschweren würde).
Wer also Mitstreiter fürs eigene Projekt sucht, vor allem so vertrauenswürdige, daß die dann auch committen dürfen, wird keine finden. Gleichzeitig ist es aber absoluter Wahnsinn, einen Soft-Fork von Misskey alleine ohne jegliche Hilfe zu pflegen und weiterzuentwickeln, insbesondere, wenn der an Fahrt aufnimmt und von mehr und mehr Leuten genutzt wird. Genau daran ist Firefish letzten Endes eingegangen.
Im Grunde braucht es heutzutage gar nicht mehr diesen Wust an Forkeys, jedenfalls nicht im Westen. Das heißt, im Grunde könnte CherryPick rein technisch die meisten Anforderungen erschlagen, und noch dazu soll es bombenstabil sein. Nur hat man dann etwas, das so aussieht, wie Matcha oder Melonenbrause schmeckt, und wo die meisten Commits, die nicht von Misskey kommen, auf Japanisch oder Hangul beschrieben sind.
#Long #LongPost #CWLong #CWLongPost #LangerPost #CWLangerPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Misskey #Forkey #Forkeys #Calckey #Firefish #Iceshrimp #Sharkey #CherryPick #FoundKey #Hajkey -
@crossgolf_rebel - kostenlose Kwalitätsposts @「 Jürgen 」:fedi_mastodon: So ist das. Es zeigt aber auch sehr deutlich den Unterschied zwischen dem Fediverse in der westlichen Welt und dem Fediverse in Ostasien.
So, wie bei uns im Westen das Fediverse im wesentlichen Mastodon ist, ist in Ostasien das Fediverse im wesentlichen *key. Die kennen auch Mastodon, aber das spielt da nur eine untergeordnete Rolle. Etwas, was dem Platzhirsch Misskey das Wasser nicht reichen kann, hat da einfach keine Chance.
In Ostasien gibt's im wesentlichen zwei Gründe für Forkeys. Zum einen ist Misskey eigentlich verbuggt bis zum Gehtnichtmehr. Die Bugs sind bekannt. Die Bugs sind in Issues auf GitHub dokumentiert. Aber es passiert einfach nix. Man könnte Pull Requests einreichen, mit denen ein Bug sofort aus der Welt geschafft werden könnte. Die werden aber einfach nicht gemerget.
Was machst du also? Du machst aus deinem Entwicklungsfork, mit dem du deinen Patch gebaut hast, ein eigenes Projekt mit eigenem Namen und haust das als direkte Konkurrenz zu Misskey raus. Also als Soft-Fork, wo du ab und an mal Commits von Misskey rüberholst und bei dir einpflegst. Oder wenn du an Misskeys Weiterentwicklung eh nicht glaubst, gleich als Hard-Fork, wo du letztlich die ganze Weiterentwicklung selbst machst.
Zum anderen gibt's immer wieder Ideen, wie die Usability von *key verbessert oder in andere Richtungen getrieben werden könnte. Das kann man natürlich nicht unbedingt mit Misskey selbst machen. Also macht man dafür eben einen Fork.
Die Featuritis westlicher Art in japanischen und südkoreanischen Forkeys kam doch eigentlich erst richtig auf, als man in Ostasien bemerkte, daß zum einen Misskey im Westen populärer wurde (immer mehr englische Notizen auf Misskey-Instanzen, immer mehr englische Issues auf GitHub, wo früher mal alle japanisch waren, etc.) und zum anderen Misskey im Westen geforkt wurde (ein Blick in die Liste der Forks des Misskey-Repository genügt).
Im Westen sind die Gründe für Forkeys etwas anders gelagert. Erstens wollten vermutlich besonders die ganz frühen westlichen Forkeys die Ästhetik verändern. Ich meine, vor ein paar Jahren hatte Misskey noch diese typische knallbunte Ästhetik von Shibuya und Akihabara und Manga und japanischen Verkaufsautomaten. Die Amis und Europäer wollten eher ein sachlicheres Aussehen haben, das Maid-Café in eine Studentenkneipe umgestalten, ungewohnte Melonenbrause durch gewohnte Cola ersetzen.
Zweitens, wo man schon mal dabei war: Features, Features, Features. Man war beeindruckt davon, was Misskey konnte, was das eigentlich als Standard und Goldstandard geltende Mastodon nicht konnte. Aber da ging noch was, da war noch Luft nach oben. Und weil verschiedene Entwickler verschiedene Vorstellungen hatten, was jetzt ein Forkey an Features haben soll, standen wohl einige Zeit vor allem FoundKey und Calckey in Konkurrenz zueinander.
Zu den Sachen, auf die sie sich einigen konnten, war, daß ein hartgecodetes Zeichenlimit von 3000 genauso Käse ist wie ein hartgecodetes Zeichenlimit von 500 auf Mastodon. Deswegen hat doch so ziemlich jeder Mastodon-Fork, der was auf sich hält, ein konfigurierbares Zeichenlimit. Und jeder Forkey, der was auf sich hält, auch.
Drittens: Bugfixes. Allerdings nicht nur von Misskey-Bugs, die von den Forkeys geerbt wurden, sondern ebenso von Bugs, die mit der Featuritis Einzug gehalten haben. Deswegen war Sharkey ("Hauptsache, erstmal Features") vs. Iceshrimp ("Hauptsache, erstmal Stabilität") das neue FoundKey vs. Calckey.
Viertens, das habe ich noch gar nicht erwähnt: ein nicht cishet-normatives Fediverse. Sogar eine Nische im Fediverse ganz ausdrücklich für Transpersonen, deren serverseitiger Unterbau selbst von Transpersonen entwickelt und gepflegt wird. Warum? Weil der Admin von misskey.io, der größten Misskey-Instanz überhaupt, durch das Shadowbanning entsprechender Begriffe mal eine gewisse Homophobie, Transphobie und generelle Queerphobie impliziert hat. Wohlgemerkt, der Admin von misskey.io, nicht irgendeiner der Entwickler von Misskey. Aber damit stand Misskey als Ganzes und wohl auch die ganze japanisch-südkoreanische Forkey-Szene doof da.
Hajkey hatte ich ja schon erwähnt. Von einer Transfrau entwickelter Forkey für eine von einer Transfrau gegründete Instanz. Noch offensichtlicher geht's fast schon gar nicht mehr: Hajkey war inspiriert von und benannt nach dem IKEA Blåhaj, dem plüschigen Transgender-Wappentier. Und auch Sharkey wurde von trans Instanzadmins angeschoben, um eine Pro-2SLGBTQQIA+-Alternative zu Misskey mit besonderem Fokus auf Transpersonen zu haben, die Misskey selbst in den Schatten stellt. Ich meine, warum ist das Maskottchen von Sharkey ein Anime-Mädchen in einem blauen Haianzug?
Sharkeys Ziel dürfte auch gewesen sein, einen Fediverse-Alleskönner zu bauen. Egal, was man im Fediverse machen will, egal, was man für Features braucht, sie sollten auf jeden Fall auch erhältlich sein von trans Entwicklern und nicht nur von Cishet-Männern. Wohl auch deshalb wurde Sharkey aufgebläht zu einem Featuremonster, das im Rahmen der Möglichkeiten von *key Friendica und sogar Hubzilla Konkurrenz zu machen versucht. Transpersonen sollten anstelle dieser beiden Anwendungen, die praktisch komplett von Cishet-Männern entwickelt und gepflegt werden, mit möglichst wenig Einschränkungen auch Sharkey nutzen können.
Das Problem im Westen ist nur, Entwickler zu finden und zu halten. Wie gesagt, in Fernost dominiert *key alles. Hier im Westen ist *key eine Nische. Hier ist alles Nische, was nicht Mastodon ist. Ein erheblicher Teil der Fediverse-Nutzer kennt nur Mastodon, glaubt gar, das Fediverse sei nur Mastodon. Ein paar mehr glauben, das Fediverse sei nicht viel mehr als Mastodon, PeerTube und Pixelfed. Geschätzt mindestens die Hälfte aller Fediverse-Nutzer glaubt, Mastodon sei die einzige auf Microblogging ausgelegte Anwendung im Fediverse.
Dazu kommt die Konkurrenz. Neben Mastodon gibt's ja nicht nur *key. Auch Pleroma und Akkoma wollen ein Stück vom Kuchen abhaben, und die dürften mindestens so bekannt sein wie *key. Daneben gibt's noch sehr viele weitere Projekte in sehr vielen weiteren Größenordnungen von snac2 über GoToSocial bis Mitra, die alle dasselbe wollen wie Mastodon und die *keys.
Entsprechend verteilen sich dann auch die fähigen Entwickler. Die meisten forken entweder Mastodon, um daraus etwas zu bauen mit Features, die "das Fediverse" dringend haben müßte, die aber schon Misskey längst hat. Nur haben sie von Misskey nie gehört und auch nicht von Pleroma oder Friendica oder sonstwas. Oder sie fangen ihre eigene Microblogging-Anwendung an mit denselben Beweggründen und demselben Basiswissen bzw. Mangel daran. Ich schätze, von denen wissen auch einige bis heute nicht, daß es Misskey und Pleroma gibt. Oder sie bauen irgendwas ganz anderes direkt gegen Mastodon.
Unter denen, die Misskey kennen, gibt's nicht viele fähige Entwickler. Das sieht man ja auch an den Smartphone-Apps: Reine Mastodon-Apps kommen gefühlt im Monatstakt. Aber es hat eine Ewigkeit gedauert, bis es auch nur eine einzige App gab, die direkt auf Misskey und die Forkeys ausgelegt war, geschweige denn stabil und nicht nur auf Japanisch und vielleicht noch Hangul verfügbar. Das heißt auch: Die paar wenigen fähigen Entwickler, die Misskey kennen, sind entweder schon irgendwo eingebunden oder gebrannte Kinder (oder Ostasiaten, die kein Englisch können, was die Kommunikation ziemlich erschweren würde).
Wer also Mitstreiter fürs eigene Projekt sucht, vor allem so vertrauenswürdige, daß die dann auch committen dürfen, wird keine finden. Gleichzeitig ist es aber absoluter Wahnsinn, einen Soft-Fork von Misskey alleine ohne jegliche Hilfe zu pflegen und weiterzuentwickeln, insbesondere, wenn der an Fahrt aufnimmt und von mehr und mehr Leuten genutzt wird. Genau daran ist Firefish letzten Endes eingegangen.
Im Grunde braucht es heutzutage gar nicht mehr diesen Wust an Forkeys, jedenfalls nicht im Westen. Das heißt, im Grunde könnte CherryPick rein technisch die meisten Anforderungen erschlagen, und noch dazu soll es bombenstabil sein. Nur hat man dann etwas, das so aussieht, wie Matcha oder Melonenbrause schmeckt, und wo die meisten Commits, die nicht von Misskey kommen, auf Japanisch oder Hangul beschrieben sind.
#Long #LongPost #CWLong #CWLongPost #LangerPost #CWLangerPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Misskey #Forkey #Forkeys #Calckey #Firefish #Iceshrimp #Sharkey #CherryPick #FoundKey #Hajkey -
@crossgolf_rebel - kostenlose Kwalitätsposts @「 Jürgen 」:fedi_mastodon: So ist das. Es zeigt aber auch sehr deutlich den Unterschied zwischen dem Fediverse in der westlichen Welt und dem Fediverse in Ostasien.
So, wie bei uns im Westen das Fediverse im wesentlichen Mastodon ist, ist in Ostasien das Fediverse im wesentlichen *key. Die kennen auch Mastodon, aber das spielt da nur eine untergeordnete Rolle. Etwas, was dem Platzhirsch Misskey das Wasser nicht reichen kann, hat da einfach keine Chance.
In Ostasien gibt's im wesentlichen zwei Gründe für Forkeys. Zum einen ist Misskey eigentlich verbuggt bis zum Gehtnichtmehr. Die Bugs sind bekannt. Die Bugs sind in Issues auf GitHub dokumentiert. Aber es passiert einfach nix. Man könnte Pull Requests einreichen, mit denen ein Bug sofort aus der Welt geschafft werden könnte. Die werden aber einfach nicht gemerget.
Was machst du also? Du machst aus deinem Entwicklungsfork, mit dem du deinen Patch gebaut hast, ein eigenes Projekt mit eigenem Namen und haust das als direkte Konkurrenz zu Misskey raus. Also als Soft-Fork, wo du ab und an mal Commits von Misskey rüberholst und bei dir einpflegst. Oder wenn du an Misskeys Weiterentwicklung eh nicht glaubst, gleich als Hard-Fork, wo du letztlich die ganze Weiterentwicklung selbst machst.
Zum anderen gibt's immer wieder Ideen, wie die Usability von *key verbessert oder in andere Richtungen getrieben werden könnte. Das kann man natürlich nicht unbedingt mit Misskey selbst machen. Also macht man dafür eben einen Fork.
Die Featuritis westlicher Art in japanischen und südkoreanischen Forkeys kam doch eigentlich erst richtig auf, als man in Ostasien bemerkte, daß zum einen Misskey im Westen populärer wurde (immer mehr englische Notizen auf Misskey-Instanzen, immer mehr englische Issues auf GitHub, wo früher mal alle japanisch waren, etc.) und zum anderen Misskey im Westen geforkt wurde (ein Blick in die Liste der Forks des Misskey-Repository genügt).
Im Westen sind die Gründe für Forkeys etwas anders gelagert. Erstens wollten vermutlich besonders die ganz frühen westlichen Forkeys die Ästhetik verändern. Ich meine, vor ein paar Jahren hatte Misskey noch diese typische knallbunte Ästhetik von Shibuya und Akihabara und Manga und japanischen Verkaufsautomaten. Die Amis und Europäer wollten eher ein sachlicheres Aussehen haben, das Maid-Café in eine Studentenkneipe umgestalten, ungewohnte Melonenbrause durch gewohnte Cola ersetzen.
Zweitens, wo man schon mal dabei war: Features, Features, Features. Man war beeindruckt davon, was Misskey konnte, was das eigentlich als Standard und Goldstandard geltende Mastodon nicht konnte. Aber da ging noch was, da war noch Luft nach oben. Und weil verschiedene Entwickler verschiedene Vorstellungen hatten, was jetzt ein Forkey an Features haben soll, standen wohl einige Zeit vor allem FoundKey und Calckey in Konkurrenz zueinander.
Zu den Sachen, auf die sie sich einigen konnten, war, daß ein hartgecodetes Zeichenlimit von 3000 genauso Käse ist wie ein hartgecodetes Zeichenlimit von 500 auf Mastodon. Deswegen hat doch so ziemlich jeder Mastodon-Fork, der was auf sich hält, ein konfigurierbares Zeichenlimit. Und jeder Forkey, der was auf sich hält, auch.
Drittens: Bugfixes. Allerdings nicht nur von Misskey-Bugs, die von den Forkeys geerbt wurden, sondern ebenso von Bugs, die mit der Featuritis Einzug gehalten haben. Deswegen war Sharkey ("Hauptsache, erstmal Features") vs. Iceshrimp ("Hauptsache, erstmal Stabilität") das neue FoundKey vs. Calckey.
Viertens, das habe ich noch gar nicht erwähnt: ein nicht cishet-normatives Fediverse. Sogar eine Nische im Fediverse ganz ausdrücklich für Transpersonen, deren serverseitiger Unterbau selbst von Transpersonen entwickelt und gepflegt wird. Warum? Weil der Admin von misskey.io, der größten Misskey-Instanz überhaupt, durch das Shadowbanning entsprechender Begriffe mal eine gewisse Homophobie, Transphobie und generelle Queerphobie impliziert hat. Wohlgemerkt, der Admin von misskey.io, nicht irgendeiner der Entwickler von Misskey. Aber damit stand Misskey als Ganzes und wohl auch die ganze japanisch-südkoreanische Forkey-Szene doof da.
Hajkey hatte ich ja schon erwähnt. Von einer Transfrau entwickelter Forkey für eine von einer Transfrau gegründete Instanz. Noch offensichtlicher geht's fast schon gar nicht mehr: Hajkey war inspiriert von und benannt nach dem IKEA Blåhaj, dem plüschigen Transgender-Wappentier. Und auch Sharkey wurde von trans Instanzadmins angeschoben, um eine Pro-2SLGBTQQIA+-Alternative zu Misskey mit besonderem Fokus auf Transpersonen zu haben, die Misskey selbst in den Schatten stellt. Ich meine, warum ist das Maskottchen von Sharkey ein Anime-Mädchen in einem blauen Haianzug?
Sharkeys Ziel dürfte auch gewesen sein, einen Fediverse-Alleskönner zu bauen. Egal, was man im Fediverse machen will, egal, was man für Features braucht, sie sollten auf jeden Fall auch erhältlich sein von trans Entwicklern und nicht nur von Cishet-Männern. Wohl auch deshalb wurde Sharkey aufgebläht zu einem Featuremonster, das im Rahmen der Möglichkeiten von *key Friendica und sogar Hubzilla Konkurrenz zu machen versucht. Transpersonen sollten anstelle dieser beiden Anwendungen, die praktisch komplett von Cishet-Männern entwickelt und gepflegt werden, mit möglichst wenig Einschränkungen auch Sharkey nutzen können.
Das Problem im Westen ist nur, Entwickler zu finden und zu halten. Wie gesagt, in Fernost dominiert *key alles. Hier im Westen ist *key eine Nische. Hier ist alles Nische, was nicht Mastodon ist. Ein erheblicher Teil der Fediverse-Nutzer kennt nur Mastodon, glaubt gar, das Fediverse sei nur Mastodon. Ein paar mehr glauben, das Fediverse sei nicht viel mehr als Mastodon, PeerTube und Pixelfed. Geschätzt mindestens die Hälfte aller Fediverse-Nutzer glaubt, Mastodon sei die einzige auf Microblogging ausgelegte Anwendung im Fediverse.
Dazu kommt die Konkurrenz. Neben Mastodon gibt's ja nicht nur *key. Auch Pleroma und Akkoma wollen ein Stück vom Kuchen abhaben, und die dürften mindestens so bekannt sein wie *key. Daneben gibt's noch sehr viele weitere Projekte in sehr vielen weiteren Größenordnungen von snac2 über GoToSocial bis Mitra, die alle dasselbe wollen wie Mastodon und die *keys.
Entsprechend verteilen sich dann auch die fähigen Entwickler. Die meisten forken entweder Mastodon, um daraus etwas zu bauen mit Features, die "das Fediverse" dringend haben müßte, die aber schon Misskey längst hat. Nur haben sie von Misskey nie gehört und auch nicht von Pleroma oder Friendica oder sonstwas. Oder sie fangen ihre eigene Microblogging-Anwendung an mit denselben Beweggründen und demselben Basiswissen bzw. Mangel daran. Ich schätze, von denen wissen auch einige bis heute nicht, daß es Misskey und Pleroma gibt. Oder sie bauen irgendwas ganz anderes direkt gegen Mastodon.
Unter denen, die Misskey kennen, gibt's nicht viele fähige Entwickler. Das sieht man ja auch an den Smartphone-Apps: Reine Mastodon-Apps kommen gefühlt im Monatstakt. Aber es hat eine Ewigkeit gedauert, bis es auch nur eine einzige App gab, die direkt auf Misskey und die Forkeys ausgelegt war, geschweige denn stabil und nicht nur auf Japanisch und vielleicht noch Hangul verfügbar. Das heißt auch: Die paar wenigen fähigen Entwickler, die Misskey kennen, sind entweder schon irgendwo eingebunden oder gebrannte Kinder (oder Ostasiaten, die kein Englisch können, was die Kommunikation ziemlich erschweren würde).
Wer also Mitstreiter fürs eigene Projekt sucht, vor allem so vertrauenswürdige, daß die dann auch committen dürfen, wird keine finden. Gleichzeitig ist es aber absoluter Wahnsinn, einen Soft-Fork von Misskey alleine ohne jegliche Hilfe zu pflegen und weiterzuentwickeln, insbesondere, wenn der an Fahrt aufnimmt und von mehr und mehr Leuten genutzt wird. Genau daran ist Firefish letzten Endes eingegangen.
Im Grunde braucht es heutzutage gar nicht mehr diesen Wust an Forkeys, jedenfalls nicht im Westen. Das heißt, im Grunde könnte CherryPick rein technisch die meisten Anforderungen erschlagen, und noch dazu soll es bombenstabil sein. Nur hat man dann etwas, das so aussieht, wie Matcha oder Melonenbrause schmeckt, und wo die meisten Commits, die nicht von Misskey kommen, auf Japanisch oder Hangul beschrieben sind.
#Long #LongPost #CWLong #CWLongPost #LangerPost #CWLangerPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Misskey #Forkey #Forkeys #Calckey #Firefish #Iceshrimp #Sharkey #CherryPick #FoundKey #Hajkey -
@crossgolf_rebel - kostenlose Kwalitätsposts @「 Jürgen 」:fedi_mastodon: So ist das. Es zeigt aber auch sehr deutlich den Unterschied zwischen dem Fediverse in der westlichen Welt und dem Fediverse in Ostasien.
So, wie bei uns im Westen das Fediverse im wesentlichen Mastodon ist, ist in Ostasien das Fediverse im wesentlichen *key. Die kennen auch Mastodon, aber das spielt da nur eine untergeordnete Rolle. Etwas, was dem Platzhirsch Misskey das Wasser nicht reichen kann, hat da einfach keine Chance.
In Ostasien gibt's im wesentlichen zwei Gründe für Forkeys. Zum einen ist Misskey eigentlich verbuggt bis zum Gehtnichtmehr. Die Bugs sind bekannt. Die Bugs sind in Issues auf GitHub dokumentiert. Aber es passiert einfach nix. Man könnte Pull Requests einreichen, mit denen ein Bug sofort aus der Welt geschafft werden könnte. Die werden aber einfach nicht gemerget.
Was machst du also? Du machst aus deinem Entwicklungsfork, mit dem du deinen Patch gebaut hast, ein eigenes Projekt mit eigenem Namen und haust das als direkte Konkurrenz zu Misskey raus. Also als Soft-Fork, wo du ab und an mal Commits von Misskey rüberholst und bei dir einpflegst. Oder wenn du an Misskeys Weiterentwicklung eh nicht glaubst, gleich als Hard-Fork, wo du letztlich die ganze Weiterentwicklung selbst machst.
Zum anderen gibt's immer wieder Ideen, wie die Usability von *key verbessert oder in andere Richtungen getrieben werden könnte. Das kann man natürlich nicht unbedingt mit Misskey selbst machen. Also macht man dafür eben einen Fork.
Die Featuritis westlicher Art in japanischen und südkoreanischen Forkeys kam doch eigentlich erst richtig auf, als man in Ostasien bemerkte, daß zum einen Misskey im Westen populärer wurde (immer mehr englische Notizen auf Misskey-Instanzen, immer mehr englische Issues auf GitHub, wo früher mal alle japanisch waren, etc.) und zum anderen Misskey im Westen geforkt wurde (ein Blick in die Liste der Forks des Misskey-Repository genügt).
Im Westen sind die Gründe für Forkeys etwas anders gelagert. Erstens wollten vermutlich besonders die ganz frühen westlichen Forkeys die Ästhetik verändern. Ich meine, vor ein paar Jahren hatte Misskey noch diese typische knallbunte Ästhetik von Shibuya und Akihabara und Manga und japanischen Verkaufsautomaten. Die Amis und Europäer wollten eher ein sachlicheres Aussehen haben, das Maid-Café in eine Studentenkneipe umgestalten, ungewohnte Melonenbrause durch gewohnte Cola ersetzen.
Zweitens, wo man schon mal dabei war: Features, Features, Features. Man war beeindruckt davon, was Misskey konnte, was das eigentlich als Standard und Goldstandard geltende Mastodon nicht konnte. Aber da ging noch was, da war noch Luft nach oben. Und weil verschiedene Entwickler verschiedene Vorstellungen hatten, was jetzt ein Forkey an Features haben soll, standen wohl einige Zeit vor allem FoundKey und Calckey in Konkurrenz zueinander.
Zu den Sachen, auf die sie sich einigen konnten, war, daß ein hartgecodetes Zeichenlimit von 3000 genauso Käse ist wie ein hartgecodetes Zeichenlimit von 500 auf Mastodon. Deswegen hat doch so ziemlich jeder Mastodon-Fork, der was auf sich hält, ein konfigurierbares Zeichenlimit. Und jeder Forkey, der was auf sich hält, auch.
Drittens: Bugfixes. Allerdings nicht nur von Misskey-Bugs, die von den Forkeys geerbt wurden, sondern ebenso von Bugs, die mit der Featuritis Einzug gehalten haben. Deswegen war Sharkey ("Hauptsache, erstmal Features") vs. Iceshrimp ("Hauptsache, erstmal Stabilität") das neue FoundKey vs. Calckey.
Viertens, das habe ich noch gar nicht erwähnt: ein nicht cishet-normatives Fediverse. Sogar eine Nische im Fediverse ganz ausdrücklich für Transpersonen, deren serverseitiger Unterbau selbst von Transpersonen entwickelt und gepflegt wird. Warum? Weil der Admin von misskey.io, der größten Misskey-Instanz überhaupt, durch das Shadowbanning entsprechender Begriffe mal eine gewisse Homophobie, Transphobie und generelle Queerphobie impliziert hat. Wohlgemerkt, der Admin von misskey.io, nicht irgendeiner der Entwickler von Misskey. Aber damit stand Misskey als Ganzes und wohl auch die ganze japanisch-südkoreanische Forkey-Szene doof da.
Hajkey hatte ich ja schon erwähnt. Von einer Transfrau entwickelter Forkey für eine von einer Transfrau gegründete Instanz. Noch offensichtlicher geht's fast schon gar nicht mehr: Hajkey war inspiriert von und benannt nach dem IKEA Blåhaj, dem plüschigen Transgender-Wappentier. Und auch Sharkey wurde von trans Instanzadmins angeschoben, um eine Pro-2SLGBTQQIA+-Alternative zu Misskey mit besonderem Fokus auf Transpersonen zu haben, die Misskey selbst in den Schatten stellt. Ich meine, warum ist das Maskottchen von Sharkey ein Anime-Mädchen in einem blauen Haianzug?
Sharkeys Ziel dürfte auch gewesen sein, einen Fediverse-Alleskönner zu bauen. Egal, was man im Fediverse machen will, egal, was man für Features braucht, sie sollten auf jeden Fall auch erhältlich sein von trans Entwicklern und nicht nur von Cishet-Männern. Wohl auch deshalb wurde Sharkey aufgebläht zu einem Featuremonster, das im Rahmen der Möglichkeiten von *key Friendica und sogar Hubzilla Konkurrenz zu machen versucht. Transpersonen sollten anstelle dieser beiden Anwendungen, die praktisch komplett von Cishet-Männern entwickelt und gepflegt werden, mit möglichst wenig Einschränkungen auch Sharkey nutzen können.
Das Problem im Westen ist nur, Entwickler zu finden und zu halten. Wie gesagt, in Fernost dominiert *key alles. Hier im Westen ist *key eine Nische. Hier ist alles Nische, was nicht Mastodon ist. Ein erheblicher Teil der Fediverse-Nutzer kennt nur Mastodon, glaubt gar, das Fediverse sei nur Mastodon. Ein paar mehr glauben, das Fediverse sei nicht viel mehr als Mastodon, PeerTube und Pixelfed. Geschätzt mindestens die Hälfte aller Fediverse-Nutzer glaubt, Mastodon sei die einzige auf Microblogging ausgelegte Anwendung im Fediverse.
Dazu kommt die Konkurrenz. Neben Mastodon gibt's ja nicht nur *key. Auch Pleroma und Akkoma wollen ein Stück vom Kuchen abhaben, und die dürften mindestens so bekannt sein wie *key. Daneben gibt's noch sehr viele weitere Projekte in sehr vielen weiteren Größenordnungen von snac2 über GoToSocial bis Mitra, die alle dasselbe wollen wie Mastodon und die *keys.
Entsprechend verteilen sich dann auch die fähigen Entwickler. Die meisten forken entweder Mastodon, um daraus etwas zu bauen mit Features, die "das Fediverse" dringend haben müßte, die aber schon Misskey längst hat. Nur haben sie von Misskey nie gehört und auch nicht von Pleroma oder Friendica oder sonstwas. Oder sie fangen ihre eigene Microblogging-Anwendung an mit denselben Beweggründen und demselben Basiswissen bzw. Mangel daran. Ich schätze, von denen wissen auch einige bis heute nicht, daß es Misskey und Pleroma gibt. Oder sie bauen irgendwas ganz anderes direkt gegen Mastodon.
Unter denen, die Misskey kennen, gibt's nicht viele fähige Entwickler. Das sieht man ja auch an den Smartphone-Apps: Reine Mastodon-Apps kommen gefühlt im Monatstakt. Aber es hat eine Ewigkeit gedauert, bis es auch nur eine einzige App gab, die direkt auf Misskey und die Forkeys ausgelegt war, geschweige denn stabil und nicht nur auf Japanisch und vielleicht noch Hangul verfügbar. Das heißt auch: Die paar wenigen fähigen Entwickler, die Misskey kennen, sind entweder schon irgendwo eingebunden oder gebrannte Kinder (oder Ostasiaten, die kein Englisch können, was die Kommunikation ziemlich erschweren würde).
Wer also Mitstreiter fürs eigene Projekt sucht, vor allem so vertrauenswürdige, daß die dann auch committen dürfen, wird keine finden. Gleichzeitig ist es aber absoluter Wahnsinn, einen Soft-Fork von Misskey alleine ohne jegliche Hilfe zu pflegen und weiterzuentwickeln, insbesondere, wenn der an Fahrt aufnimmt und von mehr und mehr Leuten genutzt wird. Genau daran ist Firefish letzten Endes eingegangen.
Im Grunde braucht es heutzutage gar nicht mehr diesen Wust an Forkeys, jedenfalls nicht im Westen. Das heißt, im Grunde könnte CherryPick rein technisch die meisten Anforderungen erschlagen, und noch dazu soll es bombenstabil sein. Nur hat man dann etwas, das so aussieht, wie Matcha oder Melonenbrause schmeckt, und wo die meisten Commits, die nicht von Misskey kommen, auf Japanisch oder Hangul beschrieben sind.
#Long #LongPost #CWLong #CWLongPost #LangerPost #CWLangerPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Misskey #Forkey #Forkeys #Calckey #Firefish #Iceshrimp #Sharkey #CherryPick #FoundKey #Hajkey -
@「 Jürgen 」:fedi_mastodon: @crossgolf_rebel - kostenlose Kwalitätsposts @Don di Dislessia Soweit ich weiß, war es so (man möge mich wiederum korrigieren; kursiv sind die "Forkeys höheren Grades", die nicht von Misskey geforkt wurden):
- Misskey
Der Ursprung in Japan. - Calckey
Soft-Fork von Misskey mit einigen Extrafeatures.
Entwickler hatte irgendwann keine Zeit/keinen Bock mehr. - Firefish
Fortführung von Calckey unter neuem Management. Wurde aufgrund einer massiven Werbeaktion eines begeisterten Nutzers mit viel Reichweite so populär, daß der Name "Calckey" irgendwann einfach doof war und das ganze Ding eine neue Identität bekam.
Entwickler verschwand irgendwann sang- und klanglos von der Bildfläche. Nach einem halben Jahr stellte sich raus: Entwickler hatte wegen Abschlußarbeit usw. keine Zeit mehr, nicht mal, sich zu verabschieden.
Wurde unter neuer Führung mit neuem Repository und neuer Leuchtturminstanz weitergeführt, aber ohne neue Website. Wurde wieder eingestellt, weil es für eine einzige Entwicklerin viel zuviel war, die ganzen alten Co-Entwickler von Firefish alle zu Iceshrimp gewechselt waren und keine neuen Mitentwickler angeheuert werden konnten. - Iceshrimp
Fork von Firefish von ehemaligen Firefish-Entwicklern. Rebased nach Misskey, weil es auf Firefish nicht weiterging. Erklärtes Ziel war, Stabilität über Calckeys Featuritis zu stellen.
Weil Misskeys Codebase an sich einiges an grundsätzlichen Macken hatte, wurde beschlossen, es ist einfacher, das ganze Zeugs von Grund auf neu zu schreiben, als zu versuchen, das alles auszubügeln. Und bei der Gelegenheit wollte man von JavaScript (TypeScript und Vue.js) weg. Also hat man angefangen, das ganze Ding in C# neu zu schreiben als Iceshrimp.NET. Ziel ist featuremäßige Deckungsgleichheit mit dem bisherigen Iceshrimp und gleichzeitig Anpassung an Mastodon. Iceshrimp.NET ist noch sehr unfertig.
Bei der Gelegenheit wurde das alte Iceshrimp in Iceshrimp-JS umbenannt und in den Wartungsmodus versetzt = gibt keine Weiterentwicklung und keine neuen Features mehr, nur Sicherheitspatches und evtl. Bugfixes. - Catodon
Soft-Fork von Firefish. Ziel war, ein Forkey zu haben, das sich in der Bedienung wie Mastodon anfühlt. Quasi Mastodon-Fassade mit *key-Struktur dahinter. Also ein Forkey für den möglichst leichten Umstieg von Mastodon nach *key.
Wurde, als Firefish endgültig eingestellt wurde und damit die Basis tot war, nach Iceshrimp rebased.
Nachdem Iceshrimp zu Iceshrimp-JS wurde und in den Wartungsmodus ging, hatte Catodon ein Problem: Man kann nicht einfach von etwas, das in TypeScript und Vue.js geschrieben ist, nach etwas rebasen, das in C# geschrieben ist (Iceshrimp.NET). Und zur Weiterentwicklung wäre ein Rebase nötig gewesen, weil man jetzt wieder eine fast tote Basis hatte. Aber nach Misskey wollte man nicht (siehe Hajkey weiter unten), und Sharkey war einerseits zu mächtig und andererseits zu kapriziös.
Inzwischen gehen Catodon die Instanzen ein. Die meisten dürften geschlossen worden sein. - Sharkey
Soft-Fork von Misskey mit dem Ziel, so ziemlich alles, was je für Forkeys an Features entwickelt worden war, in einen einzigen Forkey zu packen und noch mehr obendrauf.
Quasi das Yang zu Iceshrimps Yin. Machte lange den Eindruck, als gingen Features über Zuverlässigkeit. Sharkeys Implementation der Mastodon Client API war schon regelrecht legendär schlecht, und alle hofften auf den Retter, der daherkommt und die Implementation von Grund auf neu schreibt, weil sie als unrettbar im Eimer galt. Inzwischen soll Sharkey seine Zuverlässigkeit im Griff haben, zumindest insofern, wie auch Misskey zuverlässig ist.
Die Entwickler haben eine zweifelhafte Reputation. Unter anderem haben sie Crowdfunding-Gelder für einen Sharkey-Server gesammelt und von dem Geld einen Minecraft-Server aufgezogen, aber keinen Sharkey-Server. Mitunter wird deshalb zum Boykott von Sharkey aufgerufen. - CherryPick
Südkoreanischer Soft-Fork von Misskey. Tatsächlich älter als Sharkey, mindestens von 2021, aber später wurde wohl einiges von Sharkey nach CherryPick portiert. Das Ziel war, einen stabilen und zuverlässigen Forkey zu haben ohne die Macken von Sharkey und sogar ohne die Macken von Misskey, der aber gleichzeitig gut Features hat. Das ist wohl sogar weitestgehend gelungen.
Vom ästhetischen Stil her so ähnlich, wie Misskey früher mal war, also sehr auf den japanischen bzw. südkoreanischen Geschmack ausgelegt: bunt, grell, poppig, genki, kawaii. Alleine das zeigt, daß CherryPick von Misskey geforkt wurde, bevor Misskey gänzlich an den westlichen Geschmack angepaßt wurde.
Unklar, ob es Entwickler hat, die Englisch verstehen bzw. schreiben können; falls nicht, dann als Soft-Fork-Basis ungeeignet. Wäre ohne die Kommunikationsbarriere vermutlich der ultimative *key.
Mein letzter Stand: Bis auf eine Instanz im Großraum Washington, D.C. gibt es CherryPick-Instanzen nur in den Großräumen Tokyo und Seoul. War deshalb lange Zeit im westlichen Fediverse fast unbekannt. - FoundKey
Wohl der erste Forkey, der in PascalCase geschrieben wurde.
Meines Wissens direkter Soft-Fork von Misskey. Wird tatsächlich (oh Wunder) kleckerweise gepflegt, aber nicht für Instanzen mit mehr als 20 Nutzern empfohlen.
Ein paar andere *keys:- Hajkey
Soft-Fork von Calckey, der meines Wissens erst nach Firefish und dann nach Misskey rebased wurde. Wurde exklusiv nur für eine einzige Instanz entwickelt: transfem.social. Inzwischen eingestellt, weil wohl der Aufwand, so einen Wolpertinger nur für eine Instanz zu pflegen (man rebaset nicht mal eben von Firefish nach Misskey), zu groß war. transfem.social wurde entsprechend auf Sharkey umgestellt und ist da jetzt eine der größten Instanzen. - Neko
Soft-Fork von Misskey mit dem Ziel, es tauglich für Docker zu machen. Laut Repository nur für eine einzige Instanz gebaut. Ist nie released worden, was aber Wurscht ist, wenn es eh nur einen Admin als Zielgruppe hatte.git fetchkönnen Releases nämlich piepegal sein. - Meisskey
Japanischer Soft-Fork von Misskey von 2019 (!), der aber lange Zeit der Weiterentwicklung der Basis hinterherhinkte. Wird tatsächlich immer noch weiterentwickelt. - Leisskey
Wiederum japanischer Soft-Fork von Meisskey. Ist seit mindestens 2021 in Entwicklung, seit Februar 2023 aber eine ewige Beta, weil es seit damals keinen Release mehr gegeben hat. Dürfte zu den letzten noch in Entwicklung befindlichen "Forkeys 2. Grades" gehören. - Tanukey
Weiterer japanischer Soft-Fork von Misskey und daher so obskur im Westen, daß man schon die Websuche anstrengen muß, um das Repository zu finden (ist wohl im letzten Oktober von GitHub nach GitLab umgezogen). Noch ein Beispiel für *keys, bei denen selbst das Wissen über ihre Existenz Ostasien kaum je verlassen hat. - Backspacekey
Noch ein ambitionierter, aber eingeschlafener westlicher Misskey-Soft-Fork.
Siehe übrigens auch die Delightful Fediverse Experience: hier und hier.
Verglichen damit ist die Familie von Mistpark bis Forte schon wieder übersichtlich, vor allem, wenn die anderen mehreren Dutzend toten Forkeys mit dazugeholt werden. Immerhin stammt von Mistpark bis Forte über etwa 15 Jahre alles vom selben Schöpfer, der einfach nur sein eigenes Zeug geforkt hat.
#Long #LongPost #CWLong #CWLongPost #LangerPost #CWLangerPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Misskey #Forkey #Forkeys #Calckey #Firefish #Iceshrimp #IceshrimpJS #Iceshrimp.NET #Catodon #Sharkey #CherryPick #FoundKey #Hajkey #Neko #Meisskey #Leisskey #Tanukey #Backspacekey - Misskey
-
@「 Jürgen 」:fedi_mastodon: @crossgolf_rebel - kostenlose Kwalitätsposts @Don di Dislessia Soweit ich weiß, war es so (man möge mich wiederum korrigieren; kursiv sind die "Forkeys höheren Grades", die nicht von Misskey geforkt wurden):
- Misskey
Der Ursprung in Japan. - Calckey
Soft-Fork von Misskey mit einigen Extrafeatures.
Entwickler hatte irgendwann keine Zeit/keinen Bock mehr. - Firefish
Fortführung von Calckey unter neuem Management. Wurde aufgrund einer massiven Werbeaktion eines begeisterten Nutzers mit viel Reichweite so populär, daß der Name "Calckey" irgendwann einfach doof war und das ganze Ding eine neue Identität bekam.
Entwickler verschwand irgendwann sang- und klanglos von der Bildfläche. Nach einem halben Jahr stellte sich raus: Entwickler hatte wegen Abschlußarbeit usw. keine Zeit mehr, nicht mal, sich zu verabschieden.
Wurde unter neuer Führung mit neuem Repository und neuer Leuchtturminstanz weitergeführt, aber ohne neue Website. Wurde wieder eingestellt, weil es für eine einzige Entwicklerin viel zuviel war, die ganzen alten Co-Entwickler von Firefish alle zu Iceshrimp gewechselt waren und keine neuen Mitentwickler angeheuert werden konnten. - Iceshrimp
Fork von Firefish von ehemaligen Firefish-Entwicklern. Rebased nach Misskey, weil es auf Firefish nicht weiterging. Erklärtes Ziel war, Stabilität über Calckeys Featuritis zu stellen.
Weil Misskeys Codebase an sich einiges an grundsätzlichen Macken hatte, wurde beschlossen, es ist einfacher, das ganze Zeugs von Grund auf neu zu schreiben, als zu versuchen, das alles auszubügeln. Und bei der Gelegenheit wollte man von JavaScript (TypeScript und Vue.js) weg. Also hat man angefangen, das ganze Ding in C# neu zu schreiben als Iceshrimp.NET. Ziel ist featuremäßige Deckungsgleichheit mit dem bisherigen Iceshrimp und gleichzeitig Anpassung an Mastodon. Iceshrimp.NET ist noch sehr unfertig.
Bei der Gelegenheit wurde das alte Iceshrimp in Iceshrimp-JS umbenannt und in den Wartungsmodus versetzt = gibt keine Weiterentwicklung und keine neuen Features mehr, nur Sicherheitspatches und evtl. Bugfixes. - Catodon
Soft-Fork von Firefish. Ziel war, ein Forkey zu haben, das sich in der Bedienung wie Mastodon anfühlt. Quasi Mastodon-Fassade mit *key-Struktur dahinter. Also ein Forkey für den möglichst leichten Umstieg von Mastodon nach *key.
Wurde, als Firefish endgültig eingestellt wurde und damit die Basis tot war, nach Iceshrimp rebased.
Nachdem Iceshrimp zu Iceshrimp-JS wurde und in den Wartungsmodus ging, hatte Catodon ein Problem: Man kann nicht einfach von etwas, das in TypeScript und Vue.js geschrieben ist, nach etwas rebasen, das in C# geschrieben ist (Iceshrimp.NET). Und zur Weiterentwicklung wäre ein Rebase nötig gewesen, weil man jetzt wieder eine fast tote Basis hatte. Aber nach Misskey wollte man nicht (siehe Hajkey weiter unten), und Sharkey war einerseits zu mächtig und andererseits zu kapriziös.
Inzwischen gehen Catodon die Instanzen ein. Die meisten dürften geschlossen worden sein. - Sharkey
Soft-Fork von Misskey mit dem Ziel, so ziemlich alles, was je für Forkeys an Features entwickelt worden war, in einen einzigen Forkey zu packen und noch mehr obendrauf.
Quasi das Yang zu Iceshrimps Yin. Machte lange den Eindruck, als gingen Features über Zuverlässigkeit. Sharkeys Implementation der Mastodon Client API war schon regelrecht legendär schlecht, und alle hofften auf den Retter, der daherkommt und die Implementation von Grund auf neu schreibt, weil sie als unrettbar im Eimer galt. Inzwischen soll Sharkey seine Zuverlässigkeit im Griff haben, zumindest insofern, wie auch Misskey zuverlässig ist.
Die Entwickler haben eine zweifelhafte Reputation. Unter anderem haben sie Crowdfunding-Gelder für einen Sharkey-Server gesammelt und von dem Geld einen Minecraft-Server aufgezogen, aber keinen Sharkey-Server. Mitunter wird deshalb zum Boykott von Sharkey aufgerufen. - CherryPick
Südkoreanischer Soft-Fork von Misskey. Tatsächlich älter als Sharkey, mindestens von 2021, aber später wurde wohl einiges von Sharkey nach CherryPick portiert. Das Ziel war, einen stabilen und zuverlässigen Forkey zu haben ohne die Macken von Sharkey und sogar ohne die Macken von Misskey, der aber gleichzeitig gut Features hat. Das ist wohl sogar weitestgehend gelungen.
Vom ästhetischen Stil her so ähnlich, wie Misskey früher mal war, also sehr auf den japanischen bzw. südkoreanischen Geschmack ausgelegt: bunt, grell, poppig, genki, kawaii. Alleine das zeigt, daß CherryPick von Misskey geforkt wurde, bevor Misskey gänzlich an den westlichen Geschmack angepaßt wurde.
Unklar, ob es Entwickler hat, die Englisch verstehen bzw. schreiben können; falls nicht, dann als Soft-Fork-Basis ungeeignet. Wäre ohne die Kommunikationsbarriere vermutlich der ultimative *key.
Mein letzter Stand: Bis auf eine Instanz im Großraum Washington, D.C. gibt es CherryPick-Instanzen nur in den Großräumen Tokyo und Seoul. War deshalb lange Zeit im westlichen Fediverse fast unbekannt. - FoundKey
Wohl der erste Forkey, der in PascalCase geschrieben wurde.
Meines Wissens direkter Soft-Fork von Misskey. Wird tatsächlich (oh Wunder) kleckerweise gepflegt, aber nicht für Instanzen mit mehr als 20 Nutzern empfohlen.
Ein paar andere *keys:- Hajkey
Soft-Fork von Calckey, der meines Wissens erst nach Firefish und dann nach Misskey rebased wurde. Wurde exklusiv nur für eine einzige Instanz entwickelt: transfem.social. Inzwischen eingestellt, weil wohl der Aufwand, so einen Wolpertinger nur für eine Instanz zu pflegen (man rebaset nicht mal eben von Firefish nach Misskey), zu groß war. transfem.social wurde entsprechend auf Sharkey umgestellt und ist da jetzt eine der größten Instanzen. - Neko
Soft-Fork von Misskey mit dem Ziel, es tauglich für Docker zu machen. Laut Repository nur für eine einzige Instanz gebaut. Ist nie released worden, was aber Wurscht ist, wenn es eh nur einen Admin als Zielgruppe hatte.git fetchkönnen Releases nämlich piepegal sein. - Meisskey
Japanischer Soft-Fork von Misskey von 2019 (!), der aber lange Zeit der Weiterentwicklung der Basis hinterherhinkte. Wird tatsächlich immer noch weiterentwickelt. - Leisskey
Wiederum japanischer Soft-Fork von Meisskey. Ist seit mindestens 2021 in Entwicklung, seit Februar 2023 aber eine ewige Beta, weil es seit damals keinen Release mehr gegeben hat. Dürfte zu den letzten noch in Entwicklung befindlichen "Forkeys 2. Grades" gehören. - Tanukey
Weiterer japanischer Soft-Fork von Misskey und daher so obskur im Westen, daß man schon die Websuche anstrengen muß, um das Repository zu finden (ist wohl im letzten Oktober von GitHub nach GitLab umgezogen). Noch ein Beispiel für *keys, bei denen selbst das Wissen über ihre Existenz Ostasien kaum je verlassen hat. - Backspacekey
Noch ein ambitionierter, aber eingeschlafener westlicher Misskey-Soft-Fork.
Siehe übrigens auch die Delightful Fediverse Experience: hier und hier.
Verglichen damit ist die Familie von Mistpark bis Forte schon wieder übersichtlich, vor allem, wenn die anderen mehreren Dutzend toten Forkeys mit dazugeholt werden. Immerhin stammt von Mistpark bis Forte über etwa 15 Jahre alles vom selben Schöpfer, der einfach nur sein eigenes Zeug geforkt hat.
#Long #LongPost #CWLong #CWLongPost #LangerPost #CWLangerPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Misskey #Forkey #Forkeys #Calckey #Firefish #Iceshrimp #IceshrimpJS #Iceshrimp.NET #Catodon #Sharkey #CherryPick #FoundKey #Hajkey #Neko #Meisskey #Leisskey #Tanukey #Backspacekey - Misskey
-
@「 Jürgen 」:fedi_mastodon: @crossgolf_rebel - kostenlose Kwalitätsposts @Don di Dislessia Soweit ich weiß, war es so (man möge mich wiederum korrigieren; kursiv sind die "Forkeys höheren Grades", die nicht von Misskey geforkt wurden):
- Misskey
Der Ursprung in Japan. - Calckey
Soft-Fork von Misskey mit einigen Extrafeatures.
Entwickler hatte irgendwann keine Zeit/keinen Bock mehr. - Firefish
Fortführung von Calckey unter neuem Management. Wurde aufgrund einer massiven Werbeaktion eines begeisterten Nutzers mit viel Reichweite so populär, daß der Name "Calckey" irgendwann einfach doof war und das ganze Ding eine neue Identität bekam.
Entwickler verschwand irgendwann sang- und klanglos von der Bildfläche. Nach einem halben Jahr stellte sich raus: Entwickler hatte wegen Abschlußarbeit usw. keine Zeit mehr, nicht mal, sich zu verabschieden.
Wurde unter neuer Führung mit neuem Repository und neuer Leuchtturminstanz weitergeführt, aber ohne neue Website. Wurde wieder eingestellt, weil es für eine einzige Entwicklerin viel zuviel war, die ganzen alten Co-Entwickler von Firefish alle zu Iceshrimp gewechselt waren und keine neuen Mitentwickler angeheuert werden konnten. - Iceshrimp
Fork von Firefish von ehemaligen Firefish-Entwicklern. Rebased nach Misskey, weil es auf Firefish nicht weiterging. Erklärtes Ziel war, Stabilität über Calckeys Featuritis zu stellen.
Weil Misskeys Codebase an sich einiges an grundsätzlichen Macken hatte, wurde beschlossen, es ist einfacher, das ganze Zeugs von Grund auf neu zu schreiben, als zu versuchen, das alles auszubügeln. Und bei der Gelegenheit wollte man von JavaScript (TypeScript und Vue.js) weg. Also hat man angefangen, das ganze Ding in C# neu zu schreiben als Iceshrimp.NET. Ziel ist featuremäßige Deckungsgleichheit mit dem bisherigen Iceshrimp und gleichzeitig Anpassung an Mastodon. Iceshrimp.NET ist noch sehr unfertig.
Bei der Gelegenheit wurde das alte Iceshrimp in Iceshrimp-JS umbenannt und in den Wartungsmodus versetzt = gibt keine Weiterentwicklung und keine neuen Features mehr, nur Sicherheitspatches und evtl. Bugfixes. - Catodon
Soft-Fork von Firefish. Ziel war, ein Forkey zu haben, das sich in der Bedienung wie Mastodon anfühlt. Quasi Mastodon-Fassade mit *key-Struktur dahinter. Also ein Forkey für den möglichst leichten Umstieg von Mastodon nach *key.
Wurde, als Firefish endgültig eingestellt wurde und damit die Basis tot war, nach Iceshrimp rebased.
Nachdem Iceshrimp zu Iceshrimp-JS wurde und in den Wartungsmodus ging, hatte Catodon ein Problem: Man kann nicht einfach von etwas, das in TypeScript und Vue.js geschrieben ist, nach etwas rebasen, das in C# geschrieben ist (Iceshrimp.NET). Und zur Weiterentwicklung wäre ein Rebase nötig gewesen, weil man jetzt wieder eine fast tote Basis hatte. Aber nach Misskey wollte man nicht (siehe Hajkey weiter unten), und Sharkey war einerseits zu mächtig und andererseits zu kapriziös.
Inzwischen gehen Catodon die Instanzen ein. Die meisten dürften geschlossen worden sein. - Sharkey
Soft-Fork von Misskey mit dem Ziel, so ziemlich alles, was je für Forkeys an Features entwickelt worden war, in einen einzigen Forkey zu packen und noch mehr obendrauf.
Quasi das Yang zu Iceshrimps Yin. Machte lange den Eindruck, als gingen Features über Zuverlässigkeit. Sharkeys Implementation der Mastodon Client API war schon regelrecht legendär schlecht, und alle hofften auf den Retter, der daherkommt und die Implementation von Grund auf neu schreibt, weil sie als unrettbar im Eimer galt. Inzwischen soll Sharkey seine Zuverlässigkeit im Griff haben, zumindest insofern, wie auch Misskey zuverlässig ist.
Die Entwickler haben eine zweifelhafte Reputation. Unter anderem haben sie Crowdfunding-Gelder für einen Sharkey-Server gesammelt und von dem Geld einen Minecraft-Server aufgezogen, aber keinen Sharkey-Server. Mitunter wird deshalb zum Boykott von Sharkey aufgerufen. - CherryPick
Südkoreanischer Soft-Fork von Misskey. Tatsächlich älter als Sharkey, mindestens von 2021, aber später wurde wohl einiges von Sharkey nach CherryPick portiert. Das Ziel war, einen stabilen und zuverlässigen Forkey zu haben ohne die Macken von Sharkey und sogar ohne die Macken von Misskey, der aber gleichzeitig gut Features hat. Das ist wohl sogar weitestgehend gelungen.
Vom ästhetischen Stil her so ähnlich, wie Misskey früher mal war, also sehr auf den japanischen bzw. südkoreanischen Geschmack ausgelegt: bunt, grell, poppig, genki, kawaii. Alleine das zeigt, daß CherryPick von Misskey geforkt wurde, bevor Misskey gänzlich an den westlichen Geschmack angepaßt wurde.
Unklar, ob es Entwickler hat, die Englisch verstehen bzw. schreiben können; falls nicht, dann als Soft-Fork-Basis ungeeignet. Wäre ohne die Kommunikationsbarriere vermutlich der ultimative *key.
Mein letzter Stand: Bis auf eine Instanz im Großraum Washington, D.C. gibt es CherryPick-Instanzen nur in den Großräumen Tokyo und Seoul. War deshalb lange Zeit im westlichen Fediverse fast unbekannt. - FoundKey
Wohl der erste Forkey, der in PascalCase geschrieben wurde.
Meines Wissens direkter Soft-Fork von Misskey. Wird tatsächlich (oh Wunder) kleckerweise gepflegt, aber nicht für Instanzen mit mehr als 20 Nutzern empfohlen.
Ein paar andere *keys:- Hajkey
Soft-Fork von Calckey, der meines Wissens erst nach Firefish und dann nach Misskey rebased wurde. Wurde exklusiv nur für eine einzige Instanz entwickelt: transfem.social. Inzwischen eingestellt, weil wohl der Aufwand, so einen Wolpertinger nur für eine Instanz zu pflegen (man rebaset nicht mal eben von Firefish nach Misskey), zu groß war. transfem.social wurde entsprechend auf Sharkey umgestellt und ist da jetzt eine der größten Instanzen. - Neko
Soft-Fork von Misskey mit dem Ziel, es tauglich für Docker zu machen. Laut Repository nur für eine einzige Instanz gebaut. Ist nie released worden, was aber Wurscht ist, wenn es eh nur einen Admin als Zielgruppe hatte.git fetchkönnen Releases nämlich piepegal sein. - Meisskey
Japanischer Soft-Fork von Misskey von 2019 (!), der aber lange Zeit der Weiterentwicklung der Basis hinterherhinkte. Wird tatsächlich immer noch weiterentwickelt. - Leisskey
Wiederum japanischer Soft-Fork von Meisskey. Ist seit mindestens 2021 in Entwicklung, seit Februar 2023 aber eine ewige Beta, weil es seit damals keinen Release mehr gegeben hat. Dürfte zu den letzten noch in Entwicklung befindlichen "Forkeys 2. Grades" gehören. - Tanukey
Weiterer japanischer Soft-Fork von Misskey und daher so obskur im Westen, daß man schon die Websuche anstrengen muß, um das Repository zu finden (ist wohl im letzten Oktober von GitHub nach GitLab umgezogen). Noch ein Beispiel für *keys, bei denen selbst das Wissen über ihre Existenz Ostasien kaum je verlassen hat. - Backspacekey
Noch ein ambitionierter, aber eingeschlafener westlicher Misskey-Soft-Fork.
Siehe übrigens auch die Delightful Fediverse Experience: hier und hier.
Verglichen damit ist die Familie von Mistpark bis Forte schon wieder übersichtlich, vor allem, wenn die anderen mehreren Dutzend toten Forkeys mit dazugeholt werden. Immerhin stammt von Mistpark bis Forte über etwa 15 Jahre alles vom selben Schöpfer, der einfach nur sein eigenes Zeug geforkt hat.
#Long #LongPost #CWLong #CWLongPost #LangerPost #CWLangerPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Misskey #Forkey #Forkeys #Calckey #Firefish #Iceshrimp #IceshrimpJS #Iceshrimp.NET #Catodon #Sharkey #CherryPick #FoundKey #Hajkey #Neko #Meisskey #Leisskey #Tanukey #Backspacekey - Misskey
-
@「 Jürgen 」:fedi_mastodon: @crossgolf_rebel - kostenlose Kwalitätsposts @Don di Dislessia Soweit ich weiß, war es so (man möge mich wiederum korrigieren; kursiv sind die "Forkeys höheren Grades", die nicht von Misskey geforkt wurden):
- Misskey
Der Ursprung in Japan. - Calckey
Soft-Fork von Misskey mit einigen Extrafeatures.
Entwickler hatte irgendwann keine Zeit/keinen Bock mehr. - Firefish
Fortführung von Calckey unter neuem Management. Wurde aufgrund einer massiven Werbeaktion eines begeisterten Nutzers mit viel Reichweite so populär, daß der Name "Calckey" irgendwann einfach doof war und das ganze Ding eine neue Identität bekam.
Entwickler verschwand irgendwann sang- und klanglos von der Bildfläche. Nach einem halben Jahr stellte sich raus: Entwickler hatte wegen Abschlußarbeit usw. keine Zeit mehr, nicht mal, sich zu verabschieden.
Wurde unter neuer Führung mit neuem Repository und neuer Leuchtturminstanz weitergeführt, aber ohne neue Website. Wurde wieder eingestellt, weil es für eine einzige Entwicklerin viel zuviel war, die ganzen alten Co-Entwickler von Firefish alle zu Iceshrimp gewechselt waren und keine neuen Mitentwickler angeheuert werden konnten. - Iceshrimp
Fork von Firefish von ehemaligen Firefish-Entwicklern. Rebased nach Misskey, weil es auf Firefish nicht weiterging. Erklärtes Ziel war, Stabilität über Calckeys Featuritis zu stellen.
Weil Misskeys Codebase an sich einiges an grundsätzlichen Macken hatte, wurde beschlossen, es ist einfacher, das ganze Zeugs von Grund auf neu zu schreiben, als zu versuchen, das alles auszubügeln. Und bei der Gelegenheit wollte man von JavaScript (TypeScript und Vue.js) weg. Also hat man angefangen, das ganze Ding in C# neu zu schreiben als Iceshrimp.NET. Ziel ist featuremäßige Deckungsgleichheit mit dem bisherigen Iceshrimp und gleichzeitig Anpassung an Mastodon. Iceshrimp.NET ist noch sehr unfertig.
Bei der Gelegenheit wurde das alte Iceshrimp in Iceshrimp-JS umbenannt und in den Wartungsmodus versetzt = gibt keine Weiterentwicklung und keine neuen Features mehr, nur Sicherheitspatches und evtl. Bugfixes. - Catodon
Soft-Fork von Firefish. Ziel war, ein Forkey zu haben, das sich in der Bedienung wie Mastodon anfühlt. Quasi Mastodon-Fassade mit *key-Struktur dahinter. Also ein Forkey für den möglichst leichten Umstieg von Mastodon nach *key.
Wurde, als Firefish endgültig eingestellt wurde und damit die Basis tot war, nach Iceshrimp rebased.
Nachdem Iceshrimp zu Iceshrimp-JS wurde und in den Wartungsmodus ging, hatte Catodon ein Problem: Man kann nicht einfach von etwas, das in TypeScript und Vue.js geschrieben ist, nach etwas rebasen, das in C# geschrieben ist (Iceshrimp.NET). Und zur Weiterentwicklung wäre ein Rebase nötig gewesen, weil man jetzt wieder eine fast tote Basis hatte. Aber nach Misskey wollte man nicht (siehe Hajkey weiter unten), und Sharkey war einerseits zu mächtig und andererseits zu kapriziös.
Inzwischen gehen Catodon die Instanzen ein. Die meisten dürften geschlossen worden sein. - Sharkey
Soft-Fork von Misskey mit dem Ziel, so ziemlich alles, was je für Forkeys an Features entwickelt worden war, in einen einzigen Forkey zu packen und noch mehr obendrauf.
Quasi das Yang zu Iceshrimps Yin. Machte lange den Eindruck, als gingen Features über Zuverlässigkeit. Sharkeys Implementation der Mastodon Client API war schon regelrecht legendär schlecht, und alle hofften auf den Retter, der daherkommt und die Implementation von Grund auf neu schreibt, weil sie als unrettbar im Eimer galt. Inzwischen soll Sharkey seine Zuverlässigkeit im Griff haben, zumindest insofern, wie auch Misskey zuverlässig ist.
Die Entwickler haben eine zweifelhafte Reputation. Unter anderem haben sie Crowdfunding-Gelder für einen Sharkey-Server gesammelt und von dem Geld einen Minecraft-Server aufgezogen, aber keinen Sharkey-Server. Mitunter wird deshalb zum Boykott von Sharkey aufgerufen. - CherryPick
Südkoreanischer Soft-Fork von Misskey. Tatsächlich älter als Sharkey, mindestens von 2021, aber später wurde wohl einiges von Sharkey nach CherryPick portiert. Das Ziel war, einen stabilen und zuverlässigen Forkey zu haben ohne die Macken von Sharkey und sogar ohne die Macken von Misskey, der aber gleichzeitig gut Features hat. Das ist wohl sogar weitestgehend gelungen.
Vom ästhetischen Stil her so ähnlich, wie Misskey früher mal war, also sehr auf den japanischen bzw. südkoreanischen Geschmack ausgelegt: bunt, grell, poppig, genki, kawaii. Alleine das zeigt, daß CherryPick von Misskey geforkt wurde, bevor Misskey gänzlich an den westlichen Geschmack angepaßt wurde.
Unklar, ob es Entwickler hat, die Englisch verstehen bzw. schreiben können; falls nicht, dann als Soft-Fork-Basis ungeeignet. Wäre ohne die Kommunikationsbarriere vermutlich der ultimative *key.
Mein letzter Stand: Bis auf eine Instanz im Großraum Washington, D.C. gibt es CherryPick-Instanzen nur in den Großräumen Tokyo und Seoul. War deshalb lange Zeit im westlichen Fediverse fast unbekannt. - FoundKey
Wohl der erste Forkey, der in PascalCase geschrieben wurde.
Meines Wissens direkter Soft-Fork von Misskey. Wird tatsächlich (oh Wunder) kleckerweise gepflegt, aber nicht für Instanzen mit mehr als 20 Nutzern empfohlen.
Ein paar andere *keys:- Hajkey
Soft-Fork von Calckey, der meines Wissens erst nach Firefish und dann nach Misskey rebased wurde. Wurde exklusiv nur für eine einzige Instanz entwickelt: transfem.social. Inzwischen eingestellt, weil wohl der Aufwand, so einen Wolpertinger nur für eine Instanz zu pflegen (man rebaset nicht mal eben von Firefish nach Misskey), zu groß war. transfem.social wurde entsprechend auf Sharkey umgestellt und ist da jetzt eine der größten Instanzen. - Neko
Soft-Fork von Misskey mit dem Ziel, es tauglich für Docker zu machen. Laut Repository nur für eine einzige Instanz gebaut. Ist nie released worden, was aber Wurscht ist, wenn es eh nur einen Admin als Zielgruppe hatte.git fetchkönnen Releases nämlich piepegal sein. - Meisskey
Japanischer Soft-Fork von Misskey von 2019 (!), der aber lange Zeit der Weiterentwicklung der Basis hinterherhinkte. Wird tatsächlich immer noch weiterentwickelt. - Leisskey
Wiederum japanischer Soft-Fork von Meisskey. Ist seit mindestens 2021 in Entwicklung, seit Februar 2023 aber eine ewige Beta, weil es seit damals keinen Release mehr gegeben hat. Dürfte zu den letzten noch in Entwicklung befindlichen "Forkeys 2. Grades" gehören. - Tanukey
Weiterer japanischer Soft-Fork von Misskey und daher so obskur im Westen, daß man schon die Websuche anstrengen muß, um das Repository zu finden (ist wohl im letzten Oktober von GitHub nach GitLab umgezogen). Noch ein Beispiel für *keys, bei denen selbst das Wissen über ihre Existenz Ostasien kaum je verlassen hat. - Backspacekey
Noch ein ambitionierter, aber eingeschlafener westlicher Misskey-Soft-Fork.
Siehe übrigens auch die Delightful Fediverse Experience: hier und hier.
Verglichen damit ist die Familie von Mistpark bis Forte schon wieder übersichtlich, vor allem, wenn die anderen mehreren Dutzend toten Forkeys mit dazugeholt werden. Immerhin stammt von Mistpark bis Forte über etwa 15 Jahre alles vom selben Schöpfer, der einfach nur sein eigenes Zeug geforkt hat.
#Long #LongPost #CWLong #CWLongPost #LangerPost #CWLangerPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Misskey #Forkey #Forkeys #Calckey #Firefish #Iceshrimp #IceshrimpJS #Iceshrimp.NET #Catodon #Sharkey #CherryPick #FoundKey #Hajkey #Neko #Meisskey #Leisskey #Tanukey #Backspacekey - Misskey
-
@「 Jürgen 」:fedi_mastodon: @crossgolf_rebel - kostenlose Kwalitätsposts @Don di Dislessia Soweit ich weiß, war es so (man möge mich wiederum korrigieren; kursiv sind die "Forkeys höheren Grades", die nicht von Misskey geforkt wurden):
- Misskey
Der Ursprung in Japan. - Calckey
Soft-Fork von Misskey mit einigen Extrafeatures.
Entwickler hatte irgendwann keine Zeit/keinen Bock mehr. - Firefish
Fortführung von Calckey unter neuem Management. Wurde aufgrund einer massiven Werbeaktion eines begeisterten Nutzers mit viel Reichweite so populär, daß der Name "Calckey" irgendwann einfach doof war und das ganze Ding eine neue Identität bekam.
Entwickler verschwand irgendwann sang- und klanglos von der Bildfläche. Nach einem halben Jahr stellte sich raus: Entwickler hatte wegen Abschlußarbeit usw. keine Zeit mehr, nicht mal, sich zu verabschieden.
Wurde unter neuer Führung mit neuem Repository und neuer Leuchtturminstanz weitergeführt, aber ohne neue Website. Wurde wieder eingestellt, weil es für eine einzige Entwicklerin viel zuviel war, die ganzen alten Co-Entwickler von Firefish alle zu Iceshrimp gewechselt waren und keine neuen Mitentwickler angeheuert werden konnten. - Iceshrimp
Fork von Firefish von ehemaligen Firefish-Entwicklern. Rebased nach Misskey, weil es auf Firefish nicht weiterging. Erklärtes Ziel war, Stabilität über Calckeys Featuritis zu stellen.
Weil Misskeys Codebase an sich einiges an grundsätzlichen Macken hatte, wurde beschlossen, es ist einfacher, das ganze Zeugs von Grund auf neu zu schreiben, als zu versuchen, das alles auszubügeln. Und bei der Gelegenheit wollte man von JavaScript (TypeScript und Vue.js) weg. Also hat man angefangen, das ganze Ding in C# neu zu schreiben als Iceshrimp.NET. Ziel ist featuremäßige Deckungsgleichheit mit dem bisherigen Iceshrimp und gleichzeitig Anpassung an Mastodon. Iceshrimp.NET ist noch sehr unfertig.
Bei der Gelegenheit wurde das alte Iceshrimp in Iceshrimp-JS umbenannt und in den Wartungsmodus versetzt = gibt keine Weiterentwicklung und keine neuen Features mehr, nur Sicherheitspatches und evtl. Bugfixes. - Catodon
Soft-Fork von Firefish. Ziel war, ein Forkey zu haben, das sich in der Bedienung wie Mastodon anfühlt. Quasi Mastodon-Fassade mit *key-Struktur dahinter. Also ein Forkey für den möglichst leichten Umstieg von Mastodon nach *key.
Wurde, als Firefish endgültig eingestellt wurde und damit die Basis tot war, nach Iceshrimp rebased.
Nachdem Iceshrimp zu Iceshrimp-JS wurde und in den Wartungsmodus ging, hatte Catodon ein Problem: Man kann nicht einfach von etwas, das in TypeScript und Vue.js geschrieben ist, nach etwas rebasen, das in C# geschrieben ist (Iceshrimp.NET). Und zur Weiterentwicklung wäre ein Rebase nötig gewesen, weil man jetzt wieder eine fast tote Basis hatte. Aber nach Misskey wollte man nicht (siehe Hajkey weiter unten), und Sharkey war einerseits zu mächtig und andererseits zu kapriziös.
Inzwischen gehen Catodon die Instanzen ein. Die meisten dürften geschlossen worden sein. - Sharkey
Soft-Fork von Misskey mit dem Ziel, so ziemlich alles, was je für Forkeys an Features entwickelt worden war, in einen einzigen Forkey zu packen und noch mehr obendrauf.
Quasi das Yang zu Iceshrimps Yin. Machte lange den Eindruck, als gingen Features über Zuverlässigkeit. Sharkeys Implementation der Mastodon Client API war schon regelrecht legendär schlecht, und alle hofften auf den Retter, der daherkommt und die Implementation von Grund auf neu schreibt, weil sie als unrettbar im Eimer galt. Inzwischen soll Sharkey seine Zuverlässigkeit im Griff haben, zumindest insofern, wie auch Misskey zuverlässig ist.
Die Entwickler haben eine zweifelhafte Reputation. Unter anderem haben sie Crowdfunding-Gelder für einen Sharkey-Server gesammelt und von dem Geld einen Minecraft-Server aufgezogen, aber keinen Sharkey-Server. Mitunter wird deshalb zum Boykott von Sharkey aufgerufen. - CherryPick
Südkoreanischer Soft-Fork von Misskey. Tatsächlich älter als Sharkey, mindestens von 2021, aber später wurde wohl einiges von Sharkey nach CherryPick portiert. Das Ziel war, einen stabilen und zuverlässigen Forkey zu haben ohne die Macken von Sharkey und sogar ohne die Macken von Misskey, der aber gleichzeitig gut Features hat. Das ist wohl sogar weitestgehend gelungen.
Vom ästhetischen Stil her so ähnlich, wie Misskey früher mal war, also sehr auf den japanischen bzw. südkoreanischen Geschmack ausgelegt: bunt, grell, poppig, genki, kawaii. Alleine das zeigt, daß CherryPick von Misskey geforkt wurde, bevor Misskey gänzlich an den westlichen Geschmack angepaßt wurde.
Unklar, ob es Entwickler hat, die Englisch verstehen bzw. schreiben können; falls nicht, dann als Soft-Fork-Basis ungeeignet. Wäre ohne die Kommunikationsbarriere vermutlich der ultimative *key.
Mein letzter Stand: Bis auf eine Instanz im Großraum Washington, D.C. gibt es CherryPick-Instanzen nur in den Großräumen Tokyo und Seoul. War deshalb lange Zeit im westlichen Fediverse fast unbekannt. - FoundKey
Wohl der erste Forkey, der in PascalCase geschrieben wurde.
Meines Wissens direkter Soft-Fork von Misskey. Wird tatsächlich (oh Wunder) kleckerweise gepflegt, aber nicht für Instanzen mit mehr als 20 Nutzern empfohlen.
Ein paar andere *keys:- Hajkey
Soft-Fork von Calckey, der meines Wissens erst nach Firefish und dann nach Misskey rebased wurde. Wurde exklusiv nur für eine einzige Instanz entwickelt: transfem.social. Inzwischen eingestellt, weil wohl der Aufwand, so einen Wolpertinger nur für eine Instanz zu pflegen (man rebaset nicht mal eben von Firefish nach Misskey), zu groß war. transfem.social wurde entsprechend auf Sharkey umgestellt und ist da jetzt eine der größten Instanzen. - Neko
Soft-Fork von Misskey mit dem Ziel, es tauglich für Docker zu machen. Laut Repository nur für eine einzige Instanz gebaut. Ist nie released worden, was aber Wurscht ist, wenn es eh nur einen Admin als Zielgruppe hatte.git fetchkönnen Releases nämlich piepegal sein. - Meisskey
Japanischer Soft-Fork von Misskey von 2019 (!), der aber lange Zeit der Weiterentwicklung der Basis hinterherhinkte. Wird tatsächlich immer noch weiterentwickelt. - Leisskey
Wiederum japanischer Soft-Fork von Meisskey. Ist seit mindestens 2021 in Entwicklung, seit Februar 2023 aber eine ewige Beta, weil es seit damals keinen Release mehr gegeben hat. Dürfte zu den letzten noch in Entwicklung befindlichen "Forkeys 2. Grades" gehören. - Tanukey
Weiterer japanischer Soft-Fork von Misskey und daher so obskur im Westen, daß man schon die Websuche anstrengen muß, um das Repository zu finden (ist wohl im letzten Oktober von GitHub nach GitLab umgezogen). Noch ein Beispiel für *keys, bei denen selbst das Wissen über ihre Existenz Ostasien kaum je verlassen hat. - Backspacekey
Noch ein ambitionierter, aber eingeschlafener westlicher Misskey-Soft-Fork.
Siehe übrigens auch die Delightful Fediverse Experience: hier und hier.
Verglichen damit ist die Familie von Mistpark bis Forte schon wieder übersichtlich, vor allem, wenn die anderen mehreren Dutzend toten Forkeys mit dazugeholt werden. Immerhin stammt von Mistpark bis Forte über etwa 15 Jahre alles vom selben Schöpfer, der einfach nur sein eigenes Zeug geforkt hat.
#Long #LongPost #CWLong #CWLongPost #LangerPost #CWLangerPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Misskey #Forkey #Forkeys #Calckey #Firefish #Iceshrimp #IceshrimpJS #Iceshrimp.NET #Catodon #Sharkey #CherryPick #FoundKey #Hajkey #Neko #Meisskey #Leisskey #Tanukey #Backspacekey - Misskey
-
Misskey und Derivate, steigt ihr da durch?
Ich hab mal versucht herauszufinden wie sich das mit Misskey, Foundkey, Calckey, Firefish, Sharkey, Iceshrimp und Iceshrimp.NET verhält. Gerne korrigieren.
Misskey ist wohl der Ursprung und immer noch sehr aktiv in der Entwicklung. ✅
Foundkey ein früher Fork von Misskey, mittlerweile eingestellt. ❌
Calckey ein Fork von Foundkey, scheinbar auch nicht mehr aktiv weiterentwickelt. ❌
Firefish war dann wohl irgendwann ein neuer Name von Calckey. Wurde ebenfalls 2023 aufgelöst durch den Hauptentwickler. ❌
Iceshrimp war dann wohl wiederum ein Fork von Firefish. Es kommen scheinbar keine neuen Features mehr, da das Team sich auf eine Neuimplementierung mit .NET konzentriert (Iceshrimp.NET). 🟡
Firefish (neu) kurzes Aufbäumen des Firefish Projekts, Seti 2024 keine weiteren Commits mehr im Git Repository. ❌
Sharkey ein Fork des neuen Firefish, wohl das einzige Projekt neben Misskey, das noch aktiv weiterentwickelt wird (Iceshrimp.NET hat keine gemeinsame Codebasis mit Misskey mehr). ✅
Irgendwie schade, dass so viele enthusiastische Entwickler es nicht fertig bringen über eine längere Zeit gemeinsam an einer Variante zu arbeiten 😭.
-
Misskey und Derivate, steigt ihr da durch?
Ich hab mal versucht herauszufinden wie sich das mit Misskey, Foundkey, Calckey, Firefish, Sharkey, Iceshrimp und Iceshrimp.NET verhält. Gerne korrigieren.
Misskey ist wohl der Ursprung und immer noch sehr aktiv in der Entwicklung. ✅
Foundkey ein früher Fork von Misskey, mittlerweile eingestellt. ❌
Calckey ein Fork von Foundkey, scheinbar auch nicht mehr aktiv weiterentwickelt. ❌
Firefish war dann wohl irgendwann ein neuer Name von Calckey. Wurde ebenfalls 2023 aufgelöst durch den Hauptentwickler. ❌
Iceshrimp war dann wohl wiederum ein Fork von Firefish. Es kommen scheinbar keine neuen Features mehr, da das Team sich auf eine Neuimplementierung mit .NET konzentriert (Iceshrimp.NET). 🟡
Firefish (neu) kurzes Aufbäumen des Firefish Projekts, Seti 2024 keine weiteren Commits mehr im Git Repository. ❌
Sharkey ein Fork des neuen Firefish, wohl das einzige Projekt neben Misskey, das noch aktiv weiterentwickelt wird (Iceshrimp.NET hat keine gemeinsame Codebasis mit Misskey mehr). ✅
Irgendwie schade, dass so viele enthusiastische Entwickler es nicht fertig bringen über eine längere Zeit gemeinsam an einer Variante zu arbeiten 😭.
-
Misskey und Derivate, steigt ihr da durch?
Ich hab mal versucht herauszufinden wie sich das mit Misskey, Foundkey, Calckey, Firefish, Sharkey, Iceshrimp und Iceshrimp.NET verhält. Gerne korrigieren.
Misskey ist wohl der Ursprung und immer noch sehr aktiv in der Entwicklung. ✅
Foundkey ein früher Fork von Misskey, mittlerweile eingestellt. ❌
Calckey ein Fork von Foundkey, scheinbar auch nicht mehr aktiv weiterentwickelt. ❌
Firefish war dann wohl irgendwann ein neuer Name von Calckey. Wurde ebenfalls 2023 aufgelöst durch den Hauptentwickler. ❌
Iceshrimp war dann wohl wiederum ein Fork von Firefish. Es kommen scheinbar keine neuen Features mehr, da das Team sich auf eine Neuimplementierung mit .NET konzentriert (Iceshrimp.NET). 🟡
Firefish (neu) kurzes Aufbäumen des Firefish Projekts, Seti 2024 keine weiteren Commits mehr im Git Repository. ❌
Sharkey ein Fork des neuen Firefish, wohl das einzige Projekt neben Misskey, das noch aktiv weiterentwickelt wird (Iceshrimp.NET hat keine gemeinsame Codebasis mit Misskey mehr). ✅
Irgendwie schade, dass so viele enthusiastische Entwickler es nicht fertig bringen über eine längere Zeit gemeinsam an einer Variante zu arbeiten 😭.
-
Misskey und Derivate, steigt ihr da durch?
Ich hab mal versucht herauszufinden wie sich das mit Misskey, Foundkey, Calckey, Firefish, Sharkey, Iceshrimp und Iceshrimp.NET verhält. Gerne korrigieren.
Misskey ist wohl der Ursprung und immer noch sehr aktiv in der Entwicklung. ✅
Foundkey ein früher Fork von Misskey, mittlerweile eingestellt. ❌
Calckey ein Fork von Foundkey, scheinbar auch nicht mehr aktiv weiterentwickelt. ❌
Firefish war dann wohl irgendwann ein neuer Name von Calckey. Wurde ebenfalls 2023 aufgelöst durch den Hauptentwickler. ❌
Iceshrimp war dann wohl wiederum ein Fork von Firefish. Es kommen scheinbar keine neuen Features mehr, da das Team sich auf eine Neuimplementierung mit .NET konzentriert (Iceshrimp.NET). 🟡
Firefish (neu) kurzes Aufbäumen des Firefish Projekts, Seti 2024 keine weiteren Commits mehr im Git Repository. ❌
Sharkey ein Fork des neuen Firefish, wohl das einzige Projekt neben Misskey, das noch aktiv weiterentwickelt wird (Iceshrimp.NET hat keine gemeinsame Codebasis mit Misskey mehr). ✅
Irgendwie schade, dass so viele enthusiastische Entwickler es nicht fertig bringen über eine längere Zeit gemeinsam an einer Variante zu arbeiten 😭.
-
Misskey und Derivate, steigt ihr da durch?
Ich hab mal versucht herauszufinden wie sich das mit Misskey, Foundkey, Calckey, Firefish, Sharkey, Iceshrimp und Iceshrimp.NET verhält. Gerne korrigieren.
Misskey ist wohl der Ursprung und immer noch sehr aktiv in der Entwicklung. ✅
Foundkey ein früher Fork von Misskey, mittlerweile eingestellt. ❌
Calckey ein Fork von Foundkey, scheinbar auch nicht mehr aktiv weiterentwickelt. ❌
Firefish war dann wohl irgendwann ein neuer Name von Calckey. Wurde ebenfalls 2023 aufgelöst durch den Hauptentwickler. ❌
Iceshrimp war dann wohl wiederum ein Fork von Firefish. Es kommen scheinbar keine neuen Features mehr, da das Team sich auf eine Neuimplementierung mit .NET konzentriert (Iceshrimp.NET). 🟡
Firefish (neu) kurzes Aufbäumen des Firefish Projekts, Seti 2024 keine weiteren Commits mehr im Git Repository. ❌
Sharkey ein Fork des neuen Firefish, wohl das einzige Projekt neben Misskey, das noch aktiv weiterentwickelt wird (Iceshrimp.NET hat keine gemeinsame Codebasis mit Misskey mehr). ✅
Irgendwie schade, dass so viele enthusiastische Entwickler es nicht fertig bringen über eine längere Zeit gemeinsam an einer Variante zu arbeiten 😭.
-
Schön das ihr alle mit mir auf Calckey seid 🥰
Hier noch mal die Auswahl an Bilder im Beitrag.
Und liebe user mit Mastodon, es sind mehr als 4
#polarlicht #AureaBorealis #northernlights #Calckey -
Juten Morjen die 2.
Lieb Freunde auf Calckey, ich habe ein paar Bilder in eine Galerie gepack, vom Polarlicht heute Nacht.
Viel Spaß damit, die sollten nicht komprimiert sein 😉
Schön das ihr alle mit mir auf Calckey seid 🥰
https://moppels.bar/gallery/ahppzny2y113t5bg
hmm, komisch. Euer Mastodon kann die Galerie gar nicht anzeigen....?
#polarlicht #AureaBorealis #northernlights #Calckey