Welcome!

***
ATTENTION:  18 JULY 2024 - TESTNET IS UPGRADING TO 1.0 - beta (It will be a day or two to get frontends back up on Testnet. Thank you for your patience. - DashMoney)
UPDATE: 22 JULY 2024 - TESTNET IS OPERATION BUT JavaScript SDK is not functional yet. I will remove these when I have the Frontends back up on Testnet.
Issue has been resolved. Frontends will be up by 24 JULY 2024. It is a bit different. Everything is mainnet ready. I may have to add some alerts and info blocks.
UPDATE: 25 JULY 2024 - Still getting closer.
UPDATE 26 JULY 2024 - Decentralized Frontend at DashMoney.io is up on testnet. There are some likely changes to be made. And Dash Rentals will be up tomorrow.
***

DashMoney - New Approaches

Greetings, I have a new framework for understanding Dash frontends and dapps to share with you.

This new framework is made up of ‘Approaches’. The purpose of the “Approaches” is to better handle separation of concerns/risks and get more people active in using Dash Platform.

First, I will explain the new framework, then what I did from the previous proposal and what I plan to do for this proposal. Finally, Proxy Accounts at the end.


You can think of the Approaches as a user-development paradigm or a risk-management abstraction.

Previously, I discussed creating a new frontend using SolidJS, so other developers can learn how dapps work. But I was misunderstanding the actual problem. It is not “how to get developers?” This is misguided. Another false lead is adding a fee to Data Contract usage. This still doesn’t solve the actually issue of getting users to use Dash Platform.

The problem then is how to get people/users to use Dash Platform. Or how do you minimize risk and maximize opportunities for all parties, so people are interested, and therefore comfortable with getting involved and using Dash Platform.

Well first who are the users? Dash Entrepreneurs – people that want to earn Dash AND Dash Customers – people that want to pay in Dash.
So we have to build software products that enable Dash Entrepreneurs to bring their product/service to Dash Customers.

The Motivation for the Approaches is:  “Get to the users”.

ASIDE - My implementations with these Approaches will still utilize the React with Bootstrap style and the Frontend-Only Architecture.
- React with Bootstrap because I already have many components and can therefore develop it faster.
- Frontend-Only Architecture- all inputs only go between your browser and Dash Platform.

Now onto the Approaches..



1st Approach - Services Approach - smaller potential, not too risky so long as you can trust the software implementing it.

Types of use-cases/dapps:

a) Encrypted Platform Storage – Uses identity’s private keys to encrypt OR separate secret to encrypt and then store the cyphertext on Platform.

b) Social Backups – Shamir Secret Sharing by encrypted messaging of shamir secret shares sent to trusted others. In case, you lose your recovery phrase. (But doesn’t protect if your wallet is hacked/drained.)

c) Create/Coordinate Multisig wallet with others. (https://docs.dash.org/projects/core/en/stable/docs/examples/transaction-tutorial-p2sh-multisig.html  Why isn’t anyone building this on Platform?)

d) Proxy Accounts*** (Discussed more below)

e) Encrypted Messaging

PROS: This approach (is more subtle, less risky) shows ways that Dash Platform can be used for services or utilities. Even though you are connecting to others – it is others that you already know and you are not performing any kind of market exchange. But regardless the use-cases are beneficial.

CONS: I don’t find them to have the same potential as using Dash as money.

Thoughts: Probably best implemented as a desktop application or mobile app. Or someone could implement some kind of hardware wallet with limited access to just Dash Core and Platform that uses the dapps mentioned above.

Approach #2 –  Owner-Operator / Sole-Proprietor Approach (This is the one I will be focusing on for this proposal)

Simply put with Approach #2, only the owner's content is shown. Everyone else that goes to the site are customers.

Types of use-cases:

a) Rentals/Reservations – (individual rentals – Shopify version of AirBNB)

                    DashPayRentals.com

The DashPayRentals Frontend is currently build in Approach #2, and this is why it has a separate webpage/frontend.

b) Online Store – (like shopify) you host your own store, not an online marketplace but web store. So this is not like Amazon.  You deploy and run the store, the content and inventory is yours and only your content is shown.

Uses Dash Platform Data Contracts for Inventory and Orders, can use encryption for shipping  addresses, and operates entirely on Dash Platform(except for the sending of the Dash Frontend to the user’s browser). Inventory automatically adjusts based on confirmed orders from customers.

c) Cashier / Menu website for restaurants – copy My Store and Shopping Dapps from Decentralized Frontend and add displaying images capability to the Items and use Approach 2 format.

PROS: Uses images!(Actually, they are just image URLs pulling from imgur.com or similar) And is a lower risk point of entry for Dash entrepreneurs and users.

Why do I think this is a good fit.
    a) There are already web stores that accept cryptocurrencies.
    b) The operator of the store also owns the store.
    c) Uses Dash as money.

Creating a store is just as easy as launching the decentralized frontend, but there is no frontend fee.

1) Copy the Github code to your own Github. (There is no code that you need to write.)
        https://github.com/DashMoney/DashPayRentals-Frontend
2) Connect to a host/provider.  (Vercel, Netlify)
3) Add the environmental variables from the README.md (Use the settings/options menu of your host/provider.)
4) When you log in to your site, your identityId (an environmental variable) determines that you are the owner and logs you in to the merchant side of the frontend. Where you add the content that you want and handle the customer’s orders.

This limits the owner’s risk, because only their content is shown to the customer. And when used in conjunction with a Proxy Account, is very low risk for the customer.

CONS: Lots of people may host their own frontends, how do we know we can trust them. It is P2P, so Buyer Beware.
And wouldn’t it be better if there was a search capability, so you could search through all the stores to find what you wanted.

Problems that need to be solved.
    a) How will a user login to a website safely? Or at least with minimal risk?

•      browser extension or “Proxy Accounts” (discussed below)

    b) Search Capability

• I consider this an Approach #3 functionality.

    c) How is this different from when you were creating dapps separately before incorporating them all into the Decentralized Frontend?

• Those dapps allowed users to be both the ‘customer’ and the ‘merchant’. But this Approach #2 only the website’s owner can create content for the site. It is a sole proprietorship, everyone else that comes to the web store or rentals store are customers only.

3rd Approach – User-Networks/Decentralized Markets/Dash as Money Approach (including Defi and Search capabilities) – I still think this is the most valuable and highest potential approach.

a) Decentralized Frontends – Currently, the DashMoney-Decentralized-Frontend fits here.

b)  Search Capabilities - Location Search, Category Search, Keyword Search.
 In the previous proposal, I discussed a different Frontend with searching for businesses in a free market in Medical/Dental services. I would also include that idea here.

c) NFT and Fungible Tokens MarketPlaces -  Dapp Ventures (Equity Markets/Shares), MN shares tokens, CrowdFunding, or Tickets(One-time use NFT) etc.

PROS:  Substantial value and opportunity.

CONS: Needs momentum to build up the network effect, and conversely “the Tallest Blade of Grass is the first to be cut” so this is more risky.

THOUGHTS:
I don’t care for black market uses, because Dash can compete in the open/white market. I think Dash with Platform can compete with other currencies.
How to solve: “Go where you are treated best.” - Nomad Capitalist
Go to the white markets, where? What countries don’t care what you are using as money? Are there any?
This doesn’t mean that you need to incorporate a business or live in this jurisdiction. It could just be translate a Dash Frontend to that language and then market to people there.

- End of Approaches -

What I said I would do and What I did:

1) Finish Rides and Drivers Dapp.  (COMPLETE) Check it out on DashMoney.io

Load Boards and Truckers (BACK TO IDEAS/PLANNING)-  Most trucking load boards are desktop applications, because of all the information required. I could create the copy of Load Boards and Truckers that I had originally envisioned. A few days to just copy and paste and edit a few properties. But it would mostly just clutter the decentralized frontend. (Current thinking, this may become is own Approach #2)

2) Create the Reservations/Appointments Dapp (ALMOST COMPLETED) but in Approach #2- This is DashPayRentals.com

Left out Appointments(hourly schedule), with Reservations/Rentals being a daily schedule, it fits the time frame of owners checking every other day or so for scheduling. I think an hourly schedule needs immediate feedback. There needs to be a push notification service (email or SMS) for Dash Platform. This would entail some kind of backend, because Platform is a pull architecture.

3) Shift to SolidJS with some new dapps and a new frontend. (CHANGED)- Using SolidJS is still a great future option. But for now, I can still develop faster with ReactJS, but if we want to convert to SolidJS in the future then we can.

Also) DashMoney will not be hosting the Decentralized Frontends on mainnet, and I will only focus on development. (This is still my intention)

What I plan on doing for this proposal(estimates):

1) Finish Reservations – Rentals in Approach #2 - DashPayRentals.com (additional 1-2 weeks to finish)

2) Create a Dash Online Store in Approach #2 (5-6 weeks). The testnet version will be hosted at DashGetPaid.com when completed. This first version will have no encryption. Also initial limitations will be a few dozen items max and require periodic inventory update after 100 orders.

3) Proxy Accounts – incorporate into the Dash Frontends. (2-3 weeks)

4) Cashier/Menu in Approach #2 (2-3 weeks)

5) Figure out encryption for Data Contracts and implement it on messages, orders with shipping addresses, and designated revealed proxies. (No estimate)

6) Either do more dapps based on Approach #1: Build Encrypted Storage and Social Backups OR Work on NFT/FT Store if there is a satisfactory jurisdiction to operate in.  (No estimate)

Proxy Accounts

Motivation: Instead of using a browser extension, this is a very different solution that is only possible because of Dash Platform. Having a central wallet solution to control, pay, and sign with, creates a vulnerability - Centralization (e.g. MetaMask).

So if we could just completely separate accounts/wallets with DPNS Name Accounts/Wallets using more secure dedicated wallet applications and then other Decentralized Accounts(“Hot Wallets”) for accessing Dapps/Frontends, this may be a better approach. (And I have found it can offer very interesting possibilities.)
Because you wouldn't want to login to a new dapp/frontend with an account/wallet that has important/valuable stuff on it (DPNS Name Document or user’s funds). But you still want the dapp/frontend to know that it is you by name. You would want to use a proxy account.

• I have previously discussed the idea of “Decentralized Accounts”. I have discovered that others use different language. They use ‘Wallets’ to describe your self-custody crypto holding and ‘Accounts’ to describe any 3rd party crypto holdings.

• My language doesn’t conform to this description. The way I mean Decentralized Accounts is in the way that the mnemonic, recovery phrase, 12/24 word backup works, etc. And that way is as a “SOURCE OF ENTROPY”. Because the Source of Entropy approach to account creation is explicitly a “decentralized way of account creation.” (i.e. There is no central party in charge of account creation.)

Proxy Accounts is my way of formalizing Decentralized Accounts. And when I say formalize I mean implement with a Data Contract.

So let me describe how a Proxy Account works:

'Proxy Accounts' - Data Contract with 2 documentTypes:

1.  Controller document - this would be created by the same Identity that has the DPNS name you want the 'Proxy Account' to use. And contains a list of IdentityIds that are your “Approved Proxies" for verification.
2. Recipient document (this is the Proxy Account) – this would be created by the Proxy and just identifies the IdentityId of the Controller.

This may be altered slightly in the future, but the principle will be the same.


So a proxy has full functionality (create, edit, and delete documents/Data Contracts, etc.), but has complete separation from valuables (DPNS name document and user’s funds). You still need a little Dash in the proxy for Platform operations like 0.02 Dash. (rough estimate)

1) By tieing a name through proxy, it maintains reputation usage, but more importantly it allows for payments to occur through DashPay Data Contract.

2) It doesn’t require a trusted 3rd party extension wallet or require signing from a hardware wallet.

• For example, coordination of a market exchange(e.g. an order or request) can occur on the Merchant’s Frontend or a Decentralized Frontend with the Proxy Account, and payment can operate through the DPNS name with DashPay Data Contract. ***

3) The process can be very smooth for the user and creates a good separation of risk/concerns for users on all sides.

• Imagine you login to a website/frontend with a Proxy Account, you place the order, the merchant then confirms the order and establishes the DashPay Contact Request with the DPNS name attached to the proxy. Then you go to your DashPay Mobile wallet and complete the payment to the merchant.

This is like a 2-factor authentication in a way. (The Layer 1 Transaction through DashPay is really the essential and final say.)
    
There is more to Proxy Accounts (Future Possibilities)

• (Small) Proxy accounts can have “designated uses” so if an account is used on a frontend or dapp that doesn’t match its use as designated by “the controller” that can flag the merchant that there may be an issue.
• (Big) “Selective Revealed” Proxies so if you log into a dapp/frontend and want to make a purchase or request, but you don’t want others to know who if ordering(by viewing raw Platform data), but you do want the merchant to know, because reputation and/or DashPay Payment. Then you could send encrypted proxy info in the order/request and then only the merchant could identify you as the user of the proxy. (This would be a more involved feature.)

To finish up, proxy accounts create a complete and distinct separation between the two accounts/wallets and only associates them together through Dash Platform for usage of the DPNS name and DashPay. And that association can be established with different wallets and can be revoked by the Controller Identity at any time.
Why I think the distinction at the wallet level is important is because it allows full functionality to the proxy account and is very easy to implement, about as easy as getting a Dash name twice (once for the controller and once for the proxy).

And finally, please remember you don’t have to use Proxy Accounts, you can create any number of new  identities with different names or do whatever you want to do on Dash Platform. This is just a solution to help assist in maintaining maximal decentralization and therefore minimize risk for Dash users while still adding benefits of a reputation system and adding to the DashPay - Pay-by-Name ability.



-
-

-