-
Notifications
You must be signed in to change notification settings - Fork 3
Express Requirements on Status #330
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change | ||||
|---|---|---|---|---|---|---|
| @@ -1,3 +1,85 @@ | ||||||
| # Waku's requirements on Status | ||||||
|
|
||||||
| TODO: list specific areas of concerns and risks | ||||||
| ## Minimal Test UI | ||||||
|
|
||||||
| Chat SDK needs an slimmed down version of Status to perform testing. | ||||||
|
|
||||||
| Features such as Wallet, Communities, etc, can add complexity and noise to the testing process. | ||||||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Suggested change
Indeed we probably don't need a wallet at first, but we will with RLN very shortly after. |
||||||
| To test the ChatSDK effectively a version of the Status application which only implements the required features for private chat are needed. | ||||||
|
|
||||||
| The application should include the least amount of complexity while also effectively mitigating integration risks. | ||||||
|
|
||||||
| ### Functionality | ||||||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think this list is fine, assuming this is But I would introduce that we probably want to have more of a process of elimination when building such an app, where we cut out anything that gets in the way (via compiler flags for example). This would not change the |
||||||
|
|
||||||
| 1. Ability to create multiple Identities/Accounts | ||||||
| 1. Ability to sign-in with single chosen Identity. | ||||||
| 1. Ability to view received messages by conversation. | ||||||
| 1. Newly created inbound conversations are displayed. | ||||||
| 1. New Outbound conversations can be created. | ||||||
| 1. Ability to send messages to an existing Conversation. | ||||||
| 1. Ability to receive messages automatically in the background. | ||||||
| 1. Notifications are posted when receiving new messages. | ||||||
| 1. Encoding/encryption errors are logged and retrievable. | ||||||
| 1. Missing messages in a conversation are visible to the user. | ||||||
|
|
||||||
| ### Usability | ||||||
|
|
||||||
| ### Reliability | ||||||
|
|
||||||
| ### Performance | ||||||
|
|
||||||
| ### Supportability | ||||||
|
|
||||||
| 1. App runs on Mobile | ||||||
|
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Mobile Integration represents one of the largest risk areas. Thought I think there is an open question on whether mobile testing would be feasible outside of the Status team. |
||||||
| 1. App runs on Desktop | ||||||
|
|
||||||
| ### + (Privacy, Anonymity, Censorship-Resistance, Deployments) | ||||||
|
|
||||||
| ## Migration Preparation | ||||||
|
|
||||||
| To complete ChatSDK integration without issues, Status needs to prepare the existing code base. | ||||||
| Focus is on creating abstractions and planning for breaking changes. | ||||||
|
|
||||||
| The ChatSDK takes a different approach to managing conversations, and is incompatible with the existing application. | ||||||
| Preparing the code base in advance will reduce the integration time, and allow for faster feedback. | ||||||
|
|
||||||
| To better offer support, it would be helpful for Waku to understand Status' approach to product decisions during this migration. | ||||||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. |
||||||
| - Will Users be required to create new accounts? or Will the new Keytypes be bound to existing Identities? | ||||||
| - Will Conversations be migrated? Or will users be expected to create new conversations to use new features? | ||||||
| - What is the minimum amount of time users should be given to update before older versions are locked out? | ||||||
|
Comment on lines
+47
to
+49
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'd prefer to suggest the simplest strategy as a negotiation starting point, instead of opening too much:
|
||||||
|
|
||||||
| ### Functionality | ||||||
|
|
||||||
| 1. Isolate chat internals from application so they can be replaced effectively. | ||||||
| 1. Stored user level conversations are isolated/independant from the transport used. | ||||||
| 1. Add facade to isolate Waku dependency from existing codebase. | ||||||
|
Comment on lines
+53
to
+55
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. These are indeed required to migrate efficiently, but from my pov our requirement on Status here is specifically some kind of strategic requirements that answer questions like:
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. |
||||||
|
|
||||||
| ### Usability | ||||||
| 1. Conversation encryption/encoding mechanism can be updated with a single line code change. | ||||||
|
|
||||||
| ### Reliability | ||||||
|
|
||||||
| ### Performance | ||||||
|
|
||||||
| ### Supportability | ||||||
|
|
||||||
| 1. Document strategy for managing existing conversations through the upgrade. | ||||||
| 1. Document strategy for identity binding between new and old accounts. | ||||||
|
|
||||||
| **+ (Privacy, Anonymity, Censorship-Resistance, Deployments)** | ||||||
|
|
||||||
| ## Status Fleets Ownership | ||||||
|
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @jm-clius Are there any existing conversations on this I can catchup on?
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Uh, there were several conversations about this in the past, but I think all of this would indeed be very dated/irrelevant now. I agree with Franck that we should probably caucus on this before coming up with our FURPS. Can remain placeholder for now. |
||||||
|
|
||||||
| [Placeholder - Cannot find an references to this Conversation] | ||||||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think we should make it a Waku offsite topic first, so we cna be aligned on expectations before pushing for changes. |
||||||
|
|
||||||
| ### Functionality | ||||||
|
|
||||||
| ### Usability | ||||||
|
|
||||||
| ### Reliability | ||||||
|
|
||||||
| ### Performance | ||||||
|
|
||||||
| ### Supportability | ||||||
|
|
||||||
| **+ (Privacy, Anonymity, Censorship-Resistance, Deployments)** | ||||||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jm-clius, was your intention that this Minimal UI differs from StatusX? or different representations of the same idea?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This would be covered by Status X, indeed. The requirement is stated in functional terms, as you do here. 👍