There are a number of chat servers hosted on this server, some of them experimental. The public one is chat.SledjHamr.org.
If you want to chat with onefang, you can use this web chat thing called Candy, or access it via Jabber / XMPP at chat@chat.SledjHamr.org .
Standards are cool, the world should use more of them. Unlike a lot of chat systems, Jabber / XMPP has been a proper standard for a long time. Though one big problem with Jabber / XMPP is the large number of extra standards for extensions, not everyone supports the same ones, and some are supported badly.
Some things in the Jabber / XMPP world are known by different names, the fact that it's called either "Jabber" or "XMPP" started that trend. So it can get confusing to know what people are talking about.
Your "account name" is also known as your "JID" (Jabber ID). That will be something like name@example.com. Though that looks like an email address, it isn't one. They are unrelated, so having a name@example.com JID doesn't mean you will have a name@example.com email account. Though sometimes you do, Googles Gmail uses the same name for both, if you have name@gmail.com as a Gmail account, then you can use that as your JID to log onto Googles XMPP system, using ordinary XMPP clients, and chat with people on other XMPP servers. Other things have JIDs as well, like chat rooms.
"Apps" and "clients" are the same thing in this context. Apps is a more recent usage, mostly inspired by the invention of smartphones, clients are generally anything that hooks up with a server of some sort.
"Channel", "chat room", "conferences", "Multi User Chat", "MUC", "room", and maybe more, all refer to a group of people all chatting with each other in one place.
"Contact list" and "roster" all refer to the list of people that you know and are known to. Sometimes also called "buddies" or "subscriptions". Technically you subscribe to that persons presence, so you know when they are logged on. Or you authorize them to know if you are logged on.
"Group" is the worst one, it can refer to two different things, sometimes in the same client. Officially it refers to a grouping of people on your roster, but sometimes is used to refer to a chat room as "groupchat".
"Keys" and "fingerprints" are not quite the same thing, but might be used to refer to the same concept, they are closely related. See the section below about "The secret dance of the keys" for details.
Some Jabber / XMPP clients are -
The web client currently used by SledjHamr.org.
The web client I am switching to replacing Candy.
Conv6ations is a fork of Conversations that supports IPv6, I don't think it changes anything else. Conversations is the gold standard for OMEMO encryption support, as they invented that.
Apparently very popular, I find it to be unstable, and others have found it to be unfriendly.
An old favourite of many people, it supports a great variety of chat protocols.
onefang uses Psi+, which is an experimental fork of Psi, though some changes get merged back into Psi. Even though it's experimental, it seems quite stable to me.
User friendly enough that Boots uses it. Only supports asingle account.
Various commercial chat systems have used, or are still using XMPP protocol, though often somewhat crippled. Google have used it since the days of Google Talk, and if you have a Gmail account, you can likely use that same account for XMPP. Google Talk is now called Google Hangouts, which itself is due to be renamed / rewritten / dropped in favour of something else soonish.
Some of you may have been sent to this page from one of the OpenSims I run, this section is for you.
opensim-SC is my fork of OpenSim, and I have recently added integration with the Prosody XMPP server that I use. This means you can use your OpenSim grid account to log into Prosody. There is at least one chat room you can use to chat with anyone else from the grid that has logged on this way. More integration is planned. Eventually you'll be able to use this to chat with people that are on the grid to.
Some people just don't read the instructions, please read these instructions.
OpenSim user names are two words, which for this example we will use "Jane Doe". For this example we will use a grid URI of "http://example.com:8002/" (a typical OpenSim URI). So the XMPP server domain would then be "example.com", and your account name / JID on that server would be "Jane.Doe@example.com". Note the use of a dot "." between the first and last names.
All the OpenSim grids I run have my half arsed account system at https://example.com/sledjchisl.fcgi/account.html and currently they have the account system in the top left, and a button for converse.js at the lower right, with links to other converse.js middle right. converse.js seems to be the best of a bad lot for web clients, but as you can see it comes in four variants, some of which work better than others. Try them all if you don't want to try a desktop / mobile client. For the converse.js running on the grid server, you can skip the @example.com part of your account name / JID, and just use "Jane.Doe". NOTE: you log onto both parts separately, later it'll be single sign on so you can log onto both at once.
There are hundreds of extensions to the basic XMPP protocol, and some of them perform similar fuctions. I'll only mention the important ones here.
OMEMO encryption is a new standard for encrypting things that is based on the encryption system used in Signal (also used by WhatsApp and others). It works reasonably well for encrypted chat rooms, as well as one on one chats. It's what SledjHamr.org uses. OMEMO is what is known as end to end encryption, or e2e, which means that your messages are encrypted on your device, and only unencrypted on the recieving device. It is the style of encryption that various authoritarian and wanabe authoritarian governments wish to ban, using the excuse that they can't spy on terrorists and peadophiles, but in reality they likely want to spy on everyone.
Being newish, not all clients support it well. Are we OMEMO yet? tracks the progress of adding support to a lot of XMPP clients. For the clients listed on this page -
TL,DR - Why can't things just be easy? There is always a trade off between security and convenience. An unlocked door is very convenient, but not secure at all. Add a lock and it's more secure, but less convenient, coz now you need to carry the key, and stop to unlock the door. Things get more secure, but less convenient, when you add things like armed guards, metal detectors, sniffer dogs, fingerprint scans, paper work, a second locked door, hazmat suits. So the more security you want to have, the harder things become to use. The OMEMO developers have tried to keep things easy for users, but there's only so much "easy" that is possible. If you want very secure communications, you have to jump through some hoops. You may want to complicate things even more by using a VPN or TOR if you are paranoid, I do.
OMEMO uses what is known as asymetric encryption, using public and private keys. In a nutshell that means that the keys used to encrypt and unencrypt messages are in two parts. The private part is a very secret part you should carefully protect, the public part is what you give out to others. Then others can use your public key to encrypt something that only your private key can unencrypt. Your XMPP client takes care of that for you. If someone is in your roster, chances are you have exchanged keys with them.
The keys fingerprints are used to check if you are really talking to the person you think you are talking to, and not to someone that is pretending to be them. You do this by comparing the fingerprint you have for them on your device to the one on their device. The best way to do that is in person, but that is not always possible. You can use some other communications channel to check these, but then you have to use some other way to check it's the correct person. Maybe test them with shared knowledge an imposter might not know, like "Only the real Alice knows about the tattoo on my left buttock" or something. Your XMPP client can help with this, though sometimes it's just showing you a list of fingerprints and letting you select "I trust this one", sometimes by showing QR codes for the other person to point their devices camera at.
Things can get complicated with OMEMO. If you are using different clients on different devices, say Conversations on your phone, Psi+ on your laptop, and another copy of Psi+ on your desktop, then each of those clients will use a different pair of public / private keys. If you are like me, and use a bunch of different clients on your desktop for testing purposes, then each client on each device uses it's own key. That'll be why when you are checking my fingerprint, you might see half a dozen of them.
Things get even more complicated when using OMEMO in a chat room. You have to exchange public keys and compare fingerprints with everyone in the room. Each message sent to the room has to be encrypted with the public keys of each person in the room, to be sent to them so they can unencrypt it with their private key. If they are logged on using multiple clients / devices, then that message has to be encrypted with the public keys for each of those clents / devices. Ths is why there is a slight delay when sending encrypted messages to a chat room, encrypting messages involves heavy maths, so encrypting them a bunch of times takes a while.
To facilitate this, the OMEMO module used on this server insists that certain conditions are met before it will allow encrypted chat rooms to work. It has to be a members only chat room. It has to be non anonymous, so that everyone can see the JID of everyone else. Everyone should be on every ones roster (I have another module that ensures that). All clients / devices involved must support OMEMO,
So as you can imagine, when a new person joins an encrypted chat room, lots of keys secretly dance around between everyones clients as the entire system tries to get all of this complicated stuff sorted out automatically. Some clients have a "trust on first use" option, which you might want to try, just be aware that this means you are blindly trusting people. You might need to check your clients list of keys and fingerprints, to ensure that they are all trusted properly. OMEMO being a new protocol, and all of this being very complex, sometimes the dancers will stumble. As mentioned above not all clients fully support OMEMO, and some might not support it well.
With so much complexity, and so many clients, I haven't figured out all the quirks and solutions for all combinations yet. Some of these things might help if you are having problems. The Android app Conversations is the gold standard for OMEMO support, they invented OMEMO, so if you have an Android device, try using the very latest version of that and not be logged in on other clients. You may need to install it directly from their web site, or try the F-Droid version. Remember to enable OMEMO on the client, and in the chat room. If you are having trouble with a particular persons key/s, try a one on one encrypted chat with them. If that person isn't logged on, it sometimes helps if they are removed as a member of the chat room, and added back when you are both logged on. Try to make sure everyone is using the very latest stable version of what ever client they are using.
Some clients might support uploading and viewing pictures, or even gifs, and some might support sending files. Some will load the picture / gif for you, some you might have to click on the link.
SledjHamr.org uses Prosody, though there are other servers.
[Insert lots of details here about how to setup Prosody.]