I've moved in that direction. Then again, I never disagreed with you on the point. :)

Well, that and have to install special client software that supports it, rather than use any client at all including telnet.

This will fall over the moment the spider's IP address changes. In today's cloud-hosting world, that's extremely likely to happen. Even Aspect gets a change of IP occasionally when I push a new version, as Heroku loads it into a new virtual machine and shuts down the old one.

This is what I'm getting at. The approach described thus far basically disregards the actual meat of an intermud: the protocol.

The logic of who logs in from where and who talks when and where it is seen by whom and in what manner, all that stuff
bears serious thought and design, as opposed to being an afterthought bolted onto your favorite connection method.

IMO IMC2, with all its faults, actually got one thing right: it's simple to implement and maintain. If you want to
do the intermud world a favor, revamp IMC2 into something that handles exceptions and delimeters and colors better,
and that can route between trusted servers without having to be locked into some specific set of deranged admins.

But you do it incrementally. One step at a time without leaving people behind, and most importantly, without
insisting on, of all things in this world, telnet options and negotiations.

Just to be clear, I'm all about people having fun and if this MSDPnet thing is fun then by all means go nuts.
But if you're going to actually talk people into doing it WITH you, for heaven's sake, bake it and
have a design in mind for the actual intermud protocol.

-Crat
http://lpmuds.net

I'd be fine with that, yes.


Only the mud and the spider would need to support MSDP for the intermud communication described here. The clients used by the players wouldn't matter.


Most muds keep the same static IP address for years. However it could use a domain name just as easily.

Guys,

For an intermud network, wouldn't it be a lot simpler if we had a snippet and instructions for pushing and reading chat lines to / from a database server? If people are not willing to compile their MUD with an SQL layer, it can even be implemented with wget calls to some simple php push/pull script…
P.

I'm not sure why we need a SQL database server, but no, invariably people want all kinds of other things – we've talked about a few already like channel management, emotes, private messages, etc.

If all you wanted was a mechanism to push messages out to other people and that's it, then sure, you don't need something complicated. But that's not all that people tend to want here.

Hmm, I see. So "people" tend to want complicated stuff with "minimal investment" and they want it all done over telnet, whereas a web-based push/pull will be 10x simpler, make that 20x if you want advanced functionality (e. g. http://www.phpopenchat.org/), and won't lag their game…

Fine by me.

Plamzi, you're forgetting that this stuff already exists. You're talking as if you're comparing building this vs. building that, but that's not the situation here…

I was under the impression that it was the MUD that would be checking the spider's IP.

Wow. Kudos to DH. I'd thought Plamzi was joking.

Plamzi, the complicated stuff does exist and with minimal investment too. The functionality I described is almost all available in the
existing intermud protocols of IMC2 and i3. All you need to do is use one or another of various clients for either one, or both,
readily available either in this code repository or often enough actually pre-built into your codebase.

Which is why I keep harping on the usefulness of this LSDPnet…and how it's really missing out on the point and
services provided by the far easier to use alternatives.

Having said all that, since Scandum can build it into Tintin as an integrated distributed chat network, THAT would be
a neat thing to do and THAT would eventually prompt people to hook up to it with their muds…maybe.

-Crat
http://lpmuds.net

I wasn't joking–I was trying to come up with a minimal approach that I would consider adding to my server. Also, it was my impression that existing intermud protocols have near-0 adoption rate and a lot of rolling tumbleweeds. If they're baked into modern codebases with high adoption rates, then I would go back to questioning whether this project has an audience.

Sad to say IMC2 has not yet recovered from its tragic admin meltdown a few months back, but i3 is alive, kickin and thrivin:

http://lpmuds.net/intermud.html

http://www.mudworld.net/imud/logs/?chan=...

http://www.mudworld.net/imud/logs/?chan=...

As to whether there is trolling…well it's the internet. One does what one can by applying topic rules to the various channels. That works pretty well mostly.

-Crat

Hmm, to be blunt, I see a couple of devs chatting, which I'd be hesitant to call 'thriving'. I can get all the socialization (and patronizing) I want here. And chances are my players wouldn't be interested since the players of all those (hundreds?) of MUDs hooked on i3 don't seem to be…

Personal pass, but good luck with trying something different.

Heh. I think you might have missed a thing or two, but thanks.

I was looking to implement something basic. If the concept works someone might want to create something more advanced, but I'd hate to invest a lot of time in something that might be dead on arrival, not to mention I know little to nothing about intermud systems.

What I worry about is that identification by IP would throw the network down if the spider changes hosts, and that identification with a static password would be annoying to keep up with if the network becomes popular.

One work around would be to automatically create a password, and have the MUD set priorities on passwords. This way a priority 3 spider could be assigned to the chat channel, and be thrown off when a priority 2 spider comes along.

So if the spider finds a new MUD it generates a random signed 32 bit number, saves it, and gives that as the password. If the password is unknown it gets the lowest priority. The MUD can then increase the priority for a given password, and if desired, a different priority for each channel. If a MUD is very protective it may severely restrict what a low priority spider can do, other than to hang around to get a priority bump.

Problem spiders would be dealt with the same way as problem players are, I don't think this needs special handling.

Either ARACHNOS_LOGIN or ARACHNOS_ID could be used for a 32 bit non zero key, ID probably fits better than LOGIN in this case. Another issue would be assigning channels. Easiest would be ARACHNOS_CHANNEL <name> upon which the server would set the ID and priority for the given channel. If already set it can only be overwritten by a spider with a higher priority.

I'm open to better ways to go about this.

I think it's a waste of your time, the way you're approaching it.

It's like when someone's only tool is a hammer, and everything looks like a nail. Intermud isn't a nail.

But, as I've hinted a couple of times, your market penetration in the client arena puts you in a remarkably
advantageous position to do something innovative with intermud, specifically a client based integrated interface.

If you can get over the need to apply telopts to everything you touch, you might notice the potential
there for doing something interesting along the lines of integrating clients with existing intermud protocols,
perhaps extending them to suit that purpose.



If you intend to get into the intermud thing, do some homework. You might discover you like it.

-Crat
http://lpmuds.net

I posted that last year. I think the only thing I'd say differently is concerning the obstacles. Clearly if such a network is fully distributed, then the only people one cares about buying in to the idea are those operating the clients, mostly players. If the same old hierachical topology of muds subscribing to some fella's chat kingdom is used then one just repeats the same experiment. I would tend to put "Why are you writing yet another intermud network?" into the same category as "Why are you writing yet another mud?"
… Because we can.

I don't know what you require for something to be "thriving", but from the logs I've kept over the last year and a half:


25,000 messages a month, give or take, doesn't seem too much like a ghost town to me.

+1 to Crat's post. Another thing to consider is that if you didn't like the more, ah, 'social' aspects of protocol design, you're in for even more fun and games if you want to make a fundamentally social protocol. You're also going to run into the problem of there being very serious inertia and, so far based on current discussion, rather little incentive to change.

It kind of feels like people have this thing and are looking for problems to retrofit to it, rather than addressing an actual problem. (Because if you were trying to really solve the intermud problem, you'd be going about it differently anyhow.)