Samyoul
commented
3 years ago Team Comment Digest
Praise / Support
-
"I just love it :)"
-
"This is quite interesting and, as someone mentioned, it could be used to leverage other dapp's users to drive people to use the Status app."
Scepticism / Unsure / Ambiguity
- Don't understand this feature
- Is there a demand? x3
- Ambiguous x2
- Potential negative impact
- Doesn't help acqiuisition/retention x2
- General scepticism ^∞
-
"not sure i understand this one"
-
"Do we know that users of other Dapps actually want this? How do we verify the demand for it?"
-
"No validation from dapps/projects yet"
-
"This feature has the most ambiguity to me. What is the ultimate goal? To bring Status outside of purely the app, and into other channels (websites, dapps, etc). There is certainly value in this but also can have a negative impact on the other features (most notably SNT utlity). The positive impact on app DAU feels longer term."
-
"Too much traffic to handle if people mis-use it, also, I don't think this is that useful for user acqiuisition/retention in the app."
-
"scope is a bit unclear, and choice/s of how to implement could drastically effect how long it takes, how well it works on desktop vs. mobile, and so on"
-
"Was this feature requested a lot?"
-
"I disagree with the recently mentioned point that :“You can engage people to download the app to continue in dapp communication.” Most of the time this will be used as a Discuss or chat agent. A) Discuss - this is not a place where users come daily and if they want to continue with the discussion the content I assume they will come back to dapp using the same browser? :thinking: B) Chat Agent - This is more less help center with the live agent on the other side - people come there ask a question and leave for good - not solving the retention problem Status currently has."
-
"From my pov we're not ready to be pulled/embedded into arbitrary execution contexts that we don't know, don't control. I'd rather delay that feature instead of being the iframe for messages when it comes to security."
Implementation Considerations
- Independent library vs extension of dapp API
- Identity management
- Data exposure
- Message persistence (IPFS / IPNS for message persistence ?)
- libp2p -> devp2p bridge / straight libp2p for waku v2
- Create a Waku JS lib ?
- UX concern - Signature process for every single message sent
-
"There are at least two main implementation approaches. Do we lean towards making an independent library developers can use or extending the dapp api the app exposes? From personal tinkering, my hunch is that extending the dapp api might be an inflexible approach that may consume more core resources to get built correctly. The biggest advantage of extending the dapp api is using the existing chat identity in dapps but might also be a security concern. Everything else seems to favor an independent library."
-
"How the identity is exposed and what may be exposed with it. Need to be aware of what information gets linked in the process of implementing this."
-
"Message persistance and filtering/moderation"
-
"chat history, identity access"
-
"Communication between the browser and desktop must be done via libp2p -> devp2p bridge, and also requires a webrtc signaling server to find peers, which might be a centralized point of failure. AFAIK there is no javascript waku implementation The whisper implementation requires updating since from november 2018 to now there's been changes that made the js implementation outdated"
-
"Key management. Importing status app identity. Signature process for every single message sent. Use of IPFS / IPNS for message persistence."
-
"Can be related from desktop client, which is not ready yet"
3esmit
bgits
Status chat inside dapps (e.g. disqus in etherscan, messages about multisig tx, carbon voting)
Source: Roadmap planning workshop item 71
User stories for validation
Use cases (user)
Use cases (developer)
Uses cases (project marketeer)