Some people talk about mailing lists with a lot of reverence, but I have only ever found them to be extremely ugly and unreadable.

Are there any good clients out there that make them readable? For example a lemmy-like, threaded interface with interactivity? Or for PR/MRs an interface that shows the diffs with syntax highlighting, toggleable unified and side by side diff views, ability to comment within diffs and continue discussions within them (maybe even threaded)?

  • who@feddit.orgEnglish
    4·
    20 hours ago

    If you hate having information delivered as text, you are never going to love mailing lists. They are not applications, and most likely never will be, since that would break the universal interoperability that makes email valuable.

    However, email does support threading, and it is possible to find user agents (clients) that support it. Perhaps someone who has compared them recently can offer suggestions for whatever platform you use. (I can’t, since I’ve been using a proprietary one for ages and don’t know what else is out there these days.)

    Also, you might find that some are better than others at formatting text to your liking.

    • onlinepersona@programming.devOP
      2·
      19 hours ago

      If you hate having information delivered as text, you are never going to love mailing lists.

      Wdym? I’m reading text right now. We are interacting with text right now. It has formatting, has linking, has syntax highlighting, all depending on the client.

      key: value
object:
  key: value

      All this exists in lemmy and I love it.

      A lot of other metadata exists in emails too:

      • identities
      • timing
      • person being responded to

      Even reactions could be implemented via email e.g if the response body is a single emoji --> reaction.

      • who@feddit.orgEnglish
        1·
        8 hours ago

        The problem is not data representation. Yes, you could build fancy display features into an app that understands email, and define a data format for representing those features in email attachments/parts. They could then display just fine in your Onlinepersona app. (Or you could just use HTML email, which already has partial support in some user agents, though it is not universal.) You could even go so far as to define a reply protocol for your app to share data edits via email attachments. Those replies would be useful to other people on a mailing list who run your app.

        But at that point, what you’re using is not a mailing list. It’s an Onlinepersona app that happens to use a mailing list as a transport for your overlay protocol. To everyone on the list who doesn’t use your app, its traffic would be noise.

        In other words, the problem is not data representation, but adoption. Good luck getting all the world’s email software to support your niche extensions. I think the most you can realistically hope for is to convince the members of your favorite mailing lists to either use your app or tolerate the noise it generates.

        If you’re confident that your app is wanted by enough people to make its development worthwhile, then go for it. Just realise that it won’t be an email client; it will be an Onlinepersona client.