Starting out life as a simple MSN 7 server developed by one single person, Escargot is now a network supporting its own features and implementations of other networks, old and new, that is being contributed to by volunteers. These networks and features are called "frontends", which rely on a generic server backend that allows for any user registered on Escargot and their preferences (contacts, personal network settings, display name/status message, etc.) to seamlessly integrate with them, along with the ability for the frontends to talk to each other with little to no caveats. Each frontend is simply another way to use and connect to our federated chat-o-sphere, and this gives you the ability to use any frontend you want while still having the same account preferences.

Escargot is all about standardizing messaging so that everyone has a slice of their messenger cake while not being walled by one network to use another separate network to talk to their contacts. You can, say, use our MSN frontend to talk to users that use, say, our Yahoo! frontend, and many more, all without having to register on the frontend they're on. Everyone can compromise now, and all it takes is a single account! No more bookkeeping of IM accounts for each network you're on. :)

One thing we have to stress very importantly is that Escargot is experimental, meaning there might be bugs in the frontends or the federation between them. We plan to tackle these from time to time, but there's no guarantee that they're 100% resolvable. This shouldn't take away from your experience, though, and in the future Escargot should be at a stable state.

No. Alongside the IMs of old (and/or ones that are simply dead), we also plan to support currently active networks and protocols (e.g., XMPP, IRC, etc.), giving people who aren't interested in the classic frontends we offer a chance to use our federated chat-o-sphere while being up-to-date in the messaging platforms they use. We also plan to support protocols that are federated (and open-source) in nature, like Matrix, for one.

Development is sporadic, and our team as of current is very small and we barely have time to do any sort of major stuff right now. However, other frontends (IRC, AIM, XMPP) might be coming soon. Some even have functional proof-of-concepts.

The server is completely open source and contributions are welcome would be greatly appreciated. Be sure to check out the master branch for the newest code, with the stable code being used in production servers hosted on the live branch.

Just to stress this clearly, no we are not related to nor necessarily condone the actions originating from MessengerGeek, both the blog and the forum, nor is the person behind either involved in any of our activity. It had just happened to allow us to start off with an already populated community and grow from there. These days, however, our own community is active on a community run Discord server and a forum board that for the time being is shared on a forum made for a project following in our footsteps (NINA).

No, we don't have your password stored hostage in cleartext. We actually hash your main password with a salted PBKDF2-SHA256 hashing algorithm. For password hashes used on insecure frontends, those are hashed accordingly (e.g., salted MD5 hash for MSN 1 - 4 or MD5Crypt for Yahoo! Messenger) and are optional, as while they aren't necessarily crackable, the algorithms they utilize carry the risk of being prone to collision attacks if retreived. Just be wary when using those options. If you're really paranoid about enabling insecure frontend access, then you can create a throwaway account and enable the insecure frontend options there. Regardless, we recommend you use a different password for each site you're on so that you have less of a chance of having your security breached.

The site and web components of the main server use auto-HTTPS thanks to Caddy, the production web server we use (albeit we use an older version to maintain our sort-of compatibility with MSN on Windows XP and Vista). This ensures that when you perform sensitive actions, like logging in or managing your account, it's carried out securely and out of hackers reach 24/7. This is also utilized by clients capable of secure login, but mileage may vary on if it'll work for you depending on how old the system you're working with is.

As for chats being secured, that varies from frontend to frontend. Right now, our frontend options only allow for unencrypted communications to occur. We know this is a concern for some people, and for now there aren't any easy options for sending encrypted messages through those frontends. If you do find a way, kudos to you. In the future, we do hope we can implement frontends that have the ability to support encrypted chats. If we do get around to that however, the frontends with encryption capabilites in mind for messaging will possibly be separate from the ones not utilizing encryption because otherwise we would be breaching all sorts of privacy.

For the time being, this can be because the server is either overloaded (DDOS or large traffic) or its socket listener is acting up, and the services have to be restarted. We hope to address the first issue by federating Escargot's server communication in the future.

It can either be a server bug, or the server couldn't send a frontend-specifc message to your affected contacts because the frontend they're on doesn't support it. Unless they're on the same frontend, and the client they're using to access it simply doesn't support the features you're trying to take advantage of.

Right now, Escargot, its frontends, this site, and misc. services are all hosted on one instance. Especially with the launch of our latest update, scaling to accomodate larger traffic has been something we've been concerned about. Luckily, we already have plans for this, and this is the next major server update we have in store for Escargot.

To get Switcher to run in debug mode and log what's going on, make sure the client and its components are not running, go into the configuration files for each patched component the client utilizes, which is usually the main executable of the client (for WLM 2009 users at the moment, wlcomm.exe's configuration can be ignored) and paste this section in the beginning of each configuration file:

[debug]
enable = 1
hooks = 1

Save each configuration file and restart the client with administrative privileges (so that the log file can be created and written to). You'll then be able to get a basic description of what's going on with Switcher. If you want to disable debugging, you can remove the section entirely (or an easier option, set the enable and hooks values to 0).

If you're having issues with your client but don't know what's going on, then you can grab the log files for each of the client's patched components (and the client's native debug logs if possible) and send us an issue over at our GitLab with the log files attached.

In most cases, certain versions of the protocol a frontend supports might use insecure login methods that you haven't enabled on your account yet.

To enable these options, go to your account settings, and in the "Insecure Frontend Options" section, check off what insecure login methods you want enabled (e.g., old MSN support for MSN 1 - 4 or Yahoo! support for Yahoo! Messenger 5), type in your current password, and click on "Update".

Group chats are a new Escargot feature, and they simply let you create persistent group chats that you can invite other members to. Members in a group chat can have one of the three available roles that give them a certain amount of access:

• Member - View accepted members, see who's online, block or leave the group chat, and message other members.
• Administrator - Member privileges, plus viewing pending members, managing accepted members, and the ability to invite others to the group chat.
• Owner - Member and administrator privileges. In our implementation, administrators and owners are essentially the same, but a major difference with an Owner is that there can only be one in a group chat. Changing the owner requires transferring ownership to someone else.

On supported frontends, users can create group chats, invite others to them, manage pending invites, see who's online, block group chats, and message others in them. On the site, you can also manage your invites and if you're an administrator or owner, view and manage other members. At the moment, the only frontend that natively supports group chats is our MSN frontend, starting on WLM 2009. This version supports everything up to creation, invitations, blocking, presence, messaging, and departure (at least if you aren't an owner). Member management on the client, however, is expected to be accessed from a web site, so you'll have to log on here to perform that.

In the future, we plan to find a solution to bring group chat support to existing frontends that don't natively support it, and if we can, implement frontends that do.

There are no plans for this at the moment.

Hosting fees are manageable right now (mostly paying for bandwidth for the downloads), but if we ever do something like this, we'll probably start by accepting cryptocurrency donations.

No. Like with Escargot's other frontends, they only require accounts from our system for access. If you haven't already, go sign up for an account.

This can occur for two reasons:

• Starting with WLM 2009, the ability to be alerted when someone adds you to their contact lists is disabled by default. To enable this setting, go to Tools -> Options..., then in the "Privacy" section, check "Alert me when other people add me to their contact list" and click on OK.
• The decision to display contact notifications is determined from web services, and from our tests, the critera used to determine whether to display a notification about a new contact is pretty involved and specific. This either means that one, our implementation might not be accurate and could miss something to allow the notification to appear 100% of the time, or two, if the same person adds you again a second time, then the notification won't be displayed again (unless you clear its cache).

See this thread from our NINA board for instructions on how to fix this.

When setting up your account on Mercury for the first time or accessing your account's settings, set MSNP15 for the protocol before logging in. The default for this option chosen by Mercury is MSNP21 and as of writing we do not support that protocol yet. The MSNP11 option technically should work but is broken for unknown reasons so we recommend you avoid that for the time being.

MSN for Mac 1.0 and 2.0 have been tested to work (on Mac OS 9) and is patchable with some changes to its binary resources (or HOSTS too). Messenger:mac (macOS) 3.0.0 will work also, but MSN for Mac (Classic Mac OS) 2.5.x and Messenger:mac versions 3.5.1 and up have or are speculated to only use older SSL for login (to reiterate, our server only supports TLS 1.0 and up right now). For now, this issue won't be resolved as it isn't that important. Also considering that we believe almost all macOS versions of Messenger:mac are 32-bit and with the recent editions of the OS exclusively supporting 64-bit applications, there'd be no use for the clients in present day anyhow.

MSN Messenger did not support Windows 95 past version 5, but with us not currently supporting the Windows 95 version of MSN 5 your options for using MSN on Windows 95 are limited to versions 1 - 4 (in extension this also means you'll need an account with old MSN support enabled to log in). While versions 5.0 - 7.0 supported Windows 98 and up, our patches we developed for those versions sadly aren't compatible with Windows 9x and 2000 and currently only support XP and above. Plus our current predicament with our HTTPS setup would make it near impossible to use them on Windows 2000 without fully upgrading parts of your installation, and it'd also make support on Windows 98 virtually non-existent as our TLS 1.0 setup does not support any ciphers Windows 98 does.

On XP and Vista, for any version from 5.0 and above (or 4.7 builds .2005 - .3001 and Windows Messenger 5.1), there'll just have to be some extra setup (and patience) involved. Read this thread from our board for more information.

If you are using versions 4.7.2005 - 3001 or 5.0 - 14.0 (WLM 2009) on Windows XP or Vista, then you probably either didn't configure the system properly (see "MSN Messenger does not work on Windows 9x, 2000, XP, or Vista"), or MSN is being finnicky. If it's the latter, then you'll have to try logging in again until you see your contact list. If you're using versions 1.0 - 4.7 (any build before build 2005) however, then see question #11 in our "General" section (Why can't I log in to certain frontends?).

There's also an issue (or feature?) with older versions of Messenger (up to 8.5 we believe) where passwords in password boxes are shortened to 8 characters, which might be an inconvenience to people using longer passwords. If this occurs, then you can either change your password to something with 8 characters or less, or create a throwaway account that has a password of that length (or if you're not willing to do either, then find another frontend to use).

At the moment, you can't. We do plan to open up a frontend hosting predefined and user-created chats and wire it up with the Yahoo! Chat feature in the future.

We plan to implement Yahoo!'s webcam protocol in the future, and if possible, build it on top of a generic webcam backend that can interoperate with other frontend's webcam protocols.

Implementing voice chat for Yahoo! Messenger 6.0 and below is a bit of a mystery. All we know is that it used RTP with its own extensions, but we do not know how those extensions were set up. However, voice chat for Yahoo! Messenger with Voice and above (7+) might be do-able, since we believe it used SIP, but we don't know if this was P2P or centralized.

As for Yahoo! Chat's voice features, if we implement Yahoo! Chat at all, that consistently used the RTP-based voice servers used for classic Yahoo! Messenger clients right through the last version of the client. We don't plan to implement it for Yahoo! Chat any time soon either.

Yahoo! Messenger, by design, requires users to add contacts to a group. Because we support frontends that allow for group-less contact lists, we compromised with Yahoo! Messenger by automatically adding group-less contacts to a group named (No Group).

If you want to add a contact to your contact list without actually adding them to a group on Yahoo! Messenger, specify (No Group) as the group to add the contact to when adding them. If this is done on any other frontend that supports contact lists, then an error will be given instead.

Aliases were being implemented at one point, but they are just glorified Escargot accounts that can only be accessed from the Yahoo! Messenger frontend under your main Escargot account, and it defeats the point of Escargot being globally accessible. In the end, we scrapped all progress on them and left them unimplemented. The closest thing would be to sign up for another Escargot account.

We know most users are used to giving out their emails to others as a way to add contacts to their Escargot contact list, but as we have moved on from being exclusively MSN Messenger focused, that won't carry over well to other frontends. In Yahoo Messenger's case specifically, you had to add users by a unique alphanumeric username it referred to as a "Yahoo! ID". Because our account system allows emails to contain anything from ASCII to Unicode with no restrictions (this is standard with email addresses these days) and we felt that'd pose problems with how Yahoo! handled the IDs, we now require users have an alphanumeric username attached to their account and users on applicable frontends add others with that.