Conversation
| ### Performance | ||
|
|
||
| ### Supportability | ||
| 1. App runs on Mobile |
There was a problem hiding this comment.
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.
| # Waku's requirements on Status | ||
|
|
||
| TODO: list specific areas of concerns and risks No newline at end of file | ||
| ## Minimal Test UI |
There was a problem hiding this comment.
@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.
This would be covered by Status X, indeed. The requirement is stated in functional terms, as you do here. 👍
|
|
||
| **+ (Privacy, Anonymity, Censorship-Resistance, Deployments)** | ||
|
|
||
| ## Status Fleets Ownership |
There was a problem hiding this comment.
@jm-clius Are there any existing conversations on this I can catchup on?
There was a problem hiding this comment.
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.
|
|
||
| The application should include the least amount of complexity while also effectively mitigating integration risks. | ||
|
|
||
| ### Functionality |
There was a problem hiding this comment.
I think this list is fine, assuming this is Status X.
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 Fs per se, but more how one should read. Would you agree?
|
|
||
| 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. |
There was a problem hiding this comment.
| Features such as Wallet, Communities, etc, can add complexity and noise to the testing process. | |
| Features such as Communities, etc, can add complexity and noise to the testing process. |
Indeed we probably don't need a wallet at first, but we will with RLN very shortly after.
| - 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? |
There was a problem hiding this comment.
I'd prefer to suggest the simplest strategy as a negotiation starting point, instead of opening too much:
- new accounts
- new chats
- etc
|
|
||
| ## Status Fleets Ownership | ||
|
|
||
| [Placeholder - Cannot find an references to this Conversation] |
There was a problem hiding this comment.
I think we should make it a Waku offsite topic first, so we cna be aligned on expectations before pushing for changes.
jm-clius
left a comment
jm-clius
left a comment
There was a problem hiding this comment.
Also added a couple of comments. Presumably we want to get Status eyes on this before approving and merging?
| # Waku's requirements on Status | ||
|
|
||
| TODO: list specific areas of concerns and risks No newline at end of file | ||
| ## Minimal Test UI |
There was a problem hiding this comment.
This would be covered by Status X, indeed. The requirement is stated in functional terms, as you do here. 👍
|
|
||
| **+ (Privacy, Anonymity, Censorship-Resistance, Deployments)** | ||
|
|
||
| ## Status Fleets Ownership |
There was a problem hiding this comment.
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.
| 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. |
There was a problem hiding this comment.
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:
- Should "legacy" chats be bridged to new chat clients?
- How long should this bridged capability be running in parallel before we expect everyone to be upgraded?
- Should history be bridged/migrated too (i.e., should someone running an app on chat sdk be able to query history from before the launch of chatsdk?)
There was a problem hiding this comment.
Co-authored-by: fryorcraken <110212804+fryorcraken@users.noreply.github.com>
| 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. |
| 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. |
There was a problem hiding this comment.
3 participants
This PR adds Outbound Requirements for StatusApp. (see: requirements for more information )
The requirements represent what Waku needs from Status in order to best support them, and ensure successful integration of the ChatSDK.