imho one of the best things about Markdown is that even if you're not using it, it's pretty-well established a baseline for "these are the HTML elements that should be allowed for user styling". It's why I cringe every time I see a rich text box that has a font-size picker but not heading classes.
>I have always considered Mastodon's lack of formatting options like this to be a fantastic feature, not a deficiency.
Part of a comment from the linked site, please no rich-text. I always think when rich-text is allowed it is the first step down. Usually when that happens "ne'er-do-wells" start arriving :)
We shall allow the ne'er-do-wells to populate Mastodon, but as part of the defederated Reddiverse! :)
Honestly though, that was also my impression until I saw the implementation. It's really conservatively applied, and doesn't clog up the whole screen with text and distractions. Eg. if Discord/Slack had heading sizes for standard messages, it would be pretty horrible for the user. If our only objection is culture alignment, I say they go forward on it. I'd like to have code blocks and (eventually?) syntax highlighting for posting quick code snippets.
And worst of all is when someone emojis your message, the flow to remove that notification is different. You cannot just select the chat and it clears it.
Probably because large parts of population unfortunately prefers communicating with emojis. Curious if this becomes a a logographic language in future like Chinease.
edit: I think you might be onto something. Some novels actually addressed that possible outcome ( super sad love story being one of them iirc ).
I chuckle at the downvoting that does not address the issue. One might argue that it is a generational issue. There is an argument to be made that picture is worth a thousand words, but some things require precision that goes beyond ::eggplant::,::tongue::
I think reactions are pretty cool. Much faster than having to reply, and it's a feature that makes it easier to have short discussions. I use it all the time on Teams, Messenger, Telegram. And fwiw, it would actually break my flow to make them harder to access.
This PR is just one part of item MAS-86 on our public roadmap [1] "Markdown formatting for posts" which is meant to enable users to use code spans/blocks and bold and italic text as championed by the Elk third-party app [2]. I believe "rich text" in the PR title is a little not nuanced enough because like before I'm of the position that Mastodon is the wrong medium for long-form articles and the various block-level formatting structures that come with it, but allowing users to use bold text without resorting to mathematical Unicode characters is a win for accessibility.
Gargron, I know that you are adverse to quote-tweeting, but I have a lot of lefty friends who want to stay on Facebook despite all the privacy concerns because it lets them share memes/news stories with their IRL friends, sometimes adding context, without having to worry about their boss / landlord / XYZ seeing what they're sharing.
I think that the fact Mastodon allows per-post privacy is a great feature, but the lack of private retweets and/or retweets with context (eg quote tweets) does scare some people away from the platform.
I've seen how quote tweets can be abused, but still believe there is some potential good from the feature in Masto. Any thoughts?
(Yes, it would be trivial for a third party frontend to add quote tweets, but because that's trivial I'm not asking about that.)
There are forks who use URL unfurling to simulate quotes, so I think this can be a good approach if you can convince your instance to migrate... but, of course, every other instance won't see them nor will the desktop/mobile clients that don't implement this feature.
Other fedi implementations (Pleroma, Misskey) seems to support this approach too.
For now, easiest way seems to be a manual quote, as we did retweets before twitter had RTs.
I don't understand why quote-boosting can't be a user-selected option.
• Allow users to opt-in/out the ability to perform a quote-boost.
• Allow users to opt-in/out the ability to see others' quote-boosts.
• Allow server admins to opt-in/out the quote-boost feature.
Wouldn't this solve everyone's issue with quote-resharing?
Perhaps. My comment wasn't based on technical feasibility, but specifying the particular concern which is why Mastodon and several other ActivityPub projects do not support quote-boosts.
It effectively can't have that. Quote statuses are practically just a special way of formatting a link to another status in the message text at the moment. There's a proposal iirc to try and create a more genericized version by extending AP, but it's stalled if memory serves me right.
Even so, you're going to have implementations that will happily ignore those choices; as long as the body of an external post is obtainable in some way (right now most info is just in the embed meta tags), someone can make a version of it that ignores permissions.
Any permissions system is, of course a polite suggestion since ActivityPub pushes content to a large number of other peoples' computers in the typical case. The whole network depends on most servers being relatively well-behaved so I don't think that's a barrier.
Get on a server running the glitch or treehouse forks, 5000 characters and quote-toots. Mainline Mastodon is very much in catching-up mode with its own forks.
Does anyone think Mastodon can or will go through similar fork-and-spin-off storms as Bitcoin? I feel Mastodon is at a pretty okay stage in terms of general completeness right now, but all those devs won't just switch into maintenance mode, I assume? Seeing the various (also angry) reactions to this PR, it starts to smell a bit like someone may want to fork off into a more barebones edition.
I made an analytics tool for it, just in case brands decide to use it more, but now I am starting to get worried this could very well end up as yet another multi-fork-what-is-available-here-and-whats-not kind of headache.
Doubtful. AP is terrible but also generic enough that I don't think anyone will ever abandon it.
It's in that sweet spot of being bad enough that anyone who has experience with it can sum up a whole myriad of issues with it, but at the same time, you're going to be hard-pressed to find a different solution that will meet everyones goals. It's terrible but it works "well enough".
Fork wars seem likely for any open and distributed network project. Although the value of a network is directly proportional to the number of people on it, so one fork tends to dominate and subsume resources from the others until they become a husk hobbling along. This chaos isn't necessarily bad, it's just the nature of a network that has no centralized, controlling authority to settle disputes. It's one of the tradeoffs you take when deciding to avoid centralization.
It's still early enough that fork wars in Mastadon seem likely, and would take years to settle. When the first bitcoin fork happened, bitcoin cash, happened in 2017, it peaked at a value of about 25% of the main chain. Today it's value is about 0.5% of the main chain and it is effectively irrelevant.
But what would the forkers gain? Bitcoin doesn’t seem interesting as a precedent because there’s no financial gain in forking Mastodon. The currency of the fediverse is user content. If you can’t or don’t interoperate, you lose all of the content.
There are multiple forks of Mastodon already being run on live servers, often ad-hoc forks with minor tweaks. If you define fork narrowly enough, even changing the character limit might count, and quite a few servers do that.
Most forks do not break interoperability, which is very different from Bitcoin forks.
Beyond that, Mastodon interoperates with other software that speaks ActivityPub like Pixelfed and Friendica.
I'm not opposed to rich text, but I feel this is repeating emails mistake of having poorly defined ad-hoc per-implementation html subsets instead of formulating a widely accepted spec. This means that over time it will be increasingly difficult to ensure that implementations are actually able to process the content correctly.
Yeah, this runs the risk of becoming HTML emails all over again, with implementation-detail-defined subsets/supersets and rendering differently on every client, with different degrees of brokenness.
Mastodon adding rich text support? Sounds like they're trying to catch up to the social media platforms of yesterday. MySpace? It's funny how things go in cycles. First, we had the simple text-based internet, then we added flashy graphics and animations, then we stripped it back down again with minimalism and flat design, and now we're back to wanting more visual stimulation. But hey, why not embrace the nostalgia and bring back some of those retro features? Maybe next Mastodon will add a customizable profile background with your favorite song playing in the background.
Pleroma has had this for years.... markdown, bbcode, and limited HTML support.
Pleroma has a lot of features that Mastodon doesn't, such as support for statuses of much longer than 500 chars. There's a running gag, "Pleroma does what Mastodon't."
I very much respect the work gargron has done is making Fediverse a place that's more moral than Twitter and popularizing the space with "normies" ; however it is good to note that there are alternatives within the space that do what Mastodon doesn't.
Pleroma also runs on basically everything, which is another big mark in favor of it.
Mastodon is a ruby on rails dinosaur, which to its credit scales as well as Ruby usually does. The disadvantage is that if you're trying to run something for yourself, you're looking at a cost that is hard to justify. Last I tried using it, without downtuning sidekiq workers, you get constant CPU pressure and ~2GB idle ram usage and that's on a low-cost VPS from Hetzner (somewhere below the 10$ mark).
It also caches media like there's no tomorrow, which means that you basically need a cronjob to clear out old attachments and for 4 years straight you couldn't clean out old avatars and headers either.
Pleroma by contrast uses barely any CPU when idle and it's ram usage has only rarely exceeded the 300mb mark (and only when I foolishly plugged my instance into a relay). Media caching is off by default, so it doesn't clog up your disk unless you want it to.
The fediverse has the opportunity and benefit of rebuilding social media from lessons learned of the social media platforms. They can replicate and improve the features that served users and communities and ditch those that only benefited platform operators, commercial advertisers, and state censors.
See Eugen start talk about maybe adding quote-posts after a pile of Mastodon forks added the Treehouse fork's implementation, compatible with the MissKey and Akkoma implementations.
Does anybody else have trouble with the way Mastodon organizes their conversations? It isn't just a straightforward branching thread. I think. I'm not sure. Maybe it's the app I'm using (tusky). It's just hard. Or maybe it's hard to do branching threads ui in the screen space of a phone. I don't know. Reddit and hacker news seem to handle it okay
My biggest problem with Mastodon, although Twitter has the same issue, the quoting convention creates context if the reply poster adds it, but tweets with lots of replies are similarly a morass.
Someone is building a threaded Mastodon client, currently macOS only.
I believe this is a client issue. The Mastodon client API gives enough information to render a thread tree but most clients don't take advantage of it yet.
Fedilab on Android has a nice tree-like thread view.
A good start to see Mastodons upstream finally start to implement features considered so necessary that they existed in a fork for years beforehand[0].
I'm not trying to sound cynical, this is legit a good change. Other fedi implementations have supported different message formatting (mainly markdown) for ages and that shit still degrading away to plaintext on Mastodon is extremely aggravating if you decide to (for example) use a bulletpoint list.
Thank you so much for this. I hate that people have to abuse Unicode just to get formatting, that screen readers will just... Well if sighted people had to read what screen readers spewed out for Mathematical italics capital letters, the change would have happened years ago.
Seems like a good idea for a feature. It helps made content more accessible to those using screen readers and other such devices, and makes the content more readable than it is with plain text alone.
Is it the best platform for long form articles? Maybe not, but to be honest, we may as well make things more accessible/readable when people do happen to do that, regardless of the original intent.
One person's "basic feature" is another person's "a good addition" or even "this might be too much". People use it because they don't feel about it as strongly as you do, and it's been the case for at least the whole lifetime of Twitter.
This feature has very little to do with mass adoption. However I did see someone post link to their article in Post.News within Mastodon because Post.News supports longer form articles with formatting as well as short form content.
For regular people it's much more important how you present things in UI. If you show long form content in a short form feed so that it jams the timeline, it's obviously bad. But if you show long form content behind an extra click it doesn't jam the timeline, and suddenly it's more acceptable like in Post.News.
Honestly I don't really get why we don't have markdown everywhere.
For adding italics, underscores, and other simple formatting I haven't found anything better. Once you get the hang of basic syntax, it becomes completely natural to just add some formatting while you're typing. Especially on a phone screen, just tossing in some * or _ is dead easy.
People want to format their text. Markdown is easy to use and (AFAIK) not hard to implement. Why don't we have it everywhere?
Markdown is an unmitigated compatibility and extensibility disaster. It was designed as an authoring format, for which purpose it’s tolerable (though it’s still got major problems). But it was not designed as a publishing or general interchange format, and it’s completely unsuitable as either. (You start by saying, “when we say ‘Markdown’, what do we actually mean, technically? CommonMark? GitHub Flavoured Markdown? &c. &c.”)
What this means is: sure, use Markdown within the scope of your app if you want to (compatibility and extensibility aren’t problems there), but at the protocol level, use something sane instead, like HTML with some kind of whitelist on supported elements and attributes (and yes, I will admit that HTML whitelist inconsistency is a problem too, but it’s by far the most convenient approach, and considerably wiser than using a format like RTF or Office Open XML or OpenDocument Text, and generally more sensible than designing a new minimal markup format from scratch).
60 comments
[ 0.33 ms ] story [ 151 ms ] threadPart of a comment from the linked site, please no rich-text. I always think when rich-text is allowed it is the first step down. Usually when that happens "ne'er-do-wells" start arriving :)
Honestly though, that was also my impression until I saw the implementation. It's really conservatively applied, and doesn't clog up the whole screen with text and distractions. Eg. if Discord/Slack had heading sizes for standard messages, it would be pretty horrible for the user. If our only objection is culture alignment, I say they go forward on it. I'd like to have code blocks and (eventually?) syntax highlighting for posting quick code snippets.
When you hover over a message, the immediate options are emojis. Not reply, copy, but goddamn emojis.
I chuckle at the downvoting that does not address the issue. One might argue that it is a generational issue. There is an argument to be made that picture is worth a thousand words, but some things require precision that goes beyond ::eggplant::,::tongue::
That would be terrible
[1]: https://joinmastodon.org/roadmap [2]: https://elk.zone
I think that the fact Mastodon allows per-post privacy is a great feature, but the lack of private retweets and/or retweets with context (eg quote tweets) does scare some people away from the platform.
I've seen how quote tweets can be abused, but still believe there is some potential good from the feature in Masto. Any thoughts?
(Yes, it would be trivial for a third party frontend to add quote tweets, but because that's trivial I'm not asking about that.)
Other fedi implementations (Pleroma, Misskey) seems to support this approach too.
For now, easiest way seems to be a manual quote, as we did retweets before twitter had RTs.
* Allow users to opt-in/out of their posts being quote-boosted by others.
Even so, you're going to have implementations that will happily ignore those choices; as long as the body of an external post is obtainable in some way (right now most info is just in the embed meta tags), someone can make a version of it that ignores permissions.
Why not just copy/paste the image or URL to share a meme or news story with added context?
I would really love it, if there was push from Mastodon, to get app developers to also load Mathjax or similar parsing library within the app itself.
I made an analytics tool for it, just in case brands decide to use it more, but now I am starting to get worried this could very well end up as yet another multi-fork-what-is-available-here-and-whats-not kind of headache.
Posts authored from outside Mastodon can already include more formatting, and that has been the case for years
It's in that sweet spot of being bad enough that anyone who has experience with it can sum up a whole myriad of issues with it, but at the same time, you're going to be hard-pressed to find a different solution that will meet everyones goals. It's terrible but it works "well enough".
It's still early enough that fork wars in Mastadon seem likely, and would take years to settle. When the first bitcoin fork happened, bitcoin cash, happened in 2017, it peaked at a value of about 25% of the main chain. Today it's value is about 0.5% of the main chain and it is effectively irrelevant.
Most forks do not break interoperability, which is very different from Bitcoin forks.
Beyond that, Mastodon interoperates with other software that speaks ActivityPub like Pixelfed and Friendica.
Pleroma has a lot of features that Mastodon doesn't, such as support for statuses of much longer than 500 chars. There's a running gag, "Pleroma does what Mastodon't."
I very much respect the work gargron has done is making Fediverse a place that's more moral than Twitter and popularizing the space with "normies" ; however it is good to note that there are alternatives within the space that do what Mastodon doesn't.
Mastodon is a ruby on rails dinosaur, which to its credit scales as well as Ruby usually does. The disadvantage is that if you're trying to run something for yourself, you're looking at a cost that is hard to justify. Last I tried using it, without downtuning sidekiq workers, you get constant CPU pressure and ~2GB idle ram usage and that's on a low-cost VPS from Hetzner (somewhere below the 10$ mark).
It also caches media like there's no tomorrow, which means that you basically need a cronjob to clear out old attachments and for 4 years straight you couldn't clean out old avatars and headers either.
Pleroma by contrast uses barely any CPU when idle and it's ram usage has only rarely exceeded the 300mb mark (and only when I foolishly plugged my instance into a relay). Media caching is off by default, so it doesn't clog up your disk unless you want it to.
https://akkoma.dev/AkkomaGang/akkoma/
See Eugen start talk about maybe adding quote-posts after a pile of Mastodon forks added the Treehouse fork's implementation, compatible with the MissKey and Akkoma implementations.
Someone is building a threaded Mastodon client, currently macOS only.
https://mastodon.social/@terhechte
Early days, and kind of slow, but looks promising.
The thread is built from this object: https://federated.id/objects/2e6cf5a8-ffa8-4fca-b4cd-8e0c9a5... and its replies.
Fedilab on Android has a nice tree-like thread view.
I'm not trying to sound cynical, this is legit a good change. Other fedi implementations have supported different message formatting (mainly markdown) for ages and that shit still degrading away to plaintext on Mastodon is extremely aggravating if you decide to (for example) use a bulletpoint list.
[0]: https://glitch-soc.github.io/docs/
Is it the best platform for long form articles? Maybe not, but to be honest, we may as well make things more accessible/readable when people do happen to do that, regardless of the original intent.
Because why not? Early feedback can shape something based on user feedback, rather than taking stabs in the dark.
It is a free and open source project after all, no one has been forced to use it.
For regular people it's much more important how you present things in UI. If you show long form content in a short form feed so that it jams the timeline, it's obviously bad. But if you show long form content behind an extra click it doesn't jam the timeline, and suddenly it's more acceptable like in Post.News.
For adding italics, underscores, and other simple formatting I haven't found anything better. Once you get the hang of basic syntax, it becomes completely natural to just add some formatting while you're typing. Especially on a phone screen, just tossing in some * or _ is dead easy.
People want to format their text. Markdown is easy to use and (AFAIK) not hard to implement. Why don't we have it everywhere?
What this means is: sure, use Markdown within the scope of your app if you want to (compatibility and extensibility aren’t problems there), but at the protocol level, use something sane instead, like HTML with some kind of whitelist on supported elements and attributes (and yes, I will admit that HTML whitelist inconsistency is a problem too, but it’s by far the most convenient approach, and considerably wiser than using a format like RTF or Office Open XML or OpenDocument Text, and generally more sensible than designing a new minimal markup format from scratch).