1. 20

  2. 7

    The UI of fern is an experiment in trying to encourage users to read entire threads, read their entire timeline, and treat the fediverse more like a medium for serious discussion (i.e., to de-twitterize the fediverse’s culture with regard to sealioning).

    Good luck! (Earnestly.) I haven’t experienced this too much, but definitely an issue given the ad hoc nature of social threads. Unlike a mailing list where everybody sees the start, you don’t know about threads until someone you follow participates, and then all of a sudden, “ooh, ooh, I have something to say too!”

    1. 2

      Absolutely. It happens less than on twitter because federation makes accessibility less flat, but I run into situations where people jump into the tail end of a thread to add an off-topic comment at least once or twice a month.

      This is done mostly by noobs, who will never switch to fern anyway, but I found myself occasionally doing it when using tootstream because of the amount of effort it took to expand a thread. And, folks who use web clients rarely manage to read all of the branches of a thread, leading to duplicated conversation (because you need to not just expand the thread but also jump to the first item in the thread and expand that in order to see all posts). My thread expansion logic is designed to show all posts in a more-or-less sensible order (basically, depth-first traversal of responses starting from the OP), & traversing this becomes a little easier since you can easily skip already-seen sections. So, it’s designed to help the users avoid adding to the problem of poor-quality responses caused by lack of context.

      1. 1

        I’d like to test this, but after installation it’s not clear where to enter stuff like instance, and username etc.

        1. 1

          It prompts you for those at runtime.

          1. 3

            More specifically, at first launch – no multiaccount support yet unfortunately.

      2. 0

        I’m in favor of a UI that encourages users to read entire threads. That said, I think sealioning is fundamentally good, and I don’t particularly want to see the technologies that mediate culture try to discourage it.

        If you read the original Wondermark comic from which the reference comes, you’ll note that the sea lion originally came into the conversation because the embittered woman insulted his species in public. In the context of Twitter and similar social media platforms, I see anti-sealioning sentiment as a claim made by people who insult their outgroups with an air of smug confidence in the quasi-public space that is social media, who in turn take it as a personal affront and violation of their own space when people from those outgroups challenge them in the same quasi-public way. I don’t have a great deal of respect for this attitude towards public debate, and as an observer to many internet political debates I wasn’t directly participating in, I’ve gotten a lot of value out of reading the vehemently-disagreeing responses to the person who started the thread - responses that they would almost certainly characterize as unproductive sealioning.

        1. 3

          To my understanding, the essence of sealioning is harassment. Let’s say person A says something stupid in public, person B calls them out, person A declines to debate the matter further. If person B lets the matter drop, then they’ve won the argument by default, and that’s not sealioning. On the other hand, if person B continues to repeatedly call out person A despite A forfeiting the discussion, that is sealioning, and it’s generally unhelpful because it’s not a two-sided debate, it’s just a one-sided lecture.

          On the other hand, if person B lets the matter drop but then person C shows up and calls out person A, and person D shows up and calls out person A, that’s effectively the same thing from person A’s point of view. If C and D can see that B already tried to start a debate and was shut down, they’re not helping matters.

          You say yourself that social media is a “quasi-public space”; sealions behave like social media is a fully-public space. That’s not exactly wrong, but it’s not exactly right either.

          1. 3

            I think sealioning is fundamentally good

            If so, you’re in favor of a DDoS on a participant in public discourse:


            In the long sentence starting with “In the context of Twitter and similar social media platforms […]” you do explain what you mean by the term. It’s not the accepted one, however.

            If you read the original Wondermark comic from which the reference comes,

            The comic was a reaction and summation of Twitter culture at the time. The reason it resonated was that it managed to encapsulate the phenomenon so perfectly.


            you’ll note that the sea lion originally came into the conversation because the embittered woman insulted his species in public.

            Nothing in the comic implies that the woman is “embittered”. That’s projection on your part.

            Again referring to the comic, the words uttered by the woman are

            I don’t mind most marine mammals, but sea lions? I could do without sea lions.

            This is a statement of opinion, not an insult of a species.

            Whether the conversation is “public” is debatable, as the characters seem to be driving through a park, far from the sea, and yet a sea lion “couldn’t help but overhear”. Again, this is a akin to someone monitoring Twitter for keywords and jumping in without solicitation.

            I have addressed your interpretation of the term above. Returning to the last sentence in that paragraph:

            responses that they would almost certainly characterize as unproductive sealioning.

            No doubt these people also misinterpret the term. However, if I were engaged in a debate, and someone accused me of sealioning, I would certainly stop and reconsider my approach. I would also not accept the term unless I were, in fact, sealioning.

            1. 2

              Right. In this case, what I meant isn’t necessarily the most extreme form of sealioning (i.e., automatically monitoring ongoing discussions for mentions by strangers of particular terms before using those terms to engage in bad faith – something that’s designed to be hard to do on mastodon) but instead a weaker form (jumping onto the tail end of a thread with an off-topic or redundant response because you don’t have full context, and thus annoying everybody in the thread with a notification of a poor-quality message).

              You’ve gotta be following or on the same instance as somebody engaged in the thread or who boosted a message in that thread in order for that to happen on mastodon, unless folks are using tags, so it’s generally not the case that everybody involved is a complete stranger, and norms around sticking a CW on hellthreads means that even if tags are used they remain unsearchable in the web interface.

              Even that kind of relatively-benign form is pretty annoying, even when done in good faith. It’s usually a side effect of the way threads are displayed: folks see only one branch, and so independently come up with the same responses as folks in other branches. When those responses require a long and nuanced counterargument, it’s extra irritating. This happens to me all the time, because I post things that are controversial & spark hellthreads (like this). Note how many branches in that thread are almost totally identical because 2 or 3 people thought “IPs are also rented from the ISP and therefore you would need to replace the IP infrastructure too” was a good counterargument.

              I occasionally run into the stronger form of sealioning on the fediverse. For instance, I posted something about circularity in logic with regard to a cybernetic vs aristotlean perspective on ontology, and got a response from a guy who (based on looking at his profile) did nothing all day but tell strangers that the existence of motivated reasoning meant deduction was worthless as a thinking tool. I muted this guy, because he’s a sealion in the strongest sense: a dude with exactly one subject he’s interested in discussing, about which he knows nothing, and who (in order to discuss this subject) searches out unwilling strangers to impose bad pre-scripted arguments upon. (I went looking through the archive but it looks like this dude deleted all the posts in the thread…) Anyway, fern won’t fix that kind of thing at all (and will actually make it slightly easier because of improved search). It only prevents accidental sealioning/threadjacking based on lack of context.

        2. 9

          Was there any reason to write this in the soon-to-be EOL Python 2 over Python 3?

          1. 3

            I’d like to keep compatibility with 3, but I wrote & tested it against 2 because on my system & most others that’s still the default version (and probably will continue to be long after the language maintainers stop support). Forcing the version to 3 would require a bunch of complexity that didn’t make sense in a 1-file 700-line tool.

            1. 4

              You can set the shebang to explicitly call python3.

              1. 3

                If I did that, then all the systems that don’t have python3 at all would be broken.

                The appropriate solution is what I’ve done: set the shebang to python & write code that ought to work on any version a user might reasonably have. And, if I start to have more users I’ll test on python3 more often.

                1. 8

                  Okay, I suppose. It just seems the likelihood of a Python user who wants to use this, yet lacks Python 3 on their computer, and installing Python 3 with <package manager> install python3 is nil or approaching nil. People love to support Python 2 but it’s officially EOL in like, 6 months. Sorry if I sound condescending, I’m not trying to. It’s just the one place I’ve not found Python 3 is CentOS 6

                  1. 2

                    If halcy drops python2 support for mastodon.py I’ll have to drop python2 support for this. In the meantime, since nothing on my dev machine uses python3, I’m not going to go out of my way to drop compatibility.

                  2. 1

                    I don’t think setting the shebang to python is the right decision. Regardless of whether you’re targeting python2 or python3 (and I do agree that programmers should avoid creating new code in python2 now that we are so close to its end-of-life), it’s not consistent from system to system whether the python binary refers to version 2 or 3. I use both arch linux and ubuntu frequently, and on arch python is Python 3 but on Ubuntu it’s Python 2, so I’ve just gotten used to calling python3 or python2 explicitly (and sometimes even python3.6 specifically if I know I need that version of python 3 and not another one). Being as explicit as possible about what version of a dependency you want, and relying as little as possible on what happens to be installed under a given name on some platform, is a good practice.

                    1. 1

                      The thing is, while it’s not totally consistent across systems which version which python is set to, on those same systems, it’s not consistent whether or not python2 or python3 even exist. You can have a system where python=python2 and python 3 is installed as Python3.6 only (or it’s installed but not in the path). Distro maintainers have done all sorts of crazy stuff with how they’ve juggled multiple major versions of python being installed at once.

                      Since a lot of folks don’t have python 3 installed at all, and since part of the point of a curses client is to support systems that really don’t have the horsepower to run the web client, I don’t want to drop python2 support. (For instance, I’ve got a mac mini at home manufactured right after the switch to intel, and it’s been years since it was able to install OS updates or load most websites in its browser, & this ought to work fine on that machine.)

                  3. 1

                    maybe he means the complexity of installing python3 when you’ve python2 by default

                    1. 2

                      I mean the complexity of detecting python2, determining whether or not python3 exists, determining its path, and executing $0 with it before executing any other code – in other words, what’s necessary to support cases where python=python2 but python3=python3, cases where python=python3, and cases where python=python2 and python3 isn’t in path but various python3.x or Python3 or Python3.x exist in path.

                      This is a stupid complicated task (I’ve seen it done for Perl & tcl+wish, and done it for shells where sh may be dash or busybox), and it takes a dozen lines to do correctly.

                      I have no need for a dependency on any python3 features, so compatibility makes more sense.

                      1. 6

                        python should always equal python2, at least on systems that comply with PEP394


                        1. 2

                          I didn’t know this existed! Cool! :)

                  4. 1

                    I understand your simplicity arguments, but honestly the fact that it’s python 2 makes me want to ignore it.

                    1. 2

                      It’s not ‘python 2’ but ‘python 2 / 3’. I’m not dropping compatibility with python3 – just trying to avoid dropping compatibility with the version of python that people actually use.

                      For a small project like this, the main effort involved in supporting both is in switching which interpreter you’re running it with & making sure the dependencies are in both versions of site-packages.

                      Specifically, I haven’t been heavily testing on python 3 because changes to how strings work between 2 and 3 cause my pickled cache files not to work across major versions – in other words, in order to test on python 3, I need to move my cache out of the way to avoid corrupting it. Since this has been my primary client for 6 months, I’m not particularly happy doing that, & I’m happier just taking compatibility patches from folks like @gcupc who run it on python3.

                      1. 2

                        then ignore it

                        1. 1

                          I don’t - understand this reaction. I get wanting to support the wholesale move to Python 3, and I totally get that 3 has lots of improved language syntax and features, but if you might find a tool useful, why reject it over something like this?

                          I mean, I regularly use tools written in Perl because they Just Work even though the idea of dusting off those particular neurons makes me kinda queasy just thinking about it :)

                          1. 1

                            The impression I’m getting (from the many, many people telling me to break compatibility) is that, because the move to 3 was held back so long by incompatible 2.x code that never got ported, folks see 2.x-compatible code as traitorous / counterrevolutionary, and because 3.x has new features that encourage a different coding style, they figure any 3.x-specific code would be written in a fundamentally different way than 2.x-compatible code (and thus, 2.x-compatibility is seen as an awkward and burdensome hack).

                            Of course, the former applies much more than the latter to this code: I made it 2.7-compatible because that’s the default on my system, and because I’m not particularly invested in the progress of the python platform – I don’t care one way or another about the glorious python3 revolution, because I consider python a middling language whose primary utility is its large standard library & online help/documentation system – I don’t feel like I need to help the platform along by encouraging people to upgrade. I’ve got little interest in being pythonic or adhering to the community’s preferred idioms except when doing so makes the code smaller or more readable, but to the extent that I have any kind of python mentality affecting the style and structure of the code, it’s probably even pre-2.7 (since I learned on 2.4).

                            Anyway, this thing is BSD licensed – and TINY. If anybody is invested enough in breaking 2.7-compatibility, feel free to fork it. I’d be interested in seeing the kinds of structural changes that folks think would come out of a pure-3.x implementation, since I don’t really consider it amenable to most of the features that have been added. (In a 3.x-only port, in a couple places, forced casts could be dropped, and a couple lines of unicode handling could be eliminated, and I’ve got some polyfills for simulating library features introduced or removed in 3.x, but aside from that, the only change I could see is maybe a heavier use of functional-style list operations?)

                            1. 2

                              What you’re seeing here is the result of a lot of work people in the community are doing to motivate people to switch. There was and is a fair bit of anxiety over watching what happens when other programming languages (like Perl 5) stagnate and even when the successor arrives only a tiny group of ascetics actually use it because most of the user base has gone elsewhere.

                              So Guido and pretty much the entire community have undertaken a bunch of initiatives to force people to move. Things like stopping security updates, and having library authors drop Python 2 support with newer versions.

                              I’m honestly in favor of all of that - I quite like Python 3 and think it’s a very positive step forward for the community.

                              I’m less a fan of negative or judgemental pressure tactics however (Not suggesting those were in use here) and think that the incentives should be positive in getting people to move over.

                              1. 1

                                Makes sense. In this particular case, positive incentives aren’t going to convince me to drop support because the client is basically feature-complete & I’m not convinced that switching to new features is going to substantially lower maintenance load. The stuff that’s easier in python3 than on python2 (like unicode) is already written & stable.

                                I’ll break compatibility if my (single) dependency does, or if somebody does a fork that is convincingly preferable to my version. (Or, I guess, if one of my major planned features – like fully-featured killfiles that can inject CWs based on filters, or multi-account support with a merged timeline – can be done in 1/10th of the number of lines with a python3 feature.)

                                1. 1

                                  Obviously it’s your bat and ball, but if you really want people to feel welcome to fork, you should make it its own repository, that way they can fork and also pull your upstream changes as you evolve the script.

                                  Just a thought :)

                                  1. 3

                                    It’s in its own repository now. (That’s what triggered me to post it: a couple folks asked me to stick it in its own repo so they could submit pull requests easier.)

                    2. 3

                      Nice name ;)

                      1. 2

                        I was sort of surprised to find that there weren’t any major projects with that name already.