04 Apr, 2011, Runter wrote in the 201st comment:
Votes: 0
I think the answer to the problem is very simple. Allow multiplaying from the same user.
04 Apr, 2011, quixadhal wrote in the 202nd comment:
Votes: 0
The only way to be semi-secure in that respect is to force incoming users to register and, as part of that process, you send them a unique login ID which they have to use. IE: an account system where they don't get to pick the username.

Now, on your end, you tie all their characters to the account, and if their account gets banned, they have no way to connect without applying for a new account. Assuming you require some kind of communication with them first, you would be able to recognize the same person trying to sneak back in.

As Crat said though, that's not likely to work well unless your MUD is already *VERY* popular, or unless you have some kind of trial system where they can get hooked enough to be willing to undergo such a process. Most people just won't bother and will move on to the next game instead.
04 Apr, 2011, sankoachaea wrote in the 203rd comment:
Votes: 0
Achaea, for example, already implements an internal account system (independent of IP-addresses)

It doesn't matter if you're on the same line or coming from different IPs, if more than one character registered to the same e-mail accounts are playing at one time, the server identifies them as multiplaying…

As far as Aspect is concerned, how can it provide a solution that fits every MUD? On many servers, multiplaying isn't even against the rules.
04 Apr, 2011, Twisol wrote in the 204th comment:
Votes: 0
Cratylus said:
What I think Quix is saying is that in terms of being sure about the trustworthiness of IP information is that
if you get an inbound connection from a specific IP and then forward it to some target, the assurance that
the IP is really the right IP is no more or less compromised than your ability to keep your own proxying
server from lying. It's garbage in garbage out.

It's no different from a MUD server trusting the player, so that at least isn't an Aspect-specific problem. If an untrustworthy player spoofs their IP, it doesn't matter whether they connect through Aspect or straight to the MUD: the MUD still gets the same (wrong) data.

Cratylus said:
I do not want to seem like a naysayer or whatever, but I think that relying on human intensive methods
(registration, connection monitoring) to sanitize your proxy is a non-starter right from the get go.

I don't want to do anything more than remove the IP shadowing issue that Aspect as a proxy causes. I'm sure, as I build more advanced features into Aspect, user registration will make sense, and maybe those details could be sent along with the IP. As someone else said though, that just pushes the issue up one level. I'm not here to solve every problem.

Cratylus said:
The system Quix suggests is one example of a step in that right direction, but I'm not sure it's
all that applicable in your case, as it relies on telopts/subneg and the muds you presumably will
service may not all want to recode their networking for you.

Right, that was my first idea back when I started thinking about this, but I want to discuss it with some of the more popular MUDs to see what's feasible to get off the ground.

Cratylus said:
What they might be willing to do is recode their login handler, such that they trust your (Twisol's)
IP address to provide them login information of this sort:

<ip address><special string><new player's name>

e.g.: 1.2.3.4@joebob

The mud can strip out the header and parse it, and thereby know that the incoming connection
from your trusted proxy originated from 1.2.3.4 which actually belongs to some chump we've been
trying to ban for months but he keeps finding proxies to evade our countermeasures. It can then
reject the connection.

Alternately if that's a safe IP, it can allow it to continue as if joebob had connected directly.

That's a fantastic idea. I'm not a huge fan of limiting the number of IPs I can connect out of (much less limiting me to specific IPs), so there would need to be some way around that…

Cratylus said:
If you don't allow your end user mud targets to control access on their own, you're going to have
a tough time because you will need to demonstrate why they should trust you to handle their
access controls as diligently as they would themselves.

I think there might have been a miscommunication here. I have never intended to enforce multiplaying access rules directly within Aspect. The problem is that proxies shadow the incoming IP with their own, reducing a MUD's own ability to enforce multiplaying rules. I want to fix that by passing the user's IP on to the MUD, so they can continue enforcing their own rules.
04 Apr, 2011, Twisol wrote in the 205th comment:
Votes: 0
Stendec said:
Huh, neat. More conversation with DecafMUD mentioned. ^^

Hiya Stendec! :smile:

Stendec said:
someone finally talked me into playing Minecraft. (That game devours lives.)

Sssssssssss…. BOOM. :ghostface:

Stendec said:
Now, Twisol, you say that Aspect is meant to live in one place. Really, that isn't hard to do with DecafMUD. Like my demo page does, all you really need to do is host a proxy server for connections, which you'd need to do anyways, as the only real way to create a socket in a browser without all sorts of security stuff is Java (or perhaps Silverlight? But definitely a browser plugin). By setting up the page that hosts the DecafMUD instance differently, it would be easy to customize it for different MUDs. So far as the IP shadowing problem goes, my current proxy code doesn't support that, but it'd be rather trivial to implement if there was a standard way to send those IPs to the end server.

Right, I realized how DecafMUD works after I tried it last night. DecafMUD is probably the closest thing to Aspect there is right now, but of course you're way ahead of me.

Stendec said:
As for the 'Gawd is the rendering slow though.' comment… well, I suppose it might be. But I suspect it's just the network latency making it slow. I'm hosting that from my home connection, because I'm silly, and I have a pretty horrible ISP. The client's code, discounting network latency, is able to chunk through (on my admittedly fast PC) 437,728 bytes of ANSI-littered data in roughly 140ms. The performance links on http://decafmud.kicks-ass.net/demos.html eliminate latency as a variable from the testing. They work by loading a file from the server completely before timing how fast it takes to push that file through DecafMUD's socketData function, essentially tricking Decaf into thinking the data came from its socket handler.

I meant no offense by that statement! :redface: It just surprised me a lot, and I thought I saw individual characters being pushed into the output buffer. Running it from your home computer… would definitely do it. Thanks for the clarification!

Stendec said:
Feel free to use the display code if you'd like though. Even though it isn't fully VT-ish (cursor movement commands will be the death of me), I'm pretty happy with how it works.

Great, thanks. As for cursor movement commands… I know what you mean. XD I'm considering building a Canvas-based output buffer so I can implement those, but it's not a mega-huge priority.

Stendec said:
All this said, I wish you luck with your project.

I appreciate it!
04 Apr, 2011, Stendec wrote in the 206th comment:
Votes: 0
Twisol said:
Sssssssssss…. BOOM. :ghostface:

Nooooooooooo!! My stuff!

Twisol said:
I meant no offense by that statement! :redface: It just surprised me a lot, and I thought I saw individual characters being pushed into the output buffer. Running it from your home computer… would definitely do it. Thanks for the clarification!

No offense was taken, I assure you. Just wanted to ensure people aren't misunderstanding Decaf's performance because of my horrible connection. (Or another thing that only comes up with people who don't have their OS language as English, which I need to fix up. Probably by making an event that fires when language is changed, so UI can change strings.)

Twisol said:
Great, thanks. As for cursor movement commands… I know what you mean. XD I'm considering building a Canvas-based output buffer so I can implement those, but it's not a mega-huge priority.

I've got half of a canvas-based display plugin for DecafMUD written somewhere, actually. It works great, except for scrollback. You basically have to redraw the entire display every time the output scrolls, and keep the previous output that's scrolled away somewhere else. It's very possible though. Hmm, maybe I should finish it and show the code.
04 Apr, 2011, Runter wrote in the 207th comment:
Votes: 0
sankoachaea said:
Achaea, for example, already implements an internal account system (independent of IP-addresses)

It doesn't matter if you're on the same line or coming from different IPs, if more than one character registered to the same e-mail accounts are playing at one time, the server identifies them as multiplaying…

As far as Aspect is concerned, how can it provide a solution that fits every MUD? On many servers, multiplaying isn't even against the rules.


What deters someone from making two accounts to multiplay?
04 Apr, 2011, Twisol wrote in the 208th comment:
Votes: 0
Stendec said:
Twisol said:
Great, thanks. As for cursor movement commands… I know what you mean. XD I'm considering building a Canvas-based output buffer so I can implement those, but it's not a mega-huge priority.

I've got half of a canvas-based display plugin for DecafMUD written somewhere, actually. It works great, except for scrollback. You basically have to redraw the entire display every time the output scrolls, and keep the previous output that's scrolled away somewhere else. It's very possible though. Hmm, maybe I should finish it and show the code.

Hmm, yeah. What about SVG? There's an interesting library called Raphal that I've been eying.
04 Apr, 2011, Twisol wrote in the 209th comment:
Votes: 0
Runter said:
What deters someone from making two accounts to multiplay?

It's a bit like the NYT's "paywall". It's just good enough to deter casual players and keep the problem to a minimum.
04 Apr, 2011, sankoachaea wrote in the 210th comment:
Votes: 0
Runter said:
What deters someone from making two accounts to multiplay?

A number of things, all orthogonal to the point. This isn't a discussion of how effective Achaea's account system is –> MUDs are going to (and should) manage restriction of multi-playing regardless of the client used to play them. Twisol, and by extension, Aspect, shouldn't be overly-encumbered with a task already handled by the game.
04 Apr, 2011, Runter wrote in the 211th comment:
Votes: 0
sankoachaea said:
Runter said:
What deters someone from making two accounts to multiplay?

A number of things, all orthogonal to the point. This isn't a discussion of how effective Achaea's account system is –> MUDs are going to (and should) manage restriction of multi-playing regardless of the client used to play them. Twisol, and by extension, Aspect, shouldn't be overly-encumbered with a task already handled by the game.


Thanks for answering the question I asked.
04 Apr, 2011, David Haley wrote in the 212th comment:
Votes: 0
If using accounts is being given as some kind of solution to stopping multiplaying, and there is no solution to the problem of registering multiple accounts, then nothing has been solved…
04 Apr, 2011, sankoachaea wrote in the 213th comment:
Votes: 0
Runter said:
sankoachaea said:
Runter said:
What deters someone from making two accounts to multiplay?

A number of things, all orthogonal to the point. This isn't a discussion of how effective Achaea's account system is –> MUDs are going to (and should) manage restriction of multi-playing regardless of the client used to play them. Twisol, and by extension, Aspect, shouldn't be overly-encumbered with a task already handled by the game.


Thanks for answering the question I asked.


It's not my job to provide answers to any random question you ask, especially when #1. you could find the answer on your own and #2. it isn't relevant to the topic. Forgive me if I don't fake appreciation for laziness and sarcasm. When I open up Ask-Sankoachaea.com, I'll be sure to log this under feedback.

Edit: Yes, David, I'm not denying there is a problem with that situation… but again.. is it the responsibility of the client to make up for whatever security features the MUD is lacking? AGAIN: This isn't a discussion of how effective Achaea's account system is: we're trying to determine what Aspect (or other browser-based clients) need to pass along and how.
04 Apr, 2011, Runter wrote in the 214th comment:
Votes: 0
You refer to Achaea as some type of success story and give no details about their system, and now you act indignant when someone wants to know how it works?

Here's your answer to my question of "what deters someone from registering multiple accounts?" : "A lot of things."

If you don't want to have thoughtful discussion on topics then don't bring them up. Or maybe just decline to respond instead of hand waving things away.
04 Apr, 2011, Stendec wrote in the 215th comment:
Votes: 0
Twisol said:
Hmm, yeah. What about SVG? There's an interesting library called Raphal that I've been eying.

I haven't really done anything with SVG, though I don't see why it couldn't work. Not sure how the performance would be vs canvas. With canvas, it's just a… well, canvas that you paint on. Changing a letter in a given area is as simple as painting a new one there. With SVG, you'd have to find the text node that fills the spot (maybe a rectangular node too for the bg color, depending on how it's set up?) and remove it before placing a new one. Which sort of feels like not much better than just raw HTML. Of course, SVG has the benefit over canvas that you could actually resize it without triggering a redraw.

Not that re-drawing is THAT painful. You just need to keep y-number rows of text stored in memory, and a big huge array of color data and ANSI flags so characters are redrawn properly. And having that data makes it easy to pop rows out and put them in a more traditional buffer when they scroll off the screen. On a slightly different note, I bet SVG would be a lot better than canvas for implementing MXP.
04 Apr, 2011, sankoachaea wrote in the 216th comment:
Votes: 0
Runter said:
You refer to Achaea as some type of success story and give no details about their system, and now you act indignant when someone wants to know how it works?

If you don't want to have thoughtful discussion on topics then don't bring them up.

No. I didn't refer to them as a success story, nor did I bring Achaea up as an example of effective ways to stop multiplaying.

I mentioned Achaea's account system as a supporting detail to a more significant/relevant point, i.e. it will be difficult for Aspect (or any browser-based/proxy client) to provide a one-size-fits-all solution to multi-playing when policies and mechanisms-for-enforcement-of-policy differ widely from MUD to MUD. If you don't want to actually read what I'm writing or have thoughtful discussions about the actual topic or content of my posts, then please feel free to never again waste my time with your pointless, ungrounded accusations of dismissive hand-waving.

Back on topic, Aspect should have some way of providing client IPs (meaning player connected to Aspect) to the MUD for MUDs that do use IPs for security, however, this is probably going to require some work/cooperation with MUD admins. Shoot, some MUDs disallow multiple connections from the same IP period. That kind of knocks Aspect out right off the bat.
04 Apr, 2011, Orrin wrote in the 217th comment:
Votes: 0
I use a proxy on MudGamers and I've had maybe one or two games query the ip issue as a problem. They do have the option to host their own flash policy file and then the client can connect directly to their mud without using the proxy.
04 Apr, 2011, Twisol wrote in the 218th comment:
Votes: 0
sankoachaea said:
Back on topic, Aspect should have some way of providing client IPs (meaning player connected to Aspect) to the MUD for MUDs that do use IPs for security, however, this is probably going to require some work/cooperation with MUD admins. Shoot, some MUDs disallow multiple connections from the same IP period. That kind of knocks Aspect out right off the bat.

Thank you for succinctly describing the situation. :tongue: I'm still planning on going the "green with envy" route, by getting some of the more popular MUDs on-board. Then maybe I'll actually have some weight behind me.
04 Apr, 2011, sankoachaea wrote in the 219th comment:
Votes: 0
Probably not a bad idea. I think, once people see what you can do with Aspect, there will be some push to get MUDs working with it.

I thought Aspect would maintain some type of account system anyway, for managing/saving player settings..


Edit: Oh, you're welcome, though it was mostly for Runter's benefit.
04 Apr, 2011, Twisol wrote in the 220th comment:
Votes: 0
sankoachaea said:
I thought Aspect would maintain some type of account system anyway, for managing/saving player settings..

That's right. As we've discussed, though, it's probably not going to be a great boon for monitoring multiplaying.
200.0/275