Open weboko opened 6 days ago
I might be missing some detail here, but where is the Waku in this?
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
I imagine it to be:
chain
over Waku - posts a message with config for the chain object under some content topic;chain
- another user retrieves it from Store; chain
;signatures
from Waku;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
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.
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.
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
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
Re encryption: I think we can focus on that in the future once we have de-MLS.
ephemeral: false
to store chain data on Waku Store for retrieval by others.cc @fryorcraken @weboko on the libraries we are using:
- 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
Now, what I read is
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!
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:
as Waku developer I can:
Note: