From 4dbaa01fcdc5ce5d30fb56381771beafe2295b91 Mon Sep 17 00:00:00 2001 From: Samuel Hawksby-Robinson Date: Tue, 12 Nov 2024 13:27:59 +0000 Subject: [PATCH] Added attachments from November --- ...11-01 status-go knowledge share session.md | 102 +++++++++++++++ .../We Need To Talk About Feature Upvote.md | 121 ++++++++++++++++++ 2 files changed, 223 insertions(+) create mode 100644 attachments/2024-11/2024-11-01 status-go knowledge share session.md create mode 100644 attachments/2024-11/We Need To Talk About Feature Upvote.md diff --git a/attachments/2024-11/2024-11-01 status-go knowledge share session.md b/attachments/2024-11/2024-11-01 status-go knowledge share session.md new file mode 100644 index 0000000..1967b19 --- /dev/null +++ b/attachments/2024-11/2024-11-01 status-go knowledge share session.md @@ -0,0 +1,102 @@ +Overview + +The "status-go knowledge share session" focused on the historical context and technical challenges surrounding the Status Go project, emphasizing its evolution from initial integrations of mobile storage and messaging to the development of the Waku protocol. Discussions revealed that while end-to-end encryption and user privacy are prioritized, they complicate reliability and synchronization within the application. The team considered the potential transition from Go to Nim for development, weighing the pros and cons of such a significant rewrite against the need to maintain functionality and address technical debt. Product development priorities were established, highlighting the importance of documentation, knowledge sharing, and gradual refactoring of the Status Go code. Collaboration with research teams from Waku and Nimbus was encouraged, and the meeting concluded with actionable steps, including scheduling a follow-up meeting at Devcon and enhancing current documentation. + +Notes + +Historical Context and Project Origins (05:04 - 23:38) + +- Status initially aimed to integrate storage, messaging, and execution on a mobile node + +- Ethereum Foundation dropped Whisper and Swarm, which Status took on + +- Nimbus was created to have a seat at the table in developing consensus protocol + +- Waku was developed as a replacement for Whisper, offering better scalability + +- Status Go development focused on end-user use cases, not fundamental chat application aspects + +- Reliability became a neglected aspect between Waku protocol and Status app development + + +️ Technical Challenges and Architecture (23:38 - 53:40) + +- End-to-end encryption and reliability must happen inside the encrypted stream + +- Status Go handles end-to-end encryption as it owns the user's keys + +- Waku aims for sender and receiver anonymity, complicating reliability implementation + +- Communities (group chats) introduced additional complexities in synchronization and key sharing + +- Status Go code became complex, mixing various functionalities in long functions + +- Proposal to integrate Enwaku into Status Go as a step towards better architecture + + +Integration and Language Considerations (53:41 - 01:22:41) + +- Discussion on replacing Go with Nim for Status Go + + - Discussion centered around the potential benefits of replacing Go with Nim for Status Go, emphasizing improved integration and efficiency. + + - Concerns were raised about the complexity and historical challenges of the current Status Go codebase, highlighting the need for better documentation and understanding of the existing protocol. + + - Participants agreed on the importance of maintaining a clear separation of concerns within the code to facilitate future development and potential rewrites. + + +- Concerns raised about the feasibility and necessity of rewriting Status Go + +- Emphasis on documenting existing protocol and creating specifications + +- Suggestion to refactor Status Go gradually, extracting and isolating components + +- Consideration of language interoperability, especially Go's challenges in integration + + +Product Development and Priorities (01:22:41 - 01:54:21) + +- Focus on building a sustainable product and maintaining V1 features + +- Need to identify target users and address existing bugs + +- Rewriting Status Go considered unrealistic and potentially harmful to the project + +- Discussion on the importance of documentation and knowledge sharing + +- Balancing technical debt reduction with product development pressures + + +Collaboration and Future Steps (01:54:21 - 02:20:49) + +- Encouragement to leverage research from Waku and Nimbus teams + +- Suggestion to think about protocol specification and modularity during development + +- Proposal for follow-up discussions at Devcon + +- Emphasis on the support available from research teams for integration efforts + +- Reminder of the long-term benefits of improving code structure and documentation + + +Action items + +Igor + +- Schedule a follow-up meeting at Devcon to discuss more concrete details of Status Go integration with Enwaku (02:19:09) + + +unassigned + +- Review and update Status Go documentation to ensure it's current and comprehensive (01:57:30) + + +Status Go team + +- Begin process of extracting and isolating components within Status Go for easier future modifications (01:52:22) + + +Wallet team + +- Explore possibilities of integrating Nimbus' verifying proxy for improved security in wallet transactions (01:03:08) \ No newline at end of file diff --git a/attachments/2024-11/We Need To Talk About Feature Upvote.md b/attachments/2024-11/We Need To Talk About Feature Upvote.md new file mode 100644 index 0000000..2b15b27 --- /dev/null +++ b/attachments/2024-11/We Need To Talk About Feature Upvote.md @@ -0,0 +1,121 @@ +# TLDR + +We should consider deleting Feature Upvote and transitioning to a Discourse plugin for our feature suggestion and voting needs. + +# What Am I Talking About? + +https://status.app/feature-upvote + +Simply put, Feature Upvote is a feature suggestion and voting functionality accessible through the [status.app](http://status.app/) website. It allows users to submit ideas and vote on feature requests, providing valuable insight into what our community would like to see developed next. However, the tool has some notable downsides that impact our independence, security, and costs, prompting a need for discussion about its future. + +# Why Is It a Problem? + +There are several reasons why Feature Upvote is no longer suitable for our needs. Let’s break them down. + +## 1. Aligning with Status’ Decentralisation and Open Source Principles + +One of Status’ core principles is openness and decentralisation. By removing reliance on an external SaaS product, we are taking an active step toward reducing central points of control and dependency. This shift would serve as a statement that Status prioritises community empowerment and open source solutions, which will resonate a lot better with our user base. + +## 2. Feature Upvote Is a 3rd Party Service + +Feature Upvote is a separate service not owned or maintained by Status. While it allows us to quickly set up and manage feature requests, it relies on external hosting and maintenance by https://featureupvote.com/. + +By depending on a 3rd party service, we introduce a potential risk factor, as any changes to their policies or availability could impact our ability to use the service. Additionally, it introduces data privacy concerns since we do not fully control the environment where our users’ data is stored and accessed. + +## 3. Feature Upvote Is a Closed Source SaaS Solution + +This tool is a closed-source SaaS product, which presents limitations for us as an organisation that values transparency and decentralisation. We cannot self-host it, meaning we have no control over the underlying database or its data handling processes. As part of our website integration, we’re embedding Feature Upvote via an `