aMSN Forums
February 19, 2019, 12:17:32 pm *
Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
News: New forum for aMSN !!
  Home Help Search Login Register  
  Show Posts
Pages: [1]
1  The Community / Whatever You Want To Talk About Here / Re: Here is Practical Explanation about Next Life, Purpose of Human Life - on: August 06, 2014, 09:20:54 am
This is spam, delete this shit, lol. Google snippets of that text if you don't believe me.

(it only bothers me because I was looking for threads posted recently and both this one and the "MOVED" in the other forum were very disappointing.)
2  Development / Amsn development related issues / Re: Is there a way to create a new live/msn/wlm account ? on: August 06, 2014, 09:16:12 am
Hi, you can still create accounts through

In case that link stops working, you can also sign up at and add an alias email address, then switch the default address of that account.

The "Microsoft accounts" used to log in to skype can also be used for MSN, so any method to create those accounts works.
3  Development / aMSN2 / Re: Using EFL is a very, very bad idea on: June 14, 2008, 12:40:34 am
Our expert IRC trolls and forum users are telling that amsn2 is not a good name, because they already think that everything with "amsn" in the name is "ugly". I am not suggesting you to use "emesene", nor to leave "amsn". At least change the meaning of that A (who is that "alvaro"?)

Quote from: "Lobotomik"
EFL is a very, very bad idea,

Since you have trolled kakaroto unintentionally, this is my point of view: EFL is just one of the selectable frontends. Call it obscure, alien, whatever. But from a developer point of view, EFL is exciting, fun to code, and clearly the future. Also, it's the most flexible alternative available. It seems that the amsn team likes to design the GUI freely, regardless of users saying it's ugly because it lacks antialiasing. edit: Of course this new toolkit renders fonts properly, with antialiasing and everything. I meant that tk is ugly because before version 8.5, etc.

Quote from: "Lobotomik"
Why they should drop their goal and jump into this project that has nothing done yet, but is already painting itself into a corner, I just cannot fathom.

You've got an interesting point there. Just to clarify, we won't drop emesene. That's all I can say now for sure.

Quote from: "Fabioamd87"
BUT I need an importer for emesene log, otherwise i must still continue to use emesene

That's easy, we can even use the same database file directly. But there's nothing chat-related done right now, afaik.
4  Development / aMSN2 / Announcing aMSN2!!!! on: June 12, 2008, 08:53:29 pm
Quote from: "BigMadWolf"
Now that some emesene devs are joining and that a GTK UI will be developped for AMSN2, what's next for emesene? Project abandonned (especially libemesene), or just a fork of the UI?

I won't abandon it. We'd like to do some experiments with the emesenelib design, so it will stay alive for sure. BTW, amsn2 will be designed to allow different "protocol" implementations, so we may make emesenelib better than pymsn and use it instead :twisted:

About "fork of the UI", I think we'll copy some of the most complex modules, and rewrite the simpler ones.
5  Development / Amsn development related issues / Quirk in the amsn p2p implementation on: January 22, 2008, 05:54:51 pm
Quote from: "dx"
The official client would stop listening if i don't reply with

(hmm.. i haven't completed that sentence.)

Quote from: "kakaroto"
So the msnp2p data for the INVITE chunk and the subsequent chunks that are part of the INVITE all have the same 'blob id'. The blob id simply means : regroup all the messages with the same blob id into a single message.

That's what i wanted to hear! Now life has meaning again! Cheesy

Quote from: "kakaroto"
Now you have two choices :
1 - notify the application (not the other peer) when each chunk is received
2 - notify the application when the whole blob is tranferred..

In other words, if there is progress indicator or not. (i'd take that flag as a hint)

Quote from: "kakaroto"

Seeing the TLP_EACH flag set in those msnp2p message simply told me that it was a file transfer taking place, that's how I knew it was a file transfer from that little bit of msnp2p data... BUT I just tested and in fact, I realized the TLP_EACH flag is also set when a display picture is being transferred, hehe, so it could have been a DP... :p

Right.. so you just did a mess, but explaining a lot, everything is so clear, IT IS SO BEAUTIFUL NOW, I LOVE P2P. Ok, seriously, that just needs specs as you said, not just sniffs.

BTW, we have 0x01000030 as file data flag, which now i see it's 0x01000000 | 0x20 | 0x10.
Do you know what 0x10 means?

Quote from: "kakaroto"
Oh ok, well, a 603 decline MUST be sent everytime for a file transfer.. EVEN when you want to do a DC...

oh shit

Quote from: "kakaroto"
We do have a very complete msnp2p implementation

I meant DC implementation Tongue
So you are just missing DP/CE over DC. Does it handle incoming DP/CE invites in a direct connection?

Quote from: "kakaroto"
We wrote it while reverse engineering, it's not like we had all the docs ready.. so its purpose was "make it work" rather than "make it a clean implementation".. result.. the WHOLE MSNP2P stack is completely contained into one single function... we tried to clean it a while ago.. now we have a 'MakePacket' and "CreateSLPMessage"  that return a string with the message, but everything else is in one single function that is full of switch/case and if/else etc.. that knows what to do when we receive something...
Problem with that is that it's also very msn specific, it works with msn, but anything else.. who knows! so if a third client does something a bit different, aMSN might crash and burn... we don't know Smiley

WTF? It is still in three functions?
Hmmm... well.. it's not a very bad design, it could be hard to mantain but easier to get working.

Quote from: "kakaroto"
Cool! the bugzilla is now working, so you might want to check it out...
For now, we have in which we'll start the documentation, details are still being discussed over email and we'll probably soon decide how it will be structured!

It's.. empty :|

edit: fixed some bbcode, removed quote-without-reply
6  aMSN Support / Linux / File sending and webcam troubles on: January 21, 2008, 06:56:36 pm
(removed all quote-replies that boiled down to "thanks a lot" or "oleavr is l33t")

Quote from: "kakaroto"

There are many other flags, like the 'TLP_RAK' (0x04) which means 'request ACK', if you get that, it means that it sent a blob and it is expecting an ACK for it that it never received, so you should just ACK it (the blob id and ack id needed are sent in the last 3 fields).

I found this one (the bad way), but it was with invites (both file transfer and direct connect), when i didn't reply with the 200 ok msnslp message.
I think that the official client replies automatically to all unhandled messages with flag-2-acks. But i'm not sure. Just a thought.

Quote from: "kakaroto"

All that information is shared in private between Ole Andre, me and some other pymsn developers through google docs and will be made public once we start documenting MSNP2P protocol under IMFreedom.
If you need more info, send me your MSN address in private so I can add you to my contact list. It will be easier to share knowledge and answer your questions like that.
Hope that helps.

You should publish it ASAP... but meanwhile edited email for privacy Smiley
7  Development / Amsn development related issues / Quirk in the amsn p2p implementation on: January 21, 2008, 06:50:31 pm
Quote from: "kakaroto"
Hey, hello Smiley
Glad to see you here, I really like when developers from other clients come visit us Smiley
I'm sorry I never tried your client, but I've heard many people talk about it already, so I think you're doing a great job and you're definitely going in the right direction if you got so famous in such a short time, keep it up! And as I said before, if you need any help, I'll gladly help you, I think I know the whole MSNP2P stack better than the M$ folks :p

Thanks Cheesy

Quote from: "kakaroto"

I'm still waiting for your wireshark dumps, I hope you can get me those... what I see from the log you pasted, it looks like we get in an infinite loop for some reason during two outgoing file transfers...

Sadly i couldn't reproduce it again. But now i've increased GNU Screen's scrollback to 512kb, so if I find something similar i can at least copy everything, not just three messages Cheesy

Quote from: "kakaroto"
First, notice that there are two session ids in the blobs, Also, the flags is 20, which means 'TLP_EACH' and tells the client to get notified on each chunk instead of getting notified once the blob is completely transfered. That flag is set only during file transfers.

You mean that we should send a binary header acknowledge (flag 2) for each data message received? Sounds strange. The official client would stop listening if i don't reply with

Quote from: "kakaroto"
You say that you use direct connection for display picture and emoticon transfers.. we don't.. so *maybe* that's the problem, I think what could be happening is that you send a request for DC, we see it's not a file transfer, we reject it, but you just continue and send us ip/port or something, we see that message and since it's a trans-req-body message, we think it's for a file transfer, so we go into file transfer mode, but the code is very specific to file transfers, and not display picture, so it might be causing any kind of bugs...

That was misunderstood, we aren't l33t enough to implement DC yet. We *never* send DC requests. We do reply with 603 decline (right now) to transfer it over switchboard. (Now i know that's wrong, because that stops file transfers, and I'm trying to fix it in my local svn copy)

But if you don't send DC invites we just don't do anything. I thought you had a complete implementation (like kmess?)

Quote from: "kakaroto"

And by the way, you might be interested in these two things :
1 - you probably already know about it, but there's a nice msn library : pymsn, which uses MSNP15 and works pretty good so far. The purpose of having this library is to avoid having people rewrite the same thing in 1000 of different implementations. And as I understand it, you're writing yet another implementation :p So if you want to use pymsn instead, I'm sure this will benefit everyone, and you can concentrate on the features/UI stuff and it will help keep your code clean by having a clear separation between protocol and UI (we have this problem now with amsn, the ui and the protocol are too mixed together, and maintainability is reaching zero which is why we're starting a full rewrite..).

Yes, we know, and no, thanks. We like writing our own implementation. It's fine, and we are learning a lot.

Quote from: "kakaroto"

2 - You might be interested in joining us in a project we're starting with the other IM clients. It's a project under the IMFreedom banner, and the purpose is to basically have a unified place for all the documentation on closed protocols like MSN. As you probably know there's hypothetic, msnpiki, zoronax's blog, etc.. a LOT of different places for small bits of information on the protocol and a lot of missing stuff too which will force you to do some reverse engineering... This project aims to gather everything into one single place and have a real 'specs' for those closed protocols, thus opening them up. You can read more about the initial freedesktop bug here :
Here's a quote from what I said about this to another forum user not so long ago...

[...] Also, there's msnpiki containing many useful info in there, and finally, aMSN, pymsn, pidgin, miranda, adium and other open source IM clients are currently joining their effort into one single initiative that will be part of the IMFreedom organization in order to publish a clean documentation for all known closed protocols. Instead of having tons of websites, each explaining a tiny little bit of info from a protocol, and other features with no documentation but still being implemented in some clients, etc.. we'll try to gather it all in one place. You might want to help us with that if you've got some RE to do  
Anyways, we'll keep this subject in another thread if needed (once announced).

Tell me if you would like to participate in this effort.

Yes of course Cheesy. I don't feel very confortable helping msnpiki, they are too... lazy. The freedesktop bugzilla is down right now, i'll check later.
8  aMSN Support / Linux / File sending and webcam troubles on: January 21, 2008, 04:45:26 am
(sorry if this is offtopic, but it's better than asking by mail or private message)

Quote from: "kakaroto"
Happy to announce that SVN revision 9362 should (in theory) fix those file transfer issues. For more technical info read about it here :
The issue was coming from WLM skipping a buffer we send him for some reason (or caused by bad network), and it causes it to start asking us for the buffer again but we didn't listen to him... now it should work fine.
Please test and verify if this happens again or not.

Interesting. I knew that a post like this could provide great docs (since i'm on holidays, i can't code all day, so i fallback to documentation mode, trying to improve msnpiki) ..but i found it's the same thing as kmess.

However, i see that you are replying it or something. Or you just move the pointer back and continue sending?
Why do you call it NAK? Is it an MSNSLP message? Or just a binary message with empty body, that in the headers specifies offset and flag 1? Can you post a sample of such message?

Thanks a lot
9  Development / Amsn development related issues / Quirk in the amsn p2p implementation on: January 16, 2008, 01:47:04 pm
Oh, that code includes some dumb direct connection handling code. I couldn't check yet if amsn sent a direct connection invite, but i know that our reply is 100% wrong, a MSNSLP decline (extra: most fields are random).
That gave us some problems with file transfer, but for display pictures / custom emoticons it just seemed to work.

(the official client sends a flag 64 message some minutes after receiving the decline, and stops transferring with an error) this related?
10  Development / Amsn development related issues / Quirk in the amsn p2p implementation on: January 16, 2008, 01:11:12 pm GPL, python. (i think there was a thread about us here, when we were younger)

If you want to look at the code, it's fairly simple:, Sender class (to send emesene avatar to other clients). "__init__" processes the invite, "on_msnp2p_message_received" processes all other received messages, and "self.emit('msnp2p-message-ready', ...)" sends a reply.

I think it's reproducible always when an amsn user requests an emesene avatar. Emesene to amsn works OK, maybe because we used amsn to debug the DP p2p implementation.

But yes, i'll try to get a wireshark dump. String escapes aren't exactly userfriendly.

offtopic edit: tk 8.4 seems to depend on gtk 1.2 in my distro, wtf
update: wireshark doesn't work well here, i'll try from Cheesy
11  Development / Amsn development related issues / Quirk in the amsn p2p implementation on: January 15, 2008, 02:13:15 am
After requesting my display picture and transferring it, amsn floods my client with these flag 32 p2p messages:

<<< MSG (amsn user) 141
MIME-Version: 1.0
Content-Type: application/x-msnmsgrp2p
P2P-Dest: (me)

mP\x03U'\x16\x05\x00e7\x00\x00\x00\x00\x00\x00\xc5:\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00 \x00\x00\x00\x91C\r\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x01
<<< MSG (amsn user) 141
MIME-Version: 1.0
Content-Type: application/x-msnmsgrp2p
P2P-Dest: (me)

\xe6\x04D"\x8e\xba\x03\x00\xd5\x03\x00\x00\x00\x00\x00\x00\xc5:\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00 \x00\x00\x00\xa1B.\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x01
<<< MSG (amsn user) 141
MIME-Version: 1.0
Content-Type: application/x-msnmsgrp2p
P2P-Dest: (me)

mP\x03U'\x16\x05\x00e7\x00\x00\x00\x00\x00\x00\xc5:\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00 \x00\x00\x00\x92\xb8%\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x01
<<< MSG (amsn user) 141
MIME-Version: 1.0
Content-Type: application/x-msnmsgrp2p
P2P-Dest: (me)

\xe6\x04D"\x8e\xba\x03\x00\xd5\x03\x00\x00\x00\x00\x00\x00\xc5:\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00 \x00\x00\x00~\xf4\n\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x01

It doesn't stop, it's an infinite loop, until i close the switchboard connection.

I know this could be a fault in my p2p implementation (and that's why p2p sucks), but the worst part of the bug seems to be yours.

If you need to know what happened in that discussion before, i'd try to get it, but this time it filled the terminal scrollback
Pages: [1]
Powered by MySQL Powered by PHP Powered by SMF 1.1.11 | SMF © 2006-2009, Simple Machines LLC Valid XHTML 1.0! Valid CSS!