Kosmos Wiki - User contributions [en]

Team

2015-05-08T17:52:07Z

Jan:

== The Agreement ==

The core team consists of a group of people, who have agreed with each other on several things:

* 67P is sorely needed an we want to use it today/asap/yesterday
* We can imagine this to be commercially successful, and we can see us founding a company for the paid/pro version and potentially working for it at some point (to whatever degree that might be)
* We will take the first step and implement the [[prototype]] MVP as a side project. Most of us will come to Chaos Communication Camp in August 2015, so we'll try to finish the MVP during our time there and then define how to proceed
* All work done until then, and (as far as possible) forever, will be published under open-source licenses. However, we want to protect the project name/ trademark, so that people using the name/trademark commercially need to ask our permission, and so that we can use the name commercially ourselves for the benefit of all contributors (incl. non-partners/employees/shareholders).

== People ==

{| class="" style="width: 100%; text-align: left"
! Name
! a.k.a.
! Involvement/expertise
! Kredit address
|-
| Ben Kero
| bkero
| SysOps, DevOps, *nix systems, infrastructure development, IRC, open-source collab/community/dev/relations, ...
|-
| David Grieshammer
| lsa, lsa232
| User experience design, interaction design, graphic/web design, audio, ...
|-
| [[User:Galfert|Garret Alfert]]
| galfert
| Software development (full-stack), Ember.js, RemoteStorage, back-end, payments, ...
| 1KLjNG9FFyTGzZdtyZjQLqhEz8VqkyKkeF
|-
| [[User:Gregkare|Greg Karékinian]]
| gregkare, gkarekinian
| Infrastructure development, DevOps, operations, Chef, Ruby, *nix systems ...
| 1JspMAYETsLWbB1mRaGFFo8kXb96mERFPA
|-
| [[User:Jan|Jan Lelis]]
| janlelis, jan, jaaan
| Software development (full-stack), WebRTC, Ruby, Rails, JavaScript, AngularJS
| 1D98jYRnPYBFdd5zeLkMQgXoifEmeh6fmH
|-
| Michael Bumann
| bumi, derbumi
| Fin-tech development, blockchain technologies, Bitcoin, Ruby, Java, JavaScript, crowd funding/investment, ...
| 1Dwvbv5uMxhgHBbqawDUMSxmxmzL7VJoxV
|-
| [[User:Silverbucket|Nick Jennings]]
| silverbucket, slvrbckt
| Software development (full-stack), JavaScript, Node.js, Sockethub, RemoteStorage, ...
| 19UubPU4SKymYA7gbqoyStNavQAJDrBA59
|-
| [[User:Basti|Sebastian Kippe]]
| basti, skddc, raucao
| Software development (full-stack), front-end/UI, Ember.js, RemoteStorage / business, funding, human resources, ...
| 18mFwCsjRr1M1D6kcNwWEEumhpD5i7Amqf
|-
|}

Feature:Audio/video communication

2014-12-04T13:42:58Z

Jan: IRC is the way to go for prototype

Feature:Audio/video communication

2014-12-03T17:47:48Z

Jan: more on hyperchannel

== Summary ==

67P comes with integrated video- and audio chat capabilities. In the beginning, this is limited to 1on1 calls, but we will support conferencing and/or broadcasting at a later point. WebRTC (Web Real-time Communication) <http://webrtc.org> is used to enable this. WebRTC currently works in Firefox, Chrome, FF and Chrome on Android, Windows Opera and some lesser known browsers (e.g. Bowser on iOS). We might switch to ORTC <http://ortc.org> at some point, because that lower-level standard will be supported in Internet Explorer also.

=== Points to Discuss (read on for more info) ===

* Text chat connection in stand-alone version
* How to do the signaling

== Features ==

67P RTC will be two things:

* A stand-alone web application
* An integrated video/audio call feature in HyperChannel

Both implementations share a lot of their client-code and use the same webrtc backend stack. Only direct 1on1 calls will be implemented for now.

=== HyperChannel Integration ===

A video stream/audio symbol will be integrated into the 67P UI. You can also "pop-out" this UI component (which could be the same as the SA view or not), which makes working on multiple screens easier (and request full screen simpler).

=== Stand Alone Application ===

The WebRTC Stand Alone Application will be needed in the following cases:

* One of the participants is not on HC, but using an IRC Client
* Both parties are using IRC. The Server/Mod generates a room link on the SA app for them. Or maybe: Don't support this scenario?
* Inviting people to an 1on1 chat that are not part of the current 67P organisation (maybe via email)

=== Feature Ideas for Later™ ===

* Screensharing
* Conferencing
* Broadcasting
* Call in to a WebRTC call via plain old phone system

== Technical Implementation ==

'''Components:''' Client/UI Integration, Signaling Backend (might be IRC/SH), TURN Relay, SFU/MCU for Conferencing > 4

=== Integration of Stand Alone App ===

The SA application displays the video stream of the other party, however, some kind of text communication channel is still needed (people want to exchange links etc). There are at least three possibile variants, how this could work:

* Create some anonymous IRC-Channel "on-the-fly" (Drawback: Has to be integrate with IRC Server, not really "stand-alone" anymore)
* No Text-Chat, but Button "promote this to HyperChannel session" (Drawback: No text chat initially)
* Provide P2P Text-Chat via WebRTC's DataChannels (Drawback: Alternative Text Chat implementation, no HC Enhancements, Logs, etc)

''Jan: Currently, my favorite option would be option 1 (if that's technically possible easily) or option 3''

=== Signaling ===

WebRTC requires "signaling" which serves two purposes:
* Peers meet each other
* Peers can exchange some messages w/ each other (like "offer: i can do this codec" or "ice: i have this kind of nat")

We already have some components in the stack that can exchange messages. But it might be better to let an external server/service handle this job. Here are three ways, this could work:

==== Option 1: Signaling via IRC ====

Peers exchange their signaling messages over IRC, using some "special" message formats. For backwards compat, it includes a link to the SA app:

A → B [67p-rtc-invite] Here is your video call: https://playground.p67.io/rtc/bilfgneehlrieli
B → A [67p-rtc-accept] Accepted
A → B [67p-rtc-params] (Signaling messages)
...

If B is not an HC client, it won't send the "accepted", so signaling will be done directly in the SA app, once the link is accessed. Option 3 would work very similar.

'''Advantages:'''
* No extra component/infrastructure required
* "Communication Channel" between peers already exists (at least in HC)

'''Disadvantages:'''
* Stand-alone app needs IRC connection
* Signaling must start from web app (Browser required) - cannot be done directly from IRC-Client

==== Option 2: Signaling via a SocketHub platform ====

SocketHub could have a WebRTC platform, that is used to find the peer and exchange the signaling messages. The verbs would probably be: send, join, leave, observe

'''Advantages:'''
* No extra component/infrastructure required

'''Disadvantages:'''
* SocketHub focus is more to wrap existing services, instead of handling accounts/peers directly. All peers would have be connected to the same SH to be able to send each other messages. The webfinger approach would be a way to work around this, but this is out of scope (we don't want to require each possible participant to have a webfinger record)

==== Option 3: External Signaling ====

Signaling could be done by an external component that does room based signaling ("signaling server") like palava.tv/signaling.io/smoke-signals/signalmaster/xmpp/whatever). Both, HyperChannel and the SA app integrate some code to connect this signaling component, and don't implement the code themselves. We don't have to decide on a specific server/service. Jan is currently working on a open source javascript library ("signaling.js"), that abstracts the signaling provider and offers the same api to the developer, who can use it togehter with a webrtc client library like "simple-peer". The prototype is implemented and it will be released soon. Another option would be, to a create a SocketHub webrtc platform, which wraps a signaling server/service.

'''Advantages:'''
* Same client code can be used in HC and in stand-alone
* Separation of concerns: main app does not need to know about webrtc-signaling-internals

'''Disadvantages:'''
* (Mostly) this means client establish an extra ws-connection
* More operations (or relying on 3rd party)

''Jan: I would suggest option 3 (since it seems most flexible), but also like option 1 a lot (especially if we go with always IRC in the stand-alone sessions)''

Feature:Audio/video communication

2014-12-03T17:41:56Z

Jan: more separation between feature desc and technical details

== Summary ==

67P comes with integrated video- and audio chat capabilities. In the beginning, this is limited to 1on1 calls, but we will support conferencing and/or broadcasting at a later point. WebRTC (Web Real-time Communication) <http://webrtc.org> is used to enable this. WebRTC currently works in Firefox, Chrome, FF and Chrome on Android, Windows Opera and some lesser known browsers (e.g. Bowser on iOS). We might switch to ORTC <http://ortc.org> at some point, because that lower-level standard will be supported in Internet Explorer also.

=== Points to Discuss (read on for more info) ===

* Text chat connection in stand-alone version
* How to do the signaling

== Features ==

67P RTC will be two things:

* A stand-alone web application
* An integrated video/audio call feature in HyperChannel

Both implementations share a lot of their client-code and use the same webrtc backend stack.

Only direct 1on1 calls will be implemented for now.

=== Stand Alone Application ===

The WebRTC Stand Alone Application will be needed in the following cases:

* One of the participants is not on HC, but using an IRC Client
* Both parties are using IRC. The Server/Mod generates a room link on the SA app for them. Or maybe: Don't support this scenario?
* Inviting people to an 1on1 chat that are not part of the current 67P organisation (maybe via email)

=== Feature Ideas for Later™ ===

* Screensharing
* Conferencing
* Broadcasting
* Call in to a WebRTC call via plain old phone system

== Technical Implementation ==

'''Components:''' Client/UI Integration, Signaling Backend (might be IRC/SH), TURN Relay, SFU/MCU for Conferencing > 4

=== Integration of Stand Alone App ===

The SA application displays the video stream of the other party, however, some kind of text communication channel is still needed (people want to exchange links etc). There are at least three possibile variants, how this could work:

* Create some anonymous IRC-Channel "on-the-fly" (Drawback: Has to be integrate with IRC Server, not really "stand-alone" anymore)
* No Text-Chat, but Button "promote this to HyperChannel session" (Drawback: No text chat initially)
* Provide P2P Text-Chat via WebRTC's DataChannels (Drawback: Alternative Text Chat implementation, no HC Enhancements, Logs, etc)

''Jan: Currently, my favorite option would be option 1 (if that's technically possible easily) or option 3''

=== Signaling ===

WebRTC requires "signaling" which serves two purposes:
* Peers meet each other
* Peers can exchange some messages w/ each other (like "offer: i can do this codec" or "ice: i have this kind of nat")

We already have some components in the stack that can exchange messages. But it might be better to let an external server/service handle this job. Here are three ways, this could work:

==== Option 1: Signaling via IRC ====

Peers exchange their signaling messages over IRC, using some "special" message formats. For backwards compat, it includes a link to the SA app:

A → B [67p-rtc-invite] Here is your video call: https://playground.p67.io/rtc/bilfgneehlrieli
B → A [67p-rtc-accept] Accepted
A → B [67p-rtc-params] (Signaling messages)
...

If B is not an HC client, it won't send the "accepted", so signaling will be done directly in the SA app, once the link is accessed. Option 3 would work very similar.

'''Advantages:'''
* No extra component/infrastructure required
* "Communication Channel" between peers already exists (at least in HC)

'''Disadvantages:'''
* Stand-alone app needs IRC connection
* Signaling must start from web app (Browser required) - cannot be done directly from IRC-Client

==== Option 2: Signaling via a SocketHub platform ====

SocketHub could have a WebRTC platform, that is used to find the peer and exchange the signaling messages. The verbs would probably be: send, join, leave, observe

'''Advantages:'''
* No extra component/infrastructure required

'''Disadvantages:'''
* SocketHub focus is more to wrap existing services, instead of handling accounts/peers directly. All peers would have be connected to the same SH to be able to send each other messages. The webfinger approach would be a way to work around this, but this is out of scope (we don't want to require each possible participant to have a webfinger record)

==== Option 3: External Signaling ====

Signaling could be done by an external component that does room based signaling ("signaling server") like palava.tv/signaling.io/smoke-signals/signalmaster/xmpp/whatever). Both, HyperChannel and the SA app integrate some code to connect this signaling component, and don't implement the code themselves. We don't have to decide on a specific server/service. Jan is currently working on a open source javascript library ("signaling.js"), that abstracts the signaling provider and offers the same api to the developer, who can use it togehter with a webrtc client library like "simple-peer". The prototype is implemented and it will be released soon. Another option would be, to a create a SocketHub webrtc platform, which wraps a signaling server/service.

'''Advantages:'''
* Same client code can be used in HC and in stand-alone
* Separation of concerns: main app does not need to know about webrtc-signaling-internals

'''Disadvantages:'''
* (Mostly) this means client establish an extra ws-connection
* More operations (or relying on 3rd party)

''Jan: I would suggest option 3 (since it seems most flexible), but also like option 1 a lot (especially if we go with always IRC in the stand-alone sessions)''

Feature:Audio/video communication

2014-12-03T17:28:58Z

Jan: Initial Draft

== Summary ==

67P comes with integrated video- and audio chat capabilities. In the beginning, this is limited to 1on1 calls, but we will support conferencing and/or broadcasting at a later point. WebRTC (Web Real-time Communication) <http://webrtc.org> is used to enable this. WebRTC currently works in Firefox, Chrome, FF and Chrome on Android, Windows Opera and some lesser known browsers (e.g. Bowser on iOS). We might switch to ORTC <http://ortc.org> at some point, because that lower-level standard will be supported in Internet Explorer also.

=== Points to Discuss (read on for more info) ===

* Text chat connection in stand-alone version
* How to do the signaling

== Features ==

67P RTC will be two things:

* A stand-alone web application
* An integrated video/audio call feature in HyperChannel

Both implementations share a lot of their client-code and use the same webrtc backend stack.

Only direct 1on1 calls will be implemented for now.

=== Stand Alone Application ===

The WebRTC Stand Alone Application will be needed in the following cases:

* One of the participants is not on HC, but using an IRC Client
* Both parties are using IRC. The Server/Mod generates a room link on the SA app for them. Or maybe: Don't support this scenario?
* Inviting people to an 1on1 chat that are not part of the current 67P organisation (maybe via email)

The SA application displays the video stream of the other party, however, some kind of text communication channel is still needed (people want to exchange links etc). There are at least three possibile variants, how this could work:

* Create some anonymous IRC-Channel "on-the-fly" (Drawback: Has to be integrate with IRC Server, not really "stand-alone" anymore)
* No Text-Chat, but Button "promote this to HyperChannel session" (Drawback: No text chat initially)
* Provide P2P Text-Chat via WebRTC's DataChannels (Drawback: Alternative Text Chat implementation, no HC Enhancements, Logs, etc)

''Jan: Currently, my favorite option would be option 1 (if that's technically possible easily) or option 3''

=== Feature Ideas for Later™ ===

* Screensharing
* Conferencing
* Broadcasting
* Call in to a WebRTC call via plain old phone system

== Technical Implementation ==

'''Components:''' Client/UI Integration, Signaling Backend (might be IRC/SH), TURN Relay, SFU/MCU for Conferencing > 4

=== Signaling ===

WebRTC requires "signaling" which serves two purposes:
* Peers meet each other
* Peers can exchange some messages w/ each other (like "offer: i can do this codec" or "ice: i have this kind of nat")

We already have some components in the stack that can exchange messages. But it might be better to let an external server/service handle this job. Here are three ways, this could work:

==== Option 1: Signaling via IRC ====

Peers exchange their signaling messages over IRC, using some "special" message formats. For backwards compat, it includes a link to the SA app:

A → B [67p-rtc-invite] Here is your video call: https://playground.p67.io/rtc/bilfgneehlrieli
B → A [67p-rtc-accept] Accepted
A → B [67p-rtc-params] (Signaling messages)
...

If B is not an HC client, it won't send the "accepted", so signaling will be done directly in the SA app, once the link is accessed. Option 3 would work very similar.

'''Advantages:'''
* No extra component/infrastructure required
* "Communication Channel" between peers already exists (at least in HC)

'''Disadvantages:'''
* Stand-alone app needs IRC connection
* Signaling must start from web app (Browser required) - cannot be done directly from IRC-Client

==== Option 2: Signaling via a SocketHub platform ====

SocketHub could have a WebRTC platform, that is used to find the peer and exchange the signaling messages. The verbs would probably be: send, join, leave, observe

'''Advantages:'''
* No extra component/infrastructure required

'''Disadvantages:'''
* SocketHub focus is more to wrap existing services, instead of handling accounts/peers directly. All peers would have be connected to the same SH to be able to send each other messages. The webfinger approach would be a way to work around this, but this is out of scope (we don't want to require each possible participant to have a webfinger record)

==== Option 3: External Signaling ====

Signaling could be done by an external component that does room based signaling ("signaling server") like palava.tv/signaling.io/smoke-signals/signalmaster/xmpp/whatever). Both, HyperChannel and the SA app integrate some code to connect this signaling component, and don't implement the code themselves. We don't have to decide on a specific server/service. Jan is currently working on a open source javascript library ("signaling.js"), that abstracts the signaling provider and offers the same api to the developer, who can use it togehter with a webrtc client library like "simple-peer". The prototype is implemented and it will be released soon. Another option would be, to a create a SocketHub webrtc platform, which wraps a signaling server/service.

'''Advantages:'''
* Same client code can be used in HC and in stand-alone
* Separation of concerns: main app does not need to know about webrtc-signaling-internals

'''Disadvantages:'''
* (Mostly) this means client establish an extra ws-connection
* More operations (or relying on 3rd party)

''Jan: I would suggest option 3 (since it seems most flexible), but also like option 1 a lot (especially if we go with always IRC in the stand-alone sessions)''

Team

2014-11-30T17:57:05Z

Jan: /* The Team */ add angular to myself

== The Agreement ==

The core team consists of a group of people, who have agreed with each other on several things:

* 67P is sorely needed an we want to use it today/asap/yesterday
* We can imagine this to be commercially successful, and we can see us founding a company for the paid/pro version and potentially working for it at some point (to whatever degree that might be)
* We will take the first step and implement the [[prototype]] MVP as a side project. Most of us will come to Hacker Beach in January 2015, so we'll try to finish the prototype during our time there and then define how to proceed
* All work done until then, and (as far as possible) forever, will be published under open-source licenses. However, we want to protect the project name/ trademark, so that people using the name/trademark commercially need to ask our permission, and so that we can use the name commercially ourselves for the benefit of all contributors (incl. non-partners/employees/shareholders).

== The Team ==

{| class="" style="width: 100%; text-align: left"
! Name
! a.k.a.
! Involvement/expertise
|-
| Ben Kero
| bkero
| SysOps, DevOps, *nix systems, infrastructure development, IRC, open-source collab/community/dev/relations, ...
|-
| David Grieshammer
| ...
| User experience design, interaction design, graphic/web design, audio, ...
|-
| [[User:Galfert|Garret Alfert]]
| galfert
| Software development (full-stack), Ember.js, RemoteStorage, back-end, payments, ...
|-
| [[User:Gregkare|Grégory Karékinian]]
| gregkare, gkarekinian
| Infrastructure development, DevOps, operations, Chef, Ruby, *nix systems ...
|-
| [[User:Jan|Jan Lelis]]
| janlelis, jan, jaaan
| Software development (full-stack), WebRTC, Ruby, Rails, JavaScript, AngularJS
|-
| [[User:Silverbucket|Nick Jennings]]
| silverbucket, slvrbckt
| Software development (full-stack), JavaScript, Node.js, Sockethub, RemoteStorage, ...
|-
| [[User:Basti|Sebastian Kippe]]
| basti, skddc, raucao
| Software development (full-stack), front-end/UI, Ember.js, RemoteStorage / business, funding, human resources, ...
|-
|}