Mastodon 5.0: Laying the foundation
62 points by consteval
62 points by consteval
Reactions in the Fediverse: https://mastodon.social/@Mastodon/117117221397911074.
My own reaction, speed-reading a few hours ago: not only a good set of improvements, this is also a well-communicated set.
I'm amongst the people who previously thought that the public/private UX was good enough; that if a mistake was made, it was the end user's mistake. I believed that, as a user who had made stupid mistakes, more than once – accidentally publishing what I intended to be private, despite usually prefixing a supposedly private post with the word "privately".
It looks better, now. I'm less likely to make stupid mistakes.
I hope they'll also add text formatting into the web client, since it already supports rendering rich text. There are so many times I'd like to use backticks (or whatever else, I'm not married to the syntax) to turn a command into monospace, but there's no way to do so, unless you use external clients. There's already an emoji picker, so it'd be nice to have the entire set of tools.
There's already an emoji picker, so it'd be nice to have the entire set of tools.
I have no idea what its text entry thing is like (I don’t use Mastodon), but there’s a pretty big difference between an emoji picker and any kind of rich text support. Emoji pickers can be purely an input method for plain text. Rich text requires either using a rich text component, or parsing some lightweight markup language into rich text at submit time.
Emoji pickers on web apps are also a weird thing to have—unless they support “custom emoji” (rendering :something-user-defined: as an image), I don’t think they’ve served any useful purpose for at least five years. All major desktop operating systems have an emoji picker keyboard shortcut, and I think all major operating systems’ default touch keyboards have an emoji picker mode. Per-web-app implementations are almost inevitably worse.
Rich text requires either using a rich text component, or parsing some lightweight markup language into rich text at submit time.
That's exactly the thing though. Mastodon already renders rich text. You just have no means of entering it, unless you're using a custom client.
Emoji pickers on web apps are also a weird thing to have
I figure most of these are remnants from the transitory period where emojis were already a thing on phones, but not on PC, but I'm purely just guessing.
Rendering provided rich text is typically almost completely unrelated to, and much simpler than, taking rich text input.
Look, I've seen your comments on the site plenty so I know you're arguing in good faith and I'd completely agree with your argument in a vacuum (parsing is generally harder than manipulating an already present structure), but in this particular instance I genuinely don't get what point you're trying to make.
Not only is it possible, it's already been implemented in forks of Mastodon, and I'm pretty sure it's been submitted as a patch to Mastodon that was rejected. They're just being contrarian at this point.
Accepting that patch would have made it possible to use > for quoting, which would have replaced 90% of the use case for quote posts, which were a huge amount of work and still done wrong regardless. (they implemented it as top-posting)
I'm pretty sure it's been submitted as a patch to Mastodon that was rejected.
If so, that's remarkably short-sighted and frustrating. I don't get what they're going for with these arbitrary restrictions.
Parsing a subset of markdown (or any other markup format) is trivial for a project of Mastodon's size.
Given that Akkoma[1], Misskey[0], and GotoSocial[2] already provide for text/markdown posting, yeah, it's not beyond the realms of possibility.
[0] Strictly "MFM" but it's basically Markdown compatible
[1] https://docs.akkoma.dev/develop/development/ap_extensions/#post-source
[2] https://docs.gotosocial.org/en/latest/user_guide/posts/#input-types
There is even a friendly fork of Mastadon, glitch-soc, that supports posting in markdown (and HTML)
I have no idea what its text entry thing is like (I don’t use Mastodon)
Honestly, you should stop there. You're incorrectly speculating about something you don't know.
This feature has already been implemented. It's live, it works, people use it everyday (custom Mastodon instances have added it themselves). It's been natively supported by ActivityPub from day one (it uses HTML for message bodies), so it works across the network. The difficulty is more social than technical - convincing the flagship Mastodon project that it's worth adopting the feature.
it uses HTML for message bodies
I understand why that choice was made but I also wish it had gone for Markdown as the posting and internal format which clients could then render how they wanted. It feels faintly wrong to me to store rendered HTML in the database as the "source"[0], especially when there's no side-store of "decoded entities are [xyz]."[1]
[0] Akkoma, at least, does keep the original Markdown around if you posted as text/markdown but in a currently incompatible extension to the status type. Also I am assuming that Mastodon stores only the HTML because that's the only thing you can get back from the API and it would be weird to have the "raw" version available without access.
[1] e.g. when you requested a tweet from the Twitter API, there'd be a side-blob of "url: 20-30, username: 40-50, username: 50-55, hashtag: 80-85, hashtag: 87-90" information which told you what had been expanded and formatted.
Emoji pickers on web apps are also a weird thing to have—unless they support “custom emoji”
Mastodon does since very early in its development (2017), it was a major differentiator to other social networks.
I don’t think they’ve served any useful purpose for at least five years
For some reason, they do. A recurring complaint about IRC is that it allegedly doesn't support emojis, and as far as I can tell this is because most IRC clients don't provide an emoji picker.
When people complain about IRC not supporting emoji, I think they mean custom emoji, the shared mapping of :something-user-defined: to an image.
I actually liked the DM system in Mastodon as it made it easy to have a private branch-out convo, but I suspect I'm in the minority on this.
I liked the idea, but admittedly I needed a bit more of an on-ramp from being previously on other social media platforms and DM systems from the big ones were something I'm used to - including how group chats worked on X-the-everything-app which I left for Mastodon.
The update looks cool for me in that the UX seems way more friendly to my bad habits just enough to visit better social media instead, which I think is a net win!
Quiet public
I never got what this was for or why it was enabled so often.
DMs being anywhere and everywhere was a very bad and very weird quirk. I'm glad that's being fixed.
Many of these other changes I can't really care that much about because I almost exclusively use: https://phanpy.social
I never got what this was for or why it was enabled so often.
Before it was called "Quiet Public", a name many people strongly disliked, it was called "Unlisted", and it was, at least for most people I know, the default posting mode. A Mastodon post with the Unlisted visibility:
I think "Public but not indexed" is a much better way to express this than "Quiet Public", and I applaud the Mastodon project's decision to listen to their entire userbase who didn't like the short-lived name change.
I found unlisted to be a better term than "quite public", though agree with the upcoming changes to clarify the difference.
When I joined Mastodon many people recommended using "unlisted" for replies to your own threads to avoid spamming the main feed. That made sense to me; the top post remains visible, but all replies are seen only when you open the post itself.