Moeda.Casa
Search…
What is Next?
... from alfa( α ) to beta( β ) AND from kappa( κ ) to sigma( σ )

> jump into a possible future

As science fiction readers with tech skills, we can imagine a futuristic distributed system where everything are just coordinated ZEC transfers carrying encrypted action messages and metadata on MEMO fields.
For example, today, the weak side of privacy in Moeda are the known liquidity providers, who needs to send the private bank_history metadata, so the system can detect a payment was done to execute the ordered Contract. This could be wisely solved with an extended logic on top of the Zcash node on the Provider's side, as a layer, privately reading his own bank account history, observing new payments and sending a payment_done event:message to the pool's zaddr. We call it a Smart Node. In practical terms: if Moeda encodes the Contract UUID in the QRCode to the buyer, paid to the Agent, then, when the traditional payment is received with an identifier, this could be sent as a ZEC encrypted transaction to Moeda Smart Node as a proof it was received, and the Contract is executed with no need to know their bank history, in the Zero-knowledge spirit :D
Moeda started to conceptualize a Sentinel framework, observing and acting upon the received MEMO messages of up to 512 bytes to a node. ZecPages is an interesting example on how people can LIKE or REPLY messages, as some basic message-oriented (or event-based) architecture using Zcash as a distributed privacy layer. They could also benefit from our framework, being able to abstract a Smart Node logic, focusing all development effort on the Board logic itself.

< back to the next present

We had an exponential to-do list of tasks while developing Moeda, some we had to deprioritise - thankful for some project management collaboration, or we would still be playing around with the Nodes having triggered events from MEMO messages.
Practical next steps are,
    ZeroMQ
      While, theoretically, our server+database can handle 300 requests per second, and Oracle & Swaps seems to run well coordinated on a few Threads, a basic Chaos Engineering evidences we need a proper asynchronous Message Queuing to handle it all before things scale out.
        We would like to prepare for concurrent Contract requests before an official launch.
    Websockets!
      Prices should change on the front-end as they change on the back-end.
      So do the Contract's status after a QR-Code is paid.
    Export RESTful services API as ZKSwap do, beyond actual
      Terminal CLI app
      Implement a CryptoDealer Bot on Telegram
    DevOps
      precompile assets for deploy
      oracle workers as systemd.services
      basic DDoS protection on NGINX
      Docker image + scripts for a suddenly server change
      keep server sockets alive for active connections during a new deploy
    Our Dev to-do list has many open tasks and ideas to refine the system as a hole.
      UX
        checkbox to "hide wallet address" on QR-code page
          so "other payer" can become the buyer, unaware of Contract's wallet destination.
            Contracts ($BRL->$XYZ orders) could be generated to third-party processes
        Enhance CSS for mobile users
        Adapt as a Progressive Web App
    Test! Test! Test! Test! Test! Test!
    We also imagined an ~200-token to Shielded-ZEC Swap service, abstracting parts of our system.
Last modified 3mo ago