Balou9 / user-media-plug

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

user-media-plug design

TODO

  • a metadataserver that emits 'pair' and 'unpair' events
  • a mediadataserver that dis/connects peers according to the events above
  • a simple client api

user-media-plug has 3 data layers:

  • dynamic mediadata
  • dynamic metadata
  • static user data

Static user data

Lives in an abstract-leveldown compliant store, with levelup as db interface.

Database schema:

{
  userA: {
    password: 'sesameopen',
    peers: [ 'userB', 'userC' ],
    status: 'busy'
  },
  ...userB_Z
}

Dynamic metadata

The metadata server acts as a broker that forwards messages between peers and orchestrates connection management.

All messages directed to the server get a response.

Metadata is exchanged via events/messages. These are plain, flat objects that must have a type property, plus event-specific additional data. All messages originating from a client must have a numeric tx property (transaction identifier).

Client messages

Schema Z

userA wants to identify itself, so userA writes:

{ type: 'whoami', user: 'userA', tx: Math.random() }

Schema A

userA wants to be registered, so userA writes:

{ type: 'register', user: 'userA', peers: [], tx: Math.random() }

userA wants userB..Z be persisted as peers, so userA writes:

{ type: 'add-peers', user: 'userA', peers: [], tx: Math.random() }

userA wants userB..Z be discarded as peers, so userA writes:

{ type: 'del-peers', user: 'userA', peers: [], tx: Math.random() }

Schema F

userA wants to change status, so userA writes:

{ type: 'status', user: 'userA', status: 'online', tx: Math.random() }

Schema C

userA wants to call userB, so userA writes:

{ type: 'call', user: 'userA', peer: 'userB', tx: 0.4194567419 }

userB wants to accept userA, so userB writes:

{ type: 'accept', user: 'userB', peer: 'userA', tx: 0.4194567419 }

userB wants to reject userA, so userB writes:

{ type: 'reject', user: 'userB', peer: 'userA', tx: 0.4194567419 }

Schema B

userA wants to get its peers, so userA writes:

{ type: 'get-peers', user: 'userA', tx: Math.random() }

userA wants to get its online peers, so userA writes:

// OBSOLETE...!!!
{ type: 'peers-online', user: 'userA', tx: Math.random() }

Server messages

Schema R

server respondes to all messages with:

{ type: 'res', for: 'xyz' tx: 0.1234567419, ok: true|false } // + optional fields

Schema F

server wants to force a client to call a peerX:

{ type: 'force-call', peer: 'peerX' }

About


Languages

Language:JavaScript 100.0%