Kosmos Wiki - User contributions [en]

User:Greg

2020-01-27T11:59:24Z

Administrator: Administrator moved page User:Gregkare to User:Greg: Automatically moved page while renaming the user "Gregkare" to "Greg"

* '''Real name:''' Greg Karékinian
* '''Freenode nick:''' gregkare
* '''Personal website:''' https://karekinian.com
* '''GitHub:''' https://github.com/gregkare

User:Gregkare

2020-01-27T11:59:24Z

Administrator: Administrator moved page User:Gregkare to User:Greg: Automatically moved page while renaming the user "Gregkare" to "Greg"

#REDIRECT [[User:Greg]]

Feature:Incoming notifications / (web)hooks

2016-04-22T12:26:12Z

Administrator: Fix capitalisation of remoteStorage

== Summary ==

== Features ==

=== Sockethub Butlers ===

* Incoming Webhook (usually HTTP POST) to channel/storage
** Data formats and message rendering for known hooks/services
** Vanilla hook with defined message format and plain/common rendering for custom services
* RSS feed to channel/storage (detect known types, e.g. MediaWiki recent-changes feed)
* Bitcoin wallet transactions to channel/storage
* Email/IMAP to channel/storage. Would check for emails and parse one or all of sender/recipient/subject/text in order to trigger extracting information and/or post/store to channel/storage.
* Webpage change tracking to channel/storage (check regularly if content on a page changed)
* remoteStorage resource change to channel/storage

=== Notes ===

* [GitHub] Apparently it's now possible to define a single hook for all activities within an organization: https://developer.github.com/changes/2014-12-03-preview-the-new-organization-webhooks-api/ — that means we might be able to set that once per API/OAuth call and have a single catcher for all GitHub-related things (no more forgetting to configure channel notifications for new repos e.g.). Also, notifications for not just commits, but other activities as well.

Feature:Audio/video communication

2016-04-22T12:23:14Z

Administrator: Fix typos

== Summary ==

Kosmos 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 ([http://webrtc.org "Web Real-time Communication"]) is used to enable this. WebRTC currently works in Firefox, Chrome, FF and Chrome on Android, Opera and some lesser known browsers (e.g. Bowser on iOS). We might switch to ORTC ([http://ortc.org "Object RTC"]) at some point, which is a lower-level standard that will be supported in Internet Explorer also.

== Features ==

=== HyperChannel Integration ===

A video stream (or audio symbol for non-video) will be integrated into the Hyperchannel UI (maybe in an extra tab?) You can also "pop-out" this UI component, which makes working on multiple screens easier (and requesting full screen simpler).

=== Feature Ideas for Later™ ===

* Screensharing
* Conferencing
* Broadcasting
* Call in to a WebRTC call via plain old phone system (e.g. via [https://www.sipgate.io sipgate] or similar)

==== 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 Kosmos 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) - This will be done via IRC or WebRTC's DataChannels.

== 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")

It is implemented on top of the existing IRC channels (via SocketHub) using special message formats, which will get parsed by the HC Client. For backwards compatibility (later), it could include 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)
...

== Before feature launch ==

* In order to be able to quickly launch meetings before having our own integration, we could create scripts for hal8000 to start new meetings at e.g. g2m, meet.jit.si, talky, palava.tv.

== Notes ==

* http://socket.io/blog/socket.io-p2p

Feature:Migration from existing systems

2016-04-22T12:11:57Z

Administrator:

== Summary ==

In order to make migration from other systems/services easy and enjoyable, both for just trying out the software as well as transferring all data for a complete org migration to Kosmos, there will be a subsystem for importing data and configuration.

== Features ==

* Import user names/accounts
* Import channels, including their chat history
* Import shared files

== Migration sources ==

* Slack
* Flowdock
* Campfire
* HipChat
* IRCCloud
* Grove.io

== Notes ==

* Grove.io has JSON files for single days or complete history. Resource names are guessable/common.

Feature:Chat

2016-04-22T12:07:42Z

Administrator: Another test edit for the hook

== Summary ==

Kosmos's chat functionality is initially based on the IRC protocol (used via Sockethub), but enhances it with input/output app components, which enable rich-snippet rendering and other features. Let's call these components satellites, for lack of a better codename atm. (Feel free to brainstorm names on this wiki page. Would be great to have something where people say "dude, just write a [perfectname] for Kosmos". Kind of like DuckDuckGo "spices" for example.)

Chat is the main user interface for channels, which act as the scopes for other features, like e.g. [[Feature: File sharing| File sharing]], as well.

== Features ==

=== Satellites ===

{| class="wikitable"
! Name
! Description
|-
|Code Snippet
|When pasting a multi-line text, it offers to convert it into a rendered, potentially code-highlighted rich snippet
|-
|Map
|When pasting geo coordinates, or a maps URL (e.g. GMaps or OSM), it renders a small map with a pin and possibly popup on click, as well as a link to a big version of the map in a new window/tab/app
|-
|Incoming notification
|Every incoming notification (e.g. a Travis build) is given a notification type (hardcoded), which in turn is associated with a rich-snippet template and data.
|-
|Channel link
|When a #channelname is detected, it renders a link to that channel. Even better, if the user is using channels with the same name in multiple spaces, it should open a menu to select which one to open.
|-
|Time zones
|When other users are using different time zones, show their local time as well. Either next to the normal timestamp, or highlight the timestamp to indicate that it's not the other person's time zone and show their time on hover or similar.
|-
|Username mention
|When a person's own username is detected in another person's message, it is highlighted and a notification is triggered, if the app is not in the foreground (optionally with audio sound).
|-
|Word-list mention
|Same as username mentions, but not enabled by default (i.e. empty word list in the beginning). Users can configure their own word list per channel.
|-
|Image
|When an image URL is detected, it renders the image inline (either inline, if nothing else surrounds the url, or as a second line)
|-
|Tweet
|When a link to a tweet is detected, the tweet is fetched an rendered with a rich snippet in a new line
|-
|GitHub/Bitbucket
|When pasting a link to a GitHub repository, it renders the basic information about that repository (name, description, language, ...).
|-
|Website link
|When a generic URL is detected (and not handled by another satellite), it tries to fetch the title of the linked Web page or document and add that as a second line
|-
|Emoji
|When [http://www.emoji-cheat-sheet.com/ emoji syntax] is detected, it renders an emoji image. When starting to type emoji syntax, it shows an auto-complete menu, similar to GitHub comment form fields.
|-
|Voting
|"Everyone in favor of [x]?" triggers a yes/not poll. Responding with +1 or -1 (or using the vote input that then writes a +1 for you) counts up votes in a widget that stays in view until the poll is closed. If the majority hasn't responded in x amount of time, it sends them reminders to vote.
|-
|Correct/replace previous line
|When an s/word/word pattern is detected, it applies the replacement to the previous line of that user (only as rendering in the Web UI). A discreet highlighting is added to the word to indicate it was replaced, and when hovering (or similar), you can see the details of the replacement.
|}

Hint: all of this is backwards-compatible to plain IRC, meaning that if something is too long or for other reasons not possible to render nicely in a line of chat, it needs to be posted somewhere and linked to. The Web Client can fetch extra information from that resource, while the plain chat can use minimal messages that don't pollute the UI for plain-old-IRC-client users (let's call these programs POICs from now on. :))

=== Offline notifications for mentions ===

When you're not connected to 67P on any device, it will send notifications for username mentions in channels. Configurable methods:

* Email — Sent by Sockethub. Could even use the actual person's email address and SMTP account for sending a direct email person-to-person with the message content.
* W3C Push API / Service workers — As soon as possible
* None (maybe "weekend mode" or something)
* http://littlebigdetails.com/post/125515172684/slack-automatically-and-immediately-disables

=== Channel logs / history replay ===

Channel logs live in either the user's personal remote storage (for personal usage on public servers), or in the organization's common remote storage. A Sockethub butler daemon will publish the logs to the storage servers, while they can be retrieved from the Web Client (for replay) directly via remoteStorage.js. Also, the Web client may want to publish/read read-status for messages/message ranges to/from the storage.

=== NickServ integration ===

This should belong to the setup flow/UX for public channels, in case the server has NickServ running.

When starting the app/prototype for the first time and/or setting up a public subspace/server, 67P will guide you through the process of either creating a reserved username or configuring an existing one.

Most of this could actually be a satellite, being triggered by NickServ messages and writing the right ones back. It might make sense to make storing the password optional.

=== Easy joining of public channels as entry point to becoming a user ===

See e.g. something like https://github.com/rauchg/slackin (love the badge, too) or the various Web IRC programs, of course.

=== Create channels on the fly ===

As opposed to having to create new channels before being able to join them, it's possible to just join channels on the fly via the normal syntax and then configure them once you're in it. IRC got that right, but not possible on e.g. Grove. On pro, that needs to be limited to admins optionally (but maybe not in the first version).

=== Feature ideas for later™ ===

* Send-later for messages (e.g. wait until business hours with sending something)
* Big-screen mode/view. Can show activity in multiple/all/selected channels at once.
* History replay for normal IRC clients; could include a link to open complete history in browser (like Grove does)
* Real-time translation to user's language (with hover-to-see-source or something)
* Make channels linkable, even when they're on different networks (maybe needs a satellite for both input and display)
* [http://blog.flowdock.com/2015/04/16/team-is-the-new-everyone Team mentions]
* Move messages to other channels (Oftentimes I realize I should've posted in a different one, esp. on private servers. Very possible to implement cleanly in Kosmos.)

Feature:Chat

2016-04-22T12:05:13Z

Administrator: s/sth/something

== Summary ==

Kosmos's chat functionality is initially based on the IRC protocol (used via Sockethub), but enhances it with input/output app components, which enable rich-snippet rendering and other features. Let's call these components satellites, for lack of a better codename atm. (Feel free to brainstorm names on this wiki page. Would be great to have something where people say "dude, just write a [perfectname] for Kosmos". Kind of like DuckDuckGo "spices" for example.)

Chat is the main user interface for channels, which act as the scopes for other features, like e.g. [[Feature: File sharing| File sharing]], as well.

== Features ==

=== Satellites ===

{| class="wikitable"
! Name
! Description
|-
|Code Snippet
|When pasting a multi-line text, it offers to convert it into a rendered, potentially code-highlighted rich snippet
|-
|Map
|When pasting geo coordinates, or a maps URL (e.g. GMaps or OSM), it renders a small map with a pin and possibly popup on click, as well as a link to a big version of the map in a new window/tab/app
|-
|Incoming notification
|Every incoming notification (e.g. a Travis build) is given a notification type (hardcoded), which in turn is associated with a rich-snippet template and data.
|-
|Channel link
|When a #channelname is detected, it renders a link to that channel. Even better, if the user is using channels with the same name in multiple spaces, it should open a menu to select which one to open.
|-
|Time zones
|When other users are using different time zones, show their local time as well. Either next to the normal timestamp, or highlight the timestamp to indicate that it's not the other person's time zone and show their time on hover or similar.
|-
|Username mention
|When a person's own username is detected in another person's message, it is highlighted and a notification is triggered, if the app is not in the foreground (optionally with audio sound).
|-
|Word-list mention
|Same as username mentions, but not enabled by default (i.e. empty word list in the beginning). Users can configure their own word list per channel.
|-
|Image
|When an image URL is detected, it renders the image inline (either inline, if nothing else surrounds the url, or as a second line)
|-
|Tweet
|When a link to a tweet is detected, the tweet is fetched an rendered with a rich snippet in a new line
|-
|GitHub/Bitbucket
|When pasting a link to a Github repository, it renders the basic information about that repository (name, description, language, ...).
|-
|Website link
|When a generic URL is detected (and not handled by another satellite), it tries to fetch the title of the linked Web page or document and add that as a second line
|-
|Emoji
|When [http://www.emoji-cheat-sheet.com/ emoji syntax] is detected, it renders an emoji image. When starting to type emoji syntax, it shows an auto-complete menu, similar to GitHub comment form fields.
|-
|Voting
|"Everyone in favor of [x]?" triggers a yes/not poll. Responding with +1 or -1 (or using the vote input that then writes a +1 for you) counts up votes in a widget that stays in view until the poll is closed. If the majority hasn't responded in x amount of time, it sends them reminders to vote.
|-
|Correct/replace previous line
|When an s/word/word pattern is detected, it applies the replacement to the previous line of that user (only as rendering in the Web UI). A discreet highlighting is added to the word to indicate it was replaced, and when hovering (or similar), you can see the details of the replacement.
|}

Hint: all of this is backwards-compatible to plain IRC, meaning that if something is too long or for other reasons not possible to render nicely in a line of chat, it needs to be posted somewhere and linked to. The Web Client can fetch extra information from that resource, while the plain chat can use minimal messages that don't pollute the UI for plain-old-IRC-client users (let's call these programs POICs from now on. :))

=== Offline notifications for mentions ===

When you're not connected to 67P on any device, it will send notifications for username mentions in channels. Configurable methods:

* Email — Sent by Sockethub. Could even use the actual person's email address and SMTP account for sending a direct email person-to-person with the message content.
* W3C Push API / Service workers — As soon as possible
* None (maybe "weekend mode" or something)
* http://littlebigdetails.com/post/125515172684/slack-automatically-and-immediately-disables

=== Channel logs / history replay ===

Channel logs live in either the user's personal remote storage (for personal usage on public servers), or in the organization's common remote storage. A Sockethub butler daemon will publish the logs to the storage servers, while they can be retrieved from the Web Client (for replay) directly via remoteStorage.js. Also, the Web client may want to publish/read read-status for messages/message ranges to/from the storage.

=== NickServ integration ===

This should belong to the setup flow/UX for public channels, in case the server has NickServ running.

When starting the app/prototype for the first time and/or setting up a public subspace/server, 67P will guide you through the process of either creating a reserved username or configuring an existing one.

Most of this could actually be a satellite, being triggered by NickServ messages and writing the right ones back. It might make sense to make storing the password optional.

=== Easy joining of public channels as entry point to becoming a user ===

See e.g. something like https://github.com/rauchg/slackin (love the badge, too) or the various Web IRC programs, of course.

=== Create channels on the fly ===

As opposed to having to create new channels before being able to join them, it's possible to just join channels on the fly via the normal syntax and then configure them once you're in it. IRC got that right, but not possible on e.g. Grove. On pro, that needs to be limited to admins optionally (but maybe not in the first version).

=== Feature ideas for later™ ===

* Send-later for messages (e.g. wait until business hours with sending something)
* Big-screen mode/view. Can show activity in multiple/all/selected channels at once.
* History replay for normal IRC clients; could include a link to open complete history in browser (like Grove does)
* Real-time translation to user's language (with hover-to-see-source or something)
* Make channels linkable, even when they're on different networks (maybe needs a satellite for both input and display)
* [http://blog.flowdock.com/2015/04/16/team-is-the-new-everyone Team mentions]
* Move messages to other channels (Oftentimes I realize I should've posted in a different one, esp. on private servers. Very possible to implement cleanly in Kosmos.)

Feature:Chat

2016-04-22T12:00:28Z

Administrator: Test edit for the hook

== Summary ==

Kosmos's chat functionality is initially based on the IRC protocol (used via Sockethub), but enhances it with input/output app components, which enable rich-snippet rendering and other features. Let's call these components satellites, for lack of a better codename atm. (Feel free to brainstorm names on this wiki page. Would be great to have something where people say "dude, just write a [perfectname] for Kosmos". Kind of like DuckDuckGo "spices" for example.)

Chat is the main user interface for channels, which act as the scopes for other features, like e.g. [[Feature: File sharing| File sharing]], as well.

== Features ==

=== Satellites ===

{| class="wikitable"
! Name
! Description
|-
|Code Snippet
|When pasting a multi-line text, it offers to convert it into a rendered, potentially code-highlighted rich snippet
|-
|Map
|When pasting geo coordinates, or a maps URL (e.g. GMaps or OSM), it renders a small map with a pin and possibly popup on click, as well as a link to a big version of the map in a new window/tab/app
|-
|Incoming notification
|Every incoming notification (e.g. a Travis build) is given a notification type (hardcoded), which in turn is associated with a rich-snippet template and data.
|-
|Channel link
|When a #channelname is detected, it renders a link to that channel. Even better, if the user is using channels with the same name in multiple spaces, it should open a menu to select which one to open.
|-
|Time zones
|When other users are using different time zones, show their local time as well. Either next to the normal timestamp, or highlight the timestamp to indicate that it's not the other person's time zone and show their time on hover or similar.
|-
|Username mention
|When a person's own username is detected in another person's message, it is highlighted and a notification is triggered, if the app is not in the foreground (optionally with audio sound).
|-
|Word-list mention
|Same as username mentions, but not enabled by default (i.e. empty word list in the beginning). Users can configure their own word list per channel.
|-
|Image
|When an image URL is detected, it renders the image inline (either inline, if nothing else surrounds the url, or as a second line)
|-
|Tweet
|When a link to a tweet is detected, the tweet is fetched an rendered with a rich snippet in a new line
|-
|GitHub/Bitbucket
|When pasting a link to a Github repository, it renders the basic information about that repository (name, description, language, ...).
|-
|Website link
|When a generic URL is detected (and not handled by another satellite), it tries to fetch the title of the linked Web page or document and add that as a second line
|-
|Emoji
|When [http://www.emoji-cheat-sheet.com/ emoji syntax] is detected, it renders an emoji image. When starting to type emoji syntax, it shows an auto-complete menu, similar to GitHub comment form fields.
|-
|Voting
|"Everyone in favor of [x]?" triggers a yes/not poll. Responding with +1 or -1 (or using the vote input that then writes a +1 for you) counts up votes in a widget that stays in view until the poll is closed. If the majority hasn't responded in x amount of time, it sends them reminders to vote.
|-
|Correct/replace previous line
|When an s/word/word pattern is detected, it applies the replacement to the previous line of that user (only as rendering in the Web UI). A discreet highlighting is added to the word to indicate it was replaced, and when hovering (or similar), you can see the details of the replacement.
|}

Hint: all of this is backwards-compatible to plain IRC, meaning that if something is too long or for other reasons not possible to render nicely in a line of chat, it needs to be posted somewhere and linked to. The Web Client can fetch extra information from that resource, while the plain chat can use minimal messages that don't pollute the UI for plain-old-IRC-client users (let's call these programs POICs from now on. :))

=== Offline notifications for mentions ===

When you're not connected to 67P on any device, it will send notifications for username mentions in channels. Configurable methods:

* Email — Sent by Sockethub. Could even use the actual person's email address and SMTP account for sending a direct email person-to-person with the message content.
* W3C Push API / Service workers — As soon as possible
* None (maybe "weekend mode" or sth)
* http://littlebigdetails.com/post/125515172684/slack-automatically-and-immediately-disables

=== Channel logs / history replay ===

Channel logs live in either the user's personal remote storage (for personal usage on public servers), or in the organization's common remote storage. A Sockethub butler daemon will publish the logs to the storage servers, while they can be retrieved from the Web Client (for replay) directly via remoteStorage.js. Also, the Web client may want to publish/read read-status for messages/message ranges to/from the storage.

=== NickServ integration ===

This should belong to the setup flow/UX for public channels, in case the server has NickServ running.

When starting the app/prototype for the first time and/or setting up a public subspace/server, 67P will guide you through the process of either creating a reserved username or configuring an existing one.

Most of this could actually be a satellite, being triggered by NickServ messages and writing the right ones back. It might make sense to make storing the password optional.

=== Easy joining of public channels as entry point to becoming a user ===

See e.g. something like https://github.com/rauchg/slackin (love the badge, too) or the various Web IRC programs, of course.

=== Create channels on the fly ===

As opposed to having to create new channels before being able to join them, it's possible to just join channels on the fly via the normal syntax and then configure them once you're in it. IRC got that right, but not possible on e.g. Grove. On pro, that needs to be limited to admins optionally (but maybe not in the first version).

=== Feature ideas for later™ ===

* Send-later for messages (e.g. wait until business hours with sending sth)
* Big-screen mode/view. Can show activity in multiple/all/selected channels at once.
* History replay for normal IRC clients; could include a link to open complete history in browser (like Grove does)
* Real-time translation to user's language (with hover-to-see-source or sth)
* Make channels linkable, even when they're on different networks (maybe needs a satellite for both input and display)
* [http://blog.flowdock.com/2015/04/16/team-is-the-new-everyone Team mentions]
* Move messages to other channels (Oftentimes I realize I should've posted in a different one, esp. on private servers. Very possible to implement cleanly in Kosmos.)

MediaWiki:Common.css

2015-04-16T16:43:52Z

Administrator:

/* CSS placed here will be applied to all skins */

MediaWiki:Common.css

2015-04-16T16:42:58Z

Administrator: Created page with "/* CSS placed here will be applied to all skins */ body { color: #cc0; }"

/* CSS placed here will be applied to all skins */
body {
color: #cc0;
}

Feature

2015-03-23T18:18:26Z

Administrator: Created page with "== Features == * Chat * Incoming notifications / (web)hooks * Feature: Audio/video communication| Audio..."

== Features ==

* [[Feature: Chat| Chat]]
* [[Feature: Incoming notifications / (web)hooks| Incoming notifications / (web)hooks]]
* [[Feature: Audio/video communication| Audio/video communication]]
* [[Feature: File sharing| File sharing]]
* [[Feature: Migration from existing systems| Migration from existing systems]]
* [[Feature: Guest communication| Guest communication]]
* [[Feature: Themes| Themes]]
* [[Feature: Offline support| Offline support]]
* [[Feature: Onboarding / Setup| Onboarding / Setup]]
* [[Feature: Design| Design]]
* [[Feature: Multi-backend support| Multi-backend support]]

Main Page

2015-03-23T18:16:51Z

Administrator: /* Features */

== Codename 67P ==

Codename 67P a.k.a. Nice Cave a.k.a Subspace is a team communication application based exclusively on open protocols, standards, and APIs. All of its components are free software, published under open-source licenses. User-facing programs will be built upon the [https://platform.html5.org/ Web Platform], communicating with server components via HTTP and WebSockets.

== Building blocks ==

67P consists of several components, all of which can be configured separately, and thus be either hosted by a provider or self-hosted by the user/organization. These are:

* [http://sockethub.org Sockethub] server for facilitating client/server communication between the Web client and the multiple protocols/backends/APIs it needs to talk to (e.g. IRC, SMTP, OStatus, Twitter, GitHub, SMS gateways, TURN etc.), as well handling incoming notifications like e.g. WebHooks from services that want to publish messages to 67P-handled IRC channels
* [http://remotestorage.io RemoteStorage] server for storing all user data in a user-defined/controlled storage backend
* [https://en.wikipedia.org/wiki/Internet_Relay_Chat IRC] server for private communication servers (not needed for personal usage on public servers)
* [https://en.wikipedia.org/wiki/Traversal_Using_Relays_around_NAT TURN] server for WebRTC networking enhancements/fallback for audio and audio/video calls (optional)
* [https://github.com/67P/hyperchannel Web client], written in [http://emberjs.com/ Ember.js], using sockethub.js and remotestorage.js, and making heavy use of Ember/Web components for implementing its functionality

[[Technical overview]]

== Goals ==

* Provide users/organizations/businesses with a modern, full-featured team communication solution, which is easy to set up and use
* Eventually provide a fully hosted, one-click-setup solution for private team communication (keeping the possibility to exchange any component at will, e.g. storing all data on a user-controller remoteStorage server instead of the 67P company's own remoteStorage servers
* Use common, open, documented data formats for storing all data, thus making it possible to use/manage/input stored data from other apps (no matter if new or existing). This is where the remoteStorage protocol is different than all other personal data storage protocols made for the Web.
* Make it possible for users to be part of and use both public and private channels/spaces/servers at the same time (no more Campfire/Hipchat/Slack for work and clients, and IRC only for open-source and hobby, all in different apps)
* Always keep the whole application in a state that can be deployed by anyone (with the necessary skills) who wishes to self-host the whole system. That explicitly includes excellent documentation for doing so.
* Reversing the trend of declining IRC users on public servers by giving everyone a great Web IRC client, most importantly making it easy to connect, register nicks, auto-log and replay messages while away — all the nitty-gritty details that even software developers struggle with these days
* Always be backwards-compatible to plain IRC. This will be achieved through smart client components, enhancing the rendering/fetching of messages on the client side, while messages transferred via servers are always plain-text and readable in IRC without spammy extra characters/lines
* Have an excellent mobile client (or multiple)
* Make use of the latest Web Platform standards, not caring about backwards-compatibility in Web runtimes (much). 67P is a modern Web application, and people not running modern Web runtimes can use plain IRC clients.

== Features ==

* [[Feature: Chat| Chat]]
* [[Feature: Incoming notifications / (web)hooks| Incoming notifications / (web)hooks]]
* [[Feature: Audio/video communication| Audio/video communication]]
* [[Feature: File sharing| File sharing]]
* [[Feature: Migration from existing systems| Migration from existing systems]]
* [[Feature: Guest communication| Guest communication]]
* [[Feature: Themes| Themes]]
* [[Feature: Offline support| Offline support]]
* [[Feature: Onboarding / Setup| Onboarding / Setup]]
* [[Feature: Design| Design]]
* [[Feature: Multi-backend support| Multi-backend support]]

== Development Roadmap ==

See [[Roadmap]].

== Naming / Branding ==

67P is just a codename, because naming is hard. See [[Naming]].

== Team ==

See [[Team]].

== Company ==

See [[Company]].

== Notes ==

=== Similar projects / inspiration ===

* https://kiwiirc.com
* https://www.irccloud.com
* http://shout-irc.com
* https://gitter.im
* http://chat.stackoverflow.com
* https://chatgrape.com/ (good input field ideas)
* https://github.com/thedjpetersen/subway
* https://conversejs.org
* http://qoffee.io
* http://neovim.org (bounties for features)
* http://web.scrollback.io very similar in goals, open-source, claims to be used by a lot of different groups, has funding and appears to be hiring.
* http://sdelements.github.io/lets-chat/
* http://www.matrix.org/

Main Page

2015-03-23T18:16:07Z

Administrator: /* Features */

== Codename 67P ==

Codename 67P a.k.a. Nice Cave a.k.a Subspace is a team communication application based exclusively on open protocols, standards, and APIs. All of its components are free software, published under open-source licenses. User-facing programs will be built upon the [https://platform.html5.org/ Web Platform], communicating with server components via HTTP and WebSockets.

== Building blocks ==

67P consists of several components, all of which can be configured separately, and thus be either hosted by a provider or self-hosted by the user/organization. These are:

* [http://sockethub.org Sockethub] server for facilitating client/server communication between the Web client and the multiple protocols/backends/APIs it needs to talk to (e.g. IRC, SMTP, OStatus, Twitter, GitHub, SMS gateways, TURN etc.), as well handling incoming notifications like e.g. WebHooks from services that want to publish messages to 67P-handled IRC channels
* [http://remotestorage.io RemoteStorage] server for storing all user data in a user-defined/controlled storage backend
* [https://en.wikipedia.org/wiki/Internet_Relay_Chat IRC] server for private communication servers (not needed for personal usage on public servers)
* [https://en.wikipedia.org/wiki/Traversal_Using_Relays_around_NAT TURN] server for WebRTC networking enhancements/fallback for audio and audio/video calls (optional)
* [https://github.com/67P/hyperchannel Web client], written in [http://emberjs.com/ Ember.js], using sockethub.js and remotestorage.js, and making heavy use of Ember/Web components for implementing its functionality

[[Technical overview]]

== Goals ==

* Provide users/organizations/businesses with a modern, full-featured team communication solution, which is easy to set up and use
* Eventually provide a fully hosted, one-click-setup solution for private team communication (keeping the possibility to exchange any component at will, e.g. storing all data on a user-controller remoteStorage server instead of the 67P company's own remoteStorage servers
* Use common, open, documented data formats for storing all data, thus making it possible to use/manage/input stored data from other apps (no matter if new or existing). This is where the remoteStorage protocol is different than all other personal data storage protocols made for the Web.
* Make it possible for users to be part of and use both public and private channels/spaces/servers at the same time (no more Campfire/Hipchat/Slack for work and clients, and IRC only for open-source and hobby, all in different apps)
* Always keep the whole application in a state that can be deployed by anyone (with the necessary skills) who wishes to self-host the whole system. That explicitly includes excellent documentation for doing so.
* Reversing the trend of declining IRC users on public servers by giving everyone a great Web IRC client, most importantly making it easy to connect, register nicks, auto-log and replay messages while away — all the nitty-gritty details that even software developers struggle with these days
* Always be backwards-compatible to plain IRC. This will be achieved through smart client components, enhancing the rendering/fetching of messages on the client side, while messages transferred via servers are always plain-text and readable in IRC without spammy extra characters/lines
* Have an excellent mobile client (or multiple)
* Make use of the latest Web Platform standards, not caring about backwards-compatibility in Web runtimes (much). 67P is a modern Web application, and people not running modern Web runtimes can use plain IRC clients.

== Features ==

* [[Feature: Chat| Chat]]
* [[Feature: Incoming notifications / (web)hooks| Incoming notifications / (web)hooks]]
* [[Feature: Audio/video communication| Audio/video communication]]
* [[Feature: File sharing| File sharing]]
* [[Feature: Migration from existing systems| Migration from existing systems]]
* [[Feature: Guest communication| Guest communication]]
* [[Feature: Themes| Themes]]
* [[Feature: Offline support]]
* [[Feature: Onboarding / Setup| Onboarding / Setup]]
* [[Feature: Design| Design]]
* [[Feature: Multi-backend support| Multi-backend support]]

== Development Roadmap ==

See [[Roadmap]].

== Naming / Branding ==

67P is just a codename, because naming is hard. See [[Naming]].

== Team ==

See [[Team]].

== Company ==

See [[Company]].

== Notes ==

=== Similar projects / inspiration ===

* https://kiwiirc.com
* https://www.irccloud.com
* http://shout-irc.com
* https://gitter.im
* http://chat.stackoverflow.com
* https://chatgrape.com/ (good input field ideas)
* https://github.com/thedjpetersen/subway
* https://conversejs.org
* http://qoffee.io
* http://neovim.org (bounties for features)
* http://web.scrollback.io very similar in goals, open-source, claims to be used by a lot of different groups, has funding and appears to be hiring.
* http://sdelements.github.io/lets-chat/
* http://www.matrix.org/

Feature:Offline support

2015-03-23T18:14:18Z

Administrator: Administrator moved page Feature2:Offline support to Feature:Offline support

== Summary ==

Not only when being offline, but especially when using an intermittent, slow, or otherwise bad connection, the app still works and behaves nicely.

The Web client will check every message for actually having arrived in a channel and render the state of that nicely in the UI. If a message couldn't be sent, it offers a button to re-try sending it.

The app is delivered with an Appcache manifest in production, so that its code and assets are cached in the Web runtime, not only making start-up extremely fast, but also enabling starting the app while being offline and e.g. checking the logs of the last day or so.

Feature:Themes

2015-03-23T18:12:33Z

Administrator: Administrator moved page Feature2:Themes to Feature:Themes without leaving a redirect

== Summary ==

Different people like different things. And a virtual office shouldn't be grey and boring, same as a physical one should not. That's why you can change the visual theme of the Web client to something you find more appealing than a white background with black text on it.

== Features ==

* Choose between well-designed, beautiful, bundled themes
* If a theme isn't designed well enough, it won't be bundled. Contributed themes have to be approved by our UX/UI quality gatekeepers.
* New themes can be created easily using SCSS and the basic framework that is offered. The layout should be the same for all themes, but colors, fonts, background images, and sound effects can be adjusted by the theme.
* Theme directory with credit and votes for core bundling?

Feature:Multi-backend support

2015-03-23T18:12:07Z

Administrator: Administrator moved page Feature2:Multi-backend support to Feature:Multi-backend support

Fact: a lot of people think we're crazy for using the IRC protocol as core transport.

In the long run, it would probably make sense to add support for multiple protocols side-by-side. For example, why not have an XMPP group chat next to an IRC chat. That's what Sockethub is for after all. Could even be a Gitter channel or something other that is usually closed-source and centralized. And then we can choose which one offers the best performance and UX for Pro.

Also, as we're building Hyperchannel as componentized app from the start, integrating different transport protocols isn't difficult in regards to the UI integration.

If we add more, we should obviously also think about providing IRC gateways to those other ones, if possible.

== Notes ==

* http://xmpp.org/extensions/xep-0045.html

Feature:Guest communication

2015-03-23T18:11:46Z

Administrator: Administrator moved page Feature2:Guest communication to Feature:Guest communication without leaving a redirect

Status: idea

It's possible to create a temporary room that one can invite guests to or direct them to by their request, for both chat and audio/video communication.

Use cases:

* Invite clients, customers, contractors, or any other person(s) to a meeting/call
* Customer support

Feature:Onboarding / Setup

2015-03-23T18:11:31Z

Administrator: Administrator moved page Feature2:Onboarding / Setup to Feature:Onboarding / Setup without leaving a redirect

== Notes ==

* Have a chat bot that asks questions and uses answers to configure the app for the user (from conversation with David)

Feature:Migration from existing systems

2015-03-23T18:11:16Z

Administrator: Administrator moved page Feature2:Migration from existing systems to Feature:Migration from existing systems without leaving a redirect

== Summary ==

In order to make migration from other systems/services easy and enjoyable, both for just trying out the software as well as transferring all data for a complete org migration to 67P, there will be a subsystem for importing data and configuration.

== Features ==

* Import user names/accounts
* Import channels, including their chat history
* Import shared files

== Migration sources ==

* Slack
* Flowdock
* Campfire
* Hipchat
* IRCCloud
* Grove.io

== Notes ==

* Grove.io has JSON files for single days or complete history. Resource names are guessable/common.

Feature:File sharing

2015-03-23T18:10:56Z

Administrator: Administrator moved page Feature2:File sharing to Feature:File sharing

== Summary ==

67P comes with a complete, built-in file-sharing solution, optimized for the
quick sharing of screenshots, screencaps, documents and other files, both on
public channels as well as in private company channels.

67P also offers a history view of recently shared files per channel, so it is
easy to find something without having to search the chat logs.

When sharing a file in a channel, the Web client uses a nice [[Feature: Chat#Satellites|satellite]] to render the action and a preview of the file.

== Technical implementation ==

File sharing is based on the RemoteStorage protocol. Files are published
directly from the Web client to the remote storage.

In public channels, using one's personal remoteStorage, the files are published
there, while in private channels (pro/paid), files are published to the
organizations storage.

Image thumbnails are created directly in the browser by the
[https://github.com/remotestorage/modules/blob/master/src/shares.js remoteStorage shares] module.
Long-term the module will be extended for creating e.g. file list for zip files
and other preview/summary data.

=== Notes ===

* Share file/image icon button next to text input field?
* Easily share a quick picture from the webcam (can even be animated, e.g. with https://yahoo.github.io/gifshot/)

Feature:Audio/video communication

2015-03-23T18:10:29Z

Administrator: Administrator moved page Feature2:Audio/video communication to Feature:Audio/video communication without leaving a redirect

== 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 ([http://webrtc.org "Web Real-time Communication"]) is used to enable this. WebRTC currently works in Firefox, Chrome, FF and Chrome on Android, Opera and some lesser known browsers (e.g. Bowser on iOS). We might switch to ORTC ([http://ortc.org "Object RTC"]) at some point, which is a lower-level standard that will be supported in Internet Explorer also.

== Features ==

67P RTC is an integrated featuren in HyperChannel. Only direct 1on1 calls will be implemented for now.

=== HyperChannel Integration ===

A video stream (or audio symbol for non-video) will be integrated into the 67P UI (maybe in an extra tab?) You can also "pop-out" this UI component, which makes working on multiple screens easier (and requesting full screen simpler).

=== Feature Ideas for Later™ ===

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

==== 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) - This will be done via IRC or WebRTC's DataChannels.

== 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")

It is implemented on top of the existing IRC channels (via SockerHub) using special message formats, which will get parsed by the HC Client. For backwards compat (later), it could include 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)
...

Feature:Incoming notifications / (web)hooks

2015-03-23T18:08:31Z

Administrator: Administrator moved page Feature:Feature2:Incoming notifications / (web)hooks to Feature:Incoming notifications / (web)hooks

== Summary ==

== Features ==

=== Sockethub Butlers ===

* Incoming Webhook (usually HTTP POST) to channel/storage
** Data formats and message rendering for known hooks/services
** Vanilla hook with defined message format and plain/common rendering for custom services
* RSS feed to channel/storage (detect known types, e.g. MediaWiki recent-changes feed)
* Bitcoin wallet transactions to channel/storage
* Email/IMAP to channel/storage. Would check for emails and parse one or all of sender/recipient/subject/text in order to trigger extracting information and/or post/store to channel/storage.
* Webpage change tracking to channel/storage (check regularly if content on a page changed)
* RemoteStorage resource change to channel/storage

=== Notes ===

* [GitHub] Apparently it's now possible to define a single hook for all activities within an organization: https://developer.github.com/changes/2014-12-03-preview-the-new-organization-webhooks-api/ — that means we might be able to set that once per API/OAuth call and have a single catcher for all GitHub-related things (no more forgetting to configure channel notifications for new repos e.g.). Also, notifications for not just commits, but other activities as well.

Feature:Incoming notifications / (web)hooks

2015-03-23T18:08:09Z

Administrator: Administrator moved page Feature2:Incoming notifications / (web)hooks to Feature:Feature2:Incoming notifications / (web)hooks without leaving a redirect

== Summary ==

== Features ==

=== Sockethub Butlers ===

* Incoming Webhook (usually HTTP POST) to channel/storage
** Data formats and message rendering for known hooks/services
** Vanilla hook with defined message format and plain/common rendering for custom services
* RSS feed to channel/storage (detect known types, e.g. MediaWiki recent-changes feed)
* Bitcoin wallet transactions to channel/storage
* Email/IMAP to channel/storage. Would check for emails and parse one or all of sender/recipient/subject/text in order to trigger extracting information and/or post/store to channel/storage.
* Webpage change tracking to channel/storage (check regularly if content on a page changed)
* RemoteStorage resource change to channel/storage

=== Notes ===

* [GitHub] Apparently it's now possible to define a single hook for all activities within an organization: https://developer.github.com/changes/2014-12-03-preview-the-new-organization-webhooks-api/ — that means we might be able to set that once per API/OAuth call and have a single catcher for all GitHub-related things (no more forgetting to configure channel notifications for new repos e.g.). Also, notifications for not just commits, but other activities as well.

Feature:Design

2015-03-23T18:06:53Z

Administrator: Administrator moved page Feature2:Design to Feature:Design

== Brand / Identity ==

=== Notes ===

== Desktop ==

=== Notes ===

== Mobile ==

=== Notes ===

* http://www.pubnub.com/blog/creating-a-polymer-chat-app-with-material-design/

Feature:Themes

2015-03-23T18:05:52Z

Administrator: Administrator moved page Feature: Themes to Feature2:Themes

Feature: Themes

2015-03-23T18:05:52Z

Administrator: Administrator moved page Feature: Themes to Feature2:Themes

#REDIRECT [[Feature2:Themes]]

Feature:Multi-backend support

2015-03-23T18:05:38Z

Administrator: Administrator moved page Feature: Multi-backend support to Feature2:Multi-backend support

Feature: Multi-backend support

2015-03-23T18:05:38Z

Administrator: Administrator moved page Feature: Multi-backend support to Feature2:Multi-backend support

#REDIRECT [[Feature2:Multi-backend support]]

Feature:Guest communication

2015-03-23T18:05:30Z

Administrator: Administrator moved page Feature: Guest communication to Feature2:Guest communication

Feature: Guest communication

2015-03-23T18:05:30Z

Administrator: Administrator moved page Feature: Guest communication to Feature2:Guest communication

#REDIRECT [[Feature2:Guest communication]]

Feature:Onboarding / Setup

2015-03-23T18:05:21Z

Administrator: Administrator moved page Feature: Onboarding / Setup to Feature2:Onboarding / Setup

== Notes ==

* Have a chat bot that asks questions and uses answers to configure the app for the user (from conversation with David)

Feature: Onboarding / Setup

2015-03-23T18:05:21Z

Administrator: Administrator moved page Feature: Onboarding / Setup to Feature2:Onboarding / Setup

#REDIRECT [[Feature2:Onboarding / Setup]]

Feature:Migration from existing systems

2015-03-23T18:05:13Z

Administrator: Administrator moved page Feature: Migration from existing systems to Feature2:Migration from existing systems

== Summary ==

In order to make migration from other systems/services easy and enjoyable, both for just trying out the software as well as transferring all data for a complete org migration to 67P, there will be a subsystem for importing data and configuration.

== Features ==

* Import user names/accounts
* Import channels, including their chat history
* Import shared files

== Migration sources ==

* Slack
* Flowdock
* Campfire
* Hipchat
* IRCCloud
* Grove.io

== Notes ==

* Grove.io has JSON files for single days or complete history. Resource names are guessable/common.

Feature: Migration from existing systems

2015-03-23T18:05:13Z

Administrator: Administrator moved page Feature: Migration from existing systems to Feature2:Migration from existing systems

#REDIRECT [[Feature2:Migration from existing systems]]

Feature: File sharing

2015-03-23T18:05:07Z

Administrator: Administrator moved page Feature: File sharing to Feature2:File sharing

#REDIRECT [[Feature2:File sharing]]

Feature:File sharing

2015-03-23T18:05:06Z

Administrator: Administrator moved page Feature: File sharing to Feature2:File sharing

Feature: Audio/video communication

2015-03-23T18:04:33Z

Administrator: Administrator moved page Feature: Audio/video communication to Feature2:Audio/video communication

#REDIRECT [[Feature2:Audio/video communication]]

Feature:Audio/video communication

2015-03-23T18:04:32Z

Administrator: Administrator moved page Feature: Audio/video communication to Feature2:Audio/video communication

Feature:Offline support

2015-03-23T18:04:23Z

Administrator: Administrator moved page Feature: Offline support to Feature2:Offline support

Feature: Offline support

2015-03-23T18:04:23Z

Administrator: Administrator moved page Feature: Offline support to Feature2:Offline support

#REDIRECT [[Feature2:Offline support]]

Feature:Incoming notifications / (web)hooks

2015-03-23T18:04:12Z

Administrator: Administrator moved page Feature: Incoming notifications / (web)hooks to Feature2:Incoming notifications / (web)hooks

== Summary ==

== Features ==

=== Sockethub Butlers ===

* Incoming Webhook (usually HTTP POST) to channel/storage
** Data formats and message rendering for known hooks/services
** Vanilla hook with defined message format and plain/common rendering for custom services
* RSS feed to channel/storage (detect known types, e.g. MediaWiki recent-changes feed)
* Bitcoin wallet transactions to channel/storage
* Email/IMAP to channel/storage. Would check for emails and parse one or all of sender/recipient/subject/text in order to trigger extracting information and/or post/store to channel/storage.
* Webpage change tracking to channel/storage (check regularly if content on a page changed)
* RemoteStorage resource change to channel/storage

=== Notes ===

* [GitHub] Apparently it's now possible to define a single hook for all activities within an organization: https://developer.github.com/changes/2014-12-03-preview-the-new-organization-webhooks-api/ — that means we might be able to set that once per API/OAuth call and have a single catcher for all GitHub-related things (no more forgetting to configure channel notifications for new repos e.g.). Also, notifications for not just commits, but other activities as well.

Feature: Incoming notifications / (web)hooks

2015-03-23T18:04:12Z

Administrator: Administrator moved page Feature: Incoming notifications / (web)hooks to Feature2:Incoming notifications / (web)hooks

#REDIRECT [[Feature2:Incoming notifications / (web)hooks]]

Feature:Design

2015-03-23T18:03:58Z

Administrator: Administrator moved page Feature: Design to Feature2:Design

== Brand / Identity ==

=== Notes ===

== Desktop ==

=== Notes ===

== Mobile ==

=== Notes ===

* http://www.pubnub.com/blog/creating-a-polymer-chat-app-with-material-design/

Feature: Design

2015-03-23T18:03:58Z

Administrator: Administrator moved page Feature: Design to Feature2:Design

#REDIRECT [[Feature2:Design]]

Feature:Chat

2015-03-23T18:03:28Z

Administrator: Administrator moved page Feature:Chat to Feature2:Chat

#REDIRECT [[Feature2:Chat]]

Feature: Chat

2015-03-23T18:01:36Z

Administrator: Administrator moved page Feature: Chat to Feature:Chat

#REDIRECT [[Feature:Chat]]

Main Page

2015-03-23T17:26:37Z

Administrator: Protected "Main Page" ([Edit=Allow only autoconfirmed users] (indefinite) [Move=Allow only autoconfirmed users] (indefinite))