Loomio
Mon 8 Apr 2024 2:19PM

Proposal to revisit extending the character limit for posts

EB Evan Boehs Public Seen by 196

In 2022, a proposal to extend the post limit limit was opened, and while it yielded fruitful discussion, it never entered a formal voting stage. I frequently find myself running against this post limit, and many other instances that we federate with have a limit that is much higher.

To kick start discussion, here are my notes on the previous thread:

Pros:

  • Many servers already have this

  • Very little storage burden

  • Makes it easier to post longer things

Cons:

  • Additional maintenance burden as we would need to switch to a fork (which could have it's own pros/cons), or apply a minimal patch to the mastodon codebase to extend the limit (Basically just replacing a few `500`s with whatever `x` we decide)

  • If people don't like longer posts, the local timeline could be marginally worse (the federated timeline already experiences this).

I will open the floor for discussion and then begin a voting phase. For clarity, the two questions at hand are

  1. Should social.coop extend the character limit?

  2. If so, what should it become?

EL

Eliot Lash Mon 8 Apr 2024 2:25PM

I would like to hear from the tech working group before taking a vote as I think having to run a fork will impact them the most. It could delay upgrades having to wait for a fork like hometown to upgrade after an upstream patch, or manually maintain a custom fork. And if we switch to a different fork there's also the risk that the fork may become orphaned by its maintainers. Not sure if this is worth the extra effort even though it may be nice in some situations. I think there also is value in maintaining the 500 character limit in keeping posts terse and maintaining the "microblogging" feel.

EB

Evan Boehs Mon 8 Apr 2024 2:29PM

@Eliot Lash it's also worth noting that hometown seems to have fallen off in the past few months, it's currently running 3000 commits behind the main codebase. Unless there is another fork, if this was to be done it would probably be in the form of a patch

EL

Eliot Lash Mon 8 Apr 2024 4:25PM

@Evan BoehsThanks for the info, this is a great illustration of the issues that can arise from switching to a fork!

EB

Evan Boehs Mon 8 Apr 2024 4:26PM

@Eliot Lash I cannot overstate that this proposal is not advocating for switching to a fork, persay. In my below replies, I've detailed how this change likely could be implemented by running one line of code before deploying a new version. In my opinion, it would be much more constructive to discuss the social ramification of this change than the technical, because at least 50% of the discussion thusfar has been on that, before we've even heard from TWG!

EL

Eliot Lash Mon 8 Apr 2024 5:02PM

@Evan Boehs That's useful to know but I would argue that a one-line patch is still a fork. It's a simple one to be sure, but it could still break as it's not making a change based on public API or officially supported configuration. If the patch breaks in future updates, it will still fall on the TWG to fix, test, and maintain it. So I don't feel comfortable signing them up for this responsibility unless they have a consensus that they are willing to take this on.

EB

Evan Boehs Mon 8 Apr 2024 5:24PM

@Eliot Lash That's fair enough. I just want to avoid the negative connotation that comes with the "fork" territory of things becoming unmaintained and diverging in ways that we cannot control. Of course the input from TWG is the most important, but I don't want this technical discussion to distract from the social one. Ultimately the technical is a binary "TWG is ok with this" or "TWG is not ok with this", wheres the social one is

  1. Is a majority of the community ok with this

  2. If the community is ok with this, what should the new value be

Which is a lot more nuanced

MN

Matt Noyes Mon 8 Apr 2024 2:31PM

I agree with @Eliot Lash This is really a proposal to switch to a fork of Mastodon, with all that implies. Hometown has been suggested repeatedly over the years, as have others. It makes more sense to me to explore moving to a fork first, then consider raising the character limit. We recently discussed this in the CWG Ops Team and agreed that it is an option the group should explore.

EB

Evan Boehs Mon 8 Apr 2024 3:15PM

@Matt Noyes

This is really a proposal to switch to a fork of Mastodon

I'd like TWG's input on this because as I noted below, it appears that all code paths referencing the character limit tie back to StatusLengthValidator::MAX_CHARS, which is a constant that could be changed programmatically. If it is this simple, this is not a proposal to switch to a fork.

A

AG Mon 8 Apr 2024 2:33PM

Hi, thanks for your suggestion. For what it’s worth, I am very strongly opposed to any expansion in the character limit – as it is, when I encounter longer posts on other instances, I generally skip them.

Reading a long column of relatively narrow text on a mobile device isn’t simply tiresome on the eyes – though it is that, very much so – but also feels somewhat unneighborly to me, as though it were making a disproportionate or even obnoxiously presumptuous claim on attention. By contrast, I like being able to set only the first post in an extended sequence of thoughts to Public, and the subsequent ones to Unlisted, letting those who encounter the thread determine for themselves how much of the ride they wish to go on.

I acknowledge that much of this is in the realm of personal preference, but the exhaustion entrained by a rapid saccade down long narrow columns of text is a known usability issue of long standing. It would be nice if we didn’t inflict that on people without some very sound justification.

LV

Luis Villa Mon 8 Apr 2024 4:15PM

@AG Agreed heartily. I actively skip longer posts, both because the UI for it is bad, and because it’s simply not what I want when I’m using fedi. The activitypub plugin for wordpress is right there if someone feels the need to put blog-length posts on fedi :)

Load More