CloudServices/Roadmaps/Presence/Meetings/notes 20131014
From MozillaWiki
< CloudServices | Roadmaps | Presence | Meetings
JR is taking notes at the bottom
Agenda
See if we can get some more ideas and comments.
Presence designs thoughts:
Some use cases
Use case #1 - a chat app on Desktop (talkilla v.1)
-> See talkilla doc
Use case #2 - Big Blue Button
Use case #3 - a chat app on Firefox OS
Bob starts his phone and log into his account. That sets his presence to "online" via the presence service. The notification service is also started so Bob can be notified. Bob has a contact list on his phone to keep all his friends. A contact is an e-mail.
Bob starts the chat app. The app looks into Bob's contact list and uses the presence service to update its UI. It also hooks itself to the notification service to answer on any SIP request.
Bob wants to talk with Sarah. Bob starts a chat window . The chat app sends a request to Sarah via the notification system using her e-mail.
On Sarah's phone, the event is received, and the chat app is started. Sarah accepts the chat and a session is started.
Open questions:
tarek asked to find all the overlapping projects that seem to want to do presence.
Found various groups
INcluding big blue button
Presence / webrtc
chat simply (nick?)
Round Table:
Tarek - services = interested in RTC and Presence make sure we have most folks involved.
jr - services =
nick - Chat Simply = xmpp project with experience.
rob - project mgmt = Director of user serivces/ sync/ firefox accounts internal customer cloud user
Ian - together.js = collaboration script and pre-existing messaging "How do deal with presence? How do you ensure you're talking to who you think you're talking to?' focused on consumers and what they are doing/wanting. Use cases around how they connect and use. Other use case Anon connect to a developer? are there people in a group? (admin control /privs?) Mentor relationships. Open access and connect.
ryan - services = made the mistake of suggesting presence is not the same as messaging. Has some experience and research in various existing protocols
Mark - demigod = where do we enable various tech. Talking with various groups and projects Talkilla/ tincan / firefox accts. (single sign-on for mozilla projects) Stuff gets complicated then generic then poorly done. Need to understand various audiences and their needs. "Let humans comminicate" is a bit broad, so how can we realistically deal with that? Do we stick presence on FFx Accts?
(Not at meeting) Mark Banner - Talkilla Development lead. Interested in a wide presence system, but in q4 we need to have at least a basic system in talkilla.
Existing Systems:
SimplePush: ability to talk to wake remote systems
Big Blue Button:
Agenda
- round table, who's who
- overview of Simple Push [jrconlin] see -> <a href="https://etherpad.mozilla.org/ServicesPresence">https://etherpad.mozilla.org/ServicesPresence</a>
- overview of Talkilla, next steps [mark banner]
- Softphone system where you can connect to another app
- allows talk, video, etc.
- kind of like together
- p2p connections
- either repeat messages
- or use server as repeater
- want to ship for Q4, with Q1 being several K people using.
- Targeted to making virtual phonecalls with virtual SIMs, etc.
- overview of Chat Simply [nick chapman]
- Web based group chat system.
- based on XMPP features
- built on lot of tech
- ejabberd on backend
- strophe.js for communicating with BOSH (Jack Moffitt jmoffitt@mozilla.com)
- BOSH for interfacing with XMPP.
- Semi-custom node.js server for doing iOS push notifications.
- XMPP has various types of presence
- send a presence msg as you go online
- resource has an identifier.
- Allows multiple connect to a common device.
- messages delivered as subsription
- jabber sees who you're subscribed to and what state of subscription
- connected
- First message goes to all nodes of a given ID
- subsequent messages go to specific node of a given message
- What could browser do to make things easier?
- User interface features
- Desktop Notifications
- Improve the user experience.
- Lot of work to set up all the bits.
- User interface features
- Once all set up, it works very well.
- WebRTC fixes most of the shortcomings...
- Web based group chat system.
- overview of BigBlueButton [tarek]
- No demo :(
- Video
- same goal as application to do video meetings
- Started in flash
- previously in webFWD
- Moving from flash to HTML5 / WebRTC
- Using SIP for everything.
- FreeSwitch (does most of the presence stuff)
- Using js library (<a href="http://sipml5.org)">http://sipml5.org)</a>
- Long term goal is to be based on HTML5
- Have some pieces that are shared
- Located in Ottawa
- Tarek to send email asking for input. (received it -- Fred)
- overview of TogetherJS if Ian is around
- One of the constraints is that they want to do this all with standards so accessible from older browsers.
- Connecting with individuals
- lots of messaging systems no need to duplicate.
- creating something that is usable and simple to work with or don't have great APIs.
- How can we have less work to do with Together?
- Kinda punted.
- mostly scrappy work done for the time being.
- overview of SocialAPIs if Shane is around
- Presence in the app vs Presence as a service
- One thing that's different is that after establishing a session, you don't need to do presence exchange.
- You're connected, pretty present.
- one idea is to push the social graph down to the user / and isolate the presence info on the server - so we don't break privacy between apps+groups
- browser/app maintained presence
- Possibly have an alias that defines a group (for public lookup)
- later it might be possible to exchange individual contact info for closer relationship.
- browser/app maintained presence
- Does it make sence to do something outside of what apps are already doing?
- Product idea to do messaging app inside of firefox os
- Folks will want/expect it. need to provide it.
- what do we need on ffxos?
- tied to firefox accts.
- 100MM+ users with single signon,
- Maybe hang presence off of that.
- 100MM+ users with single signon,
- Afraid we may build tech nobody wants.
- tied to firefox accts.
- One thing that's different is that after establishing a session, you don't need to do presence exchange.
- Desktop vs Firefox OS
- Very fuzzy about what's needed between both platforms.
- Are we going to build this at the FFOS level or desktop first?
- (see use case #3)
- bricks to add to FFOS
- Are we headed there or will we stay with webapps that are not integrated?
- Talkilla already being added as an addon
- What's the end user problem we're trying to solve?
- what's the value prop?
- Lots of folks on browsers, not that many with phones.
- There's nowhere we can't go, but need compelling reason to go there.
- desktop: from working thing to widely available.
- Very fuzzy about what's needed between both platforms.
- ...
- Next steps to investigate
- Is there value in having global "presence" service?
- App can deal with lots of clients, and the central server deal with state of user?
- Has some way to state a unique id for a user.
- Is availalbe? how to contact? is app blocked?
- how to provide user control
- Server really has to know user state
- Probably should have some central infromation
- DNS like service?
- Can do simple string lookups, salts, etc.
- masked for privacy scaling
- XMPP allows federated protocols
- Do we need to mock code?
- Not sure, have we defined something new and not provided?
- What issues are at play?
- Can we reduce the number of constant connections
- mobile devices have a hard time dealing with fast connections (TCP issues)
- May want to use UDP vs. TCP
- May want to use UDP vs. TCP
- Is there value in having global "presence" service?
See if we can get some more ideas and comments.
Presence designs thoughts:
- <a href="https://etherpad.mozilla.org/ServicesPresence">https://etherpad.mozilla.org/ServicesPresence</a>
- <a href="https://id.etherpad.mozilla.org/presence">https://id.etherpad.mozilla.org/presence</a>
Some use cases
Use case #1 - a chat app on Desktop (talkilla v.1)
-> See talkilla doc
Use case #2 - Big Blue Button
Use case #3 - a chat app on Firefox OS
Bob starts his phone and log into his account. That sets his presence to "online" via the presence service. The notification service is also started so Bob can be notified. Bob has a contact list on his phone to keep all his friends. A contact is an e-mail.
Bob starts the chat app. The app looks into Bob's contact list and uses the presence service to update its UI. It also hooks itself to the notification service to answer on any SIP request.
Bob wants to talk with Sarah. Bob starts a chat window . The chat app sends a request to Sarah via the notification system using her e-mail.
On Sarah's phone, the event is received, and the chat app is started. Sarah accepts the chat and a session is started.
Open questions:
- what happens when a user is connected on several devices ?
- What protocols exist that we can beg/borrow/steal?
- <a href="http://en.wikipedia.org/wiki/SIMPLE">http://en.wikipedia.org/wiki/SIMPLE</a> (built on SIP, might be more WebRTC compatible)
- XMPP?
- IRC?
- Zephyr? Seriously? Is it 1991 in Cambridge?
- SIP
- What is the least amount of info we need to store or manage?
- Should we do end-to-end encryption?
- How do we deal with Spam?
tarek asked to find all the overlapping projects that seem to want to do presence.
Found various groups
INcluding big blue button
Presence / webrtc
chat simply (nick?)
Round Table:
Tarek - services = interested in RTC and Presence make sure we have most folks involved.
jr - services =
nick - Chat Simply = xmpp project with experience.
rob - project mgmt = Director of user serivces/ sync/ firefox accounts internal customer cloud user
Ian - together.js = collaboration script and pre-existing messaging "How do deal with presence? How do you ensure you're talking to who you think you're talking to?' focused on consumers and what they are doing/wanting. Use cases around how they connect and use. Other use case Anon connect to a developer? are there people in a group? (admin control /privs?) Mentor relationships. Open access and connect.
ryan - services = made the mistake of suggesting presence is not the same as messaging. Has some experience and research in various existing protocols
Mark - demigod = where do we enable various tech. Talking with various groups and projects Talkilla/ tincan / firefox accts. (single sign-on for mozilla projects) Stuff gets complicated then generic then poorly done. Need to understand various audiences and their needs. "Let humans comminicate" is a bit broad, so how can we realistically deal with that? Do we stick presence on FFx Accts?
(Not at meeting) Mark Banner - Talkilla Development lead. Interested in a wide presence system, but in q4 we need to have at least a basic system in talkilla.
Existing Systems:
SimplePush: ability to talk to wake remote systems
Big Blue Button:
