- Offline Membership; - Pay to Email #7
Conversation
| * facilitation of donations reception. | ||
| * Further real-world impact is numerous as it can be leveraged to businesses, receipts, cashback, and so on, which smoothly blends-in to flexibility of native account abstraction. | ||
|
|
||
| In a sense it could be a proto (like very-very proto) Aztec Name System. Though I'm really not sure if we need one more NS; on the other hand sooner or later it will inevitably appear. |
There was a problem hiding this comment.
Hopefully this saves us from NS's per chain - https://chainagnostic.org/CAIPs/caip-50
There was a problem hiding this comment.
Thanks for a reading! I always start with the same feeling! X) Though then instantly the other thought arises that it's actually that the whole thing isn't gated as much as previous solutions. And I have no idea where good balance is for this. I mean being able to use existing names provided by a previous tech is cool, though it comes with the trust into the mail server owner, as they have the private key for signing everything.
|
|
||
| While I was hoping to pull off transfers between emails there were also other stuff to hold in the contract. It's a hashed signature preventing it reuse; contract addresses for used tickers to facilitate email payments. There was also a fee designated in the email for the one who processes the payment order (i.e. feeds the signed email into the contract) to incentivize the processing. Usually it should be the receiver but for email-to-email payments it could be anyone they choose to share the email. Also a _get balance_ function was designed so an user via a block-explorer integration could check their balance (via email responder, or a web-page). The email were designed to be highly structured to fight scamming users into accidentally put into a signed message enough data to trick them into a payment. The problem is it's a hard question what to do with an email payment order which spends more than the email sender has in the contract. Introduction payment order invalidation makes whole system more complicated to use than just having a wallet. So it will be valid until fed into the contract, and receiver can be sure they can redeem it when the sender has the balance. But I see no good way to stop an user from issuing such email payments without an intention to ever back-up the email payment (order) with a balance in the contract. | ||
|
|
||
| As a mitigation for the concern few ideas were researched: debt tracking, orders ordering (too many meanings for a word :sigh:), proving some data. |
There was a problem hiding this comment.
Perhaps a time-locked escrow? If not redeemed, funds can be reclaimed by the sender.
There was a problem hiding this comment.
I'm trying to stick to the concept where an average person with an email and a friend who uses Aztec could interact with the friend and be pulled into the orbit. X) And I guess an average person doesn't expect expiration when hears an "email payment". (And designing email stuff it turns out one have to think about so many scamming vectors.) =(
With a different approach this suggestion would be absolutely valid! I only wonder what would be a reason to build this upon email messages? I feel that it would much more secure and smooth (UX and otherwise) to just generate a link for it which could be sent via an email or any other communication method.
unfortunatelly it was caught in-between versions, so I need to tactically return to commented out code to progress the biggest problem is an error preventing roll back to `0.57`
link to the diagrams
link to the diagram
This holds two separate projects for each of the challenges. Pls, delve into respective README-files - they have quite some info.