Proposer’s contact info: Kevin - kevin@walletchat.fun
Grant Category: Apps
ELI5 Project Summary: WalletChat is wallet-to-wallet chat application, which currently Web2.0 style backend, we would like to leverage Ceramic updatable streams, and ComposeDB for maximum decentralization.
Previous projects the team has meaningfully contributed to LitChat (Ceramic Winner at LFGrow)
Comparable projects or peers: Blockscan Chat
Ceramic Ecosystem Value Proposition:
What is the problem statement this proposal hopes to solve for the Ceramic ecosystem?
While Ceramic+ComposeDB advertises itself conceptually as “a decentralized SQL DB”, we believe it could be more than that leveraging the libp2p functionality that Ceramic also uses to communicate between nodes. Even if this is not possible today due to the fact there is just one overall /ceramic topic, we believe fully utilizing libp2p aligns with full decentralization. We aim to move a traditional web2.0 DB+API to a web3.0 DB+API, and have open source examples before and after to aid in community development.
Longer term, WalletChat could even be used to communicate with users of ComposeDB models to aid in re-use and collaboration.
How does your proposal offer a value proposition solving the above problem?
We aim to drive new use cases based on our questions in the forum: https://forum.ceramic.network/t/compose-db-clarifications/511. From the answers given, there is no effective way to search similar data models, there is not a great way to re-use or track usage, nor a way contact who is using a data model for collaboration. Re-use is a large reason to have open and composable data within ComposeDB. WalletChat use of ComposeDB aims to give a working example of how data can designed in a relational way, just like a relational SQL DB, such that users can build their chat networks on top of an existing ecosystem.
Why will this solution be a source of growth for the Ceramic ecosystem?
ComposeDB needs to be battle tested by experienced devs who can help fix bugs in Ceramic and ComposeDB as we build. Based on the nature of building in an alpha ComposeDB release, devs who can help diagnose and push through issues instead of requiring many hours of oversight to make progress will be valuable to the cohort and the Ceramic ecosystem.
WalletChat currently is 100% open source. A working wallet-to-wallet chat ecosystem which has a proven method for moving from SQL to ComposeDB is a great use case and example for adoption of your product. One major concern of ours, and i’m sure of others will be speed comparison of using a traditional DB vs ComposeDB. This could also be used as a benchmark to see how the speed of the network improves over time.
Funding requested (DAI/USDC): [$20,000]
Milestones:
Milestone #1: Migrate existing MySQL to ComposeDB (120 hours) - [10,000]
[ComposeDB data modeling] - [20 Hours @ 50 $/ Hr]
[Replace direct message SQL queries with ComposeDB queries] - [30 Hours @ 100 $/ Hr]
[Initial live testing, raw chat data storage from SQL DB to Ceramic] - [30 Hours @ 100 $/ Hr]
[Move remaining SQL items from SQL to Ceramic/ComposeDB] - [40 Hours @ 100 $/ Hr]
The deliverable at the end of this milestone is a working WalletChat API + Compose DB/Ceramic which will work with Postman, along with documentation which will be an interactive Swagger doc similar to our current API doc: https://api.v2.walletchat.fun/docs/index.html
Milestone #2: Aggregate StreamIDs based on DID/WalletAddress (65 hours) - [$5,500]
This will be the source of truth for all the conversations involved within WalletChat. We’ll likely have to use our API to help with this initially, but having this auto-update within the libp2p infrastructure would be the goal if possible. With this architecture, we will have to ability to allow users to create their own chat “organizations” which can be modularized so some users only track the messages they care about within a given organization.
[Integrate DID sign-in to WalletChat Web UI] - [20 Hours @ 50 $/ Hr]
[Collect and store new StreamIDs in aggregate stream] - [10 Hours @ 100 $/ Hr]
[Change WalletChat clients to use StreamIDs from aggregator for DMs] - [10 Hours @ 100 $/ Hr]
[UI to allow clients to input project defined StreamID for Organization] - [5 Hours @ 100 $/ Hr]
[Change clients to use StreamIDs from aggregator for NFT/Community chat groups] - [10 Hours @ 100 $/ Hr]
[Overall Debugging and Maintaining Open Source documentation] - [10 Hours @ 100 $/ Hr]
The deliverable at the end of this Milestone is for DMs within WalletChat to be using ComposeDB+Ceramic instead of a SQL DB
Milestone #3: User Data Model Analytics UI/UX (50 hours) - [$2,500]
UI to facilitate users to visualize and collect all data owned by their DID. The goal of ComposeDB/Ceramic is not just for decentralized data storage, but for users to truly own their data and reuse or redistribute when possible.
[Search/Display IDs for Ceramic data/models via given wallet/DID] - [40 Hours@ 50 $/ Hr]
[Documentation] - [10 Hours @ 50 $/ Hr]
Food for thought: optional metadata placed on the model which gives some organizational ID info, would be very useful for future data analytics for example find all data models owned/used by WalletChat. We might consider signing our data models with a publicly owned wallet, and use that as a way to ID our known models within Ceramic.
The deliverable here will be a basic UI where users can aggregate, sort and view their Ceramic footprint. The longer term goal of this would be way for developers to onboard existing Ceramic DAPP users to a new DAPP, and import their data. This is something not possible in web2.0 and a paradigm shift of how web3 should operate.
I understand that I will be required to provide additional KYC information to the 3Box Labs to receive this grant: Yes
Progress this week included resolving all the errors we’ve posted about the past few weeks, and hopefully that helps others as a few sections of the docs were updated.
Spoke with some of the team on a call about some next steps for WC and support.
Weekly update here! Working on a few different avenues, smoothing out our authentication process. Could still use some advice there if others have used PostMessage to send JWT/DID tokens between domains, and if that is considered safe or not? I know Ledger Live dapp browser uses this method to share a provider and some information, but wan’t 100% sure its all secure.
Was hoping someone had the link to the original walk-through for the simple profile demo, I still can’t find in the docs where I found this example
I assume this error is because Im testing with a local node:
[2023-01-21T19:25:41.098Z] ERROR: Error: CACAO expired: Commit bagcqceravpam5dgq7vnxsyy2kr2zfoa7khvratwfape3agtqzk4lt3knr6kq of Stream k2t6wzhkhabz58ijbmguakywnhcjilsp3h7cubnl99lpl878x13xc633wn3mox has a CACAO that expired at 1674000468. Loading the stream with 'sync: SyncOptions.ALWAYS_SYNC' will restore the stream to a usable state, by discarding the invalid commits (this means losing the data from those invalid writes!)
It may be helpful to have some documentation around this error, or not sure how hard it would be, to include some links to documentation in the error handler.
Thanks @0x_Sam - for me it was easier to start over new than fix this error.
For progress:
I’ve been spending a lot more time trying to help fix details in the docs/onboarding with @avi than coding so far, but hope to continue making some progress on the technical side this weekend. Its been great to see how open the Ceramic team is about taking feedback. I hope thats actually more valuable to the Ceramic team as a whole than just working around them quietly to just make progress on our integration.
I know forums get messy and hard to answer everything especially with the recent production issues this week, but I hope there is a way to answer the question I had regarding how ComposeDB / create-ceramic-app can fix the CACAO error described above. Can I pass SYNC parameters to a composeDB query, which then are fed into loadStream somehow? I don’t see an obvious way, but maybe this sort of linkage would be useful for others as i’m sure it will happen again.
Some pictures in the documentation explaining how ComposeDB + CACAO + DID + Ceramic Client + IPFS would help a lot, and realize they are in-progress. From my impression of Ceramic stack as a whole, its very modular and each stack component has 3 or 4 flavors to choose from. Its great for a developer, but sometimes hard to digest all at once. Its hard to draw a good diagram for every perumatation at once maybe, but in the case of create-ceramic app, it might be nice to have some sort of graphic which grey-out all the stack components not used (but are possible) and highlights in color how a ComposeDB executeQuery actually flows down to traditional ceramic, showing what is actually used. I find I learn best by understanding one end to end use case, vs understanding all permutations at each step.
In the future it may be useful is to have a technical FAQ, something like:
What is the easiest way to get started using ComposeDB?
A. create-ceramic-app - this is a banger of an app, right out the gate, it just works! You won’t learn a lot about all the details of each component right away, but its a great start!
Using ComposeDB - how do I get all the streamIDs that are being created using my cool new create-ceramic-app? I want to store those, and share them with others so they can read my data too!
A. ???
3 ) <insert question that has been asked 6 times in the forum>
A. ??? maybe use ChatGPT to aggregate them for you - Discord has some great bots that auto-answer a lot of common questions live in the chat feed based on pattern matching, and i’ve found them useful.
Was good to catch up this week with the mid-project call as well, and ask questions/give feedback live.
Would it make sense to take a break and re-visit with the fresh set of documentation and hard fork changes being made? We’ve not been able to resolve many of the issues brought up, realize you guys are busy and have product changes which take priority. I think it makes sense for us to focus our efforts after there is more of a lull in the action.
I will say when I did have things initially working, I was impressed with the query search/retrieval time! Way faster than when I used Ceramic 9 or 10 months ago!
I think ComposeDB could be a great architecture improvement to our current app, and really hope we can integrate.
[2023-01-21T19:25:41.098Z] ERROR: Error: CACAO expired: Commit bagcqceravpam5dgq7vnxsyy2kr2zfoa7khvratwfape3agtqzk4lt3knr6kq of Stream k2t6wzhkhabz58ijbmguakywnhcjilsp3h7cubnl99lpl878x13xc633wn3mox has a CACAO that expired at 1674000468. Loading the stream with 'sync: SyncOptions.ALWAYS_SYNC' will restore the stream to a usable state, by discarding the invalid commits (this means losing the data from those invalid writes!)
?
Is it possible that your DID session actually expired? How long did this error happen after you signed in with your wallet? Does signing out and in again help?
Hi @anon94983028 - no I’ve worked around this by just using a new wallet. This issue was explained in the thread, as I was running a local node that was turned off for 3-4 days and got this error when turned back on. I was interested in fixing the issue as the error message described, but some of the suggestions were not very straightforward (i.e. where do I actually set the mentioned values in the error message) and I think the thread was not a priority in the greater scheme of ComposeDB development (makes sense, its a one off case which can be worked around).
I am having some issues now with the simple create-ceramic-app, in a more recent thread with @anon16214351 helping out some. The debugging process has become pretty time intensive, and in general it seems lots of these things will be cleaned up by new releases, better docs, more error handling.
I’m happy to jump on a call with a dev if you guys want to drill down in some of these most recent issues, but also don’t want to burn through your devs time and ours if these are just water under the bridge in a months time.
