Hi Cookie, square, Volv.
First, thank you Cookie for such a great explanation, you made your point very explicit and understandable, and I appreciate your throughness in your explanation.
I understand better the reasons why you wouldn't want to use the MSNP2P protocol, mainly because of the trust Patchou has with Microsoft, and because of the possible (ab)use of the protocol. I understand that Microsoft wouldn't want anyone to play with their protocol.
About the mangling of sounds and the corruptions or misuse of sounds (banned sounds for example), etc.. I understand that too, and that's a good point which I didn't think of earlier.
About the compatibility issues however, I don't think that would be a problem at all, for example, right now, you send a text like :
[EmotiSound] XXXXX-XXXX-XXXXXXXX-XXXX
(only in theory, I didn't check what the exact string is). Well, you could still send that text so the old versions of MLP still interpret those strings but you could also send a different message that only newer versions would understand.
Don't forget I'm just thinking as I'm writing, and I might be saying something stupid, so don't think that everything I say is written in stone and is the best solution I could offer. Without proper brainstorming, we can't find a good solution, but if we decide to go with the interoperability thing, I'm sure we'll end up with a solution that would be profitable to everyone.
Also note that if Patchou agrees to start designing a solution together, he could come up with a list of his own requirements, like for example, no DB access, not breaking interoperability, not abusing the protocol, etc... and we could spend some time brainstorming and find out a solution that would fill in all of his requirements, if we can't find one, then too bad, we can always drop the project, but at least we tried.
Now, I want to 'prove' to you that everything has a solution. For sound mangling, you could have a DB accessor that doesn't send the sound, but just sends the md5 hash of the sound, so for example, you get the emotisound string, you ask the server for the md5 (very small data), you download the sound from the user, and only play it if the md5 matches, this way, you're sure noone messed with the sound file. In the same way the database could say "this sound is not registered" or "this sound is banned" or whatever and the client would not download or play the file.
You're saying that you would choose to keep the current behavior since helping aMSN get interoperability is not really helping you, I can only answer you that if with our help, designing a new method of fetching sounds can help you drop the DB access from MLP users themselves (without even having aMSN interoperable, I'm just talking here about a new algorithm for optimizing MLP itself) then I'm sure you would be a winner here.
Oh and about the protocol issue for sending the sound, I agree that MSNP2P may not be the solution, but MSN allows plugins to send protocol stuff, they provide means to doing that, like the P4-Context field of a message that was designed for plugins to change the friendly name of a user (like an automessage plugin setting the P4-Context to 'Automessage' so the user would see "Automessage says :" ). In the same way, without even using the MSNP2P, we could send a datacast type message or any other type of message that only our clients understand, and it wouldn't be MSNP2P messages, but just plain MSG messages that WLM ignores and delegates to plugins. We could research that a bit more and see what microsoft thinks about that, but I'm sure they accept it since I remember reading somewhere that they allowed messages like that for plugins (like the text/x-clientcaps message type for example).
Also, don't forget that voice clips are sent through those datacast messages (only the id) and that they get downloaded with MSNP2P, but ink drawings for example are sent entirely through a custom type (image/gif) message so we could send a file (in base64 format) this way as long as it's not too big.
By the way, do you have any limitation on the sound size ? Maybe it's 15 seconds or something ?
Oh and about aMSN being open source (it is), and people could read the source and misuse Patchou's DB. I'm not too sure about that. First, because there is already a wiki somewhere with Patchou's protocol reverse-engineered, and secondly because this new method we would design would be open source itself, it would be so that other clients can use it and be interoperable. I'm not only asking for aMSN interoperability but also interoperability with everyone else since the protocol would become open. And I don't think it would bother Patchou here simply because this new method would be written from the start having in mind that anyone can use it without abusing Patchou's DB. What do you think is best ? having an algorithm open source that everyone can use without harming Patchou's bank account (DB access/bandwidth) or the current algorithm which has been reverse engineered and that anyone can already misuse ?
Anyways, I feel like I've written yet another huge message that bores people, so sorry about that.
One last thing, thanks Volv for 'translating' square's message, I also didn't understand what he meant
Thanks for taking the time to read me.
KaKaRoTo
