[Subtask] Create user facing dogfooding app

[weboko]

App idea

We went through many iterations of discussing it and we had two directions to select from: game or collaborative app.
As we already have collaborative app Qaky app - we better try building game app.

PRESENTING YOU - BuddyChain

App user story

as user I can:

• see that some telemetry will be gathered before using the app;
• start a chain and share QR code to it or link;
• scan someone else's QR code and sign this chain with my signature;
• open a link shared to me to sign someone else's chain;
• see information about chain I am part of or the one shared to me by link / QR before signing;
• set up information about chain I created: title, background image, description;
• see leaderboard of chains with most signatures and people that signed them: ENS, ETH info etc;

as Waku developer I can:

• see information about usage of the app: most occurring errors, rate of received / missed messages etc;
• talk to people and ask about their feedback;

Note:

• telemetry can be added in scope of this subtask but is tracked in [Subtask] Add and refine telemetry #2179

[vpavlin]

I might be missing some detail here, but where is the Waku in this?

• QR codes will be shown
• Links will be send by messengers

I'd assume when I sign I have to publish so that the chain creator can receive/retrieve it? Can you maybe make this more clear in the description? Where else will Waku be used? Discovery of existing chains?

How do we prevent people from writing a simple script (or js/go tool) to generate fresh keys in a loop and publishing new signatures?

Also, is it a chain or a tree/graph? Cause if it is a chain, then I'd expect next person signing the latest message in the chain, but that will be potentially hard to ensure - or are people only signing the root? Then that is not a chain either:)

I am really not sure I understand the mechanics:D

[weboko]

I imagine it to be:

• user creates a chain over Waku - posts a message with config for the chain object under some content topic;
• user shares link/QR to a chain - another user retrieves it from Store;
• user broadcasts signature over Waku if decides to sign a chain;
• user receives signatures from Waku;
• user fetches signatures for other chains from Waku;

How do we prevent people from writing a simple script (or js/go tool) to generate fresh keys in a loop and publishing new signatures?

I think it would be cool if someone so interested in our tech so decides to hack it - so I would say we don't care and even can try to encourage.

is it a chain or a tree/graph

I framed it as a chain as it came up originally like that but we can make it a chain or a set of signatures.

---

Maybe renaming to BuddyBook would make things cleaner

ping @fryorcraken

[fryorcraken]

The usage of Waku enables to have a public leaderboard. Cannot happen if everything is done locally and between users.

A valid signature may be under condition that an account has some assets on Eth mainnet? Or popular L2? or an ENS name?
Or maybe signatures have more "weight" if they come from an account with onchain activity.
If someone scripts, then it may be on the leaderboard but we may decide to order account by number of signatures with onchain activities on a selected number of chains (or just eth mainnet to make it easier).

This definitely does not demonstrate the privacy side of Waku. But can demonstrate the liveness, latency and interactivity. Which I think is fine.

I think it's fine if it's a tree, and if a chain forks in 2. Both chains can be part of the leader board.

[weboko]

A valid signature may be under condition that an account has some assets on Eth mainnet? Or popular L2? or an ENS name?
Or maybe signatures have more "weight" if they come from an account with onchain activity.

I am in favor of just having some history of transactions / funds on mainnet to simplify things.

This definitely does not demonstrate the privacy side of Waku

I don't think we had any ideas with demonstrating privacy discussed. We can think of adding E2E encryption to it - but it can be far fetched.

[danisharora099]

Insightful discussion.

Re Chain Structure:
I agree with the suggestion to allow chains to branch into multiple paths. We’ll treat these branches as valid extensions of the original chain, with all branches being represented in the leaderboard.
Each signature will either sign the root or an existing signature in the chain, creating a tree-like structure. If two users sign the same point simultaneously, it will naturally create a fork.
Let's visually represent the chain as a branching tree, allowing users to explore different paths.

Managing a non-conflicting chain will be additional overhead that feels not as necessary.

Re Leaderboard:
The leaderboard will rank both original chains and their branches. We’ll use criteria such as the number of signatures, prominent users (on-chain activity, ENS names), and branch depth to determine ranking.
I’m considering whether to have an aggregated leaderboard or show branches separately.

Re Waku Integration:
Waku will be used to broadcast chain creation, signature propagation, and retrieval of signatures across users.
Users will post and fetch chain data from the Store, while signatures will be broadcast and retrieved over Waku.

Re Scripted Forks:
While it’s cool if someone scripts signature creation, we’ll give more weight to signatures tied to accounts with on-chain activity or ENS names

[danisharora099]

I am in favor of just having some history of transactions / funds on mainnet to simplify things.

Good point. If we have this, a lot of accounts would be filtered out from interacting with the chain, thus reducing chances of chain fork

[fryorcraken]

Re encryption: I think we can focus on that in the future once we have de-MLS.

[danisharora099]

Tasks

Wallet Connection and Integration

Functionality:

• Integrate wallet
• Fetch and display user wallet data (ENS name, ETH balance) within the app.
  • WalletConnect does this automatically

UI Design and Implementation:

• UI for wallet connection prompt (can use WalletConnect here)

Chain Creation

Functionality:

• Enable users to create new chains with customizable information
• Broadcast with LightPush and ephemeral: false to store chain data on Waku Store for retrieval by others.

UI Design and Implementation:

• UI for creating a new chain, including input fields for title, background image, and description.
• Allow users to preview the chain before creation.

QR Code and Link Sharing

Functionality:

• Generate QR codes and shareable links that correspond to the created chains.

UI Design and Implementation:

• UI to display generated QR codes and shareable links.
• A copy button to copy the sharable link

Chain Access and Display and Signing

Functionality:

• Implement scanning of QR codes and handling of shared links.
• Retrieve chain information from Waku Store and display it in the app.
• Allow users to sign a chain using their wallet signature.
• Handle the creation of chain branches when multiple users sign the same chain simultaneously (based on timestamp)
  • client-side
• Broadcast the new signatures over Waku using LightPush

UI Design and Implementation:

• Display detailed information about the chain, including existing signatures and chain branches.
• UI for signing a chain, with clear CTAs and confirmation dialogs.
  • Confirmation dialog to include possible forks created in the process,
• Show visual feedback upon successful signing.

Waku Integration

Functionality:

• Integrate Waku for message broadcasting (LightPush) and data retrieval (Filter + Store).
• Ensure synchronization of chain data and signatures across all users.

UI Design and Implementation:

• Reflect updates in the UI as new signatures and chain branches are added.

Account Verification and Signature Weighting

Functionality:

• Verify connected wallets for on-chain activity (e.g., transactions, assets, ENS names).
• Assign weights to signatures based on verified on-chain activity.

UI Design and Implementation:

• Display verification status and signature weights within the app.
• Highlight signatures from prominent accounts (e.g., those with ENS names or significant activity).

Leaderboard

Functionality:

• Aggregate data to rank chains and users.
• Display chain branches separately and aggregated.
• (Optional) Implement sorting and filtering options based on signature weights and other criteria.
  • Think about signature weight

UI Design and Implementation:

• Design leaderboards showcasing chains with the most signatures and users with significant contributions.
• Include visual representations of chain structures (branches and depth).

Telemetry

Functionality:

• Integrate telemetry to collect data on app usage, errors, and message rates.

UI Design and Implementation:

• (Optional) Create internal dashboards or views for developers to access analytics data within the app (if time allows)
  • We can also just use Superset manually

[danisharora099]

cc @fryorcraken @weboko on the libraries we are using:

• ok to use WalletConnect (requires API keys/centralised, but very seamless user flow handling inbuilt, plus supports multiple wallets) or should we setup our own connector?

[vpavlin]

• WalletConnect does this automatically

Do you mean Reown (previously WalletConnect :-P)

WalletConnect is probably best bet for compatibility

---

Thanks all for explanation, sounds good and fun:) I am still not clear on the "chain formation" though - when I hear "chain", I imagine

1. @fryorcraken creates a new "chain"
2. @danisharora099 signs it and publishes
3. @weboko signs whatever @danisharora099 published and publishes
4. @vpavlin signs whatever @weboko published
   ...

Now, what I read is

1. @fryorcraken creates a new "chain"
2. @danisharora099 signs the chain and publishes
3. @weboko also signs what @fryorcraken created and publishes..

but maybe I am misunderstanding and the part where a new signature is published is either automatically picked up and used as whatever is being signed by everyone wanting to sign the chain, or we don't care and as long as you are signing the same chain root, we just order the chain based on timestamp

Or maybe it does not matter at all:D

My question might be rooted in "what am I as a chain creator supposed to do" (and how will the webapp behave). BUt I guess thinking more about it it makes sense - the QR or link are just pointing to the app + chain ID, so when it all loads, I am signing the latest recorded step in the chain? (Although then the question is on which branch:D)

Anyway, those are probably technicalities which we can play around later:) Sounds like a fun app!

[fryorcraken]

1. Alice creates a new chain root
2. Alice presents QR code to Bob, Bob retrieves root from Waku and signs on it: bob_sign
3. Alice presents QR code to Carol, Carol retrieves root and bob_sign from Waku, signs on bob_sign: carol_sign
4. Bob presents QR code to David, David retrieves root, bob_sign and signs on it: david_sign -> chain forks.

David may want to refresh and resign but that's already a more complex scenario so I would not worry about it at first and let the forks happen.
I assume we solve it with e2e reliability in js-waku :)