MSNP is a strange protocol.

I've been playing with an idea of a new MSNP server for a while.

This has led to me thinking about how some things are implemented in it, namely involving the Notification Server.

The Notification Server is the most important sub-protocol of MSNP, considering the NS controls everything involving Principle communication.

Well, except the actual Instant Messaging features, that would be for Switchboard (SB).

Notifications that a Principle is contacting another Principle are sent over the NS however, which still makes it important.

This sounds like a basic description of what the sub-protocols are, but how are they implemented protocol-wise?

Glad you didn't ask. It's implemented in a TCP arcane format we call "Unobfuscated Plain Text".

This simple fact makes MSNP implementable to anything that can parse ASCII in any way to any thing that supports TCP/IP transport.

Considering that, what format is your usual MSNP command?

Usually [CMD x param0 param1...\r\n], Where CMD is the instruction and x is a transaction ID.

Transaction IDs usually increment by 1 every well, Client-to-Server transaction, as a form of asynchronous processing.

Say for example, you send an instruction which takes a while to process as transaction #1 while also sending another faster instruction as transaction #2.

The server will respond to transaction #2's instruction first with a reply, then send a response for transaction #1 after it finished processing.

You called it strange. Give me an example of such strange-ness.

I avoided that for a while, didn't I?, Okay, here's an example of a werid instruction:

FND, the Directory Find (or just Find) searches for users in the server's database.

The Strange-ness comes in it's server-side response. It's formatted as a list-iterable, but the whole response must be in one packet.

Despite the fact it uses list-iterable parameters, the client will only ever read the first response to the FND command it gets.

And even then, FND doesn't return anything usable to the client to add that person to their Contact List.

It's absurdly strange, I can see why it was removed (such that it even disconnects you if you try using it) in MSNP8.

ActivityPub, what is up with your implementation?

It seems you could of been a fun thing to implement, but instead I felt pure pain trying to figure out what I was trying to implement.

The documentation is a pure mess. Trying to figure out how anything worked was pretty much arcane knowledge.

Sure, Webfinger isn't that bad of an idea, but it's use-case in APub was never mentioned as a standard way to get actors.

It took me a while to figure out that one.

My main problem with APub was the idea of content distribution.

RSS is pretty easy, and fairly stupid (in terms of it's contemporaries), but it doesn't matter if its automated or written by a human.

ActivityPub on the other hand? Expect to send requests to multiple servers with an intent describing the concept that you exist.

I thought we progressed past the point of needing to contact multiple servers with the same information years ago— But I guess not.