Closed Bug 1264668 Opened 8 years ago Closed 8 years ago

Determine how FxA fits into Akita

Categories

(Hello (Loop) :: Client, defect)

Product:
Hello (Loop)
Component:
Client
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED INCOMPLETE

People

(Reporter: ianbicking, Unassigned)

References

Details

(Whiteboard: [akita])

User Story

Questions to be answered:
1. Do we want FxA included at all in the initial Akita version?
1a. What do we do about people already signed into FxA?
2. If not, do we expect to want FxA in a revision shortly after the first version?
3. Can we use Firefox Sync to sync the room list?
4. Do we need to worry about more than one person using a browser?
5. What happens if we want contacts or something later?
      No description provided.
Blocks: akita-planning
User Story: (updated)
Blocks: 1263128
User Story: (updated)
Whiteboard: [akita][uxtriage]
> 3. Can we use Firefox Sync to sync the room list?

Given that the room information is stored on the Loop server, also storing it in Sync seems problematic -- it requires you to think about and handle situations where the servers have conflicting data. What's the benefit?
Blocks: 1190978
Blocks: 1217412
1. Do we want FxA included at all in the initial Akita version?
No, this will make shipping Akita simpler at a time where FxA's value is only cross desktop device support.

2. If not, do we expect to want FxA in a revision shortly after the first version?
Yes, we will define the auth approach in London
(In reply to Romain Testard [:RT] from comment #2)
> 1. Do we want FxA included at all in the initial Akita version?
> No, this will make shipping Akita simpler at a time where FxA's value is
> only cross desktop device support.

The follow-up question, is what do we do for people already signed into FxA:

- Do we log them out and "loose" their existing rooms?
- Do we just keep them signed in, but never allow them to sign in again (pretty weird UX)
- Do we just hide the sign in/out menu items in the settings menu so that any user can get to them, but not in primary UX?
User Story: (updated)
Flags: needinfo?(rtestard)
Flags: needinfo?(ianb)
(In reply to Mark Banner (:standard8) from comment #3)
> (In reply to Romain Testard [:RT] from comment #2)
> > 1. Do we want FxA included at all in the initial Akita version?
> > No, this will make shipping Akita simpler at a time where FxA's value is
> > only cross desktop device support.
> 
> The follow-up question, is what do we do for people already signed into FxA:
> 
> - Do we log them out and "loose" their existing rooms?
> - Do we just keep them signed in, but never allow them to sign in again
> (pretty weird UX)
> - Do we just hide the sign in/out menu items in the settings menu so that
> any user can get to them, but not in primary UX?

This last option seems the better from a user standpoint although how expensive is it from an engineering standpoint? It effectively means that FxA has to work even though it's hidden from primary UI.
If this is not adding a lot of complexity then great.
Flags: needinfo?(rtestard)
Blocks: 1273336
To do: look at logs, and see how many users we see that are using multiple devices.

(We know that many people use FxA logins, but we suspect that they aren't using it for multidevice purposes, but only login because the interface seems to suggest a login is required)
Flags: needinfo?(ianb)
Whiteboard: [akita][uxtriage] → [akita]
Support for Hello/Loop has been discontinued.

https://support.mozilla.org/kb/hello-status

Hence closing the old bugs. Thank you for your support.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.