24 Sep, 2010, Davion wrote in the 1st comment:
Votes: 0
Tyche said:
There's a filter on IMC2 that munges links to http://lpmuds.net.
Making links to http://lpmuds.net on IMC2 is strictly forbidden and against the rulez.


It's not against the IMC rules to post links to lpmuds.net in any way. The filter isn't on IMC2 either. It's on MegaBot, and it was to remove the hurt porn Cratylus likes to share ;)
Tyche said:
You probably want to carefully consider implementing IMC2.
It like a mud of muds, run like a really bad mush. Where some super mush admin monitors and munges your
communications between other muds, and holds you responsible for the communications of anyone using it on
your mud. Most people are fine when they figure out the power structure of this super mush (i.e. which asses
to kiss).


I agree. The way it works is retarded for the way a system like this should work. Considering how IRC is its inspiration, it certainly failed and upholding the way IRC is managed. Damn software limitations :(
24 Sep, 2010, Rudha wrote in the 2nd comment:
Votes: 0
I can't say I'm terribly enthused about how that kind of thing is arbitrary and unspoken.

Davion said:
I agree. The way it works is retarded for the way a system like this should work. Considering how IRC is its inspiration, it certainly failed and upholding the way IRC is managed. Damn software limitations :(


There is absolutely nothing stopping anyone from decentralising IMC2 save laziness; the real question is if someone did that (I wouldn't be adverse to giving it a hack in my free time), it would be meaningless unless it was adopted.

Maya/Rudha
24 Sep, 2010, Scandum wrote in the 3rd comment:
Votes: 0
Still an option to use MSDP to create an Intermud service.
24 Sep, 2010, Rudha wrote in the 4th comment:
Votes: 0
Scandum said:
Still an option to use MSDP to create an Intermud service.


I see what you did there.

Still, I don't see why that couldn't work. I'll sleep on it and see what I think up when its not nearly midnight when I got up at 2am last morning.

Maya/Rudha
24 Sep, 2010, David Haley wrote in the 5th comment:
Votes: 0
What's needed isn't really another protocol; it's just the sane and predictable management of an existing network.
25 Sep, 2010, Scandum wrote in the 6th comment:
Votes: 0
Nah, MSDP baby!
25 Sep, 2010, Rudha wrote in the 7th comment:
Votes: 0
David Haley said:
What's needed isn't really another protocol; it's just the sane and predictable management of an existing network.


Decentralisation would however be a good idea, for the kinds of reasons the Cratylus has mentioned; that helps mitigate things when there's personality conflicts with admins, such as the ne that seems to have been highlighted within this very thread :)

Maya/Rudha
25 Sep, 2010, Kline wrote in the 8th comment:
Votes: 0
I'd like to see things evolve into a Freenet style network; where each node is an independent router and you only need seed your node with known friends (or a master seed router, for first-time users) to discover the rest of the network.
25 Sep, 2010, Mudder wrote in the 9th comment:
Votes: 0
I learned long ago not to click on Cratylus' links unless someone else has declared it safe. :cool:
25 Sep, 2010, Rudha wrote in the 10th comment:
Votes: 0
Kline said:
I'd like to see things evolve into a Freenet style network; where each node is an independent router and you only need seed your node with known friends (or a master seed router, for first-time users) to discover the rest of the network.


That's pretty much what I would like too; I don't think this is impossible to implement with the established protocol, though I would probably prefer using the server's RSH fingerprint to identify it rather than a username/password combination.

Maya/Rudha
26 Sep, 2010, Cratylus wrote in the 11th comment:
Votes: 0
Kline said:
I'd like to see things evolve into a Freenet style network; where each node is an independent router and you only need seed your node with known friends (or a master seed router, for first-time users) to discover the rest of the network.


I'm unfamiliar with this thing. Tell more.

How does communication work exactly in this scheme? Is each mud a peer? How do you
deal with someone who uses the n-word in every chat? Who handles that person, if
handling is done? Please elaborate on how this thing actually works.

-Crat
http://lpmuds.net
26 Sep, 2010, Kline wrote in the 12th comment:
Votes: 0
Cratylus said:
I'm unfamiliar with this thing. Tell more.

How does communication work exactly in this scheme? Is each mud a peer? How do you
deal with someone who uses the n-word in every chat? Who handles that person, if
handling is done? Please elaborate on how this thing actually works.

-Crat
http://lpmuds.net


Freenet Project. Every node is a router, you only directly connect to other nodes who you explicitly trust (as you manually add them). After that all your links through the network are discovered via your directly connected nodes, which searches their directly connected nodes, etc etc. There are a handful of semi-permanent "seed" nodes for new users to blindly connect to if they don't already have any known nodes to add to their own. This way they can still use the network (albeit more slow and insecurely) without having pre-existing friends that are part of the network.

In how to solve the problem you presented, since each node is a router, it shouldn't be too hard for each person who doesn't want to see that to explicitly block the person/game of origin on their own node. Place censorship in the hands of each game owner as to what they allow their game to receive. If someone truly becomes malicious with repeated spam/flood/attacks then I'd think the friends they are directly connected to would either disconnect them or someone further upstream of those two would. Eventually you'd be left with a spammer and his friends in their own isolated network after everyone un-peered from them; and they could be blocked at the seed nodes to prevent further re-joining.
26 Sep, 2010, Rudha wrote in the 13th comment:
Votes: 0
The existing authentication would probably have to be reworked for something like freenet, but that would be the best way to work it, I think. The current authentication has a password-based client/server setup that would need looked at; at the very least we'd probably need to drop the passwords.

Maya/Rudha
26 Sep, 2010, quixadhal wrote in the 14th comment:
Votes: 0
In such a peer oriented network, I'd suggest each MUD connected, and each user ON each mud, have a public keypair generated for them. Use the public key of each as authentication.

That way, if the mud in question uses user accounts with multiple characters, the intermud identity becomes the user, not the character. At least as far as the mud controls how people create accounts.

If I want to block all traffic from PornMUD, I can ban any packets coming from their public key and not care if they change their name to PedoMUD later. Yes, they could generate a new key pair, but unless you require people to manually sign up for access, that's the way the cookie crumbles.

If I want to just block Fapper@BambiMUD, I can block his public key and maybe also end up blocking Fapper2 and FapFap at the same place without having to also ban PizzaGuy.

The only caveat would be that the MUD that bans these guys should probably continue to forward their traffic on to other peers. It's not a deal breaker, because PronMUD can just try to find other peers to work around it, but it would mean if you had a line of peers, the one at the head of the line would have more power than the one at the back. Again though, the guy in the middle can always try to find another peer to get around the victorian morality of his two neighbors.
26 Sep, 2010, David Haley wrote in the 15th comment:
Votes: 0
This is a lot of technical talk to solve which technical problem exactly? Public keys and peering models and all this stuff sounds like an engineer gone wild on a social problem. :thinking:
26 Sep, 2010, Ludwig wrote in the 16th comment:
Votes: 0
I think the technical problem is how to best to ignore unwanted messages. I don't know the answer and I don't really care.

What I do care about is connecting to as many muds as possible through imc2 or i3. Are the mudbytes and lpmuds imc2 servers mutually exclusive?
26 Sep, 2010, Runter wrote in the 17th comment:
Votes: 0
Yes. This sounds like too much complexity to provide a service as simple as a chat server. I'd rather err on the side of no logins. Besides, its not all rainbows when you're essentially suggesting a fractured chatwork by nature. If you want to sample the ensuing chaos simply have half your users randomly gag the other half. Conversations quickly become confusing. Furthermore, some people will only connect to a network which at least says there will be some decorum.

So as a proud member of Team Haley ill submit again. What a majority of people want is just sane and consistent administration.
26 Sep, 2010, Rudha wrote in the 18th comment:
Votes: 0
Runter said:
Yes. This sounds like too much complexity to provide a service as simple as a chat server. I'd rather err on the side of no logins. Besides, its not all rainbows when you're essentially suggesting a fractured chatwork by nature. If you want to sample the ensuing chaos simply have half your users randomly gag the other half. Conversations quickly become confusing. Furthermore, some people will only connect to a network which at least says there will be some decorum.


IRC has worked quite well, but by the way you're describing that kind of network, you seem to suggest that it should have gone the way of the dinosaur a while ago.

Quote
I think the technical problem is how to best to ignore unwanted messages. I don't know the answer and I don't really care.

What I do care about is connecting to as many muds as possible through imc2 or i3.


What quantity of signal is great and all, some of us prefer a high signal-to-noise ratio.

Maya/Rudha
26 Sep, 2010, David Haley wrote in the 19th comment:
Votes: 0
Ludwig said:
What I do care about is connecting to as many muds as possible through imc2 or i3. Are the mudbytes and lpmuds imc2 servers mutually exclusive?

They're not mutually exclusive but the LPMuds network is a strict superset. LPMuds imc2 gives you access to the LPMuds i3 network via a protocol bridge, and one node of the network is a bridge to the MB imc2 network.

Rudha said:
What quantity of signal is great and all, some of us prefer a high signal-to-noise ratio.

Do you have reason to believe that lpmuds intermud has a poor signal-to-noise ratio and that some kind of massively-peered network model (massively multi-MUD peered network – MMMPN? :wink:) would fix it?

I don't understand what the advantage of the peer model is when it comes to filtering out noise. If you don't like some user or even a whole MUD, just block it on your MUD. If they're doing something utterly stupid and shouldn't be on the network in the first place, just let the admin(s) of the routers know and they can put in a network-level ban. The peer model doesn't add the ability to ignore MUDs.

In fact, as Runter said, if you can't enforce network decorum at the network level, won't that discourage some people from joining in the first place? At least if you have enforced network level policies of acceptable speech on various channels, you can have some confidence that given channels won't have people running amok.

Do you have an example of a scenario where you need to improve your signal-to-noise ratio but only the peering example lets you do so? I'm genuinely curious about this. As far as I can tell the only advantage of the peering model is that you are protected from the social problem of the possibility of a router admin going crazy and banning users or MUDs for no real reason. This is not an unimportant advantage in some circumstances, but if you have a sane, reasonable and predictable admin process the need for such protection is alleviated.
26 Sep, 2010, Rudha wrote in the 20th comment:
Votes: 0
David Haley said:
I don't understand what the advantage of the peer model is when it comes to filtering out noise. If you don't like some user or even a whole MUD, just block it on your MUD. If they're doing something utterly stupid and shouldn't be on the network in the first place, just let the admin(s) of the routers know and they can put in a network-level ban. The peer model doesn't add the ability to ignore MUDs.

In fact, as Runter said, if you can't enforce network decorum at the network level, won't that discourage some people from joining in the first place? At least if you have enforced network level policies of acceptable speech on various channels, you can have some confidence that given channels won't have people running amok.

Do you have an example of a scenario where you need to improve your signal-to-noise ratio but only the peering example lets you do so? I'm genuinely curious about this. As far as I can tell the only advantage of the peering model is that you are protected from the social problem of the possibility of a router admin going crazy and banning users or MUDs for no real reason. This is not an unimportant advantage in some circumstances, but if you have a sane, reasonable and predictable admin process the need for such protection is alleviated.


When you have a single MUD that you're getting a lot of noise through, then dropping that connection allows you to not even have to worry about suppressing that input; which, while valuable for the purpose of ignoring people whom annoy you, can also be an important network integrity point as well: if you have a compromised server, or perhaps simply a malfunctioning one that is sending copious data, or data that is in some way damaging or disruptive, the ability to drop that connection helps protect the individual members on the network; as far as I understand it, you can't really do that with the current system - you have to choose to discard each message individually and cannot separate yourself from that node.

I'm kind of just spinning my wheels at this point though, I think. Perhaps somewheres along the line I'll do my own implementation for some self-validation, but it's not that big a deal to me.

Maya/Rudha
0.0/48