[Feature request] Support for all existing MUD and MUSH protocols

[mdziczkowski]

Hello. First, I want to thank all for the great work they are doing in developing this great pice of software. Your work is very usefull and appreciated ;-)

But to the topic...

I have a question: Would it be possible to implement (hardcode) into pennmush the support of all existing MUD and MUSH protocols?

I saw that some are already there, but including the remaining ones would be also a nice extension of it's possibilities and would (at latest partially) join the both (MUD and MUSH) together, as a form of a kinda tribute to the common history.

I think that some pennmusher's (like me) could find a good usage for them :-)

Motivations

Including the support of those protocol would allow to "pull out" the most potencial of the server thru the modern clients (like for example: TinTin++, Mudlet, etc.

[talvo]

There are a lot of protocols for different MUSH and MUD servers, some of which are very unlikely to happen, either because the time investment required to code them isn't worth the payoff, or because they're more suited to MUD platforms than MUSH ones. Are there any specific ones you are particularly keen to see in Penn?

[mdziczkowski]

Hello. There are many protocols. I list only few examples of websites where they are listed.

There would be a longer research needed to find all of them ;-)

Note: Informations on some sites may be outdated

• List, see side menu
• Specification: the new MCP prorocol, ver. 2.1
• Specification: new MXP protocol
• Specification: InterMUD protocol, ver. 3
• Specification: MSP protocol

[ray73864]

Hello. There are many protocols. I list only few examples of websites where they are listed.

Most of those seem more MUD focused than anything else.

Keeping in mind that PennMUSH is a 'MUSH' server and not everything on that list would necessarily be relevant.

[mdziczkowski]

Hello. As I wrote above, this are only few examples and that I need to do research to find also the MUSH ones.

I thought that including those protocols could be a interesting extension of the Pennmush features and a kinda form of tribute to it's ancestors (as anyone knows, Pennmush has orginated from a MUD itself, but due it's "evolution", it had lost too many usefull things that could make it more interesting and the most advanced server from all ;-)

[talvo]

Penn hasn't lost features - rather, most of these didn't exist 20-30 years ago when Penn diverged from a 'MUD' server and they have since been introduced to Penn's distant cousins.

Penn already supports some of the protocols you've linked; it does prompts, GMCP, MSSP, MTTS

It doesn't support MCCP - doing so involves a massive amount of work for fairly limited benefit on modern connections where your average JPEG has a larger transfer size than a few hours' of MUSH connection.
MMCP's functionality is easily implemented by other means (such as bots or using @http) and versions of this have existed for years - and mostly died out due to exploitation/abuse.
MNES has some small value but most of it can already be done via other means.
MSDP also has some potential value, though again can be done in some other ways, and has some crossover with other protocols you've linked as well.
MSLP is for clickable links, which Penn already has via Pueblo, and is.. questionable. It would be relatively easy to implement however since the functionality is there already, it would just be a different way to pass it on to clients supporting the protocol.

MCP is a massive protocol and most of what it aims to achieve is duplicated through most of the above protocols.
MXP is pretty much Pueblo on steroids, and is.. still questionable.
The link you gave for InterMUD seems to be a proposal, not an existing specification, at a glance. It's also 20 years old and, again, provides functionality duplicated in most of the above protocols.
MSP is for sound - again, this is possible via Pueblo, but server-controlled sound is quite widely disliked from previous conversations I've had.

Implementing all of these would lead to several features existing 3-5 times in different ways and would make little sense. Most of them would provide relatively little gain for Penn. Most people who MUSH tend to use clients which have limited support for most of these protocols, as well.

Your request seems to just be "these all exist, let's toss them all in" rather than a specific desire to fix a problem/fill a gap - do you have specific use-cases/requirements for any particular protocol or feature?

[mdziczkowski]

Even if some protocols may provide similiar functionality, any additional optimization is valuable :-)

---

Let me try to give it on examples:

• MCCP (latest known is version 3) The protocol was created to provide a compression of the transmited data to spare additional internet brandwich (as we know, in that times the speed's weren't to high and all saved amount was precious).

This protocol (after few improvements) could become protected from mentioned by @talvo abuses by adding (for example) a generated token and provide an additional layer of compression, increasing both the speed and efficency of connection with the server (kinda a optimization of the client-server connection).

• MSDP: This protocol may used to implement additional services and/or bi-directional transfer in between the server and client of the data related to the world, etc.

This would allow a load balancing (optimization)

• MCP This protocol may used to seperate the client-server talk from the one of user interaction in the "world". This would give a additional level of isolation, secutity and load balancing (optimization)

• MXP As @talvo had noticed, this protocol is an extended version of pueblo, with provides additional fatures with pueblo doesn't had before. Even if it's questionable, it could be used (for example) to generate informational (if not dynamical) pages about the world itself and maybe a map, thru with users could interact.

• Intermud This protocol was created in thought of interacting in between two servers and providing a "hub" that would (among other) list the registered ones, containing their informations (including the ones needed to connect to them) and their status. It may be used other way, but I haven't had time to read it's documentation yet

• MSP: Thru this protocol penn stop beeing mute and would allow to add sounds bound to some world related actions (like for example: hitting a closed exit ;-p )

---

As @talvo had noticed, thru the time, in the development process, some functionality was duplicated, but only because the autors were trying to improve the existing protocols (with various effect of that)

[ray73864]

Now name the clients which implement these protocols themselves?

Hint, most people these days use either SimpleMU (No longer supported or even being developed), Potato, MUSHClient, BeipMU, or TinyFugue.

With a lot of people likely using either MUSHClient or Potato / BeipMU unless they are into the whole linux command line thing where they would then gravitate towards TinyFugue.

MUSHClient supports MXP and MCCP, plus Pueblo.
BeipMU supports MXP only (from what I can tell).
TinyFugue supports MCCP only (from what I can tell).
Potato I believe supports MXP and MCP and I think Pueblo?

That's basically the extent of clients that connect to a PennMUSH based game, so there is really no point in PennMUSH trying to support any other feature, as it'll just create code bloat and sit there unused.

[mdziczkowski]

I use two, with have implementation of some (of corse not all) of them:

• TinTin++ - Specification of features, where are even listed protocol's about with I had forgotten to mention
• Mudlet

[mdziczkowski]

As curiosity, I would like to mention that Mudlet has even an additional, seperated protocol called MMP (MUD Mapping Protocol) that it's responsible for displaying and interaction with map ;-)