mirror of
https://github.com/status-im/swarms.git
synced 2025-01-20 15:29:04 +00:00
Update contributors and fix some formatting (#099)
This commit is contained in:
parent
2c7c2a8004
commit
336b162ef1
@ -7,7 +7,6 @@ category: core
|
||||
lead-contributor: PombeirP
|
||||
contributors:
|
||||
- lukaszfryc
|
||||
- gravityblast
|
||||
- dmitryn
|
||||
- chadyj
|
||||
- nikitalukianov
|
||||
@ -36,7 +35,6 @@ As end users we currently don't have confidence that messages are being sent, de
|
||||
- Testing & Evaluation: @lukaszfryc
|
||||
- Contributor (Clojure): @cammellos
|
||||
- Contributor (Clojure): @dmitryn
|
||||
- Contributor (Go): @gravityblast
|
||||
- PM: @chadyj
|
||||
- UX: @nikitalukianov @jpbowen @hesterbruikman
|
||||
|
||||
@ -52,66 +50,70 @@ This section is based on user feedback spawned as part of 75-status-everyday (ht
|
||||
|
||||
1. Messages should always be sent.
|
||||
|
||||
a. Generally: lack of trust in messages being sent
|
||||
b. Provide better feedback of when messages are or aren’t sent
|
||||
c. Allow re-send of individual messages a la Whatsapp
|
||||
- Generally: lack of trust in messages being sent
|
||||
- Provide better feedback of when messages are or aren’t sent
|
||||
- Allow re-send of individual messages a la Whatsapp
|
||||
|
||||
2. Messages are in wrong order.
|
||||
1. Messages are in wrong order.
|
||||
|
||||
a. Confirm fixed in 1on1
|
||||
b. Make decision re migrations for old messages
|
||||
c. Understand and clarify work needed for private group / public (placeholders)
|
||||
d. Design: Deal with right order but “message arriving too late” (see sidebar)
|
||||
- Confirm fixed in 1on1
|
||||
- Make decision re migrations for old messages
|
||||
- Understand and clarify work needed for private group / public (placeholders)
|
||||
- Design: Deal with right order but “message arriving too late” (see sidebar)
|
||||
|
||||
3. Messages lack timestamps.
|
||||
1. Messages lack timestamps.
|
||||
|
||||
a. This appears to contribute to a lack of confidence in messaging
|
||||
b. Design (then dev): Add this to UI
|
||||
- This appears to contribute to a lack of confidence in messaging
|
||||
- Design (then dev): Add this to UI
|
||||
|
||||
4. Messages don’t arrive despite being sent, or they arrive late.
|
||||
a. Disambiguate offline from mail server node copy
|
||||
b. Understand what is needed to make mail server HA
|
||||
c. Give user feedback while it is fetching messages (non-instant)
|
||||
d. Understand if there are more reasons messages would arrive late
|
||||
1. Messages don’t arrive despite being sent, or they arrive late.
|
||||
- Disambiguate offline from mail server node copy
|
||||
- Understand what is needed to make mail server HA
|
||||
- Give user feedback while it is fetching messages (non-instant)
|
||||
- Understand if there are more reasons messages would arrive late
|
||||
|
||||
5. Messages should always be delivered, 100% of the time.
|
||||
1. Messages should always be delivered, 100% of the time.
|
||||
|
||||
a. Similar to 1 but stronger
|
||||
b. What happens if mail server goes down?
|
||||
c. Can we implement read/re-send semantics at Whisper level (mailserver)?
|
||||
d. Look into how read receipts can be improved
|
||||
e. Clarify UI a la Whatsapp double-tick
|
||||
f. Consider tracking send/delivered ratio as a metric
|
||||
- Similar to 1 but stronger
|
||||
- What happens if mail server goes down?
|
||||
- Can we implement read/re-send semantics at Whisper level (mailserver)?
|
||||
- Look into how read receipts can be improved
|
||||
- Clarify UI a la Whatsapp double-tick
|
||||
- Consider tracking send/delivered ratio as a metric
|
||||
|
||||
6. Offline inboxing not working in public chat.
|
||||
1. Offline inboxing not working in public chat.
|
||||
|
||||
a. Clarify perf dependency on smooth-ui swarm
|
||||
b. While perf is being worked on, educate user about offline only being 1-1
|
||||
- Clarify perf dependency on smooth-ui swarm
|
||||
- While perf is being worked on, educate user about offline only being 1-1
|
||||
|
||||
7. Perception of lack of notifications.
|
||||
a. UXR: understand expectation - for non-contacts? Public chats? in-app?
|
||||
b. Separate PN swarm, clarify dependency with this swarm
|
||||
1. Perception of lack of notifications.
|
||||
|
||||
8. Get notification but nothing visible in app.
|
||||
a. PN delivery being decoupled from Whisper delivery, see point 7 above
|
||||
b. Clarify dependency on PN v2 swarm and where work done
|
||||
- UXR: understand expectation - for non-contacts? Public chats? in-app?
|
||||
- Separate PN swarm, clarify dependency with this swarm
|
||||
|
||||
9. Perception of never received messages from other people.
|
||||
a. Investigate if same as filter while offline bug and current limitations
|
||||
b. More 7: Investigate non-contact PN possibility
|
||||
c. More 7: Public chat PN?
|
||||
d. UXR: Understand this problem and perception better
|
||||
1. Get notification but nothing visible in app.
|
||||
|
||||
10. Sometimes need to change mail server manually to get messages working.
|
||||
a. Make failure of individual mail server apparent and prompt switching
|
||||
b. Automated switching?
|
||||
c. How ensure no switching is necessary? (HA, see 4)
|
||||
- PN delivery being decoupled from Whisper delivery, see point 7 above
|
||||
- Clarify dependency on PN v2 swarm and where work done
|
||||
|
||||
1. Perception of never received messages from other people.
|
||||
|
||||
- Investigate if same as filter while offline bug and current limitations
|
||||
- More 7: Investigate non-contact PN possibility
|
||||
- More 7: Public chat PN?
|
||||
- UXR: Understand this problem and perception better
|
||||
|
||||
1. Sometimes need to change mail server manually to get messages working.
|
||||
|
||||
- Make failure of individual mail server apparent and prompt switching
|
||||
- Automated switching?
|
||||
- How ensure no switching is necessary? (HA, see 4)
|
||||
|
||||
### Requirements & Dependencies
|
||||
|
||||
[Request messages history after background](https://github.com/status-im/status-react/pull/3493)
|
||||
[New protocol](https://github.com/status-im/status-react/pull/3273)
|
||||
[New Status App communication protocol idea](https://github.com/status-im/ideas/blob/master/ideas/087-new-protocol.md)
|
||||
- ~~[Request messages history after background](https://github.com/status-im/status-react/pull/3493)~~
|
||||
- ~~[New protocol](https://github.com/status-im/status-react/pull/3273)~~
|
||||
- [New Status App communication protocol idea](https://github.com/status-im/ideas/blob/master/ideas/087-new-protocol.md)
|
||||
|
||||
### Security and Privacy Implications
|
||||
|
||||
@ -121,14 +123,14 @@ None currently known.
|
||||
|
||||
Complete several reliability improvements that have been identified so far:
|
||||
|
||||
- [#3827 Message reliability survey](https://github.com/status-im/status-react/issues/3827)
|
||||
- [#3793 Improve timestamps in chat messages](https://github.com/status-im/status-react/issues/3793)
|
||||
- [#3787 Improve network offline and mail server error messaging](https://github.com/status-im/status-react/issues/3787)
|
||||
- [#3784 Provide users with delivery status feedback when sending messages](https://github.com/status-im/status-react/issues/3784)
|
||||
- [#3792 Measure message send/receive ratio on internal builds](https://github.com/status-im/status-react/issues/3792)
|
||||
- [#828 Send an expiration signal when envelope wasn't delivered to any peer](https://github.com/status-im/status-go/pull/828)
|
||||
- [#810 Notify clj side when the message actually "left" local node.](https://github.com/status-im/status-go/issues/810)
|
||||
- [#3785 Remove "seen by everyone" from public chat](https://github.com/status-im/status-react/issues/3785)
|
||||
- ~~[#3827 Message reliability survey](https://github.com/status-im/status-react/issues/3827)~~
|
||||
- ~~[#3793 Improve timestamps in chat messages](https://github.com/status-im/status-react/issues/3793)~~
|
||||
- ~~[#3787 Improve network offline and mail server error messaging](https://github.com/status-im/status-react/issues/3787)~~
|
||||
- ~~[#3784 Provide users with delivery status feedback when sending messages](https://github.com/status-im/status-react/issues/3784)~~
|
||||
- ~~[#3792 Measure message send/receive ratio on internal builds](https://github.com/status-im/status-react/issues/3792)~~
|
||||
- ~~[#828 Send an expiration signal when envelope wasn't delivered to any peer](https://github.com/status-im/status-go/pull/828)~~
|
||||
- ~~[#810 Notify clj side when the message actually "left" local node.](https://github.com/status-im/status-go/issues/810)~~
|
||||
- ~~[#3785 Remove "seen by everyone" from public chat](https://github.com/status-im/status-react/issues/3785)~~
|
||||
|
||||
### Iteration 2
|
||||
|
||||
@ -140,11 +142,11 @@ After iteration 1 is complete the swarm will meet and discuss the results of the
|
||||
|
||||
## Success Metrics
|
||||
|
||||
95% of a group of 100 users surveyed - who don't have additional context beyond Status providing a p2p IM capability - using the app for an extended period of time, should answer 'yes' to the question: "Do you trust Status to deliver messages for you?" (and possibly variants of this).
|
||||
- 95% of a group of 100 users surveyed - who don't have additional context beyond Status providing a p2p IM capability - using the app for an extended period of time, should answer 'yes' to the question: "Do you trust Status to deliver messages for you?" (and possibly variants of this).
|
||||
|
||||
This is fundamentally a soft or qualitative goal. It is thus necessary but not necessarily sufficient, and additional harder numbers might be used as we develop the capability to measure this.
|
||||
This is fundamentally a soft or qualitative goal. It is thus necessary but not necessarily sufficient, and additional harder numbers might be used as we develop the capability to measure this.
|
||||
|
||||
Zero instabug reports within 30 days of alpha release
|
||||
- Zero instabug reports within 30 days of alpha release
|
||||
|
||||
## Copyright
|
||||
|
||||
|
Loading…
x
Reference in New Issue
Block a user