[visko]

This is a concept that has probably been thrown around a lot by various people; a friend of mine and I have been playing with the concept for a while now, and said friend has actually developed the server-side code, or so he says. I have yet to actually see it.

I'd like to see if anyone is interested in building a fairly comprehensive template onto which coders can fill in the blanks and in so doing, allow their version of the PTP to check for all data that is normally stored in their pfiles. This kind of code could (theoretically) have some really cool ramifications on MUDding in general, and I personally would love to be able to build up characters on multiple MUDs, run inter-MUD clans, and so on.

Anyone interested in at least throwing a few ideas around, and looking at the ramifications of such a patch?

-Visko

[thelenian]

The problem with this is you would need to have some kind of secure shared secret on all MUDs that implement this protocol. If all transmitted in plaintext (which I strongly suspect), this would easily allow someone to spoof you with a man-in-the-middle, or simply impersonate a trusted server... if your PTP even has trusted server authentication of some sort.

I'm assuming that, by allowing intermud clans, you also give the PTP daemon the access permissions necessary to update the pfiles. If you do, someone could easily spoof all the MUDs on your network and completely wipe your pfiles... and there would be nothing you could do about it.

Something like this is a security nightmare, and probably not quite worth the hassle.

Don't get me wrong, stuff like this is a cool in concept, but it just happens to be very difficult to translate into reality. If you're really serious about going ahead on this project, I would suggest that you change it to PTP over SSH2, at which point much of the security concerns are eliminated. Resolving the race conditions that will arise, however, is the hard part.

[Kallian]

This would best be implemented, imho, as an app on a centralized server whose only purpose was to store and transfer pfile information.

This seperate server would filter IPs and only allow participating muds to connect to it, as well as using a password for that individual mud, controlled by the individual mud admin and another password for the aforementioned server itself, which could be rotated on a regular basis if desired.

So overall, you'd need to be connecting from the IP of your mud, provide your mud's password, and provide the server password as well. This is relatively secure, triple-authentication scheme, that I would be comfortable using, if I was into this sort of thing.

[visko]

[Cerise]

The embermud team is currently researching and developing something along those lines. I haven't taken a peek at it yet myself but I'm sure it sounds like great fun.
I'm not sure if they are giving any information about this new project but you can try looking at:
Cant hurt to look.

[Yui Unifex]

It sounds like an interesting idea, but it has a few problems that need to be overcome:

First, the stats that the playerfiles accumulate need to be compatible across all of the participating game systems.  I can foresee this happening with one mud that's simply distributed everywhere else and code changes work in tandem, but not really with seperate muds that may have entirely different ways of doing things.

Second, you'll need some mechanism for keeping the system fair.  I shouldn't be able to start a mud, mess with my pfile and make my player invincible, and then go to other muds and have an invincible character.  So there's got to be some sort of cabal of people that review the caliber of admins and games that are allowed to participate.  This problem might be mitigated if you used a central server to dictate starting stats for the various pfiles, and you could run checks on the pfile database to see if one player mysteriously jumped levels.

Third, the authentication for these systems must be secure.  But this is easy to accomplish by simply using an SSH tunnel, as thelenian noted.

Overall, I think the idea is excellent in terms of writing a "distributed" mud world.  Many more problems arise, but those are really questions of implementation that can be solved with enough effort.

[Thoric]

What is the purpose of this pfile transferring?

MUD pfiles aren't generally compatible unless you have the same area files.

A better solution (in my humble opinion) would be a mechanism to "switch" into a character on another MUD.

You would have a much easier time coming up with creative reasons for why you have a different body (and different eq) in different worlds than the administrative issues of trusting other MUDs, and pfile compatability problems.

It could work like this...

You have a world travel spell where upon casting it would put your character into a special location temporarily to protect it, and then put you in control of a character on the other MUD (via a new connection, or through some IMC-type interface system).

[visko]

I'm not sure exactly what you mean by "taking over another character in another world", Thoric, but to answer both you and Unifex...

The basic idea is that this protocol at the user level (the mud transferring the pfile) just sends it over to another mud, or sends it to a database processing server. I would personally prefer code in each MUD that interprets the different player files from various MUDs, but the end result is this:

A filter-like program that would be added to each time another MUD joins the group of MUDs running their version of the PTP checks which MUD the pfile is coming from. Based on a list of differences in stats, gold usage, hp, mana, move, etc. this program modifies those characteristics up or down. Anything in the pfile that can't be used is stored for later use on MUDs where it would apply. Skills that a player might automatically have on one MUD are not just given to the player; obviously, when you travel to a different land, you have to learn their customs and practices the hard way.

Pfiles could get pretty large after a while of travelling to different muds, but there are already patches out allowing pfiles to be gzipped for more efficient HD storage.

The other problem is security; problem admins, problem players with shell acces, etc. Quite frankly, there is no code I can think of that's going to stop a stupid admin from wreaking havoc on a system like this. At that level, the admins who are already in on their PTP group will have to make decisions based on the integrity of the people who are requesting admittance into their MUD system. This also has the effect, possibly, on having like codebases stick together, or at least have different code bases working on the same basic ideas so that they transfer to more MUDs.

The code itself is going to be complex, but it's fairly straightforward once the most obvious problems have been discussed and worked with. A lot of the things that are coming up in this thread are really good problems, and it took the two of us a few months to put all of these onto the table. However, the end result of the conversation was that this isn't just something you patch into your MUD and go with; this requires a bit of time and a good bit of energy to implement and maintain well. But once the code is out there, I think everything will be just a tad easier.

-Visko

[Thoric]

What I meant by "taking over a character on another MUD" was that your character on another MUD would be based on information that MUD keeps on you, not the information your home-base MUD keeps on you (other than plain vanilla stats, race, class, etc).

When you "travel" to the other MUDs, the home-base MUD would only transfer vital information across, and not transfer your whole pfile.

Those other MUDs would do their own storage of your character. The home-base MUD shouldn't have to maintain stats on your character on other MUDs. This also protects those MUDs against home-base fudging with those stats.

[visko]

The only problem we came up with when we entertained that idea was storage space and character continuity. If a character gains really cool equipment or hp bonuses that would greatly aid him/her on another mud, but those things don't transfer, then the whole point of allowing characters to use multiple MUDs to progress becomes moot, and you have a completely RP-like reasoning for the thing; travelling to distant worlds to talk to other people.

The other problem, storage, is something that may or may not be an issue. With hard drives becoming very cheap and mudservers gaining GB worth of extra hard drive space now, storage quotas are going up, and with their rising, storage issues go away. Still, it would be nice to not have to worry about having the entire pbase of 15 different muds stored in your player directory.

-Visko

[Thoric]

So you want experience gained on external MUDs to count on your home MUD and/or vice-versa?

I think there will always be problems (or potential for problems) with that situation.

How do you deal with the problem of naming?

What if the player name already exists on the external MUD?

[visko]

If the name already exists, it prompts you for an alternate name. That will be the one you use on that mud at that moment. Primary name stored in the file, secondary name used on that mud. If necessary, multiple alternate names can be used.

As far as experience and everything else porting to another mud, yes, it would. Any MUD that entered into the goup would have to accept that older players from other muyds would be logging onto their mud and causing havoc. If you're in a step, you're in all the way.

This isn't something that every mud is going to want, and it's more likely that newer muds will try this in an attempt to pool pbases. But although this does require more work on everyone's part, the end result could be 500-3k players all knowing and playing with each other in huge multiple worlds, building very large intricate clans and alliances.

The ends just have to justify the means, and the code aspect doesn't play a role there. At that point, it's just getting enough good admins together to make it worthwhile.

-Visko

[Dre]

[mhc]

Anyone remember UnterMUD and UberMUD... ?

[Teelf]

I think it would solve a lot of problems if some sort of "standardized" pfile was agreed upon.  The powers that be would decide on the variables to include and what they represent. They would set a scale for each.  Example:  They could include an unsigned int for experience and set its scale from 0 - 1,000,000.  

Each MUD could inteperet this standardized pfile anyway they choose.  Example:  10,000 exp from the standard is equivalent to 2,500 exp on my mud.

Each MUD would write a function to convert from and to the standard.  That way invidual MUDs could handle problems such as characters having the same name in any way they choose.

As a side note, MXP has the ability to invisibly relocate a user to another server automatically.  That might come in handy in conjuction with something like this.

[SoEnSo]

Okay along time ago me an my buds were actualy talking about how todo this, it was when we first discovered IMC, this was waaay back, we figured if we developed a system like that, it would work..

But we never got into the building phase of it.

You see, the problem with it wouldn't be the player file, thats not a problem, the playerfiles would just store the information of the objects/clans whatever all in ur pfile, it would never really leave your system.

but the problem that would be, would mainly be the security, and the design of the hub... Then the compatability issues. As when your playing the other mud, you'd have to beable to access their commands, inwhich, you would most likely loose functionality to your own muds info. So for each mud online you'd have to write an interpreter for it, so that you'd beable to access the other muds data, and your own. This is what i'd like to call.. The pain.. As writing this would basicaly cause your mind to melt. Each new mud would require an intreter.

Now what about muds like.. Godwars, where you can't be killed unless your decapped.?? There again, more problems arise. Your player, meets on a Rom, with a player from a Godwars.. Now you gotta decap... Theres allot of compatability issues..

So once again, each mud thats online that has 1 simple difference, would require its own interpreter.


Anyways, we came to this conclusion at the wee hours of the morning. Its just my 2 cents, but fact is.. thats how it is.

[visko]

I disagree, SoEnSo...

The fact is, the player file just stores information, as you said. The thing is, that information will be interpreted differently by each MUD by default. So on a GW mud, a ROM player would have to be decapped to be killed, and on a ROM, a GW player would be killed without the need for decap. The characteristics of the player would be adjusted by the PTP server-side code to allow for fair interaction with the game in between MUDs, as Teelf was kind enough to point out, and after that the player is at the whim of the coder who built the place.

Yes there will be compatability issues with stats/skills, as people have already mentioned. Those will have to be dealt with as the protocol progresses, one issue at a time.

I may be missing something, but I don't understand why you believe what you do. Could you give me an example that would show more clearly what you are thinking?

Thanks,
-Visko

[Robbert]

Interestingly enough, this same concept is what began the TCP/IP protocol - a method of communication interaction between systems which spoke their own internal languages.

One wonders though, assuming that hypothetical level of cooperation between mud admins, why they don't just merge their efforts into a single game? ;-)

[Loriel]

Ignoring all the technical and security problems involved in this proposal, I would like to question the benefits that it offers.

As I see it, any high level/experienced player on mud A can use this system to jump straight into mud B with a similar high level, without going through the process of "learning the mud".

This does not seem to me to be a good idea in general - having an ignorant high level player wandering around is going to be bad for both that player and the rest of the playerbase, who are going to be at risk from his mistakes, and jealous of his instant elevation to such high status.

It seems to me that it's only likely to work well if the muds involved are very similar in nature - not only in underlying codebase and player interface, but also in theme and quality of playerbase - which provides an incentive for 'copycat' muds rather than original thinking.