23 Mar, 2009, David Haley wrote in the 161st comment:
Votes: 0
Why would MUD sites reject the ones done by hand but not the ones registered with the 'use MSSP' flag set to true?
23 Mar, 2009, KaVir wrote in the 162nd comment:
Votes: 0
They wouldn't, because the human administrator would reject the "fake" listings. It's the full automated approach that would have trouble.
23 Mar, 2009, Cratylus wrote in the 163rd comment:
Votes: 0
David Haley said:
I don't understand where this "poison" is supposed to come from if a MUD reports a "poisoned" IP/port.


Sample scenario:

I run Dragonball Scheisse, and I haet the owners of Dragonball Merde.

I start a mud running on some ip I don't care about…maybe even my
cable modem at home, and call it Happy Fun Mud and add it to a listing site,
checked with I-do-MSSP.

Cupla days/weeks after the listing is approved, I change HFM's MSSP data. It
now claims to be Dragonball Merde and the ip and port point to
Dragonball Scheisse.

Or I could be even more discreet and have it point to Aartwolf. Anything so
long as those immature punks at DBM don't get more players.

-Crat
http://lpmuds.net
23 Mar, 2009, David Haley wrote in the 164th comment:
Votes: 0
Well, the human administrator would have to be careful even on an automated site – I'm assuming you're talking about some kind of search-like crawler that finds MUDs and pings them, without admins registering them?

I don't know what to say, I don't think we can even start fixing this unless there is some kind of centralized, "official" authentication repository somewhere. I don't view that as a terribly plausible proposition.

However I still don't think it's a huge problem, because presumably the admins of the main listing sites will keep an eye on this or at least be responsive to complaints, as they already are with manually registered games.
23 Mar, 2009, KaVir wrote in the 165th comment:
Votes: 0
On TMC I have already registered an account, and included my mud details. TMC might decide to use MSSP to check the IP address I've listed, and verify the data retrieved from that mud against the name and address I've supplied them - then if those match, update the other details.

Creating another account on TMC is against their rules, but let's say I do it anyway. I create another listing - but I can't pick the same name as you, as TMC won't let me. So then I have to just pick a similar name. You'd spot it pretty fast, report it to Icculus, and he'd remove the fake listing and most likely the account. If he could trace it to my real account, I might lose my real account (and mud listing) as well.

It would only become a problem for sites which don't require you to create an account, where the entire process is automated without human administration.
23 Mar, 2009, David Haley wrote in the 166th comment:
Votes: 0
OK, but how is this a protocol problem? This is a social problem. How could we possibly fix this at the protocol level? Supplying the name/address doesn't really do much. I can still create Good Wars II or Legends of the Drakstone and you wouldn't know the difference.
23 Mar, 2009, Scandum wrote in the 167th comment:
Votes: 0
The purpose of the host, port, ip value is that they can be used to point the crawler to the new address.

If you have to move in a hurry in an hours notice you're screwed, but if you can leave the old mud up for a week (perhaps even 24 hours) to give crawlers your new host, port, and ip it should make for a flawless transition.

This also solves the fake address thing, a mud can point to aardwolf, which would just get the crawler to switch to crawling aardwolf creating two duplicate entries for aardwolf.

A smart crawler would automatically remove the newest duplicate or alert the sysop.
23 Mar, 2009, David Haley wrote in the 168th comment:
Votes: 0
No, that doesn't solve the spoofing thing, please read again.
23 Mar, 2009, Scandum wrote in the 169th comment:
Votes: 0
David Haley said:
No, that doesn't solve the spoofing thing, please read again.

It does for Crat's example, Mister read again.
23 Mar, 2009, David Haley wrote in the 170th comment:
Votes: 0
I'm sorry, no, it really doesn't……
23 Mar, 2009, David Haley wrote in the 171st comment:
Votes: 0
to elaborate in the interest of expediency: he's not talking about setting it to the same name/address, but something deceptively similar.

In fact, your proposal of removing duplicates keeping only the most recent one is potentially even worse, because then somebody could actually kick off the good MUD by using the same name…
23 Mar, 2009, KaVir wrote in the 172nd comment:
Votes: 0
David Haley said:
OK, but how is this a protocol problem?

It isn't. As I said earlier, "that's the problem of that particular site".

David Haley said:
Supplying the name/address doesn't really do much.

Supplying the name is necessary if the entire process is automated.
23 Mar, 2009, David Haley wrote in the 173rd comment:
Votes: 0
I was referring to this:
Quote
TMC might decide to use MSSP to check the IP address I've listed, and verify the data retrieved from that mud against the name and address I've supplied them - then if those match, update the other details.


Anyhow, if it's not a protocol problem, it's not really worth further discussion except to note it as a caveat somewhere, right?
23 Mar, 2009, KaVir wrote in the 174th comment:
Votes: 0
David Haley said:
I was referring to this:

I don't see it being any problem at all (protocol or otherwise) for TMC, or indeed any other sites that have both human administration and user accounts. It's only the fully automated sites (which TMC certainly isn't) that I think could run into problems.
23 Mar, 2009, Scandum wrote in the 175th comment:
Votes: 0
David Haley said:
to elaborate in the interest of expediency: he's not talking about setting it to the same name/address, but something deceptively similar.

That's what he said, a mud creating an entry with a duplicate name that points to aardwolf. The crawler would find the aardwolf host, notice the update, recrawl the aardwolf address, and end up using all of aardwolf's MSSP data. Then it should notice there are two duplicate entries.

David Haley said:
In fact, your proposal of removing duplicates keeping only the most recent one is potentially even worse, because then somebody could actually kick off the good MUD by using the same name…

What I said was to remove the newest duplicate, so the original entry would stay. Thinking about it MSSP is pretty fool proof.
23 Mar, 2009, David Haley wrote in the 176th comment:
Votes: 0
Just to be clear, are you talking about "run[ning] into problems" due to a flaw in the protocol, or the social problem we talked about?
23 Mar, 2009, KaVir wrote in the 177th comment:
Votes: 0
David Haley said:
Just to be clear, are you talking about "run[ning] into problems" due to a flaw in the protocol, or the social problem we talked about?

The social problem. I don't believe it's something the protocol can realistically address. In my opinion it should be left up to the individual sites to deal with fake and misleading listings - whether this is through user accounts and human administration (such as TMC), or some other means.
23 Mar, 2009, David Haley wrote in the 178th comment:
Votes: 0
Yes, I agree that it's a problem for the listing sites, not the protocol.
24 Mar, 2009, Cratylus wrote in the 179th comment:
Votes: 0
Ok, so it sounds like we're pretty firmly on the side of "basically, it would be used
by traditional-type listing sites". No MSSP peering. One mud, one query, one data set.

That's worth establishing explicitly, thanks for the input.

-Crat
http://lpmuds.net
24 Mar, 2009, David Haley wrote in the 180th comment:
Votes: 0
Well, I'm not against peer listing in general, I just haven't seen a use case for it yet. But if we do allow peer listing, then we run into trust issues at a protocol level more than without peer listing.
160.0/292