RealTimeConf notes

RTConfNotes.txt

;; This buffer is for notes you don't want to save, and for Lisp evaluation.
;; If you want to create a file, visit that file with C-x C-f,
;; then enter the text in that file's own buffer.

disqus used
thoonk, gevent and nginx_http_push to make disqus more "realtime"
https://github.com/NorthIsUp/disqus-realtime-presentation
https://ep2012.europython.eu/conference/talks/making-disqus-realtime
-----

dotcloud has cool tools
zerorpc
js.dotcloud.com
stack.io
-----

social web is the realtime web
social doesn't work when you have to wait 10 minutes for a response
superfeedr is a tool for managing feeds
1. social is b0rked
- you must choose between friends and services
- you like path, all your friends are on Facebook etc...
- we do a lot of stuff, but it's all separated
- you can cross-post but it gives you lots of dupes (annoying)
- we will outlive Facebook (also others)
  -- they'll lose our data
  -- we won't be able to recover it when they do
  -- they want to be your identity/auth
- people choose friends over apps (features/design)
- people choose devices over apps too
  -- mobile OS are gatekeepers
  
2. silos won
- services want to be your one and only web inbox
- auth via FB etc makes websites suck
- API as shackles
3. save the cheerleader (regain what we've lost)
- fork the web!
- you can use your browser to change the web (but not permanently)
- unless you use an extension (run my script always)
- go ahead and add side-effects that do things on your behalf (add new handlers)
- browsers can store your data too (localstorage, Locker, Unhosted)
- put stuff in indexed db in Chrome 
- you can use tcp to access stuff stored in a browser (Websockets)
- decentralizes the social web, establish a protocol for social web with data stored on individual clients (a'la dvcs)
- presence is baked into this model 

https://github.com/julien51/indie-butler-app

-----------------------

The Bilingual Browser
"a delusion offered for sharing"

Statement: I think web browsers should talk xmpp and http natively.
XMPP for web inbox, auth etc
XMPP solves long-polling etc.. that aren't natural for HTTP.
HTTP only is piss-poor for that stuff.

Allows for:
Presence
Micro-content push
 -- knows identity of browser and who to push to
True shared identity
 -- all identity data is accessible through xmpp
Pubsub

----------------------

SPDY
- The Past
http 1.0 in 1996, then 1.1
built for a different web. tiny 60K pages.
today, a lot more, richer content. composed of many resources of many kinds
from many sources.  HTTP has not evolved to suit this.

Round trip time is the thing. There are around 84 requests per page.
Stakes are higher, and RTT means money.

SPDY is a session-lay replacement for HTTP allows multiplexing of connections.
Goals:
- Faster
- More Secure
- long-term: less effort
- but: no guarantees

Header compression:
- headers are compressed
- reduces bandwidth
- 10-25% size reduction for first request
- 80-97% for longer lived connections
- Esp. useful in client to server direction

Pipelining
- Requests can be prioritized
- Use all bandwidth all the time
- Currently browsers manage delay of requesting resources
 - pauses loading/rendering while loading resources
 - bandwidth pipe is underutilized
 - without this, resource contention occurs and rendering is impossible
 - one big burst vs. staggered load
- SPDY doesn't need this
 - can tell you which resources are high-priority
 - browser can forget about request heuristics
 - uses interleaving to allow "simulataneous" delivery
 - high-priority data can "interrupt" low-priority
- Solves hacks
 - file concatenation
 - spriting images
 - domain sharding
 - all unecessary with prioritized multiplexing

Server push
- already here, called inlining
 -- prevents caching
 -- interferes with prioritization
- SPDY server push is better inlining
 -- Pushed resources can be cacheed
 -- Also can be cancelled
 -- we don't need to wait for roundtrip
 -- server push can send the "most important" parts first
 -- just have to put the files in order in server config
- Enables "Silk" and the like to work faster
- you can set a response header that will allow SPDY for browsers that support it

------------------
Removing the suck from websockets so they're better for the enterprise

websocket protocol is pretty old (since 2009)
final in December 2011

Support in many browsers ie10+ (no Android browser)
Latest (RFC) in Chrome 20, FF 12, Safari 6, IE 10+, Chrome for Android

Known issues with Websockets
- Usage or detecting proxy can crash the browser in older Safari and Mobile Webkit
 -- Have to do browser sniffing to get past this
- Writing to a closed websocket will crash safari mobile
 -- use setTimeout (even very small) and socket state will be set correctly
 -- (mobile only)
- 3g doesn't always work with WebSocket, or causes crashes
 -- sniff for mobile
 -- don't use websockets then
- Pressing esc in Firefox will drop the connection, even if the page is loaded
 -- bug has been open for 4 years
 -- e.preventDefault for "ESC"
- invalid UTF-8 can drop the connection (even emojis)
 -- unescape(encodeURIComponent(terribleEmojis))
- Firefox won't connect to non-secure ws:// from https
- Similar is Safari with self-signed
 -- annoying!

There are all sorts of edge-cases with websockets

firewalls, and enterprise proxies block :4000
most block anything other than 80, 443, 843
use those ports, or use flash sockets

virus scanners
out-of-date scanners will block websocket connections
depends on the scanner, some block on non-80 ports, some just block everything
blue-coat proxy blocks all js with "active-x" in source

in the end, about 10% of websocket requests fail

reccos
-------
Always use SSL for websockets
Have fallbacks
 - polling 
 - flash
 - etc..
 - order them correctly, "upgrade" to websockets
Don't use websockets on mobile
 - just poll you dingus!
Educate!
 - check out realtimeplatform.org
 - sharing is caring


---------------------------------

Firebase (@Firebase)
"Do you have data? Does it change?"

- we've got a shitload of awesome tools
- think bigger than input/output
- no longer constrained by hardware you can afford

Firebase is a tool for building full-stack realtime apps without writing 
any server-side code. HTML5, JS.  It's a full-on backend and datastore for your app.

1. real-time synchronization
2. persisten & reliable
3. scales with your data
4. data is accessible
  -- in "cloud" via unique URL
  -- in code
  -- in browser
  -- as REST endpoint

-----------------------------------------

WebRTC is almost here -- CTO from Voxeo/Tropo (Jose de Castro)

WebRTC is a new API for embedding real-time communications into web sites and 
browser-based applications
Access to camera and microphone
P2P camera, microphone, real-time media streaming.
Interoperable codecs, very secure (GVM'T grade encryption), part of w3c 
standards and a native part of the browser.

What's possible
Voice and video chat
specialized chat networks
real-time gaming data
integration with regular phones
live events, journalism
next-gen contact center

Communications Value Chain
- Access
- Identity/Addressing
- Services
- Presentation

Voxeo focuses on Services and Presentation
WebRTC is not forcing a UI on us. There is no phone, but you can make a call.

How does it all work?
2 peers need to exchange some info
- which codecs do they support?
- what's their IP

You'll need to manage this in your application
- receive the request from each peer
- pass the infomation to peers
- negotiate the connection between peers
- use SIP, Jingle (XMPP) or your own protocol
- your site (or Facebook) can pass the connection blob through their own methods

Not just video chat, any live content can be pushed in real time from peer to peer.
Big shit-fight over video codecs (webm (royalty-free) vs. h.264 (patents, $$$, not GNU friendly))

check out
<video><audio>
GetUserMedia
PeerConnection API
DataChannel API

RTP/SRTP
SDP
ICE/TURN
Opus Codec
DTLS

Try it out in Chrome 24, IE, Firefox soon, Safari follows
Watch out for boot2Gecko (Firefox OS, HTML5 + JS atop Android kernel)
Maybe even Android by next summer

Evolving standard get involved.
Try out phono, built frame upon webrtc that falls back to other things (Java, Flash etc..)

------------------------------------------
Realtime is not just for the web.

Telephony.
Mobile handsets are ubiquitous world-wide where home computers are not.
In the dark ages we had proprietary islands of functionality to run
phone networks. No API.

VOIP is a reaction to this. Frees us from big expensive boxes.
Also nicer clients help too (iPhone, software etc)

Convergence and the beginning of unified communications. 
WebRTC and open architecture are encouraging democratization of communication platforms.
Federation, Multi-modal integration (voice + video + text + presence all at once in one session)
Seeing more collaboration amongst interested parties.

What's voice application?
Starts with an audio stream.
Can connect disparate applications.
Goes beyond a phone call.

examples:
live translation service over the phone or data
automated reminder calls
mid-call assistive services
 - bring people in during a call
crm integration
over-the-top services of any variety

telephony doesn't have to be hard
Adhearsion -- ruby approach to telephony applications
Voice Application Framework

Adhearsion sits in the middle, drives a telephony engine and connects it to
whatever thing you'd like that Ruby can connect to.

Hosting flexibility -- you can host anywhere they will run Ruby.
Will run on anything UNIX based. 
Gives you the ability to interact between calls.
(drop in and out of calls)
Simple, extensible API. And it's a real project!
"gem install adhearsion" and go?
Not really Asterisk, FreeSwitch and PRISM are still a pain to set up.
Connectivitiy is PITA
Cloud deployment platform? Sure? adhearsion.com/cloud

WebRTC democratized real-time voice & video communications
but encourages silos
need to integrate with public networks
allow a range of endpoint capabilities
adhearsion makes a good web-thingy for webrtc
adhearsion does not directly handle media or signals
purely a 3rd party control component driving VOIP
Speaks Rato based on XMPP
supports accessing federated voice networks

try it out! MojoLingo builds this stuff.


---------------------------------------------
Fred Cheng (simperium)
Simperium is a hosted platform for synchronizing data

Sync + Transforms

Operational Transforms -- a set of transforms to support collaboration
Operations describe change from one state to another
Application should generate ops
Intercept application events
diffs can be used to generate operations

--------------------------------------------
The State of Realtime at &yet
as it pertains to And Bang 2.0

What are Web Apps really?
Web apps are hosted services that are good at some particular kind of data.

Your API is core to your offering. Everybody builds REST APIs for this.

Shortcomings to HTTP + REST?
How do you link one existing object to another?

Web API is not necessarily REST
APIs are sets of functionality.

What do we want from an API?
Multiple ways to get data in and out (transports, formatst)
Simple unified auth (settle for OAuth)
The official app ought to be just another client of the public API
Full data eventing (if something happens clients should know)

What about realtime?
HTTP doesn't do push.
Websockets
ServerSent Events
XMPP
Socket.io
Long-Polling
Animated GIF-Straming?!?


Throw REST+HTTP out? Nah.
HTTP is just one type of transport for your data.
APIs are functions, HTTP+REST is just one transport.
Adapters/transports to the one true API.

Build a spec
Build everything off of the spec



=========================================

Meteor w/Meteor dude Matt
-------------------------

Meteor is a JS app framework that makes it "dramatically easier" to write web
applications.

What we've learned
-------------------
Apps are moving to the client (this is sort of old skool)
- massive architectural change!
-- google docs is not a port of ms office
-- old desktop protocols/tools/languages are not as strong
-- business model is different
-- web has brought a new set of tools
-- HTTP/REST other fundamentals are less critical in the real time web
--- new shit is coming
--- opportunity to build new standards
-- data on the wire makes client side apps


What comes next
---------------
-- client-side cache
--- with app on the client we have a latency problem
--- you have to wait for data from the server
--- pre-fetch, cache
--- cache invalidations (still hard) - server pushes new data
-- remote methods
--- clients should call semantic methods (not necessarily RESTful)
--- would be nice if the method would update your local cache immediately
--- that way you don't need to wait for the server response
-- there's no standard wire format! (bummer)

DDP
----
--- wire protocol used in Meteor stack
--- servers publish sets of documents
--- clients don't necessarily need to ask
--- subscribe, and servers will set/unset documents in your client
--- sub and unsub
--- clients call methods on remote server
CALL upvotePost 1 [f2548c]
RES f2548c "okay"
--- tie subscriptions and method calls together
--- server will tell you when all your data has arrived on the server
--- methods should run once and only once (once per message semantics)
if you disconnect and call the same method again, server will just send you
the response without running the method again
--- Hey look! A real time API (pub/sub with remote method invocation)
--- does interoperability real good! Not specific to JS
--- you get common tooling between front and back end
--- you can build really interesting real-time apps fast and not worry about
cache invalidation.
--- keep it simple and it will be rad
(check DDP out: http://meteor.com/blog/2012/03/21/introducing-ddp)

JS is kinda sorta homoiconic which makes this pretty cool when implemented that
way. Clojure is also homoiconic, so that rocks too (CJScript + CJ)
==========================================================================

Owen Barnes -- SocketStream
----------------------------
- a node framework for single-page apps
- all data comes over a websocket 

3 phases of web
----------------
Static
 -- don't do shit
Dynamic
 -- snapshot
Realtime
 -- responsive, not a snapshot

"Why no use Socket.io?"
- you can, transport layer is swappable


=============================================================================

Daniel Shaw - Observability for node & realtime software (at scale)
@dshaw
voxer
-------------------------------------------------------------------
Observability is pretty hard esp at scale
-- you can't grep that 
Realtime app priorities
- Scalability
- Observability
Scale is why we build realtime apps. Observability is how we mainain the scale.
Sometime things get out of control, we should know what's going on.

Tools
-----
- logging
  don't be afraid
  limiting logging is a premature optimization
  but you can go too far
  too much noise, too much serialization of large objects
- heartbeat/health/status endpoints
  memory, uptime, version, pid, connection etc...
  (not specific to node, but we've got some nodey examples...)
- REPL
  node supports REPL because it's JS, you can drop in an observe state
  (use a socket). Other languages do that too.
  Restart loses those insights.
  (there's a node module called replify for doing this in node)
  domain sockets are good if you want everything to be secure, but you can use
  tcp if you like

aggregates and lossy things....
- log aggregation
  loggly
  graylog2
  splunk
  winston(d)
  files + grep (hahaha)
- monitoring
  boundary
  nagios
  reconnoiter
  ciconnus
  munin
- metrics
  statsd
  mockingbird
  something new from voxer...
  llquantize will give you many insights
  tell a story with visualization, comparative analysis, system health, 
  event triggers
- DTrace
  http://en.wikipedia.org/wiki/DTrace

all of this onservability is constantly growing, ongoing, neverending story
great photo of paula deen riding that dog thing

====================================================

Lightning node.js dev
---------------------
This cat writes node at MS(Glen Block @gblock)

apps and (node apps) are moving to the cloud
azure can do all the things their competitors do, recognize
this is essentially an ad for Windows Azure. Hey it does all that stuff Heroku does.
Node!

deploying node fast and continually to azure!
azure cli allows for deployment via Git a'la Heroku
========================================================

Peter Saint-Andre -- Jabber, CISCO, presence
--------------------------------------------
presence!
presence is key to IM.
The original real-time tech.
XMPP/Jabber has been around since 1999.
(Extensible messaging and presence protocol)

XMPP has generic pubsub, and pubsub for presence
presence is availability, attention, focus etc...
security is important -- SSL/TLS is not enough
internationalization matters (Unicode/UTF-8 is not enough)
federation matters
 - single service silos provide a single point of failure
decentralized tech is the Right Way

is presence still relevant?
- yes but not so exciting
- key for un-social apps like IM and collaboration (1 on 1)
- trigger for spontaneous or intensive interaction
- presence is now stable and well known via XMPP
- opportunities still exist

not just for people
- machines can have presence to
-- components, bots, etc...

challenging to manage multiple presence endpoints
- needed: better client-side composition and presentation for presence
- like: superfeedr for presence

we can build on presence
- augment with device capabilities
- extended presence, ambient info, mood, geo etc...

more interaction  in mobile and web
- more and better presence in mobile apps
- per-app presence in browsers
- XMPP over websocket

don't be scared by the x in xmpp
- angle brackets not required
- easy to use web apis

too many people are working synchronously
- sending shit over e-mail
- builing more interactive ways to work together

presence + rtc is a big opportunity
big silos have good presence, but your app has it too
don't be a small silo
use xmpp to share presence across domains
federate or die, share presence across borders with open protocol
presence is the dialtone for realtime internet
catalyst for realtime interaction and byproduct of realtime interaction
we've solved the problem, use XMPP

============================================================================

Re-thinking OAuth (or fuck OAuth)
---------------------------------
this dude doesn't like cats
can't apologize enough for OAuth

Why does OAuth suck?
- OAuth1 doesn't use https
- no user metadata
- lame requirements
 - php4 compatible
 - worlds worst hosting (no https)
 - good enough for google to deploy (secure)
 - not openid!

Pain
- signatures
- broken libaries
- provider extensions
- crappy spec

The scam
- promote no signatures
- require token refresh
- signatures < stateful client
- roundtrips required

Why does OAuth2 suck
- not a protocol
- too extensible
- refresh tokens
- no interoperability
- framework (not protocol -- breaks interoperability)
- assertions (saml, jwt)
- no signatures (they could be not so bad now)
- hosted applications centric (doesn't care about mobile, native or browser apps)
 -- server hosted, server rendered html apps

Why did this happen?
- YOU! (you keep using)
- enterprise (motivated by whack requirements)
- MS and Google (consumers aren't represented, weird use cases, wouldn't allow for strictness)
- openid (couldn't make openid incompatible changes)
- ietf (organization is turrible)

Security (Theater)
- Public clients
-- no secrets
-- url hijacking
-- malware
end up with terrible stuff like webviews for OAuth authentication
custom schemes (for redirecting to app) get stepped on
android solves this with choice dialog, but iOS doesn't
webviews can steal user/pass anyhow, so it's actually not secure
just give the app user/pass

Bearer tokens
- client side enforcement
signatures tend to solve this problem
- no client bindings
token is not bound to client
2 apps can share the same token, for example
(if you can get a valid token, you can use it in any client)
facebook added custom exception to solve this (fuuuuuck)

What should I implement?
- NO good answer
- OAuth1 doesn't scale for large orgs
- OAuth2 needs security expertise to make it effective
 -- need to add secret sauce on top of token
 -- derive encryption key using salt1
 -- derive mac key using salt2
 -- generate random iv
 -- encrypt then mac(salt1 + iv + data)
 -- transmit salt1,2 iv and encrypted

Oauth1 was success because of community
Standards make things worse for something like this
- $ centric
- ipr bullshit
- unaccountable leadership
- takes for-fucking-ever
 -- 3 years for OAuth2 spec
 -- okay for JS, where stability is important


New solution!
OZ
- OSS
- implementation first
-- working implementation, then spec after
- consumer centric web
-- fuck the enterprise, nobody cares
- allows for mobile and native
-- design for things that people actually use
- realtime & support beyond HTTP
-- don't bing to protocol

outline
- user/pass on native
- Oauth 2 flows are optional
- auto configuration
-- changeable, not compiled into applications/servers
- encapsulated tickets

lower expectations!
- nothing here....
- looking for contributors
github.com/hueniverse/oz

Eran Hammer (@eranhammer)

==================================

Johnny-five is node module for arduino
so you can arduino with node, and use websockets to send things back and forth
https://github.com/rwldrn/johnny-five


=====================================
Brian Beggs - EnerNOC (Enabling EnerNOC's Realtime Data)
---------------------------------------------------------
Smart Grid + Green Energy
Shut your shit off.

Grid operators need to be able to meet peak demand
can't just bring on a new plant
spinning reserve plants are very dirty
EnerNOC gets $ from grid operators and splits it with consumers for shutting shit off.
Looking into building small meters

Why is this cool realtime stuff?
We have to know who is using electricity where at any time.
4 million readings/day processed persisted and ready for use.
Not just DR data, but efficiency occupancy and weather too.

data needs to be realtime and fast, so we known shit is being shut off.
have to reconcile with grid operators and other stakeholders.

Past
----
Software is actually super duper old.
Oracle, flex, jboss, seam (crappy old Java shit)
Beholden to Oracle in a big way
Hardware is not great either, SDKs are rought, access to OS is restricted

Future
-----
New hardware
focus on componentizing systems, using contributing to FOSS, right tool for the job, not the tool you're accustomed to, build good products, not just meet requirements
moving to ruby, python
bummers: highly regulated, interfacing with clients that aren't moving at the same rate
Need to be highly reliable

First!
New hardware
reduce installation time and cost, and add wirelessness (meter runs embedded linux, python, and use xmpp for presence)

XMPP enables smart clients, bi-direction comm. easy way through client firewalls
- widely used and understood
- file transfer is backed in 
- very easy to extend
- SleekXMPP

Some challenges with xmpp
- 90% of installations are cellular
- socket tends to fail silently
- since xmpp messagse doesn't get a response, might be writing to a black hole
- XML (it sucks)

Dealing with it
- small name spaces, taga dn attributes
- periodic ping to server to ensure connection during inactivity
- implemtn xep-0198 stream management gets you acks for messages
- set custom timeouts for send and receive at socket level (Python!)

New data storage
- relational dbs are whack
- storing time series or logging, pretty slow, indexes grow larger than data
- doesn't shard so great

non rel with Mongo
- sharding just works
- suited to the type of data
- bucketing
- small keys
- pre-allocated stub docs
- hashed ids for data locality

now can provide an api for the meter data
- provides on-the-fly aggregations of data
not really realtime

workflow
--------
client connect to node server with socket.io
click on point or site
new request to hardware is sent, and realtime data gets sent back

You can see shit getting shut off in real time

you can disrupt even in the enterprise, hire right people, use the right tools

(check out sleekXMPP https://github.com/fritzy/SleekXMPP)

===============================================================
Bob Wyman (lightning talk!)
---------------------------
demo app, frackim (Prospective Search)
relational (retrospective) databases  -- in the past, have you seen this thing?

realtime -- not interested in the past, you want to know what happened.
prospective database indexes queries, to tell you what's going to happen.
completely different set of technologies.

everything that was in pubsub.com (100s of Ks LOC), now about 100 LOC (with app engine)
=================================================================

Luigi Montavez - Deep Dive into Server-Sent Events
--------------------------------------------------
Part of HTML5 now
Try 'em you'll like it

Realtime updates to the web, no page refresh
long polling is a hack, and is a sucky way to implement comet

Websockets
tcp browser -> server, bi-directional. low level, you must define protocol.
you can do xmpp, irc, amqp, vnc or whatever
no js polyfill, gotta fallback to flash or simliar

Server-Sent events
forgotten sibling of websockets
push only, downstream server -> client
browser handles reconnections
no need for flash fallbacks (js polyfills exists for shitty browsers)

Use-cases
stock ticker, analytics, twitter-style social feed, notifications from server

Implementing in the browser
---------------------------
var source = new EventSource("/stream");
source.addEventListener("message"....);
source.addEventListener("open" ...);
source.addEventListener("error"...);

listeners take event e, and can use e.data (message contents). You could send a string or maybe even a JSON object.
also includes retry, id, and event
browser will pass last event id to server so we can replay events that we missed
retry determines retry interval in millis
event is an event type, so you can add listeners for that type of event

all browsers 'cept android browser and IE support it
good news!
there are polyfills for those browsers that have no support
(github.com/remy/polyfills github.com/Yaffle/EventSource github.com/rwldrn/jquery.EventSource)

CORS support coming soon! (plus polyfills support it already -- in FF and Opera, Patch in for Webkit)

On the server
-------------
accept text/event-stream header in request
look for the path to your sse path, then send the event

response is "text/event-stream", send id, event, and data in payload

pretty simple in node, can be done in other things too (construct and send JSON)

Rails 4 does it too! (examples)
(django-sse is a thing for real people like us to use)
Ship it!

good bridge technology, provides a sprinkling of realtime downstream push to conventional webapps
simple, easy to implement, anti-complexity philosophy

================================================================================================

Also I took come real notes with a pen as my computer ran out of batteries. They are pretty much just about Node and Ruby specific stuff, though the Ruby stuff is neat because it deals with GIL circumventing Ruby implementations and nice concurrency patterns.