CloudServices/Roadmaps/Presence/Meetings/notes 20131031
From MozillaWiki
< CloudServices | Roadmaps | Presence | Meetings(Redirected from Services/Roadmaps/Presence/Meetings/notes 20131031)
participants:
tarek - services
ckarlof - Identity FxA
sam - Identity FxA
ben - Services
jed - Identity FxA Stormtrooper (TK-421)
jr - Services protocol monkey
nchapman - Services/XMPP
telliott - Services monkey wrangler
ozten - Identity demigod
Ed - QA manager for services
jbonacci - QA
Agenda
Q: What does "Presence" mean and how can we solve the problem?
* Findings so far:
Talkilla
Uses Persona Auth
No privacy (one server=one big chat room)
Ad-hoc long polling presence/signalling server <- might move to websockets one day
see https://github.com/mozilla/talkilla/blob/master/server/presence.js#L220 for the APIs
More a test bed, not really built to scale yet.
Once you connect, you see all connected to that server.
https://talkilla.mozillalabs.com/ (if you want to try it)
Chat Simply
ad-hoc authentication
uses BOSH and XMPP
Long Poll server
provides group chat and 1-1
Privacy ?
has to deal with a lot of these issues.
Loqui.im
multi-protocol chat system (xmpp, gtalk, etc)
for FxOS
very interested to moving to use more Fx tech (simple push, websockets, Persona)
does this have a cloud service component or is it just a client?
BigBlueButton
Sip client / based on FreeSwitch on the server
Second WEbFFD from spain.
Video conf tool , chat, share stream.
started as Flash, moved to WebRTC
Using SIPml5.js (SIMPLE?) - moving to WebRTC (http://code.google.com/p/sipml5/)
http://demo.bigbluebutton.org/
So, where next?
Max ~200K sockets per box for AWS
Issues with socket longevity
Intercommunication between CoLos can be a challenge.
ChatSImply:
Had opportunity to use websockets, but continued to
use long polling because websockets:
Issues with AWS
issues with routing and other elements
back then mobile browsers didn't support websockets
long polling works very well and is reliable.
Blong polling is costly:
each message causes connect/disconnect.
Sockets between clients can work well. Sockets to the server has had many problems. AWS limits you to 200K inbound connections. Short term connections can work. The 90% use case where there isn't a ton of traffic, long polling is sufficient. Use a socket when your doing Video or have active large traffic.
Many problems may be already solved in XMPP spec.
PubSub deeply built in.
personal eventing protocol
Pub/Sub for any event
On new event; can get an item
carrier can use long polling or websocket.
should we implement this or part of the XMPP protocol
Trying to segment XMPP traffic is a challenge.
XMPP has benefits and challenges.
Is there a list of use cases or requirements?
* How could we have Talkilla and ChatSimply partisipate in the same presence service?
*
Systems are completely sep. only common element would be the presence server.
How hard would it be to change an existing system to use the service?
How to make it so that chat simply doesn't have to run or need to run it's own contact system, but can get it from a common service?
All contact info is transient for chat system.
Further, could we provide a UI service that lets the user select and browse contacts
(e.g., selecting recipients of a message)
without revealing to the chat app (or whatever app) the contents of my contacts
but only the selected choice in the end
Having Presence use Persona, user could specify a different Persona for each cluster.
Persona lets you use a different id per site.
Users need to be able to control which contacts are exposed to which apps, so the can segment presensce. Respect user's privacy.
Federation is very important. Should focus on that.
Where to put FxA in the picture.
https://wiki.mozilla.org/Identity/Firefox-Accounts
Is FxA providing User Info (name, etc.)
Providing in the future.
Possible application of presence is huge.
(pushing updates to friends, who's online to chat, where I am, etc.)
encapsulated and controlled by FxA
so "Yes"
Contacts service on it's own would be valuable.
Not "FxA will implement Contacts, but will enable a contact service existing."
PICL for sync
Intention is FxA to hold very little user data
Makes other things go.
Services related to user password, really don't want to store user data
(Avoid Yahoo UserDB problems, It became a kitchen sink for EVERYTHING)
May provide VERY small set of common data (user name, email?, avatar?), but not a dumping ground.
10K perspective
Identity, Authorization == FxA
nb, FxA uses BrowserID protocol, like Persona, so auth is not a huge change for anyone
Possible Tasks:
Build a chat app?
Contact/address book? On the server vs UA?
Does this already exist?
https://developer.mozilla.org/en-US/docs/WebAPI/Contacts
https://mxr.mozilla.org/mozilla-central/source/dom/contacts/fallback/ContactService.jsm etc
Is there a low level r/w API? Can this be synced? etc.
Building a webapp means you want to store on server, but can use new tech.
Biggest drawback:
Can do big imports, but the contact data doesn't stay the same between devices.
Contact service would be useful.
Kinda useful for presence server as well.
Should create another non-chat type app.
Server to server app.
try to build something to standardize on.
Semi-federated
Facebook can talk XMPP, but not federated
Google shutting down public XMPP
SimpleChat asks Contact/Presence system "Who of the user's contacts are online"? It can treat this data as transient.
Does it make sense to keep the two APIs (Contacts, Presence) seperate?
Use case
Contacts & Presence..
Seem to be building the basics of Facebook Platform
Need a way to pre-emtptive grant access to apps and contacts (permissions)
Have some of the parts for this.
Can sign in with persona and use content,
no way to grant access or delegate auth.
Web activities for social services?
Do we need a permissions service?
Is this already defined or created?
Web Intents & activities?
May need to be more fine grained than FxA
How to apply to federated systems without a lot of ugly bouncing between systems.
Would folks run whole stack or bits of it.
In a single "go" grant bearer tokens for each serivce.
Should we use token server?
trade FxA token with timed auth token for interconnection.
e.g. this token will allow these services and these permissions for this period.
Difference between FB Need access to Contacts and ours "need access to a service that will return me a list of contacts"?
Provide data while providing invisible privacy (so that users can't complain about it)
Want to avoid "you are being sold" approach or feeling.
* Common apps problems
* Project Goal:
? A system allowing one to share when they'reonline engaged in an activity with others, and see when others allowed associates are doing the same, and facilitate near real-time interaction.
I would put Persona as the central thing . e.g. "a presence service that can be used by any
application on the phone - so we can federate presence around Persona."
Maybe a first experiment would be implementing a subset of XMPP for presence/signaling ?
e.g. http://xmpp.org/extensions/xep-0163.html
tarek - services
ckarlof - Identity FxA
sam - Identity FxA
ben - Services
jed - Identity FxA Stormtrooper (TK-421)
jr - Services protocol monkey
nchapman - Services/XMPP
telliott - Services monkey wrangler
ozten - Identity demigod
Ed - QA manager for services
jbonacci - QA
Agenda
Q: What does "Presence" mean and how can we solve the problem?
* Findings so far:
Talkilla
Uses Persona Auth
No privacy (one server=one big chat room)
Ad-hoc long polling presence/signalling server <- might move to websockets one day
see https://github.com/mozilla/talkilla/blob/master/server/presence.js#L220 for the APIs
More a test bed, not really built to scale yet.
Once you connect, you see all connected to that server.
https://talkilla.mozillalabs.com/ (if you want to try it)
Chat Simply
ad-hoc authentication
uses BOSH and XMPP
Long Poll server
provides group chat and 1-1
Privacy ?
has to deal with a lot of these issues.
Loqui.im
multi-protocol chat system (xmpp, gtalk, etc)
for FxOS
very interested to moving to use more Fx tech (simple push, websockets, Persona)
does this have a cloud service component or is it just a client?
BigBlueButton
Sip client / based on FreeSwitch on the server
Second WEbFFD from spain.
Video conf tool , chat, share stream.
started as Flash, moved to WebRTC
Using SIPml5.js (SIMPLE?) - moving to WebRTC (http://code.google.com/p/sipml5/)
http://demo.bigbluebutton.org/
So, where next?
- communication apps
- mostly based on XMPP
- based on LongPoll currently, moving to websockets.
- tech
- websockets are (almost) everywhere now
- Multi-platform (client list)
- May need both websocket and long-polling to handle desktop and mobile (or is this only for mobile?)
- apps are moving away from long polling techniques to using websockets
- websockets are (almost) everywhere now
Max ~200K sockets per box for AWS
Issues with socket longevity
Intercommunication between CoLos can be a challenge.
ChatSImply:
Had opportunity to use websockets, but continued to
use long polling because websockets:
Issues with AWS
issues with routing and other elements
back then mobile browsers didn't support websockets
long polling works very well and is reliable.
Blong polling is costly:
each message causes connect/disconnect.
Sockets between clients can work well. Sockets to the server has had many problems. AWS limits you to 200K inbound connections. Short term connections can work. The 90% use case where there isn't a ton of traffic, long polling is sufficient. Use a socket when your doing Video or have active large traffic.
Many problems may be already solved in XMPP spec.
PubSub deeply built in.
personal eventing protocol
Pub/Sub for any event
On new event; can get an item
carrier can use long polling or websocket.
should we implement this or part of the XMPP protocol
Trying to segment XMPP traffic is a challenge.
XMPP has benefits and challenges.
Is there a list of use cases or requirements?
* How could we have Talkilla and ChatSimply partisipate in the same presence service?
*
Systems are completely sep. only common element would be the presence server.
How hard would it be to change an existing system to use the service?
How to make it so that chat simply doesn't have to run or need to run it's own contact system, but can get it from a common service?
All contact info is transient for chat system.
Further, could we provide a UI service that lets the user select and browse contacts
(e.g., selecting recipients of a message)
without revealing to the chat app (or whatever app) the contents of my contacts
but only the selected choice in the end
Having Presence use Persona, user could specify a different Persona for each cluster.
Persona lets you use a different id per site.
Users need to be able to control which contacts are exposed to which apps, so the can segment presensce. Respect user's privacy.
Federation is very important. Should focus on that.
Where to put FxA in the picture.
https://wiki.mozilla.org/Identity/Firefox-Accounts
Is FxA providing User Info (name, etc.)
Providing in the future.
Possible application of presence is huge.
(pushing updates to friends, who's online to chat, where I am, etc.)
encapsulated and controlled by FxA
so "Yes"
Contacts service on it's own would be valuable.
Not "FxA will implement Contacts, but will enable a contact service existing."
PICL for sync
Intention is FxA to hold very little user data
Makes other things go.
Services related to user password, really don't want to store user data
(Avoid Yahoo UserDB problems, It became a kitchen sink for EVERYTHING)
May provide VERY small set of common data (user name, email?, avatar?), but not a dumping ground.
10K perspective
Identity, Authorization == FxA
nb, FxA uses BrowserID protocol, like Persona, so auth is not a huge change for anyone
Possible Tasks:
Build a chat app?
Contact/address book? On the server vs UA?
Does this already exist?
https://developer.mozilla.org/en-US/docs/WebAPI/Contacts
https://mxr.mozilla.org/mozilla-central/source/dom/contacts/fallback/ContactService.jsm etc
Is there a low level r/w API? Can this be synced? etc.
Building a webapp means you want to store on server, but can use new tech.
Biggest drawback:
Can do big imports, but the contact data doesn't stay the same between devices.
Contact service would be useful.
Kinda useful for presence server as well.
Should create another non-chat type app.
Server to server app.
try to build something to standardize on.
Semi-federated
Facebook can talk XMPP, but not federated
Google shutting down public XMPP
SimpleChat asks Contact/Presence system "Who of the user's contacts are online"? It can treat this data as transient.
Does it make sense to keep the two APIs (Contacts, Presence) seperate?
Use case
Contacts & Presence..
Seem to be building the basics of Facebook Platform
Need a way to pre-emtptive grant access to apps and contacts (permissions)
Have some of the parts for this.
Can sign in with persona and use content,
no way to grant access or delegate auth.
Web activities for social services?
Do we need a permissions service?
Is this already defined or created?
Web Intents & activities?
May need to be more fine grained than FxA
How to apply to federated systems without a lot of ugly bouncing between systems.
Would folks run whole stack or bits of it.
In a single "go" grant bearer tokens for each serivce.
Should we use token server?
trade FxA token with timed auth token for interconnection.
e.g. this token will allow these services and these permissions for this period.
Difference between FB Need access to Contacts and ours "need access to a service that will return me a list of contacts"?
Provide data while providing invisible privacy (so that users can't complain about it)
Want to avoid "you are being sold" approach or feeling.
* Common apps problems
- how can an application integrates seamessly in a FFOS phone ecosystem
- how can all the apps share the same presence service
- can we deal with presence separately from contacts ?
* Project Goal:
? A system allowing one to share when they're
I would put Persona as the central thing . e.g. "a presence service that can be used by any
application on the phone - so we can federate presence around Persona."
Maybe a first experiment would be implementing a subset of XMPP for presence/signaling ?
e.g. http://xmpp.org/extensions/xep-0163.html
