#iceshrimp — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #iceshrimp, aggregated by home.social.
-
J'en peux plus, pourquoi tant de haine :pikasob:
yarn build ____ __ _ / _/_______ _____/ /_ _____(_)___ ___ ____ / // ___/ _ \/ ___/ __ \/ ___/ / __ `__ \/ __ \ _/ // /__/ __(__ ) / / / / / / / / / / / /_/ / /___/\___/\___/____/_/ /_/_/ /_/_/ /_/ /_/ .___/ /_/ Currently building Iceshrimp! Hang on for a moment, as this may take a while. [iceshrimp-sdk]: TypeError: Cannot convert undefined or null to object [iceshrimp-sdk]: at JoyCon.recusivelyResolve (file:///home/fediverse/iceshrimp/.yarn/cache/joycon-npm-3.1.1-3033e0e5f4-4b36e34791.zip/node_modules/joycon/lib/index.js:80:30) [iceshrimp-sdk]: at async loadTsupConfig (file:///home/fediverse/iceshrimp/.yarn/__virtual__/tsup-virtual-4b773fcf67/0/cache/tsup-npm-8.5.1-41f4f7d59b-f1927ec2dd.zip/node_modules/tsup/dist/chunk-VGC3FXLU.js:33:22) [iceshrimp-sdk]: at async build (file:///home/fediverse/iceshrimp/.yarn/__virtual__/tsup-virtual-4b773fcf67/0/cache/tsup-npm-8.5.1-41f4f7d59b-f1927ec2dd.zip/node_modules/tsup/dist/index.js:1489:51) [iceshrimp-sdk]: at async CAC. (file:///home/fediverse/iceshrimp/.yarn/__virtual__/tsup-virtual-4b773fcf67/0/cache/tsup-npm-8.5.1-41f4f7d59b-f1927ec2dd.zip/node_modules/tsup/dist/chunk-DI5BO6XE.js:143:5) [iceshrimp-sdk]: at async main (file:///home/fediverse/iceshrimp/.yarn/__virtual__/tsup-virtual-4b773fcf67/0/cache/tsup-npm-8.5.1-41f4f7d59b-f1927ec2dd.zip/node_modules/tsup/dist/chunk-DI5BO6XE.js:148:3) The command failed in workspace iceshrimp-sdk@workspace:packages/iceshrimp-sdk with exit code 1 The command failed for workspaces that are depended upon by other workspaces; can't satisfy the dependency graph Failed with errors in 1s 623ms
#Iceshrimp -
Ob ich mir mal eine #iceshrimp Instanz einrichten soll? -
Do MissKey & IceShrimp have the same DDos behaviour as Mastodon when doing link preview fetching?
Looking at user agents in access logs to see what I should filter out to get a better understand on what's actually read..
Since it's #caturday, here's some kind of cat 😽
Mastodon preview fetching: https://github.com/mastodon/mastodon/issues/4486
-
Dites les admins de #iceshrimp : je remarque que j'ai énormément de place prise dans le répertoire files (+- 30 Go pour 160000 fichiers)
Est-ce que je peux faire du nettoyage là dedans avant une MAJ ?
J'ai des fichiers de 2023 qui trainent, je sais pas trop à quoi ça correspond. -
Fedistar v1.12.6
=> https://fedistar.netMulti-column Fediverse client application for desktop
- Supporting SNS
- - Mastodon
- - Pleroma
- - Friendica
- - Firefish
- - Gotosocial
- - Pixelfed
- - Akkoma (Unofficial)
- - Sharkey (Unofficial)
- - Hometown (Unofficial)
- - Iceshrimp (Unofficial)
- Multiple accounts management
- Multiple columns
- You can see timelines without sign in
- Desktop notification
- Streaming update
- Send reactions from another accounts
- Change column widthChangelog:
=> https://github.com/h3poteto/fedistar/releases/tag/v1.12.6#Fediverse #Mastodon #Pleroma #Friendica #Firefish #Gotosocial #Pixelfed #Akkoma #Sharkey #Hometown #Iceshrimp
-
As a reminder: I am offering free Iceshrimp.NET fediverse hosting on OP5+’s. Contact me for details.
-
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 -
and while i'm on that topic, out of curiosity, is it easy to change the fedi server software while retaining accounts, files, posts, federation - data in general without major breaking changes?
#fediadmin #misskey #sharkey #iceshrimp #pleroma -
Vielleicht sollten wir Bewohner der föderierten Planeten des #Fediverse den Menschen, die #neuhier sind, etwas erklären:
#DasFediverseIstMehr als Mastodon.
In den unendlichen Weiten der digitalen Unabhängigkeit befinden sich so viele Möglichkeiten , das für jede*n etwas dabei ist. Das kann natürlich #Mastodon sein, aber auch:
Microblogging Planeten
#Akkoma
#GoToSocial
#Iceshrimp
#Misskey
#Pleroma
#Sharkey
Die Macroblogging Planeten
#diaspora*
#Friendica
#Hubzilla
#(streams)
Die Fotografie Planeten
#Pixelfed
#Vernissage
Die Publishing Planeten
#Drupal
#Ghost
#Plume
#WordPress
#WriteFreely
Die Video & Live Planeten
#Loops
#Owncast
#Peer Tube
Die Audio & Podcasts.Planeten
#Castopod
#Funkwhale
Der Kalender & Events Planet
#Mobilizon
Der Foren & Diskussionen Planet
Lemmy
Und der Bücher Planet
#BookWyrm
Eine knappe Übersicht gibt es hier:
https://fediversum.info/fediverse-software-und-dienste/
Vielleicht sollten wir Bewohner der föderierten Planeten, aber auch berichten, warum wir unseren Planeten bewohnen und was wir an ihm lieben.
Und wie spannend wäre es zu erfahren, was wie es ist seinen ganz eigenen Planeten zu haben und was man tun muss um ihn zu erschaffen und sich bei Bedarf Mitbewohner zu suchen.
Das Fediverse ist so spannend. Wir sollten davon erzählen, damit die neuen Fediversebewohner neugierig werden und den perfekten Platz für sich finden können. Und auch wir alteingesessenen #Fedinauten lernen immer noch dazu.
Also lasst uns unsere Geschichten erzählen, über unsere Heimatplaneten berichten.
Unter den Hashtags #DasFediverseIstMehr #WirSindFedi #Fediliebe fange ich gleich mit einem ersten Post an. Und ihr, Fedinaut*innen der Planetenrunde?
#DigitaleSouveränität #DIDit #diversität #DasFediverseErzählt -
Vielleicht sollten wir Bewohner der föderierten Planeten des #Fediverse den Menschen, die #neuhier sind, etwas erklären:
#DasFediverseIstMehr als Mastodon.
In den unendlichen Weiten der digitalen Unabhängigkeit befinden sich so viele Möglichkeiten , das für jede*n etwas dabei ist. Das kann natürlich #Mastodon sein, aber auch:
Microblogging Planeten
#Akkoma
#GoToSocial
#Iceshrimp
#Misskey
#Pleroma
#Sharkey
Die Macroblogging Planeten
#diaspora*
#Friendica
#Hubzilla
#(streams)
Die Fotografie Planeten
#Pixelfed
#Vernissage
Die Publishing Planeten
#Drupal
#Ghost
#Plume
#WordPress
#WriteFreely
Die Video & Live Planeten
#Loops
#Owncast
#Peer Tube
Die Audio & Podcasts.Planeten
#Castopod
#Funkwhale
Der Kalender & Events Planet
#Mobilizon
Der Foren & Diskussionen Planet
Lemmy
Und der Bücher Planet
#BookWyrm
Eine knappe Übersicht gibt es hier:
https://fediversum.info/fediverse-software-und-dienste/
Vielleicht sollten wir Bewohner der föderierten Planeten, aber auch berichten, warum wir unseren Planeten bewohnen und was wir an ihm lieben.
Und wie spannend wäre es zu erfahren, was wie es ist seinen ganz eigenen Planeten zu haben und was man tun muss um ihn zu erschaffen und sich bei Bedarf Mitbewohner zu suchen.
Das Fediverse ist so spannend. Wir sollten davon erzählen, damit die neuen Fediversebewohner neugierig werden und den perfekten Platz für sich finden können. Und auch wir alteingesessenen #Fedinauten lernen immer noch dazu.
Also lasst uns unsere Geschichten erzählen, über unsere Heimatplaneten berichten.
Unter den Hashtags #DasFediverseIstMehr #WirSindFedi #Fediliebe fange ich gleich mit einem ersten Post an. Und ihr, Fedinaut*innen der Planetenrunde?
#DigitaleSouveränität #DIDit #diversität #DasFediverseErzählt -
Vielleicht sollten wir Bewohner der föderierten Planeten des #Fediverse den Menschen, die #neuhier sind, etwas erklären:
#DasFediverseIstMehr als Mastodon.
In den unendlichen Weiten der digitalen Unabhängigkeit befinden sich so viele Möglichkeiten , das für jede*n etwas dabei ist. Das kann natürlich #Mastodon sein, aber auch:
Microblogging Planeten
#Akkoma
#GoToSocial
#Iceshrimp
#Misskey
#Pleroma
#Sharkey
Die Macroblogging Planeten
#diaspora*
#Friendica
#Hubzilla
#(streams)
Die Fotografie Planeten
#Pixelfed
#Vernissage
Die Publishing Planeten
#Drupal
#Ghost
#Plume
#WordPress
#WriteFreely
Die Video & Live Planeten
#Loops
#Owncast
#Peer Tube
Die Audio & Podcasts.Planeten
#Castopod
#Funkwhale
Der Kalender & Events Planet
#Mobilizon
Der Foren & Diskussionen Planet
Lemmy
Und der Bücher Planet
#BookWyrm
Eine knappe Übersicht gibt es hier:
https://fediversum.info/fediverse-software-und-dienste/
Vielleicht sollten wir Bewohner der föderierten Planeten, aber auch berichten, warum wir unseren Planeten bewohnen und was wir an ihm lieben.
Und wie spannend wäre es zu erfahren, was wie es ist seinen ganz eigenen Planeten zu haben und was man tun muss um ihn zu erschaffen und sich bei Bedarf Mitbewohner zu suchen.
Das Fediverse ist so spannend. Wir sollten davon erzählen, damit die neuen Fediversebewohner neugierig werden und den perfekten Platz für sich finden können. Und auch wir alteingesessenen #Fedinauten lernen immer noch dazu.
Also lasst uns unsere Geschichten erzählen, über unsere Heimatplaneten berichten.
Unter den Hashtags #DasFediverseIstMehr #WirSindFedi #Fediliebe fange ich gleich mit einem ersten Post an. Und ihr, Fedinaut*innen der Planetenrunde?
#DigitaleSouveränität #DIDit #diversität #DasFediverseErzählt -
Vielleicht sollten wir Bewohner der föderierten Planeten des #Fediverse den Menschen, die #neuhier sind, etwas erklären:
#DasFediverseIstMehr als Mastodon.
In den unendlichen Weiten der digitalen Unabhängigkeit befinden sich so viele Möglichkeiten , das für jede*n etwas dabei ist. Das kann natürlich #Mastodon sein, aber auch:
Microblogging Planeten
#Akkoma
#GoToSocial
#Iceshrimp
#Misskey
#Pleroma
#Sharkey
Die Macroblogging Planeten
#diaspora*
#Friendica
#Hubzilla
#(streams)
Die Fotografie Planeten
#Pixelfed
#Vernissage
Die Publishing Planeten
#Drupal
#Ghost
#Plume
#WordPress
#WriteFreely
Die Video & Live Planeten
#Loops
#Owncast
#Peer Tube
Die Audio & Podcasts.Planeten
#Castopod
#Funkwhale
Der Kalender & Events Planet
#Mobilizon
Der Foren & Diskussionen Planet
Lemmy
Und der Bücher Planet
#BookWyrm
Eine knappe Übersicht gibt es hier:
https://fediversum.info/fediverse-software-und-dienste/
Vielleicht sollten wir Bewohner der föderierten Planeten, aber auch berichten, warum wir unseren Planeten bewohnen und was wir an ihm lieben.
Und wie spannend wäre es zu erfahren, was wie es ist seinen ganz eigenen Planeten zu haben und was man tun muss um ihn zu erschaffen und sich bei Bedarf Mitbewohner zu suchen.
Das Fediverse ist so spannend. Wir sollten davon erzählen, damit die neuen Fediversebewohner neugierig werden und den perfekten Platz für sich finden können. Und auch wir alteingesessenen #Fedinauten lernen immer noch dazu.
Also lasst uns unsere Geschichten erzählen, über unsere Heimatplaneten berichten.
Unter den Hashtags #DasFediverseIstMehr #WirSindFedi #Fediliebe fange ich gleich mit einem ersten Post an. Und ihr, Fedinaut*innen der Planetenrunde?
#DigitaleSouveränität #DIDit #diversität #DasFediverseErzählt -
Vielleicht sollten wir Bewohner der föderierten Planeten des #Fediverse den Menschen, die #neuhier sind, etwas erklären:
#DasFediverseIstMehr als Mastodon.
In den unendlichen Weiten der digitalen Unabhängigkeit befinden sich so viele Möglichkeiten , das für jede*n etwas dabei ist. Das kann natürlich #Mastodon sein, aber auch:
Microblogging Planeten
#Akkoma
#GoToSocial
#Iceshrimp
#Misskey
#Pleroma
#Sharkey
Die Macroblogging Planeten
#diaspora*
#Friendica
#Hubzilla
#(streams)
Die Fotografie Planeten
#Pixelfed
#Vernissage
Die Publishing Planeten
#Drupal
#Ghost
#Plume
#WordPress
#WriteFreely
Die Video & Live Planeten
#Loops
#Owncast
#Peer Tube
Die Audio & Podcasts.Planeten
#Castopod
#Funkwhale
Der Kalender & Events Planet
#Mobilizon
Der Foren & Diskussionen Planet
Lemmy
Und der Bücher Planet
#BookWyrm
Eine knappe Übersicht gibt es hier:
https://fediversum.info/fediverse-software-und-dienste/
Vielleicht sollten wir Bewohner der föderierten Planeten, aber auch berichten, warum wir unseren Planeten bewohnen und was wir an ihm lieben.
Und wie spannend wäre es zu erfahren, was wie es ist seinen ganz eigenen Planeten zu haben und was man tun muss um ihn zu erschaffen und sich bei Bedarf Mitbewohner zu suchen.
Das Fediverse ist so spannend. Wir sollten davon erzählen, damit die neuen Fediversebewohner neugierig werden und den perfekten Platz für sich finden können. Und auch wir alteingesessenen #Fedinauten lernen immer noch dazu.
Also lasst uns unsere Geschichten erzählen, über unsere Heimatplaneten berichten.
Unter den Hashtags #DasFediverseIstMehr #WirSindFedi #Fediliebe fange ich gleich mit einem ersten Post an. Und ihr, Fedinaut*innen der Planetenrunde?
#DigitaleSouveränität #DIDit #diversität #DasFediverseErzählt -
Ich muss ja zugeben, die interne Übersetzungsfunktion in Sharkey ist schon eine feine Lösung. Schade, dass das Misskey und Iceshrimp nicht so haben.
#Sharkey
#Misskey
#Iceshrimp -
Hallo liebe Fediverse-Admins,
ich bin auf der Suche nach einer Botpolicy für Anubis in Kombination mit Iceshrimp.
Meine aktuelle Policy ist folgende: paste.obco.pro/upload/dRGDKe
Jedoch scheint damit das Iceshrimp UI nicht richtig zu laden. Also der Feed und die Benachrichtigungen laden nicht richtig.
Hier ist der Browserlog: paste.obco.pro/upload/er0w4b
Wenn jemand eine Idee oder eine Policy hat, welche mit Iceshrimp funktioniert, wäre ich sehr dankbar.
:boost_animated: :blahaj: :rosahaj_thinking:
#fedimin #fedimins #iceshrimp #iceshrimpjs #anubis -
Hallo liebe Fediverse-Admins,
ich bin auf der Suche nach einer Botpolicy für Anubis in Kombination mit Iceshrimp.
Meine aktuelle Policy ist folgende: paste.obco.pro/upload/dRGDKe
Jedoch scheint damit das Iceshrimp UI nicht richtig zu laden. Also der Feed und die Benachrichtigungen laden nicht richtig.
Hier ist der Browserlog: paste.obco.pro/upload/er0w4b
Wenn jemand eine Idee oder eine Policy hat, welche mit Iceshrimp funktioniert, wäre ich sehr dankbar.
:boost_animated: :blahaj: :rosahaj_thinking:
#fedimin #fedimins #iceshrimp #iceshrimpjs #anubis -
Hallo liebe Fediverse-Admins,
ich bin auf der Suche nach einer Botpolicy für Anubis in Kombination mit Iceshrimp.
Meine aktuelle Policy ist folgende: paste.obco.pro/upload/dRGDKe
Jedoch scheint damit das Iceshrimp UI nicht richtig zu laden. Also der Feed und die Benachrichtigungen laden nicht richtig.
Hier ist der Browserlog: paste.obco.pro/upload/er0w4b
Wenn jemand eine Idee oder eine Policy hat, welche mit Iceshrimp funktioniert, wäre ich sehr dankbar.
:boost_animated: :blahaj: :rosahaj_thinking:
#fedimin #fedimins #iceshrimp #iceshrimpjs #anubis -
Hallo liebe Fediverse-Admins,
ich bin auf der Suche nach einer Botpolicy für Anubis in Kombination mit Iceshrimp.
Meine aktuelle Policy ist folgende: paste.obco.pro/upload/dRGDKe
Jedoch scheint damit das Iceshrimp UI nicht richtig zu laden. Also der Feed und die Benachrichtigungen laden nicht richtig.
Hier ist der Browserlog: paste.obco.pro/upload/er0w4b
Wenn jemand eine Idee oder eine Policy hat, welche mit Iceshrimp funktioniert, wäre ich sehr dankbar.
:boost_animated: :blahaj: :rosahaj_thinking:
#fedimin #fedimins #iceshrimp #iceshrimpjs #anubis -
Hallo liebe Fediverse-Admins,
ich bin auf der Suche nach einer Botpolicy für Anubis in Kombination mit Iceshrimp.
Meine aktuelle Policy ist folgende: paste.obco.pro/upload/dRGDKe
Jedoch scheint damit das Iceshrimp UI nicht richtig zu laden. Also der Feed und die Benachrichtigungen laden nicht richtig.
Hier ist der Browserlog: paste.obco.pro/upload/er0w4b
Wenn jemand eine Idee oder eine Policy hat, welche mit Iceshrimp funktioniert, wäre ich sehr dankbar.
:boost_animated: :blahaj: :rosahaj_thinking:
#fedimin #fedimins #iceshrimp #iceshrimpjs #anubis -
CW: iceshrimp behavior that’s bad for privacy
So #Iceshrimp gives you notification when someone votes on your polls, including who… Which is kinda pretty invasive on privacy when you don’t expect it, especially if you watch the poll for the first couple of votes and can then infer voting behavior.
Like, yes, technically this is of course available somewhere, but the rest of the Fediverse kinda keeps the votes private enough for the person starting them to at least not learn those votes by accident…
And it kinda sucks that Iceshrimp now seems to break that expectation… -
Die Liste eignet sich auch gut, um herauszufinden, wie viel Zeichen andere Plattformen anbieten.
So könnte eins einen Mastodon-Account für kurze Beiträge behalten (500 Zeichen), und für längere Texte einen Account mit zB 3.000, 6.000 oder sogar 100.000 Zeichen verwenden, statt "endlose" Thread-Ketten zu schreiben.
https://procial.tchncs.de/notes/ags2qegz9brg067o
#Sharkey #IceShrimp #FediVerse -
@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
-
Aus meiner "Reise" (Instanz-Wechsel) durchs FediVerse:
Ob Mastodon, IceShrimp oder Akkoma/Pleroma - alle haben ihre Stärken und Schwächen.
So *richtig* zufrieden (also zu 100%) bin ich mit keiner dieser Softwares.
Das Schöne (für mich):
Alle funktionieren mit https://phanpy.social - für mich der vermutlich beste Fedi-Client.
#FediVerse #Mastodon #IceShrimp #Akkoma #Pleroma #Phanpy -
Misskey und Derivate, steigt ihr da durch?
Ich hab mal versucht herauszufinden wie sich das mit Misskey, Foundkey, Calckey, Firefish, Sharkey, Iceshrimp und Iceshrimp.NET verhält. Gerne korrigieren.
Misskey ist wohl der Ursprung und immer noch sehr aktiv in der Entwicklung. ✅
Foundkey ein früher Fork von Misskey, mittlerweile eingestellt. ❌
Calckey ein Fork von Foundkey, scheinbar auch nicht mehr aktiv weiterentwickelt. ❌
Firefish war dann wohl irgendwann ein neuer Name von Calckey. Wurde ebenfalls 2023 aufgelöst durch den Hauptentwickler. ❌
Iceshrimp war dann wohl wiederum ein Fork von Firefish. Es kommen scheinbar keine neuen Features mehr, da das Team sich auf eine Neuimplementierung mit .NET konzentriert (Iceshrimp.NET). 🟡
Firefish (neu) kurzes Aufbäumen des Firefish Projekts, Seti 2024 keine weiteren Commits mehr im Git Repository. ❌
Sharkey ein Fork des neuen Firefish, wohl das einzige Projekt neben Misskey, das noch aktiv weiterentwickelt wird (Iceshrimp.NET hat keine gemeinsame Codebasis mit Misskey mehr). ✅
Irgendwie schade, dass so viele enthusiastische Entwickler es nicht fertig bringen über eine längere Zeit gemeinsam an einer Variante zu arbeiten 😭.
-
Misskey und Derivate, steigt ihr da durch?
Ich hab mal versucht herauszufinden wie sich das mit Misskey, Foundkey, Calckey, Firefish, Sharkey, Iceshrimp und Iceshrimp.NET verhält. Gerne korrigieren.
Misskey ist wohl der Ursprung und immer noch sehr aktiv in der Entwicklung. ✅
Foundkey ein früher Fork von Misskey, mittlerweile eingestellt. ❌
Calckey ein Fork von Foundkey, scheinbar auch nicht mehr aktiv weiterentwickelt. ❌
Firefish war dann wohl irgendwann ein neuer Name von Calckey. Wurde ebenfalls 2023 aufgelöst durch den Hauptentwickler. ❌
Iceshrimp war dann wohl wiederum ein Fork von Firefish. Es kommen scheinbar keine neuen Features mehr, da das Team sich auf eine Neuimplementierung mit .NET konzentriert (Iceshrimp.NET). 🟡
Firefish (neu) kurzes Aufbäumen des Firefish Projekts, Seti 2024 keine weiteren Commits mehr im Git Repository. ❌
Sharkey ein Fork des neuen Firefish, wohl das einzige Projekt neben Misskey, das noch aktiv weiterentwickelt wird (Iceshrimp.NET hat keine gemeinsame Codebasis mit Misskey mehr). ✅
Irgendwie schade, dass so viele enthusiastische Entwickler es nicht fertig bringen über eine längere Zeit gemeinsam an einer Variante zu arbeiten 😭.
-
Misskey und Derivate, steigt ihr da durch?
Ich hab mal versucht herauszufinden wie sich das mit Misskey, Foundkey, Calckey, Firefish, Sharkey, Iceshrimp und Iceshrimp.NET verhält. Gerne korrigieren.
Misskey ist wohl der Ursprung und immer noch sehr aktiv in der Entwicklung. ✅
Foundkey ein früher Fork von Misskey, mittlerweile eingestellt. ❌
Calckey ein Fork von Foundkey, scheinbar auch nicht mehr aktiv weiterentwickelt. ❌
Firefish war dann wohl irgendwann ein neuer Name von Calckey. Wurde ebenfalls 2023 aufgelöst durch den Hauptentwickler. ❌
Iceshrimp war dann wohl wiederum ein Fork von Firefish. Es kommen scheinbar keine neuen Features mehr, da das Team sich auf eine Neuimplementierung mit .NET konzentriert (Iceshrimp.NET). 🟡
Firefish (neu) kurzes Aufbäumen des Firefish Projekts, Seti 2024 keine weiteren Commits mehr im Git Repository. ❌
Sharkey ein Fork des neuen Firefish, wohl das einzige Projekt neben Misskey, das noch aktiv weiterentwickelt wird (Iceshrimp.NET hat keine gemeinsame Codebasis mit Misskey mehr). ✅
Irgendwie schade, dass so viele enthusiastische Entwickler es nicht fertig bringen über eine längere Zeit gemeinsam an einer Variante zu arbeiten 😭.
-
Misskey und Derivate, steigt ihr da durch?
Ich hab mal versucht herauszufinden wie sich das mit Misskey, Foundkey, Calckey, Firefish, Sharkey, Iceshrimp und Iceshrimp.NET verhält. Gerne korrigieren.
Misskey ist wohl der Ursprung und immer noch sehr aktiv in der Entwicklung. ✅
Foundkey ein früher Fork von Misskey, mittlerweile eingestellt. ❌
Calckey ein Fork von Foundkey, scheinbar auch nicht mehr aktiv weiterentwickelt. ❌
Firefish war dann wohl irgendwann ein neuer Name von Calckey. Wurde ebenfalls 2023 aufgelöst durch den Hauptentwickler. ❌
Iceshrimp war dann wohl wiederum ein Fork von Firefish. Es kommen scheinbar keine neuen Features mehr, da das Team sich auf eine Neuimplementierung mit .NET konzentriert (Iceshrimp.NET). 🟡
Firefish (neu) kurzes Aufbäumen des Firefish Projekts, Seti 2024 keine weiteren Commits mehr im Git Repository. ❌
Sharkey ein Fork des neuen Firefish, wohl das einzige Projekt neben Misskey, das noch aktiv weiterentwickelt wird (Iceshrimp.NET hat keine gemeinsame Codebasis mit Misskey mehr). ✅
Irgendwie schade, dass so viele enthusiastische Entwickler es nicht fertig bringen über eine längere Zeit gemeinsam an einer Variante zu arbeiten 😭.
-
Misskey und Derivate, steigt ihr da durch?
Ich hab mal versucht herauszufinden wie sich das mit Misskey, Foundkey, Calckey, Firefish, Sharkey, Iceshrimp und Iceshrimp.NET verhält. Gerne korrigieren.
Misskey ist wohl der Ursprung und immer noch sehr aktiv in der Entwicklung. ✅
Foundkey ein früher Fork von Misskey, mittlerweile eingestellt. ❌
Calckey ein Fork von Foundkey, scheinbar auch nicht mehr aktiv weiterentwickelt. ❌
Firefish war dann wohl irgendwann ein neuer Name von Calckey. Wurde ebenfalls 2023 aufgelöst durch den Hauptentwickler. ❌
Iceshrimp war dann wohl wiederum ein Fork von Firefish. Es kommen scheinbar keine neuen Features mehr, da das Team sich auf eine Neuimplementierung mit .NET konzentriert (Iceshrimp.NET). 🟡
Firefish (neu) kurzes Aufbäumen des Firefish Projekts, Seti 2024 keine weiteren Commits mehr im Git Repository. ❌
Sharkey ein Fork des neuen Firefish, wohl das einzige Projekt neben Misskey, das noch aktiv weiterentwickelt wird (Iceshrimp.NET hat keine gemeinsame Codebasis mit Misskey mehr). ✅
Irgendwie schade, dass so viele enthusiastische Entwickler es nicht fertig bringen über eine längere Zeit gemeinsam an einer Variante zu arbeiten 😭.
-
Sharkey & Iceshrimp Instanzen
Ich habe die Liste ein wenig überarbeitet.
Da es für die Misskey-Forks keine Anzahl der aktiven User gibt, wie bei allen anderen Fediverse-Plattformen, sortiere ich jetzt nach der Anzahl der gerade aktiven User. Das ist zwar nur eine Momentaufnahme, aber trotzdem ein guter Hinweis dafür, ob auf der Instanz etwas los ist.
https://contentnation.net/de/favstarmafia/sharkey
#Sharkey
#Iceshrimp
#Firefish
#Instanzliste
RE: https://procial.tchncs.de/notes/ags2qegz9brg067o -
Ich verteile gern Reaktionen:
🙋♂️ - Moin
👋 - Moin
:neofox_thumbsup: - Ja
:akko_thumbup: - Genau
:satania_thumbs: - Zustimmung
🤔 - mal überlegen
🤷♂️ - weiß nicht
✊ - Daumen drücken
🤭 - Hihihi
🌺 - Blumengruß
😋 - Lecker
🤣 - Hahaha
💫 - Gute Nacht
🍀- viel Glück
:meowmeow: - Awww
:ablobwhatisgoingon: - Nein
☕ - Kaffee
😉 - zwinker
🙏 - Danke
.
.
.
... und noch so viel mehr, und alles was Du mit Mastodon siehst, ist ein ❤️ oder ⭐. 😉
#Mastodon
#Sharkey
#Misskey
#Iceshrimp
#Fediverse -
connectedplaces.online/reports/fediverse-report-148-on-protocol-governance/
On the complexities of protocol governance.There are only two organisations that are active in the fediverse that are a paid member of the W3C: Meta and the Social Web Foundation.
With the Social Web Foundation also receiving funding from Meta, the company that built Threads now has more institutional standing in ActivityPub governance than any of the organisations actually building open fediverse software.
Mastodon gGmbH, Framasoft, and others are not W3C members and cannot participate in the Working Group unless they are invited.
#CHATONS #fediverse #fedivers #ActivityPub #w3c #Mastodon #Peertube #Lemmy #mBin #Piefed #NodeBB #Iceshrimp #Pixelfed #Loops -
@idlehirn as to #Iceshrimp and #Sharkey thank you, although I was more thinking about stuff other than microblogging. I'm pretty happy with my Mastodon instance for that sort of thing.
-
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