Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
84 changes: 83 additions & 1 deletion requirements/status.md
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
Copy link
Contributor Author

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?

Copy link
Contributor

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. 👍


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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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.

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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?


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
Copy link
Contributor Author

Choose a reason for hiding this comment

The 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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FYI for any readers. I proposed to @kaiserd and @sunleos to have a dedicated item in H1 to define migration strateg.,

- 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
Copy link
Contributor

Choose a reason for hiding this comment

The 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:

  • new accounts
  • new chats
  • etc


### 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
Copy link
Contributor

Choose a reason for hiding this comment

The 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:

  1. Should "legacy" chats be bridged to new chat clients?
  2. How long should this bridged capability be running in parallel before we expect everyone to be upgraded?
  3. 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?)

Copy link
Contributor

Choose a reason for hiding this comment

The 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
Copy link
Contributor Author

Choose a reason for hiding this comment

The 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?

Copy link
Contributor

Choose a reason for hiding this comment

The 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]
Copy link
Contributor

Choose a reason for hiding this comment

The 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)**