2010
02.25

Emesene Server

Emesene Server (EServer)

“[...] will be possible for a business man in New York to dictate instructions, and have them instantly appear in type at his office in London or elsewhere. He will be able to call up, from his desk, and talk to any telephone subscriber on the globe, without any change whatever in the existing equipment. An inexpensive instrument, not bigger than a watch, will enable its bearer to hear anywhere, on sea or land, music or song, the speech of a political leader, the address of an eminent man of science, or the sermon of an eloquent clergyman, delivered in some other place, however distant. In the same manner any picture, character, drawing, or print can be transferred from one to another place. Millions of such instruments can be operated from but one plant of this kind. [...]“
Nikola Tesla (1908)

[On the Wardenclyffe Tower, in "The Future of the Wireless Art" in Wireless Telegraphy and Telephony (1908) ]

About:

Emesene Server (Eserver) is an Open Protocol for instant messaging.

thanks:

Resources:

You can register here and download the client here. You must open the ports 1864-1865.
Currently under modification, and don’t work.

Currently Working:

Server:
  • Login
Client:
  • Login

Screeshots:

Login

Login

Goals:

Make a secure, strong instant messaging protocol. Based on P2P and capable to easily transmit and stream data. The main target users are people interested on social and entertain chat.

Inspiration:

Basis: Microsoft Live Messenger
Operation mode: Skype
Other: Neuronal systems

Tecnology:

Description:

Server:

Store Usernames & Passwords.

Supernode:

Store UsersContactsLists, UsersIp, UsersStatus, UsersSid.

Node:

Connect with Supernodes sendding information to other Nodes.

Clients:

Allows the user to connect to other users:
Client|Node->Supernode<-Node|Client
Or
Client|Supernode->Supernode|Client
Or
Client|Supernode<-Node|Client
Or
Client|Node->Supernode|Client.
Or
Client|Node->Node|Client

Every Client is a Node, some clients are Supernodes.

The Nodes can connect to and listen Nodes
The Nodes can connect to Supernodes
The Supernodes can connect to and listen Supernodes
The Supernodes can listen Nodes

Supernode Task:

Authenticate with the server.
Maintain connection with other Supernodes.
Wait for node and supernode connections.
Authenticate nodes and supernodes with the Suid.
Serve a contact list.
Serve status, nick, subnick, avatar, media, ip to nodes.
Serve status, nick, subnick, avatar, media, ip and suid to supernodes.
Send Node messages to other Nodes directly or through another Supernode.

Node Task:

Authenticate with the Server.
Maintain connection with at last one Supernode.
Authorize with Supernodes.
Maintain connection with Contact Nodes.
Send Client messages to Nodes directly or through a Supernode.

When switch from Node to Supernode?:

If the node can Receive connections from a Supernode on port 80, 443 and another one.
And accept and make TCP and UDP connections.
And have more than 1Gb ram (or two).

When switch from Supernode to Node?:

If the Supernode don’t receive connections or fail on create.
Or have less than 1Gb ram.

On Supernode:

Node-> Supernode Request -> Supernodes(3)
Supernodes(3)->Supernode Request->Server
Server -> SNSuid ancrypted by Passphrase -> Node
Node-> Md5(128 bit) SNSuid -> Server
Server-> SNSuid encrypted by Passphrase -> Supernodes

Transactions:

Node to node:

Node->Object encrypted with RelationshipKey->Node

Node to node thought Supernode:

Node1->
Object encrypted with RelationshipKey:
- Sender (Node1)
- Recipient (Node2)
- Object (ID: 11)
Encrypted with SNSuid
- Sender (Node1)
- Subject (Supernode)
->Supernode->
Object encrypted with RelationshipKey:
- Sender (Node1)
- Subject (Node2)
Encrypted with Suid
- Sender (Node1)
- Subject (Node2)
->Node

Login Sequence:

Client->Say hello->Server
Server->Send a random phrase encrypted by the Password->Client
Client->Send the md5 of decrypted phrase->Server
Server->
Say hello, and send the sid encrypted with the phrase SharedSecret
Send a Relationship Keylist encrypted with the phrase
->Client

Server->Esid encypted by Requester sid-> Supernodes

Example:

Client User: Beethoven
Client Password: Elisa

?user=Beethoven&request=hello

Server random phrase: Aerosmith
Phrase encripted by password: ‘\xeeN\xd0\xa5Y\xa6o(\xb5′ (in this case contain scape characters)
<epassphrase>ee4ed0a559a66f28b5</epassphrase>

Client md5 (128 bit) of decrypted phrase: 83a16d117c19fecb681515a21bc151aa

?user=Beethoven&request=phrase_md5&phrase_md5=83a16d117c19fecb681515a21bc151aa

Server: hello
Server-User sid: 194353874865
Server-User sid encrypted with phrase: 600bf99dd74fd50bdc8227df
<esid>600bf99dd74fd50bdc8227df</esid>

Nodes Request Sequence:

Node -> Plain RequestType, Data encrypted by sid -> Node
Node -> Plain Errors, Data encryptes by sid -> Node

Example:

Node Beethoven:
<request id=”1258468454545″><type>user_data</type><from>Bach</from><sender>Beethoven</sender><recipient>Supernode</recipient></request>

Supernode:
Bach Ip: 265.888.178.444
Beethoven sid: 600bf99dd74fd50bdc8227df
<response id=”4654798421″ to_request=”1258468454545″><user_data><ip>49d30660c4348ebbe00759fdbd44a8</ip></user_data></response>

Node Beethoven to 265.888.178.444:
<request id=”1258468454546″><type>ip</type><sender>Beethoven</sender><recipient>Bach</recipient></request>

Node Bach:
Bach sid: 7879465413215774
Ip: 265.888.178.444
<reponce id=”468754632157″ to_request=”1258468454546″><ip>aa48417d4b25b91b55c4dd752e3c7d</ip></responce>

Server-Client:

Proposed scheme based on Layers. Every layer could be set on the fly to stablish communication.

The client have 6 layers: Authentication layer, that set the Authentication Type required to stablish communication (the number on the Phone). Input Layer, that set the input of the Object to transmit (Mic). The Listen Layer set the communication port that is always opened and waiting information (Line In). The Process Layer take the information and redirect it to the proper location to process and generate an answer (Integrated Circuit). The Security Layer encrypt the answer message properly (? on cell phones). The Output Layer send the message (Line Out).

The server have 5 layers, basically the same as Client but not the Input one: The Listen Layer set the communication port that is always opened and waiting information (Line In). Authentication layer, that set the Authentication Type required to stablish communication (the number of the line on the Phone). The Security Layer decrypt the message (? on cell phones). The Process Layer take the information and redirect it to the proper location to process and generate an answer (Central). The Output Layer send the message (Line Out).

Client:

Authentication Layer:

  1. None
  2. UserName
  3. UserName – Password
  4. UserName – Passphrase
  5. ClientName – Passphrase | UserName – Passphrase

Input Layer:

  1. Generation
  2. Stdinput
  3. Parameter (From outside)

Listen Layer:

  1. HTTP
  2. Port UDP/TPC

Process Layer:

  1. Function
  2. Authentication

Security Layer

  1. Plain
  2. Simple encriptation

Output Layer

  1. Stdout
  2. Return
  3. HTTP POST/GET
  4. HTTPS POST/GET

Server:

Listen Layer:

  1. HTTP POST/GET (web server)
  2. HTTPS POST/GET (web server)
  3. Port UDP/TPC

Authentication Layer:

  1. None
  2. UserName
  3. UserName – Password
  4. UserName – Passphrase
  5. ClientName – Passphrase | UserName – Passphrase

Security Layer:

  1. Plain
  2. Simple encriptation

Process Layer:

  1. Function
  2. Authentication

Output Layer:

  1. HTTP
  2. HTTPS
  3. Port UDP/TPC

Example:

Client ->
Hi Server!
Server ->
Hi Client!

Client:

Authentication:
None ->
No Action

Input Layer:
Parameter ->
Object=”Hi Server!”
Type=”text”

Security Layer:
Plain ->
No Action

Output Layer:
HTTP POST ->
www.server.com?erequest=<erequest type=”text”>Hi Server!</erequest>

Server:

Listen Layer:
HTTP POST->
<erequest type=”text”>Hi Server!</erequest>

Security Layer:
Plain ->
No Action

Process Layer:
Function ->
Object=”Hi Server!”
Type=”text”

Function:
always return “Hi Client!”.

Output Layer:
HTTP ->
echo “<erequest type=”text”>Hi Client!</erequest>”

Client:

Autentication:
Direct Response ->
No Action

Listen Layer:
HTTP->
<erequest type=”text”>Hi Client!</erequest>

Input Layer:
Parameter ->
Object=”Hi Server!”
Type=”text”

Process Layer:
Function ->
Object=”Hi Server!” Type=”text”

Biological description:

Nodes: Have the pulsion to make connection to Supernodes
Supernodes: Have the pulsion to join the Sender and the Recipient.
Clients: Are mediums between User and UserNode

Share and Enjoy:
  • Print
  • Twitter
  • Facebook
  • Digg
  • del.icio.us
  • Reddit
  • Google Bookmarks

2 comments so far

Add Your Comment
  1. Wow. I’ve been wanting to work on a chat protocol like this for some time.
    I don’t have a lot of coding skills yet though. Something that would
    be original and unique to add to this chat protocol would be server-verified IP based
    supernode physical location for the purpose of automatically creating
    regional chat rooms in addition to subject-based chat rooms.

  2. Hi terlmann, glad to see somebody interested on it :)
    Good feature, sounds like the search by place on Skype…
    EServer looks to be server-less, but something like that could be implemented.

    Regards!