I was thinking one way to promote data protocols is to setup a client that connects to multiple MUDs and relays messages between them, MSDP would be a good way for client and server to communicate.

There are a couple of problems:

1) In an ideal situation there'd be one client connecting all participating MUDs, but as this is unlikely to happen there ought to be some kind of mechanism to avoid two clients connected to the same two MUDs relaying the same message twice. One solution is doing this server side, the server simply blocks duplicate messages, which might be the easiest approach. Another option is having a master server that all clients connect to that deals with conflict resolution, the advantage is that it puts less of an implementation burden on mud servers.

2) Existing Intermud protocols exist, not sure if it's the smartest idea to add yet another one.

3) Rogue clients and vandalism could be a problem. Servers may very well have to only allow Intermud clients from specific domains, or require a password.

4) Is it desirable to have clients perform tasks like mail? If the client side mail functionality is good enough a server may very well decide to handle all mud mail client side, maybe even have a specific trusted client or master server to handle mail. Other useful services could be added as well, like user profiles.

The actual data transfers would be pretty simple MSDP messages. For example:

IAC SB MSDP VAR "TIN_MAIL" VAL MSDP_OPEN VAR "SENDER" VAL "Runter" VAR "RECIPIENT" VAL "Scandum" VAR "HOST" VAL "lolamud.net" VAR "SUBJECT" VAL "Come on Scandum" VAR "MESSAGE" VAL "Teach me your skills. How do You check to find out if people are hacking your files. If it was you I want you to teach me. How do you get information on people. How do you get into other people's computers. Do you upload a program like Sub11? I want to be able to hear people talking through their microphones when they think they are all alone.. is this possible?" MSDP_CLOSE IAC SE

What problem is this solving? As you say, intermud protocols exist already. They exist to provide a chat platform. Are you adding something that doesn't already exist?

Easier implementation would be the main advantage, that is, for MUDs that already support MSDP.

Well, I'm the first to say that IMC2 at least is kinda messy. (I haven't looked at I3 from an internals perspective.) But that's not only because of its weird data format; it's also that there's just a lot of stuff to implement to get this working. It's not as simple as whizzing messages around, although I agree that a sane message format would be better. It's just that I don't think it would be so much better as to justify all the work around it. (And finally, I would want a format that had explicit, full support for rich structured data, preferably in a human readable fashion.)

I3 can be used to send data, as it uses what they call "mudmode", which just means it sends data in the same format LPC save files use. I believe Aidil implemented a JSON version of the I3 protocol which can be used on his server for those who might want to not deal with the LPC syntax.

Another option would be to have an IMC client that also connects to one specific mud. The owner then downloads the client and runs it alongside their mud as a separate application. You could ignore IMC bots that don't connect from localhost, and it would connect you to an existing intermud network. Thus rather than competing with intermud, you'd actually be promoting it.

If this was built in to the MSDP snippet, it would actually be an easier way for people to connect to the intermud networks than the existing IMC snippet - particularly for me, as I don't want to use the existing snippets due to either licence or language issues.

That would work as well, though it might be better for one of the existing networks to implement MSDP and have their server create outgoing connections.

Can anyone tell me how to obtain a password to connect to IMC? The documentation has a password field, but there's no information on how to obtain one.

If memory serves, you just pick one at random. If it hasn't seen you before, it associates that password with that name, or something like that.

Ah okay, it's too big an investment for me though as any work I do on an IMC MSDP proxy will probably never be used.

I wrote a simple tt++ script that creates an MSDP Intermud client with support for chats and tells. Muds send MSDP data to the client, in the case of a chat the MSDP data is converted back to TELNET and broadcast back to all muds the client is connected to, in the case of a tell the MSDP data is broadcast to one specific server. Servers would have to support MSDP nesting or a simple parser for TIN modules, and upon receiving the data would display it to the recipient(s).

#format IAC  %a 255
#format DONT %a 254
#format DO   %a 253
#format WONT %a 252
#format WILL %a 251
#format SB   %a 250
#format SE   %a 240

#format MSDP %a  69

#format VAR  %a  01
#format VAL  %a  02
#format OPEN %a  03
#format CLOSE %a 04

#config debug on

#event {SESSION CONNECTED}
{
        #send {$IAC$DO$MSDP\};

        #send {$IAC$SB$MSDP${VAR}INTERMUD${VAL}TIN$IAC$SE\}
}

#event {IAC SB MSDP}
{
        #switch {"%0"}
        {
                #case {"TIN_CHAT"}
                {
                        #var TIN_CHAT {%1};
                        #all chat
                };
                #case {"TIN_TELL"}
                {
                        #var TIN_TELL {%1};
                        tell
                }
        }
}

#alias {chat}
{
        #send {@tin_data{TIN_CHAT}\}
}

#alias {tell}
{
        #if {"$TIN_TELL[RECIPIENT_HOST]" != "%*.%*"}
        {
                #return
        };

        #$TIN_TELL[RECIPIENT_HOST] #send {@tin_data{TIN_TELL}\}
}

#function {tin_data}
{
        #var {result} {$IAC$SB$MSDP${VAR}%0$VAL$OPEN};

        #foreach {$%0[]} {key}
        {
                #var {result} {$result$VAR$key$VAL$%0[$key]}
        };

        #var {result} {$result}$CLOSE$IAC$SE
}

#ses godwars2.org:3000 godwars2.org 3000

The best solution is probably to upgrade an existing server to create outbound connections and communicate their protocol over MSDP.

Like I've said before… a fully distributed promiscuous network is the way to go where every client is a server, and every server is a client. The primary obstacle is control freaks who believe some centralized server and committee needs to safeguard and protect the mud world. It's not technological. Telnet is actually pretty useless and the wrong way to go with this.

The Mud Master Chat Protocol works this way, downside is that the network tends to fragment, which makes it a lot harder to reach critical mass. Even then, every MM chat server I know off is password protected, and I think the same would happen to a decentralized network.

With 14 MSDP muds the idea of an MSDP based Intermud chat seems viable now. For ease of reference I'll call the network ARACHNOS. Having given this a little more thought the easiest implementation would be as following:

1) Spider connects to a server and requests ARACHNOS_CHAT to be reported.
2) Server starts reporting chat messages using a table that contains: SENDER, HOST, PORT, and MESSAGE.
3) Server also has ARACHNOS_CHAT enabled as a configurable variable.
4) Spider forwards ARACHNOS_CHAT messages to other muds in the network.

Implementation details:

1) In theory anyone can listen in on chat messages, not a big deal.
2) The MUD will need a command for players to generate ARACHNOS chat messages.
3) Servers will likely want to restrict (by IP) who can modify the ARACHNOS_CHAT variable to avoid spoofing. Whenever it is modified the server would broadcast the message in game to whoever is tuned in.
4) Servers without associative array support will have to write a custom parser, this should be fairly straightforward as messages will have a very generic form, and be translated to something like: bubba@bubblemud.com:3000 chats: I want a twinkie.

Thoughts?

Yes: why?

And yes, that is a serious question. What is the gain here?

Various gains.

1) It might appeal to MUDs who want some kind of intermud functionality with a minimal investment.
2) It provides another use for MSDP.
3) It's something that can be shipped with MSDP handlers, as it's client independent.
4) If shipped it'll provide some useful example code of how to deal with more complex data.
5) It could be used for MSDP related announcements and discussions.

I don't think this is a *terrible* idea, but I don't see point or use. I might be missing something, I confess, and perhaps my perspective is a bit biased.

If your experience of "intermud" is IMC2, then I can see how this might be an interesting thing to try. Mudbytes IMC2 at this point
seems to consist of random messages from me every few days, and sometimes Quix, Kali, or Sini.

Based on that, pretty much anything represents a step forward, and if it's just 16 muds on a Scandum protocol, well how much worse than MB IMC2 could that be?

My perspective though, isn't limited to MB IMC2, and from that perspective I suggest that a chat network isn't *about* the technology used to
implement it, and the dicussion I've seen here so far focuses much more on shoehorning a technology into a niche it awkwardly occupies,
rather than well-thought-out establishment of a new chat network.

I might be missing something, and I do wish you luck, but I don't really see that you're approaching this from the most useful angle,
nor that you have a clear view of what makes a successful intermud work.



I agree with greater decentralization. I've avoided trying to implement a New Intermud Order that does this, because I also don't
want to squander what uptake there is on existing protocols. Instead I've tried to establish a network of networks, wherein confederated
admins can choose what policies to enforce, and subscribers can choose which networks to join. Alas, people are a lot lazier than
I'd suspected, and just use the default network, and few people seem serious about peering in a confederated rather than a
fully promiscuous way.

My reluctance to actually implement rather than just advocate full decentralization isn't about control but rather disinclination
to toss overboard the subscribership as it exists. And without doing that…without forcing people to join The New Way, I don't
see why they would. My observation of the habits of established muds tells me it's impressive enough they even maintain what
ancient comm protocols they currently have.




Like I said before, I wish you luck. At worst it'll be a dead chatline. Since I suspect your approach really
is mud client based anyway, that is probably your best vector and opportunity for success. Sandwiched
between your commercial ads in Tintin you could have a chat window that players can use to tune into different
TintinChat channels, and after a while muds might decide to implement TintinChan for their imms. You should
probably try that angle, if you want uptake.

-Crat
http://lpmuds.net

Maybe, although I'm not sure how this investment is "minimal".


This doesn't seem to be a benefit for anybody except those keeping score of MSDP uptake.


What advantage over existing intermud packages? (which don't require anything to be shipped to anybody beyond the MUD server)


You can demonstrate complex data handling without trying to get a bunch of people to get on some new chat network.


So could this forum, or your website(s) – things that already exist with no work.



If you want to do this, that's fine, but honestly I don't see the point and IMHO you will spend your time far more beneficially working on other things than trying to get everybody on ScandumChat.
If you're trying to solve the chat network problem, there are better ways to do it than retrofitting this into it. You have a data transport protocol: it is nothing to do with a chat protocol.

How about something like this…

First we do the standard handshake and introduction:

Server: IAC WILL MSDP
Client: IAC DO MSDP
Server: IAC SB MSDP MSDP_VAR "SERVER_ID" MSDP_VAL "God Wars II" IAC SE

At this point your spider compares the SERVER_ID with the name it's got stored internally, to make sure they match. If so, it then logs in with a password I've provided you:

Client: IAC SB MSDP MSDP_VAR "ARACHNOS_LOGIN" MSDP_VAL "password" IAC SE

I check that both your password and IP address are correct. If they are, I add a flag to your connection which prevents you from being disconnected after 60 seconds, and allows you to send ARACHNOS messages. If you've already got another connection logged on, I disconnect it.

An ARACHNOS message should include the player and mud name, as well as the message itself. The channel name and a timestamp might also be worth including.

The spider can store the password along with the connection information, meaning it'll have the password ready as it connects.

The biggest downside of passwords is that it'll be harder to restore the network when a spider goes down. A more promiscuous approach might work better, though that would require some way for multiple spiders to work alongside each other.

The spider can keep track of the mud name, host name, port, and add a time stamp. So the server would only need to send the player name, message, and channel.

Two or more spiders could connecting using different channels, in which case authenticating the channel might be worth looking into? Possibly allowing protected and unprotected channels.

Right, this is where the actual fun is. MSDP at this point is no longer the comm protocol, it's the (for practical purposes) transport layer, and the
real intermud communication protocol is what now comes into play.

This means handling different kinds of comms (emotes, regular chats), refereeing between conflicting usernames (since doing
this at the transport layer means actually rejecting conflicts), establishing point to point tells (presumably out of band, right? How
shall the muds authenticate through Scandumnet to establish bona fides? Or will you have a SEPARATE point to point MSDP
intermud that isn't arbitrated?), etc. You'll want standards for using/establishing new channels, some private "invite only".
Remote who, too.

Basically all the stuff that IMC2 and i3 already do and that people expect from an intermud.

Or was the plan to set up the transport layer and just kinda leaving it at that, with just bare chats (like IRC) and that's it?

-Crat
http://lpmuds.net

Hmmm, sounds suspiciously like my repeated suggestions to develop a better overall protocol for MUD connections, except you guys want to do it one layer higher up.

I keep saying, ditch TELNET and use a message protocol atop TCP where the messages are all data packets instead of text with markup. Now you're saying, use MSDP over TELNET over TCP, but almost all the cool structured features that people will want are in the MSDP data packets.

The only real difference I see is that people with old clients that know nothing about MSDP can, IN THEORY, still play your games. But in stripped-down mode which fewer and fewer people will take the time to support, just like people nowadays assume VT100 and ANSI support. In your future, mud admins will assume MSDP support and anyone not using is pretty much screwed.

If you used my idea, it would work pretty much the exact same way, except you wouldn't need to continue to pick apart the bizzaro world of IAC sequences, you'd just grab packets and toss them to the parser, which would return a nice data structure your code can then use without needing to wonder if byte 2791 was a malformed escape sequence which might be continued in the next packet or might just be an improperly terminated thing.

Oh, one other iron to toss on the fire that *IS* relevant to your idea, regardless of what you think of mine… Many people connect to MUD's from work, primarily to sit on the I3 chat lines. Currently, that only requires a single TCP connection to a single MUD. If you move your chat system into the clients, will they all have to connect to your centralized chat server AND a mud? Or will it be distributed, in which case your network admin now sees dozens of connections to random places as various clients talk to one another?

Good luck!