#forkey — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #forkey, aggregated by home.social.
-
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 -
@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
-
CW: Why Sharkey fails to render hashtags from Friendica, Hubzilla & Co. properly, and how long this bug has been known already; CW: long (over 6,600 characters), Fediverse meta, Fediverse-beyond-Mastodon meta
So there's that nasty bug on Sharkey that mangles hashtags in messages from Hubzilla and probably also Friendica, (streams) and Forte. They always look like this:
#[Hashtag](https://hub.netzgemeinde.eu/search?tag=Hashtag)
Basically, Sharkey receives fully standard Rich Text from Hubzilla. It manages to convert this Rich Text into its own Misskey-Flavored Markdown. But then its Markdown parser does not parse it and leaves the Markdown code visible to everyone. It simply doesn't expect there to be a hashtag character in front of an embedded link because, seriously, who'd ever do that and why?!
Friendica would. In fact, Friendica does. It puts the hashtag character in front of the tag, as in outside the tag, as opposed to at the beginning of the tag. It has been doing that since its beginnings in 2010 because it was designed from the get-go to also federate with StatusNet from 2008. And StatusNet does hashtags the same way on its few remaining servers. In fact, so did Identi.ca from 2008, from which StatusNet emerged.
Hubzilla, (streams) and Forte do it, too, because they have inherited it from Friendica.
On StatusNet, Friendica, Hubzilla, (streams) and Forte, a hashtag in a message looks like this:
#Hashtag
Notice how the hashtag character has the same colour as the rest of the post text. And not the same colour as the rest of the hashtag. This means that the hashtag character is not part of the link. (To Mastodon users who don't know this: If something in a "toot" has a different colour from the rest of the "toot", it's a link. Even if it doesn't show a URL in plain sight.)
On 𝕏, Mastodon, Pleroma, Akkoma, Misskey, the various Forkeys and a whole lot of other Fediverse software, a hashtag in a message looks like this:
#Hashtag
Notice how now the hashtag character has the same colour as the rest of the hashtag. This means that the hashtag character is part of the link.
But why did Identi.ca do hashtags differently from Twitter? Because Identi.ca did hashtags before Twitter. AFAIK, when Identi.ca was launched, it had support for hashtags right away. About one year before Twitter.
The hashtag itself had already been invented by the Twitter community. Chris Messina had already codified it in 2007. But it wasn't until 2009 that Twitter actually introduced a technological implementation to support it.
Again, Identi.ca must have had hashtags as early as 2008, and there was no way that Identi.ca creator Evan Prodromou could possibly predict what Twitter would do the following year. So he did what he thought was right and what actually made sense to him.
But nowadays, everybody "knows" that Twitter had the world's very first hashtag implementation ever because nobody, even in the Fediverse, has ever heard of Identi.ca. I mean, the majority of Fediverse users "know" that the Fediverse started with Mastodon.
You know, just like Officer James Barrett "knew" that there is no intelligent life outside Earth only a few minutes before he became Agent J of the Men In Black.
This is also why just about all Fediverse software that does hashtags the Twitter way expects everything to do hashtags the Twitter way. It does not expect hashtags to be done differently. And when a message comes in from Friendica, Hubzilla, (streams) or Forte with hashtags in it, it fails at varying degrees of ungracefully.
Hashtags with the hashtag character outside the link are older than hashtags with the hashtag character inside that they're not only completely unexpected, that they cause software to malfunction, but the same software often can't even handle that malfunction. It's a miracle that the Friendica/Hubzilla family doesn't cause Fediverse servers to crash or even server databases to go corrupt by simply sending hashtags.
Mastodon used to be an exception of sorts, but only because, before version 4.0 from October, 2022, its HTML "sanitiser" actually ripped out any and all rich text code from incoming messages and left nothing but plain text behind. And then it didn't recognise hashtags in messages from outside Mastodon as hashtags at all.
When Mastodon 4.0 came and supported some rich text, including embedded links, it went haywire, of course. But then someone from Friendica and Hubzilla went in and complained about this malfunction and explained what happened, why it happened and why it was not Friendica and Hubzilla that did things wrong. Besides, if something utterly defaces "toots", then Mastodon developers do step in to stop it. After all, Mastodon has a few more of them at hand, paid, full-time professionals even. You have to give it that.
Which takes us back to Sharkey. Sharkey is developed by a small handful of individuals in their spare time. Granted, it's a soft fork of Misskey, so a lot of development work is done by the Misskey devs and taken over by the Sharkey devs, but they still have to weave the code changes coming from Misskey in and make them work with what's different on Sharkey.
So it turned out that (Link content warning: eye contact) this bug has already been filed to the Sharkey devs in October, 2024. All that has happened since then until today was that Hazelnoot added two labels. But the bug report came with no explanations. In fact, it misattributed one of my Hubzilla posts as a Friendica post.
And in fact, it turned out that this is actually (Link content warning: Microsoft GitHub link, eye contact) a Misskey bug which has been filed in January, 2024, two years ago. The bug report is a bit more elaborate, but the reporter still knew precious little about what's going on. So I wrote a comment in which I explained the bug from a Friendica/Hubzilla POV as well as what's going on on the technical side, and why the error has to be on Misskey's side.
I hope this will finally help get the bug fixed. Unfortunately, this fix would come too late for Iceshrimp. Iceshrimp-JS is a true Forkey, but in maintenance mode, so I guess only security patches and critical bugfixes will be merged from Misskey, if anything. And Iceshrimp.NET is a complete rewrite of a pre-this-fix Misskey fork, so the Iceshrimp devs probably don't know about this issue either. If it fails ungracefully upon receiving hashtags with the hashtag character outside, it will require its own bug report.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Hashtag #Hashtags #HashtagMeta #CWHashtagMeta #Twitter #𝕏 #Fediverse #Mastodon #Pleroma #Akkoma #Misskey #Forkey #Forkeys #Sharkey #Iceshrimp #Iceshrimp-JS #Iceshrimp.NET #Identi.ca #Laconi.ca #StatusNet #Friendica #Hubzilla #Streams #(streams) #Forte -
CW: Why Sharkey fails to render hashtags from Friendica, Hubzilla & Co. properly, and how long this bug has been known already; CW: long (over 6,600 characters), Fediverse meta, Fediverse-beyond-Mastodon meta
So there's that nasty bug on Sharkey that mangles hashtags in messages from Hubzilla and probably also Friendica, (streams) and Forte. They always look like this:
#[Hashtag](https://hub.netzgemeinde.eu/search?tag=Hashtag)
Basically, Sharkey receives fully standard Rich Text from Hubzilla. It manages to convert this Rich Text into its own Misskey-Flavored Markdown. But then its Markdown parser does not parse it and leaves the Markdown code visible to everyone. It simply doesn't expect there to be a hashtag character in front of an embedded link because, seriously, who'd ever do that and why?!
Friendica would. In fact, Friendica does. It puts the hashtag character in front of the tag, as in outside the tag, as opposed to at the beginning of the tag. It has been doing that since its beginnings in 2010 because it was designed from the get-go to also federate with StatusNet from 2008. And StatusNet does hashtags the same way on its few remaining servers. In fact, so did Identi.ca from 2008, from which StatusNet emerged.
Hubzilla, (streams) and Forte do it, too, because they have inherited it from Friendica.
On StatusNet, Friendica, Hubzilla, (streams) and Forte, a hashtag in a message looks like this:
#Hashtag
Notice how the hashtag character has the same colour as the rest of the post text. And not the same colour as the rest of the hashtag. This means that the hashtag character is not part of the link. (To Mastodon users who don't know this: If something in a "toot" has a different colour from the rest of the "toot", it's a link. Even if it doesn't show a URL in plain sight.)
On 𝕏, Mastodon, Pleroma, Akkoma, Misskey, the various Forkeys and a whole lot of other Fediverse software, a hashtag in a message looks like this:
#Hashtag
Notice how now the hashtag character has the same colour as the rest of the hashtag. This means that the hashtag character is part of the link.
But why did Identi.ca do hashtags differently from Twitter? Because Identi.ca did hashtags before Twitter. AFAIK, when Identi.ca was launched, it had support for hashtags right away. About one year before Twitter.
The hashtag itself had already been invented by the Twitter community. Chris Messina had already codified it in 2007. But it wasn't until 2009 that Twitter actually introduced a technological implementation to support it.
Again, Identi.ca must have had hashtags as early as 2008, and there was no way that Identi.ca creator Evan Prodromou could possibly predict what Twitter would do the following year. So he did what he thought was right and what actually made sense to him.
But nowadays, everybody "knows" that Twitter had the world's very first hashtag implementation ever because nobody, even in the Fediverse, has ever heard of Identi.ca. I mean, the majority of Fediverse users "know" that the Fediverse started with Mastodon.
You know, just like Officer James Barrett "knew" that there is no intelligent life outside Earth only a few minutes before he became Agent J of the Men In Black.
This is also why just about all Fediverse software that does hashtags the Twitter way expects everything to do hashtags the Twitter way. It does not expect hashtags to be done differently. And when a message comes in from Friendica, Hubzilla, (streams) or Forte with hashtags in it, it fails at varying degrees of ungracefully.
Hashtags with the hashtag character outside the link are older than hashtags with the hashtag character inside that they're not only completely unexpected, that they cause software to malfunction, but the same software often can't even handle that malfunction. It's a miracle that the Friendica/Hubzilla family doesn't cause Fediverse servers to crash or even server databases to go corrupt by simply sending hashtags.
Mastodon used to be an exception of sorts, but only because, before version 4.0 from October, 2022, its HTML "sanitiser" actually ripped out any and all rich text code from incoming messages and left nothing but plain text behind. And then it didn't recognise hashtags in messages from outside Mastodon as hashtags at all.
When Mastodon 4.0 came and supported some rich text, including embedded links, it went haywire, of course. But then someone from Friendica and Hubzilla went in and complained about this malfunction and explained what happened, why it happened and why it was not Friendica and Hubzilla that did things wrong. Besides, if something utterly defaces "toots", then Mastodon developers do step in to stop it. After all, Mastodon has a few more of them at hand, paid, full-time professionals even. You have to give it that.
Which takes us back to Sharkey. Sharkey is developed by a small handful of individuals in their spare time. Granted, it's a soft fork of Misskey, so a lot of development work is done by the Misskey devs and taken over by the Sharkey devs, but they still have to weave the code changes coming from Misskey in and make them work with what's different on Sharkey.
So it turned out that (Link content warning: eye contact) this bug has already been filed to the Sharkey devs in October, 2024. All that has happened since then until today was that Hazelnoot added two labels. But the bug report came with no explanations. In fact, it misattributed one of my Hubzilla posts as a Friendica post.
And in fact, it turned out that this is actually (Link content warning: Microsoft GitHub link, eye contact) a Misskey bug which has been filed in January, 2024, two years ago. The bug report is a bit more elaborate, but the reporter still knew precious little about what's going on. So I wrote a comment in which I explained the bug from a Friendica/Hubzilla POV as well as what's going on on the technical side, and why the error has to be on Misskey's side.
I hope this will finally help get the bug fixed. Unfortunately, this fix would come too late for Iceshrimp. Iceshrimp-JS is a true Forkey, but in maintenance mode, so I guess only security patches and critical bugfixes will be merged from Misskey, if anything. And Iceshrimp.NET is a complete rewrite of a pre-this-fix Misskey fork, so the Iceshrimp devs probably don't know about this issue either. If it fails ungracefully upon receiving hashtags with the hashtag character outside, it will require its own bug report.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Hashtag #Hashtags #HashtagMeta #CWHashtagMeta #Twitter #𝕏 #Fediverse #Mastodon #Pleroma #Akkoma #Misskey #Forkey #Forkeys #Sharkey #Iceshrimp #Iceshrimp-JS #Iceshrimp.NET #Identi.ca #Laconi.ca #StatusNet #Friendica #Hubzilla #Streams #(streams) #Forte -
CW: Why Sharkey fails to render hashtags from Friendica, Hubzilla & Co. properly, and how long this bug has been known already; CW: long (over 6,600 characters), Fediverse meta, Fediverse-beyond-Mastodon meta
So there's that nasty bug on Sharkey that mangles hashtags in messages from Hubzilla and probably also Friendica, (streams) and Forte. They always look like this:
#[Hashtag](https://hub.netzgemeinde.eu/search?tag=Hashtag)
Basically, Sharkey receives fully standard Rich Text from Hubzilla. It manages to convert this Rich Text into its own Misskey-Flavored Markdown. But then its Markdown parser does not parse it and leaves the Markdown code visible to everyone. It simply doesn't expect there to be a hashtag character in front of an embedded link because, seriously, who'd ever do that and why?!
Friendica would. In fact, Friendica does. It puts the hashtag character in front of the tag, as in outside the tag, as opposed to at the beginning of the tag. It has been doing that since its beginnings in 2010 because it was designed from the get-go to also federate with StatusNet from 2008. And StatusNet does hashtags the same way on its few remaining servers. In fact, so did Identi.ca from 2008, from which StatusNet emerged.
Hubzilla, (streams) and Forte do it, too, because they have inherited it from Friendica.
On StatusNet, Friendica, Hubzilla, (streams) and Forte, a hashtag in a message looks like this:
#Hashtag
Notice how the hashtag character has the same colour as the rest of the post text. And not the same colour as the rest of the hashtag. This means that the hashtag character is not part of the link. (To Mastodon users who don't know this: If something in a "toot" has a different colour from the rest of the "toot", it's a link. Even if it doesn't show a URL in plain sight.)
On 𝕏, Mastodon, Pleroma, Akkoma, Misskey, the various Forkeys and a whole lot of other Fediverse software, a hashtag in a message looks like this:
#Hashtag
Notice how now the hashtag character has the same colour as the rest of the hashtag. This means that the hashtag character is part of the link.
But why did Identi.ca do hashtags differently from Twitter? Because Identi.ca did hashtags before Twitter. AFAIK, when Identi.ca was launched, it had support for hashtags right away. About one year before Twitter.
The hashtag itself had already been invented by the Twitter community. Chris Messina had already codified it in 2007. But it wasn't until 2009 that Twitter actually introduced a technological implementation to support it.
Again, Identi.ca must have had hashtags as early as 2008, and there was no way that Identi.ca creator Evan Prodromou could possibly predict what Twitter would do the following year. So he did what he thought was right and what actually made sense to him.
But nowadays, everybody "knows" that Twitter had the world's very first hashtag implementation ever because nobody, even in the Fediverse, has ever heard of Identi.ca. I mean, the majority of Fediverse users "know" that the Fediverse started with Mastodon.
You know, just like Officer James Barrett "knew" that there is no intelligent life outside Earth only a few minutes before he became Agent J of the Men In Black.
This is also why just about all Fediverse software that does hashtags the Twitter way expects everything to do hashtags the Twitter way. It does not expect hashtags to be done differently. And when a message comes in from Friendica, Hubzilla, (streams) or Forte with hashtags in it, it fails at varying degrees of ungracefully.
Hashtags with the hashtag character outside the link are older than hashtags with the hashtag character inside that they're not only completely unexpected, that they cause software to malfunction, but the same software often can't even handle that malfunction. It's a miracle that the Friendica/Hubzilla family doesn't cause Fediverse servers to crash or even server databases to go corrupt by simply sending hashtags.
Mastodon used to be an exception of sorts, but only because, before version 4.0 from October, 2022, its HTML "sanitiser" actually ripped out any and all rich text code from incoming messages and left nothing but plain text behind. And then it didn't recognise hashtags in messages from outside Mastodon as hashtags at all.
When Mastodon 4.0 came and supported some rich text, including embedded links, it went haywire, of course. But then someone from Friendica and Hubzilla went in and complained about this malfunction and explained what happened, why it happened and why it was not Friendica and Hubzilla that did things wrong. Besides, if something utterly defaces "toots", then Mastodon developers do step in to stop it. After all, Mastodon has a few more of them at hand, paid, full-time professionals even. You have to give it that.
Which takes us back to Sharkey. Sharkey is developed by a small handful of individuals in their spare time. Granted, it's a soft fork of Misskey, so a lot of development work is done by the Misskey devs and taken over by the Sharkey devs, but they still have to weave the code changes coming from Misskey in and make them work with what's different on Sharkey.
So it turned out that (Link content warning: eye contact) this bug has already been filed to the Sharkey devs in October, 2024. All that has happened since then until today was that Hazelnoot added two labels. But the bug report came with no explanations. In fact, it misattributed one of my Hubzilla posts as a Friendica post.
And in fact, it turned out that this is actually (Link content warning: Microsoft GitHub link, eye contact) a Misskey bug which has been filed in January, 2024, two years ago. The bug report is a bit more elaborate, but the reporter still knew precious little about what's going on. So I wrote a comment in which I explained the bug from a Friendica/Hubzilla POV as well as what's going on on the technical side, and why the error has to be on Misskey's side.
I hope this will finally help get the bug fixed. Unfortunately, this fix would come too late for Iceshrimp. Iceshrimp-JS is a true Forkey, but in maintenance mode, so I guess only security patches and critical bugfixes will be merged from Misskey, if anything. And Iceshrimp.NET is a complete rewrite of a pre-this-fix Misskey fork, so the Iceshrimp devs probably don't know about this issue either. If it fails ungracefully upon receiving hashtags with the hashtag character outside, it will require its own bug report.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Hashtag #Hashtags #HashtagMeta #CWHashtagMeta #Twitter #𝕏 #Fediverse #Mastodon #Pleroma #Akkoma #Misskey #Forkey #Forkeys #Sharkey #Iceshrimp #Iceshrimp-JS #Iceshrimp.NET #Identi.ca #Laconi.ca #StatusNet #Friendica #Hubzilla #Streams #(streams) #Forte -
CW: Why Sharkey fails to render hashtags from Friendica, Hubzilla & Co. properly, and how long this bug has been known already; CW: long (over 6,600 characters), Fediverse meta, Fediverse-beyond-Mastodon meta
So there's that nasty bug on Sharkey that mangles hashtags in messages from Hubzilla and probably also Friendica, (streams) and Forte. They always look like this:
#[Hashtag](https://hub.netzgemeinde.eu/search?tag=Hashtag)
Basically, Sharkey receives fully standard Rich Text from Hubzilla. It manages to convert this Rich Text into its own Misskey-Flavored Markdown. But then its Markdown parser does not parse it and leaves the Markdown code visible to everyone. It simply doesn't expect there to be a hashtag character in front of an embedded link because, seriously, who'd ever do that and why?!
Friendica would. In fact, Friendica does. It puts the hashtag character in front of the tag, as in outside the tag, as opposed to at the beginning of the tag. It has been doing that since its beginnings in 2010 because it was designed from the get-go to also federate with StatusNet from 2008. And StatusNet does hashtags the same way on its few remaining servers. In fact, so did Identi.ca from 2008, from which StatusNet emerged.
Hubzilla, (streams) and Forte do it, too, because they have inherited it from Friendica.
On StatusNet, Friendica, Hubzilla, (streams) and Forte, a hashtag in a message looks like this:
#Hashtag
Notice how the hashtag character has the same colour as the rest of the post text. And not the same colour as the rest of the hashtag. This means that the hashtag character is not part of the link. (To Mastodon users who don't know this: If something in a "toot" has a different colour from the rest of the "toot", it's a link. Even if it doesn't show a URL in plain sight.)
On 𝕏, Mastodon, Pleroma, Akkoma, Misskey, the various Forkeys and a whole lot of other Fediverse software, a hashtag in a message looks like this:
#Hashtag
Notice how now the hashtag character has the same colour as the rest of the hashtag. This means that the hashtag character is part of the link.
But why did Identi.ca do hashtags differently from Twitter? Because Identi.ca did hashtags before Twitter. AFAIK, when Identi.ca was launched, it had support for hashtags right away. About one year before Twitter.
The hashtag itself had already been invented by the Twitter community. Chris Messina had already codified it in 2007. But it wasn't until 2009 that Twitter actually introduced a technological implementation to support it.
Again, Identi.ca must have had hashtags as early as 2008, and there was no way that Identi.ca creator Evan Prodromou could possibly predict what Twitter would do the following year. So he did what he thought was right and what actually made sense to him.
But nowadays, everybody "knows" that Twitter had the world's very first hashtag implementation ever because nobody, even in the Fediverse, has ever heard of Identi.ca. I mean, the majority of Fediverse users "know" that the Fediverse started with Mastodon.
You know, just like Officer James Barrett "knew" that there is no intelligent life outside Earth only a few minutes before he became Agent J of the Men In Black.
This is also why just about all Fediverse software that does hashtags the Twitter way expects everything to do hashtags the Twitter way. It does not expect hashtags to be done differently. And when a message comes in from Friendica, Hubzilla, (streams) or Forte with hashtags in it, it fails at varying degrees of ungracefully.
Hashtags with the hashtag character outside the link are older than hashtags with the hashtag character inside that they're not only completely unexpected, that they cause software to malfunction, but the same software often can't even handle that malfunction. It's a miracle that the Friendica/Hubzilla family doesn't cause Fediverse servers to crash or even server databases to go corrupt by simply sending hashtags.
Mastodon used to be an exception of sorts, but only because, before version 4.0 from October, 2022, its HTML "sanitiser" actually ripped out any and all rich text code from incoming messages and left nothing but plain text behind. And then it didn't recognise hashtags in messages from outside Mastodon as hashtags at all.
When Mastodon 4.0 came and supported some rich text, including embedded links, it went haywire, of course. But then someone from Friendica and Hubzilla went in and complained about this malfunction and explained what happened, why it happened and why it was not Friendica and Hubzilla that did things wrong. Besides, if something utterly defaces "toots", then Mastodon developers do step in to stop it. After all, Mastodon has a few more of them at hand, paid, full-time professionals even. You have to give it that.
Which takes us back to Sharkey. Sharkey is developed by a small handful of individuals in their spare time. Granted, it's a soft fork of Misskey, so a lot of development work is done by the Misskey devs and taken over by the Sharkey devs, but they still have to weave the code changes coming from Misskey in and make them work with what's different on Sharkey.
So it turned out that (Link content warning: eye contact) this bug has already been filed to the Sharkey devs in October, 2024. All that has happened since then until today was that Hazelnoot added two labels. But the bug report came with no explanations. In fact, it misattributed one of my Hubzilla posts as a Friendica post.
And in fact, it turned out that this is actually (Link content warning: Microsoft GitHub link, eye contact) a Misskey bug which has been filed in January, 2024, two years ago. The bug report is a bit more elaborate, but the reporter still knew precious little about what's going on. So I wrote a comment in which I explained the bug from a Friendica/Hubzilla POV as well as what's going on on the technical side, and why the error has to be on Misskey's side.
I hope this will finally help get the bug fixed. Unfortunately, this fix would come too late for Iceshrimp. Iceshrimp-JS is a true Forkey, but in maintenance mode, so I guess only security patches and critical bugfixes will be merged from Misskey, if anything. And Iceshrimp.NET is a complete rewrite of a pre-this-fix Misskey fork, so the Iceshrimp devs probably don't know about this issue either. If it fails ungracefully upon receiving hashtags with the hashtag character outside, it will require its own bug report.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Hashtag #Hashtags #HashtagMeta #CWHashtagMeta #Twitter #𝕏 #Fediverse #Mastodon #Pleroma #Akkoma #Misskey #Forkey #Forkeys #Sharkey #Iceshrimp #Iceshrimp-JS #Iceshrimp.NET #Identi.ca #Laconi.ca #StatusNet #Friendica #Hubzilla #Streams #(streams) #Forte -
CW: Why Sharkey fails to render hashtags from Friendica, Hubzilla & Co. properly, and how long this bug has been known already; CW: long (over 6,600 characters), Fediverse meta, Fediverse-beyond-Mastodon meta
So there's that nasty bug on Sharkey that mangles hashtags in messages from Hubzilla and probably also Friendica, (streams) and Forte. They always look like this:
#[Hashtag](https://hub.netzgemeinde.eu/search?tag=Hashtag)
Basically, Sharkey receives fully standard Rich Text from Hubzilla. It manages to convert this Rich Text into its own Misskey-Flavored Markdown. But then its Markdown parser does not parse it and leaves the Markdown code visible to everyone. It simply doesn't expect there to be a hashtag character in front of an embedded link because, seriously, who'd ever do that and why?!
Friendica would. In fact, Friendica does. It puts the hashtag character in front of the tag, as in outside the tag, as opposed to at the beginning of the tag. It has been doing that since its beginnings in 2010 because it was designed from the get-go to also federate with StatusNet from 2008. And StatusNet does hashtags the same way on its few remaining servers. In fact, so did Identi.ca from 2008, from which StatusNet emerged.
Hubzilla, (streams) and Forte do it, too, because they have inherited it from Friendica.
On StatusNet, Friendica, Hubzilla, (streams) and Forte, a hashtag in a message looks like this:
#Hashtag
Notice how the hashtag character has the same colour as the rest of the post text. And not the same colour as the rest of the hashtag. This means that the hashtag character is not part of the link. (To Mastodon users who don't know this: If something in a "toot" has a different colour from the rest of the "toot", it's a link. Even if it doesn't show a URL in plain sight.)
On 𝕏, Mastodon, Pleroma, Akkoma, Misskey, the various Forkeys and a whole lot of other Fediverse software, a hashtag in a message looks like this:
#Hashtag
Notice how now the hashtag character has the same colour as the rest of the hashtag. This means that the hashtag character is part of the link.
But why did Identi.ca do hashtags differently from Twitter? Because Identi.ca did hashtags before Twitter. AFAIK, when Identi.ca was launched, it had support for hashtags right away. About one year before Twitter.
The hashtag itself had already been invented by the Twitter community. Chris Messina had already codified it in 2007. But it wasn't until 2009 that Twitter actually introduced a technological implementation to support it.
Again, Identi.ca must have had hashtags as early as 2008, and there was no way that Identi.ca creator Evan Prodromou could possibly predict what Twitter would do the following year. So he did what he thought was right and what actually made sense to him.
But nowadays, everybody "knows" that Twitter had the world's very first hashtag implementation ever because nobody, even in the Fediverse, has ever heard of Identi.ca. I mean, the majority of Fediverse users "know" that the Fediverse started with Mastodon.
You know, just like Officer James Barrett "knew" that there is no intelligent life outside Earth only a few minutes before he became Agent J of the Men In Black.
This is also why just about all Fediverse software that does hashtags the Twitter way expects everything to do hashtags the Twitter way. It does not expect hashtags to be done differently. And when a message comes in from Friendica, Hubzilla, (streams) or Forte with hashtags in it, it fails at varying degrees of ungracefully.
Hashtags with the hashtag character outside the link are older than hashtags with the hashtag character inside that they're not only completely unexpected, that they cause software to malfunction, but the same software often can't even handle that malfunction. It's a miracle that the Friendica/Hubzilla family doesn't cause Fediverse servers to crash or even server databases to go corrupt by simply sending hashtags.
Mastodon used to be an exception of sorts, but only because, before version 4.0 from October, 2022, its HTML "sanitiser" actually ripped out any and all rich text code from incoming messages and left nothing but plain text behind. And then it didn't recognise hashtags in messages from outside Mastodon as hashtags at all.
When Mastodon 4.0 came and supported some rich text, including embedded links, it went haywire, of course. But then someone from Friendica and Hubzilla went in and complained about this malfunction and explained what happened, why it happened and why it was not Friendica and Hubzilla that did things wrong. Besides, if something utterly defaces "toots", then Mastodon developers do step in to stop it. After all, Mastodon has a few more of them at hand, paid, full-time professionals even. You have to give it that.
Which takes us back to Sharkey. Sharkey is developed by a small handful of individuals in their spare time. Granted, it's a soft fork of Misskey, so a lot of development work is done by the Misskey devs and taken over by the Sharkey devs, but they still have to weave the code changes coming from Misskey in and make them work with what's different on Sharkey.
So it turned out that (Link content warning: eye contact) this bug has already been filed to the Sharkey devs in October, 2024. All that has happened since then until today was that Hazelnoot added two labels. But the bug report came with no explanations. In fact, it misattributed one of my Hubzilla posts as a Friendica post.
And in fact, it turned out that this is actually (Link content warning: Microsoft GitHub link, eye contact) a Misskey bug which has been filed in January, 2024, two years ago. The bug report is a bit more elaborate, but the reporter still knew precious little about what's going on. So I wrote a comment in which I explained the bug from a Friendica/Hubzilla POV as well as what's going on on the technical side, and why the error has to be on Misskey's side.
I hope this will finally help get the bug fixed. Unfortunately, this fix would come too late for Iceshrimp. Iceshrimp-JS is a true Forkey, but in maintenance mode, so I guess only security patches and critical bugfixes will be merged from Misskey, if anything. And Iceshrimp.NET is a complete rewrite of a pre-this-fix Misskey fork, so the Iceshrimp devs probably don't know about this issue either. If it fails ungracefully upon receiving hashtags with the hashtag character outside, it will require its own bug report.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Hashtag #Hashtags #HashtagMeta #CWHashtagMeta #Twitter #𝕏 #Fediverse #Mastodon #Pleroma #Akkoma #Misskey #Forkey #Forkeys #Sharkey #Iceshrimp #Iceshrimp-JS #Iceshrimp.NET #Identi.ca #Laconi.ca #StatusNet #Friendica #Hubzilla #Streams #(streams) #Forte -
@Lucas Das ist in der Tat eine gute Frage.
Bei Leuten, die von Windows nach Linux umsteigen wollen, ist ja traditionell ein Problem, daß sie sich nicht vorstellen können, daß ein Betriebssystem anders funktionieren und sich folglich auch anders bedienen kann als Windows. Also erwarten sie von Linux ein kostenloses Windows ohne Onlinekontenzwang und ohne Spionage, aber ansonsten haargenau mit der UX von Windows.
Und dann sind sie schon überfordert mit der Paketverwaltung und mit der völlig anderen Struktur des Dateisystems (oder auch nur, daß sie sich jetzt mit dem Dateisystem auseinandersetzen müssen). Wenn man ihnen dann auch noch mit "diesem doofen MS-DOS-Fenster", also der Konsole, kommt, statt ihnen für alles Klickibunti-Lösungen zu präsentieren, dann sind sie endgültig vergrault. Ach ja, und mit Quellcode und Lizenzen braucht man ihnen auch nicht kommen.
Bei Leuten, die von 𝕏 wegwollen, ist es doch nicht anders. Das haben uns doch die letzten knapp vier Jahre gezeigt.
Mastodon sieht nicht haargenau aus wie 𝕏 und bedient sich auch nicht so? Und tschüß! Ab nach Bluesky, das sieht wirklich aus wie Twitter, als Twitter noch gut war. Da muß man nicht umdenken und fast nichts neu lernen.
Bei Mastodon "muß" man eine "Instanz" wählen? Viel zu kompliziert! Bluesky stellt sich technischen Laien dagegen einfach nur als Handy-App dar, wo man sich so einfach registrieren kann wie damals auf Twitter. Ungeachtet der Tatsache, daß sowohl die offizielle Mastodon-App als auch die offizielle Bluesky-App beide eine Instanzauswahl bieten, die auch noch auf beiden optional ist, weil sie eine Instanz (mastodon.social, bsky.social) voreingestellt hat.
Auf Mastodon hat man die 800.000 Follower, die sich in 12 Jahren auf Twitter angesammelt haben, nicht innerhalb einer Stunde? Da ist doch "keiner", da hat man voll keine Reichweite und keinen Fame, das lohnt sich nicht. Sieht man ja schon daran, daß der Feed, äh, die Timeline nicht sofort nach dem ersten Login rappelvoll mit Tweets, äh, Tröts ist.
Diejenigen, die geblieben sind, sind unter entsprechend hohem Leidensdruck geblieben. Oder ihnen war und ist auch Bluesky suspekt. Oder als Bluesky aufkam, hatten sie schon mehr Interaktion, als sie auf Twitter je hatten.
Wer also "literarisch Twitter ohne Musk" sucht und partout seinen Denkkasten nicht benutzen und sich nicht umgewöhnen will, wird enttäuscht werden.
Umgekehrt kann es aber auch Leute geben, die von der Kultur auf 𝕏 komplett wegkommen wollen und etwas ganz anderes suchen. Die werden auf Mastodon auch nicht unbedingt glücklich werden. Gerade auf Mastodon und da vor allem auf den typischen "Anfängerservern" wie mastodon.social gibt es viele, die sich tatsächlich nicht umgewöhnen können oder wollen. Die benutzen Mastodon genau, wie sie 𝕏 benutzt haben. Und die verhalten sich auch wie auf 𝕏. Für die ist Mastodon "literarisch Twitter ohne Musk", nur daß es eben anders aussieht.
Vielleicht wären diese Leute auf z. B. Sharkey besser aufgehoben. Klar, Sharkey ist mit Mastodon föderiert, so daß man möglicherweise auf dieselben Nasen stoßen wird. Aber man ist nicht sofort von genau diesen Nasen umgeben, weil es die auf dem eigenen Server nicht gibt. Und wenn man auf diese Leute stößt, hat man dann schon ein Umfeld, das einem hilft, sich gegen diese Leute zu verteidigen.
Das Schöne am Fediverse außerhalb von Mastodon ist doch: Die Leute, die einfach mit geringstmöglichem Widerstand den nächstbesten 𝕏-Klon haben wollen, bleiben allesamt auf Mastodon hängen. Viele von denen wissen nicht mal, daß das Fediverse mehr ist als nur Mastodon. Das wollen die auch nicht hören, das überfordert sie nur. Einige dürften sogar glauben, das Fediverse bestünde nur aus mastodon.social.
Jenseits von Mastodon trifft man nur die Fortgeschrittenen an, die Ambitionierten, die wirklich etwas anderes als 𝕏 suchen. Die verhalten sich dann auch nicht, als wären sie noch auf 𝕏. Die verhalten sich nicht mal, als wären sie auf Mastodon.
Ich bin überhaupt dafür, mehr Leute von 𝕏 direkt nach etwas im Fediverse zu holen, das nicht Mastodon ist. Umgewöhnen werden müssen sie sich so oder so. Aber dann gewöhnen sie sich nicht an ein reines Mastodon-Fediverse, zumal etwa Misskey und die Forkeys ihnen anzeigen, von welcher Serveranwendung ein Beitrag kommt. Dann gewöhnen sie sich nicht an ein Fediverse, das nur Mastodons Features hat. Dann gewöhnen sie sich von vornherein an Features, die 𝕏 nicht hat, die Mastodon nicht hat, wo sie sich dann aber fragen, wie sie so lange ohne diese Features auskommen konnten.
Und wenn sie irgendwann selbst Leute ins Fediverse holen, dann werden sie denen auch nicht vorgaukeln, das Fediverse sei nur Mastodon.
CC: @Katharina Nocun
#Long #LongPost #CWLong #CWLongPost #LangerPost #CWLangerPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Windows #Linux #Twitter #𝕏 #Bluesky #Mastodon #NichtNurMastodon #Misskey #Forkey #Forkeys #Sharkey -
@Herr TurTur @crossgolf_rebel - kostenlose Kwalitätsposts @tux0r :openbsd: Die Idee hinter Sharkey war mal, in einen einzigen Forkey quasi alles auf einmal reinzuschmeißen bis hin zur Küchenspüle. Das fiel vor allem auf, als es noch mehr lebendige Forkeys zur Auswahl gab.
Und in der Zeit hatte Sharkey auch noch gewisse Macken, z. B. eine schon legendär unzuverlässige Implementation der Mastodon Client API, wo es hieß, am besten setzt sich einer hin und schreibt die neu. Wer was Zuverlässiges wollte, setzte damals auf Iceshrimp. Sharkey war für wagemutige Spielkinder, die sich an Hubzilla nicht rantrauten.
Inzwischen ist Calckey tot, Firefish ist tot, Iceshrimp-JS ist im Wartungsmodus (Iceshrimp.NET ist derweil noch meilenweit von "fertig" entfernt), Catodon ist auch schon siech, und das nur für eine Instanz gebaute Hajkey ist schon verwest.
CherryPick hat fast nur Server in den Großräumen Tokyo und Seoul und fühlt sich so auf den ostasiatischen Geschmack ausgelegt an wie vor ein paar Jahren noch Misskey selbst. Vielleicht erinnern sich ein paar noch daran, wie Misskey mal den Charme japanischer Verkaufsautomaten hatte.
Und der ganze noch lebende Rest scheint selbst mit Misskeys Entwicklung nicht mithalten zu können, also im Kern veraltet zu sein.
Derweil ist Sharkey wohl inzwischen ziemlich zuverlässig. So ist es zumindest im Westen zum einzigen noch nennenswerten Forkey avanciert.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Misskey #Forkey #Forkeys #Sharkey #Calckey #Firefish #Iceshrimp #Iceshrimp-JS #Iceshrimp.NET #Catodon #Hajkey #CherryPick -
@mradcliffe The danger in this, however, is that another Fediverse feature that's way older than Mastodon and at the same time absent from Mastodon would be reappropriated as something else, making Mastodon even more incompatible with the rest of the Fediverse.
In 2017, Mastodon introduced its content warning field. Ever since, almost everyone on Mastodon has been fully convinced that Eugen Rochko had invented that field from scratch. (Be honest, how about you?)
However, Mastodon's content warning field is actually a summary field that has been used by StatusNet, Friendica and Hubzilla as such since 2008, 2010 and 2012 respectively. Mastodon hadn't had any support for that summary field at first, for you don't need a summary for 500 characters. And I guess that coder from the demo scene who submitted the merge request that reappropriated the summary field as a content warning field was blissfully unaware that Mastodon was actually connected to something that did use the summary field as such.
And now you have Mastodon users scolding Friendica users because the latter allegedly misuse the CW field for "like a subject or smth idk", unaware that the self-same field has been the abstract field on Friendica for five and a half years longer than Mastodon has even existed and some seven years longer than Mastodon had its CW field.
Today, in 2025, next to nobody on Mastodon knows that the Fediverse already has group actors, and probably neither do many on the *keys. Neither Mastodon nor Misskey nor their respective forks have or support groups in any way.
If they go and reappropriate group actors as starter packs, this will break compatibility with Friendica groups, Hubzilla forums, (streams) groups, Forte groups, Lemmy communities, /kbin magazines, Mbin magazines, PieFed communities, NodeBB forums etc., all of which can be and often already are being followed by Mastodon and *key users right now. And again, they've all had group actors since their respective inception.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Mastodon #Misskey #Forkey #Forkeys #Friendica #Hubzilla #Streams #(streams) #Forte #Lemmy #/kbin #Mbin #PieFed #NodeBB #CW #CWs #CWMeta #ContentWarning #ContentWarnings #ContentWarningMeta #Group #Groups #GroupActor #GroupActors #FediGroups #FediverseGroups -
@Tim Chambers @Seth of the Fediverse @Johannes Ernst @@reiver ⊼ (Charles) :batman: @Andy Piper I hope this won't end up in a culture clash due to how big Misskey and other Forkeys are in East Asia (CherryPick almost only exists in Japan and South Korea) while Westerners tend to talk about the Fediverse and Mastodon as if they're one and the same.
Language has a chance of being an obstacle, too. If you want to get e.g. Japanese Forkey devs on board as well, chances are they don't speak English.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #Mastodon #Misskey #Forkey #Forkeys #CherryPick -
@Matthias @C.Suthorn :prn: Ich habe es oben geschrieben: So ein System ist fediverseweit gar nicht möglich. Es ist technisch nicht realisierbar.
Was Mastodon da gebaut hat, funktioniert nur innerhalb von Mastodon. Ich habe es ja oben erklärt:- Auch wenn du einen Post als nicht quote-post-bar einstellst, können Pleroma, Misskey, Friendica & Co. den trotzdem ungehindert quote-posten.
- Gleichzeitig kann niemand auf Mastodon irgendwas auf Pleroma, Misskey, Friendica & Co. quote-posten, obwohl es jeder darf.
Das liegt daran, daß Mastodon mal wieder mit voller Absicht das Rad neu erfunden hat.
Sie hätten die Art des Quote-Postens übernehmen können, die Misskey schon lange hat und die auch Threads verwendet. Sie hätten die Art des Quote-Postens übernehmen können, die Friendica seit über 15 Jahren erfolgreich einsetzt. Nein, statt dessen hat Mastodon eine eigene, proprietäre Technik entwickelt und sich mit vollem Vorsatz zum Rest des Fediverse noch inkompatibler gemacht.
Aber noch einmal: Mike Macgirvin sagt, es ist technisch nicht möglich, Quote-Posts von öffentlichen Posts zu verhindern. Und noch einmal: Der Mann muß es wissen.
Mike entwickelt schon seit fast einem halben Jahrhundert Software. Er ist Profi. Er war mal bezahlter Profi. Mike hat Friendica rausgehauen, da ging Eugen Rochko noch zur Schule.
Mike hat mehr Fediverse-Serveranwendungen entwickelt als jeder andere da draußen. Jede einzelne davon ist von den Features her leistungsfähiger als alles andere, was es im Fediverse gibt. Mike hat im Alleingang sogar mehr Fediverse-Protokolle entwickelt als jeder andere da draußen. Mike hat nomadische Identität im Alleingang erfunden, und sie funktioniert seit 2012.
Und Mike hat in puncto Sicherheit und Berechtigungssteuerung weit mehr gemacht als jeder andere Fediverse-Entwickler. Das, was er entwickelt hat, ist in seiner Funktionalität auch nicht eingeschränkt auf die eigene Software, sondern er hat sich immer auch Gedanken darüber gemacht, wie es außerhalb funktioniert, während für Eugen Rochko alles außerhalb von Mastodon Feindesland ist, das ignoriert wird und totgeschwiegen gehört.
Ganz ehrlich: Was vor allem Hubzilla und (streams) und Forte können in puncto Berechtigungssteuerung, das ist für die meisten Mastodon-Nutzer vollkommen unvorstellbar. Es gibt Berechtigungseinstellungen auf bis zu drei Ebenen (ganzer Kanal, einzelne Kontakte, pro Post/Thread) für fast alles bis hin zu Features, die Mastodon gar nicht hat.
Nur für Quote-Posts gibt's keine. Weil das fediverseweit nicht möglich ist.
Wenn es öffentlich ist und jeder es sehen kann, dann kann es auch jeder quote-posten. Das geht schlicht und ergreifend nicht zu verhindern. Nicht mal innerhalb von Hubzilla und (streams) und Forte. Außerhalb schon mal erst recht nicht.
Innerhalb von Mastodon geht's nur aus zwei Gründen. Zum einen, weil Mastodon den ganzen Rest des Fediverse bestenfalls komplett ignoriert. Zum anderen, weil Mastodon-Nutzer zwingend für jeden Pups auf GUI-Knöpfchen angewiesen sind. Sie sind es nicht gewohnt, irgendwas in ihren Tröts per Hand zu formatieren, weil sie noch nie irgendwas haben formatieren können. Und weil gefühlt beinahe jeder nur ein Smartphone und eine dedizierte Mastodon-App verwendet und kein Copy-Paste kennt, ist das Quote-Post-GUI-Knöpfchen das einzige, was sie haben, abgesehen von Screenshots.
Aber schon Mastodons Methode funktioniert, wie ich oben schon schrieb, nicht über Mastodon hinaus. Und da kann Mastodon lange drauf warten, daß der Rest des Fediverse seine eigene jahrelang etablierte Technologie wegschmeißt und auf Mastodons proprietäre Technologie umschwenkt.
Auf Misskey, den Forkeys und allen anderen, die auf dieselbe Art quote-posten, ist Quote-Posten überhaupt nicht verhinderbar. Das liegt daran, daß Quote-Posts pupeinfach als Link auf den Originalbeitrag ausgeführt sind mit "RE:" davor.RE: https://domain.tld/Adresse_des_OriginalbeitragsZack, hast du einen Quote-Post. Und mal ehrlich, für sowas braucht man kein GUI-Knöpfchen, wenn man tippen und URLs copy-pasten kann.
Auch auf Friendica, Hubzilla, (streams) und Forte, die ganz anders quote-posten, ist Quote-Posten öffentlicher Beiträge nicht verhinderbar. Da nutzen die Leute keine Apps auf Smartphones. Nein, die meisten sitzen am Desktop-PC oder Laptop mit Hardwaretastatur und nutzen einen Standardbrowser statt einer dedizierten App. Copy-Paste ist für sie kein Problem und schon gar kein Fremdwort. Außerdem sind vor allem die alten Hasen es höchstwahrscheinlich meistens gewohnt, Markup-Code für Formatierungen per Hand einzutippen, statt sich auf die GUI-Knöpfchen zu verlassen, die auch nur BBcode-Stückchen in den Editor reinpflanzen.
Mike Macgirvin sagt: Es gibt genau eine Art und Weise, wirksam fediverseweit zu verhindern, daß du gequote-postet wirst. Und das ist, nicht öffentlich zu posten.
Für jemanden für ihn ist es aber auch einfach, das zu sagen. Gerade auf Hubzilla, (streams) und Forte gibt es etliche Abstufungen zwischen öffentlich und DM. Auf Hubzilla kann ich einen Post- in alle Öffentlichkeit
- nur an mich selbst
- an eine bestimmte Privacy Group (quasi wie eine Liste auf Mastodon, aber sehr viel mächtiger)
- an diejenigen, denen ich ein Profil zugewiesen habe, das nicht das Standardprofil meines Kanals ist (Mastodon hat dagegen nur ein Profil pro Konto)
- an ein bestimmtes Forum/eine bestimmte Gruppe
- eine beliebige individuelle Auswahl aus einzelnen Kontakten, Foren/Gruppen, Privacy Groups und Profilzugewiesenen
Und der Witz ist: Das steuert nicht nur, an wen der Post geht. Das steuert auch, wer den Post (und sämtliche Kommentare zum Post) sehen darf. Wenn der Post nicht an dich geht, wirst du ihn nie zu Gesicht bekommen. Nein, auch nicht per Boost. Das ist nämlich bei nichtöffentlichen Posts explizit verboten, und das dafür nötige Bedienelement ist schlicht und ergreifend nicht da.
Es wird noch besser: Das funktioniert sogar bis nach Mastodon. Denn wenn es nicht öffentlich ist, dann stellt es sich Mastodon gegenüber als DM dar.
Ich setze noch einen drauf: Im krassen Gegensatz zum restlichen Fediverse posten Hubzilla, (streams) und Forte mit Standardeinstellungen nicht öffentlich. Alle drei haben standardmäßig schon eine Privacy Group/Zugriffsliste namens "Freunde", in der alle neuen Kontakte landen. Und alle drei posten standardmäßig nur zu dieser Privacy Group/Zugriffsliste namens "Freunde". Aus Mastodon-Sicht verschicken alle drei standardmäßig immer nur DMs. Wenn du öffentlich posten willst, ist das Extraaufwand.
So gehen Sicherheit und Privatsphäre. Und nicht mit proprietärem, zu nichts anderem kompatiblem Hokuspokus für Doofe wie auf Mastodon.
#Long #LongPost #CWLong #CWLongPost #LangerPost #CWLangerPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #Mastodon #Pleroma #Misskey #Forkey #Forkeys #Friendica #Hubzilla #Streams #(streams) #Forte #QuotePost #QuotePosts #QuoteTweet #QuoteTweets #QuoteToot #QuoteToots #QuoteTröt #QuoteTröts #Drüko #Drükos #Druko #Drukos #QuoteBoost #QuoteBoosts #QuotePostDebatte #QuoteTrötDebatte #Sicherheit #Berechtigung #Berechtigungen -
CW: The various issues with quote-posts on Mastodon that nobody on Mastodon is aware of; CW: long (almost 6,800 characters), Fediverse meta, Fediverse-beyond-Mastodon meta, Mastodon looking bad in comparison with the rest of the Fediverse, quote-post meta
Okay, everyone, sit down. I'll tell you a few things about Mastodon's quote-post feature that you know nothing about. Definitely not if all you know is Mastodon. Oh, and by the way, in case you don't know yet in spite of following me: The Fediverse is not only Mastodon.Mastodon has been quote-post-able for as long as it has been around
Eugen Rochko is bringing quote-posts to Mastodon. But he is not bringing quote-posts to the Fediverse. The Fediverse has had quote-posts for 15 years.
It was Mike Macgirvin who introduced quote-posts to the Fediverse in July, 2010, when he launched something called Mistpark back then and Friendica today (https://friendi.ca, https://en.wikipedia.org/wiki/Friendica). That was five and a half years before Mastodon was launched.
In fact, when Mastodon was launched, it immediately federated itself with Friendica and with Hubzilla, a fork of a fork of Friendica by Friendica's own creator which has quote-posts, too. So when Mastodon was launched, it immediately became possible to quote-post Mastodon toots. Not on Mastodon itself, but on Friendica and Hubzilla.Just about everything that isn't Mastodon has already got quote-posts right now
Here are a few (but not even all) Fediverse server applications that already have quote-posts:
And they're all part of the Fediverse which means that they're all connected to Mastodon. People on all of these can theoretically read your Mastodon toots. And people on all of these can theoretically quote-post your Mastodon toots.Mastodon's quote-post opt-in is not a water-tight defence against being quote-posted
So you can choose not to be quote-posted. But you can only choose not to be quote-posted by Mastodon users. This opt-in does not work with the rest of the Fediverse.
First of all, that's because Mastodon's quote-post feature is not compatible with anything else out there. Mastodon's developers have chosen to re-invent the quote-posting wheel from scratch. They've intentionally chosen to do so in a way that's completely incompatible with everything else out there.
Their intention was to reinforce Mastodon's appearance to its own users as the one and only Fediverse and ActivityPub gold standard and to make Pleroma, Akkoma, Misskey, Firefish, Iceshrimp, Sharkey, CherryPick, Catodon, Mitra, Friendica, Hubzilla, (streams), Forte etc. look broken. It's part of their plan to keep Mastodon users on Mastodon in the wake of Mastodon's market share in the Fediverse shrinking.
Also, they did not publish any specifications on their quote-post implementation, so even those non-Mastodon developers who are fast enough didn't have a chance to implement support for Mastodon's opt-in.
This means that even if you've set your posts to un-quote-post-able on Mastodon, everything I've listed above can still quote-post you with no resistance.Absolute Fediverse-wide protection against being quote-posted is impossible
And don't get your hopes high that the day will come when nobody on the Fediverse will be able to quote-post you, whether they're on Mastodon or not. Such a setting is technologically impossible.
Who says that? Mike Macgirvin says that. The guy who launched Friendica and brought quote-posts to the Fediverse 15 years ago, remember? This guy has built the Fediverse's most elaborate, most complex, most fine-grained, most advanced permissions system into (streams) and Forte.
These two have reply control, the kind of which you couldn't image in your wildest dreams. I'm serious. They have permissions settings for almost everything on two or three levels, for your whole channel, individually per contact and sometimes even per post or per file or folder in the file storage.
But they don't have quote-post permission settings. Because that's impossible to enforce Fediverse-wide. And even if it was possible, it'd be pointless. If they can't quote-post you, they'll copy-paste you. If they can't copy-paste you either because they're on a phone, they'll post screenshots of your toots.
Mike also says, there is exactly one way to keep people from quote-posting you, and that's by not posting in public. Unfortunately, unlike what he has created, Mastodon has little between "public" and "DM", if anything.Mastodon cannot quote-post the non-Mastodon Fediverse
This may be the big surprise: It has recently been discovered by chance that Mastodon's quote-post feature only works with Mastodon toots.
On the one hand, Pleroma, Akkoma, Misskey, Sharkey, Friendica, Hubzilla etc. can quote-post just about everything that comes in from Mastodon. But on the other hand, no Mastodon 4.5 user will be able to quote-post anything from either of these. Or from Pixelfed or PeerTube or Loops or Castopod or WriteFreely or whatever.
That's because Mastodon is looking for a quote-post opt-in. But nothing else in the Fediverse supports Mastodon's quote-post opt-in, also seeing as it's still officially in development. And it's highly unlikely that everything in the Fediverse will adopt another piece of non-standard, proprietary Mastodon tech."Quote" actually means something else
Lastly, Mastodon has the audacity to call this feature "quote".
A "quote" is something else. Remember forums? Like, bulletin-board forums with subforums and all? Where posts are quoted in follow-ups, entirely or only partially? That's what a quote is. That has got nothing to do with quote-posts.
Why I say that there's a difference? Because I also say that Friendica has had both quotes and quote-posts.
It has had them for 15 years, both quotes (which it calls "quotes", go figure) and quote-posts (which it calls "quoted shares", and which include the original author of the quoted post, complete with their profile picture and a clickable link to them, as well as a clickable link to the original post).
Hubzilla has both. (streams) has both. Forte has both. And I wouldn't be surprised if other Fediverse server software had both, too.
The irony is that Mastodon itself has been able to render actual quotes since version 4.0 from October, 2022. At the same time, it will continue to be unable to render any quote-posts done outside of Mastodon for the foreseeable future.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #Mastodon #NotOnlyMastodon #FediverseIsNotMastodon #MastodonIsNotTheFediverse #Pleroma #Akkoma #Misskey #Forkey #Forkeys #Firefish #Iceshrimp #Sharkey #CherryPick #Catodon #Mitra #Friendica #Hubzilla #Streams #(streams) #Forte #QuotePost #QuotePosts #QuoteTweet #QuoteTweets #QuoteToot #QuoteToots #QuoteBoost #QuoteBoosts #QuotedShares -
@silverpill Who are the longformers anyway?
They're those who either are commercial or looking for professional/commercial users or both. Flipboard. Automattic (WordPress). Ghost. These kinds.
They know themselves. They know each other. And they know Mastodon. And that's it.
None of them has ever heard of Pleroma or Akkoma.
None of them has ever heard of Misskey or the Forkeys.
None of them has ever heard of Mitra.
None of them has ever heard of GoToSocial.
None of them has ever heard of Hollo.
None of them has ever heard of Friendica, Hubzilla, (streams) or Forte, even though Friendica and Hubzilla are both older than Mastodon. And apparently, neither has @Helge. But then again, Friendica and its nomadic, security-enhanced descendants are being overlooked by almost everyone. That's why there's always on-going work for features to be "introduced to the Fediverse" which Friendica has had for a decade and a half.
Granted, the HTML support on Friendica, Hubzilla, (streams) and Forte can be summarised with "yes". But elaborate tables that show what either of them supports how would be very useful.
Also, granted, everything I've mentioned above (normally) uses something else than HTML for formatting in the frontend. For example, Misskey and all Forkeys use MFM ("Misskey-Flavoured Markdown"). Friendica uses extended BBcode with the option to use Markdown instead. Hubzilla uses even more extended BBcode. (streams) and Forte can use the same even more extended BBcode and Markdown and HTML at the same time within the same post, although not all markup languages support all features.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #Mastodon #Pleroma #Akkoma #Misskey #Forkey #Forkeys #Mitra #GoToSocial #Hollo #Friendica #Hubzilla #Streams #(streams) #Forte #LongFormContent #BBcode #Markdown #HTML #TextFormatting -
@Sven222 Kommt drauf an.
Misskey und die Forkeys zeigen an, von wo ein Beitrag kommt. Friendica zeigt es an. (streams) und Forte zeigen es an.
Hubzilla zeigt es nicht an, aber Hubzilla hat noch ganz andere Baustellen, gerade auch in der Weboberfläche.
Mastodon zeigt es auch nicht an. Und so gehen die meisten Mastodon-Nutzer bei jedem Beitrag von einem nativen Mastodon-Tröt aus. Selbst wenn etwas so wie das hier eigentlich nur zu offensichtlich gar nicht von Mastodon stammen kann, glauben wahrscheinlich viele trotzdem an irgendeine "gehackte", frisierte Mastodon-Instanz.
Ein Unterschied ist ja auch noch: Gerade Friendica- und Hubzilla-Nutzer sind es ja gewohnt, sich in alle möglichen und unmöglichen Richtungen zu verbinden, zumal die allermeisten Hubzilla-Nutzer von Friendica kommen. Und das meint nicht nur das ActivityPub-basierte Fediverse, sondern z. B. auch mal diaspora* oder RSS-/Atom-Feeds oder Tumblr oder jüngererdings auf Friendica auch mal Bluesky. In den frühen 2010ern waren die populärsten öffentlichen Friendica-Nodes die mit Facebook-Anbindung.
Ein Grund, warum (streams) und Forte so unpopulär sind, ist, weil sie eigentlich keine Zielgruppe außerhalb von Hubzilla haben, aber die Hubzilla-Nutzerschaft auf Hubzillas Features überwiegend nicht verzichten will. Dazu zählen auch die diaspora*-Verbindung und der Feed-Aggregator; beides gibt's auf (streams) und Forte nicht mehr. Forte versteht ja überhaupt nur noch ActivityPub und ist daher auch blind für Hubzilla- und (streams)-Kanäle, wo ActivityPub aus ist.
Der Friendica-Veteran hat verinnerlicht: "Wenn es existiert, kann ich mich damit verbinden."
99,99% der Mastodon-Nutzer lernen dagegen Mastodon und das Fediverse als in sich geschlossenes reines Mastodon-Netzwerk kennen ohne jegliche Verbindung nach woanders. Entweder ist das ihnen gegenüber bei der Einladung impliziert worden, oder es ist ihnen direktweg so gesagt worden. Und daran gewöhnen sie sich dann auch.
PeerTube, Pixelfed und dergleichen lernen sie dann irgendwann kennen als sowas wie Add-ons für Mastodon, also ein an Mastodon drangeklebtes YouTube, ein an Mastodon drangeklebtes Instagram usw. Viele von denen scheißen sich komplett ein, wenn sie erfahren, daß es auch noch andere Mikroblogging- und/oder Social-Networking-Sachen im Fediverse gibt und die dann auch mit Mastodon verbunden sind, aber eben nicht nachträglich an Mastodon drangeklebt.
CC: @Regezi
#Long #LongPost #CWLong #CWLongPost #LangerPost #CWLangerPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #Mastodon #Misskey #Forkey #Forkeys #Friendica #Hubzilla #Streams #(streams) #Forte #PeerTube #Pixelfed #MastodonZentrizität #MastodonNormativiät #Föderation -
@Ben Pate 🤘🏻 Let's just say the only devs who need full identity portability are silverpill and you, and silverpill is actively working on it.
Then there are Mike, Mario Vavti and Harald Eilertsen who have full identity portability.
All the other devs don't seem to care.
As for the users, however... I guess if Mastodon 4.5 went fully nomadic on Forte's scale, people would kiss Gargron's feet because he'd deliver what they've been craving for for so long. For not exactly few of them, this would be what they've been wishing for for years plus cream and a cherry on top.
And if all the various *keys (at least those that are still maintained) went nomadic on a cross-server-type scale, that'd solve the problem with entire Forkeys going belly-up and leaving its users standing in the rain with unmaintained server software. I mean, I guess we all know how volatile Forkeys tend to be. Not only could people move around from server to server with ease and take everything with them, but they could also try out new Forkeys (this explicitly includes Iceshrimp.NET) and still have clones on longer-lived applications like Sharkey, CherryPick or good old Misskey itself as fallbacks.
In fact, I think one reason for Sharkey's popularity is its import/export capability.
CC: @Marcus Rohrmoser 🌻 @Johannes Ernst @Tim Chambers
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #Mastodon #Misskey #Forkey #Forkeys #CherryPick #Sharkey #Iceshrimp #Iceshrimp.NET #NomadicIdentity -
@Chris Alemany🇺🇦🇨🇦🇪🇸 The Mastodon devs are talking as if either the Fediverse is only Mastodon, or the Fediverse as a whole doesn't have quote-posts.
Neither of this is true. The Fediverse has had quote-posts since July 2nd, 2010 when Mistpark (now known as Friendica) was launched. Mastodon toots have been quote-post-able since Mastodon itself was launched, for when Mastodon was launched, it immediately federated with at least two Fediverse server applications that have quote-posts, namely Friendica and Hubzilla, a fork of a fork of Friendica by Friendica's own creator.
Nowadays, at least Pleroma, Akkoma, all other Pleroma forks, Misskey, Calckey, Firefish, Iceshrimp-JS, Iceshrimp.NET, CherryPick, Sharkey, all other Misskey forks, Mitra, Friendica, Hubzilla, (streams) and Forte can quote-post Mastodon toots with no problem.
And Mastodon won't be able to stop them. No, seriously, it won't. Not with a non-standard, proprietary, home-brew opt-in or opt-out switch that doesn't tie into anything that the other Fediverse server apps have. And whatever switch Mastodon is working on will not tie into anything that already exists.
Let me put it this way: Hubzilla has the second-most advanced and fine-grained permissions system in the Fediverse. It goes well beyond most people's imagination. It works on three levels: for the whole channel (that's similar to a Mastodon account), for individual contacts (that's "followers" in Mastodon lingo, but Hubzilla doesn't distinguish between followers and followed), for individual content. (streams) and Forte are the only ones with an even more advanced and fine-grained permissions system.
But even they don't have a quote-post permission setting. And they have permission settings for just about everything. You want reply control in the Fediverse? Hubzilla has reply control, and (streams) and Forte have reply control on steroids. But what they don't have is a quote-posting permission because that's next to impossible to control across the Fediverse even with the most advanced permissions system.
As @Mike Macgirvin ?️ (professional software developer for almost half a century, designer of two Fediverse protocols, creator of Friendica and Hubzilla, inventor of nomadic identity, creator and maintainer of (streams) and Forte) says: The only way to make your posts un-quote-post-able is by not posting in public and not allowing everyone in the Fediverse full access to your posts. Set your "Who can quote" however you want, I'll always be able to quote-post all your public posts with no problem and with no resistance.
So what chance does Mastodon have then? Mastodon which doesn't even know what permissions are? Developed by Eugen Rochko who actually has a history of head-butting with Mike Macgirvin, and who would never take any step towards anything that Mike has ever developed?
I'm commenting from Hubzilla right now, and I'm also on (streams). And I can tell you: If you make any of your posts "un-quote-post-able", this still won't make my Share buttons on Hubzilla and (streams) disappear.
CC: @Stefan Bohacek @FinchHaven sfba
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #Mastodon #Pleroma #Akkoma #Misskey #Forkey #Forkeys #Calckey #Firefish #Iceshrimp #Iceshrimp.NET #CherryPick #Sharkey #Mitra #Friendica #Hubzilla #Streams #(streams) #Forte #QuotePost #QuotePosts #QuoteTweet #QuoteTweets #QuoteToot #QuoteToots #QuoteBoost #QuoteBoosts #QuotePostDebate #QuoteTootDebate -
@PaulaToThePeople It isn't just a matter of consent. Besides, for example, I do have quote-post control here on Hubzilla.
I can give permission to quote-post my posts to- everyone in the Fediverse
- everyone on Hubzilla and (streams)
- everyone on this hub
- approved and unapproved connections
- only approved connections
- only those of my connections whom I explicitly give permission by contact role
- nobody but myself
Over on (streams), I can still give that permission to- everyone in the Fediverse
- all my connections
- only myself + specific connections whom I grant that permission either by permission role or by individual connection settings
It's much more a matter of technology.
Mastodon is about to completely re-invent the wheel with a non-standard, Mastodon-only setting. This setting will only work within Mastodon simply because it probably won't even be documented anywhere, especially not before it's officially rolled out.
There simply is no way that every last instance of Pleroma, Akkoma, Misskey, Calckey, Firefish, Iceshrimp, CherryPick, Catodon, Meisskey, Tanukey, Neko, dozens of other Misskey forks, Friendica, Hubzilla, (streams), Forte etc. etc. will have that setting implemented before Mastodon rolls it out so that even the users on mastodon.social are perfectly safe from the first second on.
Besides, @Mike Macgirvin 🖥️, creator of Friendica, Hubzilla, (streams) and Forte and still the only maintainer of the latter two, will never introduce proprietary Mastodon features to them. He'd rather risk (streams) and Forte becoming incompatible with Mastodon. The same goes for @Mario Vavti and @Harald Eilertsen, Hubzilla's main maintainers.
If Mastodon wants to become a perfectly safe haven against unallowed quote-posting, it has only got one choice: It must introduce something like (streams)' and Forte's user agent filter and use it to block just everything that isn't Mastodon. Like, include a hard-coded allowlist that only includes Mastodon plus what little can't quote or quote-post anyway.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #Mastodon #Pleroma #Akkoma #Misskey #Forkey #Forkeys #Calckey #Firefish #Iceshrimp #CherryPick #Sharkey #Catodon #Friendica #Hubzilla #Streams #(streams) #Forte #QuotePost #QuotePosts #QuoteTweet #QuoteTweets #QuoteToot #QuoteToots #QuoteBoost #QuoteBoosts #QuotedShares #QuotePostDebate #QuoteTootDebate -
@JustBob Discord has completely warped the term "server" for entire generations of Internet users. On Discord, "server" means "chatroom".
In the Fediverse, "server" doesn't mean "chatroom". It means "server". A computer.
For example, a rack computer with no screen and no keyboard and no mouse bolted into a server rack at a data centre.
Or an old laptop that someone had lying around or a Raspberry Pi mini-computer running at someone's home, connected to their landline.
On each one of these, a big or small Twitter can be running (Mastodon).
Or a wholly different Twitter (Pleroma, Akkoma, Misskey, Calckey, Firefish, Iceshrimp, Sharkey, Catodon, Meisskey, Tanukey, Neko...).
(Here's the first important new thing for you to learn about the Fediverse: The Fediverse is not only Mastodon.)
Or a Facebook with a side of a blog and a cloud server (Friendica, (streams), Forte).
(Here's the second important new thing for you to learn about the Fediverse: The Fediverse is not only short-form microblogging. Look at this comment. Look at what I've done. Embedded links. Bold type. Impossible on Mastodon. But possible elsewhere in the Fediverse.)
Or a Facebook meets WordPress meets Google Cloud Services meets even more stuff on top (Hubzilla; this is where I am).
Or an Instagram (Pixelfed).
Or a YouTube (PeerTube).
Or a Twitch (Owncast).
Or a Reddit (Lemmy, /kbin, Mbin, PieFed).
Or a Goodreads (BookWyrm).
Or whatever. There are over 150 different server applications in the Fediverse.
mastodon.social, where you are, is only one of over 10,000 big and small Twitters of the same kind (Mastodon).
If Mastodon was like Discord, all 10,000+ Mastodon servers would run in one and the same gigantic data centre in the USA, owned by Mastodon, Inc. And they would all be property of Mastodon, Inc.
If the Fediverse was like Discord, all 30,000+ Fediverse servers would run in one and the same gigantic data centre in the USA, owned by Mastodon, Inc. And they would all be property of Mastodon, Inc. Also, they would be fully identical in functionality.
But as I've said above: They're all running on their own separate machines. With their own separate owners.
And the different server applications have different developers, and they are being developed independently from one another.
Okay, now comes the kicker: These server applications are not walled up against one another. Not only are all instances of the same server applications (e.g. Mastodon) connected to each other, but all instances of one server application are also connected to all instances of all the other server applications.
Imagine you're on Twitter. But your new friend is on Facebook. You can't follow a Facebook user on Twitter, and you can't follow a Twitter user on Facebook.
In the Fediverse, you can. You can be on Twitter. And follow a Facebook user. Directly from Twitter. Without a Facebook account.
Only that they aren't named Twitter and Facebook in the Fediverse. Twitter is named Mastodon or Pleroma or Akkoma or Misskey or Calckey or Firefish or Iceshrimp or Sharkey or Catodon or... There are dozens of Twitter alternatives in the Fediverse. Well, and Facebook is named Friendica or Hubzilla or (streams) or Forte.
You can be on Mastodon. And you can follow Friendica accounts. From Mastodon. Without a Friendica account.
This comment is a very good example. You are on Mastodon, created by @Eugen Rochko in 2016 as an alternative to Twitter that aimed to be as close to Twitter as possible.
The server that you're on, mastodon.social, is owned by Mastodon, Inc. and running on one or multiple rack servers in San Francisco, California, USA owned by Fastly.
I am on Hubzilla, created by @Mike Macgirvin 🖥️ in 2012 by forking his own Friendica from 2010, and currently mainly maintained by @Mario Vavti and @Harald Eilertsen. Hubzilla has got nothing to do with Mastodon whatsoever. It started out as an alternative to Facebook, but not a clone, rather better than Facebook, with full-blown long-form blogging capability and a built-in file storage, and it has been enhanced greatly in functionality even beyond that.
The server that I'm on, Netzgemeinde, is owned and administered by @Mark Nowiasz, who has no affiliation with the Hubzilla developers, and running on a rack server in Nuremberg, Germany owned by Netcup.
And yet, you can see this comment coming from Hubzilla on Mastodon.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #Server #Instance #Mastodon #Pleroma #Akkoma #Misskey #Forkey #Forkeys #Calckey #Firefish #Iceshrimp #Sharkey #Catodon #Meisskey #Tanukey #Neko #Friendica #Hubzilla #Streams #(streams) #Forte #Pixelfed #PeerTube #Owncast #Lemmy #/kbin #Mbin #PieFed #BookWyrm #NotOnlyMastodon #FediverseIsNotMastodon #MastodonIsNotTheFediverse -
#fediverse #bot #idea: Take a #random #word from #Wiktionary's Category:Russian terms suffixed with -ский but in the #Latin #transliteration replace the #kij (or #кий) in #ский (#skij) with #key, as if a new #Misskey #forkey #fork has just dropped to compete with #Sharkey :sagume_think:
So "ааро́новский" becomes "aarónovskey" for example :chuckling_okuu:
RE: https://makai.chaotic.ninja/notes/9ov7gpenpt