Coding

@Clarion Good idea. I will implement this.

@Hella Fixed.

I am working on a newer generation of Open Source MUSH, featuring the kind of more modern features like you see in AresMUSH and the like, while having a best-effort compatibility layer for PennMUSH code - with things like syntax highlighting, a web portal, etc added.

This is a good ways out still, but in order to prioritize the work I am doing and making sure I produce a product people actually want, I have created a simple set of surveys:

One for players: Player Survey
One for Wizards / MUSH Coders: Wizard Survey

I would love your help on this!

For more details, check out the Documentation Page, the GitHub Code page, or our Discord:

• Documentation
• GitHub
• Discord

Sort of yes? I've been toying with using the Storypath Ultra system to do a WoD-style game. I'm a big fan of the system and think it could be a good way to give a fresh coat of paint on things while keeping it familiar and comfortable.

I am currently working on a completely from scratch refactoring, redesign, and streamlining of my popular Penn/Rhost Code.

Warning, it's NOT ready to install yet.

And, at the same time, I've fixed pretty much every issue with 3.x's Rhost compatibility, and am working on finalizing a new release of for 3.5 which should be the last major bit of work I do involving that older code. I've abandoned maintaining the Storyteller stuff for 3.5 because 4.0 is already blowing it out of the water.

Here's my main goals for 4.0's version of the Codesuite:

• Rhost-only. Rhost, at the moment, has left Penn so far behind that I don't see any pros left to working with Penn. Sticking to just Rhost has lead to far simpler code, and being able to count on 32kb buffers instead of 8kb makes many things now possible.
• Account-based logins using Rhost's new login system. login to an account, select a character to play.
• Simple, streamlined, idiomatic coding style with fewer idiosyncracies. The code is much cleaner and more readable. I want to keep it that way. Easy to read, easy to maintain and modify.
• Less is more. Although the new code has trimmed out some extraneous features (like Divisions in factions), being simpler has enabled more flexibility in other ways.
• Minimal SQL involvement. Only roleplay logging and a few very similarly heavy topics require SQL. The BBS, Ticket Tracker, Storyteller data, etc, does not need SQL.
• Simple setup, largely unobtrusive installation that can get along with other code packages, if any.
• Full integration and accounting for some of Rhost's more peculiar and interesting features, like Reality Levels.
• Idiomatic handling of Rhost's security for new security model that covers collaborative building.
• Support for Storyteller games: Exalted 2e, Exalted 3e, Chronicles of Darkness 2e, World of Darkness 20th Anniversary, and perhaps some fan stuff. (Exalted vs WoD? Exalted x Chronicles of Darkness? Exalted Demake?). Maybe Scion 2e?
• (Highly experimental) MUD-style game SDK building on it. I want to see if Rhost can be used to make a spiritual successor to a Dragon Ball MUD I maintain and if I can generalize its features into a MUD SDK, I definitely will.

@Juniper Heh. Though just for the record (in case it wasn't clear by the nitpicky arguing) Ghost and I agree on the core technical risks:

1. Anything sent between your computer and an insecure endpoint is susceptible to being snooped by a third party. This includes both http(without-the-s) websites and virtually all MU* client connections.

2. Anything you send to another MU player can be snooped by a third party if THE OTHER PLAYER is using an insecure connection.

3. Anything you transmit to ANY internet service is potentially visible to and exploitable by the service owner, anyone they choose to share it with, and anyone who compromises THEIR security.

Since #2 and #3 are still risks on a MUSH even if you connect securely, I don't personally lose sleep over #1. But I do think it's prudent to follow general precautions no matter how you connect:

• Avoid sharing sensitive information with other players, and if you do - it's safer on discord or via email than on a game.
• If you're on a dodgy public network (like a coffee shop) or have a dodgy partner/roommate, use a VPN.
• Follow general internet safety practices on your PC to protect it from vulnerabilities (e.g., use firewall/virus software, be very careful with email links/attachments, etc.)
• Be extra cautious/suspicious of sites that have insecure connections, and never trust them for anything truly important (ecommerce, banking, email, etc.)

With those general precautions in place, I'm perfectly comfortable connecting to my favorite MU via Atlantis/Beip/etc. YMMV.

@Ghost said in Telnet Safety:

I don't mean for my tone to come across as accusatory as it did. I'll keep an eye on that, especially with you since you're awfully nice.

Thanks - I think we were largely just talking past each other. All good.

@Ghost said in Telnet Safety:

Whatever next state the hobby takes will probably include someone either improving the insecure transmission issue through some new client/interface to cover that problem, or improvements to client/web interfaces using TLS to allow for more of the customization that MuClients provide.

That would be nice, but moving away from the old MU clients - even if you could pry old unsupported ones out of peoples' fingers - presents a whole other set of hurdles. Probably for a different thread, tho.

@Ghost I feel like we're arguing in circles and you're saying that I'm dismissing concerns that I'm not dismissing.

I am simply saying that many of those things you're worried about (honeypot MUs run by malicious actors, scraping IPs, social engineering, data within the game being compromised/spied on) are just as much a concern if you're using a secure connection as if you're using an insecure one. That is supporting your call for vigilance, not undermining it.

I just do not agree that you can compromise a MUClient connection in the way you seem to be describing. MUs do not use telnet/23, they use a simple, custom TCP protocol. It's a dumb-as-nails text connection that sends text to the game and displays text back from the game. The primary vulnerability is simply being able to snoop and/or manipulate the text sent back and forth. Which is a point I've agreed with from post 1. If there is some other technical exploit I'm missing here, I would genuinely love to know (even if it's by DM if you don't want to advertise it). But nothing you've said so far has convinced me that there is.

Tangentially, for the record, each Ares game has to set up its own security cert.

@Ghost said in Telnet Safety:

AN EASY SCENARIO THAT IS 100% POSSIBLE AND REQUIRES NO TALENT TO PULL OFF

Absolutely everything in your nightmare scenario can be done if the game is running SSH/HTTPS. You're blaming the technology for a people problem.

@Ghost said in Telnet Safety:

I've said it before and I'll say it again:

And I've said it before and will say it again:

@faraday said in Telnet Safety:

I don't disagree with your fundamental message to be careful what you share online. That's good advice no matter what, and I echo it in the Ares data privacy guides.