@Aaron Baker:
A friend of mine have bought one of your games, lost his registration key, contacted you to get a key replacement, where you replied you don't do key replacements. Because of this, he and a lot of other people from my country will never buy games from you again. Just mentioning...

Ok, let me tell you my personal opinion. It's up to you if you agree or not, so don't get angry at me.
If we buy something, we are responsible for taking care of what we've bought. In my case, this applies not just to audiogames, but to any piece of software or hardware that I purchase over the Internet.
I'm not just keeping backups of my purchased keys on my hard drive, but also I'm keeping emails on my GMail server containing registration keys in a special GMail folder. I've bought it, and I don't wanna lose it. Simple as that. This ensures that I will be able to get to my keys in no time in case of hard drive failure or if my PC explodes and what not. Especially if I buy something for 40 dollars and more. And I'm taking it seriously since my first online purchase in my life.
I'm not the type of person who thinks: Well, I don't care if I lose the key, the developer will re-generate it for me. I simply don't want it happen, because the game may sooner or later be sold to some other developer (Q9 is a good example), discontinued, etc. That's what happens for years and years, especially in the audiogame industry.

@AronBaker, I can't help but notice you attempting to attribute -- or compare -- your games to the video game market. I'm sorry to inform you that the audio games industry is not the video games industry, and most video game developers don't offer license keys, but instead distribute via a platform like Steam, where the games can be re-downloaded and whatnot for as long as the customer needs, and as many times as the customer requires. For you folks preaching the backup rule, while the rule is generally a good thing to follow, what happens if your backup drives fail? What happens if that cloud storage provider you use goes out of business and you lose all that data? You can't just buy 10000 hard drives and set up a RAID array to back up everything to -- I doubt very many people in the community have the money for a reliable RAID array anyway. So while the back up everything is a good idea, you must also factor in the fact that, while it is the customers job to ensure that they don't lose information, it is the vendors job to ensure that they don't, either, and can provide the customer with the data the customer requires if the customer is unable to reacquire the data themselves. It doesn't matter who you are or how powerful or popular you are; if you rebuff users and blame them for losing data when the loss of such data may be out of their control, or their backup disks or services may have failed, and they don't have the money to pay for a drive data recovery service, your going to lose customers. Period. As such, if a customer loses an activation dongle (perhaps in a flood, fire, or whatnot), you are obligated to replace it, or lose that customer. If a customers email provider starts to instigate a filter that deletes emails after a specified number of days, and the customer does not have the resources to set up a backup system of their own, you are obligated to supply them with a replacement key, or lose that customer. There is no alternative. Just because I back up my entire computer to a million disk drives does not mean that those million disk drives won't fail in the near future, perhaps because Caveat Emptor set in, and I was unaware of a hardware fault in the drives and, as I am not a drive technician, can't be expected to know that. It does not mean that, because my data is spread across millions of drives, it will never go away, or never be lost.

@33, true, but we'd need all of those who integrated it to customize it for their own purpose so no one could figure out the full algorithm used, or at least have a missing key ingrediant.

There's a fairly good point to be made here.

On one hand, I think it should be up to us to expend reasonable means to back up and store our stuff. Reasonable, however, depends on  your means. Some people don't have the money for an external drive, or aren't savvy enough to think it's necessary.
But then, there's the developer angle. When you provide a replacement key, it's a pain in the neck, but the net cost to you is nothing, as far as I'm aware. You are literally just allowing someone to re-access a product they have already bought. if you want to alienate customers, go ahead and selectively institute a no-key-replacement policy alongside a price tag which is among the highest I have ever seen for an audio game. I think this is bad business practice, and don't even get me started on all the design decisions that have plagued this developer in particular. The point is, even reasonable means sometimes fail, and I don't think it's unreasonable that a player should be able to come to you and say "Hey so-and-so, I'm really sorry to do this to you but my hard drive busted/I got a new machine, and I love your game, and can I have a replacement key please? I'm really sorry I don't have a backup of my original key or email or whatever". And if you want to keep that customer a happy customer, you do a couple of minutes of legwork and give them a key. End of story. Failure to do so, in my opinion at least, speaks to a lot of negative characteristics which good developers shouldn't have, or at least shouldn't have too much of.

Now, with that out of the way, I started with responsibility for a reason, and I do realize that replacing people's keys is annoying. That said, I think some sort of software which could automatically validate your details and send you a new key is a good idea. It would take the work out of it for developers while simultaneously offering greater support to players. If I somehow lost my registration info for Manamon and Aaron refused to replace my key - he replaced my Paladin key no problem, by the way - I would immediately and without a backward glance simply stop playing Manamon and stop supporting the developer. This is true for any other game I pay a fair amount for and expect good support from.

Now I'm going to get personal to Manamon for a moment. I hope this doesn't offend, but I think it ought to be said.

Aaron, just a thought. If you don't want to add to the game anymore, don't want to support it anymore except for the fixing of bugs, then why exactly do you think you still deserve forty bucks from everyone who hasn't gotten the game yet? When the game was new, and we thought you might address a lot of your balance and other concerns, forty bucks was both a purchase and something of a promise of faith. "We're giving you this money because we expect that it's paying both for the game and for that game's continued improvement". And then the majority of that improvement never came. Most manamon are unbalanced in some fashion. Moves can't be taught except by level-up and a couple of niche items. Some items, attacks and manamon are utterly broken and simply not worth using. The script is littered with literally hundreds of spelling and grammar errors. There is virtually no post-game. Trading or battling requires a lot of business with port forwarding which is poorly explained in the manual and rather unfriendly to those who don't know what they're doing. There is no metagame to speak of and probably few to no online battles occurring. For me, at least, I view this as a broken promise of sorts. It wasn't a promise you explicitly made, but one you implicitly did by charging that price for your game. I will never suggest that people crack the game or try and steal keys or whatever - that's not ethical - but if you really don't have the time, the desire or the inclination, or dare I say even the skill, to make this game better than it is, why not abandon it, or drop its price significantly, that way people who still wish to enjoy it can do so at a reduced price, with the understanding that this is essentially as good as it gets? I really can't stress this enough.

I'd be happy to write the initial algorithm/system myself. At least, to generate keys. But other than generating new keys, 'd need to know other features you guys might want. Something like this isn't going to be easy, at least it won't be if we want to make it secure as well.

My initial thought is a DRM system like AHC uses, where you have an online account at a website, and that account determines which games you can play. With this system, rather than entering your name and a registration key, you enter a username or Email address and a password, the game logs into that account, and checks if it's authorized for that account. The developer can decide how many computers can be activated at a time. Every so often (not every time, probably random), the program phones home to make sure its license is still valid. The developer can allow a fixed number of activations, or what I might call "Reasonably Unlimited Activations." With this scheme, activations are normally allowed, unless the system sees an excessive number of activation attempts in a short period of time, or an activation from a geographic area far from where other activations have happened. In this case, the activation is possibly provisionally allowed, but the developer is alerted, and contacts the customer to see if there's a legitimate explanation for the recent activity E.G. lost all computers in a natural disaster, moved to another country, etc. or if it's a simple case of attempted account sharing. Any previously-issued software license can be revoked by the developer if it's suspect, or possibly by the customer if they've had a computer stolen, etc. When that copy of the program next checks in to validate its license, it gets told the bad news, and reverts to trial/demo/unregistered status until a new license is supplied.

@jack, I wouldn't really say that the name/key system is outdated. Its more that its implemented incorrectly, leaving applications insecure and vulnerable. Either someone uses the wrong encryption or hashing algorithm, or they try implementing their own crypto scheme (which backfires horribly), or they try to do something weird by (for example) repeatedly encrypting or hashing the same thing over and over to attempt to make it harder to crack. By the hashing/encrypting the same thing bit, I mean they'll do something like:
encrypt(encrypt(encrypt(encrypt(data))))
Or
hash(hash(hash(data)))
This kind of scheme doesn't make your application any more secure. In fact, it can Make it even less secure. The name/key system can be used, but you need internet activation, and you need to do it right. I can try and whip something up to figure out how I might do it, and then show you guys. Mmm....

@43, that's always a risk with internet activation. But that's literally the only way to prevent people from usurping the system and cracking it relatively easily. It certainly isn't perfect, and people have found ways around it, but its the best defense we have so far.

@45, not really. If we use something like a keyed hash algorithm like Argon2I, or encrypt the license data with an AEAD encryption algorithm like AES-256-GCM, and generate the key based off of random data that we ask the operating system to retrieve, and encode that data as base64 and use that as the product key, the client can send what the user enters for their license data back to the server, and the server can decode, decrypt, and verify the license datas authenticity. I'm no cryptographer, but I can probably try to whip up a minimalist command-line license key generator in C++ in about an hour, though that's a major guess.

@47, true. One way we could do this is by using an algorithm like XChaCha20Poly1305. No, I'm not abandoning AES; however, AES relies on hardware to make it fast, and if that fails it resorts to software. And AES encryption at the software level is incredibly slow compared to it running directly on the processor. XChaCha20Poly1305 is, so far as my research indicates, just as secure as AES, with the bonus of being fully software based, and much faster than AES. So, any thoughts on a resource like this:
* A developer downloads this open-source web activation framework
* In the download is the source code to both the framework as well as a little tool. The developer compiles everything.
* The developer runs the tool and is issued two things: a private key and a public key. Here, we use public key encryption to generate license keys: the developer logs into the system with his private key and is able to generate license files (which are just public keys).
* The developer receives a purchase and issues a public key license file. The customer downloads the public key file (encoded in hex, base32 or base64) and runs the app.
* The app does two things at this stage:
First: the app runs a hash of the public key, authenticates with the server and requests a hash validation. If the server responds in the affirmative, then the public key is considered an authentic public key -- that is, the app knows that the public key was issued by a trusted party; otherwise, the app rejects the public key and pops up some kind of error message stating that the license is invalid.
Second: the app decodes the public key, deserializes it, and reads it into RAM. It then sends a request to the server to verify the details of the public key with the server. If the server, again, responds in the affirmative, the key is considered truly authentic, and the app is considered activated.
Of course, all data transmission would be sent over a TLS 1.2 (or if possible, TLS 1.3) connection between the client and server, using the best encryption algorithms available. Hell, we could even make the framework scriptable, if we wanted to. But that's my general idea of how a system like this might work. I'd be happy to attempt to make a proof-of-concept using the cryptography library I am currently enjoying using. At least, the server part. The only downside to this idea is that it would not work in BGT. But the hole point of this system -- or at least one of its points -- is to utterly eradicate BGT's influence as much as possible. BGT is far too insecure and far too easy to manipulate and retrieve data from for this system to function with it.