#forkey — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #forkey, aggregated by home.social.
-
Just discovered that Misskey actually doesn't truncate alt-texts with over 512 characters, but it silently discards them entirely. If your alt-text is longer than 512 characters, this gives the impression that you're too lazy to write alt-texts altogether.
https://github.com/misskey-dev/misskey/issues/13823
I don't know if any Forkeys have fixed this, though.
#FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Misskey #Forkey #Forkeys #AltText #AltTextMeta #CWAltTextMeta -
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 @Silvia Auf *key ist doch sowieso jeder eine potentielle Katze.
#FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Misskey #Forkey #Forkeys -
@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 -
@Rob Ricci Maybe this is interesting for you:
(streams) had almost all nodeinfo code intentionally removed. This was done to keep (streams) from being crawled by instance-listing websites and dragged into competitions between server applications and particular servers.
Also, (streams) does not have a unified instance type identifier. Server admins may not only enter their own name for the server, but also their own custom instance type. If no instance type is given, (streams) uses the first word in the server name as the instance type.
Likewise, Forte's stats being reported as zero is fully intentional in order to keep it out of competitions. I'd be very surprised if there was an ActivityPub-compliant way around this.
By the way, here is a correction: Iceshrimp.NET is not a Misskey fork. It is being rewritten from the ground up in C# whereas Misskey and all Forkeys are written in TypeScript and Vue.js.
A few more Forkeys, dead or alive:- Tanukey (you've listed it elsewhere)
- Neko
- Catodon
- Hajkey
- Metaskey
- Backspacekey
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Streams #(streams) #Forte #Forkey #Forkeys #nodeinfo -
@Rob Ricci Maybe this is interesting for you:
(streams) had almost all nodeinfo code intentionally removed. This was done to keep (streams) from being crawled by instance-listing websites and dragged into competitions between server applications and particular servers.
Also, (streams) does not have a unified instance type identifier. Server admins may not only enter their own name for the server, but also their own custom instance type. If no instance type is given, (streams) uses the first word in the server name as the instance type.
Likewise, Forte's stats being reported as zero is fully intentional in order to keep it out of competitions. I'd be very surprised if there was an ActivityPub-compliant way around this.
By the way, here is a correction: Iceshrimp.NET is not a Misskey fork. It is being rewritten from the ground up in C# whereas Misskey and all Forkeys are written in TypeScript and Vue.js.
A few more Forkeys, dead or alive:- Tanukey (you've listed it elsewhere)
- Neko
- Catodon
- Hajkey
- Metaskey
- Backspacekey
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Streams #(streams) #Forte #Forkey #Forkeys #nodeinfo -
@Rob Ricci Maybe this is interesting for you:
(streams) had almost all nodeinfo code intentionally removed. This was done to keep (streams) from being crawled by instance-listing websites and dragged into competitions between server applications and particular servers.
Also, (streams) does not have a unified instance type identifier. Server admins may not only enter their own name for the server, but also their own custom instance type. If no instance type is given, (streams) uses the first word in the server name as the instance type.
Likewise, Forte's stats being reported as zero is fully intentional in order to keep it out of competitions. I'd be very surprised if there was an ActivityPub-compliant way around this.
By the way, here is a correction: Iceshrimp.NET is not a Misskey fork. It is being rewritten from the ground up in C# whereas Misskey and all Forkeys are written in TypeScript and Vue.js.
A few more Forkeys, dead or alive:- Tanukey (you've listed it elsewhere)
- Neko
- Catodon
- Hajkey
- Metaskey
- Backspacekey
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Streams #(streams) #Forte #Forkey #Forkeys #nodeinfo -
@Rob Ricci Maybe this is interesting for you:
(streams) had almost all nodeinfo code intentionally removed. This was done to keep (streams) from being crawled by instance-listing websites and dragged into competitions between server applications and particular servers.
Also, (streams) does not have a unified instance type identifier. Server admins may not only enter their own name for the server, but also their own custom instance type. If no instance type is given, (streams) uses the first word in the server name as the instance type.
Likewise, Forte's stats being reported as zero is fully intentional in order to keep it out of competitions. I'd be very surprised if there was an ActivityPub-compliant way around this.
By the way, here is a correction: Iceshrimp.NET is not a Misskey fork. It is being rewritten from the ground up in C# whereas Misskey and all Forkeys are written in TypeScript and Vue.js.
A few more Forkeys, dead or alive:- Tanukey (you've listed it elsewhere)
- Neko
- Catodon
- Hajkey
- Metaskey
- Backspacekey
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Streams #(streams) #Forte #Forkey #Forkeys #nodeinfo -
@Rob Ricci Maybe this is interesting for you:
(streams) had almost all nodeinfo code intentionally removed. This was done to keep (streams) from being crawled by instance-listing websites and dragged into competitions between server applications and particular servers.
Also, (streams) does not have a unified instance type identifier. Server admins may not only enter their own name for the server, but also their own custom instance type. If no instance type is given, (streams) uses the first word in the server name as the instance type.
Likewise, Forte's stats being reported as zero is fully intentional in order to keep it out of competitions. I'd be very surprised if there was an ActivityPub-compliant way around this.
By the way, here is a correction: Iceshrimp.NET is not a Misskey fork. It is being rewritten from the ground up in C# whereas Misskey and all Forkeys are written in TypeScript and Vue.js.
A few more Forkeys, dead or alive:- Tanukey (you've listed it elsewhere)
- Neko
- Catodon
- Hajkey
- Metaskey
- Backspacekey
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Streams #(streams) #Forte #Forkey #Forkeys #nodeinfo -
@tux0r :openbsd: "Forkey" bezeichnet Forks von Misskey, Forks von Forks von Misskey usw.
Iceshrimp.NET fällt da nicht drunter, weil es komplett neu geschrieben wird. Es ist vom Funktionsumfang her noch ziemlich mager. Das Ziel des Rewrite war, soweit ich weiß, zum einen, die Macken loszuwerden, die alle Forkeys von Misskey geerbt hatten, und zum anderen von JavaScript wegzukommen (Misskey und alle Forkeys sind in TypeScript und Vue.js geschrieben).
Aber gut, es gibt auch viele, die sich nicht vorstellen können, daß gute Serversoftware in PHP geschrieben sein kann. Mike Macgirvin entwickelt seit jeher in PHP. Und was er baut, ist nicht nur sehr mächtig und fortschrittlich, sondern auch noch leicht zu installieren und zu administrieren und weniger leistungshungrig als Mastodon.
Relatierter Memepost auf meinem Fediverse-Meme-Kanal.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Forkey #Forkeys #Iceshrimp.NET -
@tux0r :openbsd: "Forkey" bezeichnet Forks von Misskey, Forks von Forks von Misskey usw.
Iceshrimp.NET fällt da nicht drunter, weil es komplett neu geschrieben wird. Es ist vom Funktionsumfang her noch ziemlich mager. Das Ziel des Rewrite war, soweit ich weiß, zum einen, die Macken loszuwerden, die alle Forkeys von Misskey geerbt hatten, und zum anderen von JavaScript wegzukommen (Misskey und alle Forkeys sind in TypeScript und Vue.js geschrieben).
Aber gut, es gibt auch viele, die sich nicht vorstellen können, daß gute Serversoftware in PHP geschrieben sein kann. Mike Macgirvin entwickelt seit jeher in PHP. Und was er baut, ist nicht nur sehr mächtig und fortschrittlich, sondern auch noch leicht zu installieren und zu administrieren und weniger leistungshungrig als Mastodon.
Relatierter Memepost auf meinem Fediverse-Meme-Kanal.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Forkey #Forkeys #Iceshrimp.NET -
@tux0r :openbsd: "Forkey" bezeichnet Forks von Misskey, Forks von Forks von Misskey usw.
Iceshrimp.NET fällt da nicht drunter, weil es komplett neu geschrieben wird. Es ist vom Funktionsumfang her noch ziemlich mager. Das Ziel des Rewrite war, soweit ich weiß, zum einen, die Macken loszuwerden, die alle Forkeys von Misskey geerbt hatten, und zum anderen von JavaScript wegzukommen (Misskey und alle Forkeys sind in TypeScript und Vue.js geschrieben).
Aber gut, es gibt auch viele, die sich nicht vorstellen können, daß gute Serversoftware in PHP geschrieben sein kann. Mike Macgirvin entwickelt seit jeher in PHP. Und was er baut, ist nicht nur sehr mächtig und fortschrittlich, sondern auch noch leicht zu installieren und zu administrieren und weniger leistungshungrig als Mastodon.
Relatierter Memepost auf meinem Fediverse-Meme-Kanal.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Forkey #Forkeys #Iceshrimp.NET -
@Herr TurTur @crossgolf_rebel - kostenlose Kwalitätsposts @tux0r :openbsd: Die Idee hinter Sharkey war mal, in einen einzigen Forkey quasi alles auf einmal reinzuschmeißen bis hin zur Küchenspüle. Das fiel vor allem auf, als es noch mehr lebendige Forkeys zur Auswahl gab.
Und in der Zeit hatte Sharkey auch noch gewisse Macken, z. B. eine schon legendär unzuverlässige Implementation der Mastodon Client API, wo es hieß, am besten setzt sich einer hin und schreibt die neu. Wer was Zuverlässiges wollte, setzte damals auf Iceshrimp. Sharkey war für wagemutige Spielkinder, die sich an Hubzilla nicht rantrauten.
Inzwischen ist Calckey tot, Firefish ist tot, Iceshrimp-JS ist im Wartungsmodus (Iceshrimp.NET ist derweil noch meilenweit von "fertig" entfernt), Catodon ist auch schon siech, und das nur für eine Instanz gebaute Hajkey ist schon verwest.
CherryPick hat fast nur Server in den Großräumen Tokyo und Seoul und fühlt sich so auf den ostasiatischen Geschmack ausgelegt an wie vor ein paar Jahren noch Misskey selbst. Vielleicht erinnern sich ein paar noch daran, wie Misskey mal den Charme japanischer Verkaufsautomaten hatte.
Und der ganze noch lebende Rest scheint selbst mit Misskeys Entwicklung nicht mithalten zu können, also im Kern veraltet zu sein.
Derweil ist Sharkey wohl inzwischen ziemlich zuverlässig. So ist es zumindest im Westen zum einzigen noch nennenswerten Forkey avanciert.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Misskey #Forkey #Forkeys #Sharkey #Calckey #Firefish #Iceshrimp #Iceshrimp-JS #Iceshrimp.NET #Catodon #Hajkey #CherryPick -
@Herr TurTur @crossgolf_rebel - kostenlose Kwalitätsposts @tux0r :openbsd: Die Idee hinter Sharkey war mal, in einen einzigen Forkey quasi alles auf einmal reinzuschmeißen bis hin zur Küchenspüle. Das fiel vor allem auf, als es noch mehr lebendige Forkeys zur Auswahl gab.
Und in der Zeit hatte Sharkey auch noch gewisse Macken, z. B. eine schon legendär unzuverlässige Implementation der Mastodon Client API, wo es hieß, am besten setzt sich einer hin und schreibt die neu. Wer was Zuverlässiges wollte, setzte damals auf Iceshrimp. Sharkey war für wagemutige Spielkinder, die sich an Hubzilla nicht rantrauten.
Inzwischen ist Calckey tot, Firefish ist tot, Iceshrimp-JS ist im Wartungsmodus (Iceshrimp.NET ist derweil noch meilenweit von "fertig" entfernt), Catodon ist auch schon siech, und das nur für eine Instanz gebaute Hajkey ist schon verwest.
CherryPick hat fast nur Server in den Großräumen Tokyo und Seoul und fühlt sich so auf den ostasiatischen Geschmack ausgelegt an wie vor ein paar Jahren noch Misskey selbst. Vielleicht erinnern sich ein paar noch daran, wie Misskey mal den Charme japanischer Verkaufsautomaten hatte.
Und der ganze noch lebende Rest scheint selbst mit Misskeys Entwicklung nicht mithalten zu können, also im Kern veraltet zu sein.
Derweil ist Sharkey wohl inzwischen ziemlich zuverlässig. So ist es zumindest im Westen zum einzigen noch nennenswerten Forkey avanciert.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Misskey #Forkey #Forkeys #Sharkey #Calckey #Firefish #Iceshrimp #Iceshrimp-JS #Iceshrimp.NET #Catodon #Hajkey #CherryPick -
@Herr TurTur @crossgolf_rebel - kostenlose Kwalitätsposts @tux0r :openbsd: Die Idee hinter Sharkey war mal, in einen einzigen Forkey quasi alles auf einmal reinzuschmeißen bis hin zur Küchenspüle. Das fiel vor allem auf, als es noch mehr lebendige Forkeys zur Auswahl gab.
Und in der Zeit hatte Sharkey auch noch gewisse Macken, z. B. eine schon legendär unzuverlässige Implementation der Mastodon Client API, wo es hieß, am besten setzt sich einer hin und schreibt die neu. Wer was Zuverlässiges wollte, setzte damals auf Iceshrimp. Sharkey war für wagemutige Spielkinder, die sich an Hubzilla nicht rantrauten.
Inzwischen ist Calckey tot, Firefish ist tot, Iceshrimp-JS ist im Wartungsmodus (Iceshrimp.NET ist derweil noch meilenweit von "fertig" entfernt), Catodon ist auch schon siech, und das nur für eine Instanz gebaute Hajkey ist schon verwest.
CherryPick hat fast nur Server in den Großräumen Tokyo und Seoul und fühlt sich so auf den ostasiatischen Geschmack ausgelegt an wie vor ein paar Jahren noch Misskey selbst. Vielleicht erinnern sich ein paar noch daran, wie Misskey mal den Charme japanischer Verkaufsautomaten hatte.
Und der ganze noch lebende Rest scheint selbst mit Misskeys Entwicklung nicht mithalten zu können, also im Kern veraltet zu sein.
Derweil ist Sharkey wohl inzwischen ziemlich zuverlässig. So ist es zumindest im Westen zum einzigen noch nennenswerten Forkey avanciert.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Misskey #Forkey #Forkeys #Sharkey #Calckey #Firefish #Iceshrimp #Iceshrimp-JS #Iceshrimp.NET #Catodon #Hajkey #CherryPick -
@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 -
@「 Jürgen 」:fedi_mastodon: Fifth class. All of them.
As I've said, everyone talks about Mastodon as "the" Twitter alternative in the Fediverse. This means that microblogging server apps that aren't Mastodon, and that don't have the same level of publicity and fame as GoToSocial and snac, are next to unknown by Mastodon's standards.
Mind you, this ranking is extremely Mastodon-centred. But Mastodon-centrism has been the default in the Fediverse for many years now.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Misskey #Forkey #Forkeys -
@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 -
@crossgolf_rebel - kostenlose Kwalitätsposts @Stadtrandler @PuschyMTB 🚴♂️🚩 Wäre an dieser Stelle nicht die nächste Fediverse-Sprechstunde erwähnenswert? Da geht es doch um die *keys. Ich kann leider nicht dabei sein.
#FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Misskey #Forkey #Forkeys #FediverseSprechstunde -
@Prof. Rachel Thorn 🍉🇺🇦🏳️⚧️🏳️
I would also be in favor of Fediblock for instances where this behavior is rampant.
Alt-text on images is only a thing on Mastodon and amongst Pixelfed users who are also on Mastodon.
Fediblocking entire servers for a too low quota of sufficiently accurate, sufficiently detailed, rule-conforming alt-text would end up defederating Mastodon from most of the rest of the Fediverse. It would end up in the Fediblocking of entire Fediverse server application types. Pleroma, Akkoma, Misskey, Calckey, Firefish, Iceshrimp-JS, Iceshrimp.NET, CherryPick, Sharkey, Catodon, Smithereen, snac, GoToSocial, Mitra, Socialhome, Friendica, Hubzilla, (streams), Forte, Lemmy, /kbin, Mbin, PieFed, nodeBB, WordPress, Ghost, Flipboard, Plume and a whole lot of others would end up being defederated from Mastodon in their entirety because they don't have alt-text (and everyone upping their game in alt-text style, accuracy and level of detail) as an integral part of their culture.
Basically, from Mastodon's point of view, the Fediverse would end up actually being only Mastodon because Mastodon would have defederated with everything else, server by server.
I think I'm the only one on Hubzilla who actually describes their images. I'm definitely the only one amongst the few dozen (streams) users who does. But even if I put more time and effort into describing images than just about anyone else in the Fediverse, I think that wouldn't be enough to save either server application from being defederated from Mastodon in their entirety as long as not everyone else adds sufficiently accurate, sufficiently detailed, rule-conforming alt-texts to every last one of their images, as cumbersome as that may be on Hubzilla.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #Mastodon #NotOnlyMastodon #FediverseIsNotMastodon #MastodonIsNotTheFediverse #Pleroma #Akkoma #Misskey #Forkey #Forkeys #Calckey #Firefish #Iceshrimp #Iceshrimp-JS #Iceshrimp.NET #CherryPick #Sharkey #Catodon #Smithereen #snac #GoToSocial #Mitra #Socialhome #Friendica #Hubzilla #Streams #(streams) #Forte #Lemmy #/kbin #Mbin #PieFed #nodeBB #WordPress #Ghost #Flipboard #Plume #AltText #AltTextMeta #CWAltTextMeta #ImageDescription #ImageDescriptions #ImageDescriptionMeta #CWImageDescriptionMeta -
@Prof. Rachel Thorn 🍉🇺🇦🏳️⚧️🏳️
I would also be in favor of Fediblock for instances where this behavior is rampant.
Alt-text on images is only a thing on Mastodon and amongst Pixelfed users who are also on Mastodon.
Fediblocking entire servers for a too low quota of sufficiently accurate, sufficiently detailed, rule-conforming alt-text would end up defederating Mastodon from most of the rest of the Fediverse. It would end up in the Fediblocking of entire Fediverse server application types. Pleroma, Akkoma, Misskey, Calckey, Firefish, Iceshrimp-JS, Iceshrimp.NET, CherryPick, Sharkey, Catodon, Smithereen, snac, GoToSocial, Mitra, Socialhome, Friendica, Hubzilla, (streams), Forte, Lemmy, /kbin, Mbin, PieFed, nodeBB, WordPress, Ghost, Flipboard, Plume and a whole lot of others would end up being defederated from Mastodon in their entirety because they don't have alt-text (and everyone upping their game in alt-text style, accuracy and level of detail) as an integral part of their culture.
Basically, from Mastodon's point of view, the Fediverse would end up actually being only Mastodon because Mastodon would have defederated with everything else, server by server.
I think I'm the only one on Hubzilla who actually describes their images. I'm definitely the only one amongst the few dozen (streams) users who does. But even if I put more time and effort into describing images than just about anyone else in the Fediverse, I think that wouldn't be enough to save either server application from being defederated from Mastodon in their entirety as long as not everyone else adds sufficiently accurate, sufficiently detailed, rule-conforming alt-texts to every last one of their images, as cumbersome as that may be on Hubzilla.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #Mastodon #NotOnlyMastodon #FediverseIsNotMastodon #MastodonIsNotTheFediverse #Pleroma #Akkoma #Misskey #Forkey #Forkeys #Calckey #Firefish #Iceshrimp #Iceshrimp-JS #Iceshrimp.NET #CherryPick #Sharkey #Catodon #Smithereen #snac #GoToSocial #Mitra #Socialhome #Friendica #Hubzilla #Streams #(streams) #Forte #Lemmy #/kbin #Mbin #PieFed #nodeBB #WordPress #Ghost #Flipboard #Plume #AltText #AltTextMeta #CWAltTextMeta #ImageDescription #ImageDescriptions #ImageDescriptionMeta #CWImageDescriptionMeta -
@Prof. Rachel Thorn 🍉🇺🇦🏳️⚧️🏳️
I would also be in favor of Fediblock for instances where this behavior is rampant.
Alt-text on images is only a thing on Mastodon and amongst Pixelfed users who are also on Mastodon.
Fediblocking entire servers for a too low quota of sufficiently accurate, sufficiently detailed, rule-conforming alt-text would end up defederating Mastodon from most of the rest of the Fediverse. It would end up in the Fediblocking of entire Fediverse server application types. Pleroma, Akkoma, Misskey, Calckey, Firefish, Iceshrimp-JS, Iceshrimp.NET, CherryPick, Sharkey, Catodon, Smithereen, snac, GoToSocial, Mitra, Socialhome, Friendica, Hubzilla, (streams), Forte, Lemmy, /kbin, Mbin, PieFed, nodeBB, WordPress, Ghost, Flipboard, Plume and a whole lot of others would end up being defederated from Mastodon in their entirety because they don't have alt-text (and everyone upping their game in alt-text style, accuracy and level of detail) as an integral part of their culture.
Basically, from Mastodon's point of view, the Fediverse would end up actually being only Mastodon because Mastodon would have defederated with everything else, server by server.
I think I'm the only one on Hubzilla who actually describes their images. I'm definitely the only one amongst the few dozen (streams) users who does. But even if I put more time and effort into describing images than just about anyone else in the Fediverse, I think that wouldn't be enough to save either server application from being defederated from Mastodon in their entirety as long as not everyone else adds sufficiently accurate, sufficiently detailed, rule-conforming alt-texts to every last one of their images, as cumbersome as that may be on Hubzilla.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #Mastodon #NotOnlyMastodon #FediverseIsNotMastodon #MastodonIsNotTheFediverse #Pleroma #Akkoma #Misskey #Forkey #Forkeys #Calckey #Firefish #Iceshrimp #Iceshrimp-JS #Iceshrimp.NET #CherryPick #Sharkey #Catodon #Smithereen #snac #GoToSocial #Mitra #Socialhome #Friendica #Hubzilla #Streams #(streams) #Forte #Lemmy #/kbin #Mbin #PieFed #nodeBB #WordPress #Ghost #Flipboard #Plume #AltText #AltTextMeta #CWAltTextMeta #ImageDescription #ImageDescriptions #ImageDescriptionMeta #CWImageDescriptionMeta -
@Prof. Rachel Thorn 🍉🇺🇦🏳️⚧️🏳️
I would also be in favor of Fediblock for instances where this behavior is rampant.
Alt-text on images is only a thing on Mastodon and amongst Pixelfed users who are also on Mastodon.
Fediblocking entire servers for a too low quota of sufficiently accurate, sufficiently detailed, rule-conforming alt-text would end up defederating Mastodon from most of the rest of the Fediverse. It would end up in the Fediblocking of entire Fediverse server application types. Pleroma, Akkoma, Misskey, Calckey, Firefish, Iceshrimp-JS, Iceshrimp.NET, CherryPick, Sharkey, Catodon, Smithereen, snac, GoToSocial, Mitra, Socialhome, Friendica, Hubzilla, (streams), Forte, Lemmy, /kbin, Mbin, PieFed, nodeBB, WordPress, Ghost, Flipboard, Plume and a whole lot of others would end up being defederated from Mastodon in their entirety because they don't have alt-text (and everyone upping their game in alt-text style, accuracy and level of detail) as an integral part of their culture.
Basically, from Mastodon's point of view, the Fediverse would end up actually being only Mastodon because Mastodon would have defederated with everything else, server by server.
I think I'm the only one on Hubzilla who actually describes their images. I'm definitely the only one amongst the few dozen (streams) users who does. But even if I put more time and effort into describing images than just about anyone else in the Fediverse, I think that wouldn't be enough to save either server application from being defederated from Mastodon in their entirety as long as not everyone else adds sufficiently accurate, sufficiently detailed, rule-conforming alt-texts to every last one of their images, as cumbersome as that may be on Hubzilla.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #Mastodon #NotOnlyMastodon #FediverseIsNotMastodon #MastodonIsNotTheFediverse #Pleroma #Akkoma #Misskey #Forkey #Forkeys #Calckey #Firefish #Iceshrimp #Iceshrimp-JS #Iceshrimp.NET #CherryPick #Sharkey #Catodon #Smithereen #snac #GoToSocial #Mitra #Socialhome #Friendica #Hubzilla #Streams #(streams) #Forte #Lemmy #/kbin #Mbin #PieFed #nodeBB #WordPress #Ghost #Flipboard #Plume #AltText #AltTextMeta #CWAltTextMeta #ImageDescription #ImageDescriptions #ImageDescriptionMeta #CWImageDescriptionMeta -
@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 -
@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 -
@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 -
@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 -
@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 -
@Julian Fietkau
I don't know if translating the absence of a FEP-044f quote policy as “not quotable” was the right decision. Maybe it wasn't.
If you use server software that has quote-posts implemented with no quote policy, I think it's rather safe to assume that you're okay with being quote-posted.
I mean, if you're on Misskey, complaining about being quote-posted is like complaining about emoji reactions, MFM shenanigans or the overall genki feeling. Misskey is not Mastodon with 3,000 characters; deal with it. And I haven't even mentioned "Speak as Cat" yet that's popular around the Forkeys.You might have seen my comment in the forum thread on a way to make it easier for platforms like Friendica to signal a free-for-all quoting permission.
I was just about to say that this goes doubly for those server applications where quote-posts are an integral part of the communication culture.
Seriously, if you're on one of these, but you don't want anyone to quote-post you, and you still insist in always posting in public, you're doing something wrong. And just as seriously, unlike Mastodon, especially the Friendica/Hubzilla/(streams)/Forte family won't mollycoddle you. If you come to stay, we expect you to know what you're doing and why.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Mastodon #Misskey #Forkey #Forkeys #Friendica #Hubzilla #Streams #(streams) #Forte #QuotePost #QuotePosts #QuoteTweet #QuoteTweets #QuoteToot #QuoteToots #QuoteBoost #QuoteBoosts #QuotedShares #FEP_044f -
@Julian Fietkau
I don't know if translating the absence of a FEP-044f quote policy as “not quotable” was the right decision. Maybe it wasn't.
If you use server software that has quote-posts implemented with no quote policy, I think it's rather safe to assume that you're okay with being quote-posted.
I mean, if you're on Misskey, complaining about being quote-posted is like complaining about emoji reactions, MFM shenanigans or the overall genki feeling. Misskey is not Mastodon with 3,000 characters; deal with it. And I haven't even mentioned "Speak as Cat" yet that's popular around the Forkeys.You might have seen my comment in the forum thread on a way to make it easier for platforms like Friendica to signal a free-for-all quoting permission.
I was just about to say that this goes doubly for those server applications where quote-posts are an integral part of the communication culture.
Seriously, if you're on one of these, but you don't want anyone to quote-post you, and you still insist in always posting in public, you're doing something wrong. And just as seriously, unlike Mastodon, especially the Friendica/Hubzilla/(streams)/Forte family won't mollycoddle you. If you come to stay, we expect you to know what you're doing and why.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Mastodon #Misskey #Forkey #Forkeys #Friendica #Hubzilla #Streams #(streams) #Forte #QuotePost #QuotePosts #QuoteTweet #QuoteTweets #QuoteToot #QuoteToots #QuoteBoost #QuoteBoosts #QuotedShares #FEP_044f -
@Julian Fietkau
I don't know if translating the absence of a FEP-044f quote policy as “not quotable” was the right decision. Maybe it wasn't.
If you use server software that has quote-posts implemented with no quote policy, I think it's rather safe to assume that you're okay with being quote-posted.
I mean, if you're on Misskey, complaining about being quote-posted is like complaining about emoji reactions, MFM shenanigans or the overall genki feeling. Misskey is not Mastodon with 3,000 characters; deal with it. And I haven't even mentioned "Speak as Cat" yet that's popular around the Forkeys.You might have seen my comment in the forum thread on a way to make it easier for platforms like Friendica to signal a free-for-all quoting permission.
I was just about to say that this goes doubly for those server applications where quote-posts are an integral part of the communication culture.
Seriously, if you're on one of these, but you don't want anyone to quote-post you, and you still insist in always posting in public, you're doing something wrong. And just as seriously, unlike Mastodon, especially the Friendica/Hubzilla/(streams)/Forte family won't mollycoddle you. If you come to stay, we expect you to know what you're doing and why.
#Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Mastodon #Misskey #Forkey #Forkeys #Friendica #Hubzilla #Streams #(streams) #Forte #QuotePost #QuotePosts #QuoteTweet #QuoteTweets #QuoteToot #QuoteToots #QuoteBoost #QuoteBoosts #QuotedShares #FEP_044f