-
Notifications
You must be signed in to change notification settings - Fork 984
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Revert to TtT contract with on-chain tribute storage #8294
Comments
@3esmit is the simple contract already deployed? could you provide the address on testnet? |
@yenda Deployed in Ropsten. Let me know if you need a different network Version without messages and default fee of 0.1 value: |
@3esmit I don't think there should be a default tribute amount can you remove it? @rachelhamlin |
Yes please! 0 default. |
also I don't think we should have a way to set a default because it makes the reset method useless, the only place I see it useful is to remove tribute, but if instead it goes back to the default value it is misleading and probably not something someone will want. For this iteration we can make things as simple as possible. Btw idealy the method names should be |
I did the changes as you requested. Kind reminder that I believe a default small fee is an important step against spam. I didnt included a This can be a boomer when we have separated Wallet and Identity, so I started thinking on how one wallet can pay for a chat only identity tribute to talk. Im also in the research how to make an "gas anonymizer", so users dont tie wallet to chat identity, this seems to be possible by using a mixer to pay to the gas relayer. This research is happening in other swarm (Gas Abstraction/Identity/ERC725). The first version, more simple, is available here: The second version, with message signature support, is available here: The third version, with gas anonymizer support, would feature a similar change, an overload of |
Thank you @3esmit! |
@3esmit Is there a way to use the simple contract and later on add the possibility to use the MessageSigned capability in another one while still using this one as registry so that old versions of status still have access? |
@3esmit thanks for the detailed post btw! Another question, do we really need to emit a log for the simple contract? |
The upgradability is not implemented on this contract. Migration process can be defined in UI, but would be painful. New contract can read from old contract to skip migration of already defined values in older contract. I can deploy this contract and use a UpgradableInstance.sol (Proxy Contract, uses delegatecall) pointing to it, so we can have upgradability. |
The use of events is not necessary, but they might be important for updating the UI accordingly to the changes. As a common practice, meaningful state changes on the contract should fire events. However for this version of Tribute-to-Talk, indeed events are not necessary, as the values will be read from the contract always on demand, because we never know what is the new contact user will try to message, so we cannot cache that data locally, and once it's paid, there is no need of keeping sync on it. For recurring payments/subscription model this events might be interesting depending on the features of the contract, for example, if the subscription value was changed, this could be grabbed from an event, instead of every time reading all subscriptions to see if they changed value. |
Does this have implications for #8047? |
Description
Type: Feature
Summary: As a result of the issues found in #8129, we need to move storage of a user's tribute setting from IPFS to the TtT contract.
This means that we are also removing the personalized message from v1 of the feature.
Expected behavior
TtT works in 100% of scenarios.
Settings flow no longer contains option to set a personalised message.
Chat flow only displays system message requesting tribute amount, no personalized message.
Actual behavior
TtT is failing to send and receive information from IPFS.
The text was updated successfully, but these errors were encountered: