💾 Archived View for bbs.geminispace.org › u › satch › 20859 captured on 2024-12-17 at 15:25:09. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
Re: "Threaded View in Misfin Clients"
@jecxjo this is not part of the spec, but rather advice for implementers who want to do threading with misfin. These aren't rules, simply useful bits of information.
Oct 14 · 2 months ago
🚀 clseibold [OP] · Oct 14 at 18:21:
@jecxjo I just have to say, when the Gemini community suggests every single thing is complicated and overkill, people start to wonder about the community's competence and minimalist extremism, which seems to be for no other purpose than for minimalism's own sake and viewing oneself as superior.
If you're seriously going to stand here and tell me that threads, a feature we've had for decades in multiple different protocols, including NNTP, SMTP/email, Forums, and BBSs, is not desireable, and that it's overcomplicated because of a few string matchings, then I just have no words for you.
Everything I described above can be implemented in a couple hours with a hashmap. As for the bash scripts, I have no sympathy for them. That's not real programming and people are misusing something that was originally intended for batching commands for running things in the background on multiuser mainframe systems. If things are overcomplicated in bash and batch scripts, it's because you're not supposed to be using them for this stuff in the first place.
As for real message IDs, they also require rules, and actually can be more complicated than the simple method I described above.
While it's not specifically part of the spec, it's a feature of the protocol and will inevitably be something any good client would need to implement because people use and expect it. That's why i question the return on investment for a feature like this.
Right now the message body is gemtext with an optional first line as a header denoting a subject. And the message protocol is relatively out of control of the users or applications. So setting up a subject match along with To/From addressing seems to jumping back and forth and atill only a guess that things are actually threaded.
🕹️ skyjake [mod...] · Oct 15 at 04:14:
@clseibold:
I just have to say, when the Gemini community suggests every single thing is complicated and overkill, people start to wonder about the community's competence and minimalist extremism, which seems to be for no other purpose than for minimalism's own sake and viewing oneself as superior.
Maintaining minimalism while creating something useful and elegant requires a great deal of competence. You do not achieve minimalism by adding features and rules, you achieve it by removing what is not essential.
Rather than doubting other people's competence, we should celebrate the fact that when technology is simple and approachable, it can be used regardless of one's level of skill and experience.
I would say the Misfin(B) that @jecxjo references is more akin to a direct messaging protocol, while the people behind Misfin(C) are trying to build a more well-defined and full-fledged email-like system. There is a difference in mindsets.
@skyjake @jecxjo I have to say I see things a little bit differently. I don't want to contribute to any tension here, it would be really silly to get heated over whether threading is complex or simple or minimalist enough or whatever, but I just want to be clear about a couple of things.
Misfin(B) was intended to be email-like in that it would support multiple recipients and therefore group conversations. It was also compared to email more than any other type of pre-existing protocol and was pitched as 'email for the small web'.
Misfin(C) keeps with Misfin(B)'s spirit by being equally easy to implement and even less extensible.
Everything we are building on top of Misfin(C), from threading and mailbox verification to inbox search and mailinglists, is outside of the core Misfin(C) protocol and while these things serve useful functions, they don't increase complexity for those who want to keep things as technically simple as possible.
What we have is freedom to choose. Everyone can talk to one another using misfin, and just because I use threading and my server verifies that your mailbox exists before accepting messages doesn't mean that you need to implement those things. You are welcome to use a little bash script to send all your messages if you like, and read your incoming messages from the server logs just like we did a couple of years ago. There's absolutely nothing wrong with that.
I say all this because it's actually really important to me to maintain the lightweight approachability of misfin that makes it so much more fun to hack at and play with than something heavier like email. I don't think that's at risk.
Cheers!
@clseibold @satch my comment was never about the complexity and the ability of the community. it was about reflecting on minimalism because one should look at the community's needs and actions.
Look at the gemini client situation. we have dozens of clients with 90% covering the bare minimum. No titan support which honestly is needed to do heavy lifting, most only take one line inputs and don't support new lines so using BBS is a pain. SmolWeb is going to be pet projects that slowly become abandoned so maintaining minimalism in protocol and use helps keep the community alive when the code isnt.
When a misfin client doesn't support threading what will that look like? A huge mess of messages.
Threaded View in Misfin Clients — Since I have covered verification within misfin, I also want to cover how I have implemented Threaded view, and some other considerations that need to be made for Threading. Note that this is a client-side consideration, and has been partially implemented in misfin-server's client gemini interface, rather than the server itself. Threaded view tries to organize messages into threads based on a common topic. It is useful not just for responses to private...